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

Re: [Pharo-project] <deprecated> annotation?

by Lukas Renggli

>> What you think? > > How would that help anybody to find out whether they are relying on > deprecated methods? This seems like a big step backwards form a user > point of view. Suddenly a method is gone and you didn't get a warning. > You are you supposed to check for deprecated methods? Debug each and > every one of your message sends? +1, such an annotation is totally counterproductive. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 17, 2011

Re: [Pharo-project] <deprecated> annotation?

by Philippe Marschall

On 16.08.2011 19:51, Igor Stasenko wrote: > Hello, > > i know that we're already having #deprecated: , #deprecated: on: in: etc > > but one thing what i think useful about annotations that it is a way > to indicate that method is deprecated without showing a warning. > > The problem with using messages, that if you deprecate something which > used quite often by code, > you will be spammed with deprecation warnings all the time. > > So, i think that in addition to messages, we can use these > annotations, to indicate deprecated methods, in places where showing > warning(s) are not feasible > (for instance you cannot deprecate Deprecation>>showWarning, because > it will lead to infinite recurtion) > > There could be variations in same way as with messages: > > <deprecated> > <deprecated: '...' on: '..' in: '..'> > > etc. > > > What you think? How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning. You are you supposed to check for deprecated methods? Debug each and every one of your message sends? Yeah you could write tools support but we both know this isn't gonna happen. Cheers Philippe

Aug. 17, 2011

Re: [Pharo-project] Headless image hanging

by Bernat Romagosa

Thanks all! So I extended the table, let's see how it holds up now! Mariano, I know the vm's a little bit old, but I had already tried updating to the latest one and still had the same problem. Will update it anyway now that I noticed :) Thanks again! Cheers, 2011/8/17 Sven Van Caekenberghe <sven(a)beta9.be> > > On 17 Aug 2011, at 09:35, Mariano Martinez Peck wrote: > > > BTW, is not this the problem of Sempahores or I don't know what that you > need to change/make bigger in Cog ? > > Probably, http://code.google.com/p/pharo/issues/detail?id=4505 > > Hendrik fixed it for 1.4 > > You can manually extend the table in 1.2 like this: > > "Extend the external object table to allow for more sockets" > Smalltalk vmParameterAt: 49 put: 8192. > > This is only needed for Cog VMs. > > Sven > -- Bernat Romagosa.

Aug. 17, 2011

Re: [Pharo-project] Headless image hanging

by Sven Van Caekenberghe

On 17 Aug 2011, at 09:35, Mariano Martinez Peck wrote: > BTW, is not this the problem of Sempahores or I don't know what that you need to change/make bigger in Cog ? Probably, http://code.google.com/p/pharo/issues/detail?id=4505 Hendrik fixed it for 1.4 You can manually extend the table in 1.2 like this: "Extend the external object table to allow for more sockets" Smalltalk vmParameterAt: 49 put: 8192. This is only needed for Cog VMs. Sven

Aug. 17, 2011

Re: [Pharo-project] Policy for storing metacello configurations

by Damien Pollet

On 17 August 2011 08:59, Max Leske <maxleske(a)gmail.com> wrote: > Some people seem to have adopted MetacelloRepository as the standard repository for all configurations, others keep the configuration for a project in the project repositories and a third group uses both repositories (where one repository contains outdated versions of courseâ¦). The MetacelloConfiguration belongs to the project and is under responsibility of the developers, so one should be in the project's repo. MetacelloRepository is the central well-known place, so maybe only versions with a stable release really need to be there? There will be other well-known places, the idea is to have a curated one for each version of Pharo I believe. In any case, maybe part of this should be docuplemented into MetacelloToolBox ? (PS. toolbox is a proper english word, so that capital B in the class name is unnecessary :) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 17, 2011

Re: [Pharo-project] Headless image hanging

by Mariano Martinez Peck

