- Pharo-dev - lists.pharo.org

Re: [Pharo-project] how pass an instruction in an already running image

by Pavel Krivanek

Maybe some more complex version of this: http://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ker… -- Pavel On Mon, Nov 5, 2012 at 12:04 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Nice. I already thought about the Seaside interface. > > But, what do I do if I want to script the commands? For example, I would > like to orchestrate the building of a new image in the background, and when > the second one is ready to shut down the first one. > > Cheers, > Doru > > > On Mon, Nov 5, 2012 at 11:01 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> Hi Doru, >> >> On 05 Nov 2012, at 10:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> I have a running image that I trigger from the command line. What ways >> are there to make this running image react to some other command sent from >> the command line? >> >> Cheers, >> Doru >> >> >> The ideal solution, IMO, would be some local telnet access that gives you >> a REPL. >> >> What I do with server images, is to install a small, protected Seaside >> application that groups a number of the tools already present in Seaside >> into a control panel: a browser, an inspector that can also execute code >> and some status views. This gives you a primitive but effective interface >> to see what is going on. It works surprisingly well. >> >> You can find the code here: >> >> MCHttpRepository >> location: 'http://mc.stfx.eu/BetaNinePublic' >> user: '' >> password: '' >> >> BetaNine-Seaside-Pi-SvenVanCaekenberghe.2 >> >> Here are some screenshots: >> >> >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > >

Nov. 5, 2012

Re: [Pharo-project] how pass an instruction in an already running image

by Tudor Girba

Nice. I already thought about the Seaside interface. But, what do I do if I want to script the commands? For example, I would like to orchestrate the building of a new image in the background, and when the second one is ready to shut down the first one. Cheers, Doru On Mon, Nov 5, 2012 at 11:01 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Doru, > > On 05 Nov 2012, at 10:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I have a running image that I trigger from the command line. What ways are > there to make this running image react to some other command sent from the > command line? > > Cheers, > Doru > > > The ideal solution, IMO, would be some local telnet access that gives you > a REPL. > > What I do with server images, is to install a small, protected Seaside > application that groups a number of the tools already present in Seaside > into a control panel: a browser, an inspector that can also execute code > and some status views. This gives you a primitive but effective interface > to see what is going on. It works surprisingly well. > > You can find the code here: > > MCHttpRepository > location: 'http://mc.stfx.eu/BetaNinePublic' > user: '' > password: '' > > BetaNine-Seaside-Pi-SvenVanCaekenberghe.2 > > Here are some screenshots: > > > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 5, 2012

Re: [Pharo-project] Committing on dead squeak source freezes to death my system

by Sven Van Caekenberghe

On 05 Nov 2012, at 11:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > I thought that there was a timeout to reach a server and that after I could get back the system. > Right now I cannot. I'm using the latest pharo2.0 and I could not unfreeze it. > Any idea suggestions? > Stef ZnNetworkingUtils class>>#defaultSocketStreamTimeout is 30 seconds McHttpRepository>>#httpClient has #systemPolicy which means there will be 2 retries Monticello does multiple reads and writes when you save So it will take a long time to time outâ¦ I and many others would vote for a much shorter timeout, like 5 seconds. Either it works or not. Sven

Nov. 5, 2012

[Pharo-project] Committing on dead squeak source freezes to death my system

by StÃ©phane Ducasse

Hi I thought that there was a timeout to reach a server and that after I could get back the system. Right now I cannot. I'm using the latest pharo2.0 and I could not unfreeze it. Any idea suggestions? Stef

Nov. 5, 2012

Re: [Pharo-project] how pass an instruction in an already running image

by Sven Van Caekenberghe

