- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] 10409 and 10410
by StÃ©phane Ducasse Aug. 8, 2009

Aug. 8, 2009

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

1 1

Re: [Pharo-project] Fwd: [Vm-dev] Fwd: Compiling a Squeak VM, for Pharo on Ubuntu 8.04 LTS Server (64bit)
by Dave Woodward Aug. 8, 2009

Aug. 8, 2009

Date: Fri, 7 Aug 2009 16:07:43 -0100 From: Mariano Martinez Peck <marianopeck(a)gmail.com> Subject: Re: [Pharo-project] Fwd: [Vm-dev] Fwd: Compiling a Squeak VM for Pharo on Ubuntu 8.04 LTS Server (64bit) To: Pharo-project(a)lists.gforge.inria.fr Message-ID: <a38fadc50908071007h211e13fdp820f8c95394714c(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" 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 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. > > > >> > > 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 Dave Woodward ................................................... www.futuremint.com 317.332.6438 | dave(a)futuremint.com

4 7

[Pharo-project] [BUG] source ?
by StÃ©phane Ducasse Aug. 8, 2009

Aug. 8, 2009

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.

1 0

[Pharo-project] seasideHelper on pharo
by Miguel Enrique CobÃ¡ Martinez Aug. 8, 2009

Aug. 8, 2009

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

2 2

Re: [Pharo-project] Subtle behavior changes in UI threads for Pharo?
by Dale Henrichs Aug. 7, 2009

Aug. 7, 2009

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.

3 2

[Pharo-project] Subtle behavior changes in UI threads for Pharo?
by Dale Henrichs Aug. 7, 2009

Aug. 7, 2009

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

2 1

[Pharo-project] Enhanced StrikeFonts (antiAliasing , subPixel AA)
by StÃ©phane Ducasse Aug. 7, 2009

Aug. 7, 2009

From: Juan Vuletich <juan <at> jvuletich.org> Subject: [Ann] Enhanced StrikeFonts (antiAliasing , subPixel AA) Newsgroups: gmane.comp.lang.smalltalk.squeak.general Date: 2009-08-03 21:52:47 GMT (20 hours and 12 minutes ago) Hi Folks, If you update to the latest trunk, you'll load Graphics-jmv.53, Morphic-jmv.138 and System-jmv.118. This is the support for anti aliased StrikeFonts from Cuis. The new 'BitmapDejaVu' font of point size 9 is set as default. I only included size 9 (reg, italic, bold, bold italic) to avoid using too much space in the image. If people want, more sizes can be added. To do proper antialiasing / subpixel AA _without_ requiring new BitBlt modes, I use RGBMul BitBlt rule, and a second pass with RGBAdd rule. Text looks very good, in any combination of font and background colors, even at lower Display depths and / or glyphs depths. By default underscore and caret are shown as in standard ASCII. If you prefer the classic ST-80 left and up arrow, evaluate 'StrikeFont useLeftArrow'. To go back to the default, evaluate 'StrikeFont useUnderscore'. I also added 2 preferences #subPixelRenderFonts and #subPixelRenderColorFonts (both default to true). Andreas, thanks for all your help! Comments are welcome. Cheers, Juan Vuletich

5 11

[Pharo-project] Default Background
by Torsten Bergmann Aug. 7, 2009

Aug. 7, 2009

I dislike the white background in the default Pharo distribution. On the other hand a real wallpaper would blow up the image too much. So here is a small compromise (pattern background) that is easy to put into the update stream and looks good with most of the polymorph themes: -------------------------------------------------------------------- |colors form| colors := Array new:256 withAll: #(0.0 0.0 0.0). colors at: 1 put: #(0.329 0.329 0.329); at: 2 put: #(0.204 0.204 0.204); at: 3 put: #(0.267 0.267 0.267). form := ((ColorForm extent: 1@10 depth: 8 fromArray: #( 16777216 0 33554432 33554432 33554432 33554432 33554432 33554432 33554432 33554432) offset: 0@0) colorsFromArray: colors). World color: (InfiniteForm with: form) -------------------------------------------------------------------- Have fun and keep on talking small Bye Torsten [1] -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

6 5

[Pharo-project] WAKom and Seaside 2.9
by Robert Sirois Aug. 7, 2009

Aug. 7, 2009

Was Seaside 2.9 intended to be used with Pharo beta 1? WAKom still doesn't work with that version. RS _________________________________________________________________ Express your personality in color! Preview and select themes for HotmailÂ®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=PID23391…

4 4

Re: [Pharo-project] WAKom and Seaside 2.9
by Robert Sirois Aug. 7, 2009

Aug. 7, 2009

Thank you, Torsten's method seems to have solved my problem. I had a Seaside 2.9 changeset I just dropped in there and tried to use WAKom like in a Squeak image. Silly question I'm sure, but what is the difference between the two web servers? The callbacks? Thanks! RS _________________________________________________________________ Get back to school stuff for them and cashback for you. http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_Back…

1 0