- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] eventual crashes pharo vm

by Eliot Miranda

Hi Henry, On Mon, Aug 14, 2017 at 3:58 PM, henry <henry(a)callistohouse.club> wrote: > If you need more info, please ask and I will try to get ths to you. > yes, if you can make the image & changes available somewhere that would be nice. Thanks. > > - HH > > > -------- Original Message -------- > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 6:54 PM > UTC Time: August 14, 2017 10:54 PM > From: henry(a)callistohouse.club > To: Eliot Miranda <eliot.miranda(a)gmail.com> > Pharo Development List <pharo-dev(a)lists.pharo.org> > > Yes, it is pharo 6.1 32-bit, standard image with Cryptography loaded, on > ubuntu 32-bit. Here is the vm version info below. > > I loaded this package and ran the tests and it exited...http://www. > squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz > > Here is the pharo 6.1 version... > 5.0-201707201942 Thu Jul 20 20:49:40 UTC 2017 gcc 4.6.3 [Production Spur > VM] > CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad > Jul 20 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Thu Jul 20 12:42:21 2017 -0700 $ > Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk- > vm.git $ > Linux testing-gce-a2a4bdab-02ca-439f-bf6e-83038885be71 3.13.0-115-generic > #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 > GNU/Linux > plugin path: /usr/local/bin/../lib/pharo/5.0-201707201942 [default: > /usr/local/lib/pharo/5.0-201707201942/] > > - HH > > > -------- Original Message -------- > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 6:47 PM > UTC Time: August 14, 2017 10:47 PM > From: eliot.miranda(a)gmail.com > To: henry <henry(a)callistohouse.club>, Pharo Development List < > pharo-dev(a)lists.pharo.org> > > Hi Henry, > > On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: > >> Hi all. I was testing with this eventual_test package and it blows up the >> pharo 6.1 vm. I'd welcome pointers >> >> http://www.squeaksource.com/TurquoiseTesting.html >> > > Care to share how to reproduce the crash? Image version, VM version & > word size, OS, Smalltalk expression, supporting files, if any. > > _,,,^..^,,,_ > best, Eliot > > > > -- _,,,^..^,,,_ best, Eliot

Aug. 14, 2017

Re: [Pharo-dev] eventual crashes pharo vm

by henry

If you need more info, please ask and I will try to get ths to you. - HH > -------- Original Message -------- > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 6:54 PM > UTC Time: August 14, 2017 10:54 PM > From: henry(a)callistohouse.club > To: Eliot Miranda <eliot.miranda(a)gmail.com> > Pharo Development List <pharo-dev(a)lists.pharo.org> > > Yes, it is pharo 6.1 32-bit, standard image with Cryptography loaded, on ubuntu 32-bit. Here is the vm version info below. > > I loaded this package and ran the tests and it exited...http://www.squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz > > Here is the pharo 6.1 version... > 5.0-201707201942 Thu Jul 20 20:49:40 UTC 2017 gcc 4.6.3 [Production Spur VM] > CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20 12:42:21 2017 -0700 $ > Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Linux testing-gce-a2a4bdab-02ca-439f-bf6e-83038885be71 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 GNU/Linux > plugin path: /usr/local/bin/../lib/pharo/5.0-201707201942 [default: /usr/local/lib/pharo/5.0-201707201942/] > > - HH > >> -------- Original Message -------- >> Subject: Re: [Pharo-dev] eventual crashes pharo vm >> Local Time: August 14, 2017 6:47 PM >> UTC Time: August 14, 2017 10:47 PM >> From: eliot.miranda(a)gmail.com >> To: henry <henry(a)callistohouse.club>, Pharo Development List <pharo-dev(a)lists.pharo.org> >> >> Hi Henry, >> >> On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: >> >>> Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers >>> >>> http://www.squeaksource.com/TurquoiseTesting.html >> >> Care to share how to reproduce the crash? Image version, VM version & word size, OS, Smalltalk expression, supporting files, if any. >> >> _,,,^..^,,,_ >> best, Eliot

Aug. 14, 2017

Re: [Pharo-dev] eventual crashes pharo vm

by henry

