- Pharo-dev - lists.pharo.org

Re: [Pharo-project] instVarNames vs instVarNamed:

by Camillo Bruni

On 2012-09-23, at 17:38, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > On a class, should answer the inst of the corresponding metaclass > > Like when you ask the inst var of an instance, you get the inst var of the corresponding class > > Ben but that works...., I don't get it :D Nautilus instVarNamed: #maxSize Nautilus new instVarNamed: #announcer and: Nautilus class instVarNames includes: #maxSize. Nautilus instVarNames includes: #announcer. everything fine and symmetrical here...

Sept. 23, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Benjamin

On a class, should answer the inst of the corresponding metaclass Like when you ask the inst var of an instance, you get the inst var of the corresponding class Ben On Sep 23, 2012, at 5:15 PM, Camillo Bruni wrote: >> instVarNamed: is implemented on Object this is why it looks into the object class. >> but reimplementing on Class would make sense. > > I don't see any problem here, besides the maybe confusing names... > > #instVarNamed: works on class-side as well, used to read the values in the living > instance. > > What would your #instVarNamed: do?

Sept. 23, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Camillo Bruni

> instVarNamed: is implemented on Object this is why it looks into the object class. > but reimplementing on Class would make sense. I don't see any problem here, besides the maybe confusing names... #instVarNamed: works on class-side as well, used to read the values in the living instance. What would your #instVarNamed: do?

Sept. 23, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by StÃ©phane Ducasse

yes I know. instVarNamed: is implemented on Object this is why it looks into the object class. but reimplementing on Class would make sense. Stef On Sep 23, 2012, at 2:06 PM, Benjamin wrote: > It's not a class var, it's an inst var of the meta class > > > Ben > On Sep 23, 2012, at 1:27 PM, Igor Stasenko wrote: > >> On 23 September 2012 12:16, 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? >>> >> >> nope. i never tried to access class instance vars using this.. >> but it is strange, it should work. >> >>> Stef >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Sept. 23, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Benjamin

It's not a class var, it's an inst var of the meta class Ben On Sep 23, 2012, at 1:27 PM, Igor Stasenko wrote: > On 23 September 2012 12:16, 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? >> > > nope. i never tried to access class instance vars using this.. > but it is strange, it should work. > >> Stef > > > > -- > Best regards, > Igor Stasenko. >

Sept. 23, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Igor Stasenko

On 23 September 2012 12:16, 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? > nope. i never tried to access class instance vars using this.. but it is strange, it should work. > Stef -- Best regards, Igor Stasenko.

Sept. 23, 2012

Re: [Pharo-project] Changes in MongoTalk

by Nicolas Petton

Looks cool Francois! I'll have a deeper look tomorrow. Nico -- On Sat, 22 Sep 2012 18:16:26 -0700, Francois Stephany <tulipe.moutarde(a)gmail.com> wrote: > I've introduced the notion of limit to the MongoTalk driver (see the > MongoTalk repo). > > If someone (Nico, Esteban?) could have a look at the changes it would be > great. The test case is overly simplistic but it should illustrate the > point. > > Next on my list: numberToSkip[1]. With "limit" and "numberToSkip", we > should be able to have something like pagination easily. > > > Please stop me if none of these changes makes sense ;) > > > [1] > http://www.mongodb.org/display/DOCS/Mongo+Wire+Protocol#MongoWireProtocol-O… > -- Nicolas Petton http://nicolas-petton.fr

Sept. 23, 2012

[Pharo-project] instVarNames vs instVarNamed:

by StÃ©phane Ducasse

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? Stef

Sept. 23, 2012

Re: [Pharo-project] The roadmap aka fight plan to make image control host window

by StÃ©phane Ducasse

would be a nice task for the consortium engineer :) Stef On Sep 22, 2012, at 8:22 PM, Igor Stasenko wrote: > First, we need to make one thing: > > Change the VM to not call ioProcessEvents function directly, but > rather use a variable which will hold a function pointer. > Initially, when VM starts, that function pointer is NULL, and so, > "process events" is NOP. > > Then we need to implement a module which will manage host windows, > and once image tells it to create a window, > it can change the function pointer to ioProcessEvents to own function. > > This change, would allow us to temporary disable any external event > processing (like in case of callbacks). > > Second, we should move all event-related stuff to new plugin (for > instance, all definitions in sq.h > like sqInputEvent , ioSetInputSemaphore() ioGetNextEvent() etc). > > For all UI-related stuff the image should communicate with a new > plugin, while VM should get rid of all knowledge of any existence of > UI events, > like input semaphores, primitives for fetching them etc. > > Third, of course, all screen update/refresh primitives should be > deprecated, and image should use new primitives to update the contents > of host window(s). > > > -- > Best regards, > Igor Stasenko. >

Sept. 23, 2012

Re: [Pharo-project] Pharo 1.4 -- debugger initialExtent is too wide, centered

by StÃ©phane Ducasse

> I'd think these changes might be desirable for everyone -- comments? >> >> sounds all very reasonable! make a bug entry + a slice :) > > Thanks, will do -- maybe tomorrow I can figure out how to do that; it's been a couple of years since my last contribution. - Open a bug entry - Take 1.4 or 2.0 latest - do you change - bring the monticello browser - press slice select the right dirty packages that will be part of the slice - commit in the inbox the slice - mark the bug entry as FixToInclude Easy :)

Sept. 23, 2012