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

On Fri, Aug 7, 2009 at 5:10 PM, Dave Woodward <dave(a)futuremint.com> wrote: > > > 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. > 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? Cheers, 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 > > Dave Woodward > ................................................... > www.futuremint.com > 317.332.6438 | dave(a)futuremint.com > > _______________________________________________ > 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] issue 1048 missing characters when typing in 401

by Sebastian Sastre

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

Aug. 7, 2009

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

by Igor Stasenko

2009/8/7 Dale Henrichs <dale.henrichs(a)gemstone.com>: > I'm trying to characterize some differences in behavior for GemTools between Squeak and the 1.0beta for Pharo. I'm not reporting a bug as much as trying to understand what I need to do differently in Pharo. > > In GemTools, I have a special workspace (GemTools Launcher), that causes doits to be evaluated in a GemStone server. This is done by using FFI to make calls to the GemStone GCI library. > > The string is passed to GemStone via a nonblocking C call. On the Pharo (client) side, we poll for a result. While an expression is evaluating, exceptions may be raised on the server-side and on the client, we convert the gemstone exception into a Pharo exception and signal it, if/when the exception is resumed, we pass a result back to the server and continue waiting for the result of the original expression. > > There are two thing that might happen when a exception is raised in this manner. If the exception is an error, we bring up a debugger window on the client and arrange to debug the process on the server (again using the GCI). If the exception is what we call a Client Forwarder exception, then we arrange to send a message to the client object and pass the result back to the server side. Using a client forwarder, the server can send messages to the client Transcript with logging/progress messages. > > In earlier versions of Pharo and in the current version of Squeak, when we sent messages to the Transcript, the messages would show up immediately ... making it easy to watch progress of long running operations. > > In the 1.0 beta Pharo, this behavior has changed. It appears that the Transcript window is not updated until the polling process finishes, which makes the progress messages a little bit less than useful. > > I assume that I need to add a message to my polling loop to allow for display updates...I'm doing a Delay wait in the loop so the process is not in a tight loop. > > I am not running the poll in the background, because I want the UI process to be blocked ... this same mechanism is used for menu items, etc. so blocking is important. > > Thanks for the help, Dale, the key problem of this is that 'wait loop' blocks the UI process. I know, it is simplest way to prevent user from doing anything while system is busy but its not very friendly, especially when you need to perform a remote processing which requires a substantional amount of time to complete. But, i wonder, what is the point in using a non-blocking calls to communicate with GemStone, when in the end its still blocks everything (from user's point of view) ? :) Stef did a good job making a Transcript thread-safe in Pharo, so it can be used by any process (not only UI one) safely. But this implies that you should not block the UI thread to give it a chance to update the screen. In case if nothing blocks the process, the transcript window will be updated each 20ms or so (World update cycle), and such delay, i think will be hardly noticeable by users. Transcript is a stream , which updated immediately once you putting something to it, but there are no guarantees that any other objects (like window , which is displaying its contents) should be updated immediately as well. I am encouraging you to create a background process , which talks with GemStone, and then UI process just schedule user actions to it. This will make UI process non-blocking, but of course, requires additional efforts, like disabling the user from doing anything while waiting response from G/S. But this could be done nicely, and user could go to any other window/menu etc, and do things there while G/S processing the actions. Which i think makes UI much more friendly. > > Dale > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 7, 2009

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

by Dave Woodward

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

Aug. 7, 2009

Re: [Pharo-project] Enhanced StrikeFonts (antiAliasing , subPixel AA)

by Henrik Johansen

On Aug 7, 2009, at 8:22 12AM, StÃ©phane Ducasse wrote: > Thanks thanks thanks. Henrik this is cool that we get such an > analysis. Do you have an idea of the memory usage too :) > > Stef > > On Aug 6, 2009, at 4:24 PM, Henrik Johansen wrote: Without a memory allocation profiler, anything becomes a(n educated, at best) guess. Mine would be the glyph cache lookup code, where 95% of the "rendering" time is spent. For _each_ character rendered a loopup is made in a 3-layer dictionary to find the glyph: 1. By font - hashed by font size, so if f.ex you're using 2 fonts of size9, you're practically guaranteed collisions... 2. By character code. - 99% of the time, this will be in ascii range, might be a good idea to use a special class with array access for values 32-255, and a dict lookup just for the rest 3 By color/subpixel-position... - Character widths are also stored here. (but color/subpixel position make up 98% of these lookups) - Hashed by color value + subPixelPosition << 32, so you're always doing LargeInteger comparisions for lookups. Yay. - The color value calculation goes red << 24 + green << 16 + blue << 8 + alpha, so does 4 LargeInt additions instead of 3 SmallInteger adds and 1 LargeInt. Yay. Also, every time a cached glyphs is accesed, it is pushed to top of a LinkedList, the only thing I can see this LinkedList currently used for, is easy access to all the CacheItem instances when removing them all... The idea was probably to sometimes just remove the least used ones, but that's currently not done, as far as I can see. So in conclusion, the cache strategy in FreeType could benefit from a major rethinking :) Cheers, Henry

Aug. 7, 2009

Re: [Pharo-project] Default Background

by Lukas Renggli

> No. A white background with a touch of the brand is an excellent idea. Is clean > yet cosistent. > Nothing is better for fresh starts than a clean piece of white paper. > I've found right the make smaller the logo. Now is more balanced. > Please keep the default clean. > For who don't like it there is always the chance to set any other background. +1 on each of the points made Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Aug. 7, 2009

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

by Dale Henrichs

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

Aug. 7, 2009

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

by Mariano Martinez Peck

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 >

Aug. 7, 2009

Re: [Pharo-project] Default Background

by Sebastian Sastre

No. A white background with a touch of the brand is an excellent idea. Is clean yet cosistent. Nothing is better for fresh starts than a clean piece of white paper. I've found right the make smaller the logo. Now is more balanced. Please keep the default clean. For who don't like it there is always the chance to set any other background. sebastian > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > nombre de Torsten Bergmann > Enviado el: Thursday, August 06, 2009 11:21 > Para: pharo-project(a)lists.gforge.inria.fr > Asunto: [Pharo-project] Default Background > > 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 > > _______________________________________________ > 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] WAKom and Seaside 2.9

by Philippe Marschall

Schwab,Wilhelm K wrote: > My understanding is the WAKom is on the way out - they are creating "adpators" or something like that, and have a new way of controlling them. That's true, we try to have a uniform interface for all kinds of servers (Kom, Swazoo, ...). There will be two main "interfaces" a graphical server manager and the WAServerManager class. Cheers Philippe

Aug. 7, 2009