December 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Problem with OSSubprocess / signals / heartbeat ?

by stepharong

> I asked Santa an OSSubprocess that won't hang :) I really appreciate to see such not so small polar elfves helping santa :) Stef > Thanks, > Guille > > > -------- Original Message -------- >> >>> On 19 Dec 2016, at 14:41, Mariano Martinez Peck >>> <marianopeck(a)gmail.com> wrote: >>> >>> Hi guys, >>> >>> Guille Polito kept one of these images if someone can give us a hand. >>> He also proposed the great idea of using `strace` to see what was >>> going on. He (together with Pable Tesone) suspected that the >>> heartbeat could be interrupting the `clone()` function which is (I >>> think) called internally by the 'posix_spawn()' which is the one used >>> by OSSubprocess. >>> >>> When these images are "hung" they found at a infinitive loop like this: >> Okay, how many child processes do you have at that point? How many >> processes does the system have? >> >> >>> [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- >>> [pid 17477] gettimeofday({1482152630, 593498}, NULL) = 0 >>> [pid 17477] sigreturn() (mask []) = 120 >>> [pid 17477] clone(child_stack=0, >>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, >>> child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) >>> [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- >>> [pid 17477] gettimeofday({1482152630, 600126}, NULL) = 0 >>> [pid 17477] sigreturn() (mask []) = 120 >>> [pid 17477] clone(child_stack=0, >>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, >>> child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) >> so above.. 7ms between the two gettimeofday calls? Nothing else? Set a >> breakpoint on clone/fork in gdb and look at the c-stack at this point? >> Could you strace with timestamps to see how much time is spent? Is the >> process suspicious in other ways? >> >> So yes.. sounds like clone doesn't complete.. the question is why? Is >> it out of resources? Is something in the VM blocking longer than the >> heartbeat, is the heartbeat more frequent than expected? >> >> >>> As you can see, there is a SIGALARM involved. It also looks like the >>> `gettimeofday` is used by the heartbeat ? Could it be that someone >>> the heartbeat is interrupting the `clone()` ? >>> >>> Guille also showed me the `strace` output with a regular / working >>> image: >>> >>> >>> [pid 18647] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- >>> [pid 18647] gettimeofday({1482152829, 481014}, NULL) = 0 >>> [pid 18647] sigreturn() (mask []) = -1 EINTR (Interrupted system >>> call) >>> [pid 18647] getitimer(ITIMER_REAL, {it_interval={0, 2000}, >>> it_value={0, 1917}}) = 0 >>> [pid 18647] recvmsg(3, 0xff7b0734, 0) = -1 EAGAIN (Resource >>> temporarily unavailable) >>> [pid 18647] select(4, [3], [], [3], {0, 1000}) = 0 (Timeout) >>> [pid 18647] getitimer(ITIMER_REAL, {it_interval={0, 2000}, >>> it_value={0, 797}}) = 0 >>> [pid 18647] recvmsg(3, 0xff7b0734, 0) = -1 EAGAIN (Resource >>> temporarily unavailable) >>> [pid 18647] select(4, [3], [], [3], {0, 1000}) = ? ERESTARTNOHAND (To >>> be restarted if no handler) >>> [pid 18647] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- >>> >>> >>> Does anyone have any hint here? >> Get timestamps in there. How long does it take to fail/end in this >> situation? >> >> holger >> >> >> >> >> > > > -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 20, 2016

Re: [Pharo-dev] Epicea user experience report

by stepharong

