* New Ada binding to OpenGL @ 2002-12-28 6:32 David Holm 2002-12-30 20:50 ` Joachim Schr�er 2002-12-30 20:54 ` Joachim Schr�er 0 siblings, 2 replies; 14+ messages in thread From: David Holm @ 2002-12-28 6:32 UTC (permalink / raw) Hi, as the original binding to OpenGL seems to be pretty dead (the only places to find it is in AdaSDL and GtkAda) I started a new project. My bindings are not based on the old ones. The current version is based on MesaLib 5.0. At the moment there are only thin bindings but the idea is to implement a thick binding as soon as the thin one works as it should. The binding is located here: http://adaopengl.sourceforge.net/ As I'm going away today and won't have much computer access until wednesday/thursday I released a preview version (0.1). Please look through it and send constructive feedback to me. Also check the Readme before mailing me as it contains some implementation notes I scribbled down. //David Holm ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New Ada binding to OpenGL 2002-12-28 6:32 New Ada binding to OpenGL David Holm @ 2002-12-30 20:50 ` Joachim Schr�er 2002-12-30 21:45 ` David Holm ` (2 more replies) 2002-12-30 20:54 ` Joachim Schr�er 1 sibling, 3 replies; 14+ messages in thread From: Joachim Schr�er @ 2002-12-30 20:50 UTC (permalink / raw) Hello, first of all it's good to see that I'm not the only one left doing Ada and OpenGL (also see my pretty old page www.adapower.com/schroer ). A few remarks concerning your binding: 1) For writing plattform independend OpenGL applications besides GL and GLU a binding to GLUT should be included. 2) I would prefer not to call the main package Opengl but instead use a name more related to the original C headers like gl or gl_h. (A personal reason: All my OpenGL applications and classes are in children of a package called Opengl. There then are children like with Win32.Gl; package Opengl.Gl renames Win32.GL; 3) Generally I would not add anything to the binding or alter the binding generator output more than necessary. It is a thin binding and should represent the original C binding as far as possible (so you can use the C based literature). The only requirements: The binding should work and be platform independed (see remarks below). 4) The subprograms taking system.address parameters are superfluous and represent a not very Adalike style. It is very staightforward to call a function with access parameter mode or with a general access type. Simply declare arrays of aliased variables and pass The_Array(The_Array'First)'Unchecked_Access. Take the following example to call procedure glClipPlane(plane : GLENUM; equation: access GLDOUBLE); -- ./GL/gl.h:791 package Opengl.Clip_Planes is -- Plane coefficients ----------------------------------------------- A : constant := 1; B : constant := 2; C : constant := 3; D : constant := 4; -- Plane-type and simple clip-plane constants ----------------------- type Plane is array(A .. D) of aliased Gl.Gldouble; ... and then in the implementation procedure Enable(The_Plane : in Plane) is begin Counter := Counter + 1; if Counter <= Clip_Plane_Indices'Last then Gl.Glclipplane(Plane => Clip_Plane_Indices(Counter), Equation => The_Plane(A)'Unchecked_Access); Gl.Glenable(Clip_Plane_Indices(Counter)); ... 5) It's very important to use pure constants for all the integer values as you did. I saw bindings using typed constants, often of type glenum. As in Win32 a lot of these types are derived from types in package win32 I expect problems when now porting from Windows to Linux. 6) A question: Are there problems expected using this binding when running OpenGL without Mesa being installed say on windows using the old dlls and archives OpenGL32.dll / Glu32.dll / Glut32.dll, libOpenGL32.a / libGlu32.a / libGlut32.a. Will my application link and run with headers for OpenGL 1.2 or newer with underlying binary libs for OpenGL 1.1? (Of course the application does only use 1.1 features). I could try but maybe someone knows... Best regards Joachim Schroer "David Holm" <david@realityrift.com> schrieb im Newsbeitrag news:dAbP9.3047$FF4.185223@newsb.telia.net... > Hi, > as the original binding to OpenGL seems to be pretty dead (the only places > to find it is in AdaSDL and GtkAda) I started a new project. > My bindings are not based on the old ones. The current version is based on > MesaLib 5.0. > At the moment there are only thin bindings but the idea is to implement a > thick binding as soon as the thin one works as it should. > > The binding is located here: > http://adaopengl.sourceforge.net/ > > As I'm going away today and won't have much computer access until > wednesday/thursday I released a preview version (0.1). Please look through > it and send constructive feedback to me. Also check the Readme before > mailing me as it contains some implementation notes I scribbled down. > > //David Holm ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New Ada binding to OpenGL 2002-12-30 20:50 ` Joachim Schr�er @ 2002-12-30 21:45 ` David Holm 2003-01-08 20:20 ` Brian Gaffney 2002-12-30 22:51 ` David Holm 2003-01-03 21:57 ` Bobby D. Bryant 2 siblings, 1 reply; 14+ messages in thread From: David Holm @ 2002-12-30 21:45 UTC (permalink / raw) Hi, thanks for the great feedback. Joachim Schr�er wrote: > Hello, > > first of all it's good to see that I'm not the only one left doing Ada and > OpenGL > (also see my pretty old page www.adapower.com/schroer ). > A few remarks concerning your binding: > > 1) For writing plattform independend OpenGL applications besides GL and > GLU a binding to GLUT should be included. The idea was to include a GLUT binding with the first release but it slipped my mind. I was never a big fan of GLUT but I'm changing my mind on that point. I will get on it right away. > 2) I would prefer not to call the main package Opengl but instead use a > name more related to the original C headers like gl or gl_h. > (A personal reason: All my OpenGL applications and classes are in children > of a package called Opengl. There then are children like > with Win32.Gl; package Opengl.Gl renames Win32.GL; I had a tough time deciding here. gl_h was used by the old OpenGL binding and I wanted both that one and mine to be able to coexist. Most, if not all, Ada packages have longer names such as Ada.Text_IO, System.Address and so on, so I didn't like using the very short "gl" name. I'm still not sure what to do here, OpenGL seemed to be the most Ada-ish. I'm calling the thick(er) binding AdaGL, which I'm working on. > 3) Generally I would not add anything to the binding or alter the binding > generator output more than necessary. It is a thin binding and should > represent the original C binding as far as possible (so you can use the C > based literature). The only requirements: The binding should work and be > platform independed (see remarks below). I totally agree. > 4) The subprograms taking system.address parameters are superfluous and > represent a not very Adalike style. It is very staightforward to call a > function with access parameter mode or with a general access type. Simply > declare arrays of aliased variables and pass > The_Array(The_Array'First)'Unchecked_Access. Take the following example to > call > procedure glClipPlane(plane : GLENUM; > > equation: access GLDOUBLE); -- > ./GL/gl.h:791 > > > > package Opengl.Clip_Planes is > > -- Plane coefficients ----------------------------------------------- > > > A : constant := 1; B : constant := 2; C : constant := 3; D : constant := > 4; > > -- Plane-type and simple clip-plane constants ----------------------- > > type Plane is array(A .. D) of aliased Gl.Gldouble; > > ... > > > and then in the implementation > > procedure Enable(The_Plane : in Plane) is > > begin > > Counter := Counter + 1; > > if Counter <= Clip_Plane_Indices'Last then > > Gl.Glclipplane(Plane => Clip_Plane_Indices(Counter), > > Equation => The_Plane(A)'Unchecked_Access); > > Gl.Glenable(Clip_Plane_Indices(Counter)); > > ... Thank you, this is very helpful to me. I had no idea how to solve this issue and then I found some post somewhere that mentioned using System.Address, the reply to that post was that it was not a very good idea but I couldn't find an alternate solution. I've been looking for a guide or something on creating bindings from C code that would discuss issues like this one but never found any so I ended up with groups.google.com and alot of guesswork. Will look at this right after the GLUT binding =). > 5) It's very important to use pure constants for all the integer values as > you did. I saw bindings using typed constants, often of type glenum. As in > Win32 a lot of these types are derived from types in package win32 I > expect problems when now porting from Windows to Linux. Yeah, I've noticed this myself. In this case cbind selected the correct type automatically though ;). > 6) A question: Are there problems expected using this binding when running > OpenGL without Mesa being installed say on windows using the old dlls and > archives OpenGL32.dll / Glu32.dll / Glut32.dll, libOpenGL32.a / > libGlu32.a / libGlut32.a. I hope not, I'm not using windows though so I can't be sure. Continued below... > Will my application link and run with headers for OpenGL 1.2 or newer > with underlying binary libs for OpenGL 1.1? (Of course the application > does only use 1.1 features). I could try but maybe someone knows... I was hoping that the symbols specified by the pragmas would only be expanded if you include them in your application. This might be compiler specific but it seems the logical way to do it. In which case it should work with OpenGL 1.1 to 1.4 and non-Mesa libraries. Thanks again for the feedback //David Holm > Best regards > Joachim Schroer > > "David Holm" <david@realityrift.com> schrieb im Newsbeitrag > news:dAbP9.3047$FF4.185223@newsb.telia.net... >> Hi, >> as the original binding to OpenGL seems to be pretty dead (the only >> places to find it is in AdaSDL and GtkAda) I started a new project. >> My bindings are not based on the old ones. The current version is based >> on MesaLib 5.0. >> At the moment there are only thin bindings but the idea is to implement a >> thick binding as soon as the thin one works as it should. >> >> The binding is located here: >> http://adaopengl.sourceforge.net/ >> >> >> //David Holm ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New Ada binding to OpenGL 2002-12-30 21:45 ` David Holm @ 2003-01-08 20:20 ` Brian Gaffney 2003-01-08 23:47 ` David Holm 0 siblings, 1 reply; 14+ messages in thread From: Brian Gaffney @ 2003-01-08 20:20 UTC (permalink / raw) David Holm <david@realityrift.com> wrote in message news:<N73Q9.3354$FF4.203172@newsb.telia.net>... > Hi, > thanks for the great feedback. > > Joachim Schr�er wrote: . . . > > 2) I would prefer not to call the main package Opengl but instead use a > > name more related to the original C headers like gl or gl_h. > > (A personal reason: All my OpenGL applications and classes are in children > > of a package called Opengl. There then are children like > > with Win32.Gl; package Opengl.Gl renames Win32.GL; > > I had a tough time deciding here. gl_h was used by the old OpenGL binding > and I wanted both that one and mine to be able to coexist. > Most, if not all, Ada packages have longer names such as Ada.Text_IO, > System.Address and so on, so I didn't like using the very short "gl" name. > I'm still not sure what to do here, OpenGL seemed to be the most Ada-ish. > I'm calling the thick(er) binding AdaGL, which I'm working on. > David, Since in your original post you stated: > >> The binding is located here: > >> http://adaopengl.sourceforge.net/ I take it your project name is AdaOpenGL. This seems like a good candidate for a main package name. It would allow people to identify your project from the package, the package from your project, and would help reduce namespace conflicts (at least for people who know of your project). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New Ada binding to OpenGL 2003-01-08 20:20 ` Brian Gaffney @ 2003-01-08 23:47 ` David Holm 2003-01-09 9:55 ` Bobby D. Bryant 0 siblings, 1 reply; 14+ messages in thread From: David Holm @ 2003-01-08 23:47 UTC (permalink / raw) On 8 Jan 2003 12:20:22 -0800 Brian.Gaffney@myrealbox.com (Brian Gaffney) wrote: > David Holm <david@realityrift.com> wrote in message > news:<N73Q9.3354$FF4.203172@newsb.telia.net>... > David, > Since in your original post you stated: > > >> The binding is located here: > > >> http://adaopengl.sourceforge.net/ > I take it your project name is AdaOpenGL. This seems like a good > candidate for a main package name. It would allow people to identify > your project from the package, the package from your project, and > would help reduce namespace conflicts (at least for people who know of > your project). Yeah, I guess. I have a thin binding and I'm working on a thick binding. Which one should I call AdaOpenGL and what should I call the other? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New Ada binding to OpenGL 2003-01-08 23:47 ` David Holm @ 2003-01-09 9:55 ` Bobby D. Bryant 2003-01-10 18:33 ` Brian Gaffney 0 siblings, 1 reply; 14+ messages in thread From: Bobby D. Bryant @ 2003-01-09 9:55 UTC (permalink / raw) On Wed, 08 Jan 2003 23:47:25 +0000, David Holm wrote: > On 8 Jan 2003 12:20:22 -0800 > Brian.Gaffney@myrealbox.com (Brian Gaffney) wrote: >> I take it your project name is AdaOpenGL. This seems like a good >> candidate for a main package name. It would allow people to identify >> your project from the package, the package from your project, and would >> help reduce namespace conflicts (at least for people who know of your >> project). > > Yeah, I guess. > I have a thin binding and I'm working on a thick binding. Which one > should I call AdaOpenGL and what should I call the other? When it's done the thick binding is what most people will use, so IMO that's the one that should have the most straightforward name -- presumably AdaOpenGL. Or actually, I'd like to see that as the name of the _kit_. The actual package name should simply be OpenGL, so that people's source code could refer to - with OpenGL.Whatever; There's no reason to import the identifier "Ada" into the Ada namespace. Or better yet, simply GL, GLU, GLX, etc., - with GLX; ... GLX.Choose_Visual( blah-de-blah); ... Again, take your cue for what the fine folk did with GtkAda. The name of the _product_ is "GtkAda", but the names of the Ada _packages_ are Glib, GDK, GTK, etc. They do have a package called GtkAda, but that's to identify stuff that's actually new with GtkAda rather than bindings of the GTK+ stuff. -- Bobby Bryant Austin, Texas ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New Ada binding to OpenGL 2003-01-09 9:55 ` Bobby D. Bryant @ 2003-01-10 18:33 ` Brian Gaffney 0 siblings, 0 replies; 14+ messages in thread From: Brian Gaffney @ 2003-01-10 18:33 UTC (permalink / raw) "Bobby D. Bryant" <bdbryant@mail.utexas.edu> wrote in message news:<pan.2003.01.09.09.55.17.192487@mail.utexas.edu>... > On Wed, 08 Jan 2003 23:47:25 +0000, David Holm wrote: > > > On 8 Jan 2003 12:20:22 -0800 > > Brian.Gaffney@myrealbox.com (Brian Gaffney) wrote: > > >> I take it your project name is AdaOpenGL. This seems like a good > >> candidate for a main package name. It would allow people to identify > >> your project from the package, the package from your project, and would > >> help reduce namespace conflicts (at least for people who know of your > >> project). > > > > Yeah, I guess. > > I have a thin binding and I'm working on a thick binding. Which one > > should I call AdaOpenGL and what should I call the other? > > When it's done the thick binding is what most people will use, so IMO > that's the one that should have the most straightforward name -- > presumably AdaOpenGL. I was going to say I like the previously posted idea of AdaGL for the thick binding, but thinking about it I would prefer if they were kept together, so users know they're related. I'd suggest AdaOpenGL.* for the thick binding and AdaOpenGL.OpenGL.* for the thin (or maybe AdaOpenGL.Thin, but I think that's ugly). Users could use 'use' to simplify the references to shorter package names. > > Or actually, I'd like to see that as the name of the _kit_. The actual > package name should simply be OpenGL, so that people's source code could > refer to - > > with OpenGL.Whatever; > > There's no reason to import the identifier "Ada" into the Ada namespace. That's exactly the problem that was originally brought up: everybody with an OpenGL binding would do this. I don't like this, since it would only make sense if (1) there were only one binding to OpenGL, or (2) all bindings to OpenGL used the same specification. Otherwise there's no benefit to calling them all the same thing, and it gets very confusing (Which OpenGL library did the author mean? How do I use different OpenGL libraries on one computer?) > > Or better yet, simply GL, GLU, GLX, etc., - > > with GLX; > ... > GLX.Choose_Visual( blah-de-blah); > ... > I like this even less, since (unless I know something about AdaOpenGL, or OpenGL in general) I have no way of knowing that GL, GLU, and GLX are related (without looking into their files). This, to me, defeats one of the major benefits of hierachical package names. We might as well be programming in C:-) > Again, take your cue for what the fine folk did with GtkAda. The name of > the _product_ is "GtkAda", but the names of the Ada _packages_ are Glib, > GDK, GTK, etc. Again, how do I know these packages are related? Without looking into the source, how do I know Glib is related to GTK/GDK and not related to GL/GLU/GLX or something else? I can see benefits to the library (binding) creator in doing this, especially if the (original) library is evolving. However, I think it impedes code readablility, especially if more than one such library is involved. > > They do have a package called GtkAda, but that's to identify stuff that's > actually new with GtkAda rather than bindings of the GTK+ stuff. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New Ada binding to OpenGL 2002-12-30 20:50 ` Joachim Schr�er 2002-12-30 21:45 ` David Holm @ 2002-12-30 22:51 ` David Holm 2003-01-03 18:38 ` Joachim Schr�er 2003-01-03 21:57 ` Bobby D. Bryant 2 siblings, 1 reply; 14+ messages in thread From: David Holm @ 2002-12-30 22:51 UTC (permalink / raw) Joachim Schr�er wrote: > 4) The subprograms taking system.address parameters are superfluous and > represent a not very Adalike style. It is very staightforward to call a > function with access parameter mode or with a general access type. Simply > declare arrays of aliased variables and pass > The_Array(The_Array'First)'Unchecked_Access. Take the following example to > call > procedure glClipPlane(plane : GLENUM; > > equation: access GLDOUBLE); -- > ./GL/gl.h:791 > > > > package Opengl.Clip_Planes is > > -- Plane coefficients ----------------------------------------------- > > > A : constant := 1; B : constant := 2; C : constant := 3; D : constant := > 4; > > -- Plane-type and simple clip-plane constants ----------------------- > > type Plane is array(A .. D) of aliased Gl.Gldouble; > > ... > > > and then in the implementation > > procedure Enable(The_Plane : in Plane) is > > begin > > Counter := Counter + 1; > > if Counter <= Clip_Plane_Indices'Last then > > Gl.Glclipplane(Plane => Clip_Plane_Indices(Counter), > > Equation => The_Plane(A)'Unchecked_Access); > > Gl.Glenable(Clip_Plane_Indices(Counter)); > > ... > How can I pass null addresses this way? With System.Address I could use GLNULL : System.Address renames System.Null_Address; //David ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New Ada binding to OpenGL 2002-12-30 22:51 ` David Holm @ 2003-01-03 18:38 ` Joachim Schr�er 2003-01-03 23:56 ` David Holm 0 siblings, 1 reply; 14+ messages in thread From: Joachim Schr�er @ 2003-01-03 18:38 UTC (permalink / raw) Hello, to pass null simply write something like Gl.Glclipplane(Plane => 1, Equation => null); But why do you want to pass null access values. I expect some kind of error in the C code then. I will have a look for books were Ada/C coding is documented. I thing, the Ada95 rationale is a good reference. I will give you links later. J. Schr�er "David Holm" <david@realityrift.com> schrieb im Newsbeitrag news:V54Q9.3365$FF4.203703@newsb.telia.net... > Joachim Schr�er wrote: > > > 4) The subprograms taking system.address parameters are superfluous and > > represent a not very Adalike style. It is very staightforward to call a > > function with access parameter mode or with a general access type. Simply > > declare arrays of aliased variables and pass > > The_Array(The_Array'First)'Unchecked_Access. Take the following example to > > call > > procedure glClipPlane(plane : GLENUM; > > > > equation: access GLDOUBLE); -- > > ./GL/gl.h:791 > > > > > > > > package Opengl.Clip_Planes is > > > > -- Plane coefficients ----------------------------------------------- > > > > > > A : constant := 1; B : constant := 2; C : constant := 3; D : constant := > > 4; > > > > -- Plane-type and simple clip-plane constants ----------------------- > > > > type Plane is array(A .. D) of aliased Gl.Gldouble; > > > > ... > > > > > > and then in the implementation > > > > procedure Enable(The_Plane : in Plane) is > > > > begin > > > > Counter := Counter + 1; > > > > if Counter <= Clip_Plane_Indices'Last then > > > > Gl.Glclipplane(Plane => Clip_Plane_Indices(Counter), > > > > Equation => The_Plane(A)'Unchecked_Access); > > > > Gl.Glenable(Clip_Plane_Indices(Counter)); > > > > ... > > > > How can I pass null addresses this way? With System.Address I could use > GLNULL : System.Address renames System.Null_Address; > > //David ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New Ada binding to OpenGL 2003-01-03 18:38 ` Joachim Schr�er @ 2003-01-03 23:56 ` David Holm [not found] ` <67HR9.4217$gv.98715@newsfep1-gui.server.ntli.net> 0 siblings, 1 reply; 14+ messages in thread From: David Holm @ 2003-01-03 23:56 UTC (permalink / raw) Joachim Schr�er wrote: > Hello, > > to pass null simply write something like > Gl.Glclipplane(Plane => 1, Equation => null); > > But why do you want to pass null access values. > > I expect some kind of error in the C code then. > > I will have a look for books were Ada/C coding is documented. > > I thing, the Ada95 rationale is a good reference. I will give you links > later. > > J. Schr�er > Yeah, you were correct. I got errors in the C code. The thing is that for instance, glXCreateContext takes a C NULL pointer when you want to create a new context that is not a subcontext to an existing one. I have not yet managed to find a solution to how to handle this in Ada as I get a segfault in libGL when I do it (which is odd since I have a C application that passes a C-NULL here without any problems). In this case I had an overloaded function which took System.Address, so I never passed a null through an access variable. I found the rationale on www.adahome.org, so no need to send a link. //David Holm ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <67HR9.4217$gv.98715@newsfep1-gui.server.ntli.net>]
* Re: New Ada binding to OpenGL [not found] ` <67HR9.4217$gv.98715@newsfep1-gui.server.ntli.net> @ 2003-01-05 3:21 ` David Holm 0 siblings, 0 replies; 14+ messages in thread From: David Holm @ 2003-01-05 3:21 UTC (permalink / raw) chris.danx wrote: > > I've passed a C-null value to a c funtion from Ada using GNAT before, > just wish I could remember how. Surely someone else has done it too? > Did you try just "null", the ada word? > > There's also something about a C Null_Pointer in the Ref. Manual, > section B.3.1, which might be what your looking for, though I've not > used it and am not sure if that's its purpose. > It is working now. It turned out it wasn't the null at all but the function call above it that failed and returned a null, which I never detected. //David Holm ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New Ada binding to OpenGL 2002-12-30 20:50 ` Joachim Schr�er 2002-12-30 21:45 ` David Holm 2002-12-30 22:51 ` David Holm @ 2003-01-03 21:57 ` Bobby D. Bryant 2003-01-04 19:11 ` Joachim Schr�er 2 siblings, 1 reply; 14+ messages in thread From: Bobby D. Bryant @ 2003-01-03 21:57 UTC (permalink / raw) On Mon, 30 Dec 2002 21:50:20 +0100, Joachim Schr�er wrote: > 3) Generally I would not add anything to the binding or alter the > binding generator output more than necessary. It is a thin binding and > should represent the original C binding as far as possible (so you can > use the C based literature). The only requirements: The binding should > work and be platform independed (see remarks below). Some of us would greatly prefer thick bindings. IMO GtkAda is the paradigm for how this sort of thing should be done. Sure is a lot of work for something as big as GTK+ or OpenGL, though. Bobby Bryant Austin, Texas ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New Ada binding to OpenGL 2003-01-03 21:57 ` Bobby D. Bryant @ 2003-01-04 19:11 ` Joachim Schr�er 0 siblings, 0 replies; 14+ messages in thread From: Joachim Schr�er @ 2003-01-04 19:11 UTC (permalink / raw) Of course you need thick bindings. When writing greater applications you should encapsulate a lowlevel library like OpenGL by a general OO framework. (I've done somethink like this, see www.adapower.com/schroer , but that is not documented in detail.) What I meant is, the (generated) thin binding should be close to the original. What you build on top of it is another thing. J. Schr�er "Bobby D. Bryant" <bdbryant@mail.utexas.edu> schrieb im Newsbeitrag news:pan.2003.01.03.21.57.57.596399@mail.utexas.edu... > On Mon, 30 Dec 2002 21:50:20 +0100, Joachim Schr�er wrote: > > > 3) Generally I would not add anything to the binding or alter the > > binding generator output more than necessary. It is a thin binding and > > should represent the original C binding as far as possible (so you can > > use the C based literature). The only requirements: The binding should > > work and be platform independed (see remarks below). > > Some of us would greatly prefer thick bindings. IMO GtkAda is the > paradigm for how this sort of thing should be done. > > Sure is a lot of work for something as big as GTK+ or OpenGL, though. > > Bobby Bryant > Austin, Texas ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New Ada binding to OpenGL 2002-12-28 6:32 New Ada binding to OpenGL David Holm 2002-12-30 20:50 ` Joachim Schr�er @ 2002-12-30 20:54 ` Joachim Schr�er 1 sibling, 0 replies; 14+ messages in thread From: Joachim Schr�er @ 2002-12-30 20:54 UTC (permalink / raw) Hello, I forgot one thing: You should announce your work in the OpenGL newsgroup too: comp.graphics.api.opengl Joachim Schroer ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2003-01-10 18:33 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-12-28 6:32 New Ada binding to OpenGL David Holm 2002-12-30 20:50 ` Joachim Schr�er 2002-12-30 21:45 ` David Holm 2003-01-08 20:20 ` Brian Gaffney 2003-01-08 23:47 ` David Holm 2003-01-09 9:55 ` Bobby D. Bryant 2003-01-10 18:33 ` Brian Gaffney 2002-12-30 22:51 ` David Holm 2003-01-03 18:38 ` Joachim Schr�er 2003-01-03 23:56 ` David Holm [not found] ` <67HR9.4217$gv.98715@newsfep1-gui.server.ntli.net> 2003-01-05 3:21 ` David Holm 2003-01-03 21:57 ` Bobby D. Bryant 2003-01-04 19:11 ` Joachim Schr�er 2002-12-30 20:54 ` Joachim Schr�er
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox