September 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Roassal Survey

by Vanessa PeÃ±a Araya

Hello! As you probably know, Roassal was presented at ESUG. We received a lot of positive feedback from you and also a lot of request for features. Thank you very much! We want to start working on this, but also prioritize what seems to be more urgent. For this, we would like to survey the community about 1 - what are the features you would like to see in Roassal. Please, provide a list of features requests and tell us about their priority 2 - scenarios where you would like to use Roassal. Thank you very much, Vanessa.

Sept. 25, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 370 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 25, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Guido Chari

I don't see the problem either. I think the best way to see it is to send instVarNames to any object that isn't a Behavior. That way one get a MNU. So instVarNames is a behavior defined only for objects describing behavior. And instVarNamed: is a behavior of any object for accesing its instance variables. As classes are first class objects they also define this behavior. If any problem i think it should be on finding better names so confusion is avoided. Cheers, Guido. 2012/9/24 Igor Stasenko <siguctua(a)gmail.com> > On 24 September 2012 22:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > No just make instVarNamed: work on Class/Metaclass > > > but it works! > Wake up: > > Object instVarNamed: 'superclass' ==> ProtoObject > Object class instVarNamed: 'superclass' =>>> ProtoObject class > > while #instVarNames is an accessor method, since you have: > > ProtoObject subclass: #Object > instanceVariableNames: '' <<< ---- from here > classVariableNames: 'DependentsFields' > poolDictionaries: '' > category: 'Kernel-Objects' > > so, > Object instVarNames ==> #() > > Point instVarNames #('x' 'y') > > And if you want to know, what instance variables an Object (as an > object) has, you can always do: > > Object class allInstVarNames > > #('superclass' 'methodDict' 'format' 'layout' 'instanceVariables' > 'organization' 'subclasses' 'name' 'classPool' 'sharedPools' > 'environment' 'category' 'traitComposition' 'localSelectors') > > And then , access the values: > > Object instVarNamed: 'category' ==> #'Kernel-Objects' > > > And then what Mariano proposing with renaming an accessor to > 'myInstVarNames' sounds like an absurd, > then we should probably think about renaming all accessors in all > classes like that, i.e. > instead > > (1@2) x > > we should write > > (1@2) myX > > or #getX and so on.. > > > > > On Sep 24, 2012, at 8:24 PM, Guillermo Polito wrote: > > > >> What if we do it the other way? Add #variableNames to the instances :) > >> > >> Nautilus new variableNames = Nautilus instVarNames. > >> > >> And them > >> > >> Nautilus new variableNames > >> ==> #('announcer' 'browsedEnvironment' 'browsingHistory' 'plugins' > 'selectedCategory' 'selectedClass' 'selectedGroup' 'selectedMethod' > 'selectedPackage' 'showCategories' 'showComment' 'showGroups' > 'showHierarchy' 'showInstance' 'showPackages' 'ui' 'uiClass') > >> > >> Nautilus new instVarNamed: 'announcer' > >> > >> ? > >> > >> Of course, that will happen/work at metaclass level too. > >> > >> Maybe rename #instVarNames to #myInstancesVariableNames? > >> > >> Guille > >> > >> On Mon, Sep 24, 2012 at 8:18 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > >> On 2012-09-24, at 20:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> > On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote: > >> >>>> Nautilus class instVarNames > >> >>> -> #('maxSize' 'cachedLastClasses' 'groups') > >> >>> > >> >>> ok we get the instance variables > >> >>> > >> >>> Nautilus class instVarNamed: 'groups' > >> >>> -> error > >> >>> > >> >>> For me that is wrong. I should not get an error, I should get the > actual > >> >>> variable. > >> >>> I mean, why #instVarNames workds but #instVarNamed: doesn't? That > is > >> >>> inconsistent. > >> > > >> > to me mariano is right. if I can ask a class for a receiver a list of > stuff I should be able to > >> > send to the same receiver the value of the named elements. > >> > this distinction is confusing (Normally I know what is metaclass > programming) > >> > >> but with methods it's the very same, you get them no the class side, > but you > >> cannot do anything with them on the class. > >> > >> The problem is just that on a Class the instance side (of the > Metaclass) and the > >> class side collapse, so you have a double interface there. > >> > >> unless you have a strict and weird kind of separation of these two > layers > >> like in Java, you will always have a double set of methods there.. > >> > > > > > > > > -- > Best regards, > Igor Stasenko. > >

Sept. 25, 2012

[Pharo-project] [update 2.0] #20306

by Marcus Denker

20306 ----- Issue 6731: FileDialogWindow DNU - FS related http://code.google.com/p/pharo/issues/detail?id=6731 Issue 6730: Better way to define platform specific shortcuts http://code.google.com/p/pharo/issues/detail?id=6730 Issue 6632: assert:equals: reverse the order of the printed arguments http://code.google.com/p/pharo/issues/detail?id=6632 -- Marcus Denker -- http://marcusdenker.de

Sept. 25, 2012

Re: [Pharo-project] Default max heap size on OS-X

by Oscar E A Callau

Yes, I'm always changing it when downloading a new vm. However on cogMT (from Eliot), I can't write more than 1.75 GB. Cheers On Sep 24, 2012, at 11:51, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Mon, Sep 24, 2012 at 10:04 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hi > > I noticed the default SqueakMaxHeapSize on CI for Mac is 536870912 bytes. > Is there a specific reason for the default to be so low? I know there used to be > problems with the windows vm. > > > > Good point. Maybe it is time to move it to 2GB ? > > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 25, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 369 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 25, 2012

