- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About the Pharo Issue tracker

by Adrian Lienhard

Hi Guille and Carla, Yes for certain actions you need to be a committer. I added you both. Please feel free to help maintaining the issue tracker :) If an issue is not clear and lacking information, please add a note and/or ask in the mailing list. If an issue cannot be reproduced and the creator does not provide details, we just switch to "won't fix". Another area that needs work is to identify which issues should still be tackled for 1.1. In the tracker we currently have over 200 issues for milestone 1.1. Many are of the form "we should do X" and are not critical for the 1.1 release. Others may be show stopper bugs that need to be fixed. Identifying the latter is important. Cheers, Adrian On May 24, 2010, at 07:10 , Carla F. Griggio wrote: > Hmm... if I wanted to change the status of an issue to Fixed (for example), > I think I'm not able to do that either. Are you? > > Should we be commiters to be able to do these things? > > On Mon, May 24, 2010 at 2:04 AM, Carla F. Griggio > <carla.griggio(a)gmail.com>wrote: > >> Welcome, Guille :) It was very cool to have you in the Sprint :) >> >> I notice that if I try to post a new issue, I can't categorize it. Who is >> able to categorize issues? >> >> Carla. >> >> 2010/5/23 Guillermo Polito <guillermopolito(a)gmail.com> >> >>> Hi! >>> >>> First I may introduce myself. My name is Guillermo Polito and I'm from >>> Argentina. I've been using Pharo for several months with some colleagues >>> that are already here to teach OOP in the UTN university, and i've been >>> suscribed to this mailing list for some time. But it's my first mail here >>> :P. >>> >>> I participated yesterday in the Pharo Sprint in Argentina and there I had >>> my first look at the issue tracker. And well, it seemed to me to be a >>> little messy. There are lots of issues that aren't properly explained, some >>> of them are duplicated, and they are not well organized. >>> It would be nice to use the labels googlecode provides to give them some >>> categorization, so we can browse them in a more intelligent way. Maybe we >>> can split the issues in "modules" (like Collection issues, Compiler Issues, >>> Closures Issues, Networking Issues...) or something like that. That will >>> help in avoiding duplications and looking for issues to solve (because I can >>> look for issues in the modules I know the most). >>> >>> At the moment I will stay looking for issues i can fix or commenting the >>> ones that lacks information :). >>> >>> Regards, >>> Guille >>> >>> >>> >>> _______________________________________________ >>> 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 24, 2010

[Pharo-project] CompiledMethodTrailer with a different CompiledMethod class

by HernÃ¡n Morales Durand

Hello Just to make a little note. I'm adapting the lightweight classes package to work with CompilerMethodTrailer. In this method CompiledMethodTrailer>>createMethod: numberOfBytesForAllButTrailer header: headerWord | meth | encodedData ifNil: [ self encode ]. meth := CompiledMethod newMethod: numberOfBytesForAllButTrailer + size header: headerWord. ... I need to answer a different kind of CompiledMethod, it would be nice if my own CompiledMethod class could be specified in some way to make the CompiledMethodTrailer more flexible. Cheers, HernÃ¡n

May 24, 2010

Re: [Pharo-project] Bug? ParagraphEditor do-its are not following the expected method lookup

by Carla F. Griggio

