August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Native Windows

by Igor Stasenko

2009/8/18 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > Before you run too far down the let's change Morphic path you should > check with Igor I'm sure he was off a year back trying to hack > Ffenestri into Morphic. > yes, yes i have an initial implementation of new hostwindows plugin which moves/separates the windowing stuff from core VM functionality. It then would be possible to build a VM which having no windowing support at all, and works as a console application. The problem with it, that i never did any windowing & event handling on X windows or MacOS, so its not so easy. I'm only hoping that my design fits well with other platforms, not only win32. I can publish the bits i'm done. Just say. I am swamped by another projects , so i don't know when i could find a time to finish it. :( > Tim and I gave that thought up when we considered there was 400 or so > references to EventSenor Â & Display many of which had no concept of > window ownership in mind. Yes, this is a bit of pain. My thought about it, is to keep sensor global, but replace all refs to Display to 'self display' message send. There are only a few methods which assigning new value to Display , which should be addressed separately. > > > On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: > >> Thanks so much for sharing on this. >> >> There seems to be a few caches of stuff stashed in various places. >> None of it is exactly complete. Â I've taken the bulk of it from the http://source.impara.de/HostWindows >> and a bit from your experimental directory and looked at the plugins >> code in the VM tree and then just started trying to fix problems >> with event delivery. Â I'd like to pull it all together and make it >> coherent on Windows, OS X and Unix. >> >> Its really great that Pharo has integrated the HostMenus stuff - I >> think it would be cool to do HostWindows too. Â Once you eliminate >> having to emulate the look of the windows - most widget sets look >> pretty similar and I think morphic widgets inside of real windows >> would keep things from looking too weird while preserving the >> benefits of having our widgets in Smalltalk. >> >> Given Pharo's "take no prisoners" attitude, I think getting host >> windows working would allow a lot of really ugly code in >> PasteUpMorph and HandMorph to just go away. Â Event delivery in >> Morphic is just totally incomprehensible and I'm finding it is >> broken when a second window is introduced as the mouse coordinates >> seem to be delivered window relative. Â Its also really hard to work >> on because I keep junking images by making changes that wreck the UI. >> >> -Todd Blanchard >> > > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Â Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 18, 2009

[Pharo-project] [lewis@mail.msen.com: Re: [Vm-dev] Fwd: Could not load VMMaker in 10315]

by David T. Lewis

FYI. This problem was originally reported on the Pharo list earlier this year. The fix is now in VMMaker on SqueakSource. ----- Forwarded message from "David T. Lewis" <lewis(a)mail.msen.com> ----- Date: Tue, 18 Aug 2009 08:05:22 -0400 From: "David T. Lewis" <lewis(a)mail.msen.com> To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> Subject: Re: [Vm-dev] Fwd: [Pharo-project] Could not load VMMaker in 10315 VMMaker (from SqueakSource) can now be loaded into closure-enabled images. I was able to remove a couple of temp variables from the GeniePlugin primitive without affecting the logic. This was discussed on several lists back in May. The fix is in VMMaker-dtl.135 on SqueakSource, and is documented in Mantis http://bugs.squeak.org/view.php?id=7384. Dave On Mon, May 25, 2009 at 10:37:15PM -0400, David T. Lewis wrote: > > On Mon, May 25, 2009 at 11:06:10AM -0700, Eliot Miranda wrote: > > > > On Mon, May 25, 2009 at 7:40 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > > > > > > On Sun, May 24, 2009 at 01:44:52PM -0700, Eliot Miranda wrote: > > > > > > > > 3. refactor the GeniePlugin method into an outer args parser and an inner > > > > engine method and solve the problem. Since VMMaker will inline anyway > > > this > > > > shouldn't make performance worse. I haven't done this because I'm not > > > the > > > > author and it is quite a complex method. > > > > > > This sounds like the right thing to do, regardless of what may change > > > in the compiler(s). > > > > > > +1 > > > > Well unfortunately the refactoring turns out to be easier said than done. > At least it was easier for me to say it than it was for me to do it. > > I made a naive attempt to split the primitive into smaller methods, but this > just ended up trading off too many things on the stack for too many arguments > in an argument list. > > The method temp variables could be changed to be instance variables. This > would probably work fine for any current VMs (not sure about Hydra), but > it does not pass the smell test IMO. > > I suspect that Nathaniel Schaerli knew what he was doing when he wrote > this primitive, and I most certainly do not, so I don't expect that I will > make much further progress on this front. > > Dave ----- End forwarded message -----

