- Pharo-dev - lists.pharo.org

[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

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

by Martin McClure

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)) 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. I'd think these changes might be desirable for everyone -- comments? Regards, -Martin

Sept. 22, 2012

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

by Igor Stasenko

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. 22, 2012

Re: [Pharo-project] headless CogVM on Windows

by Igor Stasenko

Pavel, as you may know, we wanting to make image be in control whether it wants to display any window or not, i.e. it should tell VM to create host window if it wants to, and VM should not provide any window by default (or simulate that it is there). And we want it for a years, still nobody spent time implementing this. As to me, it worth putting effort to make this happen , instead of fixing broken headless mode. On 22 September 2012 18:39, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Well, on Mac OS X it works too but the Pharo window is always displayed. > > -- Pavel > > On Fri, Sep 21, 2012 at 7:23 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> This is the reason why I need the headless mode on Windows: >> http://youtu.be/L6P6VuqDmaM >> >> "This video shows a very simple Pharo application based on XULRunner. >> We firstly start XULRunner that displays a splashscreen. During the >> splash screen the XULRunner starts a new process with Pharo and starts >> Zinc server in it. As soon as the server is started, it starts to >> communicate to it using a WebSocket and opens the main window. When >> the window is closed, the Pharo image is closed immediately too." >> >> ...so this is the way we can create seamless applications with native >> GUI in Pharo without need of special VM extensions. Currently on >> Windows it works the same way however the Pharo window is displayed. I >> will test the Mac later. >> >> -- Pavel >> >> On Fri, Sep 21, 2012 at 5:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 21 September 2012 16:28, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>>yeah... we need a real headless mode (no systry, nothing... just a deamon >running) >>>> >>>> The regulary Squeak VM for Windows is able to do just that. >>>> It runs Smalltalk as an NT service by using the option "-service" >>>> See >>>> >>>> http://wiki.squeak.org/squeak/105 >>>> >>>> Dont know if this also works on Cog/Pharo standard VM. >>>> >>> >>> yeah.. but this is something different.. it registers itself as a >>> service in system. >>> Which is not the same as just running it headless. >>> >>>> Bye >>>> T. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> -- Best regards, Igor Stasenko.

Sept. 22, 2012

Re: [Pharo-project] headless CogVM on Windows

by Pavel Krivanek

Well, on Mac OS X it works too but the Pharo window is always displayed. -- Pavel On Fri, Sep 21, 2012 at 7:23 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > This is the reason why I need the headless mode on Windows: > http://youtu.be/L6P6VuqDmaM > > "This video shows a very simple Pharo application based on XULRunner. > We firstly start XULRunner that displays a splashscreen. During the > splash screen the XULRunner starts a new process with Pharo and starts > Zinc server in it. As soon as the server is started, it starts to > communicate to it using a WebSocket and opens the main window. When > the window is closed, the Pharo image is closed immediately too." > > ...so this is the way we can create seamless applications with native > GUI in Pharo without need of special VM extensions. Currently on > Windows it works the same way however the Pharo window is displayed. I > will test the Mac later. > > -- Pavel > > On Fri, Sep 21, 2012 at 5:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 21 September 2012 16:28, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>yeah... we need a real headless mode (no systry, nothing... just a deamon >running) >>> >>> The regulary Squeak VM for Windows is able to do just that. >>> It runs Smalltalk as an NT service by using the option "-service" >>> See >>> >>> http://wiki.squeak.org/squeak/105 >>> >>> Dont know if this also works on Cog/Pharo standard VM. >>> >> >> yeah.. but this is something different.. it registers itself as a >> service in system. >> Which is not the same as just running it headless. >> >>> Bye >>> T. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >>

Sept. 22, 2012

Re: [Pharo-project] headless CogVM on Windows

by Sven Van Caekenberghe

Cool stuff ! -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill On 21 Sep 2012, at 19:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > This is the reason why I need the headless mode on Windows: > http://youtu.be/L6P6VuqDmaM > > "This video shows a very simple Pharo application based on XULRunner. > We firstly start XULRunner that displays a splashscreen. During the > splash screen the XULRunner starts a new process with Pharo and starts > Zinc server in it. As soon as the server is started, it starts to > communicate to it using a WebSocket and opens the main window. When > the window is closed, the Pharo image is closed immediately too." > > ...so this is the way we can create seamless applications with native > GUI in Pharo without need of special VM extensions. Currently on > Windows it works the same way however the Pharo window is displayed. I > will test the Mac later. > > -- Pavel > > On Fri, Sep 21, 2012 at 5:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 21 September 2012 16:28, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> yeah... we need a real headless mode (no systry, nothing... just a deamon >running) >>> >>> The regulary Squeak VM for Windows is able to do just that. >>> It runs Smalltalk as an NT service by using the option "-service" >>> See >>> >>> http://wiki.squeak.org/squeak/105 >>> >>> Dont know if this also works on Cog/Pharo standard VM. >>> >> >> yeah.. but this is something different.. it registers itself as a >> service in system. >> Which is not the same as just running it headless. >> >>> Bye >>> T. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Sept. 21, 2012

Re: [Pharo-project] [update 2.0] #20301

by Sven Van Caekenberghe

On 21 Sep 2012, at 13:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 20301 > ----- > > Issue 6697: Zn+Zdc Update 2012-09-19 > http://code.google.com/p/pharo/issues/detail?id=6697 Thanks! Zinc-HTTP-Deprecated is an empty category now and can be removed. > Issue 6699: Share binding of metaclass methods > http://code.google.com/p/pharo/issues/detail?id=6699 > > -- > Marcus Denker -- http://marcusdenker.de -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 21, 2012