Yes, it is pharo 6.1 32-bit, standard image with Cryptography loaded, on ubuntu 32-bit. Here is the vm version info below. I loaded this package and ran the tests and it exited...http://www.squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz Here is the pharo 6.1 version... 5.0-201707201942 Thu Jul 20 20:49:40 UTC 2017 gcc 4.6.3 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Linux testing-gce-a2a4bdab-02ca-439f-bf6e-83038885be71 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 GNU/Linux plugin path: /usr/local/bin/../lib/pharo/5.0-201707201942 [default: /usr/local/lib/pharo/5.0-201707201942/] - HH > -------- Original Message -------- > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 6:47 PM > UTC Time: August 14, 2017 10:47 PM > From: eliot.miranda(a)gmail.com > To: henry <henry(a)callistohouse.club>, Pharo Development List <pharo-dev(a)lists.pharo.org> > > Hi Henry, > > On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: > >> Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers >> >> http://www.squeaksource.com/TurquoiseTesting.html > > Care to share how to reproduce the crash? Image version, VM version & word size, OS, Smalltalk expression, supporting files, if any. > > _,,,^..^,,,_ > best, Eliot

Aug. 14, 2017

Re: [Pharo-dev] eventual crashes pharo vm

by Eliot Miranda

Hi Henry, On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: > Hi all. I was testing with this eventual_test package and it blows up the > pharo 6.1 vm. I'd welcome pointers > > http://www.squeaksource.com/TurquoiseTesting.html > Care to share how to reproduce the crash? Image version, VM version & word size, OS, Smalltalk expression, supporting files, if any. _,,,^..^,,,_ best, Eliot

Aug. 14, 2017

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

by Tudor Girba

Hi, > On Aug 14, 2017, at 3:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > again, I think this is a discussion for pharo-dev. > Please keep it there (is good discussion, btw ;) ). > > What about my proposal of including a tiny PetitParser? (it would be âInfimeParserâ :P) I am for it, but there will be some work to repackage PetitParser2. Also, I notice that the French lessons start to pay off :) Cheers, Doru > Esteban > > >> On 14 Aug 2017, at 11:10, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi Tim, >> >> The main benefit of relying on Pillar is that we control its syntax and can easily extend it for our purposes. Also, there was quite a bit of engineering invested in it, and even though we still need to improve it, there exists a pipeline that allows people to quickly publish books. >> >> The figure embedding problem is one example of the need to customize the syntax and behavior, but this extensibility will become even more important for supporting the idea of moving the documentation inside the image. For example, the ability to refer to a class, method or other artifacts will be quite relevant soon especially that the editor will be able to embed advanced elements inside the text. >> >> Cheers, >> Doru >> >> >>> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Hi Stef - I think yourâs is a fair requirement (in fact I hit something similar when doing a static website using a JS markdown framework - and this is why I mentioned Kramdown which adds a few extras to regular markdown - but it feels like it goes a bit too far). >>> >>> My next item on my learning todo list was to try and replace that JS generator with something from Smalltalk - so I think we can possibly come up with something that ticks all the right boxes (Iâd like to try anyway). >>> >>> Iâll keep working away on it and compare notes with you. I think with Pillar, it was more that things like headers, bold and italics are similar concepts but just use different characters - so I keep typing the wrong thing and getting frustrated particularly when we embrace Git and readme.md is in markdown. >>> >>> >>> Tim >>> >>>> On 13 Aug 2017, at 20:08, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>> Hi tim >>>> >>>> I personally do not care much about the syntax but I care about what I >>>> can do with it >>>> (ref, cite, ... ) >>>> I cannot write books in markdown because reference to figures!!!!!! >>>> were missing. >>>> >>>> And of course a parser because markdown is not really nice to parse >>>> and I will not write a parser because I have something else to do. I >>>> want to make pillar smaller, simpler, nicer. >>>> >>>> Now if someone come up with a parser that parse for REAL a markdown >>>> that can be extended with decent behavior (figure reference, section >>>> reference, cite) and can be extended because there are many things >>>> that can be nice to have (for example I want to be able to write the >>>> example below) and emit a PillarModel (AST) we can talk to have >>>> another syntax for Pillar but not before. >>>> >>>> [[[test >>>> 2+3 >>>>>>> 5 >>>> ]]] >>>> >>>> and being able to verify that the doc is in sync. >>>> >>>> >>>> Stef >>>> >>>> >>>> >>>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>>>> Of course, I/we recognise and appreciate all the work that's gone into docs in pillar - but I think it should be reasonably straightforward to write a converter as it is pretty closely related from what I have seen. >>>>> >>>>> So I don't make the suggestion flippantly, and would want to help write a converter and get us to a common ground where we can differentiate on the aspects where we can excel. >>>>> >>>>> Tim >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>>> >>>>>> A long time issue with Markdown was that there was no standardization (and when I used Pillar's MD export ~2 years ago it didn't work well). >>>>>> >>>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the de-facto standard, so it would make sense to support it bidirectionally with Pillar. >>>>>> >>>>>>> The readme.md that Peter is talking about is gfm markdown >>>>>> >>>>>> Well, technically it is just a CommonMark, as I am not using any github extensions. >>>>>> (Github uses CommonMarks and adds just couple small extensions.) >>>>>> >>>>>> Peter >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> âLive like you mean it." >> >> > > -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