Aug. 18, 2009

Re: [Pharo-project] [ANN] prebuild PharoCore-1.0-10414-BETA

by StÃ©phane Ducasse

Thanks marcus I hope to find some time this week to restart integrating item for 1.0 stef On Aug 17, 2009, at 11:27 PM, Marcus Denker wrote: > Hi, > > To save time... > > https://gforge.inria.fr/frs/download.php/22770/PharoCore-1.0-10414-BETA.zip > > > Marcus > > > -- > Marcus Denker - http://marcusdenker.de > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 18, 2009

Re: [Pharo-project] Bug or remnant to be stripped out?

by StÃ©phane Ducasse

Thanks this is a good news. Stef On Aug 18, 2009, at 11:37 AM, Gary Chambers wrote: > Feel free to clean up TWMDB... not needed here. > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, August 16, 2009 10:52 PM > Subject: Re: [Pharo-project] Bug or remnant to be stripped out? > > >> I think that gary needs it for its clients. >> Now the WorldMainMenuBar should not depend on ClockMorph which is a >> goody for example. >> There is a clear lack of registration for the worldMenuBar. >> >> Stef >> >> On Aug 16, 2009, at 10:27 PM, csrabak(a)bol.com.br wrote: >> >>> When the main dock bar is enabled in a Pharo1.0beta #10414 update, >>> an attempt to load updates from the Configuration->update from >>> server entry leads to a MNU: >>> >>> TheWorldMainDockingBar(Object)>>doesNotUnderstand: #updateFromServer >>> Receiver: a TheWorldMainDockingBar >>> Arguments and temporary variables: >>> aMessage: updateFromServer >>> exception: MessageNotUnderstood: >>> TheWorldMainDockingBar>>updateFromServer >>> resumeValue: nil >>> Receiver's instance variables: >>> a TheWorldMainDockingBar >>> . >>> >>> . >>> >>> . >>> >>> Is this a bug or or the issue is that main dock was supposed to be >>> removed? >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 18, 2009

[Pharo-project] System Window and OB model

by Fernando olivero

Quitting a system/hierarchy browser opened with the ToolSet, fails to inform the close to the model OB browser . For example in the following code 1 doesnt get explored | window | window := ToolSet browse: Set selector: anyOne. window model announcer observe: OBCloseRequest do:[:ann| 1 explore ]. Did anybody had this problem before? Or solved it already? Fernando

Aug. 18, 2009

Re: [Pharo-project] Bug or remnant to be stripped out?

by Gary Chambers

Feel free to clean up TWMDB... not needed here. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, August 16, 2009 10:52 PM Subject: Re: [Pharo-project] Bug or remnant to be stripped out? >I think that gary needs it for its clients. > Now the WorldMainMenuBar should not depend on ClockMorph which is a > goody for example. > There is a clear lack of registration for the worldMenuBar. > > Stef > > On Aug 16, 2009, at 10:27 PM, csrabak(a)bol.com.br wrote: > >> When the main dock bar is enabled in a Pharo1.0beta #10414 update, >> an attempt to load updates from the Configuration->update from >> server entry leads to a MNU: >> >> TheWorldMainDockingBar(Object)>>doesNotUnderstand: #updateFromServer >> Receiver: a TheWorldMainDockingBar >> Arguments and temporary variables: >> aMessage: updateFromServer >> exception: MessageNotUnderstood: >> TheWorldMainDockingBar>>updateFromServer >> resumeValue: nil >> Receiver's instance variables: >> a TheWorldMainDockingBar >> . >> >> . >> >> . >> >> Is this a bug or or the issue is that main dock was supposed to be >> removed? >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 18, 2009

