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

Re: [Pharo-project] How to resurrect an unrepsonsive image?

by Javier PimÃ¡s

Probably you have a crash.dmp or a PharoDebug.log which tells you what is happening. Look at the backtrace to see what causes the error and then maybe there's some way to help you fixing it. Cheers, Javier. On Wed, Dec 7, 2011 at 10:47 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > I have a headless image that was running for a couple of days. Now it is > not responding anymore. The image was running still but the sockets for > http and vnc were closed and restarting the image just brings it up without > any sockets opened. > Injecting something via script does not work either. I copied the image to > my desktop and tried a few things but no success. > What would be a good way to get a glimpse of what is causing problems? > I had Scheduler running that saved the image every hour. And the image > itself issues http request to the outside world every 10 minutes. > > thanks, > > Norbert > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Dec. 7, 2011

Re: [Pharo-project] How to resurrect an unrepsonsive image?

by Schwab,Wilhelm K

The worst thing a computer can do is grind to a halt and leave no trace of why it happened. In Dolphin, I had some success rigging deployed images (runtime session managers) to, on control-break, log callstacks for all non-dead processes. Conditions in which two threads were each waiting on the other to do something were fairly obvious from the callstacks. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Norbert Hartl [norbert(a)hartl.name] Sent: Wednesday, December 07, 2011 4:47 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] How to resurrect an unrepsonsive image? I have a headless image that was running for a couple of days. Now it is not responding anymore. The image was running still but the sockets for http and vnc were closed and restarting the image just brings it up without any sockets opened. Injecting something via script does not work either. I copied the image to my desktop and tried a few things but no success. What would be a good way to get a glimpse of what is causing problems? I had Scheduler running that saved the image every hour. And the image itself issues http request to the outside world every 10 minutes. thanks, Norbert

Dec. 7, 2011

Re: [Pharo-project] Having a shared package-cache Re: MCDirectoryRepository defaultDirectoryName ignored?

by Sean P. DeNigris

Mariano Martinez Peck wrote > > I have no idea :( > Probably not worth wading through to find out. I'll just keep #default: and add a setting. -- View this message in context: http://forum.world.st/Having-a-shared-package-cache-Re-MCDirectoryRepositor… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 7, 2011

Re: [Pharo-project] [Moose-dev] weird cursor behavior by copy/pasting stuff

by Sean P. DeNigris

Mariano Martinez Peck wrote > > I noticed the same in another image, where KeyMapping is installed. > Maybe this is related? > Keymapping also conflicts with OB. See http://forum.world.st/Chasing-Browsers-td4102608.html Do we report Keymapping bugs in Pharo ( until SmalltalkHub is ready :) ) -- View this message in context: http://forum.world.st/Re-Moose-dev-weird-cursor-behavior-by-copy-pasting-st… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 7, 2011

Re: [Pharo-project] Having a shared package-cache Re: MCDirectoryRepository defaultDirectoryName ignored?

by Mariano Martinez Peck

On Wed, Dec 7, 2011 at 5:25 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > Mariano Martinez Peck wrote > > > > MCCacheRepository default > > directory: (FileDirectory on: '/Users/mariano/Pharo/sharedRepo'). > > > > If you just change the directory on the default instance, it would not > reset > the rest of the instance's state e.g. the 'cache' instVar. I don't know if > that matters. > I have no idea :( > > -- > View this message in context: > http://forum.world.st/Having-a-shared-package-cache-Re-MCDirectoryRepositor… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

Dec. 7, 2011

Re: [Pharo-project] [Moose-dev] weird cursor behavior by copy/pasting stuff

by Mariano Martinez Peck

On Wed, Dec 7, 2011 at 6:05 PM, Fabrizio Perin <perin(a)iam.unibe.ch> wrote: > Hi all, > I just download the last Moose build from the server and i notice a weird > cursor behavior: > If i copy/paste something either in a workspace or into a code browser i > find the cursor at the beginning of the pasted code intend of at the end. > Is it a Moose related problem? Is it a new pharo feature? Or my image is > possessed by the devil? Thanks for any help. > > I noticed the same in another image, where KeyMapping is installed. Maybe this is related? > Cheers, > Fabrizio > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- Mariano http://marianopeck.wordpress.com

Dec. 7, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 92 - TSortable

by Sean P. DeNigris

Thanks, Steph! -- View this message in context: http://forum.world.st/Re-Pharo-users-COTDC-92-TSortable-tp4166516p4169581.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 7, 2011

Re: [Pharo-project] Loading MCZ freezes, but loading the source.st works?

by Stefan Marr

On 07 Dec 2011, at 12:34, Henrik Sperre Johansen wrote: > I can't claim to know exactly, but I seem to remember it does batches of new, then changed, then removed methods. > Other than that, I think they happen "seemingly" at random. > There are many sorts of internal dependencies, so other than the old workaround of making multiple .mcz's without internal dependencies, one kind of needs an insight into what exactly was at fault here to see if anything could be improved of the loading order in the general case, which does not simultaneously break something else... For me the question is: is the fileout/source.st order in which changes are applied more stable/less prone to such errors? And in my example, it is. But I haven't looked into the implementation of either. Anyway, it might not be 'stable', but I can remove a single override on Symbol>>#precedence and now it loads. Would there be any way other than splitting up packages? Because from a semantic perspective, it just does not make sense to split these things up. The typical separation of core system and overrides does also not help, since here, the dependency is between the overrides. Thanks Stefan > > Cheers, > Henry > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Dec. 7, 2011

Re: [Pharo-project] Having a shared package-cache Re: MCDirectoryRepository defaultDirectoryName ignored?

by Sean P. DeNigris

Mariano Martinez Peck wrote > > MCCacheRepository default > directory: (FileDirectory on: '/Users/mariano/Pharo/sharedRepo'). > If you just change the directory on the default instance, it would not reset the rest of the instance's state e.g. the 'cache' instVar. I don't know if that matters. -- View this message in context: http://forum.world.st/Having-a-shared-package-cache-Re-MCDirectoryRepositor… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 7, 2011

Re: [Pharo-project] UIManager

by StÃ©phane Ducasse

>> > I assume that means these are not cases where input is not critical, and the compiler always has a backup path? > Would that mean it might be an idea to instead use Notifications here, and let the caller handle them if necessary/appropriate? Yes I think so.

Dec. 7, 2011