Aug. 14, 2017

Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript?

by Craig Latta

Hi Frank-- > I see absolutely no sense in this approach for real-world end-user > applications... Smalltalk in a web browser (or NodeJS) makes just as much sense as any other JS framework, like React, Angular, etc. BitBLT, Morphic, and even the Smalltalk process scheduler are all entirely optional; since there is full JavaScript connectivity, one can manipulate the DOM (or shadow DOM) just like any other framework, using JS functions and promises (and Smalltalk objects which can stand in for those things). > ...especially if their sources MUST be closely connected with existing > Smalltalk code, which does not run in the client like all the > data-driven model definitions etc that I already have There is no such requirement. > the Morph UI is out of any question related to what end-users expect > (pardon, but end-users would regard this as a bad joke) One need not use Morphic. One can use any JS code one likes. > the responsivness of such a solution in the browser must always be far > slower than any "normal" browser UI That's not true. For example, at the moment my UI is Mozilla's A-Frame 3D virtual reality framework, at 90 frames per second. > and it's impossible to port my >10.000 framwork and application > classes to Squeak. Caffeine can use Pharo, Squeak, or Cuis. > Should my view be completely wrong, please let me know. It actually is. :) Best of luck with your project! -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco craig(a)blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Aug. 14, 2017

S8 Smalltalk tools - Android

by Elvio Fernandez

We've published an enviroment for social development as an Android Application! Now we have support for Object Technology on Android devices. https://play.google.com/store/apps/details?id=net.smalltalking.s8.jx8 Greetings Elvio

Aug. 14, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Stephane Ducasse

