- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Feature: SystemOrganizer class>>default returns SystemOrganization

by Sean P. DeNigris

On May 18, 2010, at 11:42 AM, StÃ©phane Ducasse [via Smalltalk] <ml-node+2221496-1604744895-217701(a)n4.nabble.co m> wrote: > Right now SystemOrganization is a global stored in SystemDictionary. > And it would be nice to have a new instance named organizer held by > SystemDictionary that points > to the organizer associated with the SystemDictionary. > Similarly it would be good not to point to the global but use this > new methods. Ok, I undertand more now > Now if you have a class comments please send it we will integrate > it: add it to the bug tracker Okay I'll remove mention of it from the class comment and resubmit. > > I'm a bit worry to introduce a "singleton" It seemed to me like I was just, in effect, clarifying access to an existing singleton, no? Thanks for the explanations. Sean -- View this message in context: http://forum.world.st/Feature-SystemOrganizer-class-default-returns-SystemO… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 19, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by Igor Stasenko

2010/5/19 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Lukas, > > On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> > Same method in different classes do not Â equal eachother though, if I've >> > not made a mistake in: >> > >> > |mrtCp| >> > mrtCp := (InstructionClient>>#methodReturnTop) copy. >> > mrtCp literalAt: 2 put: #ContextPart->ContextPart. >> > (InstructionClient>>#methodReturnTop) = mrtCp >> >> For methods that send super the behavior changes if you change the >> class binding. That's probably why it is not ignored for #=. >> >> In fact I would suggest to #= from compiled method altogether, in most >> cases it doesn't do what one would expect in a given context anyway. >> There are too many and possibility completely different >> interpretations of #= for CompiledMethod. #== is the only decent >> implementation for this class. > > I sympathise but I think there is a reasonable default interpretation of #= > for CompiledMethod that is what most people want. Â The intent is to answer > whether two methods have the same execution semantics and same method tags & > properties, e.g. if one were to compile the same source code in two > different classes that had the same inst var offsets for the inst vars in > the methods, then one would want those methods to be #=. Â This allows tests > such as > - checking whether a subclass has a method that is #= to a superclass, and > is hence redundant. > - checking whether a set of sourceless methods are equivalent so that they > may be shared under different selectors (e.g. think auto-generated accessor > methods which can be cached and shared) > So for this informal definition the selector and the class are irrelevant, > but bytecodes and literals (apart from the selector and method class > literals) are relevant. Â Its almost a short-cut comparison of error-free > decompilation, although there are differences in the bytecode that wouldn't > show in decompilation (e.g. using long branches for short branches). > The current definition serves for compiler hackers as it tells you > accurately whether a compiler change has an effect on the bytecode, can be > used to test whether compilation followed by decompilation followed by > recompilation has an effect, etc. Â While it may not be a universal code > comparison method it has met my needs throughout the closure compiler so at > least I'm pretty happy with it. > (pleading for CompiledMethod>>#= to stay the same as the current Squeak 4.1 > definition, which ever since Nichoas Celier's float compilation changes, is > pretty darned good). > best > Eliot > Well, we could have a cake and eat it too. - rename #= to #isEqualToMethod: Then, the parts which intentionally require a comparisons, like you described above, will use this message. While for the rest of smalltalk code , sending #= will end up being #==. > > >> >> Lukas >> >> > >> > At the very least, the branches of >> > index = 1 and: [ #(117 120) includes: self primitive ]) >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ >> > >> > REALLY deserve some comments... >> > >> > Cheers, >> > Henry >> > >> > >> > >> > _______________________________________________ >> > 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 19, 2010

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

by Henrik Sperre Johansen

