May 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] about menu not showing up

by StÃ©phane Ducasse

Hi alain in scriptLoader I added a menu and I do not why it was working and now it does not show up. Can yu have a look? Normally you should do ScriptLoader showIntegrationMenu Tx Stef

May 19, 2010

[Pharo-project] about condenseChanges

by StÃ©phane Ducasse

Hi marcus/others I did a condenseChanges and I'm planning to issue a new image. I wanted to avoid to put it in the stream of updates because since it takes a long time everybody can be penalized but at the same time we will not have the same flow if we start from 1.0 and press update. Thoughts? Stef

May 19, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by Nicolas Cellier

Hi Eliot, What about super sends ? Object>>beNasty ^self Collection>>beNasty self addLast; 1. super beNasty. OrderedCollection>>beNasty self addLast; 1. super beNasty. Do you think you can remove OrderedCollection>>beNasty ? Nicolas 2010/5/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Elliot I think that we already took into changes made by nicolas. > > Stef > > On May 19, 2010, at 2:35 AM, Eliot Miranda wrote: > >> Hi Lukas, >> >> On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >> > Same method in different classes do not Â equal eachother though, if I've not made a mistake in: >> > >> > |mrtCp| >> > mrtCp := (InstructionClient>>#methodReturnTop) copy. >> > mrtCp literalAt: 2 put: #ContextPart->ContextPart. >> > (InstructionClient>>#methodReturnTop) = mrtCp >> >> For methods that send super the behavior changes if you change the >> class binding. That's probably why it is not ignored for #=. >> >> In fact I would suggest to #= from compiled method altogether, in most >> cases it doesn't do what one would expect in a given context anyway. >> There are too many and possibility completely different >> interpretations of #= for CompiledMethod. #== is the only decent >> implementation for this class. >> >> I sympathise but I think there is a reasonable default interpretation of #= for CompiledMethod that is what most people want. Â The intent is to answer whether two methods have the same execution semantics and same method tags & properties, e.g. if one were to compile the same source code in two different classes that had the same inst var offsets for the inst vars in the methods, then one would want those methods to be #=. Â This allows tests such as >> - checking whether a subclass has a method that is #= to a superclass, and is hence redundant. >> - checking whether a set of sourceless methods are equivalent so that they may be shared under different selectors (e.g. think auto-generated accessor methods which can be cached and shared) >> So for this informal definition the selector and the class are irrelevant, but bytecodes and literals (apart from the selector and method class literals) are relevant. Â Its almost a short-cut comparison of error-free decompilation, although there are differences in the bytecode that wouldn't show in decompilation (e.g. using long branches for short branches). >> >> The current definition serves for compiler hackers as it tells you accurately whether a compiler change has an effect on the bytecode, can be used to test whether compilation followed by decompilation followed by recompilation has an effect, etc. Â While it may not be a universal code comparison method it has met my needs throughout the closure compiler so at least I'm pretty happy with it. >> >> (pleading for CompiledMethod>>#= to stay the same as the current Squeak 4.1 definition, which ever since Nichoas Celier's float compilation changes, is pretty darned good). >> >> best >> Eliot >> >> >> >> >> >> Lukas >> >> > >> > At the very least, the branches of >> > index = 1 and: [ #(117 120) includes: self primitive ]) >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ >> > >> > REALLY deserve some comments... >> > >> > Cheers, >> > Henry >> > >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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 >

May 19, 2010

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

by StÃ©phane Ducasse

I always liked 68000.... when I imagine my codev implemented our game in overall 300000 assembly line of code and also using 6502 with 3 registers and one specific... 68000 was a dream :) Stef On May 19, 2010, at 12:28 PM, Alexandre Bergel wrote: >>> >>> Now I was wondering why in squeak and pharo >>> (Character value: 1069555750) leadingChar. "===> 255" >> >> Because the 22 least significant bits represent the #charCode and the rest (8 bits) are the #leadingChar. So 1069555750 means that #charCode is 8230 and the #leadingChar is 255. > > Pfff... Remind me the old assembly lecture :-) > > Thank you all for your comment. I will fix the test. > > Alexandre > > >> >> >> Levente >> >>> >>> stef >>> >>> >>> >>> >>> _______________________________________________ >>> 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

May 19, 2010

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

by Alexandre Bergel

>> >> Now I was wondering why in squeak and pharo >> (Character value: 1069555750) leadingChar. "===> 255" > > Because the 22 least significant bits represent the #charCode and the rest (8 bits) are the #leadingChar. So 1069555750 means that #charCode is 8230 and the #leadingChar is 255. Pfff... Remind me the old assembly lecture :-) Thank you all for your comment. I will fix the test. Alexandre > > > Levente > >> >> stef >> >> >> >> >> _______________________________________________ >> 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

May 19, 2010

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

by Levente Uzonyi

