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

[Pharo-project] A process question

by StÃ©phane Ducasse

Hi all I'm looking at all the things I did not treat when removing etoy. I kept a list for myself at: http://code.google.com/p/pharo/wiki/CurrentlyWorkingOn Now I imagine that nobody really cares or reads this page and I was thinking that I could add a entry for the methods that need to be checked and potentially cleaned or removed. What do you think. I would like to do that because some methods are not easy to treat Here is a first list. Stef Object (to fix later so far) â¢ presenter â¢ currentVocabulary â¢ defaultNameStemForInstances â¢ externalName â¢ nameForViewer â¢ objectRepresented Morph (to fix later so far) â¢ actorState â¢ actorState: anActorState â¢ allMorphsAndBookPagesInto: â¢ asNumber: aPointOrNumber -- would like to avoid to destroy graphMorph â¢ assureExternalName â¢ assuredPlayer â¢ balloonText â¢ convertAugust1998: varDict using: smartRefStrm â¢ convertNovember2000DropShadow:using: â¢ cursor â¢ cursor: â¢ decimalPlacesForGetter: aGetter (seems to be really etoy related) â¢ defaultFloatPrecisionFor: (seems to be really etoy related) â¢ defaultValueOrNil (seems to be really a hack and etoyish) â¢ forwardDirection: newDirection â¢ getNumericValue â¢ getCharacters â¢ heading â¢ heading: newHeading â¢ holdsSeparateDataForEachInstance â¢ noteDecimalPlaces: aNumber forGetter: aGetter â¢ playSoundNamed: soundName â¢ player â¢ presenter â¢ standardPalette PasteUpMorph? (to fix later so far) â¢ toggleAutoLineLayout â¢ getCharacters â¢ buildDebugMenu:

Dec. 23, 2008

[Pharo-project] there is a sixx left over in Object

by StÃ©phane Ducasse

sixxInstVarNamed: instVarName put: aValue "override if you like" self instVarAt: (self class instVarIndexFor: instVarName asString) put: aValue Does anybody know where is come from?

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

lukas would a preference help? Stef On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote: > Seaside depends on external packages, that we don't have control over. > > For example there the Swazoo package contains a class-instance > variable that is uppercase. Unfortunately Pharo throws a notification > (instance variables should begin with a lower case characters) when > loading that code. This is awkward, because it makes it impossible to > load code automatically and gives us additional work. > > In my opinion a programming language should be as open as possible, > and if possible not restrict the user in any way, even if this is > against best practices. Unfortunately many of those restrictions are > built into our language that wouldn't be necessary: > > - class names and class-variable names are enforced to be uppercase > - class instance-variable names are enforced to be lowercase > - it is not possible to assign a new value to a method argument > - variable names are enforced to be unique in all scopes > > In my opinion the language should be as open as possible. It is the > purpose of Code Critics to point out smells, not the task of the > compiler to reject code that doesn't follow best practices. > > I am slightly frustrated trying to work around these restrictions ... > > 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 >

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote: > Seaside depends on external packages, that we don't have control over. > > For example there the Swazoo package contains a class-instance > variable that is uppercase. Can you tell me which one so that I ask Janko to fix it? > Unfortunately Pharo throws a notification > (instance variables should begin with a lower case characters) when > loading that code. May be we should have a way to trap that exception. > This is awkward, because it makes it impossible to > load code automatically and gives us additional work. > > In my opinion a programming language should be as open as possible, > and if possible not restrict the user in any way, even if this is > against best practices. Unfortunately many of those restrictions are > built into our language that wouldn't be necessary: > > - class names and class-variable names are enforced to be uppercase > - class instance-variable names are enforced to be lowercase I really think that this is good. Else what is the point to have a syntax? > - it is not possible to assign a new value to a method argument This was always like that in Smalltalk. Arguments are ready only. > - variable names are enforced to be unique in all scopes This is the limit of the current compiler and not having full block closure I imagine. > In my opinion the language should be as open as possible. No it should follow well specified rules. Else this is the mess. In Smalltalk uppercase are for global variables and lowercase for private. Class instance variables are only accessible from the metaclass methods so they should be lowercase. Now if a lousy compiler allows them this is the problem. > It is the > purpose of Code Critics to point out smells, not the task of the > compiler to reject code that doesn't follow best practices. > > I am slightly frustrated trying to work around these restrictions ... > > 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 >

Dec. 23, 2008

