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

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

by Levente Uzonyi

On Tue, 18 May 2010, 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.) 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. Levente _______________________________________________ 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] Managing Pharo external packages with Metacello, please read!

by Dale Henrichs

Yes, I don't think that it is a good idea to modify the configuration when it is published in the PharoXXMetacelloRepository. In the end the reason for this discussion revolves around the desire to provide a simple method for developers/users to load projects that are "known/tested to work in PharoXX". Creating a PharoXXMetacelloRepository means that we have a "white list" of configurations that are"known/tested to work in PharoXX". GoferProjectLoader provides an API for loading projects from a target repository. The API makes it very simple to load a particular project by name, without having to specify more details about the version of groups involved. It also means that one can arrange to do special things under the cover of the GoferProjectLoader, like point to a different repository based upon the version of Pharo that it is running in ... I think that what we need in addition to a "white list" of projects, a "white list" of _versions_ that are "known/tested to work in PharoXX." I think it would be straightforward to subclass/extend the GoferProjectLoader to add the notion of a version/group "white list" that records the exact configuration/version/group(s) that have been tested and known to work. This same extension to GoferProjectLoader can automatically include an overrideRepositories: to ensure that all projects/packages are loaded from the PharoXXMetacelloRepository repository... By default, the GoferProjectLoader loaded into PharoXX would point to PharoXXMetacelloRepository and use the "white list" of versions. Once a developer/user has become comfortable using PharoXX, he/she can configure GoferProjectLoader to suit his/her needs as well as directly load Configurations/versions that are not on the "white list" (using Metacello directly) without requiring any changes to the configurations or where they originated from... So in the end the following expression will do things differently depending upon a) which version of Pharo it is executed in and b) whether or not you are using the 'default' GoferProjectLoader: Gofer project load: 'SqueakDBX'. All while using the same Configuration... Dale StÃ©phane Ducasse wrote: Yes I think that this is what dale proposed. Dale is off line today but he will probably comment Stef On May 18, 2010, at 10:59 AM, Tudor Girba wrote: Hi, I like this approach: 1. Projects can continue to be built independently. For example, in Moose, we have already a process with multiple configurations (one for each repository) depending on each other. 2. When ready, the Configurations and all related packages are "published" in the PharoXXMetacelloRepository. Having a package per Configuration makes it easy to copy it. The only problem is that the code of Configuration mentions explicitly the repository (especially in the case of having nested Configurations, I point to a configuration by specifying the repository, package, and class). So, I guess the simplest thing here would be to provide the default "load" method to already override dynamically all repositories with the PharoXXMetacelloRepository. Cheers, Doru On 18 May 2010, at 09:32, StÃ©phane Ducasse wrote: I understand nicolas. Now my agenda is more than full. and the proposal is here. Simple ========================================================== One repo per version Pharo1.0, Pharo11 ... MetacelloRepository containing **published** configurationOfXXX -> all the dependent packages are copied locally + configuration ready to load using load. A project contain its single/or several configurationOfMyProject with the complete history people commit the config to their repository and if they want they **publish** from their repository to the version repository a version. This version is frozen -> all the dependent packages are copied locally + configuration ready to load using load. For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages. We can use automatic build server to validate the status or migration between different repositories ========================================================== Stef On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote: The meaning of my message was don't do it for squeak, but do it for yourself. I don't doubt the mailing list is a mine of information, but even in the best mine you need to dig a lot before extracting the gold nuggets. Of course, I've got no right to control your agenda, who am I ? You can consider the subject close, and I won't find your attitude shocking at all. But next time, consider writing a rationale for your own, it will increase quality of Pharo decision process. Best regards Nicolas 2010/5/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr><mailto:stephane.ducasse@inria.fr>: nicolas all the information is in the metacello mailing-list and we already posted many mails on that topics in this mailing list. I'm sorry but I do not have the time to repeat again what we said. Now since I'm in a really good mood in a nutshell one repo per version Pharo1.0, Pharo11 ... MetacelloRepository containing configurationOfXXX frozen = all the dependent packages are copied locally + configuration ready to load using load. a project contain its single/or whatever configurationOfMyProject people publish the config to their repository and if they want they push from their repository to the version repository a version that they freeze (may be using tags) For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages. Then we have a server that load configuration and barks if something wrong happen. And may be we kick out the configurationofXXX from MetacelloRepositories Steph, I understand how boring it may seem: - you already discussed the subject over and over - you already took decisions and now we come later with new proposals, and ask you to reconsider the work again... more than that. :) It looks like if we did not talk or think about what we are doing. As for the Preferences/Settings, Pharo choices are probably very weel thought. However, every solution will come with trade offs, and it would be good to have a rationale justifying the choices you made, and perhaps more importantly justifying why you did abandon some solutions, because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... and find different answers in different context. Note that Squeak evolutions might have influence on Pharo too, and it's part of the context... I strongly encourage you to establish your rationale on Pharo grounds - independently of Andreas proposals, put it on the Pharo wiki and let us know the URL. You also know that Squeak goals are not exactly those of Pharo w.r.t. backward compatibility, so Squeak can't just blindly replicate Pharo solutions without a rationale. The merit of Andreas proposal is to try and establish such a rationale. Without it, we're bound to repeat discussions again and again, So to fix the problem consider that as our proposal. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com<http://www.tudorgirba.com> "Every thing has its own flow." _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 19, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by Eliot Miranda

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 >

May 19, 2010

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

by jaayer

============ 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.)

May 19, 2010

[Pharo-project] Pharo sprint this Saturday

by Alexandre Bergel

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

May 18, 2010

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

by Tudor Girba

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

May 18, 2010

Re: [Pharo-project] [Moose-dev] rome

by Igor Stasenko

On 19 May 2010 01:21, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > > On May 19, 2010, at 12:03 AM, Igor Stasenko wrote: > >> On 19 May 2010 00:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> 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 >> >> - a fourth one is direct OpenGL backend :) >> > > > OpenGL would be a nice backend indeed. > > But the text rendering would be missing, in the OpenGLCanvas part of ROME, and would have to be taken from another library? > When i wanted to add text rendering over OpenGL for Lumiere, i saw a couple of external libraries for freetype2 rendering. > Just by curiosity, did you have something in mind regarding this? > I do: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html Freetype having an API to extract the vector data from glyphs. So, the only thing what is needed is to convert & pass that data directly on GPU, and don't bother wasting time with pixels. For raster fonts, its even simpler - just use textures. > Regards, > Fernando > _______________________________________________ > 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 18, 2010

Re: [Pharo-project] [Moose-dev] rome

by Fernando olivero

On May 19, 2010, at 12:03 AM, Igor Stasenko wrote: > On 19 May 2010 00:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> 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 > > - a fourth one is direct OpenGL backend :) > OpenGL would be a nice backend indeed. But the text rendering would be missing, in the OpenGLCanvas part of ROME, and would have to be taken from another library? When i wanted to add text rendering over OpenGL for Lumiere, i saw a couple of external libraries for freetype2 rendering. Just by curiosity, did you have something in mind regarding this? Regards, Fernando

May 18, 2010

Re: [Pharo-project] [BUG] in VM perform primitive

by Igor Stasenko

- added bug entry http://bugs.squeak.org/view.php?id=7534 -- Best regards, Igor Stasenko AKA sig.

May 18, 2010

Re: [Pharo-project] [Moose-dev] rome

by Schwab,Wilhelm K

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. 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

May 18, 2010