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

[Pharo-project] [update 1.1] #11369

by StÃ©phane Ducasse

11369 ----- - Issue 2443: Perform:withArguments: Stef

May 22, 2010

Re: [Pharo-project] Status of Rome?

by Igor Stasenko

On 22 May 2010 18:34, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > me too. > Now igor do you plan to do it in pharo or by calling opengl? > Err.. what you mean by pharo? I making a calls to OpenGL, using NativeBoost's OpenGL bindings. All stuff is coded in smalltalk, so sure thing its does things in pharo :) > > On May 22, 2010, at 4:54 PM, Lukas Renggli wrote: > >> That looks cool. I am looking forward seeing that stuff in action :-) >> >> Lukas >> >> 2010/5/22 Igor Stasenko <siguctua(a)gmail.com>: >>> Good. >>> >>> I am now trying to implement a vector(truetype) font rendering. >>> >>> Just finished a little GPU fragment shader snippet, which renders a >>> quad bezier curve, with antialiasing included :) >>> >>> You supplying 3 points, which defines a quadratic curve to GPU, and it >>> does the rest. >>> >>> This is a basis for smooth true-type font rendering, since it contains >>> a contours >>> consisting from line segments or quadratic bezier segments. >>> >>> -- >>> 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 >>> >> >> >> >> -- >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 22, 2010

Re: [Pharo-project] Status of Rome?

by StÃ©phane Ducasse

me too. Now igor do you plan to do it in pharo or by calling opengl? On May 22, 2010, at 4:54 PM, Lukas Renggli wrote: > That looks cool. I am looking forward seeing that stuff in action :-) > > Lukas > > 2010/5/22 Igor Stasenko <siguctua(a)gmail.com>: >> Good. >> >> I am now trying to implement a vector(truetype) font rendering. >> >> Just finished a little GPU fragment shader snippet, which renders a >> quad bezier curve, with antialiasing included :) >> >> You supplying 3 points, which defines a quadratic curve to GPU, and it >> does the rest. >> >> This is a basis for smooth true-type font rendering, since it contains >> a contours >> consisting from line segments or quadratic bezier segments. >> >> -- >> 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 >> > > > > -- > 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 22, 2010

Re: [Pharo-project] [squeak-dev] Re: Cross-fork Metacello configurations

by Bernhard Pieber

Dear Squeakers, I agree with Sean that the necessity to copy a configuration class from a cross-fork package ConfigurationOf... to the proposed Configuration package for Squeak makes life much more complicated and more work for those good fellows who care to create portable packages. IMHO that is a bad things for all forks. The ability to support cross-fork development is one of the greatest assets of Metacello. I see no reason not to use it. The good news is that - as Sean already wrote - all the good things of Andreas proposal could work equally well even if we reused the cross-fork ConfigurationOf... packages. The fact that some core developer copies such a package to the trunk could mean it was tested with Squeak. The only difference would be having more packages in the Monticello Browser. (They could be hidden from there.) IIUC one thing misses from Metacello right now to use it in the way Andreas envisions: A categorization for an installer UI like Andreas' ConfigBrowser. I am sure Dale could be convinced to add that to the metadata/API if cross-development configurations could continue to be supported. Did I miss something? Just my 2 cents. Cheers, Bernhard Am 21.05.2010 um 20:14 schrieb Sean P. DeNigris: > > > Bert Freudenberg wrote: >> >> If the systems require different configurations, then there should be >> different configurations. >> > Absolutely, and Metacello already handles the difference. Handling it by > creating two separate Classes is solving a problem that doesn't exist, while > creating a problem for developers - who now have to do extra work for no > discernible reason. > > > Bert Freudenberg wrote: >> >> re-using configurations is not that important >> > Maybe not for code reuse, but logistically, it's much harder. I'm going > through SqS and SqMap making old interesting projects loadable. A little > more effort * 100 projects is significant. > > > Bert Freudenberg wrote: >> >> What *is* more important is that the configuration has actually been >> tested in Squeak, and not just been copied over from other places. >> > > Yes, but that is irrelevant here. If someone adds the config to the inbox, > that presumably means they have tested it in Squeak. And, there would be > nothing to prevent someone from creating a new config from scratch that > didn't work; maybe more likely not to work because a perfectly good config > has to be split apart. Anyway, I thought that's why we're going to do > automatic testing. > > In summary, if we can make life easier, why not? For example, couldn't > ConfigBrowser select classes that start with ConfigurationOf instead of > MetacelloConfigruation subclasses? > > Sean > -- > View this message in context: http://forum.world.st/Cross-fork-Metacello-configurations-tp2226390p2226525… > Sent from the Squeak - Dev mailing list archive at Nabble.com. >

