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

Re: [Pharo-project] [squeak-dev] Smalltalk at: #Foo - needs clarification

by Fernando olivero

On Oct 6, 2010, at 5:30 PM, Fernando olivero wrote: > > On Oct 6, 2010, at 4:36 PM, stephane ducasse wrote: > >> >> >>> Hello, >>> >>> just wanna ask, is this part of API will be deprecated in future? >>> (in Pharo, it put under 'to clean later' category). >>> >>> And if yes, then what will be correct (dialect-agnostic) way to access globals? >>> >>> Smalltalk globals at: #Foo ? >>> >>> I thought that #at: #at:put: (and some others) >>> historically is a part of Smalltalk protocol, and should stay there to >>> support legacy code and cross-dialect code. >>> >>> >>> What you thoughts about it? >> >> legacy you said! Let us move on. We keep to help people migrating. >> Now we should avoid it as much as possible even Smalltalk globals at:. It should be more >> self class environment at: >> >> In VisualWorks I'm not sure that Smalltalk at: make sense. > > I've been using: > > Smalltalk globals classNamed: aString. > > IMO It's better from a conceptual view because > 1. it breaks the class-symbol binding, > 2. and a Dictionary-like implementation for lookup. > > > Fernando

Oct. 6, 2010

Re: [Pharo-project] Tests broken with Citezen

by Alexandre Bergel

Yes, it works also for me. Thanks Cheers, Alexandre On 6 Oct 2010, at 11:03, StÃ©phane Ducasse wrote: > I just fixed the code. the test pass now. > Alex I could generate my web page with this version this summer so it should work. > > Stef > > On Oct 6, 2010, at 4:43 PM, Alexandre Bergel wrote: > >>> I'm loading it right now. >>> And the problem is that the default config load everything.... magritte grease seaside.... >>> 20 min at least. >> >> Yes... I was also surprised of this... >> >> Alexandre >> >> >>> >>> >>>> Hi! >>>> >>>> Citezen seems to not run on a 11414. >>>> CZEntry>>clean >>>> >>>> self class fieldKeysToRemove >>>> do: [:each | (self hasFieldWithKey: each) >>>> ifTrue: [self removeFieldWithKey: each]] >>>> >>>> There is no implementor of #fieldKeysToRemove >>>> >>>> I would like to use Citezen to generate the Research webpage on Pharo. >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 6, 2010

Re: [Pharo-project] Tests broken with Citezen

by StÃ©phane Ducasse

I just fixed the code. the test pass now. Alex I could generate my web page with this version this summer so it should work. Stef On Oct 6, 2010, at 4:43 PM, Alexandre Bergel wrote: >> I'm loading it right now. >> And the problem is that the default config load everything.... magritte grease seaside.... >> 20 min at least. > > Yes... I was also surprised of this... > > Alexandre > > >> >> >>> Hi! >>> >>> Citezen seems to not run on a 11414. >>> CZEntry>>clean >>> >>> self class fieldKeysToRemove >>> do: [:each | (self hasFieldWithKey: each) >>> ifTrue: [self removeFieldWithKey: each]] >>> >>> There is no implementor of #fieldKeysToRemove >>> >>> I would like to use Citezen to generate the Research webpage on Pharo. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2010

Re: [Pharo-project] Tests broken with Citezen

by Alexandre Bergel

> I'm loading it right now. > And the problem is that the default config load everything.... magritte grease seaside.... > 20 min at least. Yes... I was also surprised of this... Alexandre > > >> Hi! >> >> Citezen seems to not run on a 11414. >> CZEntry>>clean >> >> self class fieldKeysToRemove >> do: [:each | (self hasFieldWithKey: each) >> ifTrue: [self removeFieldWithKey: each]] >> >> There is no implementor of #fieldKeysToRemove >> >> I would like to use Citezen to generate the Research webpage on Pharo. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 6, 2010

[Pharo-project] TextConstants-related issues (3066 & 3067)

by NicolÃ¡s Paez

Issue 3066: Classes using TextConstants as a common Dictionary Issue 3067: TextConstants used in different ways Saludos! Nico. blog: nicopaez.wordpress.com

Oct. 6, 2010

Re: [Pharo-project] Tests broken with Citezen

by StÃ©phane Ducasse

I'm loading it right now. And the problem is that the default config load everything.... magritte grease seaside.... 20 min at least. Stef > Hi! > > Citezen seems to not run on a 11414. > CZEntry>>clean > > self class fieldKeysToRemove > do: [:each | (self hasFieldWithKey: each) > ifTrue: [self removeFieldWithKey: each]] > > There is no implementor of #fieldKeysToRemove > > I would like to use Citezen to generate the Research webpage on Pharo. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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

Oct. 6, 2010

Re: [Pharo-project] System Tracer

by StÃ©phane Ducasse

generate a new image. On Oct 6, 2010, at 2:23 PM, Alexandre Bergel wrote: > Hi! > > What do you want to achieve? > > Cheers, > Alexandre > > > On 6 Oct 2010, at 05:36, Gabriel HernÃ¡n Barbuto wrote: > >> Hi >> >> Does anyone know where I can find the system tracer that is currently >> in use in Pharo? >> >> Bests >> Gabriel >> >> _______________________________________________ >> 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

Oct. 6, 2010

Re: [Pharo-project] [squeak-dev] Cog+NativeBoost Linux32 binaries available

by Igor Stasenko