I like the second because it associates the name with the function. Stef > Hi all, > > One point of Ben's feedback is how Epicea code changes tool is presented > in the World Menu. Below you can see the current state + 3 options to > discuss it. > > > 1. "Epicea" main entry > "Session Changes" + "All Changes" children > [current state] > > > > > 2. Attach purpose to the name: "Epicea Code Changes" > > > > > 3. Just "Code Changes" + rephrase children: > > â > â > > 4. Flatten > > > â > > > Reminder: In World Menu > Help > Help Browser > Epicea you can find a > description of the tool and it's model. > > Cheers. > Martin > > On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias <tinchodias(a)gmail.com> > wrote: >> Hello Ben, >> >> About discussion points in 2 (a, b and c): I agree with your >> arguments... somebody that just moved from Pharo 5 to 6 and crashed an >> image will look for a "Recover lost changes" in the menu >>and can have >> a problem to discover it the replacement in a World->Tools->Epicea->... >> entry. >> >> Then, as a first step we could flatten the 2 menu entries and then at >> least anybody will easily find an entry related to changes in >> World->Tools. >> Second, we could try to merge both Epicea GUIs into one (suggestions >> are welcome). >> >> I still have to read more in detail the remaining of your report to >> answer. Anyway, thanks a lot for it. >> >> Cheers, >> Martin >> >> >> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> 1. Created fresh Pharo image (build 60269) >>> >>> >>> 2. Opened World > Tools > Epicea > All changes >>> >>> Points for discussion... >>> >>> a. How many submenu items are expected for Epicea? Can we push the >>> current ones up so the Tools menu remains a flat menu. >>> >>> b. Do we need the two current menu items? "Current session" is >>> encompassed by "All changes"? What expectations do people have of how >>> often they'll use the former rather than the latter? >>> >>> c. When people move from Pharo 5 to Pharo 6 and in a panic want to >>> "recover changes" for a crashed image, they'll be looking for that >>> familiar feature name, not a new app name. Could the app name be left >>> out or placed in brackets "Changes (Epicea)". >>> >>> btw, the interface looks really slick! nice work. >>> >>> >>> 3. Opened World > System Browser. >>> >>> 4. Added package AAA >>> All Changes window - no dynamic change. >>> On <refresh>, still no change, i.e. no sessions >>> #New All Changes window - not visible, no sessions. >>> >>> 5. Added class AA. >>> All Changes window - no dynamic change. >>> On <refresh>, shows new session with AAA & AA. >>> >>> 5. Added method... >>> AA>a >>> ^'something' >>> Prompted for author, entered 'BenComan' >>> All Changes window with session selected - dynamic update showing >>> AA>>a. >>> >>> 6. Added package BBB. >>> All Changes window - no dynamic update. >>> On <refresh>, BBB still not visible in session. >>> >>> 7. Added class A to package AAA. >>> All Changes window - dynamic update showing A. >>> On <refresh>, BBB still not visible in session. >>> >>> 8. Added class BB to package BBB. >>> All Changes window - dynamic update showing BBB & BB. >>> >>> a. Package creation event seems not handled properly, being only >>> pushed through when a class is created in it. >>> >>> b. Since there is a dynamic update for class and method >>> modifications, could the session creation also dynamically update it >>> UI. >>> >>> ----------- >>> 9. Killed the vm from command line >>> $ ps -ef | grep pharo >>> $ kill 29349 >>> Restarted Pharo image >>> >>> 10. World > Tools > Epica > All changes. >>> Authorship is inconsistent: >>> * AAA and AA have blank author >>> * AA>>a, A, BBB, B have author 'BenComan'. >>> >>> a. I understand this follows on from Author not being requested until >>> the first method was defined. Did the old changes track the author of >>> packages and classes at all? >>> >>> b. Since Epicea can track package and class authors, can we trigger >>> the author prompt earlier for them? >>> >>> 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB >>> and did <Apply Changes>. >>> Prompted for author. Entered 'DrWho' >>> Existing All Changes window - no change >>> New All Changes window - shows new session with all six changes. >>> Authorship is a little inconsistent: >>> * AAA and AA have author 'Unknown'. >>> * AA>>a, A, BBB, B have blank author. >>> >>> 12. Killed the vm from command line >>> $ ps -ef | grep pharo >>> $ kill 30696 >>> Restarted Pharo image >>> >>> 13. World > Tools > Epica > All changes. >>> Authorship is a little inconsistent: >>> First session >>> * AAA and AA have blank author >>> * AA>>a, A, BBB, B have author 'BenComan'. >>> Second session >>> * AAA and AA have blank author >>> * AA>>a, A, BBB, B have author 'DrWho'. >>> >>> a. Epicea changes are reapplied as the current author. This seems a >>> semantic change from Pharo 5 where changes were reapplied as their >>> original author. Is this accidental or by design? Can we have some >>> community discussion on this point (I don't remember seeing any)? >>> >>> cheers -ben >>> >>> P.S. I'll wait to see what arises out of discussion before creating >>> any issues. >>> >> > -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 20, 2016

Re: [Pharo-dev] Epicea user experience report

by Sean P. DeNigris

Marcus Denker-4 wrote >> 3. Just "Code Changes" + rephrase children: > I like that most. It is the easiest to understand for newcomers. +1 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Epicea-user-experience-report-tp4920653p4927604.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 20, 2016

Re: [Pharo-dev] all black pharo 6.0 window on startup - unresponsive

by Dale Henrichs