Thanks for this discussion! It will improve Guille proposal and Pharo :) I'm happy! And learning things. (ok I should prepare my lectures instead of reading. I guess that I will have to use pomodoro techniques to force me to work :) Stef On Mon, Aug 14, 2017 at 9:48 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Mon, Aug 14, 2017 at 12:26 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: >> >> Hi Eliot, >> >> On Mon, Aug 14, 2017 at 9:07 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >>> >>> Hi Guille, >>> >>> On Mon, Aug 14, 2017 at 3:42 AM, Guillermo Polito >>> <guillermopolito(a)gmail.com> wrote: >>>> >>>> Hi all, >>>> >>>> I'm proposing a kind-of critical change that I believe is very good for >>>> the health of the system: I want that the startup of the system runs in >>>> maximum priority and becomes non-interruptable. >>>> >>>> Right now, when you save your image, the shutdown and startup are run in >>>> the same priority than the process that triggered the save (usually the ui >>>> or the command line, priority 40). This can cause lots of problems and race >>>> conditions: processes with higher priorities can interrupt the >>>> shutdown/startup and try to do something while the system is unstable. As a >>>> side effect also, when you use extensively the command line, you start >>>> stacking startup contexts from old sessions: >>>> >>>> ... >>>> session 3 ctxt 4 <- This guy makes a save and a new session starts >>>> session 3 ctxt 3 >>>> session 3 ctxt 2 >>>> session 3 ctxt 1 >>>> session 2 ctxt 4 <- This guy makes a save and a new session starts >>>> session 2 ctxt 3 >>>> session 2 ctxt 2 >>>> session 2 ctxt 1 >>>> session 1 ctxt 4 <- This guy makes a save and a new session starts >>>> session 1 ctxt 3 >>>> session 1 ctxt 2 >>>> session 1 ctxt 1 >>>> >>>> Old contexts are never collected, and the objects they referenced >>>> neither. >>>> >>>> To fix these two problems I propose to do every image save/session start >>>> in a new process in maximum priority. That way, other process should not be >>>> able to interrupt the startup process. Moreover, every session >>>> shutdown/startup should happen in a new clean process, to avoid the session >>>> stacking. >>> >>> >>> I think you're mixing up two things here. One is wanting to make >>> startup/shutdown uninterruptible by raising the priority of the process that >>> does startup & shutdown. The other is starting the system with a new >>> process. >> >> >> Yes, we agree they are two different issues. >> >>> >>> >>> I don't want to express an opinion on the former, but I think the latter >>> is not a good idea. One important feature of Smalltalks up until your >>> proposed change is that snapshotAs:thenQuit: can be sent anywhere, causes a >>> snapshot and resumes execution after the send of snapshotAs:thenQuit: once >>> the internals of snapshotAs:thenQuit: have rebooted the system. This is >>> really useful: >>> >>> - applications can snapshot the system as they choose for checkpointing, >>> etc >>> - for VM debugging one can execute the snapshotAs:thenQuit: anywhere (for >>> example inside an inspector where self is bound to some interesting object) >>> and follow it by whatever code one chooses, e.g. to provoked a bug. For >>> example >>> Smalltalk snapshotAs: 'foo' thenQuit: true. >>> self doSomethingTerminal >>> >>> Your change will break this and make it much harder to debug certain >>> things. >> >> >> But this behaviour is kept in my proposal :). > > > OK, good. > > >> >> Actually, what I propose is mainly changing the following: >> >> SessionManager >> #snapshot: save andQuit: shouldQuit >> -> renamed into #launchSnapshot: save andQuit: quit. >> >> and then define: >> >> snapshot: save andQuit: quit >> | isImageStarting wait | >> wait := Semaphore new. >> [ >> isImageStarting := self launchSnapshot: save andQuit: quit. >> wait signal >> ] forkAt: Processor highestPriority. >> wait wait. >> ^ isImageStarting >> >> >> Since the snapshot runs in max priority, users will be suspended until the >> startup is run in a safe manner. Moreover, I added a semaphore to handle the >> case where a process in max priority calls a snapshot. > > > But to accomplish that you can simply do > > snapshot: save andQuit: quit > ^[self launchSnapshot: save andQuit: quit] valueUnpreemptively > > > right? > >> >> To me this proposal is cleaner than changing the priority of the current >> thread to the top priority, to then reset it to the old priority. > > > Not if encapsulated in valueUnpreemptively. > >> >>> >>> One will be able to use the file-in scheme, but this implies the system >>> will always run the compiler first, and one may not want that. >> >> >> I did not get this one. Could you explain further? > > > Ignore me. It's a non-issue since your proposal doesn't change what I > thought it did. I thought you were proposing to start the system in a new > process so that the state of the system didn't include the process that did > the snapshot. Forgive the noise. > >> >> If you mean calling the command line handlers to install .st files for >> example, the command line handlers are called before anything else today in >> any case, as they are subscribed to the startup. So even if you saved your >> image from the world menu, the saved image will try to handle command line >> arguments on the next startup. >> >>> >>> Further, the system stacking looks like a bug that should be addressed >>> elsewhere. Isn't it session management's responsibility for dropping older >>> sessions? >> >> >> Yes, it's a different issue, I know. The current issue is that there is >> code that creates a snapshot as part of the startup. Starting up from a >> separate process is part of the solution for this (as a way to prevent it, >> whatever the users do). >> >> Thanks for looking into it :) >> >> Guille > > > > > -- > _,,,^..^,,,_ > best, Eliot

Aug. 14, 2017

[Pharo 70] build 35 - PR 172 Implement-WeakIdentityValueDictionary

by Stephane Ducasse

[Pharo 70 ] build 35 - PR 172 Implement-WeakIdentityValueDictionary https://github.com/pharo-project/pharo/pull/ https://pharo.fogbugz.com/f/cases/20105/Implement-WeakIdentityValueDictiona…

Aug. 14, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Eliot Miranda

