- Pharo-dev - lists.pharo.org

Re: [Pharo-project] FFI problem

by Mariano Martinez Peck

Ok, now you can close http://code.google.com/p/pharo/issues/detail?id=908 in 10372 On Tue, Jul 7, 2009 at 6:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Jul 7, 2009, at 11:20 PM, Mariano Martinez Peck wrote: > > > Stef: Yes, it works. But, I have some questions: > > > > 1) Is it ok to have > > > > self new installer monticello http: > > 'source.squeakfoundation.org'; ??? > > > > or it is just temp ? In addition, why was #squeakfundation removed ? > > this is because now all is here: source.squeakfoundation.org??? If > > so, we can create a method for this new repository... > > It is temporary. > First I would say that FFI should have a loader doing the > initialization properly. > Second we will probably have a new loader in the near future. > > > > 2) I don't know what Smalltalk recreateSpecialObjectsArray. > > specialObjectsArray is an array known by the VM > > > But older version of FFI worked ok and also this version works ok in > > Linux...I don't understand why. > > I do not know :) > > > Is there a logic here I cannot see ? > > Is there a drawback in evaluating Smalltalk > > recreateSpecialObjectsArray. ? > > > > Cheers, > > > > Mariano > > > > On Tue, Jul 7, 2009 at 8:01 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr > > > wrote: > > Mariano > > > > I just published in Pharo a new ScriptLoader which I hope fix the > > problem. > > Could you check it? > > > > Stef > > > > On Jul 5, 2009, at 9:05 PM, Mariano Martinez Peck wrote: > > > > > Andreas: can you see new comments here: > http://code.google.com/p/pharo/issues/detail?id=908 > > > > > > What do you think? > > > > > > Thanks! > > > > > > Mariano > > > > > > On Tue, Jun 30, 2009 at 12:26 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com > > > > wrote: > > > I crated the issue so that no to forget about it: > > > > > > http://code.google.com/p/pharo/issues/detail?id=908 > > > > > > Best, > > > > > > Mariano > > > > > > > > > On Sun, Jun 28, 2009 at 3:56 AM, Andreas Raab <andreas.raab(a)gmx.de> > > > wrote: > > > Mariano Martinez Peck wrote: > > > Ok. Pharo people is in this mail. Let's wait if someone can help us. > > > > > > Please cc vm-dev on any responses. I'm not subscribed to the Pharo > > > list. > > > > > > > > > I don't know why in mi Windows machine the dump file is not > > > generated :( > > > > > > It looks like the crash has two different ways of showing. In the > > > first situation, it crashes with a recursive DNU. In the second, it > > > actually does generate a crash dump (attached). The latter seems to > > > happen when you try to step through the code. > > > > > > > > > Benoit St-Jean can you attach the complete dump file? > > > > > > I tried this in Linux and it doesn't crash my image. So, only > > > windows :( > > > > > > Difficult to say. There is a good possibility that the problem is > > > unrelated to the FFI since I have been completely unable to > > > reproduce the problem elsewhere. > > > > > > Cheers, > > > - Andreas > > > > > > > > > _______________________________________________ > > > 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 >

July 7, 2009

Re: [Pharo-project] Fwd: issue 348

by Igor Stasenko

