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

Re: [Pharo-project] preparing 1.1

by StÃ©phane Ducasse

Pavel got a 2.4 mb kernel image based on pharo!!!! But this is not public yet. Now we will do as much as we can and as much as people help to do :) Stef On Aug 7, 2009, at 4:23 PM, Lukas Renggli wrote: >> I would like to add the process of creation of some kind of the UI- >> less kernel image and overall approximation to the KernelImage >> modularization. > > +100 (i love the 3.9 based morphic kernel images) > > >> >> Cheers, >> -- Pavel >> >> On Thu, Aug 6, 2009 at 12:30 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >> > wrote: >> Hi guys >> >> we would like also to get a list of items for 1.1 >> >> http://code.google.com/p/pharo/wiki/IdeasToImplement >> >> >> â¢ MethodReference? and CompiledMethod? >> â¢ Clean category / comments (some package are totally wrong) >> â¢ First class packages >> â¢ Files: Cleaning file/directory (Gnu + rio rewrite) >> â¢ Streams >> â¢ Remove projects and other >> â¢ Clean ImageSegments? >> â¢ MethodReference?/CompiledMethod? >> â¢ NewCompiler? >> â¢ Better browser >> â¢ Cleaning Morphic (better integration of Polymorph) >> â¢ Rome and other Sophie library >> â¢ Preferences using pragmas >> â¢ Checking CUIS enhancement >> â¢ Checking Squeak enhancement >> â¢ Enhancement Strike Fonts >> â¢ underscore in selector >> - test server >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 7, 2009

Re: [Pharo-project] Subtle behavior changes in UI threads for Pharo?

by StÃ©phane Ducasse

