September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] PharoKernel #12121

by Adrian Lienhard

On Sep 3, 2010, at 15:03 , Pavel Krivanek wrote: > 2010/9/3 Denis Kudriashov <dionisiydk(a)gmail.com>: >> Could you explain why Text is not part of ui system? And why it should be in >> kernel? > > In fact some time ago I had a headless image without Text but it > needed a lot of modifications. Pharo can use text formatting for the > source codes. That is the main reason why Text should be in the > kernel. oh, shouldn't we better remove the text formatting in source code feature? I assume almost nobody uses it and it is more annoying than helpful (e.g., if I copy code from a mail, I never want to style my code). Adrian > > -- Pavel > >> 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 >> >> >> _______________________________________________ >> 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] PharoKernel #12121

by Pavel Krivanek

2010/9/3 Denis Kudriashov <dionisiydk(a)gmail.com>: > Could you explain why Text is not part of ui system? And why it should be in > kernel? In fact some time ago I had a headless image without Text but it needed a lot of modifications. Pharo can use text formatting for the source codes. That is the main reason why Text should be in the kernel. -- Pavel > 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 > > > _______________________________________________ > 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] [squeak-dev] Re: Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by Alexandre Bergel

>>> In the version I used, MONode>displayOn: did do culling, no such luck for MOEdge though. >> MOEdge does not do the culling since an edge can be visible without having its two extremity visible. Edges are indeed a problem. Having very non-embedded and very long edges costs a lot. > Unless edges can be curved, a simple rect-rect intersection would be quite sufficient for eliminating lots of edges, at least in the zoomed in scenario. It makes sense. Currently, all the non-embedded edges are displayed. However, if the window is not between the two extremity, then there is no point in drawing the edge. Something that I should implement. I added a google entry for this: http://code.google.com/p/moose-technology/issues/detail?id=450 > What I meant was, even if you do culling at the object level, you're still iterating over the entire model deciding what should be rendered every displayOn: call (if only just to perform an isVisible: check). Yes > What you really need (in _addition_ to the current graph-model, which works great for reporting damage rects etc when manipulating the model), is f.ex. a quad-tree structure based on the physical location of the objects, which can be used for culling during the rendering phase. Yes, we have been talking about QuadTree recently. It would be great to have them in Mondrian. However, QuadTree will work well for rendering the nodes. One problem that prevent scalability, is the layout computation. It easily take a lot of time. > That, and, I just realized, drawing each visible object once. ;) > If I'm not wrong (haven't tested it) the elementsToDisplay is created using allSubNodes/EdgesDo: , so what happens in the cases where displayOn: is called to one of the visible subnodes, which also has visible subnodes? A subnode is removed from elementsToDisplay if its parent is displayed and uses a bitmap cache (in #updateOwner). Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 3, 2010

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