On Aug 16, 2009, at 12:07 PM, Igor Stasenko wrote: > 2009/8/16 Stéphane Ducasse <[email protected]>: >> Bill (and igor) >> >> I would love to continue to remove Project from the image so the >> "spawnProcessIfThisIsUI:self activeProcess." >> should probably find another host. Do you have an idea about the >> class >> that could be the natural place to define >> such a method? >> if so can you propose a change? >> > > IMO WorldState is the way to go. > Since you removing Project, then you couldn't have multiple worlds, > right? yes projects are totally broken in pharo.
> >> Stef >> >> >> On Aug 16, 2009, at 5:57 AM, Schwab,Wilhelm K wrote: >> >>> Sig, all, >>> >>> I have been preparing MC packages with classes and method designed >>> to soften the blow of moving much of my domain code to Pharo. In >>> this case, I have some sends of ProcessorSchedler>>forkMainIfMain, >>> so I created that method. Initially, I made it emtpy, and then >>> based on what you helpe me find, I tried >>> >>> ProcessorScheduler>>forkMainIfMain >>> Project spawnProcessIfThisIsUI:self activeProcess. >>> >>> >>> The above gets called from something that then immediately waits on >>> a semaphore that is signalled by one of two threads. One of the >>> threads waits on a timer, the other tries to evaluate a block; >>> creating a background worker thread that will run for a limited >>> time. There is a test case that tries various combinations, some of >>> which should succeed and some should time out. I have used these >>> things in production in Dolphin for some time. >>> >>> In Dolphin, #forkMainIfMain allows the UI to be responsive during >>> these tests, but trying the above in Pharo turns ugly. There are >>> problems that appear to related to two UI processes - running short >>> of events or something like that. The tests run for only a few >>> seconds, though I suppose I could try to allow enough time to look >>> around, but then I'm probably not the right person to do the looking >>> anyway. >>> >>> DUMB question: the argument to #spawnProcessIfThisIsUI: is named >>> suspendedProcess. Do I need to ensure the process in question is >>> indeed suspended before entering the method? If so, then I start >>> wondering how to get there from #forkMainIfMain, but it's a little >>> late for my brain to take on that question. >>> >>> One thing is certain: what I tried did not work. There were errors >>> from the event loop and even some screen scarring. >>> >>> Bill >>> >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected] >>> ] On Behalf Of Igor Stasenko >>> Sent: Saturday, August 15, 2009 3:29 PM >>> To: [email protected] >>> Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? >>> >>> 2009/8/15 Schwab,Wilhelm K <[email protected]>: >>>> Is there anything in Pharo that starts a new main thread to carry >>>> on for one that is about to get blocked? It might be that Pharo >>>> does not need it, since sockets are serviced by the VM, where >>>> Dolphin (at least prior to overlapped calls) did the I/O through >>>> the event loop; if the main thread stopped, so did Windows event >>>> dispatching, and hence no socket I/O. >>>> >>> There is such thing. >>> Try to explore the way how debugger handling this (when process you >>> want to debug is current UI process), or when you pressing interrupt >>> key. >>> >>> See Debugger>>openOn: process context: context label: title >>> contents: >>> contentsStringOrNil fullView: bool >>> >>> at 'Project spawnNewProcessIfThisIsUI: process' >>> >>> >>> >>>> Dolphin to some extent, and WindowBuilder to (IIRC) a large extent >>>> create modal loops in Smalltalk code. I see a few references to >>>> such things in Pharo, but I'm fairly lost. Where should I start >>>> reading and/or browsing? >>>> >>>> Bill >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
