July 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Delay machinery (was Re: Suspending a Process)

by Nicolai Hess

2014-07-27 7:09 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > > > 2014-07-25 16:56 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> >> Over the last few days I have been looking deeper into the image locking >> when suspending a process. It is an interesting rabbit hole [1] that leads >> to pondering the Delay machinery, that leads to some VM questions. >> >> When pressing the interrupt key it seems to always opens the debugger >> with the following call stack. >> Semaphore>>critical: 'self wait' >> BlockClosure>>ensure: 'self valueNoContextSwitch' >> Semaphore>>critical: 'ensure: [ caught ifTrue: [self signal]] >> Delay>>schedule 'AccessProtect critical: [' >> Delay>>wait 'self schedule' >> WorldState>>interCyclePause: >> >> > Nicolai Hess wrote: > > Hi Ben, > > I am on Windows too :( > So, the fixes does not work (not always) on winddows too. But at least > they make it less probable to occure, but it still happens. > The most distracting thing is, after the first ui lock, pressing > alt+dot, closing the debuggers, pressing alt+dot .... > and trying to close the very first debugger, after that, it all works. The > UI is responsive again and suspending the process does > not block the ui anymore. > It "looks like" supsending the process reactivates another process that > blocks the UI. And as soon as I terminate this > process (alt+dot, close debugger ...) all works. > But I really don't know. > > Nicolai > > > Hi Nicolai, I have something for you to try. > > With the problem seeming to be stuck in the semaphore critical section, I > read around on mutexes and semaphores and found [1] enlightening, which > says: "The correct use of a semaphore is for signaling from one task to > another. A mutex is meant to be taken and released, always in that order, > by each task that uses the shared resource it protects. By contrast, tasks > that use semaphores either signal or waitânot both. [...] Any two RTOS > tasks that operate at **different priorities** and coordinate via a mutex, > create the opportunity for priority inversion [...while...] semaphores > [...] do not cause priority inversion when used for signaling." [1] > > To summarize with an example, here's how to use a mutex: > /* Task 1 */ > mutexWait(mutex_mens_room); > // Safely use shared resource > mutexRelease(mutex_mens_room); > > /* Task 2 */ > mutexWait(mutex_mens_room); > // Safely use shared resource > mutexRelease(mutex_mens_room); > > By contrast, you should always use a semaphore like this: > /* Task 1 - Producer */ > semPost(sem_power_btn); // Send the signal > > /* Task 2 - Consumer */ > semPend(sem_power_btn); // Wait for signal > > I am out of my depth here, but in light [1] the way the current code seems > to mix semaphore/mutex concepts with Semaphore>>forMutalExclusion and > Semaphore>>critical: gave me some concern. Anyway, the delay scheduling > code seemed more like a producer/consumer signaling problem than a shared > resource mutal exclusion problem, so I rewrote it like the former and fixes > the problem without causing any *obvious* problems. However I lack > experience here and it could definitely use some review. Can you take the > attached zip file and... > > 1. File in "Delay class-new delay code part 1.st" > Defines #enableNewDelayCode and #enableNewDelayCode: > Manually define the referenced class variables > > 2. File in "Delay class-new delay code part 2.st" > Modifies #handleTimerEvent, guarded by enableNewDelayCode > > 3. File in "Delay-new delay code part 3.st" > Modifies #schedule and #unschedule, guarded by enableNewDelayCode > > 4. File in "BackgroundWorkDisplayMorph.st" > > 5. Save checkpoint Image to return to between trials. > > 6. Open System Browser on BackgroundWorkDisplayMorph>>initialize > > Trial 1. > BackgroundWorkDisplayMorph new openInWorld. > > Trial 2. > Delay enableNewDelayCode: true. > BackgroundWorkDisplayMorph new openInWorld. > > If if its deemed worthwhile, I'll open a ticket to track this more > formally. One thing needed is to considered performance impact, I haven't > so far. > > cheers -ben > > [1] http://www.barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore > [2] http://nerdfortress.com/2011/02/18/you-say-semaphore-i-say-mutex/ > > > I notice... >> Delay class >> initialize >> TimingSemaphore := (Smalltalk specialObjectsArray at: 30). >> and... >> Delay class >> startTimerEventLoop >> TimingSemaphore := Semaphore new. >> which seems incongruous that TimingSemaphore is set in differently. So >> while I presume this critical stuff all works fine, just in an exotic way, >> my entropy-guarding-neuron would just like confirm this is so. >> >> -------------- >> >> In Delay class >> handleTimerEvent the comment says... >> "Handle a timer event.... >> -a timer signal (not explicitly specified)" >> ...is that event perhaps a 'tick' generated periodically by the VM via >> that item from specialObjectArray ? Or is there some other mechanism ? >> >> -------------- >> >> [1] http://www.urbandictionary.com/define.php?term=Rabbit+Hole >> cheers -ben >> >> >> P.S. I've left the following for some initial context as I change the >> subject. btw Nicolai, I confirm that my proposed fixes only work on >> Windows, not Mavericks (and I haven't checked Linux). >> >> Nicolai Hess wrote: >> >> >> Hi ben, thank you for looking at this. >> >> 2014-07-22 20:17 GMT+02:00 <btc(a)openinworld.com>: >> >>> I thought this might be interesting to learn, so I've gave it a go. I >>> had some success at the end, but I'll give a progressive report. >>> >>> First I thought I'd try moving the update of StringMorph outside the >>> worker-process using a Morph's #step method as follows... >>> >>> Morph subclass: #BackgroundWorkDisplayMorph >>> instanceVariableNames: 'interProcessString stringMorph' >>> classVariableNames: '' >>> category: 'BenPlay' >>> "---------" >>> >>> BackgroundWorkDisplayMorph>>initializeMorph >>> self color: Color red. >>> stringMorph := StringMorph new. >>> self addMorphBack: stringMorph. >>> self extent:(300@50). >>> "---------" >>> >>> BackgroundWorkDisplayMorph>>newWorkerProcess >>> ^[ >>> | work | >>> work := 0. >>> [ 20 milliSeconds asDelay wait. >>> work := work + 1. >>> interProcessString := work asString. >>> ] repeat. >>> ] newProcess. >>> "---------" >>> >>> BackgroundWorkDisplayMorph>>step >>> stringMorph contents: interProcessString. >>> "---------" >>> >>> BackgroundWorkDisplayMorph>>stepTime >>> ^50 >>> "---------" >>> >>> BackgroundWorkDisplayMorph>>initialize >>> | workerProcess running | >>> super initialize. >>> self initializeMorph. >>> >>> workerProcess := self newWorkerProcess. >>> running := false. >>> >>> self on: #mouseUp send: #value to: >>> [ (running := running not) >>> ifTrue: [ workerProcess resume. self color: Color green. ] >>> ifFalse: [ workerProcess suspend. self color: Color red. ] >>> ] >>> "---------" >>> >>> >>> >>> But evaluating "BackgroundWorkDisplayMorph new openInWorld" found this >>> exhibited the same problematic behavior you reported... Clicking on the >>> morph worked a few times and then froze the UI until Cmd-. pressed a few >>> times. >>> >> >>> However I found the following never locked the GUI. >>> >>> BackgroundWorkDisplayMorph>>initialize >>> "BackgroundWorkDisplayMorph new openInWorld" >>> | workerProcess running | >>> super initialize. >>> self initializeMorph. >>> >>> workerProcess := self newWorkerProcess. >>> running := false. >>> >>> [ [ (running := running not) >>> ifTrue: [ workerProcess resume. self color: Color green ] >>> ifFalse: [ workerProcess suspend. self color: Color red ]. >>> 10 milliSeconds asDelay wait. >>> ] repeat ] fork. >>> "---------" >>> >>> >> This locks the UI as well. Not every timet hough. I did this 5 times, >> every time in a freshly loaded image and it happens two times. >> >> >> >>> So the problem seemed to not be with #suspend/#resume or with the shared >>> variable /interProcessString/. Indeed, since in the worker thread >>> /interProcessString/ is atomically assigned a copy via #asString, and the >>> String never updated, I think there is no need to surround use of it with a >>> critical section. >>> >>> The solution then was to move the "#resume/#suspend" away from the "#on: >>> #mouseUp send: #value to:" as follows... >>> >>> BackgroundWorkDisplayMorph>>initialize >>> "BackgroundWorkDisplayMorph new openInWorld" >>> | workerProcess running lastRunning | >>> super initialize. >>> self initializeMorph. >>> >>> workerProcess := self newWorkerProcess. >>> lastRunning := running := false. >>> >>> [ [ lastRunning = running ifFalse: >>> [ running >>> ifTrue: [ workerProcess resume ] >>> ifFalse: [ workerProcess suspend ]. >>> lastRunning := running. >>> ]. >>> 10 milliSeconds asDelay wait. >>> ] repeat ] fork. >>> >>> self on: #mouseUp send: #value to: >>> [ (running := running not) >>> ifTrue: [ self color: Color green. ] >>> ifFalse: [ self color: Color red. ] >>> ] >>> "---------" >>> >> >> And this too :( >> >> >> >>> >>> And finally remove the busy loop. >>> >>> BackgroundWorkDisplayMorph>>initialize >>> "BackgroundWorkDisplayMorph new openInWorld" >>> | workerProcess running lastRunning semaphore | >>> super initialize. >>> self initializeMorph. >>> >>> workerProcess := self newWorkerProcess. >>> lastRunning := running := false. >>> semaphore := Semaphore new. >>> >>> [ [ semaphore wait. >>> running >>> ifTrue: [ workerProcess resume ] >>> ifFalse: [ workerProcess suspend ]. >>> ] repeat ] fork. >>> >>> self on: #mouseUp send: #value to: >>> [ (running := running not) >>> ifTrue: [ self color: Color green. ] >>> ifFalse: [ self color: Color red. ]. >>> semaphore signal. >>> ] >>> "---------" >>> >>> >> >> And this locks the UI too. (Loaded the code 20 times, every time after >> a fresh image start up. Two times I got a locked >> ui after the first two clicks). >> And I don't understand this code :) >> >> >> >>> Now I can't say how close that is to how it "should" be done. Its the >>> first time I used sempahores and just what I discovered hacking around. >>> But hey! it works :) >>> >>> cheers -ben >>> >>> >>> >>> Nicolai Hess wrote: >>> >>> I am still struggling with it. >>> >>> Any ideas? >>> >>> >>> 2014-07-09 11:19 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >>> >>>> >>>> >>>> >>>> 2014-07-09 2:07 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>> >>>> Hi Nicolai, >>>>> >>>>> >>>>> On Tue, Jul 8, 2014 at 7:19 AM, Nicolai Hess <nicolaihess(a)web.de> >>>>> wrote: >>>>> >>>>>> I want to create a process doing some work and call #changed on a >>>>>> Morph. >>>>>> I want to start/suspend/resume or stop this process. >>>>>> But sometimes, suspending the process locks the UI-Process, >>>>>> and I don't know why. Did I miss something or do I have to care when >>>>>> to call suspend? >>>>>> >>>>>> Wrapping the "morph changed" call in >>>>>> UIManager default defer:[ morph changed]. >>>>>> Does not change anything. >>>>>> >>>>>> Here is an example to reproduce it. >>>>>> Create the process, >>>>>> call resume, call supsend. It works, most of the time, >>>>>> but sometimes, calling suspend locks the ui. >>>>>> >>>>>> p:=[[true] whileTrue:[ Transcript crShow: (DateAndTime now asString). >>>>>> 30 milliSeconds asDelay wait]] newProcess. >>>>>> >>>>> p resume. >>>>>> p suspend. >>>>>> >>>>> >>>>> If you simply suspend this process at random form a user-priority >>>>> process you'll never be able to damage the Delay machinery you're using, >>>>> but chances are you'll suspend the process inside the critical section that >>>>> Transcript uses to make itself thread-safe, and that'll lock up the >>>>> Transcript. >>>>> >>>> >>>> Thank you Eliot >>>> yes I guessed it locks up the critical section, but I hoped with >>>> would not happen if I the use UIManager defer call. >>>> >>>> >>>> >>>>> >>>>> ThreadSafeTranscript>>nextPutAll: value >>>>> accessSemaphore >>>>> critical: [stream nextPutAll: value]. >>>>> ^value >>>>> >>>>> So instead you need to use a semaphore. e.g. >>>>> >>>>> | p s wait | >>>>> s := Semaphore new. >>>>> p:=[[true] whileTrue:[wait ifTrue: [s wait]. Transcript crShow: >>>>> (DateAndTime now asString). 30 milliSeconds asDelay wait]] newProcess. >>>>> wait := true. >>>>> 30 milliSeconds asDelay wait. >>>>> wait := false. >>>>> s signal >>>>> >>>>> etc... >>>>> >>>> >>>> Is this a common pattern I can find in pharos classes. Or I need some >>>> help understanding this. The semaphore >>>> wait/signal is used instead of process resume/suspend? >>>> >>>> What I want is a process doing repeatly some computation, >>>> calls or triggers an update on a morph, and I want to suspend and >>>> resume this process. >>>> >>>> I would stop this discussion if someone tells me, "No your are doing it >>>> wrong, go this way ..", BUT what strikes me: >>>> in this example, that reproduces my problem more closely: >>>> >>>> |p m s running| >>>> running:=false. >>>> m:=Morph new color:Color red. >>>> s:= StringMorph new. >>>> m addMorphBack:s. >>>> p:=[[true]whileTrue:[20 milliSeconds asDelay wait. s >>>> contents:(DateAndTime now asString). m changed]] newProcess. >>>> m on:#mouseUp send:#value to:[ >>>> running ifTrue:[p suspend. m color:Color red.] >>>> ifFalse:[p resume.m color:Color green.]. >>>> running := running not]. >>>> m extent:(300@50). >>>> m openInWorld >>>> >>>> >>>> clicking on the morph will stop or resume the process, if it locks up >>>> I can still press alt+dot -> >>>> - a Debugger opens but the UI is still not responsive. I can click >>>> with the mouse on the debuggers close icon. >>>> - nothing happens, as the UI is still blocked. >>>> - pressing alt+Dot again, the mouse click on the close icon is >>>> processed and the first debugger window closes >>>> - maybe other debuggers open. >>>> >>>> Repeating this steps, at some time the system is *fully* responsive >>>> again! >>>> And miraculously, it works after that without further blockages. >>>> What's happening here? >>>> >>>> >>>> Nicolai >>>> >>>> >>>> >>>>> >>>>> HTH >>>>> >>>>> regards >>>>>> Nicolai >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> best, >>>>> Eliot >>>>> >>>> >>>> >>> >>> >> >> >> > > Interesting, it works. So, it is the Delay>>schedule implementation? Because it uses a #critical block for the wait instead of wait/signal only? Nicolai

July 27, 2014

Re: [Pharo-dev] LaTeX equations support for gitbook

by Damien Cassou

Hi Serge, On Sat, Jul 26, 2014 at 9:02 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > There is only one drawback for me at the moment: apparently LaTeX > equations are not visible under markdown. I guess this might possible > to generate the pictures with LaTex. nothing exists yet, but I can help if you want to look at that. The idea would be to keep the latex formula for latex output and to use latex to generate a picture for other outputs -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 27, 2014

Re: [Pharo-dev] Smalltalkhub behaves very strangely

by Esteban Lorenzano

damnâ¦ you are having same problem Pharo team had last friday. I will check it tomorrow. Esteban On 27 Jul 2014, at 21:09, Attila Magyar <m.magyar3(a)gmail.com> wrote: > When I try to commit to my project, I often get an error message back. It > says "Error: Could not save version". In the debugger I see that the http > response code is 404. > > When I try to open my project on the web, I get an "Oops, not found!". But > the most frightening is, that when I click on my user, under the "My > projects" there is the message "No project yet". There should be about 10-12 > projects under my user (zeroflag). > > I discovered that I can "fix" this temporaly by searching one of my projects > with the search box which usually gives back some result, and after that > suddenly my projects becomes visible again. > > After doing some commits with monticello, the problem reappears. > > > > -- > View this message in context: http://forum.world.st/Smalltalkhub-behaves-very-strangely-tp4770454.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 27, 2014

Re: [Pharo-dev] in latest 40 [Nautilus] we cannot drap and drop classes

by Nicolai Hess

done ;) 2014-07-27 13:19 GMT+02:00 stepharo <stepharo(a)free.fr>: > > Yes, I missed the drag and drop part. >> Will fix with next refractoring step. >> > I'm ready to integrate it :) > > :) > > >

