- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About on:
by Bill Schwab June 5, 2008

June 5, 2008

Damien, Lukas, Stef, Yes, but it is not consistent, and they are apparently not happy with it. Object Arts' solution is consistent both with itself and with yoga of structured exception handling. However, at this point, it appears that you do not want to make the change, so I will stop pressing. 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(a)gmail.com 06/05/08 6:27 AM >>> On Thu, Jun 5, 2008 at 12:01 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> > No surprise, I would argue that we proceed, and would also include a >> rename of #next to #nextOrNil and #next: to #nextAvailable:. All code in >> the image at the time should work as before. >> >> What would be the impact on code that is not in the image? Would all >> external packages need to be adapted as well or would the current semantics >> be preserved? > > I suggest to implement #next so that it throws an EndOfStream > notification. The default action would return nil, so no existing code > needs to be changed. People that want to use exceptions capture the > notification. That's what is in VW apparently. -- 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) _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

4 3

Re: [Pharo-project] About on:
by Bill Schwab June 5, 2008

June 5, 2008

Damien, It cannot be "fixed" without breaking said external code. However, there is a very clear way for those interested to refactor old code to be consistent. The only alternative is to use selectors such as #nextOne, #nextMany:, etc., to do the jobs that #next and #next: purport to do. I can do that myself; my hope is to fix the real problem, and to gradually bring VW along with us. Perhaps my problem is that I fell into a Smalltalk (Dolphin) that had this right (and grumbled about it, only to later be convinced of its correctness), and now find the analogy to #at: very clear as a result. IMHO, this is a situation where we should lead, but you already knew that. Time for me to start my commute. 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(a)gmail.com 06/05/08 7:39 AM >>> On Thu, Jun 5, 2008 at 1:06 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Yes, but it is not consistent, and they are apparently not happy with it. Object Arts' solution is consistent both with itself and with yoga of structured exception handling. However, at this point, it appears that you do not want to make the change, so I will stop pressing. I personally would like to see this change in Pharo. However, there is no consensus and it might affect a lot of external code that the refactoring can't change. -- 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) _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] About readStream on: vs readStream
by StÃ©phane Ducasse June 5, 2008

June 5, 2008

Hi damien I was wondering why you think that ReadStream on: anObject is worse than anObject readStream? Because you do not hardcode ReadStream? Stef

2 2

[Pharo-project] HowToContribute wiki page rewrite
by Victor Rodriguez June 5, 2008

June 5, 2008

