- Pharo-dev - lists.pharo.org

Re: [Pharo-project] PharoKernel #12121

by Denis Kudriashov

Could you explain why Text is not part of ui system? And why it should be in kernel? 2010/9/3 Pavel Krivanek <pavel.krivanek(a)gmail.com> > On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants > <george.herolyants(a)gmail.com> wrote: > > 2010/9/3 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >> It is headless image. You have to use start-up scripts. See the file > >> "build_image.sh". > > > > So, why do you need this one: > > > >> - Fonts need some refactorings. Some sort of AbstractFont only with > >> capabilities required only by Text class should be part of the kernel. > > > > Because we need Text in the kernel and this class has ugly > dependencies on fonts. But this class does need only basic information > about used fonts like name, size etc. It is not the only problematic > part of the Text class. For example it is dependent on URLs. > > -- Pavel > > > ? > > > > _______________________________________________ > > 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 >

Sept. 3, 2010

Re: [Pharo-project] Single instance executables

by Schwab,Wilhelm K

Stef, I took that as agreement and created 2906. I don't know how to make it happen, but am certainly available for testing on Linux. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Friday, September 03, 2010 3:30 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Single instance executables ;) Stef On Sep 2, 2010, at 11:59 PM, Henrik Sperre Johansen wrote: > On 02.09.2010 21:45, Schwab,Wilhelm K wrote: >> Hello all, >> >> I realize that I hold an unpopular position on this, but it *will* come back to haunt us: we need to have a way to warn the user if a second copy of Pharo is launched. Random meltdowns and lost work will result from the current behavior. Let me be more bold: lost work and random corrrupted images *are resulting* from the current behavior; they are either unrecognized, or simply ignored, but it is happening. >> >> Is there a way to fix it? On Windows, I recall creating an OS semaphore with a given name and if that exists, bail out before the session even gets going. We would need a cross-platform way to do that (or at least a Linux/Mac way to do it - Windows has a mechanism), and then a place to abort startup early enough to prevent problems. Any ideas? >> >> Bill > On Windows, it will give you an error that it was unable to open the changes file when you open the second image. > > Cheers, > Henry > > PS. I think Steph agrees, given his experience with updates that mysteriously contain seemingly random bits of other methods' source code :) > > _______________________________________________ > 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

Sept. 3, 2010

[Pharo-project] FSPlatformResolver class>>forCurrentPlatform use a deprecated method

by Torsten Bergmann

Lukas wrote: >Why? OSPlatform doesn't even exist in Pharo 1.1. Pharo includes this class in Pharo-1.1-11411 Bye T. -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 fÃ¼r nur 19,99 €/mtl.!* http://portal.gmx.net/de/go/dsl

Sept. 3, 2010

Re: [Pharo-project] FSPlatformResolver class>>forCurrentPlatform use a deprecated method

by Henrik Johansen

A better choice might be Smalltalk os platformName, which works on Pharo 1.1, 1.2, Squeak 4.1 and 4.2. (well, as soon as it's properly undeprecated in 1.2 at least, #platform should be removed instead...) Cheers, Henry On Sep 3, 2010, at 2:30 23PM, Lukas Renggli wrote: > Why? OSPlatform doesn't even exist in Pharo 1.1. > > Lukas > > 2010/9/3 Cyrille Delaunay <cy.delaunay(a)gmail.com>: >> In the package Filesystem, >> FSPlatformResolver class >> forCurrentPlatform >> | platformName | >> platformName := SmalltalkImage current platformName. >> ^ (self allSubclasses detect: [:ea | ea platformName = platformName]) new >> should be replaced by >> FSPlatformResolver class >> forCurrentPlatform >> | platformName | >> platformName := OSPlatform platformName. >> ^ (self allSubclasses detect: [:ea | ea platformName = platformName]) new >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 3, 2010

Re: [Pharo-project] Object visitor

by Alexandre Bergel

The Pharo image already provides some infrastructure: SmartRefStream, ImageSegment and friends. Maybe Mariano could provide an extended answer... Cheers, Alexandre On 3 Sep 2010, at 03:54, Martin Dias wrote: > > > On Thu, Sep 2, 2010 at 4:53 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Yes. > Visitor is a convenient pattern to perform a computation over each element of a recursive data structure. > This pattern works well for trees. You need to pay attention to cycle when using it on a graph. This might be expensive if you have a large graph and you use a set to keep track of the element you run over. > > > It has to be as faster as possible, but I think that the Set would be ok. > > > > Do you want to do this on any object of the image? > > > Yes, for any object. It's for serializing a graph of objects into a stream. We need to iterate over the transitive closure of object references. > > Do you know an existing package that implements this pattern? > > > > > Alexandre > > > > Thank you for the answer > Martin > > > > On 2 Sep 2010, at 10:36, Martin Dias wrote: > > > Hi, > > > > We want to do some processing over the graph of object references. > > > > Do you recommend an implementation of visitor pattern to iterate object instance variables? > > > > Best regards, > > Martin and Tristan > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 3, 2010

Re: [Pharo-project] FSPlatformResolver class>>forCurrentPlatform use a deprecated method

by Lukas Renggli

Why? OSPlatform doesn't even exist in Pharo 1.1. Lukas 2010/9/3 Cyrille Delaunay <cy.delaunay(a)gmail.com>: > In the package Filesystem, > FSPlatformResolver class >> forCurrentPlatform > | platformName | > platformName := Â SmalltalkImage current platformName. > ^ (self allSubclasses detect: [:ea | ea platformName = platformName]) new > should be replaced by > FSPlatformResolver class >> forCurrentPlatform > | platformName | > platformName := Â OSPlatform platformName. > ^ (self allSubclasses detect: [:ea | ea platformName = platformName]) new > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Sept. 3, 2010

Re: [Pharo-project] PharoKernel #12121

by Pavel Krivanek

On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants <george.herolyants(a)gmail.com> wrote: > 2010/9/3 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> It is headless image. You have to use start-up scripts. See the file >> "build_image.sh". > > So, why do you need this one: > >> - Fonts need some refactorings. Some sort of AbstractFont only with >> capabilities required only by Text class should be part of the kernel. > Because we need Text in the kernel and this class has ugly dependencies on fonts. But this class does need only basic information about used fonts like name, size etc. It is not the only problematic part of the Text class. For example it is dependent on URLs. -- Pavel > ? > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 3, 2010

[Pharo-project] FSPlatformResolver class>>forCurrentPlatform use a deprecated method

by Cyrille Delaunay

In the package Filesystem, FSPlatformResolver class >> forCurrentPlatform | platformName | platformName := SmalltalkImage current platformName. ^ (self allSubclasses detect: [:ea | ea platformName = platformName]) new should be replaced by FSPlatformResolver class >> forCurrentPlatform | platformName | platformName := OSPlatform platformName. ^ (self allSubclasses detect: [:ea | ea platformName = platformName]) new

Sept. 3, 2010

Re: [Pharo-project] PharoKernel #12121

by George Herolyants

2010/9/3 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > It is headless image. You have to use start-up scripts. See the file > "build_image.sh". So, why do you need this one: > - Fonts need some refactorings. Some sort of AbstractFont only with > capabilities required only by Text class should be part of the kernel. ?

Sept. 3, 2010

[Pharo-project] [update 1.2] #12122

by StÃ©phane Ducasse

12122 ----- - 2904 HelpSystemAPIBuilderFailsOnTraits. Thanks Laurent Laffont. Stef and Gabriel

Sept. 3, 2010