June 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] Mvc removing step1

by Alain Plantec

Hi all I've upload SLICE-MvcRemoving-Step1 package to PharoInbox: - I update all methods with a #isMorphic send: "Smalltalk isMorphic ifTrue: [XXX] ifFalse: [YYY]" is replaced by "XXX". - I remove some methods which are no more useful as Debugger>>buildMVCDebuggerViewLabel:minSize: alain

June 2, 2008

[Pharo-project] Fwd: Discussion about Nile in Pharo

by StÃ©phane Ducasse

Begin forwarded message: > From: "Bill Schwab" <BSchwab(a)anest.ufl.edu> > Date: June 1, 2008 9:34:45 PM CEDT > To: <stephane.ducasse(a)inria.fr> > Cc: <knight(a)acm.org>, <damien.cassou(a)gmail.com> > Subject: Re: Discussion about Nile in Pharo > > Stef, > > I agree, though I would exchange the order. The RB fix of #next is > simple, and I doubt there will ever be a completely painless time to > do it. So I would do the rename, add the new/changed methods, and > then convert to Nile, having updated its semantics prior to the > conversion. > > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > >>>> StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 06/01/08 3:07 PM >>> > I think that you should > > - use the mailing-list > - separate two things > - the use of Nile as default > - the fix of the behavior next: > > Stef > > On Jun 1, 2008, at 3:27 PM, Bill Schwab wrote: > >> Damien, >> >> That is a great next step. Dumb question: do I already have an >> account by virtue of being on the list, or do I need to create one? >> >> Your rewrite to cope with #on: is fascinating, but I continue to >> wonder whether it is necessary. In fact, I _think_ I would prefer >> to rename the Nile classes (either up front or probably post-install >> via the RB) to be generic. While I too prefer idioms such as Array >> writeStream and aCollection readStream, #on: is perfectly ok, though >> clumsy. What we should do depends on your goal, and of course on >> what works best. >> >> Changing to Nile via #readStream and #writeStream has its >> advantages, but the rewrite has made me greedy :) I am thinking of >> something like the following: >> >> (1) prepare the image by renaming methods (#next -> #nextOrNil:, >> #next -> #nextAvailable:) to reflect current silently-truncating >> semantics >> >> (2) add the silent truncating methods to Nile; add #on: methods to >> Nile, including comments referencing the shortcut methods >> >> (3) change Nile's #next, #next: to raise errors; noting that after >> (1), the image will call the truncating methods, and only new code >> will see the errors >> >> (4) either Smalltalk at:#ReadStream put:NSReadStream, etc., or >> perhaps better yet just ask the RB to rename the Nile classes, so >> that one codes in terms of ReadStream, WriteStream, catches >> EndOfStream. We can provide a defined set of RB steps that anyone >> can use in a throw-away image to prepare code that we did not fix >> for them; it should basically be step (1). >> >> Comments? If you at all agree, feel free to edit and put it on the >> Wiki while I figure out how to access it. >> >> Bill >> >> >> >> >> Wilhelm K. Schwab, Ph.D. >> University of Florida >> Department of Anesthesiology >> PO Box 100254 >> Gainesville, FL 32610-0254 >> >> Email: bschwab(a)anest.ufl.edu >> Tel: (352) 846-1285 >> FAX: (352) 392-7029 >> >>>>> "Damien Cassou" <damien.cassou(a)gmail.com> 06/01/08 6:30 AM >>> >> Hi Bill, >> >> I writing a wiki page where I explain what we can do to slowly >> install Nile: >> https://gforge.inria.fr/plugins/wiki/index.php?refs=NileInstallation&id=129… >> >> You can help me with the redaction. >> >> -- >> Damien Cassou >> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >> >> > > >

June 2, 2008

Re: [Pharo-project] SqueakSource down ?

by Serge Stinckwich

No problem Adrian, i can wait ;-) 2008/6/1 Adrian Lienhard <adi(a)netstyle.ch>: > yes, again the server is not responding anymore. Unfortunately, we canot do > anything until the server admin guys come in tomorrow morning. > > Adrian > > On Jun 1, 2008, at 21:18 , Serge Stinckwich wrote: > >> SqueakSource down ? >> >> -- >> Serge Stinckwich >> http://blog.doesnotunderstand.org/ >> >> _______________________________________________ >> 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 > -- Serge Stinckwich http://blog.doesnotunderstand.org/

June 1, 2008

Re: [Pharo-project] SqueakSource down ?

by Adrian Lienhard

yes, again the server is not responding anymore. Unfortunately, we canot do anything until the server admin guys come in tomorrow morning. Adrian On Jun 1, 2008, at 21:18 , Serge Stinckwich wrote: > SqueakSource down ? > > -- > Serge Stinckwich > http://blog.doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 1, 2008