Re: [Pharo-project] OSProcess ... ported to 2.0?

by Camillo Bruni

On 2012-09-25, at 01:11, Dale Henrichs <dhenrich(a)vmware.com> wrote: > As I take yet another stab at getting the Metacello Preview running on Pharo2.0, I find that OSProcess is sprinkled with references to FileDirectory ... at least in the packages referenced by the configuration, so I'm wondering if a port exists for Phar0-2.0 ... At the moment OSProcess is a prerequisite .... use my compatibility layer for FileDirectory, which wraps around FileReference: http://smalltalkhub.com/mc/dh83/fisleg/main With that it should be possible to load most old code in 2.0. There are a 4 methods or so I haven't ported yet and I should properly isolate the package... > If there is an alternate mechanism for running shell commands from Pharo2.0, then I assume that I'll be able to use that instead ... currently there isn't any other option :/

Sept. 25, 2012

Re: [Pharo-project] Native UI bundle for Mac

by Dennis Schetinin

It works smoothly for me. Best regards, Dennis Schetinin On Tuesday, 25 September 2012 Ð³. at 0:57, Pavel Krivanek wrote: > Hi, > > I tried to create a Mac application bundle for an early Phobos version > (CogVM+XULRunner+Zinc+WebSockets). Can you please test it it works on > your Mac and maybe let me know how to improve it? Because it is not my > home platform... :-) > https://docs.google.com/open?id=0BzSsmZhqtUTeTkdoY0YyZGJlVm8 > > It should open a splash screen and then open a Pharo window together > with a native window that should respond. Some demo pages currently > may do not look perfect on Mac. > > Thanks, > -- Pavel > > > > > Attachments: > - PhobosDemo.png >

Sept. 25, 2012

[Pharo-project] OSProcess ... ported to 2.0?

by Dale Henrichs

As I take yet another stab at getting the Metacello Preview running on Pharo2.0, I find that OSProcess is sprinkled with references to FileDirectory ... at least in the packages referenced by the configuration, so I'm wondering if a port exists for Phar0-2.0 ... At the moment OSProcess is a prerequisite .... If there is an alternate mechanism for running shell commands from Pharo2.0, then I assume that I'll be able to use that instead ... Dale

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Igor Stasenko

On 24 September 2012 22:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > No just make instVarNamed: work on Class/Metaclass > but it works! Wake up: Object instVarNamed: 'superclass' ==> ProtoObject Object class instVarNamed: 'superclass' =>>> ProtoObject class while #instVarNames is an accessor method, since you have: ProtoObject subclass: #Object instanceVariableNames: '' <<< ---- from here classVariableNames: 'DependentsFields' poolDictionaries: '' category: 'Kernel-Objects' so, Object instVarNames ==> #() Point instVarNames #('x' 'y') And if you want to know, what instance variables an Object (as an object) has, you can always do: Object class allInstVarNames #('superclass' 'methodDict' 'format' 'layout' 'instanceVariables' 'organization' 'subclasses' 'name' 'classPool' 'sharedPools' 'environment' 'category' 'traitComposition' 'localSelectors') And then , access the values: Object instVarNamed: 'category' ==> #'Kernel-Objects' And then what Mariano proposing with renaming an accessor to 'myInstVarNames' sounds like an absurd, then we should probably think about renaming all accessors in all classes like that, i.e. instead (1@2) x we should write (1@2) myX or #getX and so on.. > > On Sep 24, 2012, at 8:24 PM, Guillermo Polito wrote: > >> What if we do it the other way? Add #variableNames to the instances :) >> >> Nautilus new variableNames = Nautilus instVarNames. >> >> And them >> >> Nautilus new variableNames >> ==> #('announcer' 'browsedEnvironment' 'browsingHistory' 'plugins' 'selectedCategory' 'selectedClass' 'selectedGroup' 'selectedMethod' 'selectedPackage' 'showCategories' 'showComment' 'showGroups' 'showHierarchy' 'showInstance' 'showPackages' 'ui' 'uiClass') >> >> Nautilus new instVarNamed: 'announcer' >> >> ? >> >> Of course, that will happen/work at metaclass level too. >> >> Maybe rename #instVarNames to #myInstancesVariableNames? >> >> Guille >> >> On Mon, Sep 24, 2012 at 8:18 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> On 2012-09-24, at 20:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> > On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote: >> >>>> Nautilus class instVarNames >> >>> -> #('maxSize' 'cachedLastClasses' 'groups') >> >>> >> >>> ok we get the instance variables >> >>> >> >>> Nautilus class instVarNamed: 'groups' >> >>> -> error >> >>> >> >>> For me that is wrong. I should not get an error, I should get the actual >> >>> variable. >> >>> I mean, why #instVarNames workds but #instVarNamed: doesn't? That is >> >>> inconsistent. >> > >> > to me mariano is right. if I can ask a class for a receiver a list of stuff I should be able to >> > send to the same receiver the value of the named elements. >> > this distinction is confusing (Normally I know what is metaclass programming) >> >> but with methods it's the very same, you get them no the class side, but you >> cannot do anything with them on the class. >> >> The problem is just that on a Class the instance side (of the Metaclass) and the >> class side collapse, so you have a double interface there. >> >> unless you have a strict and weird kind of separation of these two layers >> like in Java, you will always have a double set of methods there.. >> > > -- Best regards, Igor Stasenko.

Sept. 24, 2012