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

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> > > > > > > > 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: is there a difference between Intel 64 bits and amd64 ? I mean, if you compile for one, you cannot use that binaries for the other ? > > > 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? Remember it has to be the latest VM code because of the closures. All of this would be REALLY nice. Pharo and Squeak support for Linux is poor. Can you take it ? ahaha I have Linux, but 32 bits ;) 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. 8, 2009

Re: [Pharo-project] preparing 1.1

by Mariano Martinez Peck

On Thu, Aug 6, 2009 at 8:21 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > There are also the following related wiki pages: > > http://code.google.com/p/pharo/wiki/Milestones > http://code.google.com/p/pharo/wiki/HaveALookAt > http://code.google.com/p/pharo/wiki/PlanToUse > http://code.google.com/p/pharo/wiki/ToDoBetterOnLongTerm > http://code.google.com/p/pharo/wiki/BetterMop > > (We should consolidate these pages.) I can do this task if no one else wants to. Perhaps during the weekend. Let me know if I can do it. Best, Mariano > > > If you have feature requests for 1.1, please post them here. > > Adrian > > On Aug 6, 2009, at 12:30 , StÃ©phane Ducasse 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 8, 2009

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

by StÃ©phane Ducasse

I do not know (and I'm too tired now to have an opinion). My goal is that if someone plays with Semaphore, mutex in a workspace that the results on the transcript still shows the reality of the thread switching. I will go to bed and think about it. ;) Stef On Aug 7, 2009, at 11:28 PM, Dale Henrichs wrote: > Stef, > > I'm not sure that concurrent use of the ThreadSafe Transcript is any > more or less dangerous from the foreground process than from > background process. > > I've experimented with a mod to ThreadSafeTranscript>>endEntry that > allows for both foreground and background updating of the > transcript. The following expression: > > | tt | > tt := (Smalltalk at: #Transcript). > "Background updates" > [1 to: 20 do: [:i | tt nextPutAll: '[', i printString, ']'; > nextPutAll: '*'; flush . > Processor yield ]. > tt flush ] fork. > "Background updates" > [100 to: 120 do: [:i | tt nextPutAll: '{', i printString, '}'; > nextPutAll: '-'; flush. > Processor yield ]. > tt flush ] fork. > "Foreground updates" > 200 to: 220 do: [:i | tt show: '---', i printString, '---'. > Processor yield ] > > produces this output in the transcript: > > ---200---[1]{100}*---201----[2]---202---*{101}----203--- > [3]*{102}---204----[4]*---205---{103}-[5]---206---*{104}----207--- > [6]*{105}---208----[7]*---209---{106}-[8]---210---*{107}----211--- > [9]*{108}---212----[10]*---213---{109}-[11]---214---*{110}----215--- > [12]*{111}---216----[13]*---217---{112}-[14]---218---*{113}----219--- > [15]*{114}---220----[16]*{115}-[17]*{116}-[18]*{117}-[19]*{118}- > [20]*{119}-{120}- > > I protected the #changed: message and the #displayWorldSafely with > the access semaphore so at a minimum concurrent transcript accesses > shouldn't be a problem. With this mod,the transcript updates when > called from a lone foreground process, too. > > If you want, I can can submit a bug along with the proposed > fix...Alternatively, I think I've probably got enough info to fix my > problem in isolation. > > Hmmm, perhaps WorldState needs a mutex to make #displayWorldSafely > truly safe? > > Dale > > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > | 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

[Pharo-project] [ANN] 10409 and 10410

by StÃ©phane Ducasse

10409 ------- - 1003 as of 10394, pharo beeps on every SystemWindow open/close NoSound fixed Polymorph widgets 71 I was planning to release the rest now but something fucked up :( So I cannot reload the package because of a strange syntax error..... Bad.... lost 2 hours. Stef 10410 ------- - Issue 936: Traits package not browseable in Monticello - Issue 1041: Performace - OrderedCollection asArray uses primitive fallback code | ordColl| ordColl := OrderedCollection with: (247@278 corner: 1013@682) with: (803@364 corner: 816@461) with: (295@282 corner: 803@476) with: (821@348 corner: 1000@476) with: (986@349 corner: 999@463) with: (822@463 corner: 986@476). Time millisecondsToRun: [50000 timesRepeat: [ordColl asArray.]] 100 ms 30 ms - Issue 1039: better Blinking Cursor - Issue 1050: CUIS chronology enh 0099-ChronologyEnh-jmv.1.cs 0226-DateAndTime-fromSeconds-dtl-M7356.cs

Aug. 7, 2009

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

by Ramiro Diaz Trepat

Gracias ! Indeed there is no problem with the 32 bit VMs in 64bit Linux... as long as you have the 32bit libraries installed. All laughing chocolate frogs now :) r. 2009/8/7 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > On Fri, Aug 7, 2009 at 2:54 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > >> ---------- Forwarded message ---------- >> From: David T. Lewis <lewis(a)mail.msen.com> >> Date: Fri, Aug 7, 2009 at 5:39 PM >> Subject: Re: [Vm-dev] Fwd: [Pharo-project] Compiling a Squeak VM for >> Pharo on Ubuntu 8.04 LTS Server (64bit) >> To: Squeak Virtual Machine Development Discussion >> <vm-dev(a)lists.squeakfoundation.org> >> >> >> >> On Fri, Aug 07, 2009 at 01:14:21PM +0200, Damien Cassou wrote: >> > >> > ---------- Forwarded message ---------- >> > From: Dave Woodward <dave(a)futuremint.com> >> > Date: Thu, Aug 6, 2009 at 7:10 PM >> > Subject: [Pharo-project] Compiling a Squeak VM for Pharo on Ubuntu >> > 8.04 LTS Server (64bit) >> > To: pharo-project(a)lists.gforge.inria.fr >> > >> > >> > I tried using the pre-compiled VM from the Pharo website to no avail. >> > I'm not exactly sure what the problem is, but when running the >> > pre-compiled Pharo VM, OR the pre-compiled Squeak 3.10-6 VM, they just >> > quit with a "File not found" error. ?My only hunch regarding this is >> > that they were compiled on 32bit Linuxes, and I'm using a 64bit Linux. >> >> A likely guess is that some 32-bit library needs to be installed on the >> Linux system in question. The Squeak 3.10-6 VM runs fine on my 64bit >> SuSE laptop. > > > yeah. Dave: could you please try: sudo apt-get install ia32-libs > > best, > > Mariano > > > >> >> >> > I'm using a bare-bones install of Ubuntu server, 8.04LTS 64bit. ?I'm >> > using Slicehost.com for a virtual server to run a Seaside application >> > (they use all 64bit *NIXs), and I'm switching from vanilla Squeak 3.9 >> > to Pharo. >> > >> > So, since the Squeak 3.10-6 VM didn't work either I decided to compile >> > my own VM. ?This does not work out of the box on a vanilla Ubuntu >> > Server 8.04 install, so here are the steps I took to successfully >> > compile the VM from the 3.10-6 src files: >> > >> > (cd /Squeak-3.10-6/platforms/unix) >> > >> > Configure: >> > ./config/configure --without-x --without-gl --without-quartz >> --without-npsqueak >> > >> > NOTE: The configure command adds 2 entries to disable the RomePlugin. >> > It looks like it first tests Freetype (not installed so adds an entry >> > to disable RomePlugin), and then tests Cairo (not installed, so adds >> > *another* entry to disable RomePlugin). ?I believe the autoconf files >> > need to be fixed for this, but I leave it up to the squeak-dev folks >> > to figure that out as I have no knowledge of autoconf. >> > >> > Make: >> > make squeak ?(this will error) >> > >> > To fix the damage from the note above, I had to remove the duplicate >> > entry for RomePlugin_exports on line 22 of disabledPlugins.c. >> >> Thats a problem of some sort in configure, but note also that RomePlugin >> will not work on 64-bit systems (Mantis 7344). >> >> Dave >> >> >> >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> 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

Stef, I'm not sure that concurrent use of the ThreadSafe Transcript is any more or less dangerous from the foreground process than from background process. I've experimented with a mod to ThreadSafeTranscript>>endEntry that allows for both foreground and background updating of the transcript. The following expression: | tt | tt := (Smalltalk at: #Transcript). "Background updates" [1 to: 20 do: [:i | tt nextPutAll: '[', i printString, ']'; nextPutAll: '*'; flush . Processor yield ]. tt flush ] fork. "Background updates" [100 to: 120 do: [:i | tt nextPutAll: '{', i printString, '}'; nextPutAll: '-'; flush. Processor yield ]. tt flush ] fork. "Foreground updates" 200 to: 220 do: [:i | tt show: '---', i printString, '---'. Processor yield ] produces this output in the transcript: ---200---[1]{100}*---201----[2]---202---*{101}----203---[3]*{102}---204----[4]*---205---{103}-[5]---206---*{104}----207---[6]*{105}---208----[7]*---209---{106}-[8]---210---*{107}----211---[9]*{108}---212----[10]*---213---{109}-[11]---214---*{110}----215---[12]*{111}---216----[13]*---217---{112}-[14]---218---*{113}----219---[15]*{114}---220----[16]*{115}-[17]*{116}-[18]*{117}-[19]*{118}-[20]*{119}-{120}- I protected the #changed: message and the #displayWorldSafely with the access semaphore so at a minimum concurrent transcript accesses shouldn't be a problem. With this mod,the transcript updates when called from a lone foreground process, too. If you want, I can can submit a bug along with the proposed fix...Alternatively, I think I've probably got enough info to fix my problem in isolation. Hmmm, perhaps WorldState needs a mutex to make #displayWorldSafely truly safe? Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | 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 characterswhen typingin 401

by Sebastian Sastre

it's happening less often when using monospace. UI feels kind of less loaded when typing on the default monospace. > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > nombre de Schwab,Wilhelm K > Enviado el: Friday, August 07, 2009 17:36 > Para: Pharo-project(a)lists.gforge.inria.fr > Asunto: Re: [Pharo-project] [ANN] issue 1048 missing > characterswhen typingin 401 > > Are you saying to stop using a mono-space font? I would not > have done that, as I like monospace fonts for code, and I > have seen this problem, so I doubt that's it, unless it > happens to increase the workload to render the text and > pushes your machine hard enough to make it fail. > > Speaking of failing, maybe the different font causes a > primitive to fail and backup code to run - thanks and > congrats to whoever posted that theory recently. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On > Behalf Of Sebastian Sastre > Sent: Friday, August 07, 2009 2:55 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [ANN] issue 1048 missing > characters when typingin 401 > > I can't be sure but try changing the default code font to > Deja Vu Sans. > Here looks like it started to happen after I've changed the > monospace for the sans. > sebastian > PD: this is a 401 on a win32 3.11.3 > > > -----Mensaje original----- > > De: pharo-project-bounces(a)lists.gforge.inria.fr > > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En nombre de > > Stephane Ducasse Enviado el: Friday, August 07, 2009 16:34 > > Para: Pharo-project(a)lists.gforge.inria.fr > > Asunto: Re: [Pharo-project] [ANN] issue 1048 missing > characters when > > typingin 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 > > > _______________________________________________ > 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 typingin 401

by Schwab,Wilhelm K

Are you saying to stop using a mono-space font? I would not have done that, as I like monospace fonts for code, and I have seen this problem, so I doubt that's it, unless it happens to increase the workload to render the text and pushes your machine hard enough to make it fail. Speaking of failing, maybe the different font causes a primitive to fail and backup code to run - thanks and congrats to whoever posted that theory recently. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sebastian Sastre Sent: Friday, August 07, 2009 2:55 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] issue 1048 missing characters when typingin 401 I can't be sure but try changing the default code font to Deja Vu Sans. Here looks like it started to happen after I've changed the monospace for the sans. sebastian PD: this is a 401 on a win32 3.11.3 > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En nombre de > Stephane Ducasse Enviado el: Friday, August 07, 2009 16:34 > Para: Pharo-project(a)lists.gforge.inria.fr > Asunto: Re: [Pharo-project] [ANN] issue 1048 missing characters when > typingin 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 _______________________________________________ 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 typingin 401

by Sebastian Sastre

I can't be sure but try changing the default code font to Deja Vu Sans. Here looks like it started to happen after I've changed the monospace for the sans. sebastian PD: this is a 401 on a win32 3.11.3 > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > nombre de Stephane Ducasse > Enviado el: Friday, August 07, 2009 16:34 > Para: Pharo-project(a)lists.gforge.inria.fr > Asunto: Re: [Pharo-project] [ANN] issue 1048 missing > characters when typingin 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

Yes but I do not have that around me :) Stef On Aug 7, 2009, at 9:40 PM, Schwab,Wilhelm K wrote: > 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 > > _______________________________________________ > 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