On 19.05.2010 02:17, jaayer wrote: > > ============ Forwarded message ============ > From : jaayer<jaayer(a)zoho.com> > To :<alexandre.bergel(a)inria.fr> > Date : Tue, 18 May 2010 16:30:06 -0700 > Subject : Re: Decoding bug with XMLParser ? > ============ Forwarded message ============ > > ---- On Tue, 18 May 2010 02:29:18 -0700 Alexandre Bergel<alexandre.bergel(a)inria.fr> wrote ---- > >> To give a bit of context, the problem is: >> >> -=-=-=-=-=-=-=-=-=-=-=-= >> exampleEncodedXML >> ^'<?xml version="1.0" encoding="UTF-8"?> >> <test-data>…</test-data> >> ' >> >> testDecodingCharacters >> | xmlDocument element | >> "XMLTokenizer testDecodingCharacters" >> >> xmlDocument := XMLDOMParser parseDocumentFrom: self exampleEncodedXML readStream. >> element := xmlDocument firstTagNamed: #'test-data'. >> >> self assert: element contentString first codePoint = 8230 >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> #testDecodingCharacters goes yellow >> >>> Thinking of it, it's not really an encoding problem, rather a bug in >>> the entity->character conversion. I guess there should be a similar >>> test where there is an actual ellipsis character in the xml, instead >>> of the entity. >> Any idea how your test can goes green? >> >>> And now I realize our server will not be able to connect outside its >>> DMZ, so I won't be able to use the fix :D >> DMZ ? >> >> Cheers, >> Alexandre >> > Character references like the one above are handled using #nextCharReference. It does so by reading the number after the "&#" or "&x" prefix and then sending #value: to the class Unicode with that as the argument. If you evaluate the following code in a workspace with cmd-p: "(Unicode value: 8230) codePoint", you will see that the resulting code point is not what you would expect. For me it was "1069555750". The same behavior results when creating a Unicode character with #charFromUnicode:. Unless Unicode>>value: and Unicode>>charFromUnicode: are being used incorrectly, I am not sure that this is a bug, or least a bug in XML-Support. > > (I am working on adding full DTD support with validation and refactoring and re-engineering the parser at the moment, which is why minor releases have slowed to a trickle. I will take a closer look at how character encoding is handled in the process.) codePoint returns the raw value, which includes the leadingChar used to differentiate between different locale interpretations of the same character. In 1.0 this was 255 for WideCharacters, in 1.1 it has been changed to 0. ie, using codePoint in the test is erroneous, for a method which returns what you expect in both 1.0 and 1.1, use asUnicode. Cheers, Henry

May 19, 2010

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

by Levente Uzonyi

On Tue, 18 May 2010, jaayer wrote: > ============ Forwarded message ============ >From : jaayer<jaayer(a)zoho.com> To : <alexandre.bergel(a)inria.fr> Date : Tue, 18 May 2010 16:30:06 -0700 Subject : Re: Decoding bug with XMLParser ? ============ Forwarded message ============ ---- On Tue, 18 May 2010 02:29:18 -0700 Alexandre Bergel <alexandre.bergel(a)inria.fr> wrote ---- >To give a bit of context, the problem is: > >-=-=-=-=-=-=-=-=-=-=-=-= >exampleEncodedXML >Â Â Â Â ^'<?xml version="1.0" encoding="UTF-8"?> ><test-data>…</test-data> >' > >testDecodingCharacters >Â Â Â Â | xmlDocument element | >Â Â Â Â "XMLTokenizer testDecodingCharacters" > >Â Â Â Â xmlDocument := XMLDOMParser parseDocumentFrom: self exampleEncodedXML readStream. >Â Â Â Â element := xmlDocument firstTagNamed: #'test-data'. >Â Â Â Â >Â Â Â Â self assert: element contentString first codePoint = 8230 >-=-=-=-=-=-=-=-=-=-=-=-= > >#testDecodingCharacters goes yellow > >> Thinking of it, it's not really an encoding problem, rather a bug in >> the entity->character conversion. I guess there should be a similar >> test where there is an actual ellipsis character in the xml, instead >> of the entity. > >Any idea how your test can goes green? > >> And now I realize our server will not be able to connect outside its >> DMZ, so I won't be able to use the fix :D > >DMZ ? > >Cheers, >Alexandre > Character references like the one above are handled using #nextCharReference. It does so by reading the number after the "&#" or "&x" prefix and then sending #value: to the class Unicode with that as the argument. If you evaluate the following code in a workspace with cmd-p: "(Unicode value: 8230) codePoint", you will see that the resulting code point is not what you would expect. For me it was "1069555750". The same behavior results when creating a Unicode character with #charFromUnicode:. Unless Unicode>>value: and Unicode>>charFromUnicode: are being used incorrectly, I am not sure that this is a bug, or least a bug in XML-Support. (I am working on adding full DTD support with validation and refactoring and re-engineering the parser at the moment, which is why minor releases have slowed to a trickle. I will take a closer look at how character encoding is handled in the process.) Another "hard to quote" message, but I hope my answer will be clear. The "problem" is that in Pharo the leadingChar for unicode characters is still 255. This was changed in Squeak 4.1 to 0. So in Squeak 4.1: (Unicode value: 8230) codePoint. "===> 8230" While in Pharo it's: (Unicode value: 8230) codePoint. "===> 1069555750" (Character value: 1069555750) charCode. "===> 8230" (Character value: 1069555750) leadingChar. "===> 255" So using #charCode instead of #codePoint is the solution. Levente _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 19, 2010

