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

[Pharo-project] Morphic Halos

by Rob Rothwell

So...how do I bring up a Morph's halo in Pharo now? Something between 10196 and 10201 made the Alt-click quit working...! Take care, Rob

Dec. 29, 2008

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

by Alexandre Bergel

Frankly speaking, I am left unconvinced that allowing argument to be writable will increase the quality of Pharo. Alexandre On 27 Dec 2008, at 13:31, David Pennell wrote: > Its handy to at least have the option of making args writable in > order to support implementing languages like Javascript on top of > the bytecode set. > > -david > > On Sat, Dec 27, 2008 at 8:43 AM, Yoshiki Ohshima <yoshiki(a)vpri.org> > wrote: > At Sat, 27 Dec 2008 00:24:02 -0800, > Vassili Bykov wrote: > > > > On Thu, Dec 25, 2008 at 7:32 PM, Yoshiki Ohshima > <yoshiki(a)vpri.org> wrote: > > > At Wed, 24 Dec 2008 11:11:16 +0100, > > > Michael Rueger wrote: > > >> > > >> What really is the convenience of modifying an argument? Having > not to > > >> think up another name? I never understood this argument > especially if > > >> you need to use the original value of the argument in several > places. > > > > > > If you can think of an argument as a "temp initialized by the > > > caller" (like C), that kind of unifies the args and temps and > would > > > reduce the implementation complexity. In *some cases* it would > reduce > > > the lines of code in the user land. > > > > Or alternatively one can think of a temp as an argument of an > invisible block, > > > > | foo | > > foo := 3. > > ... > > > > being a form of > > > > [:foo | ...] value: 3. > > If args are assignable, and yes you can unify methods and blocks. > > But I'm pretty much convinced that debugged context being > restartable (by making args readonly) is important in practice. > > -- Yoshiki > > _______________________________________________ > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 28, 2008

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

by Vassili Bykov

On Sat, Dec 27, 2008 at 6:43 AM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > But I'm pretty much convinced that debugged context being > restartable (by making args readonly) is important in practice. Yes, that's perhaps the most concrete argument (no pun intended). However, in the classic ST80-like architecture read-only arguments are not required for restarting, since the original argument values are also available on the sender context's stack. Cheers, --Vassili

Dec. 28, 2008

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

by Lukas Renggli

> Its handy to at least have the option of making args writable in order to > support implementing languages like Javascript on top of the bytecode set. Assigning to an argument is already possible on a bytecode level, this is the compiler that prevents you from doing so. The check is in TempVariableNode>>#assignmentCheck:at: and can safely be replaced with the following method: assignmentCheck: encoder at: location ^ -1 The other issues I mentioned in the original post are similarly hardcoded. They can all be implemented by removing unnecessary checks in the compiler or class-builder. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 27, 2008

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

by David Pennell

Its handy to at least have the option of making args writable in order to support implementing languages like Javascript on top of the bytecode set. -david On Sat, Dec 27, 2008 at 8:43 AM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > At Sat, 27 Dec 2008 00:24:02 -0800, > Vassili Bykov wrote: > > > > On Thu, Dec 25, 2008 at 7:32 PM, Yoshiki Ohshima <yoshiki(a)vpri.org> > wrote: > > > At Wed, 24 Dec 2008 11:11:16 +0100, > > > Michael Rueger wrote: > > >> > > >> What really is the convenience of modifying an argument? Having not to > > >> think up another name? I never understood this argument especially if > > >> you need to use the original value of the argument in several places. > > > > > > If you can think of an argument as a "temp initialized by the > > > caller" (like C), that kind of unifies the args and temps and would > > > reduce the implementation complexity. In *some cases* it would reduce > > > the lines of code in the user land. > > > > Or alternatively one can think of a temp as an argument of an invisible > block, > > > > | foo | > > foo := 3. > > ... > > > > being a form of > > > > [:foo | ...] value: 3. > > If args are assignable, and yes you can unify methods and blocks. > > But I'm pretty much convinced that debugged context being > restartable (by making args readonly) is important in practice. > > -- Yoshiki > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 27, 2008

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

by Yoshiki Ohshima

At Sat, 27 Dec 2008 00:24:02 -0800, Vassili Bykov wrote: > > On Thu, Dec 25, 2008 at 7:32 PM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > > At Wed, 24 Dec 2008 11:11:16 +0100, > > Michael Rueger wrote: > >> > >> What really is the convenience of modifying an argument? Having not to > >> think up another name? I never understood this argument especially if > >> you need to use the original value of the argument in several places. > > > > If you can think of an argument as a "temp initialized by the > > caller" (like C), that kind of unifies the args and temps and would > > reduce the implementation complexity. In *some cases* it would reduce > > the lines of code in the user land. > > Or alternatively one can think of a temp as an argument of an invisible block, > > | foo | > foo := 3. > ... > > being a form of > > [:foo | ...] value: 3. If args are assignable, and yes you can unify methods and blocks. But I'm pretty much convinced that debugged context being restartable (by making args readonly) is important in practice. -- Yoshiki

