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

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

by Stephan Eggermont

Hi Pavel iMac 27 11.1, 10.6.8 works fine. Resizing the pharo window gives a screen with garbage and then mostly removes the pharo window. XUL stays up, but no longer switches views. Stephan

Sept. 24, 2012

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

by Pavel Krivanek

24.9.2012 v 23:34, Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Mon, Sep 24, 2012 at 10:57 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> 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. > > In my box (OSX 10.6.8 ), it opens the splash, it opens the Pharo image, but the splash is never closed and no native window is opened. > > Cheers, hmm, try it several times, try to disable the firewall and check PharoDebug.log -- Pavel > > > Thanks, > -- Pavel > > > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Eliot Miranda

On Sun, Sep 23, 2012 at 3:16 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > may be this is too early but I wanted to change the value of a class > instance variable > > Nautilus class instVarNames > -> #('maxSize' 'cachedLastClasses' 'groups') > > Nautilus class instVarNamed: 'groups' > -> error > > Nautilus instVarNamed: 'groups' > worked > > I found that strange and inconsistent. > I'am wrong? > Read Peter Hugosson Miller's message. instVarNamed: is like instVarAt:, in fact instVarNamed: instVarName ^self instVarAt: (self class allInstVarNames indexOf: instVarName) but that's slot and better is instVarNamed: instVarName ^self instVarAt: (self class instVarIndexFor: aString asString ifAbsent: [self error: 'no such inst var']) any clearer? i.e. instVarNamed: is sent to instances to access their inst vars, not to classes to access meta data about their inst vars. > Stef > -- best, Eliot

Sept. 24, 2012

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

by Mariano Martinez Peck

On Mon, Sep 24, 2012 at 10:57 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>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. > In my box (OSX 10.6.8 ), it opens the splash, it opens the Pharo image, but the splash is never closed and no native window is opened. Cheers, > > Thanks, > -- Pavel > -- Mariano http://marianopeck.wordpress.com

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Camillo Bruni

On 2012-09-24, at 22:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > No just make instVarNamed: work on Class/Metaclass it DOES work there... it just happens that Class is a Class and an Object...

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Mariano Martinez Peck

On Mon, Sep 24, 2012 at 10:57 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > No just make instVarNamed: work on Class/Metaclass > > > but then you won't be able to reach the normal instance variables of a class (the metaclass): Nautilus class instVarNamed: 'format' -> 164 I won't be able to do that if we override #instVarNamed: That's why I think I prefer the rename to #myInstancesVariableNames > 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.. > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 24, 2012

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

by StÃ©phane Ducasse

pavel we are moving in a new building tomorrow so we will beusy unpackingâ¦ at least me :) On Sep 24, 2012, at 10:57 PM, 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 > <PhobosDemo.png>

Sept. 24, 2012

[Pharo-project] Native UI bundle for Mac

by Pavel Krivanek

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

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by StÃ©phane Ducasse

No just make instVarNamed: work on Class/Metaclass 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.. >

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by StÃ©phane Ducasse

On Sep 24, 2012, at 8:18 PM, Camillo Bruni 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. Yes I know but we could override Object methods to make sense on Class/Metaclass Stef > > 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..

Sept. 24, 2012