#60332 is indeed working, thanks again! On 12/20/2016 10:19 AM, Dale Henrichs wrote: > Thanks Marcus, I will download and try again... > > > On 12/20/2016 10:17 AM, Marcus Denker wrote: >> Hi, >> >> This happend for 60330, but we have reverted and it should be working >> now again (e.g. with 60332) >> >>> On 20 Dec 2016, at 15:09, Dale Henrichs >>> <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> Running Ubuntu 14.04 and a fresh download (as of yesterday) when >>> pharo comes up I get an unresponsive and all black window -- I have >>> to kill the process. >>> >>> I have an older download of pharo6.0 that works fine ... >>> >>> Both vms are the same version: >>> >>> 5.0 #1 Tue Jun 21 12:37:33 CEST 2016 gcc 4.6.3 [Production Spur ITHB >>> VM] >>> CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: >>> 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016 >>> StackToRegisterMappingCogit >>> VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: >>> 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016 >>> https://github.com/pharo-project/pharo-vm.git Commit: >>> 9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 >>> +0200 By: GitHub <noreply(a)github.com> Jenkins build #594 >>> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 >>> 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux >>> plugin path: >>> /export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/ >>> [default: >>> /export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/] >>> >>> .. so there must be something wrong in the image itself ... >>> >>> The image that works is: Latest update: #60265 >>> >>> Not sure how to find out what update I am using, since the GUI isn't >>> functional. >>> >>> Dale >>> >>> >> >

Dec. 20, 2016

Re: [Pharo-dev] all black pharo 6.0 window on startup - unresponsive

by Dale Henrichs

Thanks Marcus, I will download and try again... On 12/20/2016 10:17 AM, Marcus Denker wrote: > Hi, > > This happend for 60330, but we have reverted and it should be working > now again (e.g. with 60332) > >> On 20 Dec 2016, at 15:09, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> Running Ubuntu 14.04 and a fresh download (as of yesterday) when pharo comes up I get an unresponsive and all black window -- I have to kill the process. >> >> I have an older download of pharo6.0 that works fine ... >> >> Both vms are the same version: >> >> 5.0 #1 Tue Jun 21 12:37:33 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM] >> CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016 >> StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016 >> https://github.com/pharo-project/pharo-vm.git Commit: 9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 +0200 By: GitHub <noreply(a)github.com> Jenkins build #594 >> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux >> plugin path: /export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/ [default: /export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/] >> >> .. so there must be something wrong in the image itself ... >> >> The image that works is: Latest update: #60265 >> >> Not sure how to find out what update I am using, since the GUI isn't functional. >> >> Dale >> >> >

Dec. 20, 2016

Re: [Pharo-dev] all black pharo 6.0 window on startup - unresponsive

by Marcus Denker

Hi, This happend for 60330, but we have reverted and it should be working now again (e.g. with 60332) > On 20 Dec 2016, at 15:09, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Running Ubuntu 14.04 and a fresh download (as of yesterday) when pharo comes up I get an unresponsive and all black window -- I have to kill the process. > > I have an older download of pharo6.0 that works fine ... > > Both vms are the same version: > > 5.0 #1 Tue Jun 21 12:37:33 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM] > CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016 > StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016 > https://github.com/pharo-project/pharo-vm.git Commit: 9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 +0200 By: GitHub <noreply(a)github.com> Jenkins build #594 > Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux > plugin path: /export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/ [default: /export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/] > > .. so there must be something wrong in the image itself ... > > The image that works is: Latest update: #60265 > > Not sure how to find out what update I am using, since the GUI isn't functional. > > Dale > >

Dec. 20, 2016

all black pharo 6.0 window on startup - unresponsive

by Dale Henrichs

Running Ubuntu 14.04 and a fresh download (as of yesterday) when pharo comes up I get an unresponsive and all black window -- I have to kill the process. I have an older download of pharo6.0 that works fine ... Both vms are the same version: 5.0 #1 Tue Jun 21 12:37:33 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM] CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016 StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016 https://github.com/pharo-project/pharo-vm.git Commit: 9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 +0200 By: GitHub <noreply(a)github.com> Jenkins build #594 Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux plugin path: /export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/ [default: /export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/] .. so there must be something wrong in the image itself ... The image that works is: Latest update: #60265 Not sure how to find out what update I am using, since the GUI isn't functional. Dale

Dec. 20, 2016

Re: [Pharo-dev] Epicea user experience report

by Marcus Denker

> > > 3. Just "Code Changes" + rephrase children: > > â<Code Changes.png> > â > I like that most. It is the easiest to understand for newcomers. Marcus

Dec. 20, 2016

Re: [Pharo-dev] Epicea user experience report

by Martin Dias

