- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] 5965 Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup!

by Sven Van Caekenberghe

On 23 May 2012, at 19:48, Marcus Denker wrote: > No, the image as it is now just quits. Delayed our deployment of the ESUG registration server > for some weeks... normal seaside use, image quites after a day. > > It's far from obvious. > > I think the image should work out of the box. Why destinguish between deployment and development? > What is good in deployment is for sure gut in development. It might be a bit surprising, but I think Hendrik's reasoning is quite good: you don't want to keep on expanding when there are problems not freeing resources that are limited. A good server needs resource limits. We can discuss more tomorrowâ¦ Sven

May 23, 2012

Re: [Pharo-project] [ANN] 5965 Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup!

by Igor Stasenko

On 23 May 2012 19:55, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 23, 2012, at 7:49 PM, Marcus Denker wrote: > >> >> On May 23, 2012, at 7:41 PM, Igor Stasenko wrote: >> >>> On 23 May 2012 18:57, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>>> Hey guys, >>>> >>>> this is kind of a show stopper for images in production :/ >>>> http://code.google.com/p/pharo/issues/detail?id=5965 >>>> >>> >>> i thought we already dealt with it. >>> no? >>> >> >> No, the image as it is now just quits. Delayed our deployment of the ESUG registration server >> for some weeks... > Â Â Â Â Â Â Â Â Â ^^^^^^^ > Â Â Â Â Â Â Â Â Â Â days of course. "It's down" "strange, Â I restarted". "Again" "Wow. But wait, there is an > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â error message". > > This has to be done better. There should not be a destinction of "deployment" and "development" > on that level. > Definitely. > Â Â Â Â Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > -- Best regards, Igor Stasenko.

May 23, 2012

Re: [Pharo-project] [ANN] 5965 Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup!

by Igor Stasenko

On 23 May 2012 19:48, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 23, 2012, at 7:41 PM, Igor Stasenko wrote: > >> On 23 May 2012 18:57, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>> Hey guys, >>> >>> this is kind of a show stopper for images in production :/ >>> http://code.google.com/p/pharo/issues/detail?id=5965 >>> >> >> i thought we already dealt with it. >> no? >> > > No, the image as it is now just quits. Delayed our deployment of the ESUG registration server > for some weeks... normal seaside use, image quites after a day. > > It's far from obvious. > > I think the image should work out of the box. Why destinguish between deployment and development? > What is good in deployment is for sure gut in development. > perhaps we should write a watchdog of external semaphore table. to see if semaphore orphaned and detect by whom. > Â Â Â Â Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > -- Best regards, Igor Stasenko.

May 23, 2012

Re: [Pharo-project] [ANN] 5965 Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup!

by Eliot Miranda

On Wed, May 23, 2012 at 10:48 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On May 23, 2012, at 7:41 PM, Igor Stasenko wrote: > > > On 23 May 2012 18:57, Sebastian Sastre <sebastian(a)flowingconcept.com> > wrote: > >> Hey guys, > >> > >> this is kind of a show stopper for images in production :/ > >> http://code.google.com/p/pharo/issues/detail?id=5965 > >> > > > > i thought we already dealt with it. > > no? > > > > No, the image as it is now just quits. Delayed our deployment of the ESUG > registration server > for some weeks... normal seaside use, image quites after a day. > But then there must be a leak. Some sockets are not getting closed or their associated semaphores are not getting released. > > It's far from obvious. > > I think the image should work out of the box. Why destinguish between > deployment and development? > What is good in deployment is for sure gut in development. > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot

May 23, 2012

Re: [Pharo-project] [ANN] 5965 Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup!

by Marcus Denker

On May 23, 2012, at 7:49 PM, Marcus Denker wrote: > > On May 23, 2012, at 7:41 PM, Igor Stasenko wrote: > >> On 23 May 2012 18:57, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>> Hey guys, >>> >>> this is kind of a show stopper for images in production :/ >>> http://code.google.com/p/pharo/issues/detail?id=5965 >>> >> >> i thought we already dealt with it. >> no? >> > > No, the image as it is now just quits. Delayed our deployment of the ESUG registration server > for some weeks... ^^^^^^^ days of course. "It's down" "strange, I restarted". "Again" "Wow. But wait, there is an error message". This has to be done better. There should not be a destinction of "deployment" and "development" on that level. Marcus -- Marcus Denker -- http://marcusdenker.de