Hello, I took the liberty of rewriting the HowToContribute wiki page [1] with some of the information from the recent discussion in the mailing list. Please take a look at the wiki page (I have also reproduced the text below) and feel free to make corrections yourself (or post a reply to this message and I'll take care of it). Please take special care reviewing the "publish to PharoInbox" step, since I have yet to publish anything myself so I might have gotten it wrong. Best regards, VÃctor RodrÃguez. p.s. I got to watch two "Smalltalk daily" [2] screencasts while waiting for the edited page to save.. any timetable on the nifty Pier or Cmsbox Pharo project site? :-) [1] http://gforge.inria.fr/plugins/wiki/index.php?id=1299&type=g [2] http://www.cincomsmalltalk.com/blog/blogView?searchCategory=screencast First and foremost, you must be aware that '''the Pharo project only accepts code published under the MIT license'''. By publishing your code in the !SqueakSource Pharo or !PharoInbox repositories, you are agreeing to this condition. With that out of the way, here are the steps to submit your contributions: * Prepare a changeset with your changes. File it out. '''Important''': Put your Full name instead of your initials, it will help up to contact you as it is often necessary. * Load your changes into a fresh image: ** Download the latest Pharo image from [Files | http://gforge.inria.fr/frs/?group_id=1299] ** Launch the fresh image and load the latest updates by clicking on the ''load code updates'' button on the left flap. ** Importat: Save the image at this point, so that you don't need to reload the updates when you test your changes. ** File in your changeset. * Create a SLICE package in your package cache: ** Open the Monticello browser. You should see one or more packages marked as modified (they have an asterisk before their name). ** Select your package-cache repository on the right hand pane. ** Create the new package (click on the ''+Package'' button). Name it SLICE-nameofchange, (e.g. SLICE-remove-isMorphic). ** Make all the modified packages (the ones with asterisks before their names) required by your SLICE package. To do this, right click on the SLICE package in the left pane and select ''add required package'', then select the package from the next menu. Repeat for all modified packages. ** Save the SLICE package (click on the ''Save'' button). An mcz package will be saved in your cache for the SLICE package and all the modified packages. You will be prompted for a log message for each one of them, type a useful comment for the first package, copy it and paste it on the others. ** To prepare for the next step, quit the image without saving. * Test your packages in the clean image. ** Relaunch the clean Pharo image. If you didn't save the image after loading the updates, load the updates (I told you it was important!). ** Open the Monticello browser. ** Open your package-cache repository (select the package-cache in the right pane, click on the ''Open'' button). ** Load your SLICE package. If it loads without errors, you are ready for the next step. If there are errors, try again, or ask for help in the mailing list. * Publish the SLICE package to !PharoInbox !SqueakSource repository. ** In the Monticello browser add the !PharoInbox repository. Make sure the SLICE package is selected in the left pane, then click on the ''+Repository''. Select ''HTTP'' from the menu, then make sure that the location reads ''http://www.squeaksource.com/PharoInbox''. ** Finally, click on ''Save''. * Announce your contribution. ** You might need to add an entry to the [tracker | http://gforge.inria.fr/tracker/?group_id=1299] to MantisBugsHarvested in the wiki, etc. ** Send a email to the mailing list. Congratulations, the world is one step closer to being a better place! We greately appreciate your effort. In case of problems, you can send a changeset to the mailing list, but please only do this as a last resort.

5 18

Re: [Pharo-project] About on:
by Bill Schwab June 5, 2008

June 5, 2008

Adrian, All external code would need to be adapted. 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 >>> adi(a)netstyle.ch 06/05/08 2:52 AM >>> On Jun 5, 2008, at 00:27 , Bill Schwab wrote: > Stef, Damien, > > No surprise, I would argue that we proceed, and would also include a > rename of #next to #nextOrNil and #next: to #nextAvailable:. All > code in the image at the time should work as before. What would be the impact on code that is not in the image? Would all external packages need to be adapted as well or would the current semantics be preserved? Adrian > The next step (part B) would be to add exception-aware #next and > #next:. > > Damien and I could cook it up, try it, and then return with an "all > clear." > > 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 6/4/2008 10:36 AM >>> > > On Jun 4, 2008, at 5:20 PM, Damien Cassou wrote: > >> On Wed, Jun 4, 2008 at 1:45 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> here is what I propose for on: >>> I will move your package out of the inbox so that the discussion >>> can go on >>> and >>> I try to integrate all the other changes. >>> Then with bill and others you propose how to proceed. >>> Is it ok ? >> >> What do you mean by 'I will move your package out of the inbox'? Do >> you mean you simply delete the packages or you moved them to Pharo? > > I mean move them to the treatedBox without putting in the image > >> Replacing 'ReadStream on: smth' by 'smth readStream' is not >> mandatory. >> However, it makes the code simpler to read, avoids a direct class >> reference and allows different implementation of #readStream >> depending >> on the kind of collection it is sent to. I do not think anyone is >> against that as soon as I apply the automatic refactoring >> carefully. I >> did that and didn't see any place where the RB did a bad job. It even >> detected that SequenceableCollection>>readStream should not be >> changed >> to avoid infinite recursion. >> >> Do you think there is a problem that I might take care of? > > Now as a group how do we want to handle this case? > We give a try and trust damien? > > Stef > > >> >> >> >> -- >> 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) >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] About on:
by Bill Schwab June 5, 2008

June 5, 2008

Stef, Damien, No surprise, I would argue that we proceed, and would also include a rename of #next to #nextOrNil and #next: to #nextAvailable:. All code in the image at the time should work as before. The next step (part B) would be to add exception-aware #next and #next:. Damien and I could cook it up, try it, and then return with an "all clear." 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 6/4/2008 10:36 AM >>> On Jun 4, 2008, at 5:20 PM, Damien Cassou wrote: > On Wed, Jun 4, 2008 at 1:45 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> here is what I propose for on: >> I will move your package out of the inbox so that the discussion >> can go on >> and >> I try to integrate all the other changes. >> Then with bill and others you propose how to proceed. >> Is it ok ? > > What do you mean by 'I will move your package out of the inbox'? Do > you mean you simply delete the packages or you moved them to Pharo? I mean move them to the treatedBox without putting in the image > Replacing 'ReadStream on: smth' by 'smth readStream' is not mandatory. > However, it makes the code simpler to read, avoids a direct class > reference and allows different implementation of #readStream depending > on the kind of collection it is sent to. I do not think anyone is > against that as soon as I apply the automatic refactoring carefully. I > did that and didn't see any place where the RB did a bad job. It even > detected that SequenceableCollection>>readStream should not be changed > to avoid infinite recursion. > > Do you think there is a problem that I might take care of? Now as a group how do we want to handle this case? We give a try and trust damien? Stef > > > > -- > 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) > > _______________________________________________ > 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

4 4

Re: [Pharo-project] About readStream on: vs readStream
by Bill Schwab June 4, 2008

June 4, 2008

Stef, FWIW, I consider it to be negotiable, provided we can use ReadStream as a factory/facade for Nile classes. With some double-dispatch, I think we could end up with something similar to directories: code references the generic class and the system instantiates platform-specific subclasses. In Nile, ReadStream on:aStream would answer a Nile read stream for the relevant collection species. That said, #readStream is a preferable idiom to #on:. My leaning would be to keep the latter and strongly encourage use of the former. 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 6/4/2008 1:36 PM >>> Hi damien I was wondering why you think that ReadStream on: anObject is worse than anObject readStream? Because you do not hardcode ReadStream? Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

June 4, 2008

Hi guys I harvested some fixes proposed: - file test cleaning - number parsing tests - nebraska cleaning I cleaned up the inbox. Tomorrow I will try to take a look at MVC step 1 :) Stef

1 0

June 4, 2008

> From: pharo-project-owner(a)lists.gforge.inria.fr > Date: June 3, 2008 6:43:05 AM CEDT > To: ducasse(a)iam.unibe.ch > Subject: About on: > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > > > From: stÃ©phane ducasse <ducasse(a)iam.unibe.ch> > Date: June 3, 2008 6:42:33 AM CEDT > To: An open mailing list to discuss any topics related to an open- > source Smalltalk <Pharo-project(a)lists.gforge.inria.fr> > Subject: About on: > > > Hi damien > > here is what I propose for on: > I will move your package out of the inbox so that the discussion can > go on and > I try to integrate all the other changes. > Then with bill and others you propose how to proceed. > Is it ok ? > > Stef > > >

2 2

June 4, 2008

Hi serge why did you remove testHex? BTW I did not receive your nice license agreement

2 4