January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About moving tmp closer their use

by StÃ©phane Ducasse

On Jan 4, 2010, at 2:05 PM, Peter Hugosson-Miller wrote: > I remember the first time I ever tried Squeak all those years ago, this was the first thing that bit me - not being able to declare temporary variables within the blocks that use them. I was so used to doing that from VisualAge. Me too :) Stef > > So, I vote in favour of the change :-) > > On Mon, Jan 4, 2010 at 1:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > My own preference is a balance between being readable and efficient. > At first, i care above anything to make my code readable. > And I think that, being properly formatted, declaring temps in blocks > scope not makes code less readable. > Also, i think that keeping variables close to desired scope, will > instead could help improving code readability. > > But i must say, we should learn & teach developers to write code short > & consise, or at least attempt to (following a well known smalltalk > practice - 1/2 lines per method). > Then we wouldn't need to choose, what way of declaring temps is better ;) > > > 2010/1/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > Hi guys > > > > in squeak a week ago nicolas pushed a cool (from my taste) changes that refactored the complete > > system so that |temp| declaration would be at the scope where they are used. > > This is not clear that this is an optimisation but I like the fact that temp > > are defined at the right place. > > Now it may lead to code that is a bit less readable in the sense that your temps > > are not systematically listed at the beginning of the method but occasionally in the closures > > that use them. > > From my hackish lisping state of mind I like it now what do you prefer? > > > > Stef > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Cheers, > Peter > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 4, 2010

Re: [Pharo-project] Can't use <Enter> key to select notifier action

by StÃ©phane Ducasse

You are the boss for that. Let us know. On Jan 4, 2010, at 2:26 PM, Gary Chambers wrote: > Sorry for delay, away for xmas! > > Having played around with a few OSes perhaps we should allow the enter key when a button has keyboard focus. For dialogs, where no button has keyboard focus, the default button should be activated (barring any specifc use of enter in the morph that has keyboard focus). > > Regards, Gary > ----- Original Message ----- > From: Mariano Martinez Peck > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Sunday, December 20, 2009 5:40 PM > Subject: Re: [Pharo-project] Can't use <Enter> key to select notifier action > > > > 2009/12/20 danklein <danielk(a)danielk.us> > When a notifier pops up, you can tab (or shift-tab) to the Proceed/Abandon/Debug/Create buttons at the top of the window. However, when the one you want is highlighted, I would like to be able to just press the to execute it, but you have to actually click on it. Is there a configuration setting to affect this behavior? > > It works with the space key, but not to the enter key. I remember a similar "issue" that Gary solve. It let us use the enter key instead of the space key in some cases, for example when you save a method with an undeclared variable and it gives you the options....I couldn't find it in my mails.... > > gary do you remember ? > > Cheers, > > Mariano > > > View this message in context: Can't use key to select notifier action > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > 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

Jan. 4, 2010

Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))

by Henrik Johansen

