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

Re: [Pharo-dev] Pharo 3.0 not responding to mouse or keyboard after launch

by Esteban Lorenzano

Hi Andres, Pharo (Cuis) does not exitâ¦ I suppose you are talking about the vm from Pharo, used with a Cuis imageâ¦ can you confirm that same problem exists in pharo-vm with pharo-image? Esteban On 13 Jan 2014, at 09:37, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > Try the following on OS X... > > 1. Launch Pharo (Cuis). > > 2. Go to the System Settings time panel. > > 3. Disable automatic time updates. > > 4. Bump the clock forward by 1 minute. > > 5. Check whether Pharo is still responsive (in the case of Cuis, it's frozen). > > 6. Wait one minute. > > 7. Check whether Pharo is still responsive (in the case of Cuis, it's responsive again). > > > As a variation, disable automatic time updates, then bump the clock backwards by 1 minute. Things still work. Then re-enable automatic time updates. When the clock goes forward, the prediction is that Pharo (Cuis) will be frozen for 1 minute. > > If this repeats for you, then also look at /var/log/system.log and see how many entries are there for NTP. If you see that NTP periodically adjusts the clock forward, then you can also expect that Pharo (Cuis) will periodically be frozen for as much time as NTP (and, on OS X 10.9, pacemaker) bumps the clock forward. > > I can reproduce this behavior on OS X 10.9 with a modern Cog VM and Cuis images. > > On 1/13/14 0:22 , Sven Van Caekenberghe wrote: >> Hi Andres, >> >> Could you describe in some detail how to make something clearly fail related to this issue ? >> >> There have been mysterious time(r) related problems in the past, it would be good to follow up on something concrete and repeatable. >> >> Thx, >> >> Sven >> >> On 12 Jan 2014, at 04:41, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: >> >>> Somewhat related only, but FYI something I've noticed with Cog VMs is that if you bump the computer clock forward by e.g. 30 seconds then Cuis remains frozen for 30 seconds. Under the assumption that Cuis and Pharo are close enough, and considering that alt+. does not bring up a debugger while the image remains frozen, I can't help asking whether the VM is setting up OS alarms at a certain wall clock hour instead of setting up timers that expire after N time has elapsed (irrespective of the wall clock). If the VM is setting up alarms at wall clock hours, then I'd strongly suggest changing that behavior because of NTP, time zone adjustments, etc. >>> >>> BTW, I found this because apparently Mavericks isn't keeping time that great and NTP frequently changes the clock by ~2 seconds. >>> >>> On 1/11/14 19:29 , Martin McClure wrote: >>>> I'm beginning to suspect that delays are not expiring at the OS level >> >> . >> >

Jan. 13, 2014

Re: [Pharo-dev] [ANN]: EventRecorderMorph Port to 3.0

by Goubier Thierry

Le 13/01/2014 10:09, roberto.minelli(a)usi.ch a Ã©crit : > I am working on a similar thing (without the replaying feature). > I am interested in profiling (i.e., recording) some morphic events. I use a tracing framework I wrote a long time ago for things like that. It's called Jejak (http://smalltalkhub.com/#!/~ThierryGoubier/Jejak) and has the ability to trace and record events from running code, even critical code like Morphic. I'm updating it for Pharo3 at the moment. And it would be great to use the new Opal facilities for doing so... at the moment, it's working by code rewriting (which is a very portable approach). Thierry > I will look into this existing recorder, thanks for sharing. > > Cheers, > R > > On Jan 13, 2014, at 9:03 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Cool! This is really interesting to have. >> >> Executable screencasts... I'll do that next time for teaching with Pharo :) >> >> Thierry >> >> Le 13/01/2014 04:14, Sean P. DeNigris a Ã©crit : >>> If you don't know EventRecorderMorph and HandMorphForReplay (which I didn't >>> and started to re-implement), they are super cool. >>> >>> 1. DoIt: "EventRecorderMorph new openInWorld" >>> 2. Click "record" in the GUI >>> 3. Perform some UI actions >>> 4. Click "play" in the GUI >>> >>> Your keyboard and mouse actions will be replayed in the World! I know >>> right?! Amazing. This could be really cool for live documentation and >>> executable screencasts :) >>> >>> It's just a straight port now, but I'd like to decouple the recorder and >>> replay hand so that any event source can be used. >>> >>> http://smalltalkhub.com/#!/~PharoExtras/EventRecorder >>> >>> Initial commit: port EventRecorderMorph and HandMorphForReplay (originally >>> in MorphicExtras-AdditionalSupport) to Pharo 3.0 >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: http://forum.world.st/ANN-EventRecorderMorph-Port-to-3-0-tp4736258.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>> >>> >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Jan. 13, 2014

