November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Squeaksource down, are people using something else?

by StÃ©phane Ducasse

On Nov 5, 2012, at 3:52 PM, GÃ¶ran Krampe wrote: > Hey! > > I just started out with a new web app and was going to use Pharo etc, but... I can't even get going since SS is down. > > Now... am I missing something obvious that people already know how to work around this - or? Nicolas is working on a new version of SmalltalkHub to support - projects - private projects so that companies can have less to worry about that and can use SmalltalkHub for growing their business The plan is that in two weeks the new version of SHub is out. Then we will start to move systematically to SmalltalkHub. Stef > > regards, GÃ¶ran >

Nov. 5, 2012

[Pharo-project] Squeaksource down, are people using something else?

by GÃ¶ran Krampe

Hey! I just started out with a new web app and was going to use Pharo etc, but... I can't even get going since SS is down. Now... am I missing something obvious that people already know how to work around this - or? regards, GÃ¶ran

Nov. 5, 2012

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

by Noury Bouraqadi

On 5 nov. 2012, at 11:45, Sven Van Caekenberghe wrote: > 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 Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury -- Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

Nov. 5, 2012

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