And the assert is failing is indeed in sqExternalSemaphores.c Here: /* Signal the external semaphore with the given index. Answer non-zero on * success, zero otherwise. This function is (should be) thread-safe; * multiple threads may attempt to signal the same semaphore without error. * An index of zero should be and is silently ignored. */ sqInt signalSemaphoreWithIndex(sqInt index) { int i = index - 1; int v; /* An index of zero should be and is silently ignored. */ assert(index >= 0 && index <= numSignalRequests); if ((unsigned)i >= numSignalRequests) return 0; On Wed, Aug 17, 2011 at 9:37 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > BTW...your VM is quite "old". Why don't you give a try with a new one? > > > On Wed, Aug 17, 2011 at 9:35 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Wed, Aug 17, 2011 at 9:16 AM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: >> >>> Bernat, >>> >>> You could try to use the Finder to search the source(s) for this string >>> or parts of it. >>> I couldn't find it in my imageâ¦ >>> >>> >> That's an assert that is failing in the VM side. >> >> index >= 0 && index <= numSignalRequests 133 >> >> means that "index >= 0 && index <= numSignalRequests" evaluated to false, >> and 133 is the line number in the C code. >> >> BTW, is not this the problem of Sempahores or I don't know what that you >> need to change/make bigger in Cog ? >> >> >> >>> Sven >>> >>> On 17 Aug 2011, at 07:32, Bernat Romagosa wrote: >>> >>> > Hi list, >>> > >>> > I think I asked this a while ago but never managed to find a solution, >>> so here we go: >>> > >>> > I have an image running under a screen session in my server, it's >>> running my simple blog written in Iliad and nothing else. The image is a >>> Pharo 1.2.1 on a Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.75] >>> machine, the server is a VPSLink slice with Debian 5 on it. >>> > >>> > For a very long while now I've been experiencing a weird behaviour. The >>> image runs flawlessly and fast for a couple of days, then it hangs without >>> any apparent reason, just stops working overnight, and the only output I get >>> in the console is >>> > >>> > index >= 0 && index <= numSignalRequests 133 >>> > >>> > repeatedly, and after that the website can't be accessed neither can I >>> reach the image via VNC, so the only solution is to kill the process and >>> fire it up again... >>> > >>> > Any clues? Is this a known bug? >>> > >>> > Cheers, >>> > >>> > -- >>> > Bernat Romagosa. >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Aug. 17, 2011

Re: [Pharo-project] Headless image hanging

by Mariano Martinez Peck

BTW...your VM is quite "old". Why don't you give a try with a new one? On Wed, Aug 17, 2011 at 9:35 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Wed, Aug 17, 2011 at 9:16 AM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > >> Bernat, >> >> You could try to use the Finder to search the source(s) for this string or >> parts of it. >> I couldn't find it in my imageâ¦ >> >> > That's an assert that is failing in the VM side. > > index >= 0 && index <= numSignalRequests 133 > > means that "index >= 0 && index <= numSignalRequests" evaluated to false, > and 133 is the line number in the C code. > > BTW, is not this the problem of Sempahores or I don't know what that you > need to change/make bigger in Cog ? > > > >> Sven >> >> On 17 Aug 2011, at 07:32, Bernat Romagosa wrote: >> >> > Hi list, >> > >> > I think I asked this a while ago but never managed to find a solution, >> so here we go: >> > >> > I have an image running under a screen session in my server, it's >> running my simple blog written in Iliad and nothing else. The image is a >> Pharo 1.2.1 on a Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.75] >> machine, the server is a VPSLink slice with Debian 5 on it. >> > >> > For a very long while now I've been experiencing a weird behaviour. The >> image runs flawlessly and fast for a couple of days, then it hangs without >> any apparent reason, just stops working overnight, and the only output I get >> in the console is >> > >> > index >= 0 && index <= numSignalRequests 133 >> > >> > repeatedly, and after that the website can't be accessed neither can I >> reach the image via VNC, so the only solution is to kill the process and >> fire it up again... >> > >> > Any clues? Is this a known bug? >> > >> > Cheers, >> > >> > -- >> > Bernat Romagosa. >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Aug. 17, 2011

Re: [Pharo-project] Headless image hanging

by Mariano Martinez Peck

On Wed, Aug 17, 2011 at 9:16 AM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > Bernat, > > You could try to use the Finder to search the source(s) for this string or > parts of it. > I couldn't find it in my imageâ¦ > > That's an assert that is failing in the VM side. index >= 0 && index <= numSignalRequests 133 means that "index >= 0 && index <= numSignalRequests" evaluated to false, and 133 is the line number in the C code. BTW, is not this the problem of Sempahores or I don't know what that you need to change/make bigger in Cog ? > Sven > > On 17 Aug 2011, at 07:32, Bernat Romagosa wrote: > > > Hi list, > > > > I think I asked this a while ago but never managed to find a solution, so > here we go: > > > > I have an image running under a screen session in my server, it's running > my simple blog written in Iliad and nothing else. The image is a Pharo 1.2.1 > on a Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.75] machine, > the server is a VPSLink slice with Debian 5 on it. > > > > For a very long while now I've been experiencing a weird behaviour. The > image runs flawlessly and fast for a couple of days, then it hangs without > any apparent reason, just stops working overnight, and the only output I get > in the console is > > > > index >= 0 && index <= numSignalRequests 133 > > > > repeatedly, and after that the website can't be accessed neither can I > reach the image via VNC, so the only solution is to kill the process and > fire it up again... > > > > Any clues? Is this a known bug? > > > > Cheers, > > > > -- > > Bernat Romagosa. > > > -- Mariano http://marianopeck.wordpress.com

Aug. 17, 2011

Re: [Pharo-project] Headless image hanging

by Sven Van Caekenberghe

Bernat, You could try to use the Finder to search the source(s) for this string or parts of it. I couldn't find it in my imageâ¦ Sven On 17 Aug 2011, at 07:32, Bernat Romagosa wrote: > Hi list, > > I think I asked this a while ago but never managed to find a solution, so here we go: > > I have an image running under a screen session in my server, it's running my simple blog written in Iliad and nothing else. The image is a Pharo 1.2.1 on a Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.75] machine, the server is a VPSLink slice with Debian 5 on it. > > For a very long while now I've been experiencing a weird behaviour. The image runs flawlessly and fast for a couple of days, then it hangs without any apparent reason, just stops working overnight, and the only output I get in the console is > > index >= 0 && index <= numSignalRequests 133 > > repeatedly, and after that the website can't be accessed neither can I reach the image via VNC, so the only solution is to kill the process and fire it up again... > > Any clues? Is this a known bug? > > Cheers, > > -- > Bernat Romagosa.

Aug. 17, 2011

Re: [Pharo-project] Fwd: [Pharo-fuel] Two nice things I did in 2 hours with Fuel

by laurent laffont

Do I hear "remote tools" ? Laurent On Tue, Aug 16, 2011 at 9:37 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > This clearly opens the door to really amazing experiment. > > Stef > > *From: *Mariano Martinez Peck <marianopeck(a)gmail.com> > *Date: *August 16, 2011 8:58:03 PM GMT+02:00 > *To: *The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > *Subject: **[Pharo-fuel] Two nice things I did in 2 hours with Fuel* > *Reply-To: *The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > > 1) serialize a living debugger, materialize it in another image and > continue debugging. > 2) use Fuel to serialize a graph to a bytearray and then store and retrieve > that from the Riak NoSQL database :) > > coooool! > > -- > Mariano > http://marianopeck.wordpress.com > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > >

Aug. 17, 2011