Re: [Pharo-project] A pause... for tests and orthogonal concerns
Also pushing a bit the integration of the regression process with hudson or others. I will have a look at the SUnit changes now for real (once the smalltalk-> SmalltalkImage is finished) Stef On Mar 15, 2010, at 12:05 AM, Stéphane Ducasse wrote: > hi guys > > I was discussing with pavel and I like his point. I would like to do a kind > of pause and fix the tests. Improve a bit the fact that we get more tests > incrementally to avoid regression. > Tell what you think and think how you could help. > > Stef > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Rewrote "Smalltalk" to "Smalltalk globals"
Apparently I integrated a change that breaks scriptLoader so now I'm going to give 7h lectures and I will check that this evening in the train. Stef On Mar 15, 2010, at 12:21 AM, Igor Stasenko wrote: > I love you guys! :) > > On 14 March 2010 22:46, Stéphane Ducasse wrote: >> Thanks. I'm merging. I like my dreams when they come true. >> >> Stef >> >> On Mar 14, 2010, at 9:40 PM, Lukas Renggli wrote: >> >>> I published a slice that rewrites "Smalltalk" to "Smalltalk globals" >>> for various messages >>> (http://code.google.com/p/pharo/issues/detail?id=2143). To adapt the >>> code in other packages just run the rewrite rules below: >>> >>> Name: SLICE-RewriteSmalltalkToSmalltalkGlobals-lr.1 >>> Author: lr >>> Time: 14 March 2010, 9:18:06 pm >>> UUID: 1742e7f2-7233-4be3-bc3d-c9332ed07ef7 >>> Ancestors: >>> Dependencies: Collections-Support-lr.31, Collections-Text-lr.30, >>> Compiler-lr.196, CompilerTests-lr.32, Compression-lr.50, >>> DeprecatedPreferences-lr.17, Files-lr.ducasse.139, FreeType-lr.524, >>> Gofer-Core-lr.118, Gofer-Tests-lr.117, Graphics-lr.214, >>> GraphicsTests-lr.32, Kernel-lr.617, KernelTests-lr.216, >>> Monticello-lr.439, MonticelloGUI-lr.51, Morphic-lr.547, >>> Multilingual-lr.155, Network-Protocols-lr.42, Network-URI-lr.17, >>> Network-Url-lr.28, PackageInfo-lr.51, Polymorph-Tools-Diff-lr.26, >>> Polymorph-Widgets-lr.214, ST80-lr.126, SUnit-lr.91, SUnitGUI-lr.57, >>> ScriptLoader11-lr.297, Settings-Polymorph-lr.3, System-lr.11, >>> System-Changes-lr.52, System-Download-lr.45, System-FilePackage-lr.36, >>> System-Localization-lr.43, System-Object Storage-lr.87, >>> System-Settings-lr.181, System-Support-lr.259, Tests-lr.131, >>> ToolBuilder-Morphic-lr.65, Tools-lr.362, Traits-lr.359 >>> >>> RBParseTreeRewriter new >>> replace: 'Smalltalk associationAt: `...@arg1' with: 'Smalltalk globals >>> associationAt: `...@arg1'; >>> replace: 'Smalltalk associationAt: `...@arg1 ifAbsent: `...@arg2' >>> with: >>> 'Smalltalk globals associationAt: >>> `...@arg1 ifAbsent: `...@arg2'; >>> replace: 'Smalltalk associationDeclareAt: `...@arg1' with: 'Smalltalk >>> globals associationDeclareAt: >>> `...@arg1'; >>> replace: 'Smalltalk associationOrUndeclaredAt: `...@arg1' with: >>> 'Smalltalk globals >>> associationOrUndeclaredAt: `...@arg1'; >>> replace: 'Smalltalk classNamed: `...@arg1' with: 'Smalltalk globals >>> classNamed: `...@arg1'; >>> replace: 'Smalltalk at: `...@arg1' with: 'Smalltalk globals at: >>> `...@arg1'; >>> replace: 'Smalltalk at: `...@arg1 ifPresent: `...@arg2' with: >>> 'Smalltalk >>> globals at: `...@arg1 ifPresent: >>> `...@arg2'; >>> replace: 'Smalltalk at: `...@arg1 ifAbsent: `...@arg2' with: >>> 'Smalltalk >>> globals at: `...@arg1 ifAbsent: >>> `...@arg2'; >>> replace: 'Smalltalk includesKey: `...@arg1' with: 'Smalltalk globals >>> includesKey: `...@arg1'; >>> replace: 'Smalltalk keyAtIdentityValue: `...@arg1' with: 'Smalltalk >>> globals keyAtIdentityValue: `...@arg1'; >>> replace: 'Smalltalk flushClassNameCache' with: 'Smalltalk globals >>> flushClassNameCache'; >>> yourself >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Set with nil is fixed and waiting for a nice reviewer
ok thanks for the information. On Mar 15, 2010, at 7:08 AM, Levente Uzonyi wrote: > On Mon, 15 Mar 2010, Stéphane Ducasse wrote: > >> so may be the bug entry should have stated that because oscar and nico spend >> a day on it. > > The good news is that the tests are ready which is probably the larger part. > The bad news is that integrating the tally hack is easier, than the > SetElement version (which is also Igor's code, but that may not be clear from > my previous mail). > > > Levente > >> >> Stef >> >> On Mar 15, 2010, at 12:56 AM, Henrik Sperre Johansen wrote: >> >>> On 15.03.2010 00:18, Igor Stasenko wrote: 2010/3/14 Levente Uzonyi: > On Sun, 14 Mar 2010, Stéphane Ducasse wrote: > >> during the sprint niko schwarz and oscar nierstrasz fixed the Set in nil >> entry. >> Thanks. >> http://code.google.com/p/pharo/issues/detail?id=1907 > Why did you choose Igor's negative tally hack instead of the SetElement > version? > I'd prefer to use SetElement, unless there was a decision made, to use negative tally. We had a quite big discussion around it on squeak-dev, and most developers said that SetElement is the way to go, because it is clean, OO-oriented, even if somewhat slower comparing to other approaches. >>> +1 >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Set with nil is fixed and waiting for a nice reviewer
On Mon, 15 Mar 2010, Stéphane Ducasse wrote: so may be the bug entry should have stated that because oscar and nico spend a day on it. The good news is that the tests are ready which is probably the larger part. The bad news is that integrating the tally hack is easier, than the SetElement version (which is also Igor's code, but that may not be clear from my previous mail). Levente Stef On Mar 15, 2010, at 12:56 AM, Henrik Sperre Johansen wrote: On 15.03.2010 00:18, Igor Stasenko wrote: 2010/3/14 Levente Uzonyi: On Sun, 14 Mar 2010, Stéphane Ducasse wrote: during the sprint niko schwarz and oscar nierstrasz fixed the Set in nil entry. Thanks. http://code.google.com/p/pharo/issues/detail?id=1907 Why did you choose Igor's negative tally hack instead of the SetElement version? I'd prefer to use SetElement, unless there was a decision made, to use negative tally. We had a quite big discussion around it on squeak-dev, and most developers said that SetElement is the way to go, because it is clean, OO-oriented, even if somewhat slower comparing to other approaches. +1 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Set with nil is fixed and waiting for a nice reviewer
so may be the bug entry should have stated that because oscar and nico spend a day on it. Stef On Mar 15, 2010, at 12:56 AM, Henrik Sperre Johansen wrote: > On 15.03.2010 00:18, Igor Stasenko wrote: >> 2010/3/14 Levente Uzonyi: >>> On Sun, 14 Mar 2010, Stéphane Ducasse wrote: >>> during the sprint niko schwarz and oscar nierstrasz fixed the Set in nil entry. Thanks. http://code.google.com/p/pharo/issues/detail?id=1907 >>> Why did you choose Igor's negative tally hack instead of the SetElement >>> version? >>> >> I'd prefer to use SetElement, unless there was a decision made, to use >> negative tally. >> We had a quite big discussion around it on squeak-dev, and most >> developers said that SetElement >> is the way to go, because it is clean, OO-oriented, even if somewhat >> slower comparing to other approaches. >> > +1 > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about video games
the second is scary :) On Mar 15, 2010, at 2:19 AM, Igor Stasenko wrote: > On 15 March 2010 02:59, Michael J. Forster wrote: >> On 2010-03-14, at 16:09, Stéphane Ducasse wrote: >> >>> A friend of mine sent this interesting links >>> >>> >>> http://www.wired.com/gaming/gamingreviews/commentary/games/2008/09/gamesfrontiers_0908 >>> http://www.businessweek.com/innovate/content/jan2009/id20090114_362962.htm >>> >>> Worth to read. >>> >>> Stef >> >> >> The students might have employed the scientific method, but the article >> itself is not a good example of even populist science writing. >> >> The author states that enrollment in the sciences has fallen because of >> boring presentation of facts and that video games offer a rejuvenated quest >> for facts. How do we know that enrollment has declined for that claimed >> reason? How do we know that it's not the subject matter of video games that >> interests the students, and that students won't shoe the same disinterest >> when we apply video games to, say, biology or particle physics? >> >> I would never discard a new viable approach to teaching and learning, but >> this sounds a lot like the ethanol solution to climate change. >> > > Hmm, i didn't read a second link, but from a first one i think it says that > it doesn't makes students to be more interested in theory or > fundamental science. > What it does, is teaching them the way of thinking, exactly how > scientific method works. > So, then, once they realising that, it is much easier for them to > learn more diffucult things > and apply the same approach to a different areas. > > >> Mike ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Best regards, > Igor Stasenko AKA sig. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about video games
On 2010-03-14, at 20:19, Igor Stasenko wrote: On 15 March 2010 02:59, Michael J. Forster wrote: On 2010-03-14, at 16:09, Stéphane Ducasse fr> wrote: A friend of mine sent this interesting links http://www.wired.com/gaming/gamingreviews/commentary/games/2008/09/gamesfrontiers_0908 http://www.businessweek.com/innovate/content/jan2009/id20090114_362962.htm Worth to read. Stef The students might have employed the scientific method, but the article itself is not a good example of even populist science writing. The author states that enrollment in the sciences has fallen because of boring presentation of facts and that video games offer a rejuvenated quest for facts. How do we know that enrollment has declined for that claimed reason? How do we know that it's not the subject matter of video games that interests the students, and that students won't shoe the same disinterest when we apply video games to, say, biology or particle physics? I would never discard a new viable approach to teaching and learning, but this sounds a lot like the ethanol solution to climate change. Hmm, i didn't read a second link, but from a first one i think it says that it doesn't makes students to be more interested in theory or fundamental science. What it does, is teaching them the way of thinking, exactly how scientific method works. So, then, once they realising that, it is much easier for them to learn more diffucult things and apply the same approach to a different areas. Well, as I said, the articles themselves are hardly scientific in their assertions and analysis. My point is that, as I have observed in students I have studied with and those I have taught, understanding the scientific method is not the hurdle. Finding the motivation and patience to carry out the slow painstaking work of applying that scientific method -- doing the work of science -- is what turns people away. Science is very hard work, and, materialistically, the pay sucks. So, if I were to reason as recklessly as the authors, I would argue that as much of the problem lies with a generation of instant- gratification seeking people as it does with boring old science classes. Further, I might rant that it was video games that created that problem. Heck, the best that we can hope for is that these kids will end up applying the scientific method to online poker. Of course, that wouldn't be very scientific of me ;-) Anyway, yes, it was worth a read. Thanks for that, Stephane. Mike ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about video games
On 15 March 2010 02:59, Michael J. Forster wrote: > On 2010-03-14, at 16:09, Stéphane Ducasse wrote: > >> A friend of mine sent this interesting links >> >> >> http://www.wired.com/gaming/gamingreviews/commentary/games/2008/09/gamesfrontiers_0908 >> >>> >>> http://www.businessweek.com/innovate/content/jan2009/id20090114_362962.htm >> >> Worth to read. >> >> Stef > > > The students might have employed the scientific method, but the article > itself is not a good example of even populist science writing. > > The author states that enrollment in the sciences has fallen because of > boring presentation of facts and that video games offer a rejuvenated quest > for facts. How do we know that enrollment has declined for that claimed > reason? How do we know that it's not the subject matter of video games that > interests the students, and that students won't shoe the same disinterest > when we apply video games to, say, biology or particle physics? > > I would never discard a new viable approach to teaching and learning, but > this sounds a lot like the ethanol solution to climate change. > Hmm, i didn't read a second link, but from a first one i think it says that it doesn't makes students to be more interested in theory or fundamental science. What it does, is teaching them the way of thinking, exactly how scientific method works. So, then, once they realising that, it is much easier for them to learn more diffucult things and apply the same approach to a different areas. > Mike ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about video games
On 2010-03-14, at 16:09, Stéphane Ducasse wrote: A friend of mine sent this interesting links http://www.wired.com/gaming/gamingreviews/commentary/games/2008/09/gamesfrontiers_0908 http://www.businessweek.com/innovate/content/jan2009/id20090114_362962.htm Worth to read. Stef The students might have employed the scientific method, but the article itself is not a good example of even populist science writing. The author states that enrollment in the sciences has fallen because of boring presentation of facts and that video games offer a rejuvenated quest for facts. How do we know that enrollment has declined for that claimed reason? How do we know that it's not the subject matter of video games that interests the students, and that students won't shoe the same disinterest when we apply video games to, say, biology or particle physics? I would never discard a new viable approach to teaching and learning, but this sounds a lot like the ethanol solution to climate change. Mike ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Set with nil is fixed and waiting for a nice reviewer
On 15.03.2010 00:18, Igor Stasenko wrote: 2010/3/14 Levente Uzonyi: On Sun, 14 Mar 2010, Stéphane Ducasse wrote: during the sprint niko schwarz and oscar nierstrasz fixed the Set in nil entry. Thanks. http://code.google.com/p/pharo/issues/detail?id=1907 Why did you choose Igor's negative tally hack instead of the SetElement version? I'd prefer to use SetElement, unless there was a decision made, to use negative tally. We had a quite big discussion around it on squeak-dev, and most developers said that SetElement is the way to go, because it is clean, OO-oriented, even if somewhat slower comparing to other approaches. +1 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about video games
Really interesting. The last sentence from the first link, when the kid says "I'm just cheating the game", makes me wonder if scientists are kids trying to cheat the real world game ;) On Sun, Mar 14, 2010 at 10:09 PM, Stéphane Ducasse wrote: > A friend of mine sent this interesting links > > http://www.wired.com/gaming/gamingreviews/commentary/games/2008/09/gamesfrontiers_0908 > >> http://www.businessweek.com/innovate/content/jan2009/id20090114_362962.htm > > Worth to read. > > Stef > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Patrick Barroca ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Rewrote "Smalltalk" to "Smalltalk globals"
I love you guys! :) On 14 March 2010 22:46, Stéphane Ducasse wrote: > Thanks. I'm merging. I like my dreams when they come true. > > Stef > > On Mar 14, 2010, at 9:40 PM, Lukas Renggli wrote: > >> I published a slice that rewrites "Smalltalk" to "Smalltalk globals" >> for various messages >> (http://code.google.com/p/pharo/issues/detail?id=2143). To adapt the >> code in other packages just run the rewrite rules below: >> >> Name: SLICE-RewriteSmalltalkToSmalltalkGlobals-lr.1 >> Author: lr >> Time: 14 March 2010, 9:18:06 pm >> UUID: 1742e7f2-7233-4be3-bc3d-c9332ed07ef7 >> Ancestors: >> Dependencies: Collections-Support-lr.31, Collections-Text-lr.30, >> Compiler-lr.196, CompilerTests-lr.32, Compression-lr.50, >> DeprecatedPreferences-lr.17, Files-lr.ducasse.139, FreeType-lr.524, >> Gofer-Core-lr.118, Gofer-Tests-lr.117, Graphics-lr.214, >> GraphicsTests-lr.32, Kernel-lr.617, KernelTests-lr.216, >> Monticello-lr.439, MonticelloGUI-lr.51, Morphic-lr.547, >> Multilingual-lr.155, Network-Protocols-lr.42, Network-URI-lr.17, >> Network-Url-lr.28, PackageInfo-lr.51, Polymorph-Tools-Diff-lr.26, >> Polymorph-Widgets-lr.214, ST80-lr.126, SUnit-lr.91, SUnitGUI-lr.57, >> ScriptLoader11-lr.297, Settings-Polymorph-lr.3, System-lr.11, >> System-Changes-lr.52, System-Download-lr.45, System-FilePackage-lr.36, >> System-Localization-lr.43, System-Object Storage-lr.87, >> System-Settings-lr.181, System-Support-lr.259, Tests-lr.131, >> ToolBuilder-Morphic-lr.65, Tools-lr.362, Traits-lr.359 >> >> RBParseTreeRewriter new >> replace: 'Smalltalk associationAt: `...@arg1' with: 'Smalltalk globals >> associationAt: `...@arg1'; >> replace: 'Smalltalk associationAt: `...@arg1 ifAbsent: `...@arg2' with: >> 'Smalltalk globals associationAt: >> `...@arg1 ifAbsent: `...@arg2'; >> replace: 'Smalltalk associationDeclareAt: `...@arg1' with: 'Smalltalk >> globals associationDeclareAt: >> `...@arg1'; >> replace: 'Smalltalk associationOrUndeclaredAt: `...@arg1' with: >> 'Smalltalk globals >> associationOrUndeclaredAt: `...@arg1'; >> replace: 'Smalltalk classNamed: `...@arg1' with: 'Smalltalk globals >> classNamed: `...@arg1'; >> replace: 'Smalltalk at: `...@arg1' with: 'Smalltalk globals at: >> `...@arg1'; >> replace: 'Smalltalk at: `...@arg1 ifPresent: `...@arg2' with: >> 'Smalltalk >> globals at: `...@arg1 ifPresent: >> `...@arg2'; >> replace: 'Smalltalk at: `...@arg1 ifAbsent: `...@arg2' with: 'Smalltalk >> globals at: `...@arg1 ifAbsent: >> `...@arg2'; >> replace: 'Smalltalk includesKey: `...@arg1' with: 'Smalltalk globals >> includesKey: `...@arg1'; >> replace: 'Smalltalk keyAtIdentityValue: `...@arg1' with: 'Smalltalk >> globals keyAtIdentityValue: `...@arg1'; >> replace: 'Smalltalk flushClassNameCache' with: 'Smalltalk globals >> flushClassNameCache'; >> yourself >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Set with nil is fixed and waiting for a nice reviewer
2010/3/14 Levente Uzonyi : > On Sun, 14 Mar 2010, Stéphane Ducasse wrote: > >> during the sprint niko schwarz and oscar nierstrasz fixed the Set in nil >> entry. >> Thanks. >> http://code.google.com/p/pharo/issues/detail?id=1907 > > Why did you choose Igor's negative tally hack instead of the SetElement > version? > I'd prefer to use SetElement, unless there was a decision made, to use negative tally. We had a quite big discussion around it on squeak-dev, and most developers said that SetElement is the way to go, because it is clean, OO-oriented, even if somewhat slower comparing to other approaches. > > Levente > >> >> Now does somebody with knowledge could have a look because this is a >> sensitive >> part of the system and more eyes does not hurt. >> >> Stef >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] A pause... for tests and orthogonal concerns
hi guys I was discussing with pavel and I like his point. I would like to do a kind of pause and fix the tests. Improve a bit the fact that we get more tests incrementally to avoid regression. Tell what you think and think how you could help. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Use of #asMorph
On 14 March 2010 19:42, Stéphane Ducasse wrote:
>
> On Mar 14, 2010, at 3:04 PM, Igor Stasenko wrote:
>
>> On 14 March 2010 15:38, Stéphane Ducasse wrote:
>>>
>>> I'm not convinced by your argumentation.
>>> Because
>>> #('a' 'b') collect: [:each | each asMorph]
>>> would mean to me that you get StringMorph or some morph representation of
>>> the object.
>>
>> Yes, exactly like that.
>> And i want to find a convenient approach how to achieve that. Means ,
>> that from one side we having
>> a container (list, inspector, panel, window etc) and from other side,
>> we having a model which is a collection of items.
>> And i want to find a way, how an object, which you want to represent
>> in a container, could pick a most appropriate form
>> of its representation, BUT depending on a nature of container.
>
> it smells like a lot of magic or double dispatch?
Yes, it is a double dispatch. But the problem who will take a first
half and who is second, i.e.
will message should come in
object(item) -> container direction
or
container -> object(item).
>>
>>> If this is what you want why not but I thought you talk about container
>>> containee relationship/
>>>
>>
>> I am not convinced myself that such way is feasible either. You tell :)
>> Usually, in most cases, a container dictating how its items should be
>> displayed and behave.
>> And usually, a model knows more than a little about items it contains
>> (for instance a class methods pane contains only methods, not
>> arbitrary objects).
>>
>>>
>>>
>>> Stef
>>>
>>>
>>> On Mar 14, 2010, at 2:05 PM, Igor Stasenko wrote:
>>>
On 14 March 2010 14:40, stephane ducasse
wrote:
> Igor
>
> I do not know (I'm dizzy after a couple of hours of bus) but
> asMorph for me conveys the idea that we get a transformation of the
> receiver, while if this is just to
> change the model of a morph why not model:
>
Changing a model gives nothing:
morph := MyListMorph new.
morph model: someModel.
now, since my morph is a list, it assumes that someModel object
implements a protocol, which allows to extract the
items ( #size, #at: etc).
The question is, what you would do, if you want to represent each item
in a list as a morph, so instead of:
strings := model items collect: [:each | each asString ].
you doing:
subMorphs := model items collect: [:each | each asMorph ].
...
this gives you a freedom to pick any form how represent each item in a
list, instead of bare strings.
>
> Stef
>
--
Best regards,
Igor Stasenko AKA sig.
>>>
>>>
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Best regards,
Igor Stasenko AKA sig.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Macoosi International Solver Competion
I think is worth Pharo community to give a look at this link http://www.mancoosi.org/misc-2010/ specially people more interested in package management. HTH -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Next sprint? London? England? Brussels
I would like to attempt :) now that I am near ;) On Sun, Mar 14, 2010 at 8:24 PM, Stéphane Ducasse wrote: > Excellent! > > Stef > > On Mar 14, 2010, at 8:19 PM, Gary Chambers wrote: > > > We at Pinesoft are based in London, Holborn just outside Chancery Lane > > tube station. > > > > I'll ask the guys but expect that we'd be more than happy to host a > > sprint... > > > > Regards, Gary > > > > On Sun, 2010-03-14 at 19:02 +0100, Stéphane Ducasse wrote: > >> Hi guys > >> > >> I want to thank the participants of the sprint of yesterday. Philippe it > was fun to pair program > >> and crash the system with you much more fun that alone. > >> So here is a proposition for another sprint at Berne the saturday 5 th > of June. > >> > >> Now I would love to come and code with you guys on the other side of the > channel > >> but I have no clue about england geography and where you are located. > >> Mike, gary do you have an idea? > >> > >> We could also organize a sprint at Brussels > >> Lille is so central that this is cool. > >> > >> Stef > >> ___ > >> Pharo-project mailing list > >> Pharo-project@lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > ___ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] about video games
A friend of mine sent this interesting links http://www.wired.com/gaming/gamingreviews/commentary/games/2008/09/gamesfrontiers_0908 > http://www.businessweek.com/innovate/content/jan2009/id20090114_362962.htm Worth to read. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Rewrote "Smalltalk" to "Smalltalk globals"
Thanks. I'm merging. I like my dreams when they come true. Stef On Mar 14, 2010, at 9:40 PM, Lukas Renggli wrote: > I published a slice that rewrites "Smalltalk" to "Smalltalk globals" > for various messages > (http://code.google.com/p/pharo/issues/detail?id=2143). To adapt the > code in other packages just run the rewrite rules below: > > Name: SLICE-RewriteSmalltalkToSmalltalkGlobals-lr.1 > Author: lr > Time: 14 March 2010, 9:18:06 pm > UUID: 1742e7f2-7233-4be3-bc3d-c9332ed07ef7 > Ancestors: > Dependencies: Collections-Support-lr.31, Collections-Text-lr.30, > Compiler-lr.196, CompilerTests-lr.32, Compression-lr.50, > DeprecatedPreferences-lr.17, Files-lr.ducasse.139, FreeType-lr.524, > Gofer-Core-lr.118, Gofer-Tests-lr.117, Graphics-lr.214, > GraphicsTests-lr.32, Kernel-lr.617, KernelTests-lr.216, > Monticello-lr.439, MonticelloGUI-lr.51, Morphic-lr.547, > Multilingual-lr.155, Network-Protocols-lr.42, Network-URI-lr.17, > Network-Url-lr.28, PackageInfo-lr.51, Polymorph-Tools-Diff-lr.26, > Polymorph-Widgets-lr.214, ST80-lr.126, SUnit-lr.91, SUnitGUI-lr.57, > ScriptLoader11-lr.297, Settings-Polymorph-lr.3, System-lr.11, > System-Changes-lr.52, System-Download-lr.45, System-FilePackage-lr.36, > System-Localization-lr.43, System-Object Storage-lr.87, > System-Settings-lr.181, System-Support-lr.259, Tests-lr.131, > ToolBuilder-Morphic-lr.65, Tools-lr.362, Traits-lr.359 > > RBParseTreeRewriter new > replace: 'Smalltalk associationAt: `...@arg1' with: 'Smalltalk globals > associationAt: `...@arg1'; > replace: 'Smalltalk associationAt: `...@arg1 ifAbsent: `...@arg2' with: > 'Smalltalk globals associationAt: > `...@arg1 ifAbsent: `...@arg2'; > replace: 'Smalltalk associationDeclareAt: `...@arg1' with: 'Smalltalk > globals associationDeclareAt: > `...@arg1'; > replace: 'Smalltalk associationOrUndeclaredAt: `...@arg1' with: > 'Smalltalk globals > associationOrUndeclaredAt: `...@arg1'; > replace: 'Smalltalk classNamed: `...@arg1' with: 'Smalltalk globals > classNamed: `...@arg1'; > replace: 'Smalltalk at: `...@arg1' with: 'Smalltalk globals at: > `...@arg1'; > replace: 'Smalltalk at: `...@arg1 ifPresent: `...@arg2' with: 'Smalltalk > globals at: `...@arg1 ifPresent: > `...@arg2'; > replace: 'Smalltalk at: `...@arg1 ifAbsent: `...@arg2' with: 'Smalltalk > globals at: `...@arg1 ifAbsent: > `...@arg2'; > replace: 'Smalltalk includesKey: `...@arg1' with: 'Smalltalk globals > includesKey: `...@arg1'; > replace: 'Smalltalk keyAtIdentityValue: `...@arg1' with: 'Smalltalk > globals keyAtIdentityValue: `...@arg1'; > replace: 'Smalltalk flushClassNameCache' with: 'Smalltalk globals > flushClassNameCache'; > yourself > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Rewrote "Smalltalk" to "Smalltalk globals"
I published a slice that rewrites "Smalltalk" to "Smalltalk globals" for various messages (http://code.google.com/p/pharo/issues/detail?id=2143). To adapt the code in other packages just run the rewrite rules below: Name: SLICE-RewriteSmalltalkToSmalltalkGlobals-lr.1 Author: lr Time: 14 March 2010, 9:18:06 pm UUID: 1742e7f2-7233-4be3-bc3d-c9332ed07ef7 Ancestors: Dependencies: Collections-Support-lr.31, Collections-Text-lr.30, Compiler-lr.196, CompilerTests-lr.32, Compression-lr.50, DeprecatedPreferences-lr.17, Files-lr.ducasse.139, FreeType-lr.524, Gofer-Core-lr.118, Gofer-Tests-lr.117, Graphics-lr.214, GraphicsTests-lr.32, Kernel-lr.617, KernelTests-lr.216, Monticello-lr.439, MonticelloGUI-lr.51, Morphic-lr.547, Multilingual-lr.155, Network-Protocols-lr.42, Network-URI-lr.17, Network-Url-lr.28, PackageInfo-lr.51, Polymorph-Tools-Diff-lr.26, Polymorph-Widgets-lr.214, ST80-lr.126, SUnit-lr.91, SUnitGUI-lr.57, ScriptLoader11-lr.297, Settings-Polymorph-lr.3, System-lr.11, System-Changes-lr.52, System-Download-lr.45, System-FilePackage-lr.36, System-Localization-lr.43, System-Object Storage-lr.87, System-Settings-lr.181, System-Support-lr.259, Tests-lr.131, ToolBuilder-Morphic-lr.65, Tools-lr.362, Traits-lr.359 RBParseTreeRewriter new replace: 'Smalltalk associationAt: `...@arg1' with: 'Smalltalk globals associationAt: `...@arg1'; replace: 'Smalltalk associationAt: `...@arg1 ifAbsent: `...@arg2' with: 'Smalltalk globals associationAt: `...@arg1 ifAbsent: `...@arg2'; replace: 'Smalltalk associationDeclareAt: `...@arg1' with: 'Smalltalk globals associationDeclareAt: `...@arg1'; replace: 'Smalltalk associationOrUndeclaredAt: `...@arg1' with: 'Smalltalk globals associationOrUndeclaredAt: `...@arg1'; replace: 'Smalltalk classNamed: `...@arg1' with: 'Smalltalk globals classNamed: `...@arg1'; replace: 'Smalltalk at: `...@arg1' with: 'Smalltalk globals at: `...@arg1'; replace: 'Smalltalk at: `...@arg1 ifPresent: `...@arg2' with: 'Smalltalk globals at: `...@arg1 ifPresent: `...@arg2'; replace: 'Smalltalk at: `...@arg1 ifAbsent: `...@arg2' with: 'Smalltalk globals at: `...@arg1 ifAbsent: `...@arg2'; replace: 'Smalltalk includesKey: `...@arg1' with: 'Smalltalk globals includesKey: `...@arg1'; replace: 'Smalltalk keyAtIdentityValue: `...@arg1' with: 'Smalltalk globals keyAtIdentityValue: `...@arg1'; replace: 'Smalltalk flushClassNameCache' with: 'Smalltalk globals flushClassNameCache'; yourself -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Questions about TextMorph
take squeak 3.5 Stef > >> >> Stef > > Yes, during this Pharo Sprint we worked on a EntryFieldMorph, NewTextMorph > and CodeMorph, that respectivly use SimpleEditor, TextEditor and > SmalltalkEditor ( from CUIS). > > I'll make a couple of tests tomorrow and publish the SLICE. EXCELLENT and THANKS for the clipboard check You see commit often commit simple but commit a LOT :) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Questions about TextMorph
On Mar 14, 2010, at 8:41 PM, Stéphane Ducasse wrote: >> >> I building a new TextMorph, in the context of porting Cuis Editors. >> >> I'm having problems understanding some behavior of TexMorph, >> >> 1. Whats the purpose of predecessor and successor in TextMorph? > > is it not to bind to the next one and get the text flow as in the cool squeak > demo. where can is see this demo? , i think that having pred and suc made the code more complicated. > >> 2. Why does the paragraph needs to be lazily initialized. >> >> Im my implementation of TextMorph i have neither and i don't see a good >> reason to add them. >> >> Fernando > > Fernando I would suggest to publish the code and that we see. > With Morph I have the impression that a lot have to be reconsidered. I cleanup a lot of stuff out of TextMorph, into NewTextMorph. > > Stef Yes, during this Pharo Sprint we worked on a EntryFieldMorph, NewTextMorph and CodeMorph, that respectivly use SimpleEditor, TextEditor and SmalltalkEditor ( from CUIS). I'll make a couple of tests tomorrow and publish the SLICE. Fernando > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.1] #11261
Thanks nicolas. I'm cleaning the inbox and I will ntegrate now. Stef On Mar 14, 2010, at 8:38 PM, Nicolas Cellier wrote: > 2010/3/13 Stéphane Ducasse : >> 11261 >> - >> >> - Issue 1978: Refactored DirectoryEntry by Chris Muller (tx Philippe) > > Ah, excellent, but impossible to open a FileBrowser - see this one in > PharoInbox: Tools-nice.362 > > Nicolas > >> - Issue 2137: TextConverter cleaning >> Removes unneccessary complexity from TextConverter>> nextPutAll:toStream, >> use streamContents for code clarity in String>>convertToWithConverter. >> - Issue 1656: remove #asOOP >> >> Stef >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Questions about TextMorph
> > I building a new TextMorph, in the context of porting Cuis Editors. > > I'm having problems understanding some behavior of TexMorph, > > 1. Whats the purpose of predecessor and successor in TextMorph? is it not to bind to the next one and get the text flow as in the cool squeak demo. > 2. Why does the paragraph needs to be lazily initialized. > > Im my implementation of TextMorph i have neither and i don't see a good > reason to add them. > > Fernando Fernando I would suggest to publish the code and that we see. With Morph I have the impression that a lot have to be reconsidered. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.1] #11261
2010/3/13 Stéphane Ducasse : > 11261 > - > > - Issue 1978: Refactored DirectoryEntry by Chris Muller (tx Philippe) Ah, excellent, but impossible to open a FileBrowser - see this one in PharoInbox: Tools-nice.362 Nicolas > - Issue 2137: TextConverter cleaning > Removes unneccessary complexity from TextConverter>> nextPutAll:toStream, use > streamContents for code clarity in String>>convertToWithConverter. > - Issue 1656: remove #asOOP > > Stef > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Questions about TextMorph
I building a new TextMorph, in the context of porting Cuis Editors. I'm having problems understanding some behavior of TexMorph, 1. Whats the purpose of predecessor and successor in TextMorph? 2. Why does the paragraph needs to be lazily initialized. Im my implementation of TextMorph i have neither and i don't see a good reason to add them. Fernando ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11270
11270 - - Some tests fixed! Thanks Fabrizio - Issue 2099 remove cycles: Network-UUID <-> Collections-Strings Kernel <-> Monticello MorphicTests-WindowNotification <-> Morphic-WindowNotification System-FilePackage <-> Monticello Thanks jannik Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Next sprint? London? England? Brussels
Excellent! Stef On Mar 14, 2010, at 8:19 PM, Gary Chambers wrote: > We at Pinesoft are based in London, Holborn just outside Chancery Lane > tube station. > > I'll ask the guys but expect that we'd be more than happy to host a > sprint... > > Regards, Gary > > On Sun, 2010-03-14 at 19:02 +0100, Stéphane Ducasse wrote: >> Hi guys >> >> I want to thank the participants of the sprint of yesterday. Philippe it was >> fun to pair program >> and crash the system with you much more fun that alone. >> So here is a proposition for another sprint at Berne the saturday 5 th of >> June. >> >> Now I would love to come and code with you guys on the other side of the >> channel >> but I have no clue about england geography and where you are located. >> Mike, gary do you have an idea? >> >> We could also organize a sprint at Brussels >> Lille is so central that this is cool. >> >> Stef >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Next sprint? London? England? Brussels
We at Pinesoft are based in London, Holborn just outside Chancery Lane tube station. I'll ask the guys but expect that we'd be more than happy to host a sprint... Regards, Gary On Sun, 2010-03-14 at 19:02 +0100, Stéphane Ducasse wrote: > Hi guys > > I want to thank the participants of the sprint of yesterday. Philippe it was > fun to pair program > and crash the system with you much more fun that alone. > So here is a proposition for another sprint at Berne the saturday 5 th of > June. > > Now I would love to come and code with you guys on the other side of the > channel > but I have no clue about england geography and where you are located. > Mike, gary do you have an idea? > > We could also organize a sprint at Brussels > Lille is so central that this is cool. > > Stef > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update] #10514 Network fix
I think that is correct. The problem of finding the IP address of the public interface is just another problem. May be I'm wrong, but I believe localhost has a precise definition already, it's not an invitation for us to ponder about the probable interpretations of the separate words local + host. Again, as it says in Wikipedia: "Localhost always translates to the loopback IP address 127.0.0.1 in IPv4, or ::1 in IPv6" Cheers and thanks for your work. r On Sun, Mar 14, 2010 at 6:29 PM, John M McIntosh < john...@smalltalkconsulting.com> wrote: > Ok, well obviously I need someone to define the problem if the fix was just > to return 127.0.0.1 as the result of localhostAddress. > But I *think* someone wants to know what the public interface address is, > so they can choose to bind to a particular IF, or publish it somehow. > > But maybe I'm wrong.. > > > On 2010-03-14, at 3:38 AM, Adrian Lienhard wrote: > > > Yes, pre-SocketAddress. We have left the class SocketAddress in the image > but without the additional behavior. > > > > Adrian > > > > -- > === > John M. McIntoshTwitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > === > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Set with nil is fixed and waiting for a nice reviewer
Niko Oscar? Stef On Mar 14, 2010, at 7:16 PM, Levente Uzonyi wrote: > On Sun, 14 Mar 2010, Stéphane Ducasse wrote: > >> during the sprint niko schwarz and oscar nierstrasz fixed the Set in nil >> entry. >> Thanks. >> http://code.google.com/p/pharo/issues/detail?id=1907 > > Why did you choose Igor's negative tally hack instead of the SetElement > version? > > > Levente > >> >> Now does somebody with knowledge could have a look because this is a >> sensitive >> part of the system and more eyes does not hurt. >> >> Stef >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
Yes I waiting. But thanks for the step list because this is half of the work (I hope ;)) Stef On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: > On Sun, 14 Mar 2010, stephane ducasse wrote: > >> Hi levente and others >> >> I always wanted to have Dictionary not be a subclass of Set and you did it. >> Now when you introduced that in Squeak, we were busy. >> But now I'm so found of this change (like other Smalltalk -> SmalltalkImage >> current --- which we stopped in the >> middle because lack of momentum and mindsharing) that I would like to >> integrate it into Pharo. >> Do you have any specific recommandations (like not shooting in our own foot)? > > IIRC this is what I did: > - created a copy of Set named HashedCollection > - changed it's category to Collections-Abstract > - changed Set's superclass to HashedCollection while removed it's instance > variables > - removed Set specific methods from HashedCollection > - copied Dictionary specific methods from Set to Dictionary > - changed Dictionary's superclass to HashedCollection > - removed Dictionary specific methods from Set > - cleaup (code that assumes that Dictionary is a Set may be everywhere in the > image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) > > But if you change these classes now, you'll have to update Andrés' changes. > That's why I told you earlier to add those changes before touching anything > else in the Set hierarchy. The weak dictionary related parts have to be > updated already. > > > Levente > >> >> Stef >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update] #10514 Network fix
Ok, well obviously I need someone to define the problem if the fix was just to return 127.0.0.1 as the result of localhostAddress. But I *think* someone wants to know what the public interface address is, so they can choose to bind to a particular IF, or publish it somehow. But maybe I'm wrong.. On 2010-03-14, at 3:38 AM, Adrian Lienhard wrote: > Yes, pre-SocketAddress. We have left the class SocketAddress in the image but > without the additional behavior. > > Adrian > -- === John M. McIntoshTwitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Pharocasts: How to contribute to Pharo
Here's the screencast http://pharocasts.blogspot.com/2010/03/how-to-contribute-to-pharo.html Cheers, Laurent Laffont ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Set with nil is fixed and waiting for a nice reviewer
On Sun, 14 Mar 2010, Stéphane Ducasse wrote: during the sprint niko schwarz and oscar nierstrasz fixed the Set in nil entry. Thanks. http://code.google.com/p/pharo/issues/detail?id=1907 Why did you choose Igor's negative tally hack instead of the SetElement version? Levente Now does somebody with knowledge could have a look because this is a sensitive part of the system and more eyes does not hurt. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk -> SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Next sprint? London? England? Brussels
Hi guys I want to thank the participants of the sprint of yesterday. Philippe it was fun to pair program and crash the system with you much more fun that alone. So here is a proposition for another sprint at Berne the saturday 5 th of June. Now I would love to come and code with you guys on the other side of the channel but I have no clue about england geography and where you are located. Mike, gary do you have an idea? We could also organize a sprint at Brussels Lille is so central that this is cool. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] squeaksource is down....
so this is strange they was a Squeak source is down message send an email to squeak mailing-list message ;") On Mar 14, 2010, at 6:48 PM, Lukas Renggli wrote: >> apparently 3 min after showing me the squeaksource is donw it was up again. >> May be the watch dog (if any) was working well :) > > There is no watch dog other than the one that sends out mails if the > web address is not reachable. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Set with nil is fixed and waiting for a nice reviewer
during the sprint niko schwarz and oscar nierstrasz fixed the Set in nil entry. Thanks. http://code.google.com/p/pharo/issues/detail?id=1907 Now does somebody with knowledge could have a look because this is a sensitive part of the system and more eyes does not hurt. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] squeaksource is down....
> apparently 3 min after showing me the squeaksource is donw it was up again. > May be the watch dog (if any) was working well :) There is no watch dog other than the one that sends out mails if the web address is not reachable. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Use of #asMorph
On Mar 14, 2010, at 3:04 PM, Igor Stasenko wrote:
> On 14 March 2010 15:38, Stéphane Ducasse wrote:
>>
>> I'm not convinced by your argumentation.
>> Because
>>#('a' 'b') collect: [:each | each asMorph]
>> would mean to me that you get StringMorph or some morph representation of
>> the object.
>
> Yes, exactly like that.
> And i want to find a convenient approach how to achieve that. Means ,
> that from one side we having
> a container (list, inspector, panel, window etc) and from other side,
> we having a model which is a collection of items.
> And i want to find a way, how an object, which you want to represent
> in a container, could pick a most appropriate form
> of its representation, BUT depending on a nature of container.
it smells like a lot of magic or double dispatch?
>
>> If this is what you want why not but I thought you talk about container
>> containee relationship/
>>
>
> I am not convinced myself that such way is feasible either. You tell :)
> Usually, in most cases, a container dictating how its items should be
> displayed and behave.
> And usually, a model knows more than a little about items it contains
> (for instance a class methods pane contains only methods, not
> arbitrary objects).
>
>>
>>
>> Stef
>>
>>
>> On Mar 14, 2010, at 2:05 PM, Igor Stasenko wrote:
>>
>>> On 14 March 2010 14:40, stephane ducasse wrote:
Igor
I do not know (I'm dizzy after a couple of hours of bus) but
asMorph for me conveys the idea that we get a transformation of the
receiver, while if this is just to
change the model of a morph why not model:
>>> Changing a model gives nothing:
>>>
>>> morph := MyListMorph new.
>>> morph model: someModel.
>>>
>>> now, since my morph is a list, it assumes that someModel object
>>> implements a protocol, which allows to extract the
>>> items ( #size, #at: etc).
>>> The question is, what you would do, if you want to represent each item
>>> in a list as a morph, so instead of:
>>>
>>> strings := model items collect: [:each | each asString ].
>>>
>>> you doing:
>>>
>>> subMorphs := model items collect: [:each | each asMorph ].
>>> ...
>>> this gives you a freedom to pick any form how represent each item in a
>>> list, instead of bare strings.
>>>
>>>
Stef
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] squeaksource is down....
apparently 3 min after showing me the squeaksource is donw it was up again. May be the watch dog (if any) was working well :) Stef On Mar 14, 2010, at 6:08 PM, Lukas Renggli wrote: > Not for me. > > 2010/3/14 Stéphane Ducasse : >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fix 2145 - InitialExtent
Thanks laurent! I'm eager to see that screencast :) Stef On Mar 14, 2010, at 5:29 PM, laurent laffont wrote: > In Inbox. http://code.google.com/p/pharo/issues/detail?id=2145 > > Laurent Laffont > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] squeaksource is down....
Not for me. 2010/3/14 Stéphane Ducasse : > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
> where after a while you don't know what a given annotation does because > the logic of working is somewhere else. > I prefer a single standardized message, just like "new" and "initialize" > that have well stated intentions and not convert smalltalk in a soup of > annotations like Java currently is. What about selecting the annotation and looking for its senders? The annotation doesn't change *anything* in that regard. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11269
11269 - - Issue 2145: initialExtent of Workspace is not good stef showing to laurent :) Laurent showing to stef how to screencast (stay tuned :)). Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] squeaksource is down....
___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
El dom, 14-03-2010 a las 16:12 +0100, Lukas Renggli escribió: > >> startupLevel > >>^ 100 > >> > >> method > >> > > err, but you still need to have a method, where this pragma will be located > > :) > > Yes, in the startup method itself. > > The #startUp, #shutDown, #cleanUp protocol is quite strange. They are > all defined as empty methods in Behavior, but for #startUp and > #shutDown a registration is required. This registration is missing in > some cases. #cleanUp does not require a registration. In all cases > cleanUp just delegates to one or more other methods that do the actual > cleanup. > > What I propose is to use pragmas for that. This allows to drop all the > existing implementors of #startUp, #shutDown, and #cleanUp and give > them intention revealing names. Also I envision getting rid of these > ugly boolean flags that are never quite clear what they do and what is > the default. I imagine the following 6 annotations: > > > > > > > > > > > This means for example that HandMorph > class>>#clearCompositionWindowManager could simply look likes this: > > HandMorph class>>clearCompositionWindowManager > > > CompositionWindowManager := nil > > The #startUp and the code that registers and unregisters from the > startup list is no longer necessary. > But isn't this the rationale for using annotations on Java for example, where after a while you don't know what a given annotation does because the logic of working is somewhere else. I prefer a single standardized message, just like "new" and "initialize" that have well stated intentions and not convert smalltalk in a soup of annotations like Java currently is. My 2 cents. > Lukas > -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fix 2145 - InitialExtent
In Inbox. http://code.google.com/p/pharo/issues/detail?id=2145 Laurent Laffont ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
On 14 March 2010 17:12, Lukas Renggli wrote: >>> startupLevel >>> ^ 100 >>> >>> method >>> >> err, but you still need to have a method, where this pragma will be located >> :) > > Yes, in the startup method itself. > > The #startUp, #shutDown, #cleanUp protocol is quite strange. They are > all defined as empty methods in Behavior, but for #startUp and > #shutDown a registration is required. This registration is missing in > some cases. #cleanUp does not require a registration. In all cases > cleanUp just delegates to one or more other methods that do the actual > cleanup. > > What I propose is to use pragmas for that. This allows to drop all the > existing implementors of #startUp, #shutDown, and #cleanUp and give > them intention revealing names. Also I envision getting rid of these > ugly boolean flags that are never quite clear what they do and what is > the default. I imagine the following 6 annotations: > > > > > > > > > > > This means for example that HandMorph > class>>#clearCompositionWindowManager could simply look likes this: > > HandMorph class>>clearCompositionWindowManager > > > CompositionWindowManager := nil > > The #startUp and the code that registers and unregisters from the > startup list is no longer necessary. > Good point. > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
>> startupLevel >> ^ 100 >> >> method >> > err, but you still need to have a method, where this pragma will be located :) Yes, in the startup method itself. The #startUp, #shutDown, #cleanUp protocol is quite strange. They are all defined as empty methods in Behavior, but for #startUp and #shutDown a registration is required. This registration is missing in some cases. #cleanUp does not require a registration. In all cases cleanUp just delegates to one or more other methods that do the actual cleanup. What I propose is to use pragmas for that. This allows to drop all the existing implementors of #startUp, #shutDown, and #cleanUp and give them intention revealing names. Also I envision getting rid of these ugly boolean flags that are never quite clear what they do and what is the default. I imagine the following 6 annotations: This means for example that HandMorph class>>#clearCompositionWindowManager could simply look likes this: HandMorph class>>clearCompositionWindowManager CompositionWindowManager := nil The #startUp and the code that registers and unregisters from the startup list is no longer necessary. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
On 14 March 2010 15:24, Stéphane Ducasse wrote: > Yes we talked about that. > What we would like to do is to use pragma to avoid to have a > > startupLevel > ^ 100 > > method > err, but you still need to have a method, where this pragma will be located :) > Stef > > On Mar 14, 2010, at 2:01 PM, Nicolas Cellier wrote: > >> Hi guys, >> You should have a look at Keith's work on image startup management. >> Some good ideas and MIT code could be good to >> experiment/polish/integrate in Pharo. >> Don't remember all the links (It's not always simple with Keith), but >> here are some starters: >> >> https://code.launchpad.net/~keithy/ >> https://code.launchpad.net/Cuis >> http://vimeo.com/9392990 >> >> Cheers >> >> Nicolas >> >> 2010/3/14 Stéphane Ducasse : >>> lol >>> >>> ;) >>> >>> we beat them :) >>> >>> >>> On Mar 14, 2010, at 12:55 PM, Philippe Marschall wrote: >>> On 11.03.2010 14:24, stephane ducasse wrote: > Hi guys > > tristan is a new student here and he would like to work on collection > optimization and implementation. > I would like the get some ideas from you. > - are there some collections that would be cool to improve? > - are there some collections that would be cool to have and that we > do not have yet? An ordered set, use case: start up and shut down list ;-) Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Use of #asMorph
On 14 March 2010 15:38, Stéphane Ducasse wrote:
>
> I'm not convinced by your argumentation.
> Because
> #('a' 'b') collect: [:each | each asMorph]
> would mean to me that you get StringMorph or some morph representation of the
> object.
Yes, exactly like that.
And i want to find a convenient approach how to achieve that. Means ,
that from one side we having
a container (list, inspector, panel, window etc) and from other side,
we having a model which is a collection of items.
And i want to find a way, how an object, which you want to represent
in a container, could pick a most appropriate form
of its representation, BUT depending on a nature of container.
> If this is what you want why not but I thought you talk about container
> containee relationship/
>
I am not convinced myself that such way is feasible either. You tell :)
Usually, in most cases, a container dictating how its items should be
displayed and behave.
And usually, a model knows more than a little about items it contains
(for instance a class methods pane contains only methods, not
arbitrary objects).
>
>
> Stef
>
>
> On Mar 14, 2010, at 2:05 PM, Igor Stasenko wrote:
>
>> On 14 March 2010 14:40, stephane ducasse wrote:
>>> Igor
>>>
>>> I do not know (I'm dizzy after a couple of hours of bus) but
>>> asMorph for me conveys the idea that we get a transformation of the
>>> receiver, while if this is just to
>>> change the model of a morph why not model:
>>>
>> Changing a model gives nothing:
>>
>> morph := MyListMorph new.
>> morph model: someModel.
>>
>> now, since my morph is a list, it assumes that someModel object
>> implements a protocol, which allows to extract the
>> items ( #size, #at: etc).
>> The question is, what you would do, if you want to represent each item
>> in a list as a morph, so instead of:
>>
>> strings := model items collect: [:each | each asString ].
>>
>> you doing:
>>
>> subMorphs := model items collect: [:each | each asMorph ].
>> ...
>> this gives you a freedom to pick any form how represent each item in a
>> list, instead of bare strings.
>>
>>
>>>
>>> Stef
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Best regards,
Igor Stasenko AKA sig.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Use of #asMorph
I'm not convinced by your argumentation.
Because
#('a' 'b') collect: [:each | each asMorph]
would mean to me that you get StringMorph or some morph representation of the
object.
If this is what you want why not but I thought you talk about container
containee relationship/
Stef
On Mar 14, 2010, at 2:05 PM, Igor Stasenko wrote:
> On 14 March 2010 14:40, stephane ducasse wrote:
>> Igor
>>
>> I do not know (I'm dizzy after a couple of hours of bus) but
>> asMorph for me conveys the idea that we get a transformation of the
>> receiver, while if this is just to
>> change the model of a morph why not model:
>>
> Changing a model gives nothing:
>
> morph := MyListMorph new.
> morph model: someModel.
>
> now, since my morph is a list, it assumes that someModel object
> implements a protocol, which allows to extract the
> items ( #size, #at: etc).
> The question is, what you would do, if you want to represent each item
> in a list as a morph, so instead of:
>
> strings := model items collect: [:each | each asString ].
>
> you doing:
>
> subMorphs := model items collect: [:each | each asMorph ].
> ...
> this gives you a freedom to pick any form how represent each item in a
> list, instead of bare strings.
>
>
>>
>> Stef
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
Yes we talked about that. What we would like to do is to use pragma to avoid to have a startupLevel ^ 100 method Stef On Mar 14, 2010, at 2:01 PM, Nicolas Cellier wrote: > Hi guys, > You should have a look at Keith's work on image startup management. > Some good ideas and MIT code could be good to > experiment/polish/integrate in Pharo. > Don't remember all the links (It's not always simple with Keith), but > here are some starters: > > https://code.launchpad.net/~keithy/ > https://code.launchpad.net/Cuis > http://vimeo.com/9392990 > > Cheers > > Nicolas > > 2010/3/14 Stéphane Ducasse : >> lol >> >> ;) >> >> we beat them :) >> >> >> On Mar 14, 2010, at 12:55 PM, Philippe Marschall wrote: >> >>> On 11.03.2010 14:24, stephane ducasse wrote: Hi guys tristan is a new student here and he would like to work on collection optimization and implementation. I would like the get some ideas from you. - are there some collections that would be cool to improve? - are there some collections that would be cool to have and that we do not have yet? >>> >>> An ordered set, use case: start up and shut down list ;-) >>> >>> Cheers >>> Philippe >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
thanks. I'm waiting for the hash fixes that martin and andres are looking at. Stef On Mar 14, 2010, at 2:10 PM, Nicolas Cellier wrote: > 2010/3/14 stephane ducasse : >> Hi levente and others >> >> I always wanted to have Dictionary not be a subclass of Set and you did it. >> Now when you introduced that in Squeak, we were busy. >> But now I'm so found of this change (like other Smalltalk -> SmalltalkImage >> current --- which we stopped in the >> middle because lack of momentum and mindsharing) that I would like to >> integrate it into Pharo. >> Do you have any specific recommandations (like not shooting in our own foot)? >> >> Stef >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > Very good idea. > > Can't help you much, Levente did all the hard work. > Remember you also have: > http://code.google.com/p/pharo/issues/detail?id=213 > http://code.google.com/p/pharo/issues/detail?id=902 > http://code.google.com/p/pharo/issues/detail?id=1868 > http://code.google.com/p/pharo/issues/detail?id=1907 > ... and good tricks from Andres Valloud that Levente probably used to. > > Cheers > > Nicolas > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
2010/3/14 stephane ducasse : > Hi levente and others > > I always wanted to have Dictionary not be a subclass of Set and you did it. > Now when you introduced that in Squeak, we were busy. > But now I'm so found of this change (like other Smalltalk -> SmalltalkImage > current --- which we stopped in the > middle because lack of momentum and mindsharing) that I would like to > integrate it into Pharo. > Do you have any specific recommandations (like not shooting in our own foot)? > > Stef > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Very good idea. Can't help you much, Levente did all the hard work. Remember you also have: http://code.google.com/p/pharo/issues/detail?id=213 http://code.google.com/p/pharo/issues/detail?id=902 http://code.google.com/p/pharo/issues/detail?id=1868 http://code.google.com/p/pharo/issues/detail?id=1907 ... and good tricks from Andres Valloud that Levente probably used to. Cheers Nicolas ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Use of #asMorph
On 14 March 2010 14:40, stephane ducasse wrote: > Igor > > I do not know (I'm dizzy after a couple of hours of bus) but > asMorph for me conveys the idea that we get a transformation of the receiver, > while if this is just to > change the model of a morph why not model: > Changing a model gives nothing: morph := MyListMorph new. morph model: someModel. now, since my morph is a list, it assumes that someModel object implements a protocol, which allows to extract the items ( #size, #at: etc). The question is, what you would do, if you want to represent each item in a list as a morph, so instead of: strings := model items collect: [:each | each asString ]. you doing: subMorphs := model items collect: [:each | each asMorph ]. ... this gives you a freedom to pick any form how represent each item in a list, instead of bare strings. > > Stef > -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
Hi guys, You should have a look at Keith's work on image startup management. Some good ideas and MIT code could be good to experiment/polish/integrate in Pharo. Don't remember all the links (It's not always simple with Keith), but here are some starters: https://code.launchpad.net/~keithy/ https://code.launchpad.net/Cuis http://vimeo.com/9392990 Cheers Nicolas 2010/3/14 Stéphane Ducasse : > lol > > ;) > > we beat them :) > > > On Mar 14, 2010, at 12:55 PM, Philippe Marschall wrote: > >> On 11.03.2010 14:24, stephane ducasse wrote: >>> Hi guys >>> >>> tristan is a new student here and he would like to work on collection >>> optimization and implementation. >>> I would like the get some ideas from you. >>> - are there some collections that would be cool to improve? >>> - are there some collections that would be cool to have and that we do >>> not have yet? >> >> An ordered set, use case: start up and shut down list ;-) >> >> Cheers >> Philippe >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] About getting HashedCollection (another dream happening)
Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk -> SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
lol ;) we beat them :) On Mar 14, 2010, at 12:55 PM, Philippe Marschall wrote: > On 11.03.2010 14:24, stephane ducasse wrote: >> Hi guys >> >> tristan is a new student here and he would like to work on collection >> optimization and implementation. >> I would like the get some ideas from you. >> - are there some collections that would be cool to improve? >> - are there some collections that would be cool to have and that we do >> not have yet? > > An ordered set, use case: start up and shut down list ;-) > > Cheers > Philippe > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN 1.1] pre-built core 1.1#11268
thanks marcus I just arrived to annecy and will probably hack again this afternoon (with laurent ?) Stef On Mar 14, 2010, at 12:00 PM, Marcus Denker wrote: > > > https://gforge.inria.fr/frs/download.php/26667/PharoCore-1.1-11268-UNSTABLE.zip > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] about polymorph
Hi gary here is the vision I would love to have for polymorph. Gary what would be good is that if we could - create adequate hooks in the underlying Morph to make sure that Polymorph can be easily added. - revisite clean change existing morphs that you may have to patch or rewrite to get polymorph The vision is can we have a good foundation on top of which "polymorph" could be build I put "" because it implies that some of the Polymorph changes or widgets may be pushed to the basis and Polymorph may be lighter because of that. This decomposition would make sure that Polymorph can be autonomous from the foundation and that for example you can decline different variants or that other people can define different look if they want. What do you think? I believe that we could get the best of both worlds: pharo infrastructure a better infrastructure and you less code to maintain for polymorph. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Polymorph
+1 On Mar 13, 2010, at 10:29 PM, Igor Stasenko wrote: > I'd recommend to incorporate all Polymorph's overrides into Morphic. > Then you can still maintain Polymorph as separate package, > but don't fool yourself with a tons of overrides. > > On 13 March 2010 19:15, Stéphane Ducasse wrote: >> >> On Mar 13, 2010, at 5:56 PM, Gary Chambers wrote: >> >>> All "fun" on squeak-dev... >>> >>> Getting close to abandoning support for Polymorph in Squeak at all now... >>> Only a few apps based on 3.9 left here. Not sure they need any of the >>> ongoing improvements. >> >> I'm not sure that maintaining two version is an option for you. >> >>> So, the question is, how would we want future additions/changes/fixes to >>> apply in Pharo. >> >> The way you were doing them is ok. >> You could also publish directly in Pharo >> But if you want to have you own package and control over it this is ok too. >> >>> Having Polymorph as an external (mergable, not loadable) package has worked >>> well for us, as much as it can be well. >>> >>> Perhaps changesets are the way to go from here... opinions/advice welcome... >> >> Why MC is not good for you? >> >>> >>> Regards, Gary >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Collection
On 11.03.2010 14:24, stephane ducasse wrote: > Hi guys > > tristan is a new student here and he would like to work on collection > optimization and implementation. > I would like the get some ideas from you. > - are there some collections that would be cool to improve? > - are there some collections that would be cool to have and that we do > not have yet? An ordered set, use case: start up and shut down list ;-) Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [ANN 1.1] pre-built core 1.1#11268
https://gforge.inria.fr/frs/download.php/26667/PharoCore-1.1-11268-UNSTABLE.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Mac carbon VM goes to 4.2.3beta1U
Thanks John! This is the direct download link so not everybody needs to spend minutes to find it :) ftp://ftp.smalltalkconsulting.com/Squeak%204.2.3beta1U.app.zip Cheers, Adrian On Mar 14, 2010, at 08:34 , John M McIntosh wrote: > In order to wrap up some VM fixes that should be pushed into the Squeak 4.x > offering I've compiled up a 4.2.3beta1U VM > This will be the last 4.x series of macintosh VMs as the 5.x series gains > support. > > Someone should run the Sunit and smoke test to ensure the VM is sane. > > Follow the macintosh link from http://www.squeakvm.org/index.html > > 4.2.3b1 We update to VMMaker 160 > > Reference Mantis 7405: Array new: SmallInteger maxVal > broken. > Reference Mantis 7407: BitBlt. Incorrect alpha values > for several rules. > Reference Mantis 7421: Bug in > Interpreter>>primitiveNextPut: > (Various 64bit fixes which don't apply to this 32bit VM) > > Put ObjectiveCPlugin.bundle to 1.1.2 > Removed SparklePlugin because of file copy issues on > squeak 4.0 build process. bad sym links > > This VM includes some features not in VMMaker yet > * > (a) primitiveAsyncFileOpen: 64bit > (b) explicit declare for primitiveShowHostWindow: > (c) primitive for microsecond clock > (f) statGCTime, > statFullGCMSecs,statIGCDeltaTime,statIncrGCMSecs go to 64bit for > microscecond clock > (e) primitiveVMParameter changes to pull back 64bit > values > (f) JPEGReaderPlugin, work to make 64bit clean > (g) primitiveMIDIGetPortName: 64bit fix > > > NSCursorWrapper.m compiler warning cleanup > sqMacMacmain.m compiler warning cleanup > sqMacTime.c add microsecond clock > sqmacWIndowUniversal.c compiler warning cleanup > > > -- > === > John M. McIntoshTwitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > === > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update] #10514 Network fix
Yes, pre-SocketAddress. We have left the class SocketAddress in the image but without the additional behavior. Adrian On Mar 13, 2010, at 20:06 , Chris Muller wrote: > One year ago? So pre-SocketAddress? > > On Sat, Mar 13, 2010 at 8:22 AM, Adrian Lienhard wrote: >> NOTE: this update reverts NetNameResolver and code from other classes like >> Socket to the state we had about one year ago. Please let us know about any >> problems related to networking! >> >> 10514 >> - >> - Issue 1884: NetNameResolver doesn't work in PharoCore 10508 >> - Upadet VBRegex to version VB-Regex-lr.38 >> >> ___ >> http://www.adrian-lienhard.ch/ >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
