January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] PharoSound

by Hilaire Fernandes

Le 21/01/2011 20:39, Henrik Sperre Johansen a Ã©crit : > And yes, they include all changes from NonCorePackages, plus preserve > all settings so you can avoid crashing the VM if you want :) Thanks to clarify! I will contribute to the sound effort latter in the year, but not right now. Hilaire

Jan. 22, 2011

[Pharo-project] for coral

by StÃ©phane Ducasse

We should: - use this list - have a plan so adrien can you give a list of features and milestone (the deamon was just a test) - for me I have - clean command line infrastructure - install UIDummyManager controlling no pop up - robust auto install of coral - samples of code - start documenting FileSystem Stef

Jan. 22, 2011

[Pharo-project] Fwd: [squeak-dev] Instruments for headless images

by StÃ©phane Ducasse

Begin forwarded message: > From: Chris Muller <asqueaker(a)gmail.com> > Date: January 20, 2011 10:05:44 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Cc: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Subject: Re: [Pharo-project] [squeak-dev] Instruments for headless images > Reply-To: Pharo-project(a)lists.gforge.inria.fr, ma.chris.m(a)gmail.com > > The Ma stack does something similar, although not crippling the system > to the same extent. > > How do you determine you're running headless? I attached my > implementation of #maIsHeadless for determining whether the VM was > launched headless. Perhaps we should integrate this functionality > into Squeak and Pharo (or a variant without the prefix, of course). > > Then, I use MaCommandLineProcessor which is concerned with handling > the command-line Squeak was launched with: > > Then, I write my .st scripts like: > > MaCommandLineProcessor do: > [ : arg1 : arg2 : arg3 : etc | > "my batch code script..." > "args come in as Strings." > "... you can have a variable number of args." ] > > as well as a uniform error-handler for all scripts, to redirect to > stdout and stderr, thusly: > > MaCommandLineProcessor class>>#do: aBlock > | stdOut stdErr | > self ensureStartedUp. > stdOut := StandardFileStream stdout. > stdErr := StandardFileStream stderr. > [ aBlock valueWithAllArguments: self args ] > on: Notification , Warning > do: > [ : noti | stdOut > nextPutAll: DateAndTime now asString ; space ; > nextPutAll: noti description ; > perform: MultiByteFileStream lineEndDefault. > noti resume ] > on: SyntaxErrorNotification > do: > [ : err | stdOut > nextPutAll: err errorCode ; > perform: MultiByteFileStream lineEndDefault. > self haltOrQuit ] > on: Error > do: > [ : err | stdErr > nextPutAll: 'ERROR: ' ; > nextPutAll: DateAndTime now asString ; space ; > perform: MultiByteFileStream lineEndDefault ; > nextPutAll: err description ; > perform: MultiByteFileStream lineEndDefault. > err isMaUserError ifFalse: > [ stdErr nextPutAll: > (err signalerContext longStack > copyReplaceAll: Character cr asString > with: (String perform: MultiByteFileStream lineEndDefault)) ]. > self haltOrQuit ] > > #haltOrQuit is where it checks #maIsHeadless to determine whether to > halt or quit. > > MaCommandLineProcessor is part of "Ma base additions" package, so any > of the "Ma" softwares (Magma, Maui, Ma client server, etc.) will have > it. But I think it would be useful to put this (or, a variant) > directly into a future Squeak. > > - Chris > > > On Thu, Jan 20, 2011 at 2:39 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> Hello folks. >> >> I'd like to ask, if there any 'standartized' instruments for headless >> images (or alike). >> >> I need a simple things: >> - redirect all ToolSet/UIManager messages to Transcript >> - redirect Transcript logging to file or stdout >> >> in short, these tools should serve a simple, yet important purpose: >> - if image runs in headless mode, it should suppress anything which >> expecting user interaction (like showing warnings with 'continue' >> button) and either log such messages to file >> or simply quit image with error message. >> >> Without such tool it is quite difficult to monitor, what happens with >> your headless image.. unless you have RFB installed.. but that is >> different and unrelated story. >> >> >> I did a prototype once for Hydra (you can check it at >> SqS/HydraVM/HydraVM.mcz package) >> there are two subclasses: >> - MorphicUIManager subclass: #HydraUIManager >> - StandardToolSet subclass: #HydraDebugToolSet >> >> and >> - WriteStream subclass: #HydraTranscript >> >> which can be installed as a Transcript. >> >> And in order to prepare image to run in headless mode, i issued: >> ToolSet unregister: StandardToolSet. >> ToolSet register: HydraDebugToolSet. >> UIManager default: HydraUIManager new. >> >> Also, HydraTranscript >> startUp does something like: >> >> TranscriptStream >> newTranscript: (self basicNew initialize >> on: (String new: 1000)) >> >> >> With that i could run the image in headless mode, knowing that in case >> of error or warning etc, all will be redirected to transcript, >> moreover i even stopped the UI process, so it never run on headless images. >> >> I wonder if there are other work, which can offer similar, >> and is there any way to detect that image are running in headless mode? >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> >

Jan. 22, 2011