Re: [Pharo-project] Pharo image builds (was Re: Notifiers)

by StÃ©phane Ducasse

yes On Dec 23, 2008, at 6:28 PM, Michael Roberts wrote: > If i'm right in thinking Damien's Pharo-Dev images are early release > candidates going forwards for the Pharo image, without the one-click, > would it make sense to start naming them Pharo. i.e. drop the -Dev. > That way we could start to get consistent with our naming, get the > web documentation consistent etc. thoughts? > > cheers, > > Mike > > On Sun, Dec 21, 2008 at 10:31 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> Here is an answer for "what is Pharo?" >> >> There will be two images: >> "Pharo-Core": the image in which the development of Pharo takes place >> "Pharo": the image to develop your application with (= "Pharo-Core" + >> IDE tools [1]) >> >> "Pharo" is the image that will be officially shipped (packaged as a >> one-click image). "Pharo-Core" on the other hand will be important >> for >> deployment as it has a low memory footprint. >> >> Cheers, >> Adrian >> >> [1] http://code.google.com/p/pharo/wiki/Packages >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2008

Re: [Pharo-project] Vocabulary

by StÃ©phane Ducasse

Excellent! Did you check whether other parts used Vocabulary? Thanks. On Dec 23, 2008, at 3:02 PM, David RÃ¶thlisberger wrote: > >> OBClassAwareNode>>allCategories depends on the class Vocabulary which >> does not seem to be present anymore. > > ok, I fixed this method to not use Vocabulary anymore. (OB-Standard- > dr.383) > > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2008

Re: [Pharo-project] Gepetto2 and Pharo

by Alexandre Bergel

Hi Marcus, When I run in Pharo the 133 tests of Gepetto2, I have 119 passes, 6 expected failures, 2 failures, and 6 errors. Is there something in Pharo that would prevent Gepetto2 from running correctly ? Alexandre On 23 Dec 2008, at 15:31, Alexandre Bergel wrote: > Hi Marcus, > > Do you know whether Gepetto2 is know to work on Pharo? I am trying > to make Christo (the code coverage tool) run on Pharo. > > (I ask for it publicly since someone else than Marcus may know). > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Bill Schwab

Lukas, I'm largely on board, but have a couple of concerns, followed by an addition: --- it is not possible to assign a new value to a method argument Doing that strikes me as an accident waiting to happen. What is limited by the restriction? The workaround that comes to mind is to pass around a value holder, which is a nice red flag to anyone reading the code that "out-parameters" are likely. Of course, one can also use instance variables or temporaries (local only) to overcome most problems where the restriction has bothered me (and IMHO, saved me from doing something unintended). --- variable names are enforced to be unique in all scopes To which I say, "thanks for the help!!" What is the down side of this? Or are you asking for name spaces and disambiguation? But I would argue that the latter is changing the language, not making the compiler less suspicious. My addition: give me back my underscores :) *---"In my opinion the language should be as open as possible." I really can't agree here. It is one thing to avoid enforcing aesthetics; it is another thing to accept ambiguous input. 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) 273-6785 FAX: (352) 392-7029 >>> renggli(a)gmail.com 12/23/2008 9:41:01 AM >>> Seaside depends on external packages, that we don't have control over. For example there the Swazoo package contains a class-instance variable that is uppercase. Unfortunately Pharo throws a notification (instance variables should begin with a lower case characters) when loading that code. This is awkward, because it makes it impossible to load code automatically and gives us additional work. In my opinion a programming language should be as open as possible, and if possible not restrict the user in any way, even if this is against best practices. Unfortunately many of those restrictions are built into our language that wouldn't be necessary: - class names and class-variable names are enforced to be uppercase - class instance-variable names are enforced to be lowercase - it is not possible to assign a new value to a method argument - variable names are enforced to be unique in all scopes In my opinion the language should be as open as possible. It is the purpose of Code Critics to point out smells, not the task of the compiler to reject code that doesn't follow best practices. I am slightly frustrated trying to work around these restrictions ... 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

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Jim Menard

+1 Jim -- Jim Menard, jimm(a)io.com, jim.menard(a)gmail.com http://www.io.com/~jimm/

Dec. 23, 2008

[Pharo-project] Gepetto2 and Pharo

by Alexandre Bergel

Hi Marcus, Do you know whether Gepetto2 is know to work on Pharo? I am trying to make Christo (the code coverage tool) run on Pharo. (I ask for it publicly since someone else than Marcus may know). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 23, 2008