On 6 October 2010 16:54, Fernando olivero <fernando.olivero(a)usi.ch> wrote: > > On Oct 6, 2010, at 3:36 PM, Igor Stasenko wrote: > >> On 6 October 2010 16:31, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 6 October 2010 16:08, Fernando olivero <fernando.olivero(a)usi.ch> wrote: >>>> Ok, thanks for the info. >>>> >>>> Â i'm more than interested in the doing the MacOsX port of NBOpenGL. When i have the time ( not in the near future) i will produce a native boost mac vm deployable , plus the NBOpenGL-MacOsX. >>>> >>>> Regarding the window downloable, i followed the instructions in the page, the load order of packages but a certain class seems to be missing when i want to try the example ( the true type font example rendering ) in the NBOpenGL-Morphic package. >>>> >>> >>> Ohh.. i found that last one is saved as >>> NBOpenGL-Morphic-Igor.Stasenko.3fqa >>> >>> instead of >>> NBOpenGL-Morphic-Igor.Stasenko.3 >>> >>> don't ask me how.. looks like some MC bug. >>> >>> it is listed as a separate item in repository packages list .. crap >>> >>> Also, the missing class is NBGLCurveRenderer, which i moved to >>> NBOpenGL-Rome package. >>> I did a snapshot of it. But it depends on RomeCanvas class(es) , which >>> is part of Athens.. >>> But just ignore that for now and load it. For demo, you need only >>> NBGLCurveRenderer which not rely on any Rome-specific stuff. > > Just for curiosity, why this dependance on Rome? To end up providing a Canvas were all the rendering is performed by OpenGL and you text rendering class ? A NBGLCurveRenderer is actually an experiment, which should be a part of something bigger (read Rome). So, that's why i moved it there, breaking demo :) I plan to implement an OpenGL backend for canvas, which implements Rome protocol. And then implement Morphic which using rome-canvas for rendering.. And then implement brand-new zoomable UI in it.. (i have a big plans)... :) > >>> >>> It should be less messy.. But this is still under construction, so , >>> sorry for inconvenience :) >>> >> > No problem! It's a big project, and you are making an excellent job! > >> So, the load order is >> >> Core >> Win >> TrueType >> Display >> Rome >> Morphic.3fqa >> >> then you can run the: >> >> GLTTRenderingDemo new openInWorld >> >> (works for me) :) >> > > > Ok! Great! I wil try it. > > Maybe we could add some OpenGL rendering examples, some of them can be taken from AlienOpenGL examples, or other source. > I found it useful for documenting the usage to have a class called AlienOpenGLExamples, with examples as instance methods Â ( and also to validate that the rendering is ok). > Yes yes. Things needs to be properly organized. I just don't have much time to do that :) > > Fernando > > > _______________________________________________ > 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.

Oct. 6, 2010

[Pharo-project] Smalltalk at: #Foo - needs clarification

by Igor Stasenko

Hello, just wanna ask, is this part of API will be deprecated in future? (in Pharo, it put under 'to clean later' category). And if yes, then what will be correct (dialect-agnostic) way to access globals? Smalltalk globals at: #Foo ? I thought that #at: #at:put: (and some others) historically is a part of Smalltalk protocol, and should stay there to support legacy code and cross-dialect code. What you thoughts about it? -- Best regards, Igor Stasenko AKA sig.

Oct. 6, 2010

Re: [Pharo-project] [squeak-dev] Cog+NativeBoost Linux32 binaries available

by Fernando olivero

On Oct 6, 2010, at 3:36 PM, Igor Stasenko wrote: > On 6 October 2010 16:31, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 6 October 2010 16:08, Fernando olivero <fernando.olivero(a)usi.ch> wrote: >>> Ok, thanks for the info. >>> >>> i'm more than interested in the doing the MacOsX port of NBOpenGL. When i have the time ( not in the near future) i will produce a native boost mac vm deployable , plus the NBOpenGL-MacOsX. >>> >>> Regarding the window downloable, i followed the instructions in the page, the load order of packages but a certain class seems to be missing when i want to try the example ( the true type font example rendering ) in the NBOpenGL-Morphic package. >>> >> >> Ohh.. i found that last one is saved as >> NBOpenGL-Morphic-Igor.Stasenko.3fqa >> >> instead of >> NBOpenGL-Morphic-Igor.Stasenko.3 >> >> don't ask me how.. looks like some MC bug. >> >> it is listed as a separate item in repository packages list .. crap >> >> Also, the missing class is NBGLCurveRenderer, which i moved to >> NBOpenGL-Rome package. >> I did a snapshot of it. But it depends on RomeCanvas class(es) , which >> is part of Athens.. >> But just ignore that for now and load it. For demo, you need only >> NBGLCurveRenderer which not rely on any Rome-specific stuff. Just for curiosity, why this dependance on Rome? To end up providing a Canvas were all the rendering is performed by OpenGL and you text rendering class ? >> >> It should be less messy.. But this is still under construction, so , >> sorry for inconvenience :) >> > No problem! It's a big project, and you are making an excellent job! > So, the load order is > > Core > Win > TrueType > Display > Rome > Morphic.3fqa > > then you can run the: > > GLTTRenderingDemo new openInWorld > > (works for me) :) > Ok! Great! I wil try it. Maybe we could add some OpenGL rendering examples, some of them can be taken from AlienOpenGL examples, or other source. I found it useful for documenting the usage to have a class called AlienOpenGLExamples, with examples as instance methods ( and also to validate that the rendering is ok). Fernando

Oct. 6, 2010