November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Trailer format

by Nicolas Cellier

2009/11/15 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Hi Nicolas, > Â Thanks for your comments. I've checked all CompiledMethods in a Core image > > | col | > col := OrderedCollection new: 20. > CompiledMethod allInstancesDo: [: cm | > Â Â Â Â [ RBParser > Â Â Â Â Â Â Â Â parseMethod: cm getSource asString > Â Â Â Â Â Â Â Â onError: [ :msg :pos | Â col add: (msg -> cm) ] ] > Â Â Â Â on: Error do: [: ex | ] ]. > col explore > > which gave me 9 instances with problems, 8 of them have source pointer > problems and they are uninstalled, in explorer : > > self collect: [: assoc | assoc value getSource asString ] > I recommend trying: ScriptLoader new cleanUpMethods. That should eliminate most copies of CompiledMethod and replace with an original. > After applying your patch and condensing changes and source files, > I've tried again > > CompiledMethod allInstances first getSource asString > > and the Decompiler raises now an exception, is this expected? > It would be too hard to correct the source pointer numbers of > uninstalled compiled methods? > > Cheers, > > HernÃ¡n > Decompiler might have bugs, some since closure refactorings, some older, but at least we know something is wrong. I always prefer a Debugger to a false response ! Instead of simply erasing the source pointer of un-installed CompiledMethod during condenseChanges/condenseSources, we could log their source. But it was already too late when I discovered this (while chasing MethodProperties)... > 2009/11/15 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> You should check this: >> Â CompiledMethod allInstances first isInstalled. >> >> If false, the answer probably is at >> http://code.google.com/p/pharo/issues/detail?id=1423 >> >> 2009/11/15 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >>> Hi all, >>> Â Possibly this is a bug. To reproduce it download a Pharo-Core (I'm >>> using #11045), update from servers and evaluate: >>> >>> CompiledMethod allInstances first getSource asString >>> >>> if you see something like the following result, some things could be wrong: >>> >>> Â '(firstCollection at: index) equals: Â a. >>> Â Â Â Â Â Â Â Â self assert: (secondCollection at: index) equals: Â b.] >>> >>> Â Â Â Â ' >>> >>> because that isn't a message pattern. The compiled method instance is >>> >>> (BlockClosure>>#newProcess "a CompiledMethod(1962)") >>> >>> and the source string is in PharoV10.sources, but >>> #fileIndexFromSourcePointer: is answering "2" which is the changes >>> file and should answer "1"... someone with a better understanding of >>> sources arithmetic may comment. >>> Cheers, >>> >>> HernÃ¡n >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 15, 2009

Re: [Pharo-project] Trailer format

by HernÃ¡n Morales Durand

Hi Nicolas, Thanks for your comments. I've checked all CompiledMethods in a Core image | col | col := OrderedCollection new: 20. CompiledMethod allInstancesDo: [: cm | [ RBParser parseMethod: cm getSource asString onError: [ :msg :pos | col add: (msg -> cm) ] ] on: Error do: [: ex | ] ]. col explore which gave me 9 instances with problems, 8 of them have source pointer problems and they are uninstalled, in explorer : self collect: [: assoc | assoc value getSource asString ] After applying your patch and condensing changes and source files, I've tried again CompiledMethod allInstances first getSource asString and the Decompiler raises now an exception, is this expected? It would be too hard to correct the source pointer numbers of uninstalled compiled methods? Cheers, HernÃ¡n 2009/11/15 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > You should check this: > Â CompiledMethod allInstances first isInstalled. > > If false, the answer probably is at > http://code.google.com/p/pharo/issues/detail?id=1423 > > 2009/11/15 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >> Hi all, >> Â Possibly this is a bug. To reproduce it download a Pharo-Core (I'm >> using #11045), update from servers and evaluate: >> >> CompiledMethod allInstances first getSource asString >> >> if you see something like the following result, some things could be wrong: >> >> Â '(firstCollection at: index) equals: Â a. >> Â Â Â Â Â Â Â Â self assert: (secondCollection at: index) equals: Â b.] >> >> Â Â Â Â ' >> >> because that isn't a message pattern. The compiled method instance is >> >> (BlockClosure>>#newProcess "a CompiledMethod(1962)") >> >> and the source string is in PharoV10.sources, but >> #fileIndexFromSourcePointer: is answering "2" which is the changes >> file and should answer "1"... someone with a better understanding of >> sources arithmetic may comment. >> Cheers, >> >> HernÃ¡n >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 15, 2009

[Pharo-project] SystemVersion 1.0 and 1.1

by Michael Roberts

Please review these changes for 1.0 & 1.1 branches. This currently only bootstraps better version strings. After this I have some class changes and deprecations for 1.1 (only). =1.0 branch= http://code.google.com/p/pharo/issues/detail?id=1446 In the inbox is a template update: Name: ScriptLoader-MikeRoberts.1134 Author: MikeRoberts Ancestors: ScriptLoader-AdrianLienhard.1133 =1.1 branch= http://code.google.com/p/pharo/issues/detail?id=1447 In the inbox is a template update: Name: ScriptLoader11-MikeRoberts.54 Author: MikeRoberts Ancestors: ScriptLoader11-StephaneDucasse.53 === This just sets the system version in both branches. Note that the two update lists must be updated immediately afterwards. This has the ability to break the update stream so please review carefully! thanks, Mike