Dec. 27, 2008

Re: [Pharo-project] Introducing Mars 0.1

by Esteban Lorenzano

On 2008-12-24 16:46:30 -0200, "Damien Pollet" <damien.pollet(a)gmail.com> said: > On Wed, Dec 24, 2008 at 19:43, Damien Pollet > <damien.pollet(a)gmail.com> wrote: >> PS. After re-reading Lukas's mails, Transcript and Workspace do work >> here too :) > > Actually, after implementing String class>>space, most windows worked ;) Lukas, Damien, Thanks for reporting this... I thought I wasn't using String space, but I found a place where I'm actually using it. It seems to not been supported on pharo, so I changed it to a "Character space asString" and now it shouldn't be a problem. Cheers, Esteban

Dec. 27, 2008

Re: [Pharo-project] Introducing Mars 0.1

by Esteban Lorenzano

On 2008-12-22 14:04:10 -0200, Alexandre Bergel <alexandre(a)bergel.eu> said: >>> What is the size of Mars? >> Currently is very small, but I really don't know how to messure > >> this... >> there is a method counter or something around? > > When I print this: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=- > | marsClasses methods sizeOfAllMethods | > marsClasses := Smalltalk allClasses select: [:cls | '*Mars*' match: > > cls category]. > methods := marsClasses inject: Set new into: [:sum :cls | sum, cls > > methodDict values]. > sizeOfAllMethods := methods inject: 0 into: [:sum :cm | sum + cm size]. > { marsClasses size . methods size . sizeOfAllMethods } > -=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > I have: #(76 661 24663) 24kb is not so much, isn't? > > The weight of all the mars methods is 24Kb. I do not know what is the > > impact on the overall pharo image although (anyone has an idea?). > > The size of bundle is 92Kb according to the mac finder. > >>> How did you get multiple windows :) >> They are just cocoa windows, created each time one is needed >> >>> Are call back from cocoa handled? > > doing a print on "10 + 20" prints "nil" Are you selecting "10 + 20" before printing it? currently it does not work as expected: executing print-it (or any command) at the end of line performs the line. I'm working on that now (bah... I'm working on using OTWorkspace instead current workspace, and that should solve this minimal problems) Btw... "doit" inside a class method is not working properly either. Next release will solve this execution problems. > > It looks really good! Thanks, is great you like it :) Cheers, Esteban

Dec. 27, 2008

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

by Esteban Lorenzano

Just for the record, Java compiler enforces code conventions like uppercases and so... but is configurable, usually you get a warning. You can change compiler configuration so it can throw an exception and you can tell him to ignore it (wich is what I do allways before starting a project, not because I break the rules, just because I hate to see the compiler telling me about other packages who break them... all the time) IMHO, Lukas is right, it is not a problem of the compiler, but Lint... but if others prefer the compiler to do such tasks, I think java approach is not so bad: having three states configuration and defaulting them to warning (no error). Cheers, Esteban On 2008-12-24 12:13:56 -0200, Alexandre Bergel <alexandre(a)bergel.eu> said: > I do not think that a preference should relax some static language > > enforcements. > Contrary to Java, the Smalltalk community does not appear to be big > > enough to have these problem unsolvable. > > I agree with Stephane, having a name that begins with a capitalized > > letter has a strong connotation of global visibility. And, on the > > contrary, an identifier beginning with a small letter has a restricted > > scope. > > Forbidding a new value to be assigned to a method variable is a simple > > increase the readability. Even if closure were supported, we should > > not allow a single identifier to appear as argument in different > > blocks in the same method. This does not help readability. > > As a follower to that line, something that would be great to have, is > > to forbid accesses to an undefined variable. > > I am aware that I am talking as someone who does not maintain cross- > > dialect applications, but we cannot trade readability for a local in > > time commodity. > > Alexandre > > > On 23 Dec 2008, at 18:02, StÃ©phane Ducasse wrote: > >> 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 >>> >> >> >> _______________________________________________ >> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 27, 2008

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

by Vassili Bykov

On Thu, Dec 25, 2008 at 7:32 PM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > At Wed, 24 Dec 2008 11:11:16 +0100, > Michael Rueger wrote: >> >> What really is the convenience of modifying an argument? Having not to >> think up another name? I never understood this argument especially if >> you need to use the original value of the argument in several places. > > If you can think of an argument as a "temp initialized by the > caller" (like C), that kind of unifies the args and temps and would > reduce the implementation complexity. In *some cases* it would reduce > the lines of code in the user land. Or alternatively one can think of a temp as an argument of an invisible block, | foo | foo := 3. ... being a form of [:foo | ...] value: 3. --Vassili

Dec. 27, 2008