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

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

by StÃ©phane Ducasse

On May 19, 2010, at 12:47 AM, Tudor Girba wrote: > Hi Veronica, > > A bit of feedback: > - After loading Torch, the package contextual menu seems to crash the Monticello Browser > - You extend isSuper in RBProgramNode and RBVariableNode, which generates an override conflict with methods in Moose-Core. may be moose should have a look at the new AST-semantics package that lukas created because veronica used that ones originally and after a discussing with lukas he created ast-semantics > - The Glamour tags look different, so I guess you also have some Glamour overrides. That should not happen :). Maybe you have some suggestions for improvement, or maybe you just need the border for the [i] icon? > > Cheers, > Doru > > > On 18 May 2010, at 15:16, Veronica Isabel Uquillas Gomez wrote: > >> Hi Tudor, >> >> thank you :D >> >> sure!!! >> >> cheers, >> Veronica >> >> >> On 18 May 2010, at 11:39, Tudor Girba wrote: >> >>> Hi Veronica, >>> >>> It is pretty impressive :). >>> >>> Would it be Ok if I added this on the Moose page? >>> >>> Cheers, >>> Doru >>> >>> >>> On 18 May 2010, at 11:21, StÃ©phane Ducasse wrote: >>> >>>> Thanks veronica. >>>> lukas said that he was impressed this is a complement :) >>>> >>>> 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 >>> >>> -- >>> www.tudorgirba.com >>> >>> "Problem solving efficiency grows with the abstractness level of problem understanding." >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > _______________________________________________ > 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] [Moose-dev] rome

by StÃ©phane Ducasse

On May 19, 2010, at 12:08 AM, Schwab,Wilhelm K wrote: > Stef, > > Thanks, that helps. Where does post script fit into it? I am getting a few steps ahead of myself here, but some day it would be important to be able to print on Linux. Sooner than that, it would be nice to do something similar to passing a Windows HDC into a function in a DLL to speed up loops over lots of numbers. If nothing else, the primitives should serve as examples for anything I find missing. it could fit in there. Rome is an API. so we can after have the subclasses we would like draw on various canvases. > > One small frustration/irony has been that I now end up using code to turn what should be double arrays into ordinary collections of objects then into text to shove into gnuplot. There are some hints that I might be able to do better, but for now, the graphics from gnuplot are worth looking the other way :) > > Bill > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Tuesday, May 18, 2010 4:22 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [Moose-dev] rome > > rome is a new api for rendering image and text. > the idea is to offer a common api and several backends > one would balloon > another would be cairo/pango > a third one could be morphic30 primitives > > the idea is to get rome working with the vm primitives and/or balloon then to get it working with cairo via the ROME plugin > > then we could start to migrate the system to use this api. > > Stef > > > On May 18, 2010, at 11:14 PM, Schwab,Wilhelm K wrote: > >> Having some code to load will go a long way to answering my question, but more basic than that, I have tried (and failed miserably) to trace Rome back to some library/framework/etc. Is there any background reading I can do to see where this might be heading? Any pointers would be greatly appreciated. >> >> Bill >> >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Cyrille Delaunay >> Sent: Tuesday, May 18, 2010 4:04 AM >> To: Related to the development of Moose and other related tools >> Cc: pharo-project >> Subject: Re: [Pharo-project] [Moose-dev] rome >> >> Hello, >> >> Indeed, I started to build a small package, integrating one by one things working in Rome. >> You can load it from the squeak source repository: >> www.squeaksource.com/Athens >> >> For now, the working canvas are: >> - RomePluginCanvas (making the binding with cairo) >> - RomeBalloonCanvas >> >> You can see some examples in the class side of RomeDemo. >> All is not working. You can have a look at RomeDemo >> demoMovingCar, that should work with the RomePluginCanvas and the RomeBalloonCanvas. >> >> All that concern fonts is not yet integrated, a lot of thing are already broken in the sophie dev image. >> So all examples drawing simple form, without text, should work. >> >> You can also have a look at the version of Alain plantec, from which I based the package Athens. This is already a condense version of all stuffs from the sophie image. >> You can load it from: www.squeaksource.source/PharoTaskForces (load te last version of 'Rome'). >> >> The next steps are: >> - Integrate fonts >> - The class RomeSVGDemo doesn't work >> >> >> >> >> 2010/5/17 Tudor Girba <tudor.girba(a)gmail.com> Hi Cyrille, >> >> A bird told me that you are working on a Rome plugin. What is the >> status? Could we test something? :) >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "The coherence of a trip is given by the clearness of the goal." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> 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

> 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" stef

May 19, 2010

Re: [Pharo-project] Pharo sprint this Saturday

by Serge Stinckwich

On Wed, May 19, 2010 at 6:15 AM, Alexandre Bergel <alexandre.bergel(a)inria.fr> wrote: > Hi All, > > I am now with Mariano, working on the details for this Saturday. > More info on http://code.google.com/p/pharo/wiki/PharoSprints > Please, get in touch with Mariano first if you want to attend. > > As already said, the objective of the sprint will be to help produce Pharo 1.1 > > We will try to be present on IRC and/or iChat for remote pair programming :-) Hi Alex, maybe you could add the GMT time of the sprint if some people want to join. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 19, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by StÃ©phane Ducasse

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