[Pharo-project] Fwd: SequenceableCollection do: causes GCs with closure bytecodes

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: August 17, 2009 8:09:25 PM CEDT > To: Henrik Johansen <henrik.s.johansen(a)veloxit.no> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, Marcus Denker <denker(a)acm.org > >, John McIntosh <johnmci(a)smalltalkconsulting.com> > Subject: Re: [Pharo-project] SequenceableCollection do: causes GCs > with closure bytecodes > > > > On Mon, Aug 17, 2009 at 7:02 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > > > Begin forwarded message: > > From: Henrik Johansen <henrik.s.johansen(a)veloxit.no> > Date: August 17, 2009 3:21:53 PM CEDT > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] SequenceableCollection do: causes GCs with > closure bytecodes > Reply-To: Pharo-project(a)lists.gforge.inria.fr > > Something I noticed when looking at ByteArray>>hex, anyone know the > reason why there's GC going on in do: with closure images, but not > using the old bytecodes? > > Because with the old bytecodes a block activation simply reuses the > BlockContext allocated to implement the block whereas with the new > bytecodes a block activation allocates a new context. The stack VM > reduces context allocation markedly and so simple examples like the > below won't allocate. In the stack VM context allocation is > deferred until the context object is actually used. Contexts are > allocated on process switch, when a block is created or when > thisContext is used. > > HTH > > Even with no closed-over variables in the block, it seems it creates > extra fodder for the Garbage collector... > > Is it something the stack VM / Improved Garbage Collector will change? > > Cheers, > Henry > > Simple test: > intArray := (1 to: 10000000) asArray. > TimeProfileBrowser onBlock: [intArray do: [:ix | ix yourself]] > (It's not due to sampling overhead, Time millisecondsToRun: return > similiar runtimes) > > Without closures (I used 250): > -941 tallies, 965 msec. > **GCs** > incr 4 totalling 0ms > > With closures (I used 414): > -1938 tallies, 1938 msec. > **GCs** > inc 2510 totalling 614ms > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Aug. 18, 2009

Re: [Pharo-project] Native Windows

by David T. Lewis

On Mon, Aug 17, 2009 at 06:02:58PM -0700, John M McIntosh wrote: > Well let me comment > > For years the squeak community complained about the fact there was > just one window and morphic, and no way > to offer native widgets or have more than one window. > > The folks providing funding for Sophie complained about this same fact > too. > > So years ago, Tim and I spent a summer working out how to provide the > multiple window support for Squeak > aka Areithfa Ffenestri http://wiki.squeak.org/squeak/3862 > > It's quite simple, the HostWindowProxy proxy lets you manipulate the > window and draw to it. > The VM was changed so that Events *should* tag UI events with a window > index number. > EventSensor then brings up the events and hands them to who ever is > interested. > > It's all fully explained on the web page. > > We built it on the macintosh first, with *pending* support for the > other platforms. I'm sure Bert did a Linux variation. > mmm I'm sure windowIndex 0 refers to the main squeak window btw. FWIW, I did make a start at getting this working on X11 for unix VMs, but did not get the project finished. Background: http://lists.squeakfoundation.org/pipermail/vm-dev/2008-July/001977.html I can dig up the missing attachments if anyone is interested. Bert may have done some related work since then. Dave

Aug. 18, 2009

Re: [Pharo-project] Native Windows

by John M McIntosh

Before you run too far down the let's change Morphic path you should check with Igor I'm sure he was off a year back trying to hack Ffenestri into Morphic. Tim and I gave that thought up when we considered there was 400 or so references to EventSenor & Display many of which had no concept of window ownership in mind. On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: > Thanks so much for sharing on this. > > There seems to be a few caches of stuff stashed in various places. > None of it is exactly complete. I've taken the bulk of it from the http://source.impara.de/HostWindows > and a bit from your experimental directory and looked at the plugins > code in the VM tree and then just started trying to fix problems > with event delivery. I'd like to pull it all together and make it > coherent on Windows, OS X and Unix. > > Its really great that Pharo has integrated the HostMenus stuff - I > think it would be cool to do HostWindows too. Once you eliminate > having to emulate the look of the windows - most widget sets look > pretty similar and I think morphic widgets inside of real windows > would keep things from looking too weird while preserving the > benefits of having our widgets in Smalltalk. > > Given Pharo's "take no prisoners" attitude, I think getting host > windows working would allow a lot of really ugly code in > PasteUpMorph and HandMorph to just go away. Event delivery in > Morphic is just totally incomprehensible and I'm finding it is > broken when a second window is introduced as the mouse coordinates > seem to be delivered window relative. Its also really hard to work > on because I keep junking images by making changes that wreck the UI. > > -Todd Blanchard > -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Aug. 18, 2009

Re: [Pharo-project] Native Windows

by Eagle Offshore

Thanks so much for sharing on this. There seems to be a few caches of stuff stashed in various places. None of it is exactly complete. I've taken the bulk of it from the http://source.impara.de/HostWindows and a bit from your experimental directory and looked at the plugins code in the VM tree and then just started trying to fix problems with event delivery. I'd like to pull it all together and make it coherent on Windows, OS X and Unix. Its really great that Pharo has integrated the HostMenus stuff - I think it would be cool to do HostWindows too. Once you eliminate having to emulate the look of the windows - most widget sets look pretty similar and I think morphic widgets inside of real windows would keep things from looking too weird while preserving the benefits of having our widgets in Smalltalk. Given Pharo's "take no prisoners" attitude, I think getting host windows working would allow a lot of really ugly code in PasteUpMorph and HandMorph to just go away. Event delivery in Morphic is just totally incomprehensible and I'm finding it is broken when a second window is introduced as the mouse coordinates seem to be delivered window relative. Its also really hard to work on because I keep junking images by making changes that wreck the UI. -Todd Blanchard On Aug 17, 2009, at 6:02 PM, John M McIntosh wrote: > Well let me comment > > For years the squeak community complained about the fact there was > just one window and morphic, and no way > to offer native widgets or have more than one window. > > The folks providing funding for Sophie complained about this same fact > too. > > So years ago, Tim and I spent a summer working out how to provide the > multiple window support for Squeak > aka Areithfa Ffenestri http://wiki.squeak.org/squeak/3862 > > It's quite simple, the HostWindowProxy proxy lets you manipulate the > window and draw to it. > The VM was changed so that Events *should* tag UI events with a window > index number. > EventSensor then brings up the events and hands them to who ever is > interested. > > It's all fully explained on the web page. > > We built it on the macintosh first, with *pending* support for the > other platforms. I'm sure Bert did a Linux variation. > mmm I'm sure windowIndex 0 refers to the main squeak window btw. > > The original source code without complexity should sit in the > ftp.smalltalkconsulting.com/experimental/Ffenestri/ > changes sets > Ffenestri-b-1 thru b-4 > > You should be able to load it into a Squeak image from Jan 2007, > infact I rebuilt the change sets and tested them in a January 2007 > image > for a pending Squeak release let's see, oh yes the email for that is > attached at the end. > > We alter event sensor, as you know that was all changed in Pharo > It also alters Moprhic a bit so it understands windowIndex logic. > > Now about implementation, part of the problem is where does the events > go and where does the drawing go. > Lots of this is done in globals with no reference to the windowIndex. > > We had two implementations > (a) We alter Project, when you enter project it then set the Display, > so we could make a Project Window and drawing and mouse events would > go to it, I'm not sure > about todays version of Morphic but in the past you could have > multiple Projects open, but only one would be active, then others > would be *stopped* > > (b) We altered Tweak, Tweak at the time being the future vision of > Morphic and UI on Squeak. Tweak actually built an environment and > stuck the UI input queue and display information in an instance > variable associated with the Tweak world. So it was *trivial* to hook > up the host window proxy display logic and dispatch the events to the > proper Tweak world. > > (c) I lie, I believe Michael Rueger built a subset of morphic (or > something) that is Ffenestri aware, but I don't think it was ever > published. > > Out of this, there was a dull thud as the folks wanting multiple host > windows just failed to produce code using it. > The powers that be that directed Sophie decided in fact one window was > enough, so we never implemented things with multiple windows. > The version of Tweak we were using in Sophie was grave-yarded. > > > Maybe you could send me the details of your trail of MC loading since > I don't recall an Process or Delay overrides. We had lots of that in > Sophie via changes from Tweak/Qwaq to fix evil semaphore and process > bugs plus Tweak did process priority escalation to solve event > ordering/semaphore issues. > > On 17-Aug-09, at 3:05 PM, Eagle Offshore wrote: > >> Well, I may have spoken too soon. Digging into the platform specific >> window proxies - I see proxies for MacOS 9, OS X, Win32, and >> Acorn???, >> but nothing for linux. OTOH, I find source code for a HostWindows >> plugin in the Unix VM source tree. >> >> Anybody with more knowledge of why we have a plugin without a proxy? >> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > The 3.10 team asked me to build a change set for Ffenestri (multiple > host window support), and Mac Host Menus for 3.10. > The last change set was build for Tweak in 2004. > > I've updated my ftp site and my idisk in the Ffenestri folder found in > the experimental directory with a number of new > change sets that let you load the Ffenestri logic into a 3.10 image, > likely also into a 3.9 image. Testing shows that this re-released code > works with Mac PowerPC and MacIntel. I did uncover a byte order > problem on macintel btw. > > For the additional Macintosh Host menu support, used by Sophie, and by > Scratch I've also pushed out a set of change sets > to allow one to load that logic into a 3.10 image, likely also into a > 3.9 image too. Testing shows that this re-released code works with Mac > PowerPC and MacIntel. > > I did NOT revisit the Tweak support, there seems to be a LACK of > interest. Anyone who wants to explore that should email me and I'll > point out the methods of interest they can rework for Tweak. Of > course for Tweak you can open a tweak project in a host window and > expect everything to work since the display and event queue are > instance variables, not globals like in Morphic. > > > -------------------------- > Well I note the HostMenu support *is* in Pharo now, so you need to > very careful what the HostMenus-Events.1.cs does > -------------------------- > > > Ffenestri-b-1-HostWindowPlugin.2.cs > This is the plugin for host windows > > Ffenestri-b-2-WindowProxies.3.cs > Setup window proxis > > Ffenestri-b-3-MultiHostWindows-Sunits.1.cs > SUnits to test multiple window support, works on mac powerpc and > macIntel > Check with Impara about windows changes to enable support on Windows. > > Ffenestri-b-3-MultiHostWindows.1.cs > Add base support for Multiple windows. > > Ffenestri-b-4-Events-Morphic.1.cs > Adds multiple window support for base Morphic, see Sunits for usage. > > HostMenus-Base.2.cs > Add base support for Mac Host Windows. > > HostMenus-Events.1.cs > Add interface to EventSensor for mac host menus, assumes Ffenestri- > b-3- > MultiHostWindows.1.cs is loaded. > > HostMenus-Mac-SUnits.1.cs > SUnit to test mac host menu support, works on mac powerpc and > macIntel. > > HostMenus-Mac-MacPlugin.1.cs > This is the plugin that provides the menu support for os-9/os-x > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 18, 2009