Well, just to let you know, I've submitted a fix to PharoInbox: Name: SLICE-superBugInParagraphEditor-carlaGriggio.1 Author: carlaGriggio Time: 24 May 2010, 2:33:50 am UUID: 94ff9a49-b4ba-488b-9470-777e0f1885a7 Ancestors: SLICE-superBugInParagraphEditor-carlaGriggio.1 Dependencies: Compiler-carlaGriggio.212, CompilerTests-carlaGriggio.42, Kernel-carlaGriggio.665, ParagraphEditor-Test-carlaGriggio.1 But I can't change the status of the issue to fixed :P On Wed, May 19, 2010 at 4:51 PM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > Not the cs, I have an st. It's in the first email of this thread. I also > attached a cs with a possible fix. > > > > On Wed, May 19, 2010 at 4:35 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Yes this is an important bug >> do you have the cs of your little example? >> >> Stef >> >> On May 19, 2010, at 9:17 PM, Carla F. Griggio wrote: >> >> > Just reproducing it would be helpful :O a friend of mine already >> > tested the code I attatched and saw the same problem. >> > >> > If you recall having a class with a method sending a message to super, >> > and a sublclass inheriting that method, you can try to reproduce it >> > there too debugging that message on an instance of the subclass. >> > >> > It's not easy to explain with words, that's why I made a little >> > package of code to illustrate the situation. >> > >> > The thing is that when printing the evaluation of a selected bunch of >> > code inside a debugger window (paragraphEditor?), if the code you're >> > evaluating is a message to super, and the class of the object you're >> > debugging is inheriting the method you're debugging, the printed >> > result will be wrong. In other words, the method lookup fails. >> > >> > This doesn't happen with normal excution of code (thank God!). >> > >> > I think this is an important bug, seeing those wrong results when >> > debugging can be very confusing. I spent hours feeling stupid last >> > Monday while debugging because I trusted those wrong results and >> > couldn't see where I was doing something wrong :P >> > >> > Cheers! >> > Carla >> > >> > On Wednesday, May 19, 2010, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >> Hi Carla. I would like to help you, but I have no idea. I could >> reproduce it. >> >> >> >> Maybe Lukas, Igor, Eliot etc can help you. I have no idea. >> >> >> >> Cheers >> >> >> >> Mariano >> >> >> >> 2010/5/18 Carla F. Griggio <carla.griggio(a)gmail.com> >> >> Hi everybody! >> >> Well, maybe you are already aware of this... maybe not. I tried to find >> an issue about this and unless I didn't think of the right keywords, it's >> not there. >> >> >> >> >> >> >> >> I was debugging a template method and sudenly I found myself spending >> ours trying to find out why I got different results when printing the result >> of a message sent to super and when steping into that message and printing >> the (same) result there. >> >> >> >> >> >> >> >> Imagine this simple situation (I attatch the complete code and some >> tests so you can reproduce this): >> >> AverageTotalization inherits from >> Totalization.WeightedAverageTotalization inherits from AverageTotalization. >> >> >> >> >> >> >> >> Totalization>>total >> >> >> >> ^self summatory >> >> >> >> >> >> >> >> >> >> >> >> AverageTotalization>>total >> >> >> >> ^(super total) / self denominator >> >> >> >> >> >> >> >> >> >> >> >> AverageTotalization>> denominator >> >> >> >> ^values size >> >> >> >> >> >> >> >> >> >> WeightedAverageTotalization>> denominator >> >> >> >> "Weights is a dictionary" >> >> >> >> ^self weights values sum >> >> >> >> >> >> >> >> >> >> If I debug aWeightedAverateTotalization total and try to print super >> total in the debugger ParagraphEditor, I'll get this result: >> >> >> >> >> >> >> >> (self summatory / self denominator) >> >> >> >> >> >> instead of just: >> >> self summatory >> >> This only happens when I print or inspect or other do-its in the >> debugger window. The method lookup works OK when just >> _______________________________________________ >> >> 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 24, 2010

Re: [Pharo-project] About the Pharo Issue tracker

by Carla F. Griggio