I m not really satisfied of what I did but I think that this is important to have a thread safe transcript. Now I have the impression that the Morphic concurrency model could really be rethought. I'm not good enough with process and the rest but I got so burnt by it (I had to cancel work made by nathanael for the botsinc environment to have animation in BotsInc because they worked on PC but blocked the UI on mac). On Aug 7, 2009, at 9:06 PM, Dale Henrichs wrote: > Igor, > > I appreciate what you are saying and in the fullness of time, we may > be able to do more things with background processes. > > However, we _are_ running a development environment for GemStone > that should appear to the user to be no different than the Pharo > development environment ... i.e., when you evaluate the following > expression in Pharo or The GemTools client: > > 10 timesRepeat: [ (Delay forSeconds: 1) wait ] > > you would expect the UI process to be blocked for the duration of > execution. This is why I _block_ the UI process during execution. > > If you have a long running process running in the foreground > (whether or not it is running on GemStone) you expect to be able to > interrupt the process and bring up a debugger on the interrupted > process. In order to do that with the GemTools client, we have to > use a non-blocking C call, so that the GemTools client can recognize > the interrupt and take appropriate action. This is why we are using > a non-blocking call. > > With that said, something subtle _has_ changed in the way that the > Pharo UI processes updates windows ... In earlier versions of Pharo, > the Transcript window (whether or not it was thread-safe) updated > without any special effort on my part, with the 1.0 beta, the > transcript window is not updating. I've tried both thread safe and > non-thread safe Transcripts and it doesn't appear to matter. > > While poking around, I have discovered that the transcript is not > updated until the process finishes in Pharo either. So the following > expression "misbehaves" whether executed in GemStone or Pharo: > > 10 timesRepeat: [ > (Delay forSeconds: 1) wait. > Transcript cr; show: 'hi' ] > > I guess I _expect_ the display to be updated whether or not I am > running a process in the foreground. > > If I insert a 'World displayWorldSafely' into the loop then the > transcript is updated 'correctly': > > 10 timesRepeat: [ > (Delay forSeconds: 1) wait. > Transcript cr; show: 'hi'. > World displayWorldSafely ] > > Is this expected behavior and the correct solution to my problem? > > Dale > ----- "Igor Stasenko" <siguctua(a)gmail.com> wrote: > > | 2009/8/7 Dale Henrichs <dale.henrichs(a)gemstone.com>: > | > I'm trying to characterize some differences in behavior for > GemTools > | between Squeak and the 1.0beta for Pharo. I'm not reporting a bug as > | much as trying to understand what I need to do differently in Pharo. > | > > | > In GemTools, I have a special workspace (GemTools Launcher), that > | causes doits to be evaluated in a GemStone server. This is done by > | using FFI to make calls to the GemStone GCI library. > | > > | > The string is passed to GemStone via a nonblocking C call. On the > | Pharo (client) side, we poll for a result. While an expression is > | evaluating, exceptions may be raised on the server-side and on the > | client, we convert the gemstone exception into a Pharo exception and > | signal it, if/when the exception is resumed, we pass a result back > to > | the server and continue waiting for the result of the original > | expression. > | > > | > There are two thing that might happen when a exception is raised > in > | this manner. If the exception is an error, we bring up a debugger > | window on the client and arrange to debug the process on the server > | (again using the GCI). If the exception is what we call a Client > | Forwarder exception, then we arrange to send a message to the client > | object and pass the result back to the server side. Using a client > | forwarder, the server can send messages to the client Transcript > with > | logging/progress messages. > | > > | > In earlier versions of Pharo and in the current version of Squeak, > | when we sent messages to the Transcript, the messages would show up > | immediately ... making it easy to watch progress of long running > | operations. > | > > | > In the 1.0 beta Pharo, this behavior has changed. It appears that > | the Transcript window is not updated until the polling process > | finishes, which makes the progress messages a little bit less than > | useful. > | > > | > I assume that I need to add a message to my polling loop to allow > | for display updates...I'm doing a Delay wait in the loop so the > | process is not in a tight loop. > | > > | > I am not running the poll in the background, because I want the UI > | process to be blocked ... this same mechanism is used for menu > items, > | etc. so blocking is important. > | > > | > Thanks for the help, > | > | Dale, the key problem of this is that 'wait loop' blocks the UI > | process. I know, it is simplest way to prevent user from doing > | anything while system is busy but its not very friendly, especially > | when you need to perform a remote processing which requires a > | substantional amount of time to complete. > | But, i wonder, what is the point in using a non-blocking calls to > | communicate with GemStone, when in the end its still blocks > | everything > | (from user's point of view) ? :) > | > | Stef did a good job making a Transcript thread-safe in Pharo, so it > | can be used by any process (not only UI one) safely. > | But this implies that you should not block the UI thread to give > it a > | chance to update the screen. In case if nothing blocks the process, > | the transcript window will be updated each 20ms or so (World update > | cycle), and such delay, i think will be hardly noticeable by users. > | Transcript is a stream , which updated immediately once you putting > | something to it, but there are no guarantees that any other objects > | (like window , which is displaying its contents) should be updated > | immediately as well. > | > | I am encouraging you to create a background process , which talks > | with > | GemStone, and then UI process just schedule user actions to it. This > | will make UI process non-blocking, but of course, requires > additional > | efforts, like disabling the user from doing anything while waiting > | response from G/S. But this could be done nicely, and user could go > | to > | any other window/menu etc, and do things there while G/S processing > | the actions. Which i think makes UI much more friendly. > | > | > | > > | > Dale > | > > | > _______________________________________________ > | > 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. 7, 2009

Re: [Pharo-project] [ANN] issue 1048 missing characters when typing in 401

by Schwab,Wilhelm K

Stef, I think it helps to have a slightly slow machine, and maybe to run Linux and to do so on a wide screen monitor??? 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: Friday, August 07, 2009 2:34 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] issue 1048 missing characters when typing in 401 can you let us know how to reproduce it (image, vm os) + steps because I code all the day in pharo and I do not have that problem. Stef > Hi guys, > ok I'm totally annoyed by this one. > I can't type two lines straight. > The most typed key on my keyboard right now is f* backspace with love > :) sebastian > > > _______________________________________________ > 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. 7, 2009

Re: [Pharo-project] [ANN] issue 1048 missing characters when typing in 401

by StÃ©phane Ducasse

can you let us know how to reproduce it (image, vm os) + steps because I code all the day in pharo and I do not have that problem. Stef > Hi guys, > ok I'm totally annoyed by this one. > I can't type two lines straight. > The most typed key on my keyboard right now is f* backspace > with love :) > sebastian > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 7, 2009

