- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Object visitor

by Mariano Martinez Peck

Hi Martin, a couple of questions: - What you want to do with each obejct? I mean, you want to traverse the graph...ok, but to do what? - Do you want to do it at VM or image side? Is speed important? But as Alexandre said, you can take a look to ReferenceStream or ImageSegment. In VM side you can see the GC stuff for example. Cheers Mariano 2010/9/2 Martin Dias <tinchodias(a)gmail.com> > 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 >

Sept. 3, 2010

Re: [Pharo-project] PharoKernel #12121

by Miguel Enrique CobÃ¡ MartÃnez

El vie, 03-09-2010 a las 15:24 +0200, Adrian Lienhard escribiÃ³: > 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). +1 It can be added as an external packege for development images later. > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 3, 2010

Re: [Pharo-project] PharoKernel #12121

by StÃ©phane Ducasse

I sent an email on this topics a while ago if I remember correctly but I got not real feedback. We can always add another layer later to do hypertext navigation but not on the source code. >>> 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? > > Yes, this complicates everything and is not used anywhere. > > Lukas > > -- > 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] PharoKernel #12121

by StÃ©phane Ducasse

> <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. :) I think that we should go slowly. The tool that nicolas is building will help us on that because we can browse dependencies and mark them as blacklisted He will start to push on us things to fix. Jannik also asked to use DSM on the complete Pharo image and to qualify dependencies. I have 800 references to qualify and I started to write log now I will open tickets. Stef

Sept. 3, 2010

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

by StÃ©phane Ducasse

indeed may be we should do that http://code.google.com/p/pharo/issues/detail?id=2907 On Sep 3, 2010, at 2:46 PM, Henrik Johansen wrote: > 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 > > > _______________________________________________ > 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] FSPlatformResolver class>>forCurrentPlatform use a deprecated method

by Cyrille Delaunay

Yes, I naively repeated what was telling me the 'deprecated' message :) But indeed, use 'Smalltalk platformName' seems to work fine. 2010/9/3 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > 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 > > > _______________________________________________ > 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 Lukas Renggli

>> 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? Yes, this complicates everything and is not used anywhere. Lukas -- Lukas Renggli www.lukas-renggli.ch

Sept. 3, 2010

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