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

[Pharo-project] Merging 6834
by StÃ©phane Ducasse June 2, 2008

June 2, 2008

I'm merging 0006834: Delay class>>timeoutSemaphore:afterMSecs: doesn't. Description The implementation for Delay class>>timeoutSemaphore:afterMSecs: doesn't even use its first parameter, so it can't do what it says it does. This method should be deprecated or removed entirely. Additional Information + tests

1 0

[Pharo-project] Some questions on how to help
by Norbert Hartl June 2, 2008

June 2, 2008

Hi, I really appreciate the existence of the pharo project. For me I declared it as a good starting point for me to dive into the deeper waters of squeak/pharo. My biggest problem is that I do not know how exactly things have to be done. I don't want to just submit changes without to know if the worth it. A little story. I started last week to toy around with the newest pharo release. On the web site I read that all tests green is a primary goal. So I started to let the test runner run all tests. After having some trouble I found a failing test in NumberParsingTest. The test is failing because the test case expects Number>>readFrom: to throw an error if a number couldn't be parsed. Searchig the ST80 book I found nothing about Number>>readFrom:. Searching the web I found a thread on squeak-dev from january where the outcome was: - readFrom: returns 0 on unsuccesful read attempt to satisfy the parser (sounds like some history thing) - readExactlyFrom: does throw an error an unsuccesful read attempt. And it utilizes sqNumberParser So what to do? I tried to be least aggressive and fixed the test case to use readExactlyFrom: (and then splitting the test case into two because the test does different things). Not thinking first I would have asked a lot of questions on this list: - Do we want to preserve the current readFrom: ? - Should we integrate sqNumberParser completely avoiding mulitple implementations? - Is it only me having slightly problems having a class Number which uses a class SqNumberParser instead of integrating the code into the Number hierarchy? Is there a way to get this questions answered without generating a lot of noise on the list? Other questions: - I scanned the image for obsolete references and found some. I don't know how to deal with it in an update. Using ServerDirectory resetServers. FileServices removeObsolete. PackageOrganizer default unregisterPackageNamed: 'FlexibleVocabularies' I have removed all obsolete references but one. How is this integrated into the upstream? - Trying to solve the last obsolete references I found an obsolete class referenced in PasteUpMorph. The method which referenced it is PasteUpMorph>>isSafeToServe. The method is in category Nebraska. I thought Nebraska has been removed from the system. Thinking that I would have removed all methods of this category but one because they have no senders. One method transferRemoteServerFrom: is referenced from Project>>enter: returningFlag revert: revertFlag saveForRevert: saveForRevert Is it ok to rip this call out (by trying to understand what it does in class Project ;) ) Some words of advice would be helpful to get a feeling about those things. I don't have a problem preparing some stuff and put it into the Inbox. A problem would be to have a patch rejected without explanation :) Norbert

2 2

[Pharo-project] Re: [Sapphire-devl] sapphire to pharo :)
by Adrian Lienhard June 2, 2008

June 2, 2008

Hi Stef, Today I tried again to load Pharo starting from a fresh 3.9.1 image but I got the same error when loading "10015-Sap- FixingInvisibleInTheRest..." (see my mail in this thread from May 16). I had a closer look and the problem is that script106 tries to load Protocols-sd.13.mcz, which does not exist in the repository. I guess the update worked for you because this file was in your local cache. Can you copy this package to the repository? Adrian On May 17, 2008, at 08:19 , StÃ©phane Ducasse wrote: > Yes this may happen. We are certainly stressing the server. > Now #hex is really missing in 391. :) > > Stef > > On May 17, 2008, at 6:40 AM, Victor Rodriguez wrote: > >> On Sat, May 17, 2008 at 12:14 AM, Victor Rodriguez >> <victor.palique(a)gmail.com> wrote: >> ... >>> It failed for me in update 10016. I attach the log. >> >> It must have been a network error, since started all over again and >> it >> is now in update 10020... >> >> Victor. >> >> _______________________________________________ >> Sapphire-devl mailing list >> Sapphire-devl(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/sapphire-devl >> > > > _______________________________________________ > Sapphire-devl mailing list > Sapphire-devl(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/sapphire-devl

2 6

[Pharo-project] Mvc removing step1
by Alain Plantec June 2, 2008

June 2, 2008

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

2 3

[Pharo-project] Fwd: I tried to load
by StÃ©phane Ducasse June 2, 2008

June 2, 2008

Begin forwarded message: > From: "Gary Chambers" <gary(a)pinesoft.co.uk> > Date: June 2, 2008 2:48:17 PM CEDT > To: "stephane ducasse" <stephane.ducasse(a)free.fr> > Subject: RE: I tried to load > > Had a go with Pharo today. UI Enhancements loads OK provided > MCPackageLoader>>basicLoad is modified to prevent the display of > progress > while processing the additions. > > I'm thinking of some way of flaging a package for this, though MC > would need > quite a few changes to handle it. Perhaps pick up an extra field in > the > package dictionary of the mcz and, somehow, pass along to the > PackageLoader... > > Regards, Gary. > >> -----Original Message----- >> From: stephane ducasse [mailto:stephane.ducasse@free.fr] >> Sent: 22 May 2008 6:13 PM >> To: Gary Chambers >> Subject: Re: I tried to load >> >> >> Thanks I will check. >> I can load 60 without any problems. >> >> Stef >> >>> Sounds like an MC load order problem again. >>> The change was for double-dispatching of use of fill-styles back to >>> the >>> fill-style itself to support more complex/composite fill styles. >>> >>> Best to try to load with the MCPackageLoader>>basicLoad modification >>> and as >>> few windows etc. as possible. >>> >>> Let me know if your problems persist and I'll give it a go too. >>> >>> Regards, Gary. >> >> > > > > ****************************************************************************************************************************************** > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > ******************************************************************************************************************************************* > > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA >

2 1

[Pharo-project] Fwd: Discussion about Nile in Pharo
by StÃ©phane Ducasse June 2, 2008

June 2, 2008

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

1 0

[Pharo-project] SqueakSource down ?
by Serge Stinckwich June 1, 2008

June 1, 2008

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

2 2

June 1, 2008

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

1 0

June 1, 2008

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

1 0

June 1, 2008

1 0