- Pharo-dev - lists.pharo.org

Re: [Pharo-project] addDeferredUIMessage: Documentation

by David T. Lewis

On Mon, May 21, 2012 at 03:46:21PM -0700, Sean P. DeNigris wrote: > I want to add a good comment to addDeferredUIMessage:. I know we use it > whenever we're updating Morphic from a background thread, but I've read > stuff saying to use it when Morphic is not in a "sane" state. In Squeak: addDeferredUIMessage: valuableObject "Arrange for valuableObject to be evaluated at a time when the user interface is in a coherent state." > > When, if ever, would you call addDeferredUIMessage: from the UI thread? > > I posted the following to the Squeak list 2 years ago.... > > I'm trying to add some documentation to addDeferredUIMessage:. What's a > good summary on this method? > > I collected the following snippets from the web... > > If you want to run something that accesses the Morphic UI, even though you > are not running from somewhere that the UI is in a sane state, you should > normally use addDeferredUIMessage:. Otherwise, you can put Morphic into > extremely confused states.... > > Per Ned Konz @ http://wiki.squeak.org/squeak/528: > Deferred UI messages are processed in the middle of the Morphic event loop, > just after responding to events, and before doing other step methods and > displaying the world. Look for implementors of #addDeferredUIMessage:, look > at the one in WorldState, look for senders of #deferredUIMessages, and > you'll see WorldState>>runStepMethodsIn: which empties the queue. And it's > called from doOneCycleNowFor: which is the body of the main Morphic event > loop. > > Per http://wiki.squeak.org/squeak/5689: > If you want to run something that accesses the Morphic UI, even though you > are not running from somewhere that the UI is in a sane state, you should > normally use addDeferredUIMessage:. Otherwise, you can put Morphic into > extremely confused states.... > > Per Wilhelm K Schwab @ > http://forum.world.st/Fwd-MouseOverHandler-td1300474.html#a1300474: > provides a clean way to interact with the GUI from background threads > > Per http://www.visoracle.com/squeak/faq/containerless.html: > As it is now, it's quite simple to put long-running computations in > background threads; you just don't let the background threads call methods > directly on Morphs. We have addDeferredUIMessage: to queue up action from > the background threads for later execution in the UI thread during the > next window cycle. > > Sean > > -- > View this message in context: http://forum.world.st/addDeferredUIMessage-Documentation-tp4631251.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 22, 2012

Re: [Pharo-project] Monticello Browser messing up Morphic?

by Fernando Olivero

I haven't experienced it. To recover: The trail generally happens when you have to UI process installed. Terminate the extra one and things will be back to normal. (try with both, and the current UI process will tell you it cant be killed). Fernando On Tue, May 22, 2012 at 12:24 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Every time I go to save a package in the latest 2.0, the world gets messed up > like http://code.google.com/p/pharo/issues/detail?id=5013. It seems to start > when I click "Save" and the commit message editor comes up. If I drag it > around, it leaves a trail (the Process Browser shows a "nil" process at the > UI priority in addition to the UI process). Once I accept the comment, MC > Browser gets that big red X thing replacing the list on the left. > > Is anyone else seeing this? > > Sean > > -- > View this message in context: http://forum.world.st/Monticello-Browser-messing-up-Morphic-tp4631248.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 21, 2012

[Pharo-project] addDeferredUIMessage: Documentation

by Sean P. DeNigris

I want to add a good comment to addDeferredUIMessage:. I know we use it whenever we're updating Morphic from a background thread, but I've read stuff saying to use it when Morphic is not in a "sane" state. When, if ever, would you call addDeferredUIMessage: from the UI thread? I posted the following to the Squeak list 2 years ago.... I'm trying to add some documentation to addDeferredUIMessage:. What's a good summary on this method? I collected the following snippets from the web... If you want to run something that accesses the Morphic UI, even though you are not running from somewhere that the UI is in a sane state, you should normally use addDeferredUIMessage:. Otherwise, you can put Morphic into extremely confused states.... Per Ned Konz @ http://wiki.squeak.org/squeak/528: Deferred UI messages are processed in the middle of the Morphic event loop, just after responding to events, and before doing other step methods and displaying the world. Look for implementors of #addDeferredUIMessage:, look at the one in WorldState, look for senders of #deferredUIMessages, and you'll see WorldState>>runStepMethodsIn: which empties the queue. And it's called from doOneCycleNowFor: which is the body of the main Morphic event loop. Per http://wiki.squeak.org/squeak/5689: If you want to run something that accesses the Morphic UI, even though you are not running from somewhere that the UI is in a sane state, you should normally use addDeferredUIMessage:. Otherwise, you can put Morphic into extremely confused states.... Per Wilhelm K Schwab @ http://forum.world.st/Fwd-MouseOverHandler-td1300474.html#a1300474: provides a clean way to interact with the GUI from background threads Per http://www.visoracle.com/squeak/faq/containerless.html: As it is now, it's quite simple to put long-running computations in background threads; you just don't let the background threads call methods directly on Morphs. We have addDeferredUIMessage: to queue up action from the background threads for later execution in the UI thread during the next window cycle. Sean -- View this message in context: http://forum.world.st/addDeferredUIMessage-Documentation-tp4631251.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 21, 2012