Re: [Pharo-project] Some important news

by Tony Fleig

Excellent. Where do I sign up? On Fri, Jan 21, 2011 at 11:26 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > some important news today, we decided that we will set up a pharo association > so that we can promote pharo. We would like to be able to collect money and > create bounties to improve pharo. > > Stef >

Jan. 22, 2011

Re: [Pharo-project] Instruments for headless images

by David T. Lewis

On Fri, Jan 21, 2011 at 08:44:23PM +0100, Igor Stasenko wrote: > > that what i meant by saying 'VM support' SqueakVMs don't have such primitive. > But maybe we don't need it, because i think it would be much better to > give image a full control upon creation/closing of host windows. > So, image could decide by own what to do (and then you even don't need > to a special handling in VM for headless mode, since it will be a > decision which image does, not VM). > Maybe slightly off topic, but with an interpreter VM on X11 you can do this: OSProcess thisOSProcess processAccessor primKillDisplay. (Delay forSeconds: 5) wait. OSProcess thisOSProcess processAccessor primOpenXDisplay In other words, close the display under control of the image, and open it again under control of the image. You can also reopen the display on any X11 server willing to accept the connection (i.e. close the display on your current machine and reopen it somewhere else). VM support is in XDisplayControlPlugin (on SqueakSource). It should be possible to make it work with Cog also. The equivalent functionality for Windows and non-X11 Mac would work quite differently, so putting it in a plugin is a good approach. I agree with Eliot's recommendation that the display should be opened by the image after the image is started, rather than opened by the VM before the image is started. IIRC this has been discussed in the past but has not been implemented. Dave

Jan. 22, 2011

Re: [Pharo-project] Issue 3506 in pharo: TextMorph's #autoFit: and #wrapFlag: are confusing

by pharo＠googlecode.com

Comment #4 on issue 3506 by sean.p.d...(a)gmail.com: TextMorph's #autoFit: and #wrapFlag: are confusing http://code.google.com/p/pharo/issues/detail?id=3506 Okay, I'll look for the files

Jan. 22, 2011

Re: [Pharo-project] Some important news

by S Krish

Great News.. On Sat, Jan 22, 2011 at 12:56 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi guys > > some important news today, we decided that we will set up a pharo > association > so that we can promote pharo. We would like to be able to collect money and > create bounties to improve pharo. > > Stef >

Jan. 22, 2011

[Pharo-project] collapsing panes

by Tudor Girba

Hi, I have a question about how to obtain an effect similar to minimizing a pane in Eclipse. Let's consider the example from below. I have a ProportionalLayout because I want to fill the entire space and be able to resize the inside panes. Now, I would also like to have some way of collapsing one of the panes and have the rest resize to fill the rest of the space. It's a bit like I would need some part of a behavior from the TableLayout. Can anyone provide me with some hints in this direction? Do I need to create a new Layout? | container morph1 morph2 morph3 window | container := PanelMorph new. morph1 := PanelMorph new fillStyle: (SolidFillStyle color: Color red). morph2 := PanelMorph new fillStyle: (SolidFillStyle color: Color blue). morph3 := PanelMorph new fillStyle: (SolidFillStyle color: Color yellow). container changeProportionalLayout. container addMorph: morph1 fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0.33)). container addMorph: morph2 fullFrame: (LayoutFrame fractions: (0 @ 0.33 corner: 1 @ 0.66)). container addMorph: morph3 fullFrame: (LayoutFrame fractions: (0 @ 0.66 corner: 1 @ 1)). container addPaneSplitters. container fillStyle: (SolidFillStyle color: Color yellow). container extent: 400@400. container openInWindow. Cheers, Doru -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by Eliot Miranda

On Fri, Jan 21, 2011 at 1:35 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Eliot > > it is possible with the current vms? > I think not, but I think its really really close. Basically instead of the VM responding to -headless you'd have the image respond to -headless and arrange that all the code that starts-up the GUI window is called from a new primitive, say, openDisplay. Right now (I think) the VM decides whether to open up the main display or not, and does so by looking for a -headless argument, and if not found, opening the GUI window which remains blank. Ask Igor to trace through the startup code on each platform, looking for "headless" in the source and I'm sure he'll find it. best Eliot > Stef > On Jan 21, 2011, at 9:15 PM, Eliot Miranda wrote: > > > > > > > On Fri, Jan 21, 2011 at 11:44 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Eliot > > > > does it mean that we could run headless and that if specified on the > command line we could for example get a debugger open on bugs? Because I > would love that for coral. > > > > Exactly. In fact I think one mode is that one can get the system to > snapshot when the error happens, one can then send the snapshot to a > developer, and the snapshot comes up headful with the debugger. > > > > > > Stef > > > > >

Jan. 21, 2011

[Pharo-project] Fwd: Thanks !!!

by StÃ©phane Ducasse

Hi lille/douai/bruxelles pharo sprinters Thanks for all this good energy. Yesterday I went to a javascript conference and my energy was low to see how we (smalltalkers) would better organized and pushing. Now today it was good energy. Thanks again. Stef

Jan. 21, 2011