May 22, 2010

Re: [Pharo-project] Status of Rome?

by Lukas Renggli

That looks cool. I am looking forward seeing that stuff in action :-) Lukas 2010/5/22 Igor Stasenko <siguctua(a)gmail.com>: > Good. > > I am now trying to implement a vector(truetype) font rendering. > > Just finished a little GPU fragment shader snippet, which renders a > quad bezier curve, with antialiasing included :) > > You supplying 3 points, which defines a quadratic curve to GPU, and it > does the rest. > > This is a basis for smooth true-type font rendering, since it contains > a contours > consisting from line segments or quadratic bezier segments. > > -- > 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 > -- Lukas Renggli www.lukas-renggli.ch

May 22, 2010

Re: [Pharo-project] Status of Rome?

by Igor Stasenko

Good. I am now trying to implement a vector(truetype) font rendering. Just finished a little GPU fragment shader snippet, which renders a quad bezier curve, with antialiasing included :) You supplying 3 points, which defines a quadratic curve to GPU, and it does the rest. This is a basis for smooth true-type font rendering, since it contains a contours consisting from line segments or quadratic bezier segments. -- Best regards, Igor Stasenko AKA sig.

May 22, 2010

Re: [Pharo-project] Pharo sprint in buenos Aires is starting now

by Alexandre Bergel

> IRC: http://www.mibbit.com/chat/ (Channel #pharo-project) Please, use http://webchat.freenode.net/?channels=pharo-project instead Alexande

May 22, 2010

[Pharo-project] Link to Web Client

by Diogenes Moreira

http://webchat.freenode.net/?channels=pharo-project

May 22, 2010

[Pharo-project] Pharo sprint in buenos Aires is starting now

by Alexandre Bergel

A bit after the schedule, but we are a little group. http://code.google.com/p/pharo/wiki/PharoSprints IRC: http://www.mibbit.com/chat/ (Channel #pharo-project) Cheers, Alexandre

May 22, 2010

Re: [Pharo-project] Styler?

by StÃ©phane Ducasse

The problem is with CodeMorph lukas. It requires a styler. in the past it was hardcoding a ref to SHTextStylerST80 I removed it and I added an instance variable stylerClass. But now it means that this is the responsibility of the client to specify the styler and having one by default would be nice. Stef On May 22, 2010, at 12:13 PM, Lukas Renggli wrote: > Why is a NullStyler necessary when Shout can load without overriding any code? > > Lukas > > 2010/5/22 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Sat, May 22, 2010 at 10:09 AM, stephane ducasse >> <stephane.ducasse(a)free.fr> wrote: >>> >>> Hi guys >>> >>> what do we do with shout? >>> Squeak introduced it directly in the system. Now I was thinking that what >>> could be a solution is to have a >>> default API/null pattern class that could be in the core and that when >>> Shout gets loaded the shout class is used instead. >> >> Wasn't this the idea of ToolSet ? but sucks...(as we said few threads ago) >> >>> >>> Now we could add Shout to the TextEditor package but I would like to >>> understand how we can do it without. >> >> This is an excellent question and idea. Using some kind of Strategy pattern >> or similar may help. >> But I 9999999999^9999999 not to put Shout neither Style in Core ;) >> >> I haven't look anything about the code. I have no idea. But cannot CodeMorph >> or whatever have a class variable that holds the Styler? >> Then we create, as you said, a NullStyler for core. Shout implements its own >> Styler and when loaded, it does: >> CodeMorph styler: ShoutStyler or similar. >> >> I guess the NullStyler is better than having to do everywhere codeMorph >> styler isNil ifFalse: [ .... >> >> Cheers >> >> Mariano >> >> >>> >>> And also it is interesting to see if one day we will need selector >>> namespace or something like that to deal well with extensions. >>> Stef >>> >>> in PharoCore-1.1 11367 >>> >>> Fails as CodeMorph#stylerClass is not initialized. And no *Styler* class >>> exists on PharoCore.... >>> >>> To make test passes on Pharo I've written >>> >>> CodeMorph#defaultStylerClass >>> ^ SHTextStylerST80 >>> >>> CodeMorph#stylerClass >>> ^ stylerClass ifNil: [stylerClass := self defaultStylerClass]. >>> >>> the solution proposed by laurent only works when shout is loaded and this >>> is not always the case. >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > 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 22, 2010