Hi all, One point of Ben's feedback is how Epicea code changes tool is presented in the World Menu. Below you can see the current state + 3 options to discuss it. 1. "Epicea" main entry > "Session Changes" + "All Changes" children [current state] 2. Attach purpose to the name: "Epicea Code Changes" 3. Just "Code Changes" + rephrase children: â â 4. Flatten â Reminder: In World Menu > Help > Help Browser > Epicea you can find a description of the tool and it's model. Cheers. Martin On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hello Ben, > > About discussion points in 2 (a, b and c): I agree with your arguments... > somebody that just moved from Pharo 5 to 6 and crashed an image will look > for a "Recover lost changes" in the menu and can have a problem to discover > it the replacement in a World->Tools->Epicea->... entry. > > Then, as a first step we could flatten the 2 menu entries and then at > least anybody will easily find an entry related to changes in World->Tools. > > Second, we could try to merge both Epicea GUIs into one (suggestions are > welcome). > > I still have to read more in detail the remaining of your report to > answer. Anyway, thanks a lot for it. > > Cheers, > Martin > > > On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> 1. Created fresh Pharo image (build 60269) >> >> >> 2. Opened World > Tools > Epicea > All changes >> >> Points for discussion... >> >> a. How many submenu items are expected for Epicea? Can we push the >> current ones up so the Tools menu remains a flat menu. >> >> b. Do we need the two current menu items? "Current session" is >> encompassed by "All changes"? What expectations do people have of how >> often they'll use the former rather than the latter? >> >> c. When people move from Pharo 5 to Pharo 6 and in a panic want to >> "recover changes" for a crashed image, they'll be looking for that >> familiar feature name, not a new app name. Could the app name be left >> out or placed in brackets "Changes (Epicea)". >> >> btw, the interface looks really slick! nice work. >> >> >> 3. Opened World > System Browser. >> >> 4. Added package AAA >> All Changes window - no dynamic change. >> On <refresh>, still no change, i.e. no sessions >> #New All Changes window - not visible, no sessions. >> >> 5. Added class AA. >> All Changes window - no dynamic change. >> On <refresh>, shows new session with AAA & AA. >> >> 5. Added method... >> AA>a >> ^'something' >> Prompted for author, entered 'BenComan' >> All Changes window with session selected - dynamic update showing AA>>a. >> >> 6. Added package BBB. >> All Changes window - no dynamic update. >> On <refresh>, BBB still not visible in session. >> >> 7. Added class A to package AAA. >> All Changes window - dynamic update showing A. >> On <refresh>, BBB still not visible in session. >> >> 8. Added class BB to package BBB. >> All Changes window - dynamic update showing BBB & BB. >> >> a. Package creation event seems not handled properly, being only >> pushed through when a class is created in it. >> >> b. Since there is a dynamic update for class and method >> modifications, could the session creation also dynamically update it >> UI. >> >> ----------- >> 9. Killed the vm from command line >> $ ps -ef | grep pharo >> $ kill 29349 >> Restarted Pharo image >> >> 10. World > Tools > Epica > All changes. >> Authorship is inconsistent: >> * AAA and AA have blank author >> * AA>>a, A, BBB, B have author 'BenComan'. >> >> a. I understand this follows on from Author not being requested until >> the first method was defined. Did the old changes track the author of >> packages and classes at all? >> >> b. Since Epicea can track package and class authors, can we trigger >> the author prompt earlier for them? >> >> 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB >> and did <Apply Changes>. >> Prompted for author. Entered 'DrWho' >> Existing All Changes window - no change >> New All Changes window - shows new session with all six changes. >> Authorship is a little inconsistent: >> * AAA and AA have author 'Unknown'. >> * AA>>a, A, BBB, B have blank author. >> >> 12. Killed the vm from command line >> $ ps -ef | grep pharo >> $ kill 30696 >> Restarted Pharo image >> >> 13. World > Tools > Epica > All changes. >> Authorship is a little inconsistent: >> First session >> * AAA and AA have blank author >> * AA>>a, A, BBB, B have author 'BenComan'. >> Second session >> * AAA and AA have blank author >> * AA>>a, A, BBB, B have author 'DrWho'. >> >> a. Epicea changes are reapplied as the current author. This seems a >> semantic change from Pharo 5 where changes were reapplied as their >> original author. Is this accidental or by design? Can we have some >> community discussion on this point (I don't remember seeing any)? >> >> cheers -ben >> >> P.S. I'll wait to see what arises out of discussion before creating any >> issues. >> >> >

Dec. 20, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60332 Home: https://github.com/pharo-project/pharo-core

Dec. 20, 2016