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

[Pharo-project] there is a sixx left over in Object
by StÃ©phane Ducasse Dec. 23, 2008

Dec. 23, 2008

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

3 5

[Pharo-project] Vocabulary
by Damien Cassou Dec. 23, 2008

Dec. 23, 2008

OBClassAwareNode>>allCategories depends on the class Vocabulary which does not seem to be present anymore. -- Damien Cassou http://damiencassou.seasidehosting.st

3 5

[Pharo-project] A process question
by StÃ©phane Ducasse Dec. 23, 2008

Dec. 23, 2008

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:

1 0

Re: [Pharo-project] On not unnecessarily closing down the language
by Bill Schwab Dec. 23, 2008

Dec. 23, 2008

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

1 0

Re: [Pharo-project] New pharo-dev based on 10196
by Bill Schwab Dec. 23, 2008

Dec. 23, 2008

Damien, Thanks for making the new image. Is there a way to tell the image to display walkbacks instead of going straight into the debugger? The new image seemed a nice excuse to play catch-up, which means getting a few things loaded. Seaside - I recalled discussion of it, and quckly stumbled onto a closed bug report about ScriptLoader new universalInstaller universe install: 'Seaside'. That appears to work. The cryptography team's work will be important. This gets weird fast. I have a 3.9 image where it is installed correctly and works; I have very little idea how that happened. My subsequent installation attempts appear not to be complete. SqueakMap appears to be going away in Pharo. Replacing it appear to be Installer, ScriptLoader, and maybe some of your tools to build the developer images. Is there a clear correct way to install packages now? Put another way, if I make an attempt to sort out installing the cryptography and SSL classes in Pharo, how would recommend attacking it? Pharo is not even in beta yet, so no complaints, but I am missing something on how to go from a new core image to something that is ready for use. 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

6 11

[Pharo-project] Inclusion of OB-Tools inside Pharo
by Damien Cassou Dec. 22, 2008

Dec. 22, 2008

On Sun, Dec 21, 2008 at 11:44 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Sounds good. And in that case (OB Tools at the end of the list), I urge > serious attention to having a notifier. Learning from history, and all > that. Hi Bill, I decided to load OB-Tools (a reimplementation of some tools using the ob framework) inside the pharo-dev images. I put OB-Tools inside the list of packages that will be part of the official Pharo distribution. This was a mistake because no discussion happened about this package at all on this mailing list. I've just moved OB-Tools to the list of pending packages. Now, we have to discuss (in this new thread): - Do we want an OB-based version of the tools inside Pharo? - Do we want all tools implemented by Lukas or just some of them? - What features are missing? - What are the bugs? - Who maintains this package? -- Damien Cassou http://damiencassou.seasidehosting.st

4 3

Re: [Pharo-project] Universes and Installer?
by Bill Schwab Dec. 22, 2008

Dec. 22, 2008

Stef, That explains a lot. The Seaside installation was/is helpful, but otherwise I will try to forget it exists. 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 >>> stephane.ducasse(a)inria.fr 12/22/08 1:47 PM >>> Scriptloader is our internal code to publish release. It is not for public consumption. It works well but only for us. For the rest we should Installer and I'm waiting damien to write some text on Sake and Packages so that I finally understand them. Stef On Dec 22, 2008, at 5:09 PM, Bill Schwab wrote: > It makes a lot of sense to use MC, universes, etc. rather than re- > write > them; no argument there. Would it help to roll ScriptLoader into > Installer? Installer _looks_ to me as though it tries to be a > much-needed facade over the various options for sharing code. The > problem is complex, so must be the solution, but I think it would help > to have a single entry point even if it is merely a facade. > > Bill > aka Confused Smalltalker :) > > > > > 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 > >>>> alexandre(a)bergel.eu 12/22/08 10:39 AM >>> > Works. Thanks! > > Alexandre > > > On 22 Dec 2008, at 12:26, Damien Cassou wrote: > >> On Mon, Dec 22, 2008 at 4:18 PM, Alexandre Bergel >> <Alexandre.Bergel(a)inria.fr> wrote: >>> If I execute "Installer universe" in a workspace, an error >>> "Universes >>> code not present" is signaled . >>> Does this mean that only a subset of Installer is present in Pharo- >>> Core? >> >> >> No, you have the complete Installer package. However, Installer needs >> some back-ends. Depending on what you want to, you will need >> SqueakMap, Monticello, Sake and Universes. >> >>> On the Installer squeaksource repository there is a package >>> Universes. >>> It looks like to be the right candidate. However, some extensions on >>> StringSocket need to be present. I do not know where to get them >>> from. >> >> You could use the dev images but I guess you won't do it. So, just >> execute: >> >> ScriptLoader new installingUniverse >> >>> http://www.squeaksource.com/Installer.html does not say much on >>> this. >>> Keith? Do I miss something? >> >> >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> _______________________________________________ >> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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

[Pharo-project] Issues 142 & 144
by HernÃ¡n Morales Durand Dec. 22, 2008

Dec. 22, 2008

http://code.google.com/p/pharo/issues/detail?id=142 http://code.google.com/p/pharo/issues/detail?id=144

2 2

[Pharo-project] Issue tracker & dev images
by Michael Roberts Dec. 22, 2008

Dec. 22, 2008

folks, I was looking at issue 364 which is a bug in the pharo-dev image. Have we defined what the bug process is for the dev image vs the core? I wasn't sure. I.e are we happy to collate both on the one tracker; do we have appropriate types; is it not expected; etc. thanks Mike

5 5

Re: [Pharo-project] Universes and Installer?
by Bill Schwab Dec. 22, 2008

Dec. 22, 2008

It makes a lot of sense to use MC, universes, etc. rather than re-write them; no argument there. Would it help to roll ScriptLoader into Installer? Installer _looks_ to me as though it tries to be a much-needed facade over the various options for sharing code. The problem is complex, so must be the solution, but I think it would help to have a single entry point even if it is merely a facade. Bill aka Confused Smalltalker :) 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 >>> alexandre(a)bergel.eu 12/22/08 10:39 AM >>> Works. Thanks! Alexandre On 22 Dec 2008, at 12:26, Damien Cassou wrote: > On Mon, Dec 22, 2008 at 4:18 PM, Alexandre Bergel > <Alexandre.Bergel(a)inria.fr> wrote: >> If I execute "Installer universe" in a workspace, an error "Universes >> code not present" is signaled . >> Does this mean that only a subset of Installer is present in Pharo- >> Core? > > > No, you have the complete Installer package. However, Installer needs > some back-ends. Depending on what you want to, you will need > SqueakMap, Monticello, Sake and Universes. > >> On the Installer squeaksource repository there is a package >> Universes. >> It looks like to be the right candidate. However, some extensions on >> StringSocket need to be present. I do not know where to get them >> from. > > You could use the dev images but I guess you won't do it. So, just > execute: > > ScriptLoader new installingUniverse > >> http://www.squeaksource.com/Installer.html does not say much on this. >> Keith? Do I miss something? > > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

4 3