Unicode Changeset

[JWPlatt]

The GoMe summary of the Guild meeting said Christian was working on getting unicode over to us. Rarified has been working with the changesets Adam gave him, so if Christian has something already prepared, please let us know.

Thanks.

[Hoikas]

Sorry, the GoMe summary was in error. I spent a few lines praising Christian's work and it got slightly misquoted.

I'm looking forward to seeing what you guys come up with though.

[JWPlatt]

He deserves it, and thanks.

[JWPlatt]

Adam, I haven't looked for myself but I get the impression by the number of changesets that the unicode stuff is larger than some of the simpler changes you have made. Could you generate some individual pull requests on Bitbucket for - just throwing out a number - the top ten of your smallest, most effective (favorite) changes to consider? i.e., bang for the buck.

[Christian Walther]

What Hoikas said. I have posted a comment on http://www.guildofmessengers.com/en/con ... tober-2011 and Leo has amended his wording. (It still sounds a bit exaggerated to me though.)

That said, at one point I did actually start to look into porting the Unicode stuff to CWE-ou, however I haven’t gotten much farther than identifying the changesets that Hoikas later posted here, always hoping that someone who can spare more time than I would beat me to it. So please don’t count on me too much – there’s a deadline approaching in my day job, so I’ll continue to be busy for at least another month. I’ve also been working on getting my local MOSS server set up to test things with CWE-ou.

JW, I was about to mention the same thing about the complexity. I’m thinking this one, once the revised version is done, would be a nice candidate for starters. And try not to greet Hoikas with the same humongous review machinery as you did Filbert, you’ll be sure to frustrate him away.

[JWPlatt]

Heh, yeah - noted. Bitbucket is there to make it easy. The Fisheye/Crucible test was a sideline for our own purposes. Rarified may set up additional issues like that to test and refine the process and track the Bitbucket activity on Foundry, but Adam can consider it completely optional.

Actually, anyone could start the issue. It won't always be up to us, and preferably won't be as folks start to run things on their own.

[Hoikas]

Adam, I haven't looked for myself but I get the impression by the number of changesets that the unicode stuff is larger than some of the simpler changes you have made. Could you generate some individual pull requests on Bitbucket for - just throwing out a number - the top ten of your smallest, most effective (favorite) changes to consider? i.e., bang for the buck.

Indeed, unicode is a very complicated change. I'll take a look at everything that I have contributed and see what would be most worthwhile with the least amount of work. It might take me awhile to get bitbucket pull requests made though--I am no VCS expert, and I'm unfamiliar with how to get my changes on bitbucket. I suppose that will mean rereading some of CW's post on the subject. For my own sanity, I will start with this fix (yay, one-liner).

[rarified]

Adam,

I've already extracted your unicode changesets as patches, and applied them to a fork of CWE-ou.

The main question I have is: there are changes to python code compilation/module loading in some of the earlier changesets. Are they needed for your changes in MOULSCRIPT? I have not applied those (the module) changes yet.

Also, Branan changed some buffer allocation from the traceable heap allocation to stack allocation, which I have left out. Was that for a performance reason? I'd like to not change that, if for no other reason than to keep the debugging interface the same for Cyan.

Thanks
_R

[Hoikas]

Oh good. I suppose I need to get with the program now

The python compilation and loading changes were made for two reasons. When we fist updated to Python 2.7, we found that using python.pak files no longer worked. Therefore, we had to write a PEP 302 module loader for the python packages. Later, we needed support for python modules because python unicode support requires the "encodings" module, which is not included with MOUL. So, branan changed the python compilation code in plPythonPack to support modules and modified our PEP 302 hook to support Python modules.

Sorry about the indirect answer, but that's the best explanation I can think of.

Also, Branan changed some buffer allocation from the traceable heap allocation to stack allocation, which I have left out. Was that for a performance reason? I'd like to not change that, if for no other reason than to keep the debugging interface the same for Cyan.

I don't really recall any changes in buffer allocation. Can you show me the change? Perhaps that will jog my memory.

EDIT: Typo

[rarified]

I don't really recall any changes in buffer allocation. Can you show me the change? Perhaps that will jog my memory.

Git changeset 56e101ed83111b7fddf9d3dd75ef0eda16ac51ba in CWE. Sorry, it wasn't Branan, it was Michael Hansen.

Code: Select all

Index: Sources/Plasma/PubUtilLib/plInputCore/plInputDevice.cpp
===================================================================
diff -u -N -rf8bc99d0c300116c9d2ee883d8256d3a28b9b07c -r56e101ed83111b7fddf9d3dd75ef0eda16ac51ba
--- Sources/Plasma/PubUtilLib/plInputCore/plInputDevice.cpp	(.../plInputDevice.cpp)	(revision f8bc99d0c300116c9d2ee883d8256d3a28b9b07c)
+++ Sources/Plasma/PubUtilLib/plInputCore/plInputDevice.cpp	(.../plInputDevice.cpp)	(revision 56e101ed83111b7fddf9d3dd75ef0eda16ac51ba)
@@ -208,8 +208,8 @@
 {
     short   code = msg->GetKeyCode();
     char    c = 0;
-    unsigned char *kbState = TRACKED_NEW unsigned char[256];
-    unsigned char *buffer = TRACKED_NEW unsigned char[256];
+    unsigned char kbState[256];
+    unsigned char buffer[256];
     UINT scanCode;
     int     retVal;
 
@@ -320,9 +320,6 @@
             break;
     }
 
-    delete [] kbState;
-    delete [] buffer;
-
     return c;
 }