On Mon, Aug 14, 2017 at 12:26 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hi Eliot, > > On Mon, Aug 14, 2017 at 9:07 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Guille, >> >> On Mon, Aug 14, 2017 at 3:42 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Hi all, >>> >>> I'm proposing a kind-of critical change that I believe is very good for >>> the health of the system: I want that the startup of the system runs in >>> maximum priority and becomes non-interruptable. >>> >>> Right now, when you save your image, the shutdown and startup are run in >>> the same priority than the process that triggered the save (usually the ui >>> or the command line, priority 40). This can cause lots of problems and race >>> conditions: processes with higher priorities can interrupt the >>> shutdown/startup and try to do something while the system is unstable. As a >>> side effect also, when you use extensively the command line, you start >>> stacking startup contexts from old sessions: >>> >>> ... >>> session 3 ctxt 4 <- This guy makes a save and a new session starts >>> session 3 ctxt 3 >>> session 3 ctxt 2 >>> session 3 ctxt 1 >>> session 2 ctxt 4 <- This guy makes a save and a new session starts >>> session 2 ctxt 3 >>> session 2 ctxt 2 >>> session 2 ctxt 1 >>> session 1 ctxt 4 <- This guy makes a save and a new session starts >>> session 1 ctxt 3 >>> session 1 ctxt 2 >>> session 1 ctxt 1 >>> >>> Old contexts are never collected, and the objects they referenced >>> neither. >>> >>> To fix these two problems I propose to do every image save/session start >>> in a new process in maximum priority. That way, other process should not be >>> able to interrupt the startup process. Moreover, every session >>> shutdown/startup should happen in a new clean process, to avoid the session >>> stacking. >>> >> >> I think you're mixing up two things here. One is wanting to make >> startup/shutdown uninterruptible by raising the priority of the process >> that does startup & shutdown. The other is starting the system with a new >> process. >> > > Yes, we agree they are two different issues. > > >> >> I don't want to express an opinion on the former, but I think the latter >> is not a good idea. One important feature of Smalltalks up until your >> proposed change is that snapshotAs:thenQuit: can be sent anywhere, causes a >> snapshot and resumes execution after the send of snapshotAs:thenQuit: once >> the internals of snapshotAs:thenQuit: have rebooted the system. This is >> really useful: >> >> - applications can snapshot the system as they choose for checkpointing, >> etc >> - for VM debugging one can execute the snapshotAs:thenQuit: anywhere (for >> example inside an inspector where self is bound to some interesting object) >> and follow it by whatever code one chooses, e.g. to provoked a bug. For >> example >> Smalltalk snapshotAs: 'foo' thenQuit: true. >> self doSomethingTerminal >> >> Your change will break this and make it much harder to debug certain >> things. >> > > But this behaviour is kept in my proposal :). > OK, good. > Actually, what I propose is mainly changing the following: > > SessionManager >> #snapshot: save andQuit: shouldQuit > -> renamed into #launchSnapshot: save andQuit: quit. > > and then define: > > snapshot: save andQuit: quit > | isImageStarting wait | > wait := Semaphore new. > [ > isImageStarting := self launchSnapshot: save andQuit: quit. > wait signal > ] forkAt: Processor highestPriority. > wait wait. > ^ isImageStarting > > > Since the snapshot runs in max priority, users will be suspended until the > startup is run in a safe manner. Moreover, I added a semaphore to handle > the case where a process in max priority calls a snapshot. > But to accomplish that you can simply do snapshot: save andQuit: quit ^[self launchSnapshot: save andQuit: quit] valueUnpreemptively right? > To me this proposal is cleaner than changing the priority of the current > thread to the top priority, to then reset it to the old priority. > Not if encapsulated in valueUnpreemptively. > >> One will be able to use the file-in scheme, but this implies the system >> will always run the compiler first, and one may not want that. >> > > I did not get this one. Could you explain further? > Ignore me. It's a non-issue since your proposal doesn't change what I thought it did. I thought you were proposing to start the system in a new process so that the state of the system didn't include the process that did the snapshot. Forgive the noise. > If you mean calling the command line handlers to install .st files for > example, the command line handlers are called before anything else today in > any case, as they are subscribed to the startup. So even if you saved your > image from the world menu, the saved image will try to handle command line > arguments on the next startup. > > >> Further, the system stacking looks like a bug that should be addressed >> elsewhere. Isn't it session management's responsibility for dropping older >> sessions? >> > > Yes, it's a different issue, I know. The current issue is that there is > code that creates a snapshot as part of the startup. Starting up from a > separate process is part of the solution for this (as a way to prevent it, > whatever the users do). > > Thanks for looking into it :) > > Guille > -- _,,,^..^,,,_ best, Eliot

Aug. 14, 2017