May 19, 2010

Re: [Pharo-project] Pharo sprint this Saturday

by StÃ©phane Ducasse

Excellent! Do not forget to ask participants to sign the license agreement. Stef On May 19, 2010, at 1:15 AM, Alexandre Bergel wrote: > Hi All, > > I am now with Mariano, working on the details for this Saturday. > More info on http://code.google.com/p/pharo/wiki/PharoSprints > Please, get in touch with Mariano first if you want to attend. > > As already said, the objective of the sprint will be to help produce Pharo 1.1 > > We will try to be present on IRC and/or iChat for remote pair programming :-) > > Cheers, > Alexandre > > _______________________________________________ > 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 Damien Pollet

2010/5/19 Levente Uzonyi <leves(a)elte.hu>: > 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. What about updating the leadingChar in Pharo to match Squeak? (I know it's not the correct solution to the present problem but it's these kinds of sneaky differences between platform that make life difficult) What's the semantic difference between picking 0 or 255? Is one more correct than the other? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

May 19, 2010

Re: [Pharo-project] Feature: SystemOrganizer class>>default returns SystemOrganization

by Sean P. DeNigris

On May 18, 2010, at 11:42 AM, StÃ©phane Ducasse [via Smalltalk] <ml-node+2221496-1604744895-217701(a)n4.nabble.co m> wrote: > Right now SystemOrganization is a global stored in SystemDictionary. > And it would be nice to have a new instance named organizer held by > SystemDictionary that points > to the organizer associated with the SystemDictionary. > Similarly it would be good not to point to the global but use this > new methods. Ok, I undertand more now > Now if you have a class comments please send it we will integrate > it: add it to the bug tracker Okay I'll remove mention of it from the class comment and resubmit. > > I'm a bit worry to introduce a "singleton" It seemed to me like I was just, in effect, clarifying access to an existing singleton, no? Thanks for the explanations. Sean -- View this message in context: http://forum.world.st/Feature-SystemOrganizer-class-default-returns-SystemO… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 19, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by Igor Stasenko

2010/5/19 Eliot Miranda <eliot.miranda(a)gmail.com>: > 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 > Well, we could have a cake and eat it too. - rename #= to #isEqualToMethod: Then, the parts which intentionally require a comparisons, like you described above, will use this message. While for the rest of smalltalk code , sending #= will end up being #==. > > >> >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 19, 2010

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

by Henrik Sperre Johansen

On 19.05.2010 02:17, jaayer wrote: > > ============ Forwarded message ============ > From : jaayer<jaayer(a)zoho.com> > To :<alexandre.bergel(a)inria.fr> > Date : Tue, 18 May 2010 16:30:06 -0700 > Subject : Re: Decoding bug with XMLParser ? > ============ Forwarded message ============ > > ---- On Tue, 18 May 2010 02:29:18 -0700 Alexandre Bergel<alexandre.bergel(a)inria.fr> wrote ---- > >> To give a bit of context, the problem is: >> >> -=-=-=-=-=-=-=-=-=-=-=-= >> exampleEncodedXML >> ^'<?xml version="1.0" encoding="UTF-8"?> >> <test-data>…</test-data> >> ' >> >> testDecodingCharacters >> | xmlDocument element | >> "XMLTokenizer testDecodingCharacters" >> >> xmlDocument := XMLDOMParser parseDocumentFrom: self exampleEncodedXML readStream. >> element := xmlDocument firstTagNamed: #'test-data'. >> >> self assert: element contentString first codePoint = 8230 >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> #testDecodingCharacters goes yellow >> >>> Thinking of it, it's not really an encoding problem, rather a bug in >>> the entity->character conversion. I guess there should be a similar >>> test where there is an actual ellipsis character in the xml, instead >>> of the entity. >> Any idea how your test can goes green? >> >>> And now I realize our server will not be able to connect outside its >>> DMZ, so I won't be able to use the fix :D >> DMZ ? >> >> Cheers, >> Alexandre >> > Character references like the one above are handled using #nextCharReference. It does so by reading the number after the "&#" or "&x" prefix and then sending #value: to the class Unicode with that as the argument. If you evaluate the following code in a workspace with cmd-p: "(Unicode value: 8230) codePoint", you will see that the resulting code point is not what you would expect. For me it was "1069555750". The same behavior results when creating a Unicode character with #charFromUnicode:. Unless Unicode>>value: and Unicode>>charFromUnicode: are being used incorrectly, I am not sure that this is a bug, or least a bug in XML-Support. > > (I am working on adding full DTD support with validation and refactoring and re-engineering the parser at the moment, which is why minor releases have slowed to a trickle. I will take a closer look at how character encoding is handled in the process.) codePoint returns the raw value, which includes the leadingChar used to differentiate between different locale interpretations of the same character. In 1.0 this was 255 for WideCharacters, in 1.1 it has been changed to 0. ie, using codePoint in the test is erroneous, for a method which returns what you expect in both 1.0 and 1.1, use asUnicode. Cheers, Henry

May 19, 2010