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

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

Re: [Pharo-project] Packages remodularization

by Mariano Martinez Peck

This is invaluable useful information...I just created http://code.google.com/p/pharo/issues/detail?id=2105 so that not to forget about this email. cheers mariano On Tue, Mar 2, 2010 at 12:15 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Mar 2, 2010 at 12:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > >> We can use dashes in package names, however it's a little bit >> confusing and Monticello cannot process it well if one package has >> shorter name, for example Announcements and Announcements-View >> > > Yes, I suffered that several times. In that case Announcements-View is > interpreted as a subcategory in the package Announcements > but not as a separate package Announcements-View > > >> >> -- Pavel >> >> On Tue, Mar 2, 2010 at 12:03 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> I only wanted to keep the the original package and don't use any dash >> >> in the package name. Of course we can use your way. >> > >> > Aha ok, then this is fine of course. I don't care about the dashes. >> > >> > Lukas >> > >> >> >> >> Cheers, >> >> -- Pavel >> >> >> >> On Tue, Mar 2, 2010 at 11:50 AM, Lukas Renggli <renggli(a)gmail.com> >> wrote: >> >>>> SystemOrganization renameCategory: 'Announcements-Core' toBe: >> 'Announcements'. >> >>>> SystemOrganization renameCategory: 'Announcements-View' toBe: >> >>>> 'AnnouncementsView'. >> >>> >> >>> Why can't this just be split into two packages 'Announcements-Core' >> >>> and 'Announcements-View'? >> >>> >> >>> Furthermore, the code above looses all extension methods. For example >> >>> 'Announcements-View' extends 'Announcement-Core' in the class >> >>> Announcement. Maybe it would be safer to rename packages using the >> >>> code we use in Seaside: >> >>> >> >>> renamePackage: oldPackageName to: newPackageName >> >>> "self renamePackage: 'Seaside-Squeak-Development-Core' to: >> >>> 'Seaside-Pharo-Development-Core'" >> >>> >> >>> | oldPackage newPackage oldWorkingCopy newWorkingCopy | >> >>> oldPackage := PackageInfo named: oldPackageName. >> >>> newPackage := PackageInfo named: newPackageName. >> >>> >> >>> " rename system categories " >> >>> oldPackage systemCategories do: [ :oldCategory | >> >>> | newCategory | >> >>> newCategory := oldCategory allButFirst: oldPackage >> systemCategoryPrefix size. >> >>> Smalltalk organization renameCategory: oldCategory >> toBe: newPackage >> >>> systemCategoryPrefix , newCategory ]. >> >>> >> >>> " rename method categories " >> >>> oldPackage extensionClasses do: [ :extensionClass | >> >>> (oldPackage extensionCategoriesForClass: >> extensionClass) do: [ :oldProtocol | >> >>> | newProtocol | >> >>> newProtocol := oldProtocol allButFirst: >> oldPackage methodCategoryPrefix size. >> >>> extensionClass organization renameCategory: >> oldProtocol toBe: >> >>> newPackage methodCategoryPrefix , newProtocol ] ]. >> >>> >> >>> " update monticello packages " >> >>> oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: >> oldPackageName). >> >>> newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: >> newPackageName). >> >>> newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; >> modified: true. >> >>> >> >>> " test is all methos have been caught " >> >>> oldPackage methods isEmpty >> >>> ifTrue: [ oldWorkingCopy unload. PackageOrganizer >> default >> >>> unregisterPackage: oldPackage ] >> >>> ifFalse: [ self error: 'Some code entities remain in >> the old >> >>> package, please migrate manually.' ] >> >>> >> >>> Otherwise, I completely agree with the proposed refactorings :-) >> >>> >> >>> 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 >> >> >> > >> > >> > >> > -- >> > 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 >> > >

March 3, 2010

Re: [Pharo-project] [ANN] Magma 1.0 release 44

by Mariano Martinez Peck

Adrian did a change and asked for feedback. Not sure what happened. On Tue, Mar 2, 2010 at 4:56 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > > Hi Chris, thanks for your reply, I am aware of all the problems caused by > > the new NetNameResolver in Pharo. > > BTW, I am not so aware of these problems. Basic networking seems to > be so badly broken I am not even able to connect a socket, so I've got > to think any networking application, including even Seaside, would be > broken. I'm surprised that such a breakage would be allowed to > persist in Pharo for so long. Do you know what is going on and what > the plan is? > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma >

March 3, 2010