Re: [Pharo-project] DateAndTime>>asDosTime

by Sean P. DeNigris

Camillo Bruni-3 wrote > > yep I would say so too... > the major user is zip compression hence no one will ever notice the > possibly flawed implementation :P > Yes, since the error is internally consistent (zip and unzip cancel each other out), the image doesn't notice. But I manually unzipped an mcz file and the date was way off... I created an issue and uploaded a fix: Issue 5936: DateAndTime DOS conversion http://code.google.com/p/pharo/issues/detail?id=5936 Neither #fromDosTime: nor #asDosTime seem to correctly translate from DateAndTime to DOS timestamps. Delete comment Comment 1 by project member sean.p.denigris, Today (2 hours ago) Fix in inbox: Name: SLICE-Issue-5936-DateAndTime-DOS-conversion-SeanDeNigris.1 * Fix conversion to/from DateAndTime and DOS timestamps. DOS format per http://blogs.msdn.com/b/oldnewthing/archive/2003/09/05/54806.aspx and http://mindprod.com/jgloss/zip.html * Deprecated and renamed DateAndTime>>asDosTime to #asDosTimestamp (it is not a time, but an encoded date/time) * Deprecated and renamed DateAndTime class>>fromDosSeconds: to #fromDosTimestamp (it is not a number of seconds, like a UNIX or Squeak date/time) * Updated ZipArchiveMember to use new method names * Create DosTimestamp class, and move all DOS-related logic out of DateAndTime * Update tests, removing #testAsDosTimeIndependentOfTimezone (they are not independent; DOS timestamps are in local time), and add tests, which all pass Sean -- View this message in context: http://forum.world.st/DateAndTime-asDosTime-tp4630789p4631250.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 21, 2012

[Pharo-project] Monticello Browser messing up Morphic?

by Sean P. DeNigris

Every time I go to save a package in the latest 2.0, the world gets messed up like http://code.google.com/p/pharo/issues/detail?id=5013. It seems to start when I click "Save" and the commit message editor comes up. If I drag it around, it leaves a trail (the Process Browser shows a "nil" process at the UI priority in addition to the UI process). Once I accept the comment, MC Browser gets that big red X thing replacing the list on the left. Is anyone else seeing this? Sean -- View this message in context: http://forum.world.st/Monticello-Browser-messing-up-Morphic-tp4631248.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 21, 2012

Re: [Pharo-project] Pharo conference schedule

by stephane ducasse

Here are the links. https://www.google.com/calendar/ical/2d97rjlqso704v09d49sgcsjec%40group.cal… https://www.google.com/calendar/embed?src=2d97rjlqso704v09d49sgcsjec%40grou… Stef On May 21, 2012, at 10:59 PM, StÃ©phane Ducasse wrote: > Hi guys > > I'm fighting a bit with the google calendar and the program. > Here are the latest schedule. > Remember that we want to have discussions.<Screen Shot 2012-05-21 at 10.50.40 PM.pdf><Screen Shot 2012-05-21 at 10.58.09 PM.pdf>

May 21, 2012

[Pharo-project] Pharo conference schedule

by StÃ©phane Ducasse

Hi guys I'm fighting a bit with the google calendar and the program. Here are the latest schedule. Remember that we want to have discussions.

May 21, 2012

[Pharo-project] Pharo 1.3 - Build # 36 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

May 21, 2012

[Pharo-project] Fwd: [Vm-dev] Linux 4.4.7.2357 VM crash under memory pressure

by StÃ©phane Ducasse