My 2 cents: compiler should always work together with requestor: Compiler compile: some thing requestor: aRequestor. Then it could always ask, aRequestor if its interactive, or not, but i think, Compiler could live just well without such knowledge at all - each time it needs some extra data - it can simply ask the requestor to handle such particular situation, in a fashion like following: Compiler>>compileError: error ^ requestor handleError: error ifUnhandled: [ error signal ] all we need is just carefully establish protocol between Compiler and requestor object, so then making interactive/non-interactive/partly interactive will be completely independant from Compiler. 2009/7/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi Pavel > >> Hi, >> >> every UIManager may have its own preference about this behaviour >> (for example the dummy ui manager has no user input). It is cleaner >> solution than to set interactivity for every Compiler instance or >> for the Compiler class. > > In fact I have the impression that this is the same pattern than with > preference class. > We are now making sure that the Preference layer can be remove by > removing references from within the package to the Preference > class and we turn into a flow from the preference class to push value > to the tools default value. > > Similarly we prefer Â that the UIManager pushes information to the > compiler and not that the compiler rely on > UIManager. I would like to think about a Compiler been able to run > standalone without UI. > > Now we could have > > UIManager>> setUpForNonInteraction > > Â Â Â Â Â Â Â Â Compiler setInNonInteractiveMode > Â Â Â Â Â Â Â Â ,... > Â Â Â Â Â Â Â Â other class > > and Compiler code > referring to itself (its value for non interaction) > > This way we could even remove completely the UIManager. > > Else I think that UIManager will become another huge facade that we > cannot remove. > > > >> >> Cheers, >> -- Pavel >> >> >> On Tue, Jul 7, 2009 at 7:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >> > wrote: >> pavel I was wondering why you want to have interactiveParserFor: in >> UIManager and not in Compiler? >> >> May be I missed something but I'm ready to learn. >> >> Stef >> >> >> >> >> On Jul 7, 2009, at 7:18 PM, StÃ©phane Ducasse wrote: >> >> > >> > From: Pavel Krivanek <pavel.krivanek(a)gmail.com> >> > Date: July 6, 2009 2:26:56 PM CEDT >> > To: stephane ducasse <stephane.ducasse(a)free.fr> >> > Subject: issue 348 >> > >> > Hi Stef, >> > >> > I updated the issue http://code.google.com/p/pharo/issues/detail? >> > id=348 >> > >> > Cheers, >> > -- Pavel >> > >> > >> > >> > >> > _______________________________________________ >> > 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 > -- Best regards, Igor Stasenko AKA sig.

July 7, 2009

Re: [Pharo-project] Issue 941: adding class methods fails

by Johan Brichau

that's issue 941 (not 942) sorry On 08 Jul 2009, at 00:46, Johan Brichau wrote: > Hi, > > Adding (new) class methods fails in latest image. > I described the problem and proposed a fix attached to issue 942 > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

July 7, 2009

[Pharo-project] Issue 941: adding class methods fails

by Johan Brichau

Hi, Adding (new) class methods fails in latest image. I described the problem and proposed a fix attached to issue 942 ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

On the other hand, asRational and asFraction are quite synonym to me. asFraction might as well be implementation dependent... And asRational can be interpreted this way only for historical reasons (st80). I want either a short approximated fraction like (13/10), or an exact fraction. Nicolas 2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > On the other hand, VW already has asRational, and it doesn't do what > asFraction does. Â To some extent, I think #asExactFraction and selectors > like that are misleading. Â Why would anyone want #asImpreciseFraction, > or #asRationalMoreOrLess... > > Nicolas Cellier wrote: >> Hi Andres, >> That's great to see this addition, but it would have been even greater >> to call this method #asExactFraction or #asTrueFraction to get some >> minimal core API with other dialects... >> >> Anyway, you see the kind of arguments you'll have to provide if you >> ever want to follow the path you once proposed... >> >> Cheers >> >> Nicolas >> >> 2009/7/7 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: >> >>> VisualWorks introduced LimitedPrecisionReal>>asFraction. Â That message >>> returns the actual floating point value represented by the receiver. Â Of >>> course, I messed up and forgot * self sign... but that's the idea (and >>> it's fixed for 7.7). Â So, in reality, you should compare >>> >>> 13/10 = 1.3 asFraction >>> >>> which will answer false, like it should. >>> >>> Andres. >>> >>> >>> John M McIntosh wrote: >>> >>>> Let me step back and say, ok you are possibly breaking existing code, >>>> and causing all sorts of confusion for an >>>> optimization change? Â So where is the justification from the >>>> optimization viewpoint? Does it make browser >>>> windows open in 1/2 the time? >>>> >>>> If it takes more time milliseconds? to produce an answer that is what >>>> people expect, then t I think it's worth it. >>>> Yes I understand that floats are inexact but people think they know >>>> how they work thus expect to be able to say >>>> (13/10) = 1.3 Â without having to give clues with asFloat to indicate >>>> their intent. >>>> >>>> Let me see >>>> squeak 3.10.x Â (13/10) = 1.3 Â true >>>> Pharo 1037 Â (13/10) = 1.3 Â false >>>> VisualWorks (13/10) = 1.3 Â true >>>> >>>> I would classify this as a bug >>>> >>>> >>>> On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote: >>>> >>>> >>>> >>>>> I added this new issue that happens on the latest image. >>>>> I'm posting it here because I think it is an important bug because >>>>> it affects the number model. >>>>> The problem is related with all fractions who's denominator is not >>>>> power of two. (130/100 = 1.3 or 1/5 = 0.2, etc) >>>>> (See >>>>> Float>>adaptToFraction: rcvr andCompare: selector where it does >>>>> Â Â .... >>>>> Â Â "Try to avoid asTrueFraction because it can cost" >>>>> Â Â selector == #= ifTrue: [ >>>>> Â Â Â rcvr denominator isPowerOfTwo ifFalse: [^false]]. >>>>> >>>>> Â Â ...) >>>>> >>>>> >>>>> Hernan. >>>>> >>>>> >>>> -- >>>> = >>>> = >>>> = >>>> ======================================================================== >>>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Â Twitter: >>>> squeaker68882 >>>> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com >>>> = >>>> = >>>> = >>>> ======================================================================== >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

