- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.1] #11241

by Lukas Renggli

Great! Adrian, is it possible to merge Issue 2102 into Pharo 1.0 too? I think it is important to have that fixed there too. Lukas On 3 March 2010 14:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 11241 > ----- > > - Issue 2102: Â Fix the fact that local temp can shadow silently instance var > - cleaning findChgSet > - fixing packageInfo typos overriden -> overridden > - Fix file = and added one test > > Stef > > _______________________________________________ > 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

March 3, 2010

[Pharo-project] [update 1.1] #11241

by StÃ©phane Ducasse

11241 ----- - Issue 2102: Fix the fact that local temp can shadow silently instance var - cleaning findChgSet - fixing packageInfo typos overriden -> overridden - Fix file = and added one test Stef

March 3, 2010

Re: [Pharo-project] Problems using java code importer with inFusion under windows

by Simon Denier

On 3 mars 2010, at 03:34, David T. Lewis wrote: > On Tue, Mar 02, 2010 at 02:18:20PM +0100, Fabrizio Perin wrote: >> Because the discussion about this topic happened on the moose mailing list i >> just update also the pharo mailing list. To summarize: >> >> I had problems using the importer of java code with inFusion on Windows, at >> the end i discovered that the primitives into WindowsOSProcessAccessor just >> fails during the initialization and that the process is not able to access >> the OS. There is also a bug report here: >> >> http://code.google.com/p/moose-technology/issues/detail?id=321&q=OSProcess&… > > Hi Fabrizio, > > The failure that you are seeing is because the OSProcessPlugin is not > present in your VM, and therefore the primitives are not there (so really > there is nothing to debug). > > OSProcess is not fully implemented on Windows. You can find some information > about OSProcess at http://wiki.squeak.org/squeak/708 > > If you have the option to use Unix/Linux or Mac, you should get better results. Hi David Is there other means to launch a command line (and external tools) form a Windows VM then? -- Simon

March 3, 2010

Re: [Pharo-project] Worth reading discussion on Smalltalk vs SmalltalkImage

by StÃ©phane Ducasse

On Mar 3, 2010, at 1:28 PM, Henrik Johansen wrote: > > > Den 03.03.2010 10:36, skrev StÃ©phane Ducasse: >> Browser vs SystemNavigation and much more such as abstraction (traits kind of mistakes) for the sake of it. >> >> I was thinking that I would love to have a message-oriented solution. >> One of these days 1.2 we will have to clean Smalltalk, SmalltalkImage current. >> The mail is long but worth to get some ideas that you may like or not. >> >> Stef >> > I have to say I support what to me seemed like the general consensus on > this, that the separation just didn't go far enough to make it worth it :) > I especially like the > Smalltalk vm parameterAt: > Smalltalk query allCallsOn: > etc. > protocol, sure you add a globals category to SystemDictionary, but to me > the resulting code looks much better than both the current state of > SmalltalkImage vmParameterAt: and SystemNavigation current allCallsOn: > (or were those class methods?), and the old where SystemDictionary was a > complete mess. I agree with part of it (see my next/previous mail :) even if for SystemNavigation I do not really like Smalltalk query ccalll.... > The important thing if this becomes the solution, is deciding what goes > where, (in a consistent fashion across forks), I'm sure that we will be able to have something that is cross fork. I do not have the energy to argue. > as well as the level of > backwards-compatibility packages should be offered/deprecation methods > kept in the image.

March 3, 2010

Re: [Pharo-project] Worth reading discussion on Smalltalk vs SmalltalkImage

by StÃ©phane Ducasse

I have the impression that there is no rush to fix Smalltalk SmalltalkImage SystemNavigation now if the urge is so intense that we have to.... I was thinking that I would like to have a solution where Smalltalk -> sole instance of System (aka SmalltalkImage) SystemDictionary -> renamed into Namespace and it accessible via Smalltalk environment Smalltalk namespace Or Smalltalk is just an holder for a couple of globals Smalltalk image -> SmalltalkImage current Smalltalk vm -> SmalltalkVM (not yet done) Smalltalk namespace -> Namespace instance Stef

March 3, 2010

Re: [Pharo-project] Worth reading discussion on Smalltalk vs SmalltalkImage

by Henrik Johansen

Den 03.03.2010 10:36, skrev StÃ©phane Ducasse: > Browser vs SystemNavigation and much more such as abstraction (traits kind of mistakes) for the sake of it. > > I was thinking that I would love to have a message-oriented solution. > One of these days 1.2 we will have to clean Smalltalk, SmalltalkImage current. > The mail is long but worth to get some ideas that you may like or not. > > Stef > I have to say I support what to me seemed like the general consensus on this, that the separation just didn't go far enough to make it worth it :) I especially like the Smalltalk vm parameterAt: Smalltalk query allCallsOn: etc. protocol, sure you add a globals category to SystemDictionary, but to me the resulting code looks much better than both the current state of SmalltalkImage vmParameterAt: and SystemNavigation current allCallsOn: (or were those class methods?), and the old where SystemDictionary was a complete mess. The important thing if this becomes the solution, is deciding what goes where, (in a consistent fashion across forks), as well as the level of backwards-compatibility packages should be offered/deprecation methods kept in the image. Cheers, Henry

March 3, 2010

Re: [Pharo-project] Undo compiler temporary variable handling

by StÃ©phane Ducasse