> Reportedly Pharo 1.3 works fine. Only Pharo 1.4 has been seen crashing so far: > > http://lists.sugarlabs.org/archive/sugar-devel/2012-May/037490.html > > And I just tried Squeak 4.3. No problem. > > - Bert - > From: Bert Freudenberg <bert(a)freudenbergs.de> > Subject: Re: [Vm-dev] Linux 4.4.7.2357 VM crash under memory pressure > Date: May 21, 2012 11:14:39 AM GMT+02:00 > To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Reply-To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > > > On 21.05.2012, at 04:32, David T. Lewis wrote: > >> >> On Sun, May 20, 2012 at 08:55:18PM +0200, Bert Freudenberg wrote: >>> >>> >>> On 20.05.2012, at 19:35, David T. Lewis wrote: >>> >>>> >>>> On Sun, May 20, 2012 at 03:08:20PM +0200, Bert Freudenberg wrote: >>>>> >>>>> Hilaire discovered that his newest DrGeo segfaults on the XO-1. It works fine elsewhere, including the XO-1.5, which has pretty much the same OS. >>>>> >>>>> We narrowed down the problem to the XO-1 having only 256 MB of RAM and no swap space. I can reproduce the crash in a virtual Ubuntu 12 with 768 MB RAM (!) but no swap. Top reports: >>>>> >>>>> Mem: 766204k total, 601588k used, 164616k free, 45624k buffers >>>>> Swap: 0k total, 0k used, 0k free, 277024k cached >>>>> >>>>> but DrGeo still crashes. Etoys runs fine using the same Squeak VM on the same system (and on XO-1). DrGeo is based on Pharo 1.4, using a closure image. Etoys still is pre-closure. >>>>> >>>> >>>> I recall some recent discussion on the Pharo list about some "strange objects" >>>> that had entered the image for a period of time. It was something to do with >>>> a mismatch in the number of instance variable slots. The VM crash is happening >>>> in a method that is stepping through the fields of an object, so if something >>>> was out of whack there it might well lead to problems. >>>> >>>> The discussion started here: >>>> >>>> http://lists.gforge.inria.fr/pipermail/pharo-project/2012-May/064539.html >>>> >>>> It would be worth checking if the DrGeo image might have this issue, in >>>> case those objects might for some reason be interacting badly with the >>>> garbage collector. >>>> >>>> Dave >>> >>> Interesting. However, it's strange that this would manifest only on machines with less memory - shouldn't the VM topple over at the first GC no matter what? >>> >> >> I don't see any obvious reason why the small memory would make a difference >> either. I'm really just trying to think of things that might be different in >> this case. The failure seems to be happening in GC code that has not changed >> in recent years, but it's happening after calling a method that depends on >> object header format (#lastPointerWhileForwarding:), and it is happening in >> code the iterates over the fields of an object. Beyond that I'm just totally >> guessing. >> >> Dumb question - do you know if any other closure-enabled images have this >> problem on small memory systems? I'd have thought someone would have noticed >> by now, but maybe not. >> >> Dave

May 21, 2012

Re: [Pharo-project] [Sugar-devel] Dr.Geo on XO 1

by StÃ©phane Ducasse

hilaire could you try a 20 image? Stef On May 21, 2012, at 8:47 PM, Hilaire Fernandes wrote: > > Bert mentionned: > > I could also reproduce it in a virtual Ubuntu 12 with 768 MB RAM (!) but > no swap. Top reports: > > Mem: 766204k total, 601588k used, 164616k free, 45624k buffers > Swap: 0k total, 0k used, 0k free, 277024k cached > > but DrGeo still crashes. > > OTOH, Etoys runs fine using the same Squeak VM on the same system (and > on XO-1). So I wonder what the new DrGeo does differently ... > > The image is in this zip archive > https://gforge.inria.fr/frs/download.php/30585/DrGeoII-12.04.xo > > Hilaire > > > Le 21/05/2012 10:51, StÃ©phane Ducasse a Ã©crit : >>>> I could also reproduce it in a virtual Ubuntu 12 with 768 MB RAM (!) but no swap. Top reports: >>>> >>>> Mem: 766204k total, 601588k used, 164616k free, 45624k buffers >>>> Swap: 0k total, 0k used, 0k free, 277024k cached >>>> >>>> but DrGeo still crashes. >>>> >>>> OTOH, Etoys runs fine using the same Squeak VM on the same system (and on XO-1). So I wonder what the new DrGeo does differently ... >>>> > >

May 21, 2012