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

Re: [Pharo-project] [ANN] Updating a Pharo image is now possible

by stan shepherd

Hi, I get Error: can't find EOCD position, during load of 'System-Support-stephane_ducasse.28.mcz' eocdPosition = 0 Full walkback is attached. Cheers, ...Stan 2009/8/8 Damien Cassou <damien.cassou(a)gmail.com>: > Hi, > > just wanted to say that updating a Pharo image seems to work ok now. > I've removed the overrides in some packages. > > However, remember that the update mechanism only updates Core > packages, not packages listed in > http://code.google.com/p/pharo/wiki/Packages. This could be possible > but has not been done yet. What do you think about that? > > -- > 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 >

Aug. 8, 2009

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

by Dale Henrichs

Will do... Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | dale could you publish your code and open a BT entry so that a person | | with a better understanding of the implications than me | can comment on it? | 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. 8, 2009

Re: [Pharo-project] Missing characters when typing?

by Schwab,Wilhelm K

You might be on to something. Potentially accented characters (I'm no expert on languages, so I could be off a little) seem to drop most often or at least be near to the characters that do drop. Note that it is difficult to be precise about this. First, I can never know exactly what keys I hit, and second, I'm rushing to try to stress the event loop which probably increases my error rate. However, I'm a pretty fair typist, at least when the text is origininating in my head (I never transcribe for others, so I don't have that skill), and I know Pharo does drop characters, even if I can't tell you exsactly which ones. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Saturday, August 08, 2009 2:11 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Missing characters when typing? Hi all, seems not to be fixed: http://code.google.com/p/pharo/issues/detail?id=1048#c4 as additional info: does that happen only on Linux? does that only happen with potentially accented characters like e, a, u etc? There is some really ugly Linux specific code for handling composed characters which could be the source of the problems. If there are missing characters on other platforms too then the problem might be somewhere else. I'm not familiar with autocompletion (old fashioned using only bare bones images), so not sure what magic happens there potentially. Michael _______________________________________________ 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

[Pharo-project] Loading CUIS strike font

by StÃ©phane Ducasse

does one of you succeed to load the latest version of CUIS ? http://www.jvuletich.org/Squeak/Misc/ I got base64Decoded missing but I could not find it in CUIS 258 Stef

Aug. 8, 2009

Re: [Pharo-project] [ANN] Updating a Pharo image is now possible

by StÃ©phane Ducasse

good steps in the right direction. From an integration point of view I would like to enhance scriptloader to perform the steps I mentioned in the other emails. stef On Aug 8, 2009, at 12:18 PM, Damien Cassou wrote: > Hi, > > just wanted to say that updating a Pharo image seems to work ok now. > I've removed the overrides in some packages. > > However, remember that the update mechanism only updates Core > packages, not packages listed in > http://code.google.com/p/pharo/wiki/Packages. This could be possible > but has not been done yet. What do you think about that? > > -- > 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

Aug. 8, 2009

[Pharo-project] a process to maintain non core package

by StÃ©phane Ducasse

Hi in the future I would like to have a process like that to maintain package like sound (or morphic extras) or any package that are not core else we will not be able to maintain them or to apply package wide changes. - we mark the packages that are not in the image but that we want to maintain - at integration step we load all the external packages - integrate - publish in different repos Else I bet that we will not be able to maintain the non core packages. Stef PS: I'm integrating Issue 1051: Cuis 0053-ensure-close.1.cs and some changes touched sound so this is good experiment.

Aug. 8, 2009

[Pharo-project] [ANN] Updating a Pharo image is now possible

by Damien Cassou

Hi, just wanted to say that updating a Pharo image seems to work ok now. I've removed the overrides in some packages. However, remember that the update mechanism only updates Core packages, not packages listed in http://code.google.com/p/pharo/wiki/Packages. This could be possible but has not been done yet. What do you think about that? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 8, 2009

[Pharo-project] Fwd: [squeak-dev] Trunk now Toolbuilderized ;-)

by StÃ©phane Ducasse

Begin forwarded message: > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: August 8, 2009 9:46:34 AM CEDT > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Subject: [squeak-dev] Trunk now Toolbuilderized ;-) > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > Folks - > > Just as an FYI, I did a serious pass on toolbuildering (or would > that be toolbuilderizing? ;-) the Tools package in the trunk. In the > process I've removed some tons of stuff from the Tools package > referencing half of MVC and Morphic and replaced them with using > ToolBuilder specs consistently. > > Since that was a sizable change there is a chance for some fallout > and I'd appreciate feedback if you find something that got broken in > the process. One difference I'm aware about is that I (temporarily) > removed the "always visible comment pane" in the browser. I just > haven't figured out how to deal with it using ToolBuilder - if > anyone has an idea I'm all ears. Everything else should work, > including Inspector, Debugger, PackagePaneBrowser, etc. > > The good news is that this is both, progress towards unloading MVC > as well as making some tools available to MVC which previously were > either not at all or only partially available. So all in all, I > consider it a good trade. > > Cheers, > - Andreas >

Aug. 8, 2009

[Pharo-project] [ANN] 10410

by StÃ©phane Ducasse

> 10410 > ------- > - 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. 8, 2009

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

by Damien Cassou

2009/8/7 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Damien:Â can we edit once again the readme file and put this? Done in the new release VM: 0.15.2d -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 8, 2009