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

Fwd: [Pharo-project] About on:

by StÃ©phane Ducasse

Begin forwarded message: > From: Alan Knight <knight(a)acm.org> > Date: June 6, 2008 2:05:34 PM CEDT > To: pharo-project-owner(a)lists.gforge.inria.fr > Cc: "Bill Schwab" <BSchwab(a)anest.ufl.edu> > Subject: Re: [Pharo-project] About on: > > I guess I'm a non-member and not allowed to post, but it'd probably > be good if you could forward this. > >> Um, I guess that'd be me, but I'm missing a bit of context here. I >> guess you're probably not talking about #on:, but about #next, >> which I had discussed earlier with Bill. >> >> I had glanced at the ANSI standard and it appeared to me that it >> left the behaviour undefined. I don't know if you could >> characterize that as "wrong". A bad idea, perhaps, but it can't be >> wrong because it doesn't say anything. >> >> With respect to next, what VisualWorks does is raise an EndOfStream >> exception which is a notification. If not caught, it proceeds with >> nil. I don't think this is a good idea, and would like to at least >> make it not common behaviour. But I can't see changing the >> behaviour that a read past end of stream results in a nil. That >> assumption is pretty deep in a lot of Smalltalk code, and I think >> (without checking) that it is what all the dialects except Dolphin >> do. >> >> I note that it's not necessary to avoid the use of next in your own >> code if you don't like the behaviour. Just use it in conjunction >> with an atEnd test. >> >> At 09:27 AM 6/5/2008, Bill Schwab wrote: >>> 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 >> >> -- >> Alan Knight [|], Engineering Manager, Cincom Smalltalk >> knight(a)acm.org >> aknight(a)cincom.com >> http://www.cincom.com/smalltalk > > -- > Alan Knight [|], Engineering Manager, Cincom Smalltalk > knight(a)acm.org > aknight(a)cincom.com > http://www.cincom.com/smalltalk

June 6, 2008

Re: [Pharo-project] Wiki pages moved to http://code.google.com/p/pharo/

by Serge Stinckwich

Some Wiki pages like : NoPopupsEverywhere could be move on the issue tracker i think. 2008/6/6 Victor Rodriguez <victorr(a)gmail.com>: > Hello all, > > I have "moved" all the wiki pages from the INRIA gforge wiki to the > google code one. I believe I got all the pages, but it won't hurt if > someone can double check, which will be very easy, because I left a > "wiki has moved" message in all moved pages. > > I did some very minor cleanup, mostly making sure lists and links > appear correctly, but most pages still need to be fixed. > > Please help cleaning up the new wiki! > > I suggest for us to be very aggressive on keeping the wiki in a good > shape. On second thought, make that *very very* aggresive :-). I > know it is a lot of work, but there is nothing worse than a messy > wiki. Conversely, nothing speaks better of an open source project > than a clean and useful wiki. > > Ã votre service, > > VÃctor RodrÃguez. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/

June 6, 2008

Re: [Pharo-project] Wiki pages moved to http://code.google.com/p/pharo/

by Serge Stinckwich

2008/6/6 Victor Rodriguez <victorr(a)gmail.com>: > Hello all, > > I have "moved" all the wiki pages from the INRIA gforge wiki to the > google code one. I believe I got all the pages, but it won't hurt if > someone can double check, which will be very easy, because I left a > "wiki has moved" message in all moved pages. > > I did some very minor cleanup, mostly making sure lists and links > appear correctly, but most pages still need to be fixed. > > Please help cleaning up the new wiki! > > I suggest for us to be very aggressive on keeping the wiki in a good > shape. On second thought, make that *very very* aggresive :-). I > know it is a lot of work, but there is nothing worse than a messy > wiki. Conversely, nothing speaks better of an open source project > than a clean and useful wiki. Yes you are right, we are trying to do the same on the french Squeak wiki : http://community.ofset.org/wiki/Squeak > Ã votre service, Merci Victor. -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/

June 6, 2008

[Pharo-project] Re: Wiki pages moved to http://code.google.com/p/pharo/

by Victor Rodriguez

On Thu, Jun 5, 2008 at 11:27 PM, Victor Rodriguez <victorr(a)gmail.com> wrote: ... > Please help cleaning up the new wiki! BTW, I forgot to mention that I couldnÂ´t fix the front page. Someone please do it, or take the leap of faith and make me an administrator. :-) Saludos, VÃctor RodrÃguez. > > I suggest for us to be very aggressive on keeping the wiki in a good > shape. On second thought, make that *very very* aggresive :-). I > know it is a lot of work, but there is nothing worse than a messy > wiki. Conversely, nothing speaks better of an open source project > than a clean and useful wiki. > > Ã votre service, > > VÃctor RodrÃguez. >

June 6, 2008

[Pharo-project] Wiki pages moved to http://code.google.com/p/pharo/

by Victor Rodriguez

Hello all, I have "moved" all the wiki pages from the INRIA gforge wiki to the google code one. I believe I got all the pages, but it won't hurt if someone can double check, which will be very easy, because I left a "wiki has moved" message in all moved pages. I did some very minor cleanup, mostly making sure lists and links appear correctly, but most pages still need to be fixed. Please help cleaning up the new wiki! I suggest for us to be very aggressive on keeping the wiki in a good shape. On second thought, make that *very very* aggresive :-). I know it is a lot of work, but there is nothing worse than a messy wiki. Conversely, nothing speaks better of an open source project than a clean and useful wiki. Ã votre service, VÃctor RodrÃguez.

June 6, 2008

Re: [Pharo-project] Most active

by Serge Stinckwich

2008/6/5 Lukas Renggli <renggli(a)gmail.com>: >> This is the INRIA gforge ;-) >> and the most active project on SqueakSource seems to be broken ... > > Could well be. Why do you think it is broken? The recently created and recently used projects list seems always the same since several days or have some illusion :-) -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/

June 5, 2008

Re: [Pharo-project] About on:

by Bill Schwab

Lukas, The changes I propose would be almost trivial for them to adopt, and might actually make their lives easier in targeting Dolphin, should they wish to do so. The current semantics are <candidMode>watered-down to the point of being pointless, all in the name of being backwardly compatible with something that was questionable even before the existence of tools for exceptions and handling of same</candidMode>. All arguments in favor of preserving current behavior have been based on backward compatibility - nothing on merits. It will be interesting to see what happens when it comes time to de-cruft morphic - *that* will break external code. I will grant you one thing though: if I were to choose between breaking old morphic code or Seaside, I would certainly keep Seaside going, though I suspect the Seaside developers would accomodate us in trying to align the dialects. All they would need to do is use a selector to match the semantics they have learned to accept. It is the first disk pack I would burn - well, maybe just after underscore assignment has been scorched down to the sub-atomic level :) I will probably end up taking some of my own advice. Once my code can move to Pharo[*], I will probably load it into a throw-away image, using the RB therein to rename selectors. The first step would be to get #next and #next: "out of the way," by naming them #nextOrNil and #nextAvailable: - that's what they do. Load my code, and then rename #next to #nextOne and #next: to #nextMany:. These methods would signal EndOfStreamError (new name) to steer clear of default actions. Filing out and loading the resulting code should allow me to safely avoid the (to me deprecated) #next and #next:. It is a shame though, as they are the natural selectors one would want to use. Some slips detection based on packages and/or developer name would help me catch myself should I revert. It is precisely the risk of using the simpler/misleading selectors that has me convinced the breaking change is needed. Failing that, I need to at least solve it for my own code, and I will of course make that available to all. [*] I assume that I will write Dolphin code to export something that Pharo can load. If any of you know of a good solution to that problem, please let me know. In case you are wondering why the renaming is all done in Pharo, it is because it hopefully does a better job of leaving formatting in tact - D5's version of the RB is fairly hostile in that regard. 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 11:10:07 AM >>> > ANSI is a standard and there are cases where it is wrong (commitee decisions > = compromise) I agree, however changing the behavior of #next means that we will not be able to develop Seaside on Pharo. Seaside takes great advantage that Squeak is ANSI compatible. Lukas > > On Jun 5, 2008, at 3:27 PM, Bill Schwab wrote: > > > > 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 > > > > _______________________________________________ > > 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 > -- 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

June 5, 2008

[Pharo-project] Hunting down nebraska

by Norbert Hartl

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

June 5, 2008

Re: [Pharo-project] MVC removing step2: your point of view

by Alain Plantec

On Thursday 5 June 2008 16:08:34 StÃ©phane Ducasse wrote: > alain > you should pay attention that you shoudl deprecate the method. ok, I'm aware of this > People should be able to load their code in pharo well but I don't know how to really remove mvc and keep backward compatibility even some method are kept as deprecated. > > ... > > the same would be applied to openInMorphic (->open), > > inspectModelInMorphic (->inspectModel), inspectInMorphic: (- > > >inspect:), inspectInMorphic (->removed because no sender), > > > > thanks > > for now I'm not sure that I would focus on that. > I would clean really the ugly part and etoy. ok, no problem, I can help gary on etoy now alain > > stef > > > > > alain > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > >

June 5, 2008

Re: [Pharo-project] Most active

by Lukas Renggli

> This is the INRIA gforge ;-) > and the most active project on SqueakSource seems to be broken ... Could well be. Why do you think it is broken? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

June 5, 2008