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

Re: [Pharo-project] ClassTestCase

by StÃ©phane Ducasse

Lukas what would be good is to have a specific pharo smallLint that we could run to check. My brain is too small for all these details. Stef On May 24, 2010, at 6:18 PM, Lukas Renggli wrote: >> For now the list of levente and a slow machine >> >> "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." >> is the one to use > > Please read my comments on the issue tracker. > > For *any practical* example it doesn't matter what to use speed wise: > > 1 = nil ifTrue: [ ] > 2 == nil ifTrue: [ ] > 3 isNil ifTrue: [ ] > 4 ifNil: [ ] > > Personally I find 3 the most readable. 1 and 3 are the only practical > ones if you use OODBs, because they are not shortcut by the compiler. > > I only use 4 for lazy initializers, it makes a good pattern. The use > of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable > if you don't care about compatibility with other Smalltalk dialects. > > 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

May 24, 2010

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by StÃ©phane Ducasse

Guess what is my choice :) >>>> > Yes. But i want to stress, what meaning we are putting into 'API'. the real one :) > > API is protocols, not classes. > So, a code which renders something using API, should use only messages > sent to a canvas object. > The difference could be illustrated by following: > > a) > drawOn: aCanvas > > path := RomePath new. > path moveTo: .. lineTo:... close. > aCanvas strokePath: path > > b) > drawOn: aCanvas > > path := aCanvas newPath. > path moveTo: .. lineTo:... close. > aCanvas strokePath: path > > In case a) you are introducing a dependency on a concrete path > implementation(RomePath). > in case b) you asking a canvas to provide a path instance, which > conforms to a path protocol. > > Here lies the main difference, which either gives you a freedom of > choice, or otherwise makes your code inflexible. > That's what i mean by no dependecy. I understood it :) > In case b), a rendering backend is > free to use own data structures > to optimally reify a path(s), while in case a) you forcing a canvas to > have an intimate knowledge about RomePath > - a concrete implementation, which may not fit best for canvas and > hence it will waste cycles converting a path > representation into more appropriate form, in order to render it. > > That's why, if we follow path b), then morphic rendering could be > completely autonomous, > and do not depend on concrete Rome API implementation. > And enforcing it from a very starting, will make sure that we won't > introduce unnecessary > dependencies and inflexibility. so this is why it would be good to have a concrete scenario to stress and validate the Athens new canvas I would really like to see how the one of Morphic 30 will fit into it too. So let us start like that: - design your API with flexibility in mind + ROME from the point of you of Canvas method - give feedback about athens inflexibility - we update it - we iterate the goal should be that at the end we can get really fast a different back-end. With a bit of chance we will d the same with Morphic30 and we will have a cool system. Stef

May 24, 2010

Re: [Pharo-project] [squeak-dev] Need someone to test if NBOpenGL works for you on win32

by Igor Stasenko

On 24 May 2010 19:21, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi Igor, > > I'm testing your work in Win32. Following instructions in this page > http://code.google.com/p/nativeboost/wiki/Installation when evaluating > > NBInstaller install > > in PharoCore1.1ALPHA #11368 I receive: "You need to enable an > underscore selectors in preferences first". I see no preference listed > in the preferences browsers and didn't found the > #allowUnderscoreSelectors for enabling this setting. Any idea? > Strange. Here the piece of code, which tests that underscores supported: [ Compiler evaluate: '| t_a | ' ] on: Error do: [:ex | self inform: 'You need to enable an underscore selectors in preferences first' . ^ self ]. It works fine in pharocore-11367, and actually this message was mainly for squeak/trunk where you can control the underscore by preference. In Pharo it should work out of the box. > Cheers, > > HernÃ¡n > > 2010/5/24 Igor Stasenko <siguctua(a)gmail.com>: >> Hi, >> >> i just snapshotted my stuff with various fixes, to make it load >> cleanly on pharo and squeak images. >> >> I'd like you to ask to test and load it and tell me if it works for you. >> >> Currently it works only on win32 platform. It could work on Linux, but >> i didn't had time to port it yet. >> >> There is no automatic installation procedure right now, so here what >> you should try: >> >> - first, you need to have VM with NativeBoost plugin + NativeBoost >> loaded into an image >> (see http://code.google.com/p/nativeboost/wiki/Installation for instructions) >> >> >> - then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL >> in following order: >> >> - NBOpenGL-Core >> - NBOpenGL-Win >> - NBOpenGL-TrueType >> - NBOpenGL-Display >> - NBOpenGL-Morphic >> >> i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were >> released recently, >> and it seems works ok. >> on squeak/trunk it should also work without problems. >> >> Now, if everything went right, then we're ready to run a demo: >> >> GLViewportMorph new "useOwnForm: true;" openInWorld >> >> This thing should render a TrueType glyphs and animating a smooth zoom of it. >> Nothing fancy, i just wanna know, if it works for you (and how well). Â :) >> >> As you may know, GPU/OpenGL implementations vary depending on vendor >> and how old your hardware is, >> and i don't have all of it at my disposal. >> >> Ok.. if you got it running, and it renders the glyphs.. there's one thing left: >> Â - save your image and quit (without closing this morph) >> Â - start image >> >> it should continue working as if nothing happens. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > _______________________________________________ > 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.

