- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] About on:

by Lukas Renggli

> 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

June 5, 2008

Re: [Pharo-project] Most active

by Serge Stinckwich

2008/6/5 Damien Cassou <damien.cassou(a)gmail.com>: > Pharo is the 4th most active project in gforge and it appears in the > front page. Pharo is also the most active SqueakSource project. This is the INRIA gforge ;-) and the most active project on SqueakSource seems to be broken ... -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/

June 5, 2008

Re: [Pharo-project] Most active

by Alexandre Bergel

This is an excellent news :-) Alexandre On 5 Jun 2008, at 17:06, Damien Cassou wrote: > Pharo is the 4th most active project in gforge and it appears in the > front page. Pharo is also the most active SqueakSource project. > > -- > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 5, 2008

[Pharo-project] Most active

by Damien Cassou

Pharo is the 4th most active project in gforge and it appears in the front page. Pharo is also the most active SqueakSource project. -- 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)

June 5, 2008

Re: [Pharo-project] About on:

by StÃ©phane Ducasse

ANSI is a standard and there are cases where it is wrong (commitee decisions = compromise) 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 >

June 5, 2008

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

by StÃ©phane Ducasse

alain you should pay attention that you shoudl deprecate the method. People should be able to load their code in pharo On Jun 5, 2008, at 1:52 PM, Alain Plantec wrote: > 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 for now I'm not sure that I would focus on that. I would clean really the ugly part and etoy. 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] About on:

by Bill Schwab

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

June 5, 2008