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

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b7

by Ken G. Brown

Did a quick try of a fresh Squeak4.2-10382-alpha on your latest 5.8b7, MacPro OS X 10.6.4, NVIDIA GeForce 7300 GT graphics card Resizing the Squeak window still results in graphic artifacts that go away when stopped resizing. Tried 'Update Squeak', got 'Error: unmatched string quote' in scanner while processing update.nice.150.mcm and snapshotting methods. Open Monticello Browser from World menu. +Repository select HTTP, Accept. click 'Open', with http://www.squeaksource.com/ selected. Get 'Error: Could not access http://www.squeaksource.com/' http://www.squeaksource.com/ is accessible from Safari. Ken G. Brown At 6:25 PM -0700 9/2/10, John M McIntosh wrote: >Content-Type: multipart/signed; boundary=Apple-Mail-121-227271873; > protocol="application/pkcs7-signature"; micalg=sha1 > >I've stuck a version (5.8b7) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. >Please ensure drawing looks sane, and how it interacts with the mouse and keyboard seems viable. > >http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b7.app.zip > >I finished the open/GL tuning and based on benchmarking I simplified the explicit flush required when a >Smalltalk Morphic draw cycle fails to do a flush. Lastly I cross check the source code to ensure it compiles >correctly for the iOS platform. > >-- >=========================================================================== >John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >=========================================================================== > > > > > >Attachment converted: MacProHD0:smime 764.p7s ( / ) (079FC4B2)

Sept. 3, 2010

Re: [Pharo-project] [OSProcess] Proposal for Pharo 1.2 compatibility

by David T. Lewis

On Fri, Sep 03, 2010 at 01:03:31PM +0200, Cyrille Delaunay wrote: > Hello, > > I would suggest to replace the two methods > -------------------------------------------------------------- > OSPRocess class >> platformName > "After Squeak version 3.6, #platformName was moved to SmalltalkImage " > > ^ ((Smalltalk classNamed: 'SmalltalkImage') > ifNil: [^ Smalltalk platformName]) current platformName > > OSPRocess class >> osVersion > "After Squeak version 3.6, #osVersion was moved to SmalltalkImage " > > ^ ((Smalltalk classNamed: 'SmalltalkImage') > ifNil: [^ Smalltalk osVersion]) current osVersion > > -------------------------------------------------------------- > by: > ------------------------------------------------------------- > OSProcess class >> platformName > ^ ((Smalltalk classNamed: 'OSPlatform') > ifNil: [ > (Smalltalk classNamed: 'SmalltalkImage') current > ifNil: [^ Smalltalk platformName]]) platformName > > OSProcess class >> osVersion > ^ ((Smalltalk classNamed: 'OSPlatform') > ifNil: [ > (Smalltalk classNamed: 'SmalltalkImage') current > ifNil: [^ Smalltalk osVersion]]) osVersion > ------------------------------------------------------------ > > to avoid deprecation messages when using it in Pharo 1.2. Does it looks > good? I'm not able to publish on the squeaksource repository This failed on the first Pharo image that I tried, which was a Pharo-1.1-11400-rc2dev10.06.1 image. I think this is the subject of some recent refactoring, so I'm not sure if it's safe to use it yet (will somebody try to load OSProcess in one of the images that has OSPlatform but that does not yet have the #platformName refactoring?). I expect that there are several versions of Pharo in general circulation, so can someone give me some guidance as to whether it is safe to code for "OSPlatform current platformName" as the expected idiom on Pharo, or should we wait a while and live with the deprecation warnings? Thanks, Dave

Sept. 3, 2010

Re: [Pharo-project] PharoKernel #12121

by Adrian Lienhard

I added a ticket: http://code.google.com/p/pharo/issues/detail?id=2908 Cheers, Adrian On Sep 3, 2010, at 17:20 , Miguel Enrique CobÃ¡ MartÃnez wrote: > 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 > > > _______________________________________________ > 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 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