Hmm... if I wanted to change the status of an issue to Fixed (for example), I think I'm not able to do that either. Are you? Should we be commiters to be able to do these things? On Mon, May 24, 2010 at 2:04 AM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > Welcome, Guille :) It was very cool to have you in the Sprint :) > > I notice that if I try to post a new issue, I can't categorize it. Who is > able to categorize issues? > > Carla. > > 2010/5/23 Guillermo Polito <guillermopolito(a)gmail.com> > >> Hi! >> >> First I may introduce myself. My name is Guillermo Polito and I'm from >> Argentina. I've been using Pharo for several months with some colleagues >> that are already here to teach OOP in the UTN university, and i've been >> suscribed to this mailing list for some time. But it's my first mail here >> :P. >> >> I participated yesterday in the Pharo Sprint in Argentina and there I had >> my first look at the issue tracker. And well, it seemed to me to be a >> little messy. There are lots of issues that aren't properly explained, some >> of them are duplicated, and they are not well organized. >> It would be nice to use the labels googlecode provides to give them some >> categorization, so we can browse them in a more intelligent way. Maybe we >> can split the issues in "modules" (like Collection issues, Compiler Issues, >> Closures Issues, Networking Issues...) or something like that. That will >> help in avoiding duplications and looking for issues to solve (because I can >> look for issues in the modules I know the most). >> >> At the moment I will stay looking for issues i can fix or commenting the >> ones that lacks information :). >> >> Regards, >> Guille >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

May 24, 2010

Re: [Pharo-project] About the Pharo Issue tracker

by Carla F. Griggio

Welcome, Guille :) It was very cool to have you in the Sprint :) I notice that if I try to post a new issue, I can't categorize it. Who is able to categorize issues? Carla. 2010/5/23 Guillermo Polito <guillermopolito(a)gmail.com> > Hi! > > First I may introduce myself. My name is Guillermo Polito and I'm from > Argentina. I've been using Pharo for several months with some colleagues > that are already here to teach OOP in the UTN university, and i've been > suscribed to this mailing list for some time. But it's my first mail here > :P. > > I participated yesterday in the Pharo Sprint in Argentina and there I had > my first look at the issue tracker. And well, it seemed to me to be a > little messy. There are lots of issues that aren't properly explained, some > of them are duplicated, and they are not well organized. > It would be nice to use the labels googlecode provides to give them some > categorization, so we can browse them in a more intelligent way. Maybe we > can split the issues in "modules" (like Collection issues, Compiler Issues, > Closures Issues, Networking Issues...) or something like that. That will > help in avoiding duplications and looking for issues to solve (because I can > look for issues in the modules I know the most). > > At the moment I will stay looking for issues i can fix or commenting the > ones that lacks information :). > > Regards, > Guille > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 24, 2010

Re: [Pharo-project] Metacello and SourceTalk ...

by Julian Fitzell

The fact that MC2 is still a moving target. Or at least it would be if it was moving. :) More to the point, the early releases had some problems that prompted further redesign and I'd recommend against creating large amounts of date in those versions that will need to be brought forward. In other words, I don't think it's ready for prime time in its current state. Julian On Mon, May 17, 2010 at 1:34 PM, Geert Claes <geert.wl.claes(a)gmail.com>wrote: > > What would be the biggest challenges moving to MC2 and a MC2 Repository > like > SourceTalk? > > > Mariano Martinez Peck wrote: > > > > Hi Geert. I agree it would awesome to have Monticello 2 and SourcTalk for > > Pharo 1.2. I have not idea the status. I tested once (you can see > > squeakdbx there) but I have a lot of problems. And the project seems > > "dead". I mean, I don't think someone is working on it. That said, it > > would be great someone to work on it and maybe start to using it by Pharo > > 1.2 > > > -- > View this message in context: > http://forum.world.st/Metacello-and-SourceTalk-tp2219294p2219517.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 24, 2010

Re: [Pharo-project] ClassTestCase

by Levente Uzonyi