On Wed, 19 May 2010, StÃ©phane Ducasse wrote: >> Another "hard to quote" message, but I hope my answer will be clear. >> The "problem" is that in Pharo the leadingChar for unicode characters is still 255. This was changed in Squeak 4.1 to 0. So in Squeak 4.1: >> (Unicode value: 8230) codePoint. "===> 8230" >> >> While in Pharo it's: >> (Unicode value: 8230) codePoint. "===> 1069555750" >> (Character value: 1069555750) charCode. "===> 8230" >> (Character value: 1069555750) leadingChar. "===> 255" >> >> So using #charCode instead of #codePoint is the solution. > > Thanks levente. > In Pharo 1.1 we get the same as in squeak. >> (Unicode value: 8230) codePoint. "===> 1069555750" >> (Character value: 1069555750) charCode. "===> 8230" >> (Character value: 1069555750) leadingChar. "===> 255" > > > > 0 locale encoded by 0 is Unicode > > initialize > > self allSubclassesDo: [:each | each initialize]. > > EncodedCharSets := Array new: 256. > > EncodedCharSets at: 0+1 put: Unicode "Latin1Environment". > EncodedCharSets at: 1+1 put: JISX0208. > EncodedCharSets at: 2+1 put: GB2312. > EncodedCharSets at: 3+1 put: KSX1001. > EncodedCharSets at: 4+1 put: JISX0208. > EncodedCharSets at: 5+1 put: JapaneseEnvironment. > EncodedCharSets at: 6+1 put: SimplifiedChineseEnvironment. > EncodedCharSets at: 7+1 put: KoreanEnvironment. > EncodedCharSets at: 8+1 put: GB2312. > "EncodedCharSets at: 9+1 put: UnicodeTraditionalChinese." > "EncodedCharSets at: 10+1 put: UnicodeVietnamese." > EncodedCharSets at: 12+1 put: KSX1001. > EncodedCharSets at: 13+1 put: GreekEnvironment. > EncodedCharSets at: 14+1 put: Latin2Environment. > EncodedCharSets at: 15+1 put: RussianEnvironment. > EncodedCharSets at: 16+1 put: NepaleseEnvironment. > EncodedCharSets at: 256 put: Unicode. > >> > > Now I was wondering why in squeak and pharo > (Character value: 1069555750) leadingChar. "===> 255" Because the 22 least significant bits represent the #charCode and the rest (8 bits) are the #leadingChar. So 1069555750 means that #charCode is 8230 and the #leadingChar is 255. Levente > > stef > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 19, 2010

Re: [Pharo-project] TORCH: supporting source-code change integration

by Veronica Isabel Uquillas Gomez

On 18 May 2010, at 12:55, StÃ©phane Ducasse wrote: > veronica > > I would love to have the two clouds on the same page :) or maybe mixed together, and you see the symbols in greed and red!! > Doru we are looking for a nice way to represent the left top corner (which summarize the changes) if you have any idea. thinking to add icons and tags in that panel, instead of plain text > > Stef > > On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote: > >> Dear all, >> >> I would like to announce Torch, a tool for supporting source-code change integration. For now, it offers visualizations of the changes and enhanced change lists. >> Torch can be accessed through Monticello (in the main MC browser, in the repository browser or in the history browser). Selecting a version or slice, you can view the changes with Torch using the contextual menu. >> Once you open the Torch dashboard, you can access the enhanced change list or a detailed visualization via the contextual menu as well. >> >> Torch is available on SqueakSource, the repository is named Torch, and you need to load the ConfigurationOfTorch package. >> It runs in a dev or core image. >> >> For a dev image. >> - ConfigurationOfTorch loadVersion10 >> >> For a core image. >> 1) Set fonts - described in the attached file. >> 2) ConfigurationOfTorch loadDefault >> >> I would appreciate comments and feedback! >> >> Best Regards, >> VerÃ³nica Uquillas GÃ³mez >> Vrije University Brussel - SOFT Lab >> University of Lille - RMOD Team >> >> <torchFontsScript.st> >> >> >> >> _______________________________________________ >> 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

May 19, 2010

Re: [Pharo-project] Pharo 1.1: String-> arithmetic

by Veronica Isabel Uquillas Gomez

gracias Fernando... it is clear now!! Vero On 19 May 2010, at 10:49, Fernando olivero wrote: > Hola Vero, check out the Collection arithmethic method category emails of the previous days. > (http://code.google.com/p/pharo/issues/detail?id=332) > Saludos, > Fernando > > On May 19, 2010, at 10:26 AM, Veronica Isabel Uquillas Gomez wrote: > >> Hi Stef, >> >> In Pharo 1.1 the class String has not the protocol arithmetic and its methods... why? >> Got errors when running some tests. Could I add them with a new version of Torch? >> >> Vero >> _______________________________________________ >> 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

May 19, 2010

Re: [Pharo-project] Pharo 1.1: String-> arithmetic

by Veronica Isabel Uquillas Gomez

On 19 May 2010, at 10:35, StÃ©phane Ducasse wrote: > because > > 'abc' * 2 does not make sense. > and because this was limited anyway. > > better use plain collect:... I am not using them... it is in one of my prerequisites... > >> Hi Stef, >> >> In Pharo 1.1 the class String has not the protocol arithmetic and its methods... why? >> Got errors when running some tests. Could I add them with a new version of Torch? > > I would prefer not. ok!! > >> >> Vero >> _______________________________________________ >> 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

May 19, 2010

Re: [Pharo-project] Pharo 1.1: String-> arithmetic

by Fernando olivero

Hola Vero, check out the Collection arithmethic method category emails of the previous days. (http://code.google.com/p/pharo/issues/detail?id=332) Saludos, Fernando On May 19, 2010, at 10:26 AM, Veronica Isabel Uquillas Gomez wrote: > Hi Stef, > > In Pharo 1.1 the class String has not the protocol arithmetic and its methods... why? > Got errors when running some tests. Could I add them with a new version of Torch? > > Vero > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 19, 2010