2009/7/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Jul 7, 2009, at 11:21 PM, Hernan Wilkinson wrote: > >> ok, but can you be sure that your objects are not handling floats? >> maybe the same code handles floats when you want speed and fractions >> when you want precision, I remember we did that once but I don't >> remember if we had to compare the numbers... >> I understand your point and I agree with you that erratic behavior >> should be avoided as much as possible, new programmers always get >> confused when two floats print the same but return false when >> compared, but do you agree with me that this new behavior make >> floats "less polymorphic" with numbers? and code more odd?... you >> see, people will have the same question as me, why (13/10) = 1.3 >> returns false but (1/2) = 0.5 returns true? >> Maybe the solution has to be more drastic, and if we want to avoid >> people for comparing floats for equality, just not let them or >> return false always... or take the other road as Smalltalk had after >> now, that is: make the implementation detail as hide as possible, >> and if the programmer really cares about representation problems let >> him compare the numbers with a difference... >> Smalltalk has almost 30 years old and I have not seen any big >> problem related to comparing numbers, so why changing that? what do >> we gain with the change?... I'm still not sure that this change is >> for the better :-) > > :-) > yes I understand that point too :) > So please continue to discuss that we understand the deep pros and > cons. I think this is extremely healthy > > Stef > Except the polymorphism argument, this is more a principle of inertia. "Why did you change the browser, I want it back..." IMO, Smalltalk had not so many problems because it is not used for number crunching. Financial apps use ScaledDecimal where due and avoid the problem. I used it for crunching numbers, but I feel a bit alone :) Concerning polymorphism, I hope I demonstrated this is a false polymorphism because you get non transitive equality and numbers not well ordered. Anyway: | a b | a = 13/10. b= a asFloat. self assert: (a = b) ==> (a squared = b squared). self assert: (a = b) ==> (a fractionPart = b fractionPart). etc... They behave differently, really. Concerning (0.5) ~= (1/2) that might be a good idea. What stopped me was the implications it would have on inequality tests... 0.5 < (1/2). -> false 0.5 = (1/2). -> false 0.5 > (1/2). -> false So they are unordered... I prefer 0.5 = (1/2). -> true strategy mainly for this reason. Nicolas

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