July 27, 2014

Smalltalkhub behaves very strangely

by Attila Magyar

When I try to commit to my project, I often get an error message back. It says "Error: Could not save version". In the debugger I see that the http response code is 404. When I try to open my project on the web, I get an "Oops, not found!". But the most frightening is, that when I click on my user, under the "My projects" there is the message "No project yet". There should be about 10-12 projects under my user (zeroflag). I discovered that I can "fix" this temporaly by searching one of my projects with the search box which usually gives back some result, and after that suddenly my projects becomes visible again. After doing some commits with monticello, the problem reappears. -- View this message in context: http://forum.world.st/Smalltalkhub-behaves-very-strangely-tp4770454.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 27, 2014

Morph lost sense of bounds?

by Hilaire

Something strange I realize now: When I add one image morph into another image morph, the later one has an incorret bounds (it does not encompass its submorphs bounds) I check at bounds inst var., it is clearly over modified, it smells bad -- Dr. Geo - http://drgeo.eu iStoa - http://launchpad.net/istoa

July 27, 2014

Re: [Pharo-dev] Improving Pharo By Example

by kilon alios

no idea how to do that Serge. git repo url looks to me read only does not allow me to modify it. It says I need to authenticate using the mail and password from setting but does not tell how. I also cannot add webhooks for UPBE git repo, I tried to fork to my own githube account still same problem. On Sun, Jul 27, 2014 at 6:59 PM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > Great work Kilon ! > > Apparently, you have to remove .git in the name of your git repo (look > at the settings of your book), because everytime you click on star or > watch icon there is a wrong URL. > > Regards, > > On Sun, Jul 27, 2014 at 5:53 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > > another stupid mistake I forgot to add the book. Ok all fixed. Book is > > uploaded and here is the link > > > > https://www.gitbook.io/book/kilon/pbe > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