May 24, 2010

Re: [Pharo-project] Cannot add halos to selected morph in 1.1 #11368

by HernÃ¡n Morales Durand

Thanks, I was very used to the right click :) HernÃ¡n 2010/5/24 Lukas Renggli <renggli(a)gmail.com>: > Alt+Shift+Click displays the halos on that particular morph on my system. > > Lukas > > On 24 May 2010 19:01, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >> If you evaluate >> >> BorderedMorph new borderColor: Color red; borderWidth: 10; openInWorld. >> >> in PharoCore1.1ALPHA #11368 in Win32 and if you want to add halos to >> this morph to remove it easily, the halos are added to the world >> PasteUpMorph and you would need to figure a way to remove it >> programatically. >> Cheers, >> >> HernÃ¡n >> >> _______________________________________________ >> 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 >

May 24, 2010

Re: [Pharo-project] Cannot add halos to selected morph in 1.1 #11368

by Lukas Renggli

Alt+Shift+Click displays the halos on that particular morph on my system. Lukas On 24 May 2010 19:01, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > If you evaluate > > BorderedMorph new borderColor: Color red; borderWidth: 10; openInWorld. > > in PharoCore1.1ALPHA #11368 in Win32 and if you want to add halos to > this morph to remove it easily, the halos are added to the world > PasteUpMorph and you would need to figure a way to remove it > programatically. > Cheers, > > HernÃ¡n > > _______________________________________________ > 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

May 24, 2010

[Pharo-project] Cannot add halos to selected morph in 1.1 #11368

by HernÃ¡n Morales Durand

If you evaluate BorderedMorph new borderColor: Color red; borderWidth: 10; openInWorld. in PharoCore1.1ALPHA #11368 in Win32 and if you want to add halos to this morph to remove it easily, the halos are added to the world PasteUpMorph and you would need to figure a way to remove it programatically. Cheers, HernÃ¡n

May 24, 2010

[Pharo-project] #methodClass: answering different in Pharo and Squeak

by HernÃ¡n Morales Durand

Hi, If anyone is using the result of CompiledMethod #methodClass:, in Pharo and Squeak is answering a different object. In Pharo (PharoCore1.1ALPHA #11367) returns an Association and in Squeak 4.1 the CompiledMethod instance which is the historical behavior. This would lead to two different tests where should be the same. Cheers, HernÃ¡n

May 24, 2010

Re: [Pharo-project] [squeak-dev] Need someone to test if NBOpenGL works for you on win32

by HernÃ¡n Morales Durand

