- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3566 in pharo: Changes needed to update Sound for 1.2

by pharo＠googlecode.com

Updates: Status: Started Comment #7 on issue 3566 by marcus.d...(a)gmail.com: Changes needed to update Sound for 1.2 http://code.google.com/p/pharo/issues/detail?id=3566 I can not merge in 1.2 DNU for #dependencies on nil

Jan. 22, 2011

Re: [Pharo-project] Instruments for headless images

by StÃ©phane Ducasse

tx On Jan 21, 2011, at 11:19 PM, Eliot Miranda wrote: > > > 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. 22, 2011

Re: [Pharo-project] Issue 3570 in pharo: EdgeGripMorph DNU when resizing

by pharo＠googlecode.com

Updates: Status: Fixed Labels: Milestone-1.3 Comment #2 on issue 3570 by marcus.d...(a)gmail.com: EdgeGripMorph DNU when resizing http://code.google.com/p/pharo/issues/detail?id=3570 12319 TODO: 1.3

Jan. 22, 2011

Re: [Pharo-project] Pharo on the iPhone

by Hilaire Fernandes

Check with Bert, Bert help me to make working DrGeo on the iPhone, he integrates some changes in the Pharo image for that. I will check that in a few week. One aspect we have to do, is to produce a Pharo theme mathcing the iPhone/iPAD UI guideline. I have not yet started the effort on that department, but we could collaborate on that topic. Hilaire Le 21/01/2011 02:10, Alexandre Bergel a Ã©crit : > Hi! > > iPhone 4 is amazing. It will be even better with Pharo inside. Is there a way to install it? > > Cheers, > Alexandre > > NB: my device is non jailbreaked. > -- Education 0.2 -- http://blog.ofset.org/hilaire

Jan. 22, 2011

Re: [Pharo-project] for coral

by Marcus Denker

On Jan 22, 2011, at 9:15 AM, StÃ©phane Ducasse wrote: > We should: > > - use this list > - have a plan Item 1: Hudson Project for Coral. :-) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 22, 2011

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