Re: [Pharo-project] Managing Pharo external packages with Metacello, please read!

by Dale Henrichs

Yes, I don't think that it is a good idea to modify the configuration when it is published in the PharoXXMetacelloRepository. In the end the reason for this discussion revolves around the desire to provide a simple method for developers/users to load projects that are "known/tested to work in PharoXX". Creating a PharoXXMetacelloRepository means that we have a "white list" of configurations that are"known/tested to work in PharoXX". GoferProjectLoader provides an API for loading projects from a target repository. The API makes it very simple to load a particular project by name, without having to specify more details about the version of groups involved. It also means that one can arrange to do special things under the cover of the GoferProjectLoader, like point to a different repository based upon the version of Pharo that it is running in ... I think that what we need in addition to a "white list" of projects, a "white list" of _versions_ that are "known/tested to work in PharoXX." I think it would be straightforward to subclass/extend the GoferProjectLoader to add the notion of a version/group "white list" that records the exact configuration/version/group(s) that have been tested and known to work. This same extension to GoferProjectLoader can automatically include an overrideRepositories: to ensure that all projects/packages are loaded from the PharoXXMetacelloRepository repository... By default, the GoferProjectLoader loaded into PharoXX would point to PharoXXMetacelloRepository and use the "white list" of versions. Once a developer/user has become comfortable using PharoXX, he/she can configure GoferProjectLoader to suit his/her needs as well as directly load Configurations/versions that are not on the "white list" (using Metacello directly) without requiring any changes to the configurations or where they originated from... So in the end the following expression will do things differently depending upon a) which version of Pharo it is executed in and b) whether or not you are using the 'default' GoferProjectLoader: Gofer project load: 'SqueakDBX'. All while using the same Configuration... Dale StÃ©phane Ducasse wrote: Yes I think that this is what dale proposed. Dale is off line today but he will probably comment Stef On May 18, 2010, at 10:59 AM, Tudor Girba wrote: Hi, I like this approach: 1. Projects can continue to be built independently. For example, in Moose, we have already a process with multiple configurations (one for each repository) depending on each other. 2. When ready, the Configurations and all related packages are "published" in the PharoXXMetacelloRepository. Having a package per Configuration makes it easy to copy it. The only problem is that the code of Configuration mentions explicitly the repository (especially in the case of having nested Configurations, I point to a configuration by specifying the repository, package, and class). So, I guess the simplest thing here would be to provide the default "load" method to already override dynamically all repositories with the PharoXXMetacelloRepository. Cheers, Doru On 18 May 2010, at 09:32, StÃ©phane Ducasse wrote: I understand nicolas. Now my agenda is more than full. and the proposal is here. Simple ========================================================== One repo per version Pharo1.0, Pharo11 ... MetacelloRepository containing **published** configurationOfXXX -> all the dependent packages are copied locally + configuration ready to load using load. A project contain its single/or several configurationOfMyProject with the complete history people commit the config to their repository and if they want they **publish** from their repository to the version repository a version. This version is frozen -> all the dependent packages are copied locally + configuration ready to load using load. For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages. We can use automatic build server to validate the status or migration between different repositories ========================================================== Stef On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote: The meaning of my message was don't do it for squeak, but do it for yourself. I don't doubt the mailing list is a mine of information, but even in the best mine you need to dig a lot before extracting the gold nuggets. Of course, I've got no right to control your agenda, who am I ? You can consider the subject close, and I won't find your attitude shocking at all. But next time, consider writing a rationale for your own, it will increase quality of Pharo decision process. Best regards Nicolas 2010/5/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr><mailto:stephane.ducasse@inria.fr>: nicolas all the information is in the metacello mailing-list and we already posted many mails on that topics in this mailing list. I'm sorry but I do not have the time to repeat again what we said. Now since I'm in a really good mood in a nutshell one repo per version Pharo1.0, Pharo11 ... MetacelloRepository containing configurationOfXXX frozen = all the dependent packages are copied locally + configuration ready to load using load. a project contain its single/or whatever configurationOfMyProject people publish the config to their repository and if they want they push from their repository to the version repository a version that they freeze (may be using tags) For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages. Then we have a server that load configuration and barks if something wrong happen. And may be we kick out the configurationofXXX from MetacelloRepositories Steph, I understand how boring it may seem: - you already discussed the subject over and over - you already took decisions and now we come later with new proposals, and ask you to reconsider the work again... more than that. :) It looks like if we did not talk or think about what we are doing. As for the Preferences/Settings, Pharo choices are probably very weel thought. However, every solution will come with trade offs, and it would be good to have a rationale justifying the choices you made, and perhaps more importantly justifying why you did abandon some solutions, because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... and find different answers in different context. Note that Squeak evolutions might have influence on Pharo too, and it's part of the context... I strongly encourage you to establish your rationale on Pharo grounds - independently of Andreas proposals, put it on the Pharo wiki and let us know the URL. You also know that Squeak goals are not exactly those of Pharo w.r.t. backward compatibility, so Squeak can't just blindly replicate Pharo solutions without a rationale. The merit of Andreas proposal is to try and establish such a rationale. Without it, we're bound to repeat discussions again and again, So to fix the problem consider that as our proposal. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com<http://www.tudorgirba.com> "Every thing has its own flow." _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 19, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by Eliot Miranda