Hi Igor, I'm testing your work in Win32. Following instructions in this page http://code.google.com/p/nativeboost/wiki/Installation when evaluating NBInstaller install in PharoCore1.1ALPHA #11368 I receive: "You need to enable an underscore selectors in preferences first". I see no preference listed in the preferences browsers and didn't found the #allowUnderscoreSelectors for enabling this setting. Any idea? Cheers, HernÃ¡n 2010/5/24 Igor Stasenko <siguctua(a)gmail.com>: > Hi, > > i just snapshotted my stuff with various fixes, to make it load > cleanly on pharo and squeak images. > > I'd like you to ask to test and load it and tell me if it works for you. > > Currently it works only on win32 platform. It could work on Linux, but > i didn't had time to port it yet. > > There is no automatic installation procedure right now, so here what > you should try: > > - first, you need to have VM with NativeBoost plugin + NativeBoost > loaded into an image > (see http://code.google.com/p/nativeboost/wiki/Installation for instructions) > > > - then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL > in following order: > > - NBOpenGL-Core > - NBOpenGL-Win > - NBOpenGL-TrueType > - NBOpenGL-Display > - NBOpenGL-Morphic > > i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were > released recently, > and it seems works ok. > on squeak/trunk it should also work without problems. > > Now, if everything went right, then we're ready to run a demo: > > GLViewportMorph new "useOwnForm: true;" openInWorld > > This thing should render a TrueType glyphs and animating a smooth zoom of it. > Nothing fancy, i just wanna know, if it works for you (and how well). Â :) > > As you may know, GPU/OpenGL implementations vary depending on vendor > and how old your hardware is, > and i don't have all of it at my disposal. > > Ok.. if you got it running, and it renders the glyphs.. there's one thing left: > Â - save your image and quit (without closing this morph) > Â - start image > > it should continue working as if nothing happens. > > -- > Best regards, > Igor Stasenko AKA sig. > >

May 24, 2010

Re: [Pharo-project] ClassTestCase

by Lukas Renggli

> For now the list of levente and a slow machine > > Â Â Â Â "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." > is the one to use Please read my comments on the issue tracker. For *any practical* example it doesn't matter what to use speed wise: 1 = nil ifTrue: [ ] 2 == nil ifTrue: [ ] 3 isNil ifTrue: [ ] 4 ifNil: [ ] Personally I find 3 the most readable. 1 and 3 are the only practical ones if you use OODBs, because they are not shortcut by the compiler. I only use 4 for lazy initializers, it makes a good pattern. The use of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable if you don't care about compatibility with other Smalltalk dialects. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 24, 2010

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by Igor Stasenko

On 24 May 2010 18:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >> >> I did this once for GLCanvas, and don't want to repeat that again :) >> The Balloon canvas and its uses is too damn focused on blitting, which makes >> it too hard to provide a backend which doing most things on GPU. >> If you want to go into vector world, you should keep a distance from >> any blitting operations. >> Simply because they are ineffective, CPU hungry and don't scale well. > > In that case what would be the next generation API (call it Athens) > that would make ROME getting better and that your code would propose an API compliant > interface? You could that way have a class that implements the Athens interface and > the system gets improved and you would not depend on Athens. > Â Because we should not neglect that without common API change and adaptation > is and will be a pain. > Yes. But i want to stress, what meaning we are putting into 'API'. API is protocols, not classes. So, a code which renders something using API, should use only messages sent to a canvas object. The difference could be illustrated by following: a) drawOn: aCanvas path := RomePath new. path moveTo: .. lineTo:... close. aCanvas strokePath: path b) drawOn: aCanvas path := aCanvas newPath. path moveTo: .. lineTo:... close. aCanvas strokePath: path In case a) you are introducing a dependency on a concrete path implementation(RomePath). in case b) you asking a canvas to provide a path instance, which conforms to a path protocol. Here lies the main difference, which either gives you a freedom of choice, or otherwise makes your code inflexible. That's what i mean by no dependecy. In case b), a rendering backend is free to use own data structures to optimally reify a path(s), while in case a) you forcing a canvas to have an intimate knowledge about RomePath - a concrete implementation, which may not fit best for canvas and hence it will waste cycles converting a path representation into more appropriate form, in order to render it. That's why, if we follow path b), then morphic rendering could be completely autonomous, and do not depend on concrete Rome API implementation. And enforcing it from a very starting, will make sure that we won't introduce unnecessary dependencies and inflexibility. > Stef > _______________________________________________ > 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.

May 24, 2010