August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Complex Number Discussion

by Ken.Dickey

HELP REQUEST I am working an old, very slow machine and must be missing something. I have browsed senders of #sqrt and run the full test suite with sqrt either answering a complex or giving an error on negative arguments and have not seen a difference. Can someone please send me a/some non-trivial examples of where returning complex results for negative arguments breaks something. Thanks a bunch, -KenD

Aug. 16, 2009

Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?

by Schwab,Wilhelm K

Sig, Two UI processes polling for input is probably what has happened. I should give some attention to how Dolphin prevents that. Two things that come to mind are raising the priority of a new UI thread to create a modal event loop, and (which Pharo almost certainly does too) starting a new UI thread when needed. My TimedEvaluator class has headless and "with progres" subclasses. The latter will need some porting, and perhaps the headless one should simply block, or at least do so in Pharo. Terminating the UI thread seems a little harsh, but that might be what is needed. Another option might be to suspend the old UI thread, start the new one, and then undo the damage at the end. Is that something that #forkMainIfMain should do automatically? One of the things that drives me nuts is whether a #suspend would stop the thread that is trying to do the work =:0 Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Sunday, August 16, 2009 5:05 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? 2009/8/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > 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. > I think, once you spawn a new UI process by your code, you should prevent an old process from returning back to World/WorldState event handling, by simply terminating it after you done. Otherwise, again, take a look what debugger does, when you clicking 'proceed' on a process which being debugged and which was a UI process. It should do some tricks, otherwise you end up with two event loops polling the same event source. > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor > Stasenko > Sent: Saturday, August 15, 2009 3:29 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? > > 2009/8/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> 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 >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 16, 2009

Re: [Pharo-project] Beta: browser missing splitters?

by Damien Cassou

This seems related to Seaside and not to Pharo. Could you please repost there? Thank you On Tue, Aug 11, 2009 at 9:07 PM, Schwab,Wilhelm K<bschwab(a)anest.ufl.edu> wrote: > I wanted to take a look at Seaside 2.9's WADevelopment class, specifically how it automates saving packages. Â After finding the download system for Seaside (very nice!), I had a great excuse to grab the beta and load 2.9 from a change set. Â It worked - congrats to all involved. > > One thing that stands out to me is that the panes in the browser appear to lack splitters, so one is stuck with their relative sizes :( > > As a secondary item, when trying to click-drag where a splitter might be, it picks up the entire browser; IMHO, it should ignore the input. Â Better still, it should have splitters. > > Please view all of this as a success. Â I loaded a beta web framework into a beta Smalltalk system, and that's worst that happened! Â In fairness, I have not tried to use Seaside 2.9, but for now, I just want to organize the saving of my packages to go from my current image into the beta. > > Bill > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 16, 2009

Re: [Pharo-project] right button still doesn't work on Windows

by Damien Cassou

Please add a comment on the bug tracker saying what should be done. 2009/8/11 Mariano Martinez Peck <marianopeck(a)gmail.com>: > With Pharo beta, right button still doesn't work out of the box in Windows. > Instead, you have to use the wheel button. > > To fix it, you must evaluate:Â Â InputEventSensor installMouseDecodeTable > > I saw that in: http://code.google.com/p/pharo/issues/detail?id=838 > > The thing is...where can I put that code so that new images work out of the > box? > > Best, > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 16, 2009

Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?

by Schwab,Wilhelm K

Stef, When I saw Project was involved, I immediately though you and the other usual suspects in the "cleaning" business - you guys do great work, and it can't be easy. FWIW, Dolphin defines ProcessorScheduler>>forkMainIfMain, and I have code that uses same, so there likely will be such a method in my image at least. Of course, I can write it in terms of anything else you might want to use, but it seems a logical choice to me. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Sunday, August 16, 2009 4:18 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? 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? 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: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of Igor Stasenko > Sent: Saturday, August 15, 2009 3:29 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? > > 2009/8/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> 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 >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 16, 2009

Re: [Pharo-project] [update] 10414

by Igor Stasenko

2009/8/16 Marcus Denker <denker(a)acm.org>: > > On 13.08.2009, at 16:26, Adrian Lienhard wrote: > >> update #10414 >> ----------------- >> 310+311: Reorganize unit tests in a more modular way such that they >> can be unloaded >> >> Now all unit tests are in the packages "Tests", "CollectionsTests", >> "KernelTests", "MorphicTests", etc. The key point of this >> reorganization is to make these packages really modular, i.e., they >> can be unloaded without leaving obsolete classes behind. I also made >> sure that SUnit with its GUI is unloadable. >> >> If you execute in a Pharo-core image: >> >> ScriptLoader new cleanUpForProduction; cleanUpForRelease >> >> you get an image without tests and SUnit that is 8.0 MB on disk. >> > > And after deleting the ScriptLoader class, it's only 6.9 MB. > Very good! > Â Â Â Â Marcus > > > -- > Marcus Denker - http://marcusdenker.de > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 16, 2009

Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?

by Igor Stasenko

2009/8/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > 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? > 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: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of Igor Stasenko >> Sent: Saturday, August 15, 2009 3:29 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? >> >> 2009/8/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> 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 >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 16, 2009

Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?

by Igor Stasenko

2009/8/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > 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. > I think, once you spawn a new UI process by your code, you should prevent an old process from returning back to World/WorldState event handling, by simply terminating it after you done. Otherwise, again, take a look what debugger does, when you clicking 'proceed' on a process which being debugged and which was a UI process. It should do some tricks, otherwise you end up with two event loops polling the same event source. > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko > Sent: Saturday, August 15, 2009 3:29 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? > > 2009/8/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> 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 >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 16, 2009

Re: [Pharo-project] Class browser with changing title.

by Henrik Sperre Johansen

This change was for the OB-browsers. IMHO, I'd be nice to have the same functionality in (the thing previously known as) Pharo-core too, though :) Cheers, Henry On 16.08.2009 11:02, StÃ©phane Ducasse wrote: > Hi javier > > did you sign the license agreement? and send it to me :)? > Then open an entry in the bug tracker and add you changes there. > > > Stef > > On Aug 15, 2009, at 2:28 AM, Javier PimÃ¡s wrote: > > >> Thanks everybody for the answers of last post. Finally I used the >> technique Mariano recommended because it was just what I wanted. >> >> Here I'm proposing a really small change to the class browser so >> that whenever a class or method is selected it's title is changed >> accordingly. The title produced is such that you can distinguish the >> browsers when looking at the taskbar (very usefull when you have >> many browsers opened). In case you like it, it would be nice to have >> it included in main pharo. >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> <ClassBrowserchange. >> 1.cs>_______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Aug. 16, 2009

Re: [Pharo-project] Create a changeset for an entire package?

by Michael Roberts

Monticello ? Mike On Friday, August 14, 2009, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > It seems fixing bugs is not the only hard part... I've a bunch of fixes for GLCanvas, and a small proposed change for the class browser but I can't find a way to export a diff of all the changed packages, nor a diff of an entire package nor a diff of a class so anybody can see the changes before commiting... Do I have to file out every class I changed? there has to some easier way. > > Thanks, > Â Â Â Â Â Â Â Â Â Â Javier. > -- > Javier PimÃ¡s > Ciudad de Buenos Aires >

Aug. 16, 2009