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

Re: [Pharo-project] preparing 1.1

by Adrian Lienhard

Mariano, That would be great. Please go ahead! Adrian On Aug 8, 2009, at 02:00 , Mariano Martinez Peck wrote: > 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 >> > _______________________________________________ > 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] [BUG] source ?

by StÃ©phane Ducasse

when I integrated http://code.google.com/p/pharo/issues/detail?id=936 save then load the trait package testPrinting | composition1 composition2 | composition1 := ((self t1 - { #a } + self t2) @ { (#z -> #c) } - { #b. #c } + self t3 - { #d. #e } + self t4) @ { (#x -> #a). (#y -> #b) }. composition2 := self t4 @ { (#x -> #a). (#y -> #b) } + self t1 - { #a } + self t3 - { #d. #e } + self t2 - { #b. #c }. self assertPrints: composition1 printString like: 'T1 - {#a} + T2 @ {#z->#c} - {#b. #c} + T3 - {#d. #e} + T4 @ {#x->#a. #y->#b}'. self assertPrints: composition2 printString like: 'T4 @ {#x->#a. #y->#b} + T1 - {#a} + T3 - {#d. #e} + T2 - {#b. #c}' get cut as testPrinting | composition1 composition2 | composition1 := ((self t1 - { #a } right parenthesis expected -> Not fun.

Aug. 8, 2009

Re: [Pharo-project] file dialog

by StÃ©phane Ducasse

with the fallback solution you mentioned it would be great. Stef On Aug 8, 2009, at 3:19 AM, John M McIntosh wrote: > In Sophie we built out the native file dialog handlers for Windows and > macintosh. > Someone might want to harvest them? > > People *like* working with the native platform file choosers/pickers. > > Extensive use of FFI tho, but a fall back to squeak like file dialogs > if we found > the platform didn't support the native ones. > > > On 7-Aug-09, at 7:18 AM, StÃ©phane Ducasse wrote: > >> 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 > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > 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

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

[Pharo-project] Missing characters when typing?

by Michael Rueger

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

Aug. 8, 2009

Re: [Pharo-project] file dialog

by John M McIntosh

In Sophie we built out the native file dialog handlers for Windows and macintosh. Someone might want to harvest them? People *like* working with the native platform file choosers/pickers. Extensive use of FFI tho, but a fall back to squeak like file dialogs if we found the platform didn't support the native ones. On 7-Aug-09, at 7:18 AM, StÃ©phane Ducasse wrote: > 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 -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Aug. 8, 2009

Re: [Pharo-project] seasideHelper on pharo

by Miguel Enrique CobÃ¡ Martinez

El sÃ¡b, 08-08-2009 a las 01:58 +0100, Keith Hodges escribiÃ³: > All the repositories are open if you want to fix things. I wont be > fixing things myself in the near future due to other commitments and my > general disillusion. > > I suggest that you put your findings as to what is needed to make things > work where into Sake/Packages. Ok, will investigate. I wish that that feeling pass soon, as we as community really need your effort and coding abilities. > > Keith

Aug. 8, 2009

Re: [Pharo-project] seasideHelper on pharo

by Keith Hodges

Miguel Enrique CobÃ¡ Martinez wrote: > Hi Keith, > > I think you're subscribed to this list. If not, maybe someone know. > > I am trying to load seaside helper on an pharo core 10408 image. > > First I installed Seaside (after loading its dependencies) with: > > Installer ss > project: 'Seaside'; > answer: '.*username.*' with: 'admin'; > answer: '.*password.*' with: 'seaside'; > install: 'Seaside2.8a1'. > > This installed (accord to monticello browser) Seaside2.8a1-pmm.593. > This version worked ok and I could navigate the examples without > problem. > > Now I installed seasideHelper from the squeak universe : > > Installer universe > answer:'username' with:'admin'; > answer:'password' with:'seaside'; > install: 'Magma seasideHelper'. > > but according to the messages shown, seasideHelper has its problems with > pharo. I got some errors because of argument assignment but were solved > with: > > Preferences disable: #allowBlockArgumentAssignment > > During install it shows an error for class > > MagmaPreferences > > not existing in the image. It is part of Magma client as I can see from > a squeak image I have. I abandon the debugger message and retry. The > message doesn't appear again, but the class is not found. > > At the end the version of of seaside is: > > Seaside2.8a1-lr.591. and WAKom don't start because of BlockClosure > #newProcessWithBindings don't exists anymore. > > Well, I am trying to digg in the code but I want to know if anyone has a > version that works in pharo or if it is planned to have support for > pharo and for seaside versions that include suppor for the new closure > vm? > > Thanks for your answers > All the repositories are open if you want to fix things. I wont be fixing things myself in the near future due to other commitments and my general disillusion. I suggest that you put your findings as to what is needed to make things work where into Sake/Packages. Keith

Aug. 8, 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

> > > 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 ? > No, they are the same. The same vm can run on intel and amd cpus in 64 bit mode.

Aug. 8, 2009

[Pharo-project] seasideHelper on pharo

by Miguel Enrique CobÃ¡ Martinez

Hi Keith, I think you're subscribed to this list. If not, maybe someone know. I am trying to load seaside helper on an pharo core 10408 image. First I installed Seaside (after loading its dependencies) with: Installer ss project: 'Seaside'; answer: '.*username.*' with: 'admin'; answer: '.*password.*' with: 'seaside'; install: 'Seaside2.8a1'. This installed (accord to monticello browser) Seaside2.8a1-pmm.593. This version worked ok and I could navigate the examples without problem. Now I installed seasideHelper from the squeak universe : Installer universe answer:'username' with:'admin'; answer:'password' with:'seaside'; install: 'Magma seasideHelper'. but according to the messages shown, seasideHelper has its problems with pharo. I got some errors because of argument assignment but were solved with: Preferences disable: #allowBlockArgumentAssignment During install it shows an error for class MagmaPreferences not existing in the image. It is part of Magma client as I can see from a squeak image I have. I abandon the debugger message and retry. The message doesn't appear again, but the class is not found. At the end the version of of seaside is: Seaside2.8a1-lr.591. and WAKom don't start because of BlockClosure #newProcessWithBindings don't exists anymore. Well, I am trying to digg in the code but I want to know if anyone has a version that works in pharo or if it is planned to have support for pharo and for seaside versions that include suppor for the new closure vm? Thanks for your answers

Aug. 8, 2009