you rock guy! **thanks** a lot! Stef On Mar 3, 2010, at 11:52 AM, Jorge Ressia wrote: > Hi, > > I committed the change Compiler-JorgeRessia.141 > > Basically the problem was that the interactive mode was not taken into > account in the Encode and BytecodeEncoder >> bindTemp: method. > > bindTemp: name > "Declare a temporary; error not if a field or class variable or > out-of-scope temp. > Read the comment in Encoder>>bindBlockArg:within: and subclass > implementations." > self supportsClosureOpcodes ifFalse: > [^super bindTemp: name]. > scopeTable at: name ifPresent: > [:node| > "When non-interactive raise the error only if it is a duplicate" > (node isTemp or: [requestor interactive]) > ifTrue:[^self notify:'Name is already defined'] > ifFalse:[self warnAboutShadowed: name]]. > ^self reallyBind: name > > We tested it with Lukas and is working fine. However, we should see > that there are no further side effects. > > Cheers, > > Jorge > > > On Wed, Mar 3, 2010 at 9:37 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> lukas can youreread because I tried to improve thte explanation. >> >> >>> In 1.1 and I think that this is the wrong version of the changes that was introduced >>> because the interface sucks >>> ================= >>> Parser warningAllowed: true >>> >>> Object subclass: #Zork >>> instanceVariableNames: 't' >>> >>> zork >>> >>> | t | >>> t := 1. >>> >>> I get "t appears to beunused in this method.Ok to remove it?" >>> >>> Now with >>> Parser warningAllowed: false >>> >>> Object subclass: #Zork >>> instanceVariableNames: 't' >>> >>> zork >>> >>> | t | >>> t := 1. >>> the variable t shadows the instance variable without noticed >>> >>> So for Pharo we get simply for now issue Parser warningAllowed: true >>> to get it to the "normal" behavior. >>> >>> In 1.0 >>> ================= >>> The interface changes -> Parser warnUser >>> but we have the same silly broken pop up. >>> >>> Now I checked and in 3.9 >>> ================= >>> >>> we got 'Name is already defined.' which is the correct behavior >>> so it seems that this is not the warning preference that are responsible of the problem. >> >> >> _______________________________________________ >> 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

March 3, 2010

Re: [Pharo-project] Undo compiler temporary variable handling

by Jorge Ressia

Hi, I committed the change Compiler-JorgeRessia.141 Basically the problem was that the interactive mode was not taken into account in the Encode and BytecodeEncoder >> bindTemp: method. bindTemp: name "Declare a temporary; error not if a field or class variable or out-of-scope temp. Read the comment in Encoder>>bindBlockArg:within: and subclass implementations." self supportsClosureOpcodes ifFalse: [^super bindTemp: name]. scopeTable at: name ifPresent: [:node| "When non-interactive raise the error only if it is a duplicate" (node isTemp or: [requestor interactive]) ifTrue:[^self notify:'Name is already defined'] ifFalse:[self warnAboutShadowed: name]]. ^self reallyBind: name We tested it with Lukas and is working fine. However, we should see that there are no further side effects. Cheers, Jorge On Wed, Mar 3, 2010 at 9:37 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > lukas can youreread because I tried to improve thte explanation. > > >> In 1.1 and I think that this is the wrong version of the changes that was introduced >> because the interface sucks >> ================= >> Parser warningAllowed: true >> >> Object subclass: #Zork >> Â Â Â instanceVariableNames: 't' >> >> zork >> >> Â Â Â | t | >> Â Â Â t := 1. >> >> I get "t appears to beunused in this method.Ok to remove it?" >> >> Now with >> Â Â Â Parser warningAllowed: false >> >> Object subclass: #Zork >> Â Â Â instanceVariableNames: 't' >> >> zork >> >> Â Â Â | t | >> Â Â Â t := 1. >> Â the variable t shadows the instance variable without noticed >> >> So for Pharo we get simply for now issue Parser warningAllowed: true >> to get it to the "normal" behavior. >> >> In 1.0 >> ================= >> The interface changes -> Parser warnUser >> but we have the same silly broken pop up. >> >> Now I checked and in 3.9 >> ================= >> >> we got Â 'Name is already defined.' which is the correct behavior >> so it seems that this is not the warning preference that Â are responsible of the problem. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 3, 2010

Re: [Pharo-project] about code formatting in pharo

by Peter Hugosson-Miller

On Wed, Mar 3, 2010 at 10:51 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >what do you mean by now used? > >Did they change that recently? > > According to http://planetmisc.squeak.org/ > a new package Compiler-cmm.131.mcz is now in Squeak inbox > and may find its way into trunk ... > > > >I don't like Beck's rule "3. Rectangular Block" > vs. > >So for me personally, Beck's rule 3 is the one that looks better. > > And there we have them: discussions on what looks better :) > Hehehe, walked right into that one, didn't I ;-) Bye > T. > -- > Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - > jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Cheers, Peter

March 3, 2010

[Pharo-project] about code formatting in pharo

by Torsten Bergmann

>what do you mean by now used? >Did they change that recently? According to http://planetmisc.squeak.org/ a new package Compiler-cmm.131.mcz is now in Squeak inbox and may find its way into trunk ... >I don't like Beck's rule "3. Rectangular Block" vs. >So for me personally, Beck's rule 3 is the one that looks better. And there we have them: discussions on what looks better :) Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

March 3, 2010