On Sun, 23 May 2010, Mariano Abel Coca wrote: > There are few now, but it was done yesterday in a few hours. We will keep > adding new tests to that suites, so suggestions are welcome :). > > Actually there are only 3 tests there: > > - One that checks that all the methods in the image are categorized > - One that checks that never redefine #doesNotUnderstand: without redefining > #respondsTo: and vice versa. > - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= > nil, etc. as suggested in issue 1594 (Actually, after reading this issue is > that we started with this idea). "x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and "== nil" is not less readable if you know what #== means (but that's basic smalltalk knowledge, so it's fair to assume that everybody knows it). Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible). So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible. (*) Benchmarks on my slow machine: ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 == nil ] ] timeToRun ]) average asFloat. "===> 386.6" ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 isNil ] ] timeToRun ]) average asFloat. "===> 586.4" ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | ] ] timeToRun ]) average asFloat. "===> 282.3" 586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908" ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 393.6" ((1 to: 10) collect: [ :run | [ 1 to: 10000000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 585.2" 585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584" Levente > > Cheers, > > Mariano. > > > On Sun, May 23, 2010 at 4:53 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >> wrote: > >> Sounds exciting can you tell us a bit more? >> >> On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote: >> >>> If anyone want, can take a look at: >>> >>> http://www.squeaksource.com/CodeQualityTests >>> http://www.squeaksource.com/CodeStandardsTests >>> >>> And run the tests before committing the next version of their packages. >>> >>> We will try to help to pass the tests as soon as possible. >>> >>> Cheers, >>> >>> Mariano. >>> >>> >>> On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza < >> patchinko(a)gmail.com> wrote: >>> We're working on it, making small changes and creating code standards >>> tests and code quality tests. >>> >>> It would be great to have a way of tracking the results of these tests >>> in a distant future and make them mandatory before integrate new >>> things into the image. >>> >>> Francisco >>> >>> On Sat, May 22, 2010 at 7:17 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> What I was thinking mariano is that we could move one class at a time >> in classTests and make the tests green. >>>> This way we do not have red tests and still make progress >>>> Stef >>>> >>>> >>>> On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: >>>> >>>>> It is a must. We have to got all the tests in green. But actually that >> isn't tested. >>>>> >>>>> I'll make the tests, I'll fix them, and then I'll send the whole >> changes to merge in the baseline. >>>>> >>>>> Cheers, >>>>> >>>>> Mariano. >>>>> >>>>> >>>>> On Sat, May 22, 2010 at 2:58 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >>>>> the key point is that we would like to avoid to have red tests all the >> time >>>>> so fixing the as yet unclassified should be done before. >>>>> >>>>> >>>>> BTW Does anybody use >>>>> BadEqualer >>>>> HashTester >>>>> PrototypeTester >>>>> >>>>> because so far I do not see anybody user of them. >>>>> They look like experiment code to me. >>>>> >>>>> Stef >>>>> >>>>> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: >>>>> >>>>>> Hi, I want to make global the checks included in ClassTestCase, and >> remove it. That is because actually it's only being tested for it's >> subclasses. And also, it's declaring that a subclass will be a class test >> instead of just a test, but no one of it's subclasses actually test the >> class, but the instances, therefore is a TestCase, not a ClassTestCase. See >> TimespanTest as an example. >>>>>> >>>>>> What Im saying is that I'm trying to force a run of a suit of Code >> Standards and Code Quality tests before sending something to merge to a >> baseline of a project. >>>>>> >>>>>> What do you think? Are you agree with that? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Mariano. >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

May 23, 2010

Re: [Pharo-project] [squeak-dev] runSimulated behaviour

by Eliot Miranda

