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

Re: [Pharo-project] [ANN] OpenGL specs parser/FFI methods generator

by Andreas Raab

On 4/13/2010 8:42 PM, Igor Stasenko wrote: > On 14 April 2010 06:22, Andreas Raab<andreas.raab(a)gmx.de> wrote: >> On 4/13/2010 8:10 PM, Igor Stasenko wrote: >>> >>> i just submitted a code, which could help us greatly in having >>> up-to-date and full OpenGL API coverage in Squeak. >>> >>> This package extracts data directly from spec files, used by OpenGL >>> folks for generating C headers (gl.h / glext.h etc). >> >> Sweet! I had no idea these spec files existed. Do you know if the spec files >> cover OpenGL ES as well? Also, have you run this against the existing OpenGL >> code to see if it produces matching output? (more to verify your translation >> than anything else) >> > I think better would be to check with C header files, like glew > (http://sourceforge.net/projects/glew/) True. Have you tried it? > The FFI code generator is unfinished (if you look at it, its using an > OpenGL-defined standard type set, like GLEnum GLShort etc..) > So, there should be 1 more mapping step to turn them into 'long short' etc. > Or, if FFI can cope with type aliases, then they could be kept as is. This should be straightforward. > There's also all constant values sitting parsed. But i haven't coded > the fileout yet. > The repository is open for write globally, so you can just commit your > stuff right there. > > But i'd like to note, that in order to avoid dependencies, it would be > better to use separate subpackage > for code generation, while in original package there should be just > classes for parsing and holding the data. Well, I don't really care since this would be (mostly) a one-time job unless someone cares about special API versions ;-) OpenGL should be generated by something like: OpenGLApiGenerator generateFunctions: 1.4 on: OpenGL. which would create the equivalent to the current OpenGL function set. Then we move on to, e.g., OpenGLApiGenerator generateExtFunctions: 'ARB_multisample' on: OpenGL. etc. The default OpenGL would include all versions and extensions but if you'd like to be more specific you can generate custom versions of the API for your use (we'd do this for Teleplace for example since we're trying to stick to 1.4 and certain extensions). Cheers, - Andreas >> I'm definitely interested in looking at this. The original OpenGL calls were >> generated by code that I've lost in the mean time so it's great to have a >> way of recreating it from first principles! >> > Yeah. I've been looking for having this a long time :) > >> Cheers, >> - Andreas >> >> >>> So it is 100% correct. >>> Parsing these files is much easier than C headers. >>> There's also a lot of additional data , which helps to automatically >>> categorise the methods and generate correct callout code. >>> >>> The parsed data can be later used for generating an FFI/Alien OpenGL >>> callout code with full coverage of all existing extensions. >>> And you don't need to keep this package in image after you done >>> generating the code. >>> Or, it can stay, just make sure that you prune all parsed data by issuing: >>> >>> GLAPIData reset. >>> >>> The sources for parsing is located at: >>> >>> http://www.opengl.org/registry/#specfiles >>> >>> Place all *.spec and *.tm files into a single directory, and then issue: >>> >>> GLAPIData parseAll: (FileDirectory on: 'your/path'). >>> >>> >>> There is an example, how to generate an FFI callout methods. >>> >>> Use: >>> >>> GLAPIData gl generateFFIMethodsInto: (FileStream newFileNamed: >>> 'gl.st') forClass: 'OpenGL' >>> >>> Then, you can file-in the generated code right into your image: >>> >>> (FileStream oldFileNamed: 'gl.st') fileIn >>> >>> The resulting file is about 700kbytes big, having methods like: >>> >>> !OpenGL methodsFor: 'EXT_framebuffer_multisample' stamp: >>> 'Igor.Stasenko 4/14/2010 05:22'! >>> glRenderbufferStorageMultisampleEXT: target with: samples with: >>> internalformat with: width with: height >>> "This method was automatically generated from OpenGL specs" >>> "See http://squeaksource.com/OpenGLSpecs for details" >>> <apicall: void 'glRenderbufferStorageMultisampleEXT' (GLenum >>> GLsizei >>> GLenum GLsizei GLsizei)> >>> ^ self externalCallFailed >>> >>> >>> P.S. I plan to use this data directly by native code, in a way like: >>> >>> glTexCoord2hNV: s with: t >>> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>> ^ self glAPICall: 'glTexCoord2hNV' >>> >>> since i don't need a type data placed in method. I guess, Alien could >>> use similar approach. >>> >> >> >> > > >

April 14, 2010

Re: [Pharo-project] [squeak-dev] Re: [ANN] OpenGL specs parser/FFI methods generator

by Igor Stasenko

On 14 April 2010 06:22, Andreas Raab <andreas.raab(a)gmx.de> wrote: > On 4/13/2010 8:10 PM, Igor Stasenko wrote: >> >> i just submitted a code, which could help us greatly in having >> up-to-date and full OpenGL API coverage in Squeak. >> >> This package extracts data directly from spec files, used by OpenGL >> folks for generating C headers (gl.h / glext.h etc). > > Do you know if the spec files cover OpenGL ES as well? by looking at gl.spec i see some OES stuff. But its commented out and having different format. So parser don't sees it. > > Cheers, > Â - Andreas > > >> So it is 100% correct. >> Parsing these files is much easier than C headers. >> There's also a lot of additional data , which helps to automatically >> categorise the methods and generate correct callout code. >> >> The parsed data can be later used for generating an FFI/Alien OpenGL >> callout code with full coverage of all existing extensions. >> And you don't need to keep this package in image after you done >> generating the code. >> Or, it can stay, just make sure that you prune all parsed data by issuing: >> >> GLAPIData reset. >> >> The sources for parsing is located at: >> >> http://www.opengl.org/registry/#specfiles >> >> Place all *.spec and *.tm files into a single directory, and then issue: >> >> Â GLAPIData parseAll: (FileDirectory on: 'your/path'). >> >> >> There is an example, how to generate an FFI callout methods. >> >> Use: >> >> Â GLAPIData gl generateFFIMethodsInto: (FileStream newFileNamed: >> 'gl.st') forClass: 'OpenGL' >> >> Then, you can file-in the generated code right into your image: >> >> Â (FileStream oldFileNamed: 'gl.st') fileIn >> >> The resulting file is about 700kbytes big, having methods like: >> >> !OpenGL methodsFor: 'EXT_framebuffer_multisample' stamp: >> 'Igor.Stasenko 4/14/2010 05:22'! >> glRenderbufferStorageMultisampleEXT: target with: samples with: >> internalformat with: width with: height >> Â Â Â Â "This method was automatically generated from OpenGL specs" >> Â Â Â Â "See http://squeaksource.com/OpenGLSpecs for details" >> Â Â Â Â <apicall: void 'glRenderbufferStorageMultisampleEXT' (GLenum >> GLsizei >> GLenum GLsizei GLsizei)> >> Â Â Â Â ^ self externalCallFailed >> >> >> P.S. I plan to use this data directly by native code, in a way like: >> >> glTexCoord2hNV: s with: t >> Â Â Â Â <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> Â Â Â Â ^ self glAPICall: 'glTexCoord2hNV' >> >> since i don't need a type data placed in method. I guess, Alien could >> use similar approach. >> > > > -- Best regards, Igor Stasenko AKA sig.

April 14, 2010

Re: [Pharo-project] [squeak-dev] Re: [ANN] OpenGL specs parser/FFI methods generator

by Igor Stasenko

On 14 April 2010 06:22, Andreas Raab <andreas.raab(a)gmx.de> wrote: > On 4/13/2010 8:10 PM, Igor Stasenko wrote: >> >> i just submitted a code, which could help us greatly in having >> up-to-date and full OpenGL API coverage in Squeak. >> >> This package extracts data directly from spec files, used by OpenGL >> folks for generating C headers (gl.h / glext.h etc). > > Sweet! I had no idea these spec files existed. Do you know if the spec files > cover OpenGL ES as well? Also, have you run this against the existing OpenGL > code to see if it produces matching output? (more to verify your translation > than anything else) > I think better would be to check with C header files, like glew (http://sourceforge.net/projects/glew/) The FFI code generator is unfinished (if you look at it, its using an OpenGL-defined standard type set, like GLEnum GLShort etc..) So, there should be 1 more mapping step to turn them into 'long short' etc. Or, if FFI can cope with type aliases, then they could be kept as is. There's also all constant values sitting parsed. But i haven't coded the fileout yet. The repository is open for write globally, so you can just commit your stuff right there. But i'd like to note, that in order to avoid dependencies, it would be better to use separate subpackage for code generation, while in original package there should be just classes for parsing and holding the data. > I'm definitely interested in looking at this. The original OpenGL calls were > generated by code that I've lost in the mean time so it's great to have a > way of recreating it from first principles! > Yeah. I've been looking for having this a long time :) > Cheers, > Â - Andreas > > >> So it is 100% correct. >> Parsing these files is much easier than C headers. >> There's also a lot of additional data , which helps to automatically >> categorise the methods and generate correct callout code. >> >> The parsed data can be later used for generating an FFI/Alien OpenGL >> callout code with full coverage of all existing extensions. >> And you don't need to keep this package in image after you done >> generating the code. >> Or, it can stay, just make sure that you prune all parsed data by issuing: >> >> GLAPIData reset. >> >> The sources for parsing is located at: >> >> http://www.opengl.org/registry/#specfiles >> >> Place all *.spec and *.tm files into a single directory, and then issue: >> >> Â GLAPIData parseAll: (FileDirectory on: 'your/path'). >> >> >> There is an example, how to generate an FFI callout methods. >> >> Use: >> >> Â GLAPIData gl generateFFIMethodsInto: (FileStream newFileNamed: >> 'gl.st') forClass: 'OpenGL' >> >> Then, you can file-in the generated code right into your image: >> >> Â (FileStream oldFileNamed: 'gl.st') fileIn >> >> The resulting file is about 700kbytes big, having methods like: >> >> !OpenGL methodsFor: 'EXT_framebuffer_multisample' stamp: >> 'Igor.Stasenko 4/14/2010 05:22'! >> glRenderbufferStorageMultisampleEXT: target with: samples with: >> internalformat with: width with: height >> Â Â Â Â "This method was automatically generated from OpenGL specs" >> Â Â Â Â "See http://squeaksource.com/OpenGLSpecs for details" >> Â Â Â Â <apicall: void 'glRenderbufferStorageMultisampleEXT' (GLenum >> GLsizei >> GLenum GLsizei GLsizei)> >> Â Â Â Â ^ self externalCallFailed >> >> >> P.S. I plan to use this data directly by native code, in a way like: >> >> glTexCoord2hNV: s with: t >> Â Â Â Â <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> Â Â Â Â ^ self glAPICall: 'glTexCoord2hNV' >> >> since i don't need a type data placed in method. I guess, Alien could >> use similar approach. >> > > > -- Best regards, Igor Stasenko AKA sig.

April 14, 2010

Re: [Pharo-project] Connectors minimal version into pharo

by Carla F. Griggio

Interesting! I was just about to try Connectors in Pharo too :P I'd be happy to help if you need a hand. On Mon, Apr 12, 2010 at 10:11 AM, Fernando olivero <oliverof(a)lu.unisi.ch>wrote: > Great! Once i have something working i'll post the package in squeaksource. > > I will try to remove the fsm dependency and try to avoid having so many > extensions, and have a minimal functionality. > Connectors is a full blown system, i just need to draw simple constrained > connection between morphs without the graph support. > > Fernando > > > On Apr 12, 2010, at 2:00 PM, StÃ©phane Ducasse wrote: > > > > > On Apr 12, 2010, at 12:51 AM, Fernando olivero wrote: > > > >> Hi all, i just wanted to re post the fix underscore code Lukas posted a > while ago. > >> > >> I've just imported Connectors package into pharo, (i'm trying to get a > minimal version working ), > > > > excellent! > > I'm interesting in a mini version of that ;) > > > >> and stumbled upon the problem of the underscores.. > >> but now thanks to SmallInt rules it was easy and fast to overcome this > problem! > >> > > > > > > _______________________________________________ > > 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 >

April 14, 2010

Re: [Pharo-project] [ANN] OpenGL specs parser/FFI methods generator

by Andreas Raab

On 4/13/2010 8:10 PM, Igor Stasenko wrote: > i just submitted a code, which could help us greatly in having > up-to-date and full OpenGL API coverage in Squeak. > > This package extracts data directly from spec files, used by OpenGL > folks for generating C headers (gl.h / glext.h etc). Sweet! I had no idea these spec files existed. Do you know if the spec files cover OpenGL ES as well? Also, have you run this against the existing OpenGL code to see if it produces matching output? (more to verify your translation than anything else) I'm definitely interested in looking at this. The original OpenGL calls were generated by code that I've lost in the mean time so it's great to have a way of recreating it from first principles! Cheers, - Andreas > So it is 100% correct. > Parsing these files is much easier than C headers. > There's also a lot of additional data , which helps to automatically > categorise the methods and generate correct callout code. > > The parsed data can be later used for generating an FFI/Alien OpenGL > callout code with full coverage of all existing extensions. > And you don't need to keep this package in image after you done > generating the code. > Or, it can stay, just make sure that you prune all parsed data by issuing: > > GLAPIData reset. > > The sources for parsing is located at: > > http://www.opengl.org/registry/#specfiles > > Place all *.spec and *.tm files into a single directory, and then issue: > > GLAPIData parseAll: (FileDirectory on: 'your/path'). > > > There is an example, how to generate an FFI callout methods. > > Use: > > GLAPIData gl generateFFIMethodsInto: (FileStream newFileNamed: > 'gl.st') forClass: 'OpenGL' > > Then, you can file-in the generated code right into your image: > > (FileStream oldFileNamed: 'gl.st') fileIn > > The resulting file is about 700kbytes big, having methods like: > > !OpenGL methodsFor: 'EXT_framebuffer_multisample' stamp: > 'Igor.Stasenko 4/14/2010 05:22'! > glRenderbufferStorageMultisampleEXT: target with: samples with: > internalformat with: width with: height > "This method was automatically generated from OpenGL specs" > "See http://squeaksource.com/OpenGLSpecs for details" > <apicall: void 'glRenderbufferStorageMultisampleEXT' (GLenum GLsizei > GLenum GLsizei GLsizei)> > ^ self externalCallFailed > > > P.S. I plan to use this data directly by native code, in a way like: > > glTexCoord2hNV: s with: t > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > ^ self glAPICall: 'glTexCoord2hNV' > > since i don't need a type data placed in method. I guess, Alien could > use similar approach. >

April 14, 2010

[Pharo-project] [ANN] OpenGL specs parser/FFI methods generator

by Igor Stasenko

Hello, i just submitted a code, which could help us greatly in having up-to-date and full OpenGL API coverage in Squeak. This package extracts data directly from spec files, used by OpenGL folks for generating C headers (gl.h / glext.h etc). So it is 100% correct. Parsing these files is much easier than C headers. There's also a lot of additional data , which helps to automatically categorise the methods and generate correct callout code. The parsed data can be later used for generating an FFI/Alien OpenGL callout code with full coverage of all existing extensions. And you don't need to keep this package in image after you done generating the code. Or, it can stay, just make sure that you prune all parsed data by issuing: GLAPIData reset. The sources for parsing is located at: http://www.opengl.org/registry/#specfiles Place all *.spec and *.tm files into a single directory, and then issue: GLAPIData parseAll: (FileDirectory on: 'your/path'). There is an example, how to generate an FFI callout methods. Use: GLAPIData gl generateFFIMethodsInto: (FileStream newFileNamed: 'gl.st') forClass: 'OpenGL' Then, you can file-in the generated code right into your image: (FileStream oldFileNamed: 'gl.st') fileIn The resulting file is about 700kbytes big, having methods like: !OpenGL methodsFor: 'EXT_framebuffer_multisample' stamp: 'Igor.Stasenko 4/14/2010 05:22'! glRenderbufferStorageMultisampleEXT: target with: samples with: internalformat with: width with: height "This method was automatically generated from OpenGL specs" "See http://squeaksource.com/OpenGLSpecs for details" <apicall: void 'glRenderbufferStorageMultisampleEXT' (GLenum GLsizei GLenum GLsizei GLsizei) > ^ self externalCallFailed P.S. I plan to use this data directly by native code, in a way like: glTexCoord2hNV: s with: t <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self glAPICall: 'glTexCoord2hNV' since i don't need a type data placed in method. I guess, Alien could use similar approach. -- Best regards, Igor Stasenko AKA sig.

April 14, 2010

Re: [Pharo-project] news about 1.0

by StÃ©phane Ducasse

thanks a lot for the information!. Stef On Apr 13, 2010, at 10:01 PM, laurent laffont wrote: > Hi, > > with last squeak-vm Linux binaries all Pharo tests are green and fonts working. So it may be a good candidate for the one click image. > > http://www.squeakvm.org/unix/release/Squeak-4.0.3.2202-linux_i386.tar.gz > > Cheers, > > Laurent Laffont > > > On Mon, Apr 12, 2010 at 11:40 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Apr 11, 2010, at 11:26 03PM, StÃ©phane Ducasse wrote: > > > Hi guys > > > > mariano, marcus and adrian got some push to get 1.0 out. I was just on cc: > > I think that we made a mistake not to roll that publicly via the mailing-list (we will do that for 1.1). > > Now this is holidays time here, mariano is going to get married and adrian just moved so no > > internet connection. > > Tomorrow I will sync with marcus to know if I can help to get this 1.0 version out. > > If I remember the mails I saw, marcus was looking for the > > BitBltPluging binaries for the one click image on other platforms than mac os. > > > > Stef > Hum, aren't they usually built as internal? > In that case, the only reason for including plugin binaries would be if there's been bug fixes to it since the vm was shipped... > Which would probably mean you're providing a too old VM in the first place. > IIRC, On Windows, 3.11.8 / 4.0.2 would both include updated plugins, the main difference being 4.0.2 providing support for old image segment loading, but requiring in-image handling of quit events. > > Not sure about linux, since I don't use it. > Seems to be in a state of updating at the moment, with 5-6 commits over the weekend, so might be worth waiting for. > > Cheers, > Henry > _______________________________________________ > 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

April 13, 2010

Re: [Pharo-project] news about 1.0

by laurent laffont

Hi, with last squeak-vm Linux binaries all Pharo tests are green and fonts working. So it may be a good candidate for the one click image. http://www.squeakvm.org/unix/release/Squeak-4.0.3.2202-linux_i386.tar.gz Cheers, Laurent Laffont On Mon, Apr 12, 2010 at 11:40 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > On Apr 11, 2010, at 11:26 03PM, StÃ©phane Ducasse wrote: > > > Hi guys > > > > mariano, marcus and adrian got some push to get 1.0 out. I was just on > cc: > > I think that we made a mistake not to roll that publicly via the > mailing-list (we will do that for 1.1). > > Now this is holidays time here, mariano is going to get married and > adrian just moved so no > > internet connection. > > Tomorrow I will sync with marcus to know if I can help to get this 1.0 > version out. > > If I remember the mails I saw, marcus was looking for the > > BitBltPluging binaries for the one click image on other platforms > than mac os. > > > > Stef > Hum, aren't they usually built as internal? > In that case, the only reason for including plugin binaries would be if > there's been bug fixes to it since the vm was shipped... > Which would probably mean you're providing a too old VM in the first place. > IIRC, On Windows, 3.11.8 / 4.0.2 would both include updated plugins, the > main difference being 4.0.2 providing support for old image segment loading, > but requiring in-image handling of quit events. > > Not sure about linux, since I don't use it. > Seems to be in a state of updating at the moment, with 5-6 commits over the > weekend, so might be worth waiting for. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 13, 2010

Re: [Pharo-project] fixing underscores in a trivial manner thanks to SmalllintChecker and Lukas!

by Chris Muller

> Sure, that's why we version code. So I have to hunt around prior versions in the SCR just to discover who *really* wrote some method and when? Or, when debugging something and suspecting a method indicating recently "changed", I dig around the SCR, only to discover, "oh, actually Dan Ingalls' method really didn't change since 1999 afterall, it was just the assignment operator in 2010." Invalid accounting info all over the image. Sheesh, what a shame.. >> Just a friendly reminder that the FixUnderscores package is available >> to do this with preservation.. > > It's broken, it only works 90%. I've been using it for years with no problem. What do you mean "broken?"

April 13, 2010

Re: [Pharo-project] About getting HashedCollection (another dream happening)

by Levente Uzonyi

On Tue, 13 Apr 2010, Chris Muller wrote: > Peter mentioned VA, whose Set's swallow nil's. Perhaps that's the missing link in the communication here. Igor is talking about *Squeak*, which does not swallow nil's, it throws an error. So, to "fix consequences instead of causes" in the case of Squeak, the software would have to be doing something like: [ #(1 2 3 nil) asSet ] on: Error do: [ : err | "ignore it!" ] which, deserves to break if it exists at all.. Squeak doesn't raise an error, but adds nil to the set (since 4.1), so there's no need for such tricks. If you want to ignore nils, just #reject: or #remove: them. Levente On Mon, Apr 12, 2010 at 10:33 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > igor > > peter snippets was just a dull example. Peter mentioned that some people fix consequences instead of causes.... > > > Stef > _______________________________________________ > 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

April 13, 2010