Re: [Pharo-project] Subtle behavior changes in UI threads for Pharo?

by Igor Stasenko

2009/8/7 Dale Henrichs <dale.henrichs(a)gemstone.com>: > Igor, > > I appreciate what you are saying and in the fullness of time, we may be able to do more things with background processes. > Sure :) > However, we _are_ running a development environment for GemStone that should appear to the user to be no different than the Pharo development environment ... i.e., when you evaluate the following expression in Pharo or The GemTools client: > > Â 10 timesRepeat: [ (Delay forSeconds: 1) wait ] > > you would expect the UI process to be blocked for the duration of execution. This is why I _block_ the UI process during execution. yes it is blocked, since this expression runs in the UI process itself and therefore it can't handle any user input before quitting it. > > If you have a long running process running in the foreground (whether or not it is running on GemStone) you expect to be able to interrupt the process and bring up a debugger on the interrupted process. In order to do that with the GemTools client, we have to use a non-blocking C call, so that the GemTools client can recognize the interrupt and take appropriate action. This is why we are using a non-blocking call. Sure. I'm using interrupt key time to time. But if you wouldn't block the UI process, you can, instead, let user click on 'interrupt' or 'cancel' button. Isn't that more consistent approach, than letting user to wonder cluelessly, what is happening and why UI not responding? :) > > With that said, something subtle _has_ changed in the way that the Pharo UI processes updates windows ... In earlier versions of Pharo, the Transcript window (whether or not it was thread-safe) updated without any special effort on my part, with the 1.0 beta, the transcript window is not updating. I've tried both thread safe and non-thread safe Transcripts and it doesn't appear to matter. > > While poking around, I have discovered that the transcript is not updated until the process finishes in Pharo either. So the following expression "misbehaves" whether executed in GemStone or Pharo: > > Â 10 timesRepeat: [ > Â Â (Delay forSeconds: 1) wait. > Â Â Transcript cr; show: 'hi' ] > > I guess I _expect_ the display to be updated whether or not I am running a process in the foreground. > then you need to explicitly put the code which can do 'update', as you doing below. > If I insert a 'World displayWorldSafely' into the loop then the transcript is updated 'correctly': > > Â 10 timesRepeat: [ > Â Â (Delay forSeconds: 1) wait. > Â Â Transcript cr; show: 'hi'. > Â Â World displayWorldSafely ] > My guess that maybe 'World doOneCycle' be more appropriate? > Is this expected behavior and the correct solution to my problem? > Seems so. And this is makes your code non-thread safe, since it could run safely only in the UI process. [snip] Btw, going beyond the topic, i thought that in future, its maybe worth to think about creating a special 'watchdog' which watching that each world cycle is no longer than 1 sec. If its longer than that (like when UI blocked by some lengthly process), then watchdog spawns a new UI process and revokes the old UI process from being that one. Then things like: 10 timesRepeat: [ (Delay forSeconds: 1) wait ] will eventually start running in background, always giving the user be able interact with UI, despite anything what could happen with current UI process. This seems a brute-force approach, but consider it as my personal POV: blocked UI stinks :) -- Best regards, Igor Stasenko AKA sig.

Aug. 7, 2009

Re: [Pharo-project] Fwd: [Vm-dev] Fwd: Compiling a Squeak VM, for Pharo on Ubuntu 8.04 LTS Server (64bit)

by Miguel Enrique CobÃ¡ Martinez