On Jan 4, 2010, at 2:45 57AM, Levente Uzonyi wrote: > On Wed, 30 Dec 2009, StÃ©phane Ducasse wrote: > >> BIG THANKS igor!!! >> >> 11127 >> ----- >> >> - Issue 1690: New Method Trailer part 7 (cs 9) > > There are still some issues. Some methods (for example TPureBehavior >> #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.) > > > Levente CompiledMethod>>storeOn: also needs to be updated, (Compiler evaluate: aCompiledMethod storeString) does not reconstruct the original trailer. Caught by ArrayTest >> testComplexIsSelfEvaluating, of all places :) Cheers, Henry

Jan. 4, 2010

Re: [Pharo-project] Can't use <Enter> key to select notifier action

by Gary Chambers

Sorry for delay, away for xmas! Having played around with a few OSes perhaps we should allow the enter key when a button has keyboard focus. For dialogs, where no button has keyboard focus, the default button should be activated (barring any specifc use of enter in the morph that has keyboard focus). Regards, Gary ----- Original Message ----- From: Mariano Martinez Peck To: Pharo-project(a)lists.gforge.inria.fr Sent: Sunday, December 20, 2009 5:40 PM Subject: Re: [Pharo-project] Can't use <Enter> key to select notifier action 2009/12/20 danklein <danielk(a)danielk.us> When a notifier pops up, you can tab (or shift-tab) to the Proceed/Abandon/Debug/Create buttons at the top of the window. However, when the one you want is highlighted, I would like to be able to just press the to execute it, but you have to actually click on it. Is there a configuration setting to affect this behavior? ---------------------------------------------------------------------------- It works with the space key, but not to the enter key. I remember a similar "issue" that Gary solve. It let us use the enter key instead of the space key in some cases, for example when you save a method with an undeclared variable and it gives you the options....I couldn't find it in my mails.... gary do you remember ? Cheers, Mariano View this message in context: Can't use key to select notifier action Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ 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

Jan. 4, 2010

Re: [Pharo-project] About moving tmp closer their use

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > Hi guys > > in squeak a week ago nicolas pushed a cool (from my taste) changes that refactored the complete > system so that |temp| declaration would be at the scope where they are used. > This is not clear that this is an optimisation but I like the fact that temp > are defined at the right place. > Now it may lead to code that is a bit less readable in the sense that your temps > are not systematically listed at the beginning of the method but occasionally in the closures > that use them. > >From my hackish lisping state of mind I like it now what do you prefer? > Yes, I always prefer to see variable declarations in the scope where they are used Alain > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Jan. 4, 2010

Re: [Pharo-project] About moving tmp closer their use

by Peter Hugosson-Miller

I remember the first time I ever tried Squeak all those years ago, this was the first thing that bit me - not being able to declare temporary variables within the blocks that use them. I was so used to doing that from VisualAge. So, I vote in favour of the change :-) On Mon, Jan 4, 2010 at 1:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > My own preference is a balance between being readable and efficient. > At first, i care above anything to make my code readable. > And I think that, being properly formatted, declaring temps in blocks > scope not makes code less readable. > Also, i think that keeping variables close to desired scope, will > instead could help improving code readability. > > But i must say, we should learn & teach developers to write code short > & consise, or at least attempt to (following a well known smalltalk > practice - 1/2 lines per method). > Then we wouldn't need to choose, what way of declaring temps is better ;) > > > 2010/1/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > Hi guys > > > > in squeak a week ago nicolas pushed a cool (from my taste) changes that > refactored the complete > > system so that |temp| declaration would be at the scope where they are > used. > > This is not clear that this is an optimisation but I like the fact that > temp > > are defined at the right place. > > Now it may lead to code that is a bit less readable in the sense that > your temps > > are not systematically listed at the beginning of the method but > occasionally in the closures > > that use them. > > From my hackish lisping state of mind I like it now what do you prefer? > > > > Stef > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Cheers, Peter

Jan. 4, 2010

Re: [Pharo-project] What about killing PharoWeb images?

by Mariano Martinez Peck

On Mon, Jan 4, 2010 at 2:01 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/1/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > > We certainly don't need the web images, but I would like to see them stay > to > > help with testing. If we are building them with unstable versions of > > Seaside, that is a problem with the process (loading the wrong stuff) not > > the concept/service (providing a Seaside-ready version of Pharo for > > testing). We just finished designing a beta program, at least three of > > volunteers indicated a preference for the web image. > > > > Bill > > 1. *We* (who sitting here for a while), certainly don't need web images. > 2. Newcomers, or entry-level youngsters, definitely will prefer a > ready-to-use solutions, which easy to install, run & play with. > > So, +1 for keeping web images. > But Igor, there is nothing easier than a double click. And seaside one click is just a double click no matter in what OS you are. They are MUCH more easier for new commers than a PharoWeb image where they have to download the VM, the sources and the image. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 4, 2010

Re: [Pharo-project] Does someone know why Nile is in Dev images?

by Mariano Martinez Peck

Ok... The good news is that this is a community :) Sometimes the community thinks as you do and sometimes not. This is life ;) I will put it in the ConfigurationOfPharo for the Dev then. Cheers Mariano 2010/1/3 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > Mariano, > > You _like_ the new inspector???? :) Can't stand it myself. If I want > that kind of view, I use the explorer. Selecting the standard toolset (so > far at least) makes it "go away," so I'm happy. One thing that I miss is > the diving inspector that started in VW (IIRC) and was ported to Dolphin. > > Nile causes me no trouble, and I am glad to see movement away from the > Squeak streams. We will not be able to rid ourselves of the latter w/o > elevating Nile to being a part of the system. Your point about putting it > in the core is well-taken, but I think having it in the dev/web images is a > good thing because it should help drive Moose and other groups to dev as > opposed to the core. Given our obvious need to test before releasing the > dev/web images, anything that promotes their use is helpful. > > Bill > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *On Behalf Of *Mariano > Martinez Peck > *Sent:* Sunday, January 03, 2010 7:03 AM > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] Does someone know why Nile is in Dev > images? > > Sorry Stef but I disagree. PLEASE don't misunderstand me. I know a lot of > very good people have worked and is still working in Nile project. So, I am > sure it is an excellent product. > > However, I don't think it should be in Dev image. Dev image is for > "Developers". So, we put tools like NewInspector, RoelTyper, E and > OCompletion, Refactoring, etc. But why Nile ? > > I am not agree this is neither a way to push Nile to be used. It is no > difference if you already have the code in the image or not, it is just one > click of difference (as you have the Nile-All). Even if it where the case, I > think it should be in Core image. The way to push a project to be used is > to write documentation, tutorials, show the benefits over other > implementations....and so on. > > If Moose use it, ok, put it as a dependency. Now you have a Metacello > configuration for Moose :) > I mean, in SqueakDBX we use FFI and we don't put in the image. Seaside uses > Slime and it is not in the image. > > Just my opinion. I hope no one feels offended. > > What others think about this ? > > Cheers > > Mariano > > On Sun, Jan 3, 2010 at 11:02 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Nile is in dev because it should be progressively use to replace existing >> streams. >> For example in Moose some important collection extensions depend on it. >> >> >> > Does another package of the dev image depends on Nile? If not, I don't >> understand why it is part of the dev image. I see it as any other external >> package but not a "dev tool" that should be included. >> > >> > Thanks >> > >> > Mariano >> > _______________________________________________ >> > 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 >