Re: [Pharo-dev] [ANN]: EventRecorderMorph Port to 3.0

by roberto.minelli＠usi.ch

I am working on a similar thing (without the replaying feature). I am interested in profiling (i.e., recording) some morphic events. I will look into this existing recorder, thanks for sharing. Cheers, R On Jan 13, 2014, at 9:03 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Cool! This is really interesting to have. > > Executable screencasts... I'll do that next time for teaching with Pharo :) > > Thierry > > Le 13/01/2014 04:14, Sean P. DeNigris a Ã©crit : >> If you don't know EventRecorderMorph and HandMorphForReplay (which I didn't >> and started to re-implement), they are super cool. >> >> 1. DoIt: "EventRecorderMorph new openInWorld" >> 2. Click "record" in the GUI >> 3. Perform some UI actions >> 4. Click "play" in the GUI >> >> Your keyboard and mouse actions will be replayed in the World! I know >> right?! Amazing. This could be really cool for live documentation and >> executable screencasts :) >> >> It's just a straight port now, but I'd like to decouple the recorder and >> replay hand so that any event source can be used. >> >> http://smalltalkhub.com/#!/~PharoExtras/EventRecorder >> >> Initial commit: port EventRecorderMorph and HandMorphForReplay (originally >> in MorphicExtras-AdditionalSupport) to Pharo 3.0 >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/ANN-EventRecorderMorph-Port-to-3-0-tp4736258.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Jan. 13, 2014

Re: [Pharo-dev] Pharo 3.0 not responding to mouse or keyboard after launch

by Andres Valloud

Try the following on OS X... 1. Launch Pharo (Cuis). 2. Go to the System Settings time panel. 3. Disable automatic time updates. 4. Bump the clock forward by 1 minute. 5. Check whether Pharo is still responsive (in the case of Cuis, it's frozen). 6. Wait one minute. 7. Check whether Pharo is still responsive (in the case of Cuis, it's responsive again). As a variation, disable automatic time updates, then bump the clock backwards by 1 minute. Things still work. Then re-enable automatic time updates. When the clock goes forward, the prediction is that Pharo (Cuis) will be frozen for 1 minute. If this repeats for you, then also look at /var/log/system.log and see how many entries are there for NTP. If you see that NTP periodically adjusts the clock forward, then you can also expect that Pharo (Cuis) will periodically be frozen for as much time as NTP (and, on OS X 10.9, pacemaker) bumps the clock forward. I can reproduce this behavior on OS X 10.9 with a modern Cog VM and Cuis images. On 1/13/14 0:22 , Sven Van Caekenberghe wrote: > Hi Andres, > > Could you describe in some detail how to make something clearly fail related to this issue ? > > There have been mysterious time(r) related problems in the past, it would be good to follow up on something concrete and repeatable. > > Thx, > > Sven > > On 12 Jan 2014, at 04:41, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > >> Somewhat related only, but FYI something I've noticed with Cog VMs is that if you bump the computer clock forward by e.g. 30 seconds then Cuis remains frozen for 30 seconds. Under the assumption that Cuis and Pharo are close enough, and considering that alt+. does not bring up a debugger while the image remains frozen, I can't help asking whether the VM is setting up OS alarms at a certain wall clock hour instead of setting up timers that expire after N time has elapsed (irrespective of the wall clock). If the VM is setting up alarms at wall clock hours, then I'd strongly suggest changing that behavior because of NTP, time zone adjustments, etc. >> >> BTW, I found this because apparently Mavericks isn't keeping time that great and NTP frequently changes the clock by ~2 seconds. >> >> On 1/11/14 19:29 , Martin McClure wrote: >>> I'm beginning to suspect that delays are not expiring at the OS level > > . >

Jan. 13, 2014

Re: [Pharo-dev] Pharo 3.0 not responding to mouse or keyboard after launch

by Sven Van Caekenberghe

Hi Andres, Could you describe in some detail how to make something clearly fail related to this issue ? There have been mysterious time(r) related problems in the past, it would be good to follow up on something concrete and repeatable. Thx, Sven On 12 Jan 2014, at 04:41, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > Somewhat related only, but FYI something I've noticed with Cog VMs is that if you bump the computer clock forward by e.g. 30 seconds then Cuis remains frozen for 30 seconds. Under the assumption that Cuis and Pharo are close enough, and considering that alt+. does not bring up a debugger while the image remains frozen, I can't help asking whether the VM is setting up OS alarms at a certain wall clock hour instead of setting up timers that expire after N time has elapsed (irrespective of the wall clock). If the VM is setting up alarms at wall clock hours, then I'd strongly suggest changing that behavior because of NTP, time zone adjustments, etc. > > BTW, I found this because apparently Mavericks isn't keeping time that great and NTP frequently changes the clock by ~2 seconds. > > On 1/11/14 19:29 , Martin McClure wrote: >> I'm beginning to suspect that delays are not expiring at the OS level

Jan. 13, 2014

Re: [Pharo-dev] Pharo3 and MetacelloPreview

by Johan Brichau

Sorry, I meant the loading of the following: ((Smalltalk at: #ConfigurationOfMetacello) new project version: #previewBootstrap) load. On 13 Jan 2014, at 09:18, Johan Brichau <johan(a)inceptive.be> wrote: > Hi all, > > When I load the Metacello Preview in Pharo3, I get a very weird loading of the Phantom-Core-dgg.24 package (which yields a warning because of unexisting classes in the image). > > Nowhere in my image (thus all loaded configurations) I can find the name 'Phantom'. So where is this coming from? > What I can make of the execution stack in Metacello is that 'Metacello-ProfStef-dkh.13' strangely resolves to a loading of 'Phantom-Core-dgg.24' > > Anyone using the Metacello Preview in Pharo3? > Anyone experiencing the same? > > Johan

Jan. 13, 2014

Re: [Pharo-dev] Pharo 3.0 not responding to mouse or keyboard after launch

by Sven Van Caekenberghe

Thanks for the persistency in track down this problem, Martin. And for sharing it with the list. Sven On 13 Jan 2014, at 07:50, Martin McClure <martin(a)hand2mouse.com> wrote: > On 01/12/2014 10:18 PM, HernÃ¡n Morales Durand wrote: >> That sounds really weird. Having to launch from GUI to start a working >> image is not very convenient. >> Let us know if you have any other findings. > > Thanks. After some digging, I think I've got it. > > The pharo executable is launched by the bash shell via a fork followed by an execve. The signal mask is inherited from the parent process, and preserved across the execve. Pharo does not modify the signal mask except once: > > rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 > > which only appears to deal with one real-time signal. > > In my case, somehow one set of shells has SIGALRM masked, and another set of shells does not have it masked. Pharo seems to rely on SIGALRMs from the interval timer to wake it up periodically (every 2 ms) presumably to see whether it has any work to do. > > So no SIGALRMS delivered, not much happens. > > I have no idea why my shells are masking various signals, but it seems clear that it would be a good idea for the VM to initialize its signal mask explicitly rather than depending on the parent process to have it set sanely. > > So I count this one as a VM bug. If someone better connected with the VM community would report it as such, I'd appreciate it. > > Thanks for all the suggestions while I dug to the bottom of this one. > > Regards, > > -Martin >

Jan. 13, 2014

Pharo3 and MetacelloPreview

by Johan Brichau

Hi all, When I load the Metacello Preview in Pharo3, I get a very weird loading of the Phantom-Core-dgg.24 package (which yields a warning because of unexisting classes in the image). Nowhere in my image (thus all loaded configurations) I can find the name 'Phantom'. So where is this coming from? What I can make of the execution stack in Metacello is that 'Metacello-ProfStef-dkh.13' strangely resolves to a loading of 'Phantom-Core-dgg.24' Anyone using the Metacello Preview in Pharo3? Anyone experiencing the same? Johan

Jan. 13, 2014

Re: [Pharo-dev] [ANN]: EventRecorderMorph Port to 3.0

by Goubier Thierry

Cool! This is really interesting to have. Executable screencasts... I'll do that next time for teaching with Pharo :) Thierry Le 13/01/2014 04:14, Sean P. DeNigris a Ã©crit : > If you don't know EventRecorderMorph and HandMorphForReplay (which I didn't > and started to re-implement), they are super cool. > > 1. DoIt: "EventRecorderMorph new openInWorld" > 2. Click "record" in the GUI > 3. Perform some UI actions > 4. Click "play" in the GUI > > Your keyboard and mouse actions will be replayed in the World! I know > right?! Amazing. This could be really cool for live documentation and > executable screencasts :) > > It's just a straight port now, but I'd like to decouple the recorder and > replay hand so that any event source can be used. > > http://smalltalkhub.com/#!/~PharoExtras/EventRecorder > > Initial commit: port EventRecorderMorph and HandMorphForReplay (originally > in MorphicExtras-AdditionalSupport) to Pharo 3.0 > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ANN-EventRecorderMorph-Port-to-3-0-tp4736258.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Jan. 13, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by phil＠highoctane.be

Cmd-L... of course one has to know why it is there in the first place. And no dialog or undo is needed. Why not put the content in the clipboard and be done with it? I am doing select all and copy before some Cmd-L. Oops didn't wanted to spawn further discussion... Just that it is the way I use it now. On Monday, January 13, 2014, Sven Van Caekenberghe wrote: > > On 13 Jan 2014, at 01:12, Sebastian Sastre <sebastian(a)flowingconcept.com<javascript:;>> > wrote: > > > > > On Jan 12, 2014, at 7:59 PM, Sven Van Caekenberghe <sven(a)stfx.eu<javascript:;>> > wrote: > > > >> Cancel is next to Accept in almost any Edit menu, with the command keys > L and S respectively. You should have seen this the moment you started > coding: > > > > This comment brings something interesting to add to the discussion and, > Sven, you might not have said that in this way but, with your permission, I > want to point out this only to leave a record for all of us to reflect. > > > > you see... the problem with what should or shouldn't have the user seen, > is that it suggest the user is under evaluation. > > > > Worst, it suggest a dualistic way to evaluate it. > > > > Is not the user who is under evaluation. > > > > It's your product's success in helping the user to do some task with > less resistance. > > > > The way you evaluate usability is in observing the resistance points (UI > fails), or absence of it (UI successes) on tasks the user is trying to > achieve. > > > > Of course our challenge and opportunity is in embracing this and take a > deep breath to resist the temptation to appeal to any of these: > > > http://www.satinderrana.com/blog/2010/07/top-20-excuses-for-broken-code-by-… > > > > Pharo rocks and, as all products, has space for improvements (I can give > quite some feedback about that menu BTW) > > > > What we have here, is an opportunity to put some love in its user > experience to make it more awesome for more people > > > > sebastian > > > > o/ > > Please do, Sebastian, start discussing about ways to improve the basic UI, > you seem to have an interest in the subject. It will of course be quite > hard with so many opinions. > > Sven > > > > -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Jan. 13, 2014