2009/7/7 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > ok, but can you be sure that your objects are not handling floats? maybe the > same code handles floats when you want speed and fractions when you want > precision, I remember we did that once but I don't remember if we had to > compare the numbers... > I understand your point and I agree with you that erratic behavior should be > avoided as much as possible, new programmers always get confused when two > floats print the same but return false when compared, but do you agree with > me that this new behavior make floats "less polymorphic" with numbers? and > code more odd?... you see, people will have the same question as me, why > (13/10) = 1.3 returns false but (1/2) = 0.5 returns true? > Maybe the solution has to be more drastic, and if we want to avoid people > for comparing floats for equality, just not let them or return false > always... or take the other road as Smalltalk had after now, that is: make > the implementation detail as hide as possible, and if the programmer really > cares about representation problems let him compare the numbers with a > difference... > Smalltalk has almost 30 years old and I have not seen any big problem > related to comparing numbers, so why changing that? what do we gain with the > change?... I'm still not sure that this change is for the better :-) > > Well, we are going to lack of arguments and just repeat ourselves :) It is for the better because it makes comparison a full order relation ship and equality transitive. | a b c | a := 13/10. b := a asFloat. c := b asTrueFraction. a < c self asssert: (a = b) & (b = c) ==> (a == c). self asssert: (a < c) & (b = c) ==> (a < b). It is also better because your learn sooner to not be surpised by 1.3*1.3 ~= 1.69. You should know that lispers (lots of grey bearded) were better behaved than us, long before us. See http://www.lispworks.com/documentation/lcl50/aug/aug-170.html That's not a definitive argument, but a good clue. Concerning (1/2) ~= 0.5, Andres suggested that once, why not. This is explicitely possible to implement Scheme with this rule. I gave you some examples that are not hypothetical: I've been caught 15 years ago with this kind of bad behaviour. I now would like to see real examples rather than just expectations based on bad habits. Nicolas

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Andres Valloud

On the other hand, VW already has asRational, and it doesn't do what asFraction does. To some extent, I think #asExactFraction and selectors like that are misleading. Why would anyone want #asImpreciseFraction, or #asRationalMoreOrLess... Nicolas Cellier wrote: > Hi Andres, > That's great to see this addition, but it would have been even greater > to call this method #asExactFraction or #asTrueFraction to get some > minimal core API with other dialects... > > Anyway, you see the kind of arguments you'll have to provide if you > ever want to follow the path you once proposed... > > Cheers > > Nicolas > > 2009/7/7 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > >> VisualWorks introduced LimitedPrecisionReal>>asFraction. That message >> returns the actual floating point value represented by the receiver. Of >> course, I messed up and forgot * self sign... but that's the idea (and >> it's fixed for 7.7). So, in reality, you should compare >> >> 13/10 = 1.3 asFraction >> >> which will answer false, like it should. >> >> Andres. >> >> >> John M McIntosh wrote: >> >>> Let me step back and say, ok you are possibly breaking existing code, >>> and causing all sorts of confusion for an >>> optimization change? So where is the justification from the >>> optimization viewpoint? Does it make browser >>> windows open in 1/2 the time? >>> >>> If it takes more time milliseconds? to produce an answer that is what >>> people expect, then t I think it's worth it. >>> Yes I understand that floats are inexact but people think they know >>> how they work thus expect to be able to say >>> (13/10) = 1.3 without having to give clues with asFloat to indicate >>> their intent. >>> >>> Let me see >>> squeak 3.10.x (13/10) = 1.3 true >>> Pharo 1037 (13/10) = 1.3 false >>> VisualWorks (13/10) = 1.3 true >>> >>> I would classify this as a bug >>> >>> >>> On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote: >>> >>> >>> >>>> I added this new issue that happens on the latest image. >>>> I'm posting it here because I think it is an important bug because >>>> it affects the number model. >>>> The problem is related with all fractions who's denominator is not >>>> power of two. (130/100 = 1.3 or 1/5 = 0.2, etc) >>>> (See >>>> Float>>adaptToFraction: rcvr andCompare: selector where it does >>>> .... >>>> "Try to avoid asTrueFraction because it can cost" >>>> selector == #= ifTrue: [ >>>> rcvr denominator isPowerOfTwo ifFalse: [^false]]. >>>> >>>> ...) >>>> >>>> >>>> Hernan. >>>> >>>> >>> -- >>> = >>> = >>> = >>> ======================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >>> squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> = >>> = >>> = >>> ======================================================================== >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > . > >

July 7, 2009

Re: [Pharo-project] SUnit assert:equals:

by Michael Roberts

No you understand certainly, I wasn't clear. If we provide a nice api for comparing things are equal it would be a shame to not provide the convenience for doubles. Newcomers to the environment would not necessarily understand the pitfalls of testing equality on doubles. Thus providing convenience in one area could look very attractive in the general case if there are no other methods hinting their appropriate use. I'm sure such a method has already been written in a repository somewhere . I just thought it would be good to put them in together. That make sense? Mike On Tuesday, July 7, 2009, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: > > Hi Mike, > > I don't understand. Â assert:equals: should only be used for exact > equality tests, not for comparing doubles. > > Doubles should never go through this method. > > Existing tests won't know about assert:equals: > > Did I misunderstand you? > > - on > > On 7 Jul 2009, at 19:24, Michael Roberts wrote: > >> If you are adding this it would be good to either add or review >> existing implementation that checks the comparison is within a >> tolerance. This would be for asserting double values are close but not >> necessarily exact. I would rather we didn't get double comparison >> going through this method you describe which would be easy to do. >> >> Thanks >> mike > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Andres Valloud

The answer is true on 7.6, and I don't think anything changed that for 7.7. Historical background aside, I think it's wrong anyway... in the hash book, exercise 7.20 asks to find two different fractions that are equal to the same float. In other words, if f is a float, and r1 and r2 are fractions, then r1 ~= r2 but r1 = f and r2 = f. And those do exist... Andres. StÃ©phane Ducasse wrote: > so andres what will be the value of > >>> (13/10) = 1.3 >>> > in VW7.7 > > On Jul 7, 2009, at 11:18 PM, Andres Valloud wrote: > > >> VisualWorks introduced LimitedPrecisionReal>>asFraction. That message >> returns the actual floating point value represented by the >> receiver. Of >> course, I messed up and forgot * self sign... but that's the idea (and >> it's fixed for 7.7). So, in reality, you should compare >> >> 13/10 = 1.3 asFraction >> >> which will answer false, like it should. >> >> Andres. >> >> >> John M McIntosh wrote: >> >>> Let me step back and say, ok you are possibly breaking existing code, >>> and causing all sorts of confusion for an >>> optimization change? So where is the justification from the >>> optimization viewpoint? Does it make browser >>> windows open in 1/2 the time? >>> >>> If it takes more time milliseconds? to produce an answer that is what >>> people expect, then t I think it's worth it. >>> Yes I understand that floats are inexact but people think they know >>> how they work thus expect to be able to say >>> (13/10) = 1.3 without having to give clues with asFloat to indicate >>> their intent. >>> >>> Let me see >>> squeak 3.10.x (13/10) = 1.3 true >>> Pharo 1037 (13/10) = 1.3 false >>> VisualWorks (13/10) = 1.3 true >>> >>> I would classify this as a bug >>> >>> >>> On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote: >>> >>> >>> >>>> I added this new issue that happens on the latest image. >>>> I'm posting it here because I think it is an important bug because >>>> it affects the number model. >>>> The problem is related with all fractions who's denominator is not >>>> power of two. (130/100 = 1.3 or 1/5 = 0.2, etc) >>>> (See >>>> Float>>adaptToFraction: rcvr andCompare: selector where it does >>>> .... >>>> "Try to avoid asTrueFraction because it can cost" >>>> selector == #= ifTrue: [ >>>> rcvr denominator isPowerOfTwo ifFalse: [^false]]. >>>> >>>> ...) >>>> >>>> >>>> Hernan. >>>> >>>> >>> -- >>> = >>> = >>> = >>> = >>> = >>> = >>> ===================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >>> squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> = >>> = >>> = >>> = >>> = >>> = >>> ===================================================================== >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > . > >

July 7, 2009