Jan. 4, 2010

Re: [Pharo-project] What about killing PharoWeb images?

by Igor Stasenko

2010/1/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > We certainly don't need the web images, but I would like to see them stay to > help with testing.Â If we are building them with unstable versions of > Seaside, that is a problem with the process (loading the wrong stuff) not > the concept/service (providing a Seaside-ready version of Pharo for > testing).Â Â We just finished designing a beta program, at least three of > volunteers indicated a preference for the web image. > > Bill 1. *We* (who sitting here for a while), certainly don't need web images. 2. Newcomers, or entry-level youngsters, definitely will prefer a ready-to-use solutions, which easy to install, run & play with. So, +1 for keeping web images. -- Best regards, Igor Stasenko AKA sig.

Jan. 4, 2010

Re: [Pharo-project] 64 bit images (was Re: [squeak-dev] The Trunk: Collections-dtl.268.mcz)

by StÃ©phane Ducasse

excellent On Jan 4, 2010, at 1:44 PM, Laval Jannik wrote: > Yes, but the changeset build the fix in SystemDictionary, > In a previous discussion, we decide to create an instance variable in SmalltalkImage and to put methods in SmalltalkImage too. > > Cheers, > Jannik > > On Jan 4, 2010, at 13:35 , StÃ©phane Ducasse wrote: > >> Jannik >> >> did you check the changeset in the mantis bug report? >> >> Stef >> On Jan 4, 2010, at 10:53 AM, Laval Jannik wrote: >> >>> Hi, >>> >>> I made a new version of the system-tracer (in attachment). >>> It works fine with the latest pharo version. >>> >>> For wordSize, we decide to create a instance variable in SmalltalkImage, which is initialized at startup. >>> The method initialPC is: >>> >>> --- >>> initialPC >>> "Answer the program counter for the receiver's first bytecode." >>> >>> ^ (self numLiterals + 1) * SmalltalkImage current wordSize + 1 >>> --- >>> >>> The fix will be integrated in Pharo soon. >>> It is also in attachment. >>> >>> <addWordSizeInSystemDictionary.1.cs><System-Tracing-forPharo.cs> >>> >>> Cheers >>> >>> On Jan 3, 2010, at 06:46 , John M McIntosh wrote: >>> >>>> Ok, well I was hoping that Laval Jannik would review the changes/solution in http://bugs.squeak.org/view.php?id=7430 >>>> then update his original System-Tracing.2forPharo3.cs Then test to confirm we can build a 64bit image from the current Pharo image >>>> >>>> >>>> On 2010-01-02, at 6:46 PM, David T. Lewis wrote: >>>> >>>>> John, one additional note. >>>>> >>>>> The SystemTracer changesets currently in circulation have an obsolete >>>>> implementation of SystemDictionary>>wordSize.The original 64-bit >>>>> Squeak used vmParameterAt: 27 for the VM to answer its word size, >>>>> but this was later changed to vmParameter at: 40. This is the reason >>>>> that the original "dist3" 64-bit image does not work on current VMs. >>>>> >>>>> You will want to revert #wordSize back to a current version >>>>> so that it uses vmParameter at: 40. >>>>> >>>>> This issue will go away when we implement the cached #wordSize fixes >>>>> discussed separately (http://bugs.squeak.org/view.php?id=7430) but >>>>> I wanted to mention it because I spotted the obsolete method in the >>>>> System-Tracing2forPharo.cs change set. >>>>> >>>> >>>> -- >>>> =========================================================================== >>>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>> =========================================================================== >>>> >>>> >>>> >>>> >>> >>> --- >>> Jannik Laval >>> --- >>> >>> _______________________________________________ >>> 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

Jan. 4, 2010