I finally managed to reproduce your situation, using get.pharo.org/70+vm on
Linux (Ubuntu 16.04.3 LTS, 64bit using a 32bit VM).
Indeed the second time the image comes up blank. It does however still work (I
had a running server in it and I could access it via the browser). You can also
interrupt Pharo (ctrl-.) and the debugger shows the process is blocked at the
'wait wait' in the following method:
SessionManager>>#snapshot: save andQuit: quit
| isImageStarting wait |
"We do the snapshot in a separate process in maximum priority to have
always a clean startup.
This process will be interrupted by the fork, and will be resumed as
soon as the snapshot finishes.
We synchronize these processes in case both are in the same priority.
When both arguments are false, do nothing and return false."
(save or: [quit]) ifFalse: [ ^ false ].
wait := Semaphore new.
isImageStarting := self launchSnapshot: save andQuit: quit.
] forkAt: Processor highestPriority.
Now, the underlying error is ZnCrPortableWriteStream that disappeared and is
used by the command line handlers.
It seems the latest Zinc (as loaded by Seaside) does not yet contain this class.
I'll check and come back.
> On 9 Feb 2018, at 00:04, Maximiliano Tabacman via Pharo-dev
> <firstname.lastname@example.org> wrote:
> From: Maximiliano Tabacman <mtabac...@yahoo.com>
> Subject: Re: [Pharo-dev] [Seaside-dev] How should I load Seaside/Bootstrap in
> Pharo 7 ?
> Date: 9 February 2018 at 00:04:59 GMT+1
> To: email@example.com, "Sean P. DeNigris" <s...@clipperadams.com>
> I can only test it in Ubuntu and Windows for the moment.
> Steps to reproduce (in Windows)
> 1) Download:
> 2) Download:
> 3) Unzip everything to the same directory, then start Pharo.exe
> 4) Execute in Workspace
> Metacello new
> repository: 'github://SeasideSt/Seaside:master/repository';
> 5) Save and Quit
> 6) Try to start Pharo.exe
> If I delete stderr, stdout and PharoDebug.log before restarting Pharo, I can
> see that stderr and PharoDebug.log are created at 0 bytes, there is no other
> log that I can find.
> As you can see, no startup scripts are involved. This is a clean Pharo
> installation. And this happens both in Windows and in Ubuntu, no matter in
> which OS I try to do the download+load.
> If it is of any help, this has been happening exactly since build 383. It
> worked perfectly up to build 382.
> On Thursday, February 8, 2018, 4:42:36 PM GMT-3, Sean P. DeNigris
> <s...@clipperadams.com> wrote:
> Pharo Smalltalk Developers mailing list wrote
> > I have no idea why this is happening
> I had a similar situation due to a deprecation warning generated by my
> startup script. I aborted from the debugger, and the image worked normally,
> but when I saved, quit and tried to restart the image, it wouldn't open (VM
> icon in list of active apps, but window never appeared macOS high Sierra).
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html