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

[Pharo-project] Hunting down nebraska
by Norbert Hartl June 5, 2008

June 5, 2008

Last time I chased obsolete classes and I found a nebraska category in PasteUpMorph. Now I did a search over all classes if there are more nebraska categories. And there were a lot. Most of them were empty. Even the category I removed myself. Is it true that Monticello isn't able to delete method categories? I attach a changeset that removes the method categories because with a changeset it works. Or did I something wrong? After removing the empty ones there are still two left. 1.) Canvas->Nebraska/embeddedWorlds containing a method transform2By: clippingTo: during: smoothing: A flag is indicating that this is added to Canvas for nebraska to work. The right method seems to be ï»¿transform2By: clippingTo: during: smoothing: (no 2 after transform) However this method is referenced from to places: BOBTransformationMorph>>drawSubmorphsOnREAL: and TransformationB2Morph>>drawSubmorphsOn: Is anybody familiar with those morphs. It appears that the method can be substituted by the original method but I'm not sure. 2.) SketchEditorMorph->Nebraska support All those methods don't seem to be rippable from the class as they are interwoven with all other methods. Maybe a re- categorization will do. Any ideas? Norbert

1 0

[Pharo-project] MVC removing step2: your point of view
by Alain Plantec June 5, 2008

June 5, 2008

Hi all, I'm cleaning some methods which contain 'AsMorph'. for example, Browser>>openAsMorphMessageEditing: is send only in Browser>>openMessageEditString: which only returns openAsMorphMessageEditing: result. so, I copy code from Browser>>openAsMorphMessageEditing: to Browser>>openMessageEditString: and remove Browser>>openAsMorphMessageEditing:. I guess this is ok. But now I'm continuing by chasing all methods with 'InMorphic' in their name. As an example, there is Morph>>embeddedInMorphicWindowLabeled:. the question is, do I make the asumption that morphic is the only way or the default (then Morph>>embeddedInMorphicWindowLabeled: can be renamed as Morph>>embeddedInWindowLabeled:) or do I let it as is ? the same would be applied to openInMorphic (->open), inspectModelInMorphic (->inspectModel), inspectInMorphic: (->inspect:), inspectInMorphic (->removed because no sender), thanks alain

3 3

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

June 5, 2008

Lukas, I have blind copied someone who can comment, or not at his discretion, on Cincom's view on this; he never said he was commenting off the record, but I try to err toward assuming that. I got the distinct sense that they are contemplating a change of some type and are also struggling with backward compatibility. You are correct about ANSI; I was shocked to see what they did. Without reservation, I assert the standard is wrong. Exception handling was created to allow the widespread elimination of precisely the condition that arises when #next reads off the end of a stream. I can always (and probably will if we do not fix this) deprecate #next and #next: in my own work, but that still leaves inconsistencies between and within 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 >>> renggli(a)gmail.com 6/5/2008 7:18 AM >>> > > Yes, but it is not consistent, and they are apparently not happy with it. Why? Can you give any pointers? > 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. As far as I see this is inconsistent with the ANSI standard. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 2

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