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

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

[Pharo-project] Changes in MongoTalk

by Francois Stephany

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…

Sept. 23, 2012

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

by Ben Coman

Same here. What might also be nice would be a window menu item like 'Remember default debugger window position/size'. Then its real easy for anyone to customize on the fly - which might even change from day to day. Camillo Bruni wrote: > On 2012-09-22, at 23:08, Martin McClure <martin(a)hand2mouse.com> wrote: > > >> In Pharo 1.4, if your Display is not tiny, the initial extent of the debugger is 2/3 the width and 4/5 the height of Display. For large screens, this is just too big, especially too wide. >> >> My current Display is 2396x1741x32, and I have to immediately resize any debugger smaller in order to make it usable. I've experimented with leaving the height as is and limiting the width to 900 in Debugger>>initialExtent; this produces a much more usable result. >> >> ((w - (w // 3)) min: 900) @ (h - (h // 5)) >> > > definitely! > > >> The debugger also always centers its window in Display. Since my Display is spread across two monitors, this means it always must be moved to be readable. If I comment out the line >> >> window center: Display center. >> >> in MorphicUIManager>>openDebugger:fullMorphicLabel:, I'm much happier. >> > > +1 > > >> I'd think these changes might be desirable for everyone -- comments? >> > > sounds all very reasonable! make a bug entry + a slice :) > >

Sept. 23, 2012

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

by Martin McClure

On 09/22/2012 02:14 PM, Camillo Bruni wrote: > >> 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. Regards, -Martin

Sept. 23, 2012

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

by Camillo Bruni

On 2012-09-22, at 23:08, Martin McClure <martin(a)hand2mouse.com> wrote: > In Pharo 1.4, if your Display is not tiny, the initial extent of the debugger is 2/3 the width and 4/5 the height of Display. For large screens, this is just too big, especially too wide. > > My current Display is 2396x1741x32, and I have to immediately resize any debugger smaller in order to make it usable. I've experimented with leaving the height as is and limiting the width to 900 in Debugger>>initialExtent; this produces a much more usable result. > > ((w - (w // 3)) min: 900) @ (h - (h // 5)) definitely! > The debugger also always centers its window in Display. Since my Display is spread across two monitors, this means it always must be moved to be readable. If I comment out the line > > window center: Display center. > > in MorphicUIManager>>openDebugger:fullMorphicLabel:, I'm much happier. +1 > I'd think these changes might be desirable for everyone -- comments? sounds all very reasonable! make a bug entry + a slice :)

Sept. 22, 2012