Hi Lukas, On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Same method in different classes do not equal eachother though, if I've > not made a mistake in: > > > > |mrtCp| > > mrtCp := (InstructionClient>>#methodReturnTop) copy. > > mrtCp literalAt: 2 put: #ContextPart->ContextPart. > > (InstructionClient>>#methodReturnTop) = mrtCp > > For methods that send super the behavior changes if you change the > class binding. That's probably why it is not ignored for #=. > > In fact I would suggest to #= from compiled method altogether, in most > cases it doesn't do what one would expect in a given context anyway. > There are too many and possibility completely different > interpretations of #= for CompiledMethod. #== is the only decent > implementation for this class. > I sympathise but I think there is a reasonable default interpretation of #= for CompiledMethod that is what most people want. The intent is to answer whether two methods have the same execution semantics and same method tags & properties, e.g. if one were to compile the same source code in two different classes that had the same inst var offsets for the inst vars in the methods, then one would want those methods to be #=. This allows tests such as - checking whether a subclass has a method that is #= to a superclass, and is hence redundant. - checking whether a set of sourceless methods are equivalent so that they may be shared under different selectors (e.g. think auto-generated accessor methods which can be cached and shared) So for this informal definition the selector and the class are irrelevant, but bytecodes and literals (apart from the selector and method class literals) are relevant. Its almost a short-cut comparison of error-free decompilation, although there are differences in the bytecode that wouldn't show in decompilation (e.g. using long branches for short branches). The current definition serves for compiler hackers as it tells you accurately whether a compiler change has an effect on the bytecode, can be used to test whether compilation followed by decompilation followed by recompilation has an effect, etc. While it may not be a universal code comparison method it has met my needs throughout the closure compiler so at least I'm pretty happy with it. (pleading for CompiledMethod>>#= to stay the same as the current Squeak 4.1 definition, which ever since Nichoas Celier's float compilation changes, is pretty darned good). best Eliot > Lukas > > > > > At the very least, the branches of > > index = 1 and: [ #(117 120) includes: self primitive ]) > > ifTrue: [ > > > > REALLY deserve some comments... > > > > Cheers, > > Henry > > > > > > > > _______________________________________________ > > 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 19, 2010

[Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

by jaayer

============ Forwarded message ============ >From : jaayer<jaayer(a)zoho.com> To : <alexandre.bergel(a)inria.fr> Date : Tue, 18 May 2010 16:30:06 -0700 Subject : Re: Decoding bug with XMLParser ? ============ Forwarded message ============ ---- On Tue, 18 May 2010 02:29:18 -0700 Alexandre Bergel <alexandre.bergel(a)inria.fr> wrote ---- >To give a bit of context, the problem is: > >-=-=-=-=-=-=-=-=-=-=-=-= >exampleEncodedXML >Â Â Â Â ^'<?xml version="1.0" encoding="UTF-8"?> ><test-data>…</test-data> >' > >testDecodingCharacters >Â Â Â Â | xmlDocument element | >Â Â Â Â "XMLTokenizer testDecodingCharacters" > >Â Â Â Â xmlDocument := XMLDOMParser parseDocumentFrom: self exampleEncodedXML readStream. >Â Â Â Â element := xmlDocument firstTagNamed: #'test-data'. >Â Â Â Â >Â Â Â Â self assert: element contentString first codePoint = 8230 >-=-=-=-=-=-=-=-=-=-=-=-= > >#testDecodingCharacters goes yellow > >> Thinking of it, it's not really an encoding problem, rather a bug in >> the entity->character conversion. I guess there should be a similar >> test where there is an actual ellipsis character in the xml, instead >> of the entity. > >Any idea how your test can goes green? > >> And now I realize our server will not be able to connect outside its >> DMZ, so I won't be able to use the fix :D > >DMZ ? > >Cheers, >Alexandre > Character references like the one above are handled using #nextCharReference. It does so by reading the number after the "&#" or "&x" prefix and then sending #value: to the class Unicode with that as the argument. If you evaluate the following code in a workspace with cmd-p: "(Unicode value: 8230) codePoint", you will see that the resulting code point is not what you would expect. For me it was "1069555750". The same behavior results when creating a Unicode character with #charFromUnicode:. Unless Unicode>>value: and Unicode>>charFromUnicode: are being used incorrectly, I am not sure that this is a bug, or least a bug in XML-Support. (I am working on adding full DTD support with validation and refactoring and re-engineering the parser at the moment, which is why minor releases have slowed to a trickle. I will take a closer look at how character encoding is handled in the process.)

May 19, 2010

[Pharo-project] Pharo sprint this Saturday

by Alexandre Bergel

Hi All, I am now with Mariano, working on the details for this Saturday. More info on http://code.google.com/p/pharo/wiki/PharoSprints Please, get in touch with Mariano first if you want to attend. As already said, the objective of the sprint will be to help produce Pharo 1.1 We will try to be present on IRC and/or iChat for remote pair programming :-) Cheers, Alexandre

May 18, 2010

Re: [Pharo-project] TORCH: supporting source-code change integration

by Tudor Girba

Hi Veronica, A bit of feedback: - After loading Torch, the package contextual menu seems to crash the Monticello Browser - You extend isSuper in RBProgramNode and RBVariableNode, which generates an override conflict with methods in Moose-Core. - The Glamour tags look different, so I guess you also have some Glamour overrides. That should not happen :). Maybe you have some suggestions for improvement, or maybe you just need the border for the [i] icon? Cheers, Doru On 18 May 2010, at 15:16, Veronica Isabel Uquillas Gomez wrote: > Hi Tudor, > > thank you :D > > sure!!! > > cheers, > Veronica > > > On 18 May 2010, at 11:39, Tudor Girba wrote: > >> Hi Veronica, >> >> It is pretty impressive :). >> >> Would it be Ok if I added this on the Moose page? >> >> Cheers, >> Doru >> >> >> On 18 May 2010, at 11:21, StÃ©phane Ducasse wrote: >> >>> Thanks veronica. >>> lukas said that he was impressed this is a complement :) >>> >>> On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote: >>> >>>> Dear all, >>>> >>>> I would like to announce Torch, a tool for supporting source-code >>>> change integration. For now, it offers visualizations of the >>>> changes and enhanced change lists. >>>> Torch can be accessed through Monticello (in the main MC browser, >>>> in the repository browser or in the history browser). Selecting a >>>> version or slice, you can view the changes with Torch using the >>>> contextual menu. >>>> Once you open the Torch dashboard, you can access the enhanced >>>> change list or a detailed visualization via the contextual menu >>>> as well. >>>> >>>> Torch is available on SqueakSource, the repository is named >>>> Torch, and you need to load the ConfigurationOfTorch package. >>>> It runs in a dev or core image. >>>> >>>> For a dev image. >>>> - ConfigurationOfTorch loadVersion10 >>>> >>>> For a core image. >>>> 1) Set fonts - described in the attached file. >>>> 2) ConfigurationOfTorch loadDefault >>>> >>>> I would appreciate comments and feedback! >>>> >>>> Best Regards, >>>> VerÃ³nica Uquillas GÃ³mez >>>> Vrije University Brussel - SOFT Lab >>>> University of Lille - RMOD Team >>>> >>>> <torchFontsScript.st> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of >> problem understanding." >> >> >> >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

May 18, 2010

Re: [Pharo-project] [Moose-dev] rome

by Igor Stasenko

On 19 May 2010 01:21, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > > On May 19, 2010, at 12:03 AM, Igor Stasenko wrote: > >> On 19 May 2010 00:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> rome is a new api for rendering image and text. >>> the idea is to offer a common api and several backends >>> Â Â Â Â one would balloon >>> Â Â Â Â another would be cairo/pango >>> Â Â Â Â a third one could be morphic30 primitives >> >> - a fourth one is direct OpenGL backend :) >> > > > OpenGL would be a nice backend indeed. > > But the text rendering would be missing, in the OpenGLCanvas part of ROME, and would have to be taken from another library? > When i wanted to add text rendering over OpenGL for Lumiere, i saw a couple of external libraries for freetype2 rendering. > Just by curiosity, did you have something in mind regarding this? > I do: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html Freetype having an API to extract the vector data from glyphs. So, the only thing what is needed is to convert & pass that data directly on GPU, and don't bother wasting time with pixels. For raster fonts, its even simpler - just use textures. > Regards, > 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.

May 18, 2010