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

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

Re: [Pharo-dev] [Vm-dev] vm crash when using rairedTo: with fractions

by Stephane Ducasse

I like your answer nicolas. If this is really important for any business or any dev around let us know we can just tag it and we will port it for 6.2. Stef On Mon, Aug 14, 2017 at 11:29 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi Tim, > I'd say: is this a showstopper? > How often do you raise a Fraction to the power of another Fraction with > large denominator (> 10000)? > Or is it used indirectly by some kind of Framework? > > If yes then open a pharo bug entry and mark for 6.x, else just wait 7.x... > > Nicolas > > > 2017-08-14 10:49 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >> >> Is there a way for this to get back into 6.1 - so we can shoot for a >> stable 6.x version that will last us for a year while 7.x is under >> development? >> >> Iâm not familiar with how point release are handled in Pharo, and I get >> the impression that this is going to be a slightly rockier year as there >> have been some pretty revolutionary changes made to get us here. >> >> As its a vm change does this mean we get 6.2 queued up somehow? >> >> Tim >> >> > On 13 Aug 2017, at 20:12, Stephane Ducasse <stepharo.self(a)gmail.com> >> > wrote: >> > >> > Tx eliot. >> > >> > >> > On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda >> > <eliot.miranda(a)gmail.com> wrote: >> >> Hi Andrei, >> >> >> >> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis >> >> <chisvasileandrei(a)gmail.com> >> >> wrote: >> >>> >> >>> >> >>> Hi, >> >>> >> >>> I was executing this code '(2009/2000) ** (3958333/100000)' with the >> >>> Pharo6.1 distribution and the vm crashed with she stack attached >> >>> below. >> >>> Tried it on both mac and windows 10. >> >>> Seems that #raisedTo: has a special case for fractions that ends up >> >>> calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash. >> >> >> >> >> >> The plugin is now fixed; see VMMaker.oscog-eem.2262. I'll generate >> >> code >> >> soon (am debugging something you're familiar with that takes several >> >> hours >> >> to run and don't want to generate sources while it's running). But I'm >> >> glad >> >> you've found a better way! This case creates 600k byte large integers >> >> and >> >> takes forever to run :-) >> >> >> >>> >> >>> Cheers, >> >>> Andrei >> >>> >> >>> >> >>> 0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) >> >>> LargePositiveInteger >> >>> 0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) >> >>> LargePositiveInteger >> >>> 0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) >> >>> LargePositiveInteger >> >>> 0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) >> >>> LargePositiveInteger >> >>> 0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: >> >>> a(n) LargePositiveInteger >> >>> 0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: >> >>> a(n) >> >>> LargePositiveInteger >> >>> 0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009 >> >>> 0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction >> >>> 0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction >> >>> 0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction >> >>> 0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject >> >>> 0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler >> >>> 0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) >> >>> RubSmalltalkEditor >> >>> 0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) >> >>> RubSmalltalkEditor >> >>> 0xade0b8 M >> >>> GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint >> >>> 0x3062fdc8: a(n) GLMMorphicPharoScri >> >>> enderer >> >>> 0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) >> >>> MorphicAlarm >> >>> 0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm >> >>> 0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState >> >>> 0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) >> >>> WorldState >> >>> 0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState >> >>> 0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph >> >>> 0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState >> >>> 0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState >> >>> 0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph >> >>> 0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph >> >>> class >> >>> 0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) >> >>> MorphicUIManager >> >>> 0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure >> >>> >> >> >> >> >> >> >> >> -- >> >> _,,,^..^,,,_ >> >> best, Eliot >> > >> >> >

Aug. 14, 2017

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

by Guillermo Polito

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 :). 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. 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. > 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? 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

Aug. 14, 2017

Re: [Pharo-dev] PharoJS crashes at first try

by Stephane Ducasse

On Sun, Aug 13, 2017 at 9:19 PM, Frank-B <frank.berger.software(a)web.de> wrote: > Stephane, > > thank you for your open words. > > 1) No I am NOT Frank Lesser and I will communicate this even clearer in a > personal email to you. Ok ;) > > 2) I had tried to make very clear that I see the Pharo project very positive > and my critics as being (at least intended) constructive. Ok :) > 3) I never care about my reputation. I only care about truth, facts and a > sincere appearance. Few people appreciate this attitude and I do not value > the others all too high or seriously. Unfortunately, we all have to live in > these timees of universal lies, deception and fraud. You probably know the > good German word "LÃ¼genpresse" and my version is: "the current Zeitgeist > equals LÃ¼genpresse". I do not german and the underlying message. My advice is that generally people are nice and willing to help but it depends also how people behave :). > 4) I have some good, solid and unusual ideas how I could improve the Pharo > project considerably but for several reasons it is much to early to discuss > this. It will take another 2-3 years and I will definitely come back when > the time has come on my side. > > 5) As a contributor in the general Pharo sense I am currently neither > capable (working 85-100 hours a week on my projects) nor eligible and the > latter reason is not simple to explain, so I leave it at that for now. Ok. It is up to you. You see today I saw the method -> in Object and there is not a little example in the comments. So I will add one so that newbies like my sons can read and understand without their father telling them. And this is a contribution. :) Stef > > Frank > > > > > > -- > View this message in context: http://forum.world.st/PharoJS-crashes-at-first-try-tp4960686p4960770.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 14, 2017

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

by Eliot Miranda

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. 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. 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. Further, the system stacking looks like a bug that should be addressed elsewhere. Isn't it session management's responsibility for dropping older sessions? For normal users, this should have no side effect at all. This change will > have a good impact on people working on the debugger and the stack such as > fueling-out the stack because they will have a cleaner stack. > > There is however a side-effect/design point to consider: startup actions > should be quick to run. If a startup action requires to run a long-running > action such as starting a server or managing a command line action, that > should run in a separate process with lower priority (usually > userPriority). In other words, the startup action should create a new > process managing its action. > > If you want to review (and I'd be glad) > > Pull request: https://github.com/pharo-project/pharo/pull/198 > Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 > Current validation going on: https://ci.inria.fr/pharo-ci- > jenkins2/job/Test%20pending%20pull%20request%20and% > 20branch%20Pipeline/view/change-requests/job/PR-198/ > > Guille > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- _,,,^..^,,,_ best, Eliot

Aug. 14, 2017

Re: [Pharo-dev] Little article: keep your pharo repository in sync

by Stephane Ducasse

Thanks guille This is great to have all these ressources on git integration. Once you are done :) we can really easily create a booklet around git and pharo. Stef On Mon, Aug 14, 2017 at 7:40 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > This little article explains how you should keep your branches in sync > with iceberg or (in worst-case scenario) from the command line. > > https://github.com/guillep/PharoIntegrationProcess/wiki/ > Keep-your-repo-in-sync > > These are the things I do all the time, if you have other cases, or you > want to add anything, just tell. > > Guille > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Aug. 14, 2017