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

[Pharo-project] 2 new updates
by StÃ©phane Ducasse June 4, 2008

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

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

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

[Pharo-project] why removing testhex?
by StÃ©phane Ducasse June 4, 2008

June 4, 2008

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

2 4

[Pharo-project] EToys
by Gary Chambers June 4, 2008

June 4, 2008

Just joined the mailing list. Was wonderering if you/we were looking at removing EToys. I'd be happy to help with that (it cuts deep into Morphic so should lead to some simplification). A "patch up" package could be made, perhaps, to reintegrate EToys after loading. Regards, Gary.

5 14

Re: [Pharo-project] EToys
by Bill Schwab June 4, 2008

June 4, 2008

My hunch is that Stef is against loading it in its current state. Any well-factored and optional package should be welcome. I am thrilled to see Gary on board! 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 6/3/2008 10:50 AM >>> On Tue, Jun 3, 2008 at 5:47 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Tue, Jun 3, 2008 at 5:39 PM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >> Damien, >> >> I don't, particularly! Just wondering what the approach is here... quite >> happy to rip it out altogether (might get a bit zealous with it!). Early >> indications are that around 200 methods can be dropped from Morph alone! >> >> Will wait for the inbox to settle first before applying my investigations to >> Pahro though. > > I was asking the question to StÃ©phane who said: > > "No reload of Etoy (as its current state) is important else it will > reintroduce cruft" Now that I read again the sentence, I think it can have 2 different meanings: "No ! reload of etoy is important !" or "reload of etoy is not important" Which one is correct? Knowing Stef, I would vote for 2 but I thought he meant 1. -- 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

2 1

[Pharo-project] Tools-AlexandreBergel.83 adds a dependency to OmniBrowser
by Damien Cassou June 3, 2008

June 3, 2008

There is a reference to OB specific classes in Tools-AlexandreBergel.83. OB must not be part of pharo in my opinion. -- 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)

2 1

[Pharo-project] Missing development tools in Pharo
by Oscar Nierstrasz June 3, 2008

June 3, 2008

I am missing some things in Pharo, starting with the Refactoring Browser and the VB-regex package. I sympathize with the principle of keeping Pharo small, but it would be really nice if we had in the Squeak flap some buttons to load in much of this standard stuff. How hard would it be to do this? It will surely be needed for Pharo development itself, no? - on

2 2

Re: {Spam?} [Pharo-project] Some questions on how to help
by Bill Schwab June 2, 2008

June 2, 2008

Norbert, I have also noted the "return nil on error" in parsers, and (my current mission) streams. IMHO, these decisions were questionable before structured exception handling, and are all the more unfortunate now. My preference would be to create something like #readFrom:onError: and then re-write #readFrom: in terms of it, raising an error inside the block. Failing to do that risks intermittent downstream failures due to "unexpected" garbage values. I like my bad news early, and in context. Skipping to the end of your message, I am hopeful that Pharo will not suffer from Squeak's barriers to adoption of good code, but I cannot promise same. It is probably best to start small and ask up-front whether people want what you propose. I suspect you will find that good work will be included in Pharo. 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 >>> norbert(a)hartl.name 6/2/2008 2:28:15 PM >>> 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

[Pharo-project] Lots of modifications waiting in PharoInbox
by Serge Stinckwich June 2, 2008

June 2, 2008

There is now a lots of package modifications waiting in the inbox. Is Stef the only one to integrate the changes inside Pharo ? -- Serge Stinckwich http://blog.doesnotunderstand.org/

2 1

[Pharo-project] Fwd: New update
by StÃ©phane Ducasse June 2, 2008

June 2, 2008

> > > > 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 > > + obsolete references identified by norbert > > Stef > > >

1 0

[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

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

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

Re: [Pharo-project] Replacing 'ReadStream on smth:' by 'smth readStream'
by Bill Schwab June 1, 2008

June 1, 2008

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

2 1

[Pharo-project] [ANN][Pharo-dev] First release
by Damien Cassou June 1, 2008

June 1, 2008

Hi, I've published the first version of Pharo-dev. It is hosted on gforge as usual: https://gforge.inria.fr/frs/?group_id=1299. I will try to generate new pharo-dev images when I generate squeak-dev images if anyone is interested. Are you? Bye -- 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)

5 11

[Pharo-project] Resent messages?
by Bill Schwab June 1, 2008

June 1, 2008

Hello all, Did some messages get posted more than once? It beats losing them, but leaves me wondering whether it is my goofy email server or something about the list conversion. FWIW. 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

1 0

Re: [Pharo-project] new to pharo
by Alain Plantec June 1, 2008

June 1, 2008

On Saturday 31 May 2008 14:24:05 you wrote: > Alain, > > You have COMPLETELY missed the focus of my response; thanks for > objecting so we can clarify it. My point was that it is a great start > on explaining something that is indeed mysterious to many (including > myself!), and deserves to be built up into a Wiki page for future > reference vs. "lost" in an archived list. Excuse me, it seems that I have to improve my english alain > > Please continue questioning the experts, and document what they tell > you. We will have it right when the answer is a link to a page complete > with a FAQ. > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

1 0