May 23, 2012

Re: [Pharo-project] [ANN] 5965 Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup!

by Marcus Denker

On May 23, 2012, at 7:41 PM, Igor Stasenko wrote: > On 23 May 2012 18:57, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> Hey guys, >> >> this is kind of a show stopper for images in production :/ >> http://code.google.com/p/pharo/issues/detail?id=5965 >> > > i thought we already dealt with it. > no? > No, the image as it is now just quits. Delayed our deployment of the ESUG registration server for some weeks... normal seaside use, image quites after a day. It's far from obvious. I think the image should work out of the box. Why destinguish between deployment and development? What is good in deployment is for sure gut in development. Marcus -- Marcus Denker -- http://marcusdenker.de

May 23, 2012

Re: [Pharo-project] [ANN] 5965 Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup!

by Igor Stasenko

On 23 May 2012 18:57, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Hey guys, > > this is kind of a show stopper for images in production :/ > http://code.google.com/p/pharo/issues/detail?id=5965 > i thought we already dealt with it. no? > sebastian > > o/ > > > > > > -- Best regards, Igor Stasenko.

May 23, 2012

Re: [Pharo-project] Bug in Pharo-1.4-14438-OneClick.sh

by Damien Cassou

Hi, On Tue, May 22, 2012 at 9:56 PM, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> wrote: > I attached my version of script. thank you very much. I updated http://code.google.com/p/pharo/issues/detail?id=5950. Thanks -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 23, 2012

Re: [Pharo-project] what is the magic with MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. ' ?

by Chris Muller

I don't know if your goal is to save space but... one of the nice things I've been enjoying about using a Magma-based MC repository is that the VersionInfo chain only goes back as far as you've actually accessed. Beyond that it's terminated by a Proxy object. It's the best of both worlds: the full version history is instantly and transparently available but without taking up any space until it's accessed.. On Mon, May 21, 2012 at 2:42 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > The immediate impact of this is that you wont' be able to use the packages in your image in a three way merge, because the system will no longer be able to find a common ancestor. By implication you shouldn't save any of the packages either, because you risk polluting the "package pool" with ancestor-less versions. > > I've done a little experimentation with this in the git work (at one point in time, I was not saving the ancestry information on disk) ... > > If you somehow record the immediate ancestor(s) of the package, you can restore the ancestry chain with the MonticelloBrowser 'adopt' operation and then you can do the merge or save the package ... > > You can save and load these puppies ... I'm pretty sure that the ancestry is used only for merging ... > > oh yeah, the name of the package with the author and version number is derived from the first ancestor, i.e., the package that was loaded into the image, while this doesn't cause explicit problems, it can be unsettling ... > > At least that's what I recall.... > > Dale > > ----- Original Message ----- > | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> > | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> > | Sent: Monday, May 21, 2012 10:58:23 AM > | Subject: [Pharo-project] what is the magic with MCVersionInfo allInstances do: [ :each | each instVarNamed: > | 'ancestors' put: nil ]. ' ? > | > | Hi guys. Can a MC guy tell me what happens when I do: > | > | MCVersionInfo allInstances do: [ :each | each instVarNamed: > | 'ancestors' put: nil ]. > | > | what is what is actually clean? is that useful? what are the > | consequences/impact when I do that? is my image broken? can I still > | use monticello browser and all my projects with it? > | > | thanks > | > | -- > | Mariano > | http://marianopeck.wordpress.com > | > | >

May 23, 2012

[Pharo-project] [ANN] 5965 Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup!

by Sebastian Sastre

Hey guys, this is kind of a show stopper for images in production :/ http://code.google.com/p/pharo/issues/detail?id=5965 sebastian o/

May 23, 2012