I don't understand why this problem appear only recently, and if i remember before i never heard that people had a problems with too many open sockets (and consequently exceeding a semaphore table space). Is there something we changed in language? in VM? or is it purely because we are lagging behind the scale of projects which today running on pharo? :) On 7 October 2011 22:22, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Janko,   you need to /save/ the image having applied Smalltalk vm maxExternalSemaphoresSilently: 3000.  This must be set in the image at start-up, not after the image has loaded.  i.e. the VM inspects the value saved in the image header and applies the value *before* the image starts running.
2011/10/7 Janko Mivšek <janko.mivsek@eranova.si>
Hi Henrik,
S, Henrik Sperre Johansen piše:
On 05.10.2011 01:18, Schwab,Wilhelm K wrote:
The log you posted contains the string "Not enough space for external objects, set a larger size at startup!" Â Maybe a command-line switch to the vm will give you more memory and a way to get the image going?
Smalltalk vm maxExternalSemaphoresSilently: aSize  would be the line to include. If the script passed on a command line is higher in the startuplist than the InputEventSensor, it would get it working again.
Ok, I'm back having time to look at this problem and I made a start.st script below, start the image with it, but get the same blank screen as you can see in attached screenshot. Ctrl or Alt . doesn't help.
start.st Smalltalk vm maxExternalSemaphoresSilently: 3000
./Contents/Linux/squeak ./Contents/Resources/waste.image start.st
Any more idea? Otherwise I'll start to recover from changes, but starting this nonresponsive image would of course be faster solution:)
Best regards Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
-- best, Eliot
-- Best regards, Igor Stasenko.