Nov. 15, 2009

[Pharo-project] Package name "SharedPool-Speech", "SharedPool-FFI", etc ?

by David T. Lewis

There is currently a package dependency for VMMaker that requires the entire Speech package (for KlattSynthesizerPlugin). This can be resolved through a minor refactoring of Speech, mainly to move the shared pool class KlattResonatorIndices into a separate package, e.g. "SharedPool-Speech". Are there any objections to adopting the package name "SharedPool-Speech" for this? By implication, we might also have "SharedPool-FFI" and so forth. If no objections, I'll make a SqueakSource project for Speech, starting with the Speech-md.9.mcz from Squeak 3.9a, and updating it as described. With that in place, VMMaker will be loadable with just the shared pool prerequisite, rather than the entire Speech package. No flame wars please, just speak up if there is a good reason that I should *not* do this. Thanks!

Nov. 15, 2009

Re: [Pharo-project] Trailer format

by Nicolas Cellier

You should check this: CompiledMethod allInstances first isInstalled. If false, the answer probably is at http://code.google.com/p/pharo/issues/detail?id=1423 2009/11/15 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Hi all, > Â Possibly this is a bug. To reproduce it download a Pharo-Core (I'm > using #11045), update from servers and evaluate: > > CompiledMethod allInstances first getSource asString > > if you see something like the following result, some things could be wrong: > > Â '(firstCollection at: index) equals: Â a. > Â Â Â Â Â Â Â Â self assert: (secondCollection at: index) equals: Â b.] > > Â Â Â Â ' > > because that isn't a message pattern. The compiled method instance is > > (BlockClosure>>#newProcess "a CompiledMethod(1962)") > > and the source string is in PharoV10.sources, but > #fileIndexFromSourcePointer: is answering "2" which is the changes > file and should answer "1"... someone with a better understanding of > sources arithmetic may comment. > Cheers, > > HernÃ¡n > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 15, 2009

Re: [Pharo-project] installing hyper in pharo

by Philippe Marschall

Alexandre Bergel wrote: > For people who wonder what Hyper is. Philippe made a port of Hyper > from Gemstone. Here is what you can read from the Gemstone squeaksource: > Hyper is a web server written in Smalltalk. It runs on VisualWorks, > VisualAge, GemStone and Squeak. Sport is the platform-specific layer. > Hyper is licensed as LGPL. Yeah, but it doesn't work. See the mail of Lukas for why. Cheers Philippe

Nov. 15, 2009

Re: [Pharo-project] annotation pane revival

by Alain Plantec

Alain Plantec a Ã©crit : > StÃ©phane Ducasse a Ã©crit : > >> you should publish the slice with the ***other*** mcz in the inbox ? done now Alain > I was not publishing, I was only asking for feedbacks. >

Nov. 15, 2009

[Pharo-project] Trailer format

by HernÃ¡n Morales Durand

Hi all, Possibly this is a bug. To reproduce it download a Pharo-Core (I'm using #11045), update from servers and evaluate: CompiledMethod allInstances first getSource asString if you see something like the following result, some things could be wrong: '(firstCollection at: index) equals: a. self assert: (secondCollection at: index) equals: b.] ' because that isn't a message pattern. The compiled method instance is (BlockClosure>>#newProcess "a CompiledMethod(1962)") and the source string is in PharoV10.sources, but #fileIndexFromSourcePointer: is answering "2" which is the changes file and should answer "1"... someone with a better understanding of sources arithmetic may comment. Cheers, HernÃ¡n

Nov. 15, 2009

Re: [Pharo-project] annotation pane revival

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > you should publish the slice with the ***other*** mcz in the inbox ? > > I was not publishing, I was only asking for feedbacks. > On Nov 14, 2009, at 2:14 PM, Alain Plantec wrote: > > >> Hi all, >> For those who like the annotation pane in browsers, changes sorter etc (of Pharo-core) >> Here is a SLICE that make it work again. >> It also cleans PluggableTextMorph (remove dirty code related to annotation) >> Could you check before I send it to the inbox ? >> thanks >> Alain >> <SLICE-annotationRevival-AlainPlantec.1.mcz>_______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > >

Nov. 15, 2009

[Pharo-project] [update 1.1] #11044-45

by StÃ©phane Ducasse

11044 ----- - Issue 1443: Speed-up PackageInfo classesAndMetaClasses by answering a Set - Issue 1442: part one - fixCollisionsFrom: broken in case of nil key in Dictionary - Issue 797: Pressing key Ã¹ (u grave) on french keyboard -> Error 11045 ----- - Issue 1442: Part two fixCollisionsFrom: broken in case of nil key in Dictionary - Issue 1293: HTTPSocket waits forever on data => HTTP 1.0 - HTTP 1.1 incompability : parse connection -> close header to solve

Nov. 15, 2009