Hi Michael, Michael, Dennis, Hi All, I think this is a simple bug in ContextPart >> #tryNamedPrimitiveIn:for:withArgs:, which neglects to flush the method cache for the method and/or selector used to simulate execution of a named primitive. With the relevant flushCacher calls added I no longer see any of the simulation failures recently experienced (someMethod getSourceFromFile, TimeStamp now). Please test the attached and let me know how you get on. The problem is caused by using the same method to invoke differet primitives in quick succession where, because the method cache is not flushed, the wrong primitive (a previous primitive) is left in the cache and invoked instead of the desired primitive. In Cog I added a primitive to directly evaluate a named primitive so the problem does not occur. Adding the two lines marked >> below fixes the problem. The line "theMethod flushCache" is probably more than we need, but does not harm. HTH Eliot !ContextPart methodsFor: 'private' stamp: 'eem 5/23/2010 14:13'! tryNamedPrimitiveIn: aCompiledMethod for: aReceiver withArgs: arguments "Hack. Attempt to execute the named primitive from the given compiled method" | selector theMethod spec | arguments size > 8 ifTrue:[^PrimitiveFailToken]. selector := #( tryNamedPrimitive tryNamedPrimitive: tryNamedPrimitive:with: tryNamedPrimitive:with:with: tryNamedPrimitive:with:with:with: tryNamedPrimitive:with:with:with:with: tryNamedPrimitive:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with:with:) at: arguments size+1. theMethod := aReceiver class lookupSelector: selector. theMethod == nil ifTrue:[^PrimitiveFailToken]. spec := theMethod literalAt: 1. spec replaceFrom: 1 to: spec size with: (aCompiledMethod literalAt: 1) startingAt: 1. >> theMethod flushCache. >> selector flushCache. ^aReceiver perform: selector withArguments: arguments! ! On Thu, May 20, 2010 at 2:55 AM, Michael Haupt <mhaupt(a)gmail.com> wrote: > Dear all, > > we're observing some strange behaviour in simulated bytecode execution > in Squeak (4.1, on Macs). > > Printing this: > ContextPart runSimulated: [ TimeStamp now ] > will work once and then reproducibly fail with code simulation errors. > > This works well (also reproducibly): > ContextPart trace: [ TimeStamp now ] > > Going to more detail, we figured out that simulation reproducibly > works if things are written to the Transcript every now and then. > Printing this: > n:=0. thisContext runSimulated: [ TimeStamp now ] contextAtEachStep: [ > :c | n\\100=0 ifTrue: [ Transcript show: $. ] ] > works. > > We've tried to just insert some artificial delays (<someValue> > milliSeconds asDelay wait) in the block, but that will not > reproducibly work; it also leads to code simulation errors. So it > can't be just the time it takes to write to Transcript. Or so we > believe. > > Does anybody know the reason for this strange behaviour, or where in > the simulation logic to look? > > Best, > > Michael > >

May 23, 2010

Re: [Pharo-project] Rendering fonts on OpenGL

by Igor Stasenko

2010/5/23 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: > Hi, may I ask how you are rendering these fonts? You parse the glyphs and > then render lines with opengl or use freetype to render to a texture without > antialiasing or both? Squeak has already a TT font reader, so i just taking the data from there and piping to GPU. What you see here is freely scalable vector/curve rendering done completely on GPU. > If you asked me, I'd say I like the method but for > fonts they look a bit blury, I'd say too much for the smaller ones. I think this is best what you can achieve without hinting / subpixel AA. > Also, what are you working on? > I once did a GLCanvas, and now i want to reiterate and improve it using new callout mechanism (NativeBoost), and full coverage of OpenGL API, with all extensions available at your disposal. > Regards, > Â Â Â Â Â Â Â Â Â Â Â Javier. > > 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> -- Best regards, Igor Stasenko AKA sig.

May 23, 2010

Re: [Pharo-project] Rendering fonts on OpenGL

by Javier PimÃ¡s

Hi, may I ask how you are rendering these fonts? You parse the glyphs and then render lines with opengl or use freetype to render to a texture without antialiasing or both? If you asked me, I'd say I like the method but for fonts they look a bit blury, I'd say too much for the smaller ones. Also, what are you working on? Regards, Javier. 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> > Hello, > > This is a Tahoma font, rendered with OpenGL > > look how much difference between no-AA > and with enabled multisampling. > > I think that with multisampling, the quality is quite good to not > bother about sub-pixel AA. > Sub-pixel AA could be added later, if there's any brave soul who can > implement a fragment shader for it :) > > Moreover, with multisampling, all fragments on screen (lines, points, > polygons) will also be automatically antialiased. > This means no rigid edges for everything, not just for fonts :) > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Javier PimÃ¡s Ciudad de Buenos Aires

May 23, 2010