July 27, 2014

Re: [Pharo-dev] Improving Pharo By Example

by Serge Stinckwich

Great work Kilon ! Apparently, you have to remove .git in the name of your git repo (look at the settings of your book), because everytime you click on star or watch icon there is a wrong URL. Regards, On Sun, Jul 27, 2014 at 5:53 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > another stupid mistake I forgot to add the book. Ok all fixed. Book is > uploaded and here is the link > > https://www.gitbook.io/book/kilon/pbe -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

July 27, 2014

Re: [Pharo-dev] Improving Pharo By Example

by kilon alios

another stupid mistake I forgot to add theâ book. Ok all fixed. Book is uploaded and here is the link https://www.gitbook.io/book/kilon/pbe

July 27, 2014

Re: [Pharo-dev] Improving Pharo By Example

by kilon alios

hey guys I just committed the relevant files for gitbook for Updated PBE if someone can push into gitbook I will appreciate it because it seems that it cant authorise my account :( I use git push https://push.gitbook.io/kilon/pbe.git I enter my username and then password and it says"fatal: Authentication failed for 'https://push.gitbook.io/kilon/pbe.git/'" no idea why. On the other hand their book editor can log in to my account just fine but it also fails to publish the book. In any case the book is ready to be published is just a single command line away :) On Fri, Jun 27, 2014 at 9:05 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > you are very fast, great work Damien ! > > > On Fri, Jun 27, 2014 at 7:31 PM, Damien Cassou <damien.cassou(a)gmail.com> > wrote: > >> On Fri, Jun 27, 2014 at 3:19 PM, kilon alios <kilon.alios(a)gmail.com> >> wrote: >> > finished Chapter 4. Damien your automatic conversion tool worked very >> well >> > for me, it has been a huge boost to my workflow, there are problems >> with it >> > that I keep reporting to its github repo . I definitely see if these >> minor >> > problems are removed that the automatic conversion will do 90% of the >> work >> > for you. I am sure these problems will be fixed very soon. >> >> >> I've fixed all your conversion bugs. The only remaining problem is for >> Emacs syntax highlighting. >> >> Thank you for reporting >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." >> Winston Churchill >> >> >

July 27, 2014