> > > Mariano, I installed the ia32-libs package, and now the binary > works > great! Perhaps there should be a short sentence mentioning > this in the > Readme file? I suppose I should have known since I was on a > 64bit > linux... but... I didn't! Thanks again for everyone's help. > > Excellent!!! Greate news. > > Damien: can we edit once again the readme file and put this? Perhaps > SOMETHING as this: > > " > For 64 bits you have two options: > * Compile the VM by yourself > * Install 32-libs package from you OS. For example, in Ubuntu you can > execute 'sudo apt-get install ia32-libs' > " > > Anyone has a better message? In my Debian GNU/Linux 5 (lenny) amd64 I always used the squeak vm installed from the Debian repos. That vm was already for 64 bits (I didn't had ia32-libs installed) and everything worked ok. Maybe another option would be to ask JosÃ© Luis Redrejo to rebuild a vm for amd64 and: 1. upload it to debian/ubuntu repos to cover the users that use that OSes, they only had to download an image and not the vm. 2. upload it to the squeak and pharo sites and put a link to download a vm for x86 and other for amd64. 3. Generate two zips, one for ia32 and other for amd64 and the user selects the correct one. 4. put the message that you propose in the zip as a fallback. What do you think?

Aug. 7, 2009

Re: [Pharo-project] Fwd: [Vm-dev] Fwd: Compiling a Squeak VM, for Pharo on Ubuntu 8.04 LTS Server (64bit)

by Mariano Martinez Peck

2009/8/7 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El vie, 07-08-2009 a las 14:10 -0400, Dave Woodward escribiÃ³: > > > > > > > yeah. Dave: could you please try: sudo apt-get install ia32-libs > > > > best, > > > > Mariano > > > > > > > > > > Mariano, I installed the ia32-libs package, and now the binary works > > great! Perhaps there should be a short sentence mentioning this in the > > Readme file? I suppose I should have known since I was on a 64bit > > linux... but... I didn't! Thanks again for everyone's help. > > Congrats for that improvement but now you have a image that runs ok but > is isolated from the internet. The network isn't working on 64 bit > architecture, even with ia32-libs. > > check: > http://code.google.com/p/pharo/issues/detail?id=794 > http://code.google.com/p/pharo/issues/detail?id=961 > Yes, but, those bugs are fixed if you compile the VM ? I image they don't. So, it doesn't matter if it is with ia32-lib or if you compiled, they won't work. However perhaps would be nice to have a place where to put the known problems with 64 bits. FFI doesn't work well with 64 neither. Best, Mariano > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 7, 2009

Re: [Pharo-project] Fwd: [Vm-dev] Fwd: Compiling a Squeak VM, for Pharo on Ubuntu 8.04 LTS Server (64bit)

by Miguel Enrique CobÃ¡ Martinez

El vie, 07-08-2009 a las 14:10 -0400, Dave Woodward escribiÃ³: > > > yeah. Dave: could you please try: sudo apt-get install ia32-libs > > best, > > Mariano > > > > > Mariano, I installed the ia32-libs package, and now the binary works > great! Perhaps there should be a short sentence mentioning this in the > Readme file? I suppose I should have known since I was on a 64bit > linux... but... I didn't! Thanks again for everyone's help. Congrats for that improvement but now you have a image that runs ok but is isolated from the internet. The network isn't working on 64 bit architecture, even with ia32-libs. check: http://code.google.com/p/pharo/issues/detail?id=794 http://code.google.com/p/pharo/issues/detail?id=961

Aug. 7, 2009

Re: [Pharo-project] file dialog

by Schwab,Wilhelm K

Gary, Some time ago, you mentioned having made some progress on printing. Is that something you can make available? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Friday, August 07, 2009 9:24 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] file dialog I'll add some then :-) Printing, unfortunately, is another common feature that is not really supported. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, August 07, 2009 3:18 PM Subject: Re: [Pharo-project] file dialog Yes and we would integrate fast any steps in that direction. Stef On Aug 7, 2009, at 11:25 AM, Gary Chambers wrote: > Unfortunately, the current protocol of UIManager is rather limited. > Would be good to flesh out properly with colour choosers, font > choosers etc. > > For the moment your best bet is: > > UITheme builder fileSave: 'Your title here' > > which returns a new empty file stream or nil if cancelled. > There are other variants, see TEasilyThemed for others. > > Regards, Gary > > ----- Original Message ----- > From: "Tudor Girba" <girba(a)iam.unibe.ch> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, August 05, 2009 10:36 AM > Subject: Re: [Pharo-project] file dialog > > > Hi again, > > On the same topic, what is the invocation to open a dialogue that > allows for saving files? > > Cheers, > Doru > > > On 5 Aug 2009, at 10:26, Tudor Girba wrote: > >> Thanks Mariano, >> >> The following code works: >> >> UIManager default >> chooseFileMatching: #('mse') >> label: 'Import model from MSE file.'. >> >> The problem is indeed that you have to pass a valid set of >> extensions, >> so * is not allowed. Anyway, it works for the moment but perhaps it >> should be changed to: >> >> FileDialogWindow>>validExtensions: aList >> "Set the filter for the files to be those with the given >> extensions." >> >> aList notEmpty >> ifTrue: [self defaultExtension: aList first]. >> self fileSelectionBlock: [:de | >> de isDirectory >> ifTrue: [self showDirectoriesInFileList] >> ifFalse: [(self fileNamePattern match: de name) and: [ >> aList contains: [:each | each match: >> (FileDirectory extensionFor: >> de name asLowercase) ] ]]] >> >> On the other hand the fileNamePattern seems to already have the job >> of >> filtering, so I do not really understand why we need aList. >> >> Cheers, >> Doru >> >> On 5 Aug 2009, at 09:39, StÃ©phane Ducasse wrote: >> >>> if you have a fix tag it 1.0 ;) >>> >>> Stef >>> >>> On Aug 5, 2009, at 12:56 AM, Mariano Martinez Peck wrote: >>> >>>> >>>> >>>> On Tue, Aug 4, 2009 at 7:32 PM, Tudor Girba <girba(a)iam.unibe.ch> >>>> wrote: >>>> Hi, >>>> >>>> I need to load a file from the disk. >>>> >>>> I am invoking: >>>> UIManager default >>>> chooseFileMatching: '*.mse' >>>> label: 'Import model from MSE file.'. >>>> >>>> The problem is that I do not see any files, even though I have >>>> files >>>> with .mse ending in the directory. Also, even if I pass '*.*' I >>>> still >>>> cannot see the files (only the directories). >>>> >>>> Could anyone tell me what I am doing wrong? >>>> >>>> I could reproduce it and debugging I noticed that >>>> >>>> FileDialogWindow>>validExtensions: aList >>>> "Set the filter for the files to be those with the given >>>> extensions." >>>> >>>> aList notEmpty >>>> ifTrue: [self defaultExtension: aList first]. >>>> self fileSelectionBlock: [:de | >>>> de isDirectory >>>> ifTrue: [self showDirectoriesInFileList] >>>> ifFalse: [(self fileNamePattern match: de name) and: [ >>>> aList includes: (FileDirectory extensionFor: >>>> de name asLowercase)]]] >>>> >>>> >>>> I think there can be a problem with this method. Here, aList will >>>> be >>>> '*.*' and as you can imagine that string doesn't includes any of >>>> the >>>> extensions. Perhaps we can change that include for a match: or >>>> something like that. To see this, remove the line >>>> aList includes: (FileDirectory extensionFor: de name asLowercase >>>> >>>> and you will see that now all the files are shown. >>>> >>>> we should open a ticket but I don't know if this should be 1.0 tag >>>> >>>> best, >>>> >>>> Mariano >>>> >>>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Next time you see your life passing by, say 'hi' and get to know >>>> her." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> www.tudorgirba.com >> >> "What is more important: To be happy, or to make happy?" >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > www.tudorgirba.com > > "Some battles are better lost than fought." > > > > > _______________________________________________ > 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 7, 2009

Re: [Pharo-project] Subtle behavior changes in UI threads for Pharo?

by Dale Henrichs

Igor, I appreciate what you are saying and in the fullness of time, we may be able to do more things with background processes. However, we _are_ running a development environment for GemStone that should appear to the user to be no different than the Pharo development environment ... i.e., when you evaluate the following expression in Pharo or The GemTools client: 10 timesRepeat: [ (Delay forSeconds: 1) wait ] you would expect the UI process to be blocked for the duration of execution. This is why I _block_ the UI process during execution. If you have a long running process running in the foreground (whether or not it is running on GemStone) you expect to be able to interrupt the process and bring up a debugger on the interrupted process. In order to do that with the GemTools client, we have to use a non-blocking C call, so that the GemTools client can recognize the interrupt and take appropriate action. This is why we are using a non-blocking call. With that said, something subtle _has_ changed in the way that the Pharo UI processes updates windows ... In earlier versions of Pharo, the Transcript window (whether or not it was thread-safe) updated without any special effort on my part, with the 1.0 beta, the transcript window is not updating. I've tried both thread safe and non-thread safe Transcripts and it doesn't appear to matter. While poking around, I have discovered that the transcript is not updated until the process finishes in Pharo either. So the following expression "misbehaves" whether executed in GemStone or Pharo: 10 timesRepeat: [ (Delay forSeconds: 1) wait. Transcript cr; show: 'hi' ] I guess I _expect_ the display to be updated whether or not I am running a process in the foreground. If I insert a 'World displayWorldSafely' into the loop then the transcript is updated 'correctly': 10 timesRepeat: [ (Delay forSeconds: 1) wait. Transcript cr; show: 'hi'. World displayWorldSafely ] Is this expected behavior and the correct solution to my problem? Dale ----- "Igor Stasenko" <siguctua(a)gmail.com> wrote: | 2009/8/7 Dale Henrichs <dale.henrichs(a)gemstone.com>: | > I'm trying to characterize some differences in behavior for GemTools | between Squeak and the 1.0beta for Pharo. I'm not reporting a bug as | much as trying to understand what I need to do differently in Pharo. | > | > In GemTools, I have a special workspace (GemTools Launcher), that | causes doits to be evaluated in a GemStone server. This is done by | using FFI to make calls to the GemStone GCI library. | > | > The string is passed to GemStone via a nonblocking C call. On the | Pharo (client) side, we poll for a result. While an expression is | evaluating, exceptions may be raised on the server-side and on the | client, we convert the gemstone exception into a Pharo exception and | signal it, if/when the exception is resumed, we pass a result back to | the server and continue waiting for the result of the original | expression. | > | > There are two thing that might happen when a exception is raised in | this manner. If the exception is an error, we bring up a debugger | window on the client and arrange to debug the process on the server | (again using the GCI). If the exception is what we call a Client | Forwarder exception, then we arrange to send a message to the client | object and pass the result back to the server side. Using a client | forwarder, the server can send messages to the client Transcript with | logging/progress messages. | > | > In earlier versions of Pharo and in the current version of Squeak, | when we sent messages to the Transcript, the messages would show up | immediately ... making it easy to watch progress of long running | operations. | > | > In the 1.0 beta Pharo, this behavior has changed. It appears that | the Transcript window is not updated until the polling process | finishes, which makes the progress messages a little bit less than | useful. | > | > I assume that I need to add a message to my polling loop to allow | for display updates...I'm doing a Delay wait in the loop so the | process is not in a tight loop. | > | > I am not running the poll in the background, because I want the UI | process to be blocked ... this same mechanism is used for menu items, | etc. so blocking is important. | > | > Thanks for the help, | | Dale, the key problem of this is that 'wait loop' blocks the UI | process. I know, it is simplest way to prevent user from doing | anything while system is busy but its not very friendly, especially | when you need to perform a remote processing which requires a | substantional amount of time to complete. | But, i wonder, what is the point in using a non-blocking calls to | communicate with GemStone, when in the end its still blocks | everything | (from user's point of view) ? :) | | Stef did a good job making a Transcript thread-safe in Pharo, so it | can be used by any process (not only UI one) safely. | But this implies that you should not block the UI thread to give it a | chance to update the screen. In case if nothing blocks the process, | the transcript window will be updated each 20ms or so (World update | cycle), and such delay, i think will be hardly noticeable by users. | Transcript is a stream , which updated immediately once you putting | something to it, but there are no guarantees that any other objects | (like window , which is displaying its contents) should be updated | immediately as well. | | I am encouraging you to create a background process , which talks | with | GemStone, and then UI process just schedule user actions to it. This | will make UI process non-blocking, but of course, requires additional | efforts, like disabling the user from doing anything while waiting | response from G/S. But this could be done nicely, and user could go | to | any other window/menu etc, and do things there while G/S processing | the actions. Which i think makes UI much more friendly. | | | > | > Dale | > | > _______________________________________________ | > 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. 7, 2009