[Pharo-project] Re: about http://bugs.squeak.org/view.php?id=6336
Thanks. Another problem with real atomic loading. Stef
Hi Stef,
there is nothing special with the two change sets except their fileIn order, since instances of Character are used while both of them are loaded and compiled ...
The 3.10 release team attempted to make .mcz out of them but failed miserably, so I suggest you just file them in.
Let me know how it worked for you; perhaps also see if before/after the .image indeed gets smaller by ca. 300 KB.
Ah, and before I forget: because of Association #hash #= (since 3.8 or so, Marcus knows the problem), compilation of Unicode methods take looong, since one of its class variables has a populated SparseLarge* thing which is #hash'ed and #='ed when compiling access to each class variable :( But this is a genaral problem, which just manifests, when compiling Unicode, with pain.
Cheers, Klaus
On Tue, 23 Sep 2008 21:52:35 +0200, Stéphane Ducasse wrote:
Hi klaus
I would like to include the following in pharo about http://bugs.squeak.org/view.php?id=6336
can you tell me if I should pay attention to something in particular.
Stef
On 24.09.2008, at 09:02, Stéphane Ducasse wrote:
Thanks. Another problem with real atomic loading.
Stef
Hi Stef,
there is nothing special with the two change sets except their fileIn order, since instances of Character are used while both of them are loaded and compiled ...
The 3.10 release team attempted to make .mcz out of them but failed miserably, so I suggest you just file them in.
Let me know how it worked for you; perhaps also see if before/after the .image indeed gets smaller by ca. 300 KB.
Ah, and before I forget: because of Association #hash #= (since 3.8 or so, Marcus knows the problem), compilation of Unicode methods take looong, since one of its class variables has a populated SparseLarge* thing which is #hash'ed and #='ed when compiling access to each class variable :( But this is a genaral problem, which just manifests, when compiling Unicode, with pain.
I added Association = while working on AOStA... I searched for a long time for some bug until I found that = was inherited from LookUpKey only taking the key into account. I checked with VW, and there it checks both key and value for =. What I then did is to add a hash, too. That was no good idea, as it makes now the #hash very slow. In VW, theu just use the #hash of LookUpKey. So: we should do the same. Keep =, but remove #hash. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
participants (2)
-
Marcus Denker -
Stéphane Ducasse