[Pharo-project] SqueakSource down ?

by Serge Stinckwich

SqueakSource down ? -- Serge Stinckwich http://blog.doesnotunderstand.org/

June 1, 2008

[Pharo-project] Fwd: Discussion about Nile in Pharo

by StÃ©phane Ducasse

Begin forwarded message: > From: "Bill Schwab" <BSchwab(a)anest.ufl.edu> > Date: June 1, 2008 4:32:46 PM CEDT > To: <damien.cassou(a)gmail.com> > Cc: <knight(a)acm.org>, <stephane.ducasse(a)inria.fr> > Subject: Re: Discussion about Nile in Pharo > > Damien, > > A partial reply. Interesting point about the various collection > classes. Perhaps we can double-dispatch to make the creation work, > something like > > ReadStream on:aCollection > ^aCollection readStream. > > ReadStream and friends would exist, but concrete classes would be > instantiated. Could that work? It would be along the lines of > Squeak's file directories, where the programmer can think in > abstractions and the code does the right thing (and instantiates the > correct classes) for the platform. > > As far as #next, my proposal is to avoid the error altogether by > transforming (RB) old code so that it uses #nextOrNil and will work > as before, but without abusing the contentious selector. > Untransformed old code would likely break, but there would be a > procedure for using a throw-away Squeak image to fix it for > inclusion in Pharo, and we would have already done transformed code > considered to be part of Pharo. My instinct tells me to get it done > up front, for fear that the backward-compatibility arguments would > prevent doing it in the future. I am not usually a disk-pack > arsonist, but in this case, the sooner the better IMHO. Again, a > few messages to the RB, and nothing changes except we rename the > abused selector. Everything continues to work; new code can work as > it should. > > I can check with Dolphin, but I do not believe #peek* are affected. > It could get interesting for sockets where new elements could be in > transit, but the general feel of peek is to look and either move > past the element or leave the position unchanged; the latter would > probably be what happens. I will ponder and look at the other > dialects. > > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > >>>> "Damien Cassou" <damien.cassou(a)gmail.com> 06/01/08 9:47 AM >>> > On Sun, Jun 1, 2008 at 3:27 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> > wrote: >> That is a great next step. Dumb question: do I already have an >> account by virtue of being on the list, or do I need to create one? > > You have to create an account I think. Then, you has to ask the pharo > project to join. We will receive a mail and will be able to accept > your request (or refuse, we will see :-D). > > >> Your rewrite to cope with #on: is fascinating, but I continue to >> wonder whether it is necessary. In fact, I _think_ I would prefer >> to rename the Nile classes (either up front or probably post- >> install via the RB) to be generic. While I too prefer idioms such >> as Array writeStream and aCollection readStream, #on: is perfectly >> ok, though clumsy. What we should do depends on your goal, and of >> course on what works best. > > > I do not agree for the following reasons: > > - in Nile, there is just one class which is the equivalent of > ReadStream, WriteStream and ReadWriteStream. It is named > NSCollectionStream. There is no one-to-one relation. > - in Nile, there are specific classes to handle strings and arrays, > NSStringStream and NSArrayStream.How do you change the existing source > code to use the right stream class depending on the collection class? > > >> Changing to Nile via #readStream and #writeStream has its >> advantages, but the rewrite has made me greedy :) I am thinking of >> something like the following: >> >> (1) prepare the image by renaming methods (#next -> #nextOrNil:, >> #next -> #nextAvailable:) to reflect current silently-truncating >> semantics > > > - I'm not sure we should do this change now. I would prefer waiting > that Nile is the default Stream implementation. That way, we avoid > changing the Squeak Stream library. Moreover, I think people need more > time to think about throwing errors with #next. They need to see how > that change will affect their code in practice. Moreover, this change > might introduce a lot of new methods like peekIfAvailable and others. > > >> (2) add the silent truncating methods to Nile; > >> add #on: methods to Nile, including comments referencing the >> shortcut methods > > > #on: is already in Nile and it is the only way to create a new > collection stream. > > >> (3) change Nile's #next, #next: to raise errors; noting that after >> (1), the image will call the truncating methods, and only new code >> will see the errors >> >> (4) either Smalltalk at:#ReadStream put:NSReadStream, etc., or >> perhaps better yet just ask the RB to rename the Nile classes, so >> that one codes in terms of ReadStream, WriteStream, catches >> EndOfStream. We can provide a defined set of RB steps that anyone >> can use in a throw-away image to prepare code that we did not fix >> for them; it should basically be step (1). >> >> Comments? If you at all agree, feel free to edit and put it on the >> Wiki while I figure out how to access it. > > > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > >

June 1, 2008

[Pharo-project] Fwd: Discussion about Nile in Pharo

by StÃ©phane Ducasse

Begin forwarded message: > From: "Bill Schwab" <BSchwab(a)anest.ufl.edu> > Date: June 1, 2008 3:27:45 PM CEDT > To: <damien.cassou(a)gmail.com> > Cc: <knight(a)acm.org>, <stephane.ducasse(a)inria.fr> > Subject: Re: Discussion about Nile in Pharo > > Damien, > > That is a great next step. Dumb question: do I already have an > account by virtue of being on the list, or do I need to create one? > > Your rewrite to cope with #on: is fascinating, but I continue to > wonder whether it is necessary. In fact, I _think_ I would prefer > to rename the Nile classes (either up front or probably post-install > via the RB) to be generic. While I too prefer idioms such as Array > writeStream and aCollection readStream, #on: is perfectly ok, though > clumsy. What we should do depends on your goal, and of course on > what works best. > > Changing to Nile via #readStream and #writeStream has its > advantages, but the rewrite has made me greedy :) I am thinking of > something like the following: > > (1) prepare the image by renaming methods (#next -> #nextOrNil:, > #next -> #nextAvailable:) to reflect current silently-truncating > semantics > > (2) add the silent truncating methods to Nile; add #on: methods to > Nile, including comments referencing the shortcut methods > > (3) change Nile's #next, #next: to raise errors; noting that after > (1), the image will call the truncating methods, and only new code > will see the errors > > (4) either Smalltalk at:#ReadStream put:NSReadStream, etc., or > perhaps better yet just ask the RB to rename the Nile classes, so > that one codes in terms of ReadStream, WriteStream, catches > EndOfStream. We can provide a defined set of RB steps that anyone > can use in a throw-away image to prepare code that we did not fix > for them; it should basically be step (1). > > Comments? If you at all agree, feel free to edit and put it on the > Wiki while I figure out how to access it. > > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > >>>> "Damien Cassou" <damien.cassou(a)gmail.com> 06/01/08 6:30 AM >>> > Hi Bill, > > I writing a wiki page where I explain what we can do to slowly > install Nile: > https://gforge.inria.fr/plugins/wiki/index.php?refs=NileInstallation&id=129… > > You can help me with the redaction. > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > >

June 1, 2008

[Pharo-project] I added the 3.10.1 list of fixes to the wiki.

by StÃ©phane Ducasse

June 1, 2008

Re: [Pharo-project] Replacing 'ReadStream on smth:' by 'smth readStream'

by StÃ©phane Ducasse

Good! Stef On Jun 1, 2008, at 3:58 PM, Bill Schwab wrote: > Stef, > > My email server crashed yesterday and was out of action for several > hours. From emails I found this morning, it looks like Damien and I > will cook up a plan on the Wiki. With luck, we will be able to get > the > RB to do the tedious work, and also leave a simple defined procedure > for > converting "old" code that we did not have loaded during the > transformation. Transformed code should work as it always did; new > code > will be able to benefit from consistent semantics and exception > handling. There will also be silently truncating methods for the > situations (and they indeed exist) that call for them. > > More to come. > > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > >>>> stephane.ducasse(a)inria.fr 05/31/08 4:22 PM >>> > > On May 30, 2008, at 10:46 PM, Bill Schwab wrote: > >> Stef, >> >> Whether or not I agree depends on what you mean. While I think I >> see where Damien is going, my read is that #on: is actually >> negotiable, given that we should be able to either fix (or simply >> replace and than alias) ReadStream - two different ways of solving >> the same problem. But if you concerned about breaking some things >> that Damien and I are committed to fixing as part of the change, >> then I submit that we will be helpless when we move from the >> relatively calm world of streams to the chaos of morphic. > > You lost me. :) > > >> Which part bothers you? > > None :) > >> The plan is to rennovate (sometimes messy) and *then* slowly evolve >> the resulting stable system, right? > > The plan is to move but be careful. This is why I would like you guys > to tell us > what you want to do (or are doing) so that we can document the changes > and everybody can participate > and help also fixing if necessary. I just want more organized > communication when we have a "big" change. > No more. > > Stef > > _______________________________________________ > 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 >

June 1, 2008

Re: [Pharo-project] Re: [Sapphire-devl] sapphire to pharo :)

by StÃ©phane Ducasse

> >> Done. >> Can you check? > > Looks good! I got beyond the problematic script. But I could not > load to the latest package because the SqueakSource server went down > in the meantime :(. Will check again later. Yes I noticed that too :) I was planning to do a new release. Stef

June 1, 2008