Hi Doru, On 05 Nov 2012, at 10:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I have a running image that I trigger from the command line. What ways are there to make this running image react to some other command sent from the command line? > > Cheers, > Doru The ideal solution, IMO, would be some local telnet access that gives you a REPL. What I do with server images, is to install a small, protected Seaside application that groups a number of the tools already present in Seaside into a control panel: a browser, an inspector that can also execute code and some status views. This gives you a primitive but effective interface to see what is going on. It works surprisingly well. You can find the code here: MCHttpRepository location: 'http://mc.stfx.eu/BetaNinePublic' user: '' password: '' BetaNine-Seaside-Pi-SvenVanCaekenberghe.2 Here are some screenshots: Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Nov. 5, 2012

[Pharo-project] how pass an instruction in an already running image

by Tudor Girba

Hi, I have a running image that I trigger from the command line. What ways are there to make this running image react to some other command sent from the command line? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Nov. 5, 2012

Re: [Pharo-project] Are the any Fuel file analysis tools/techniques?

by Mariano Martinez Peck

On Mon, Nov 5, 2012 at 5:24 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 04/11/12 6:43 AM, Mariano Martinez Peck wrote: > >> But this only works for the serialization, not for the materialization. >> > > FLMaterializer>>**materializeFromFileNamed: aFilename > ^ (self materializationFromFileNamed: aFilename) root > > I've been using #materializeFromFileNamed: in my code, but I just happened > to pick #materializationFromFileNamed: while debugging another problem, a > moment ago. > > When I inspect the resulting FLMaterialization object, I can see the > clusters - which is exacting what I was looking for a few days ago. By > scanning the clusters, it should have been easy to figure out what objects > should never have been serialized (e.g. WASession). Which was a critical > clue to figure out where to look for where the extra objects were coming > from. > > > Yes, you are totally right. What I ment is that at this point (to be able to inspect instVar 'clusters') the materialization has already happened, I mean, the graph is already materialized and in memory. That's why I was suggesting that maybe it was better to get this info before the serialization itself. But anyway, yes, this will also be helpful. -- Mariano http://marianopeck.wordpress.com

Nov. 5, 2012

Re: [Pharo-project] Are the any Fuel file analysis tools/techniques?

by Yanni Chiu

On 04/11/12 6:43 AM, Mariano Martinez Peck wrote: > But this only works for the serialization, not for the materialization. FLMaterializer>>materializeFromFileNamed: aFilename ^ (self materializationFromFileNamed: aFilename) root I've been using #materializeFromFileNamed: in my code, but I just happened to pick #materializationFromFileNamed: while debugging another problem, a moment ago. When I inspect the resulting FLMaterialization object, I can see the clusters - which is exacting what I was looking for a few days ago. By scanning the clusters, it should have been easy to figure out what objects should never have been serialized (e.g. WASession). Which was a critical clue to figure out where to look for where the extra objects were coming from.

Nov. 5, 2012

Re: [Pharo-project] About a object life

by Edgar J. De Cleene

On 11/4/12 4:33 PM, "Craig Latta" <craig(a)netjam.org> wrote: > > Hi Edgar-- > > Do you really want to know how old an object is, or just whether > it's older than some other object? If you don't care about degrading the > identity hash distribution, you could steal a few bits from the object > header for a counter. Craig: Like to know how old an object is. As my reply to Hans-Martin, guess this is not possible in current Pharo/Squeak. Nice to read you ! Edgar

Nov. 4, 2012

Re: [Pharo-project] PluggableListMorph error, how to debug ?

by Alexandre Bergel

Excellent tip!! Alexandre On Nov 4, 2012, at 2:37 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > In Pharo 1.4, browse Morph > Find the method fullDrawOn: > > and replace > > on: Error do: [:err | > self setProperty: #errorOnDraw toValue: true. > self setProperty: #drawError toValue: err freeze. > ^ self drawErrorOn: aCanvas > ] > > by: > value > > Now you will have a debugger instead of the red square of death > > But do it at you own risk ^^ > Ben > > On Nov 4, 2012, at 6:04 PM, laurent laffont wrote: > >> Hi, >> >> sometimes I have a PluggableListMorph that displays a big red square (see attached screenshot). How can I debug why this happens ? >> >> <image.png> >> >> Cheers, >> >> Laurent > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 4, 2012