* OpenGL in Ada @ 2010-07-08 2:42 Shark8 2010-07-08 14:15 ` John B. Matthews ` (4 more replies) 0 siblings, 5 replies; 24+ messages in thread From: Shark8 @ 2010-07-08 2:42 UTC (permalink / raw) Hello everyone, I posted about wanting to write an OS in Ada a while ago and, as part of that effort I've taken to translating the OpenGL API. No, I don't mean JUST running the headers through ato-Ada converter but actually translating the API into a more Ada-natural form. As an example, here is the glColor-'family' of functions: * WINGDIAPI void APIENTRY glColor3b (GLbyte red, GLbyte green, GLbyte blue); * WINGDIAPI void APIENTRY glColor3bv (const GLbyte *v); * WINGDIAPI void APIENTRY glColor3d (GLdouble red, GLdouble green, GLdouble blue); * WINGDIAPI void APIENTRY glColor3dv (const GLdouble *v); * WINGDIAPI void APIENTRY glColor3f (GLfloat red, GLfloat green, GLfloat blue); * WINGDIAPI void APIENTRY glColor3fv (const GLfloat *v); * WINGDIAPI void APIENTRY glColor3i (GLint red, GLint green, GLint blue); * WINGDIAPI void APIENTRY glColor3iv (const GLint *v); * WINGDIAPI void APIENTRY glColor3s (GLshort red, GLshort green, GLshort blue); * WINGDIAPI void APIENTRY glColor3sv (const GLshort *v); * WINGDIAPI void APIENTRY glColor3ub (GLubyte red, GLubyte green, GLubyte blue); * WINGDIAPI void APIENTRY glColor3ubv (const GLubyte *v); * WINGDIAPI void APIENTRY glColor3ui (GLuint red, GLuint green, GLuint blue); * WINGDIAPI void APIENTRY glColor3uiv (const GLuint *v); * WINGDIAPI void APIENTRY glColor3us (GLushort red, GLushort green, GLushort blue); * WINGDIAPI void APIENTRY glColor3usv (const GLushort *v); * WINGDIAPI void APIENTRY glColor4b (GLbyte red, GLbyte green, GLbyte blue, GLbyte alpha); * WINGDIAPI void APIENTRY glColor4bv (const GLbyte *v); * WINGDIAPI void APIENTRY glColor4d (GLdouble red, GLdouble green, GLdouble blue, GLdouble alpha); * WINGDIAPI void APIENTRY glColor4dv (const GLdouble *v); * WINGDIAPI void APIENTRY glColor4f (GLfloat red, GLfloat green, GLfloat blue, GLfloat alpha); * WINGDIAPI void APIENTRY glColor4fv (const GLfloat *v); * WINGDIAPI void APIENTRY glColor4i (GLint red, GLint green, GLint blue, GLint alpha); * WINGDIAPI void APIENTRY glColor4iv (const GLint *v); * WINGDIAPI void APIENTRY glColor4s (GLshort red, GLshort green, GLshort blue, GLshort alpha); * WINGDIAPI void APIENTRY glColor4sv (const GLshort *v); * WINGDIAPI void APIENTRY glColor4ub (GLubyte red, GLubyte green, GLubyte blue, GLubyte alpha); * WINGDIAPI void APIENTRY glColor4ubv (const GLubyte *v); * WINGDIAPI void APIENTRY glColor4ui (GLuint red, GLuint green, GLuint blue, GLuint alpha); * WINGDIAPI void APIENTRY glColor4uiv (const GLuint *v); * WINGDIAPI void APIENTRY glColor4us (GLushort red, GLushort green, GLushort blue, GLushort alpha); * WINGDIAPI void APIENTRY glColor4usv (const GLushort *v); which was rewritten as: -- Color Formats Procedure Color ( red, green, blue : in Byte ); Procedure Color ( v : RGB_Byte_Vector ); Procedure Color ( red, green, blue : in double ); Procedure Color ( v : RGB_Double_Vector ); Procedure Color ( red, green, blue : in float ); Procedure Color ( V : RGB_Float_Vector ); Procedure Color ( red, green, blue : int ); Procedure Color ( V : RGB_Integer_Vector ); Procedure Color ( red, green, blue : Short ); Procedure Color ( V : RGB_Short_Vector ); Procedure Color ( red, green, blue : Unsigned_Byte ); Procedure Color ( v : RGB_Unsigned_Byte_Vector ); Procedure Color ( red, green, blue : in Unsigned_Integer ); Procedure Color ( v : RGB_Unsigned_Integer_Vector ); Procedure Color ( red, green, blue : in Unsigned_Short ); Procedure Color ( v : RGB_Unsigned_Short_Vector ); Procedure Color ( red, green, blue, alpha : in byte ); Procedure Color ( v: RGBA_Byte_Vector ); Procedure Color ( red, green, blue, alpha : in double ); Procedure Color ( v : RGBA_Double_Vector ); Procedure Color ( red, green, blue, alpha : in float ); Procedure Color ( v: RGBA_Float_Vector ); Procedure Color ( red, green, blue, alpha : in int ); Procedure Color ( v: RGBA_Integer_Vector ); Procedure Color ( red, green, blue, alpha : in short ); Procedure Color ( v: RGBA_Short_Vector ); Procedure Color ( red, green, blue, alpha : in Unsigned_Byte ); Procedure Color ( v: RGBA_Unsigned_Byte_Vector ); Procedure Color ( red, green, blue, alpha : in Unsigned_Integer ); Procedure Color ( v: RGBA_Unsigned_Integer_Vector ); Procedure Color ( red, green, blue, alpha : in Unsigned_Short ); Procedure Color ( v: RGBA_Unsigned_Short_Vector ); where X_Y_Vector is an array of elements of type Y and indexed on type X. Another thing that I've done is, to the best of my ability, used Ada's strong typing to make passing invalid parameters less of a problem; for example: Type Begin_Mode_Type is ( POINTS, LINES, LINE_LOOP, LINE_STRIP, TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN, QUADS, QUAD_STRIP, POLYGON ); For Begin_Mode_Type use ( POINTS => GL_POINTS, LINES => GL_LINES, LINE_LOOP => GL_LINE_LOOP, LINE_STRIP => GL_LINE_STRIP, TRIANGLES => GL_TRIANGLES, TRIANGLE_STRIP => GL_TRIANGLE_STRIP, TRIANGLE_FAN => GL_TRIANGLE_FAN, QUADS => GL_QUADS, QUAD_STRIP => GL_QUAD_STRIP, POLYGON => GL_POLYGON ); is a type for the glBegin-wrapper which only allows the passing of valid "mode"-parameters. {That is, range points..polygon.} My questions are these: Would anyone, other than myself, find such a translation of interest? and When I finish, would anyone want to test it out? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-08 2:42 OpenGL in Ada Shark8 @ 2010-07-08 14:15 ` John B. Matthews 2010-07-09 2:18 ` anon 2010-07-12 16:51 ` Warren 2010-07-09 11:43 ` Gautier write-only ` (3 subsequent siblings) 4 siblings, 2 replies; 24+ messages in thread From: John B. Matthews @ 2010-07-08 14:15 UTC (permalink / raw) In article <68dd0333-f502-4351-9e50-4ec83bddc44e@k39g2000yqd.googlegroups.com>, Shark8 <onewingedshark@gmail.com> wrote: > Would anyone, other than myself, find such a translation of interest? I have used AdaOpenGL in the past. Is your project related in any way? <http://adaopengl.sourceforge.net/> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews> ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-08 14:15 ` John B. Matthews @ 2010-07-09 2:18 ` anon 2010-07-12 16:51 ` Warren 1 sibling, 0 replies; 24+ messages in thread From: anon @ 2010-07-09 2:18 UTC (permalink / raw) In <nospam-8BBB96.10151708072010@news.aioe.org>, "John B. Matthews" <nospam@nospam.invalid> writes: >In article ><68dd0333-f502-4351-9e50-4ec83bddc44e@k39g2000yqd.googlegroups.com>, > Shark8 <onewingedshark@gmail.com> wrote: > >> Would anyone, other than myself, find such a translation of interest? > >I have used AdaOpenGL in the past. Is your project related in any way? > ><http://adaopengl.sourceforge.net/> > >-- >John B. Matthews >trashgod at gmail dot com ><http://sites.google.com/site/drjohnbmatthews> But the last time I downloaded the packages they needed a few modifications for the current GNAT and OpenGL standards that I was using. but it was no problem. And with these APIs packages all you would need to do is replace the openGL libraries calls with the actual routines. Have fun! Let us know when it ready for testing! ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-08 14:15 ` John B. Matthews 2010-07-09 2:18 ` anon @ 2010-07-12 16:51 ` Warren 2010-07-13 12:26 ` Ludovic Brenta 1 sibling, 1 reply; 24+ messages in thread From: Warren @ 2010-07-12 16:51 UTC (permalink / raw) John B. Matthews expounded in news:nospam-8BBB96.10151708072010 @news.aioe.org: > In article > <68dd0333-f502-4351-9e50-4ec83bddc44e@k39g2000yqd.googlegroups.com>, > Shark8 <onewingedshark@gmail.com> wrote: > >> Would anyone, other than myself, find such a translation of interest? > > I have used AdaOpenGL in the past. Is your project related in any way? > > <http://adaopengl.sourceforge.net/> There is the SDL project: http://www.libsdl.org/libraries.php available for portable game writing. Something like that in Ada form would be very useful. This is a big project, to be sure, but Ada tasking and games seem like a natural fit to me. I'd be interested in developing some games with this kind of framework. Warren ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-12 16:51 ` Warren @ 2010-07-13 12:26 ` Ludovic Brenta 2010-07-13 13:13 ` Warren 0 siblings, 1 reply; 24+ messages in thread From: Ludovic Brenta @ 2010-07-13 12:26 UTC (permalink / raw) Warren wrote on comp.lang.ada: > There is the SDL project:http://www.libsdl.org/libraries.php > available for portable game writing. Something like that in > Ada form would be very useful. This is a big project, to be > sure, but Ada tasking and games seem like a natural fit > to me. I'd be interested in developing some games with this > kind of framework. There exists an Ada binding: http://sourceforge.net/projects/adasdl/ Several years ago I started rewroting Defendguin in Ada with this binding, see http://green.ada-france.org:8081/branch/changes/org.ludovic-brenta.defendguin IIUC, it is possible to do OpenGL from within, or in conjunction with, SDL, as most OpenGL games I know of also use SDL. I never tried. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-13 12:26 ` Ludovic Brenta @ 2010-07-13 13:13 ` Warren 0 siblings, 0 replies; 24+ messages in thread From: Warren @ 2010-07-13 13:13 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1025 bytes --] Ludovic Brenta expounded in news:b3788036-725e-4462-8389-e7a9ca52b6a7@g19g2000yqc.googlegroups.com: > Warren wrote on comp.lang.ada: >> There is the SDL project:http://www.libsdl.org/libraries.php >> available for portable game writing. �Something like that in >> Ada form would be very useful. This is a big project, to be >> sure, but Ada tasking and games seem like a natural fit >> to me. I'd be interested in developing some games with this >> kind of framework. > > There exists an Ada binding: http://sourceforge.net/projects/adasdl/ Well that is cool. Thanks for the pointer. > Several years ago I started rewroting Defendguin in Ada with this > binding, see > > http://green.ada-france.org:8081/branch/changes/org.ludovic-brenta.defe > ndguin > > IIUC, it is possible to do OpenGL from within, or in conjunction with, > SDL, as most OpenGL games I know of also use SDL. I never tried. I'll definitely have to check that out. Now if I can only get my current project workload out of the way. ;-) Warren ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-08 2:42 OpenGL in Ada Shark8 2010-07-08 14:15 ` John B. Matthews @ 2010-07-09 11:43 ` Gautier write-only 2010-07-09 15:11 ` Gene ` (2 subsequent siblings) 4 siblings, 0 replies; 24+ messages in thread From: Gautier write-only @ 2010-07-09 11:43 UTC (permalink / raw) On Jul 7, 10:42 pm, Shark8 <onewingedsh...@gmail.com> wrote: > Hello everyone, > I posted about wanting to write an OS in Ada a while ago and, as part > of that effort I've taken to translating the OpenGL API. No, I don't > mean JUST running the headers through ato-Ada converter but actually > translating the API into a more Ada-natural form. ... > My questions are these: > Would anyone, other than myself, find such a translation of interest? > and > When I finish, would anyone want to test it out? You may save lots of work by looking at the GL bindings there http://globe3d.sf.net which are also Ada-ized (overloaded names, all useless gl* and GL_* stripped) Have fun, Gautier ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-08 2:42 OpenGL in Ada Shark8 2010-07-08 14:15 ` John B. Matthews 2010-07-09 11:43 ` Gautier write-only @ 2010-07-09 15:11 ` Gene 2010-07-09 17:38 ` Shark8 2015-01-15 7:11 ` OpenGL in Ada #2 JillRivas 2015-01-30 14:45 ` OpenGL in Ada Lucretia 4 siblings, 1 reply; 24+ messages in thread From: Gene @ 2010-07-09 15:11 UTC (permalink / raw) On Jul 7, 10:42 pm, Shark8 <onewingedsh...@gmail.com> wrote: > Hello everyone, > I posted about wanting to write an OS in Ada a while ago and, as part > of that effort I've taken to translating the OpenGL API. No, I don't > mean JUST running the headers through ato-Ada converter but actually > translating the API into a more Ada-natural form. > > As an example, here is the glColor-'family' of functions: > * WINGDIAPI void APIENTRY glColor3b (GLbyte red, GLbyte green, > GLbyte blue); > * WINGDIAPI void APIENTRY glColor3bv (const GLbyte *v); > * WINGDIAPI void APIENTRY glColor3d (GLdouble red, GLdouble green, > GLdouble blue); > * WINGDIAPI void APIENTRY glColor3dv (const GLdouble *v); > * WINGDIAPI void APIENTRY glColor3f (GLfloat red, GLfloat green, > GLfloat blue); > * WINGDIAPI void APIENTRY glColor3fv (const GLfloat *v); > * WINGDIAPI void APIENTRY glColor3i (GLint red, GLint green, GLint > blue); > * WINGDIAPI void APIENTRY glColor3iv (const GLint *v); > * WINGDIAPI void APIENTRY glColor3s (GLshort red, GLshort green, > GLshort blue); > * WINGDIAPI void APIENTRY glColor3sv (const GLshort *v); > * WINGDIAPI void APIENTRY glColor3ub (GLubyte red, GLubyte green, > GLubyte blue); > * WINGDIAPI void APIENTRY glColor3ubv (const GLubyte *v); > * WINGDIAPI void APIENTRY glColor3ui (GLuint red, GLuint green, > GLuint blue); > * WINGDIAPI void APIENTRY glColor3uiv (const GLuint *v); > * WINGDIAPI void APIENTRY glColor3us (GLushort red, GLushort > green, GLushort blue); > * WINGDIAPI void APIENTRY glColor3usv (const GLushort *v); > * WINGDIAPI void APIENTRY glColor4b (GLbyte red, GLbyte green, > GLbyte blue, GLbyte alpha); > * WINGDIAPI void APIENTRY glColor4bv (const GLbyte *v); > * WINGDIAPI void APIENTRY glColor4d (GLdouble red, GLdouble green, > GLdouble blue, GLdouble alpha); > * WINGDIAPI void APIENTRY glColor4dv (const GLdouble *v); > * WINGDIAPI void APIENTRY glColor4f (GLfloat red, GLfloat green, > GLfloat blue, GLfloat alpha); > * WINGDIAPI void APIENTRY glColor4fv (const GLfloat *v); > * WINGDIAPI void APIENTRY glColor4i (GLint red, GLint green, GLint > blue, GLint alpha); > * WINGDIAPI void APIENTRY glColor4iv (const GLint *v); > * WINGDIAPI void APIENTRY glColor4s (GLshort red, GLshort green, > GLshort blue, GLshort alpha); > * WINGDIAPI void APIENTRY glColor4sv (const GLshort *v); > * WINGDIAPI void APIENTRY glColor4ub (GLubyte red, GLubyte green, > GLubyte blue, GLubyte alpha); > * WINGDIAPI void APIENTRY glColor4ubv (const GLubyte *v); > * WINGDIAPI void APIENTRY glColor4ui (GLuint red, GLuint green, > GLuint blue, GLuint alpha); > * WINGDIAPI void APIENTRY glColor4uiv (const GLuint *v); > * WINGDIAPI void APIENTRY glColor4us (GLushort red, GLushort > green, GLushort blue, GLushort alpha); > * WINGDIAPI void APIENTRY glColor4usv (const GLushort *v); > > which was rewritten as: > -- Color Formats > Procedure Color ( red, green, blue : in Byte ); > Procedure Color ( v : RGB_Byte_Vector ); > Procedure Color ( red, green, blue : in double ); > Procedure Color ( v : RGB_Double_Vector ); > Procedure Color ( red, green, blue : in float ); > Procedure Color ( V : RGB_Float_Vector ); > Procedure Color ( red, green, blue : int ); > Procedure Color ( V : RGB_Integer_Vector ); > Procedure Color ( red, green, blue : Short ); > Procedure Color ( V : RGB_Short_Vector ); > Procedure Color ( red, green, blue : Unsigned_Byte ); > Procedure Color ( v : RGB_Unsigned_Byte_Vector ); > Procedure Color ( red, green, blue : in Unsigned_Integer ); > Procedure Color ( v : RGB_Unsigned_Integer_Vector ); > Procedure Color ( red, green, blue : in Unsigned_Short ); > Procedure Color ( v : RGB_Unsigned_Short_Vector ); > Procedure Color ( red, green, blue, alpha : in byte ); > Procedure Color ( v: RGBA_Byte_Vector ); > Procedure Color ( red, green, blue, alpha : in double ); > Procedure Color ( v : RGBA_Double_Vector ); > Procedure Color ( red, green, blue, alpha : in float ); > Procedure Color ( v: RGBA_Float_Vector ); > Procedure Color ( red, green, blue, alpha : in int ); > Procedure Color ( v: RGBA_Integer_Vector ); > Procedure Color ( red, green, blue, alpha : in short ); > Procedure Color ( v: RGBA_Short_Vector ); > Procedure Color ( red, green, blue, alpha : in Unsigned_Byte ); > Procedure Color ( v: RGBA_Unsigned_Byte_Vector ); > Procedure Color ( red, green, blue, alpha : in Unsigned_Integer ); > Procedure Color ( v: RGBA_Unsigned_Integer_Vector ); > Procedure Color ( red, green, blue, alpha : in Unsigned_Short ); > Procedure Color ( v: RGBA_Unsigned_Short_Vector ); > > where X_Y_Vector is an array of elements of type Y and indexed on type > X. > > Another thing that I've done is, to the best of my ability, used Ada's > strong typing to make passing invalid parameters less of a problem; > for example: > Type Begin_Mode_Type is > ( POINTS, LINES, LINE_LOOP, LINE_STRIP, TRIANGLES, > TRIANGLE_STRIP, > TRIANGLE_FAN, QUADS, QUAD_STRIP, POLYGON > ); > > For Begin_Mode_Type use > ( POINTS => GL_POINTS, > LINES => GL_LINES, > LINE_LOOP => GL_LINE_LOOP, > LINE_STRIP => GL_LINE_STRIP, > TRIANGLES => GL_TRIANGLES, > TRIANGLE_STRIP => GL_TRIANGLE_STRIP, > TRIANGLE_FAN => GL_TRIANGLE_FAN, > QUADS => GL_QUADS, > QUAD_STRIP => GL_QUAD_STRIP, > POLYGON => GL_POLYGON > ); > > is a type for the glBegin-wrapper which only allows the passing of > valid "mode"-parameters. {That is, range points..polygon.} > > My questions are these: > Would anyone, other than myself, find such a translation of interest? > and > When I finish, would anyone want to test it out? Having done this a couple of times myself, you should consider the approach of writing a specialized program that processes the OpenGL header into a binding. OpenGL will remain a moving target as graphics hardware continues to evolve. Compilers will always have their unique quirks. With all this room for variation, it will probably be easier to maintain a translator than to revise the binding every time the standard changes or grows. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-09 15:11 ` Gene @ 2010-07-09 17:38 ` Shark8 2010-07-09 20:54 ` Gene 2010-07-10 4:00 ` BrianG 0 siblings, 2 replies; 24+ messages in thread From: Shark8 @ 2010-07-09 17:38 UTC (permalink / raw) On Jul 9, 9:11 am, Gene <gene.ress...@gmail.com> wrote: > On Jul 7, 10:42 pm, Shark8 <onewingedsh...@gmail.com> wrote: > > > > > Hello everyone, > > I posted about wanting to write an OS in Ada a while ago and, as part > > of that effort I've taken to translating the OpenGL API. No, I don't > > mean JUST running the headers through ato-Ada converter but actually > > translating the API into a more Ada-natural form. > > > As an example, here is the glColor-'family' of functions: > > * WINGDIAPI void APIENTRY glColor3b (GLbyte red, GLbyte green, > > GLbyte blue); > > * WINGDIAPI void APIENTRY glColor3bv (const GLbyte *v); > > * WINGDIAPI void APIENTRY glColor3d (GLdouble red, GLdouble green, > > GLdouble blue); > > * WINGDIAPI void APIENTRY glColor3dv (const GLdouble *v); > > * WINGDIAPI void APIENTRY glColor3f (GLfloat red, GLfloat green, > > GLfloat blue); > > * WINGDIAPI void APIENTRY glColor3fv (const GLfloat *v); > > * WINGDIAPI void APIENTRY glColor3i (GLint red, GLint green, GLint > > blue); > > * WINGDIAPI void APIENTRY glColor3iv (const GLint *v); > > * WINGDIAPI void APIENTRY glColor3s (GLshort red, GLshort green, > > GLshort blue); > > * WINGDIAPI void APIENTRY glColor3sv (const GLshort *v); > > * WINGDIAPI void APIENTRY glColor3ub (GLubyte red, GLubyte green, > > GLubyte blue); > > * WINGDIAPI void APIENTRY glColor3ubv (const GLubyte *v); > > * WINGDIAPI void APIENTRY glColor3ui (GLuint red, GLuint green, > > GLuint blue); > > * WINGDIAPI void APIENTRY glColor3uiv (const GLuint *v); > > * WINGDIAPI void APIENTRY glColor3us (GLushort red, GLushort > > green, GLushort blue); > > * WINGDIAPI void APIENTRY glColor3usv (const GLushort *v); > > * WINGDIAPI void APIENTRY glColor4b (GLbyte red, GLbyte green, > > GLbyte blue, GLbyte alpha); > > * WINGDIAPI void APIENTRY glColor4bv (const GLbyte *v); > > * WINGDIAPI void APIENTRY glColor4d (GLdouble red, GLdouble green, > > GLdouble blue, GLdouble alpha); > > * WINGDIAPI void APIENTRY glColor4dv (const GLdouble *v); > > * WINGDIAPI void APIENTRY glColor4f (GLfloat red, GLfloat green, > > GLfloat blue, GLfloat alpha); > > * WINGDIAPI void APIENTRY glColor4fv (const GLfloat *v); > > * WINGDIAPI void APIENTRY glColor4i (GLint red, GLint green, GLint > > blue, GLint alpha); > > * WINGDIAPI void APIENTRY glColor4iv (const GLint *v); > > * WINGDIAPI void APIENTRY glColor4s (GLshort red, GLshort green, > > GLshort blue, GLshort alpha); > > * WINGDIAPI void APIENTRY glColor4sv (const GLshort *v); > > * WINGDIAPI void APIENTRY glColor4ub (GLubyte red, GLubyte green, > > GLubyte blue, GLubyte alpha); > > * WINGDIAPI void APIENTRY glColor4ubv (const GLubyte *v); > > * WINGDIAPI void APIENTRY glColor4ui (GLuint red, GLuint green, > > GLuint blue, GLuint alpha); > > * WINGDIAPI void APIENTRY glColor4uiv (const GLuint *v); > > * WINGDIAPI void APIENTRY glColor4us (GLushort red, GLushort > > green, GLushort blue, GLushort alpha); > > * WINGDIAPI void APIENTRY glColor4usv (const GLushort *v); > > > which was rewritten as: > > -- Color Formats > > Procedure Color ( red, green, blue : in Byte ); > > Procedure Color ( v : RGB_Byte_Vector ); > > Procedure Color ( red, green, blue : in double ); > > Procedure Color ( v : RGB_Double_Vector ); > > Procedure Color ( red, green, blue : in float ); > > Procedure Color ( V : RGB_Float_Vector ); > > Procedure Color ( red, green, blue : int ); > > Procedure Color ( V : RGB_Integer_Vector ); > > Procedure Color ( red, green, blue : Short ); > > Procedure Color ( V : RGB_Short_Vector ); > > Procedure Color ( red, green, blue : Unsigned_Byte ); > > Procedure Color ( v : RGB_Unsigned_Byte_Vector ); > > Procedure Color ( red, green, blue : in Unsigned_Integer ); > > Procedure Color ( v : RGB_Unsigned_Integer_Vector ); > > Procedure Color ( red, green, blue : in Unsigned_Short ); > > Procedure Color ( v : RGB_Unsigned_Short_Vector ); > > Procedure Color ( red, green, blue, alpha : in byte ); > > Procedure Color ( v: RGBA_Byte_Vector ); > > Procedure Color ( red, green, blue, alpha : in double ); > > Procedure Color ( v : RGBA_Double_Vector ); > > Procedure Color ( red, green, blue, alpha : in float ); > > Procedure Color ( v: RGBA_Float_Vector ); > > Procedure Color ( red, green, blue, alpha : in int ); > > Procedure Color ( v: RGBA_Integer_Vector ); > > Procedure Color ( red, green, blue, alpha : in short ); > > Procedure Color ( v: RGBA_Short_Vector ); > > Procedure Color ( red, green, blue, alpha : in Unsigned_Byte ); > > Procedure Color ( v: RGBA_Unsigned_Byte_Vector ); > > Procedure Color ( red, green, blue, alpha : in Unsigned_Integer ); > > Procedure Color ( v: RGBA_Unsigned_Integer_Vector ); > > Procedure Color ( red, green, blue, alpha : in Unsigned_Short ); > > Procedure Color ( v: RGBA_Unsigned_Short_Vector ); > > > where X_Y_Vector is an array of elements of type Y and indexed on type > > X. > > > Another thing that I've done is, to the best of my ability, used Ada's > > strong typing to make passing invalid parameters less of a problem; > > for example: > > Type Begin_Mode_Type is > > ( POINTS, LINES, LINE_LOOP, LINE_STRIP, TRIANGLES, > > TRIANGLE_STRIP, > > TRIANGLE_FAN, QUADS, QUAD_STRIP, POLYGON > > ); > > > For Begin_Mode_Type use > > ( POINTS => GL_POINTS, > > LINES => GL_LINES, > > LINE_LOOP => GL_LINE_LOOP, > > LINE_STRIP => GL_LINE_STRIP, > > TRIANGLES => GL_TRIANGLES, > > TRIANGLE_STRIP => GL_TRIANGLE_STRIP, > > TRIANGLE_FAN => GL_TRIANGLE_FAN, > > QUADS => GL_QUADS, > > QUAD_STRIP => GL_QUAD_STRIP, > > POLYGON => GL_POLYGON > > ); > > > is a type for the glBegin-wrapper which only allows the passing of > > valid "mode"-parameters. {That is, range points..polygon.} > > > My questions are these: > > Would anyone, other than myself, find such a translation of interest? > > and > > When I finish, would anyone want to test it out? > > Having done this a couple of times myself, you should consider the > approach of writing a specialized program that processes the OpenGL > header into a binding. OpenGL will remain a moving target as graphics > hardware continues to evolve. Compilers will always have their unique > quirks. With all this room for variation, it will probably be easier > to maintain a translator than to revise the binding every time the > standard changes or grows. I see what you're saying. The problem is in the specs, the moving target you mentioned, for example the glBegin function could be extended to take a new enumeration, say, GL_AWESOME! This disrupts the allowable inputs for glBegin, now we have a non-contiguous range of GL_POINTS..GL_POLYGON & GL_AWESOME..GL_AWESOME since these are constants instead of true enumeration-types {thank you c/c++} and the glFUNCTIONs take a 32-bit value as the "enumeration." Basically it's the result of a) lack of foresight, and b) lazy programming. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-09 17:38 ` Shark8 @ 2010-07-09 20:54 ` Gene 2010-07-12 17:04 ` Warren 2010-07-10 4:00 ` BrianG 1 sibling, 1 reply; 24+ messages in thread From: Gene @ 2010-07-09 20:54 UTC (permalink / raw) On Jul 9, 1:38 pm, Shark8 <onewingedsh...@gmail.com> wrote: > On Jul 9, 9:11 am, Gene <gene.ress...@gmail.com> wrote: > > > > > > > On Jul 7, 10:42 pm, Shark8 <onewingedsh...@gmail.com> wrote: > > > > Hello everyone, > > > I posted about wanting to write an OS in Ada a while ago and, as part > > > of that effort I've taken to translating the OpenGL API. No, I don't > > > mean JUST running the headers through ato-Ada converter but actually > > > translating the API into a more Ada-natural form. > > > > As an example, here is the glColor-'family' of functions: > > > * WINGDIAPI void APIENTRY glColor3b (GLbyte red, GLbyte green, > > > GLbyte blue); > > > * WINGDIAPI void APIENTRY glColor3bv (const GLbyte *v); > > > * WINGDIAPI void APIENTRY glColor3d (GLdouble red, GLdouble green, > > > GLdouble blue); > > > * WINGDIAPI void APIENTRY glColor3dv (const GLdouble *v); > > > * WINGDIAPI void APIENTRY glColor3f (GLfloat red, GLfloat green, > > > GLfloat blue); > > > * WINGDIAPI void APIENTRY glColor3fv (const GLfloat *v); > > > * WINGDIAPI void APIENTRY glColor3i (GLint red, GLint green, GLint > > > blue); > > > * WINGDIAPI void APIENTRY glColor3iv (const GLint *v); > > > * WINGDIAPI void APIENTRY glColor3s (GLshort red, GLshort green, > > > GLshort blue); > > > * WINGDIAPI void APIENTRY glColor3sv (const GLshort *v); > > > * WINGDIAPI void APIENTRY glColor3ub (GLubyte red, GLubyte green, > > > GLubyte blue); > > > * WINGDIAPI void APIENTRY glColor3ubv (const GLubyte *v); > > > * WINGDIAPI void APIENTRY glColor3ui (GLuint red, GLuint green, > > > GLuint blue); > > > * WINGDIAPI void APIENTRY glColor3uiv (const GLuint *v); > > > * WINGDIAPI void APIENTRY glColor3us (GLushort red, GLushort > > > green, GLushort blue); > > > * WINGDIAPI void APIENTRY glColor3usv (const GLushort *v); > > > * WINGDIAPI void APIENTRY glColor4b (GLbyte red, GLbyte green, > > > GLbyte blue, GLbyte alpha); > > > * WINGDIAPI void APIENTRY glColor4bv (const GLbyte *v); > > > * WINGDIAPI void APIENTRY glColor4d (GLdouble red, GLdouble green, > > > GLdouble blue, GLdouble alpha); > > > * WINGDIAPI void APIENTRY glColor4dv (const GLdouble *v); > > > * WINGDIAPI void APIENTRY glColor4f (GLfloat red, GLfloat green, > > > GLfloat blue, GLfloat alpha); > > > * WINGDIAPI void APIENTRY glColor4fv (const GLfloat *v); > > > * WINGDIAPI void APIENTRY glColor4i (GLint red, GLint green, GLint > > > blue, GLint alpha); > > > * WINGDIAPI void APIENTRY glColor4iv (const GLint *v); > > > * WINGDIAPI void APIENTRY glColor4s (GLshort red, GLshort green, > > > GLshort blue, GLshort alpha); > > > * WINGDIAPI void APIENTRY glColor4sv (const GLshort *v); > > > * WINGDIAPI void APIENTRY glColor4ub (GLubyte red, GLubyte green, > > > GLubyte blue, GLubyte alpha); > > > * WINGDIAPI void APIENTRY glColor4ubv (const GLubyte *v); > > > * WINGDIAPI void APIENTRY glColor4ui (GLuint red, GLuint green, > > > GLuint blue, GLuint alpha); > > > * WINGDIAPI void APIENTRY glColor4uiv (const GLuint *v); > > > * WINGDIAPI void APIENTRY glColor4us (GLushort red, GLushort > > > green, GLushort blue, GLushort alpha); > > > * WINGDIAPI void APIENTRY glColor4usv (const GLushort *v); > > > > which was rewritten as: > > > -- Color Formats > > > Procedure Color ( red, green, blue : in Byte ); > > > Procedure Color ( v : RGB_Byte_Vector ); > > > Procedure Color ( red, green, blue : in double ); > > > Procedure Color ( v : RGB_Double_Vector ); > > > Procedure Color ( red, green, blue : in float ); > > > Procedure Color ( V : RGB_Float_Vector ); > > > Procedure Color ( red, green, blue : int ); > > > Procedure Color ( V : RGB_Integer_Vector ); > > > Procedure Color ( red, green, blue : Short ); > > > Procedure Color ( V : RGB_Short_Vector ); > > > Procedure Color ( red, green, blue : Unsigned_Byte ); > > > Procedure Color ( v : RGB_Unsigned_Byte_Vector ); > > > Procedure Color ( red, green, blue : in Unsigned_Integer ); > > > Procedure Color ( v : RGB_Unsigned_Integer_Vector ); > > > Procedure Color ( red, green, blue : in Unsigned_Short ); > > > Procedure Color ( v : RGB_Unsigned_Short_Vector ); > > > Procedure Color ( red, green, blue, alpha : in byte ); > > > Procedure Color ( v: RGBA_Byte_Vector ); > > > Procedure Color ( red, green, blue, alpha : in double ); > > > Procedure Color ( v : RGBA_Double_Vector ); > > > Procedure Color ( red, green, blue, alpha : in float ); > > > Procedure Color ( v: RGBA_Float_Vector ); > > > Procedure Color ( red, green, blue, alpha : in int ); > > > Procedure Color ( v: RGBA_Integer_Vector ); > > > Procedure Color ( red, green, blue, alpha : in short ); > > > Procedure Color ( v: RGBA_Short_Vector ); > > > Procedure Color ( red, green, blue, alpha : in Unsigned_Byte ); > > > Procedure Color ( v: RGBA_Unsigned_Byte_Vector ); > > > Procedure Color ( red, green, blue, alpha : in Unsigned_Integer ); > > > Procedure Color ( v: RGBA_Unsigned_Integer_Vector ); > > > Procedure Color ( red, green, blue, alpha : in Unsigned_Short ); > > > Procedure Color ( v: RGBA_Unsigned_Short_Vector ); > > > > where X_Y_Vector is an array of elements of type Y and indexed on type > > > X. > > > > Another thing that I've done is, to the best of my ability, used Ada's > > > strong typing to make passing invalid parameters less of a problem; > > > for example: > > > Type Begin_Mode_Type is > > > ( POINTS, LINES, LINE_LOOP, LINE_STRIP, TRIANGLES, > > > TRIANGLE_STRIP, > > > TRIANGLE_FAN, QUADS, QUAD_STRIP, POLYGON > > > ); > > > > For Begin_Mode_Type use > > > ( POINTS => GL_POINTS, > > > LINES => GL_LINES, > > > LINE_LOOP => GL_LINE_LOOP, > > > LINE_STRIP => GL_LINE_STRIP, > > > TRIANGLES => GL_TRIANGLES, > > > TRIANGLE_STRIP => GL_TRIANGLE_STRIP, > > > TRIANGLE_FAN => GL_TRIANGLE_FAN, > > > QUADS => GL_QUADS, > > > QUAD_STRIP => GL_QUAD_STRIP, > > > POLYGON => GL_POLYGON > > > ); > > > > is a type for the glBegin-wrapper which only allows the passing of > > > valid "mode"-parameters. {That is, range points..polygon.} > > > > My questions are these: > > > Would anyone, other than myself, find such a translation of interest? > > > and > > > When I finish, would anyone want to test it out? > > > Having done this a couple of times myself, you should consider the > > approach of writing a specialized program that processes the OpenGL > > header into a binding. OpenGL will remain a moving target as graphics > > hardware continues to evolve. Compilers will always have their unique > > quirks. With all this room for variation, it will probably be easier > > to maintain a translator than to revise the binding every time the > > standard changes or grows. > > I see what you're saying. The problem is in the specs, the moving > target you mentioned, for example the glBegin function could be > extended to take a new enumeration, say, GL_AWESOME! This disrupts the > allowable inputs for glBegin, now we have a non-contiguous range of > GL_POINTS..GL_POLYGON & GL_AWESOME..GL_AWESOME since these are > constants instead of true enumeration-types {thank you c/c++} and the > glFUNCTIONs take a 32-bit value as the "enumeration." > > Basically it's the result of a) lack of foresight, and b) lazy > programming. Well, plus the need for backward compatibility. Nonetheless, if you have isolated the need to identify glBegin args in a table within a translator, so it can spit out the requisite new enumeration equivalences, I believe you are ahead of the game. No one is saying the translator will keep working with zero modifications. For (an admittedly contrived) example, if the spec introduces a new call that accepts anything glBegin will accept plus a few other flags, the translator can encode this idea in a new addendum table and an algorithm. This is easier and less error prone going forward than remembering to update both enumerations in parallel. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-09 20:54 ` Gene @ 2010-07-12 17:04 ` Warren 0 siblings, 0 replies; 24+ messages in thread From: Warren @ 2010-07-12 17:04 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2926 bytes --] Gene expounded in news:2074b3a5-12f3-4260-a2ad-f15ed251e378@d16g2000yqb.googlegroups.com: > On Jul 9, 1:38�pm, Shark8 <onewingedsh...@gmail.com> wrote: >> On Jul 9, 9:11�am, Gene <gene.ress...@gmail.com> wrote: >> > On Jul 7, 10:42�pm, Shark8 <onewingedsh...@gmail.com> wrote: >> >> > > Hello everyone, >> > > I posted about wanting to write an OS in Ada a while ago and, as >> > > part of that effort I've taken to translating the OpenGL API. No, >> > > I don't mean JUST running the headers through ato-Ada converter >> > > but actually translating the API into a more Ada-natural form. ... >> > Having done this a couple of times myself, you should consider the >> > approach of writing a specialized program that processes the OpenGL >> > header into a binding. �OpenGL will remain a moving target as >> > graphic > s >> > hardware continues to evolve. �Compilers will always have their >> > uniqu > e >> > quirks. �With all this room for variation, it will probably be >> > easier to maintain a translator than to revise the binding every >> > time the standard changes or grows. >> >> I see what you're saying. The problem is in the specs, the moving >> target you mentioned, for example the glBegin function ... > > Well, plus the need for backward compatibility. > > Nonetheless, if you have isolated the need to identify glBegin args in > a table within a translator, so it can spit out the requisite new > enumeration equivalences, I believe you are ahead of the game. No one > is saying the translator will keep working with zero modifications. > > For (an admittedly contrived) example, if the spec introduces a new > call that accepts anything glBegin will accept plus a few other flags, > the translator can encode this idea in a new addendum table and an > algorithm. This is easier and less error prone going forward than > remembering to update both enumerations in parallel. I've not tried to use OpenGL myself, but my two cents worth- I'd prefer the binding not to be as much of a moving target. One thing you can use is procedure/function overloading as well as differently named procedures/functions. The Ada binding should have some of the benefit of hindsight, since it is developed after. So take that advantage and design an API that is "proper". In other words, make it less of a binding, than a proper Ada library layer to the OpenGL behind the scenes. If you extend something, then I think this can be normally done without breaking existing APIs. I know there will be exceptions, but I'd be real annoyed if I had to re-work my app every time a new version of the binding came out. This is one of the reasons that my own open sourced projects depend upon as few external projects as possible. I don't like having to re-work and debug other user's problems in my software by email, inflicted by other dependency projects' [sometimes] whimsical changes. Warren ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-09 17:38 ` Shark8 2010-07-09 20:54 ` Gene @ 2010-07-10 4:00 ` BrianG 2010-07-10 11:47 ` Gautier write-only 2010-07-11 5:30 ` tmoran 1 sibling, 2 replies; 24+ messages in thread From: BrianG @ 2010-07-10 4:00 UTC (permalink / raw) Shark8 wrote: > On Jul 9, 9:11 am, Gene <gene.ress...@gmail.com> wrote: >> On Jul 7, 10:42 pm, Shark8 <onewingedsh...@gmail.com> wrote: >>> Hello everyone, >>> I posted about wanting to write an OS in Ada a while ago and, as part >>> of that effort I've taken to translating the OpenGL API. No, I don't >>> mean JUST running the headers through ato-Ada converter but actually >>> translating the API into a more Ada-natural form. >>> As an example, here is the glColor-'family' of functions: ... >>> which was rewritten as: >>> -- Color Formats >>> Procedure Color ( red, green, blue : in Byte ); >>> Procedure Color ( v : RGB_Byte_Vector ); >>> Procedure Color ( red, green, blue : in double ); >>> Procedure Color ( v : RGB_Double_Vector ); >>> Procedure Color ( red, green, blue : in float ); >>> Procedure Color ( V : RGB_Float_Vector ); >>> Procedure Color ( red, green, blue : int ); One problem you'll have is if a user wants to make a call with all literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler won't know which version to use. The best solution I've found (besides making users specify a type) is to have a second name which is defined for int and float only (or whatever the default is), but I've come up with no good format for the second name: Color_Literal, Color_L, Color1, ...? (I've tried starting a similar effort, but never got very far. I was using the OpenGL "red book" as a basis; I find it interesting that the OpenGL definition recognizes that "some languages like Ada and C++" could implement names this way, but every Ada library I've seen follows the C naming scheme.) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-10 4:00 ` BrianG @ 2010-07-10 11:47 ` Gautier write-only 2010-07-11 2:45 ` BrianG 2010-07-11 5:30 ` tmoran 1 sibling, 1 reply; 24+ messages in thread From: Gautier write-only @ 2010-07-10 11:47 UTC (permalink / raw) On 10 juil, 06:00, BrianG wrote: > One problem you'll have is if a user wants to make a call with all > literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the > compiler won't know which version to use. Sure it will know! The confusion is rather when the GL.Float and the GL.Double versions are named Color. One solution is to choose one type as "most common" per category (floating-point, integer), and for instance name "Color" for GL.Double and Color_f for GL.Float: http://globe3d.sourceforge.net/g3d_html/gl__ads.htm#3437_13 There is also an automatic tool to generate these parts of bindings in a consistent manner, with Import pragmata etc. - just use it (or the binding itself...). G. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-10 11:47 ` Gautier write-only @ 2010-07-11 2:45 ` BrianG 2010-07-11 4:10 ` Gautier write-only 0 siblings, 1 reply; 24+ messages in thread From: BrianG @ 2010-07-11 2:45 UTC (permalink / raw) Gautier write-only wrote: > On 10 juil, 06:00, BrianG wrote: > >> One problem you'll have is if a user wants to make a call with all >> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the >> compiler won't know which version to use. > > Sure it will know! > The confusion is rather when the GL.Float and the GL.Double versions > are named Color. One solution is to choose one type as "most common" > per category (floating-point, integer), and for instance name "Color" > for GL.Double and Color_f for GL.Float: > > http://globe3d.sourceforge.net/g3d_html/gl__ads.htm#3437_13 > > There is also an automatic tool to generate these parts of bindings in > a consistent manner, with Import pragmata etc. - just use it (or the > binding itself...). > > G. I don't understand your "rather"; that's exactly my point. See the start of my post. This doesn't just apply to Float/Double, it also applies to Byte/Short/Int/Long (etc.). That's why I specifically included those versions of the calls in my post. What you have is a way to do it, but that's not what the OP posted. He had all procedures named Color, so the user doesn't need to worry about implementation. (If I use Color for Double and want to change my program to use Float, I have to change the names of all calls, even if I use calls where the compiler could determine what I want - and not just calls to Color, many routines would have the same issue.) This is also what the OpenGL documentation implies should be done in a language like Ada. You could have both Color and Color_F for Float (which is part of what my point was). Then you could also have Color and Color_I for Int, which was the other part of my point: Color_F and Color_I don't have to have different names. If there's only one version for each category, they could be overloaded. My problem is I can't come up with an obvious second name. Color_F and Color_I (etc) are obvious and simple, so maybe that's the best option. (My defintion of "obvious and simple" is: I write a program without worrying about (or thinking of) this issue, the compile complains where I use only literals, and I change the needed names. I'd like the name change to be as easy and obvious as possible. That's why I thought having only two names would be ideal - the 'normal' name and the 'oops' name. Possibly using multiple second names is the only practical option. I'd still like to keep all versions of the 'normal' name, since I don't always need to specify the type - otherwise, you might as well keep all of the suffixes used by C - especially if the 'default' is the one used most often.) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-11 2:45 ` BrianG @ 2010-07-11 4:10 ` Gautier write-only 0 siblings, 0 replies; 24+ messages in thread From: Gautier write-only @ 2010-07-11 4:10 UTC (permalink / raw) On Jul 11, 4:45 am, BrianG <briang...@gmail.com> wrote: > I don't understand your "rather"; that's exactly my point. See the > start of my post. Sorry, I misunderstood you. ... > My problem is I can't come up with an obvious > second name. Color_F and Color_I (etc) are obvious and simple, so > maybe that's the best option. In my opinion it is. It is the closest to the full overloading to "Color", but avoiding the problem with litterals. Then you can have also have also "Color" for one of the fp types, same for one of the integer types. G. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-10 4:00 ` BrianG 2010-07-10 11:47 ` Gautier write-only @ 2010-07-11 5:30 ` tmoran 2010-07-11 20:46 ` anon 1 sibling, 1 reply; 24+ messages in thread From: tmoran @ 2010-07-11 5:30 UTC (permalink / raw) > >>> Procedure Color ( red, green, blue : in double ); > >>> Procedure Color ( red, green, blue : in float ); > > One problem you'll have is if a user wants to make a call with all > literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler > won't know which version to use. The best solution I've found (besides > making users specify a type) And what's wrong with requiring the user to be unambiguous by specifying a type? It's unlikely there will be a lot of calls with all literals (unless generated by some program) so it shouldn't be onerous. And "Float'(1.0)" is clearer to the person reading the code five years from now than "Color_F". ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-11 5:30 ` tmoran @ 2010-07-11 20:46 ` anon 2010-07-12 14:17 ` Shark8 0 siblings, 1 reply; 24+ messages in thread From: anon @ 2010-07-11 20:46 UTC (permalink / raw) In <i1bktn$ucj$1@speranza.aioe.org>, tmoran@acm.org writes: >> >>> Procedure Color ( red, green, blue : in double ); >> >>> Procedure Color ( red, green, blue : in float ); >> >> One problem you'll have is if a user wants to make a call with all >> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler >> won't know which version to use. The best solution I've found (besides >> making users specify a type) > >And what's wrong with requiring the user to be unambiguous by specifying >a type? It's unlikely there will be a lot of calls with all literals >(unless generated by some program) so it shouldn't be onerous. And >"Float'(1.0)" is clearer to the person reading the code five years >from now than "Color_F". What your are forgetting is the openGL is a specification from the openGL group ( opengl.org ), it is just like the Ada RM in that respect. For a program or package, to be classified as openGL it must comply with "openGL group" openGL specification. Changing any API part nullify the use of openGL in any part of your system. So, adding or altering any definitions about the given API must comply with the openGL specification. Names of the API functions and procedures with the API defined types are set by this openGL group. visit www.opengl.org for more information on openGL and the "openGL group" Also, you may find the API specifications predefined with examples in C that you can alter to Ada there as well. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-11 20:46 ` anon @ 2010-07-12 14:17 ` Shark8 2010-07-13 0:45 ` BrianG 0 siblings, 1 reply; 24+ messages in thread From: Shark8 @ 2010-07-12 14:17 UTC (permalink / raw) On Jul 11, 2:46 pm, a...@att.net wrote: > In <i1bktn$uc...@speranza.aioe.org>, tmo...@acm.org writes: > >> >>> Procedure Color ( red, green, blue : in double ); > >> >>> Procedure Color ( red, green, blue : in float ); > > >> One problem you'll have is if a user wants to make a call with all > >> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler > >> won't know which version to use. The best solution I've found (besides > >> making users specify a type) > > >And what's wrong with requiring the user to be unambiguous by specifying > >a type? It's unlikely there will be a lot of calls with all literals > >(unless generated by some program) so it shouldn't be onerous. And > >"Float'(1.0)" is clearer to the person reading the code five years > >from now than "Color_F". > > What your are forgetting is the openGL is a specification from the openGL > group ( opengl.org ), it is just like the Ada RM in that respect. For a > program or package, to be classified as openGL it must comply with "openGL > group" openGL specification. Changing any API part nullify the use of > openGL in any part of your system. > > So, adding or altering any definitions about the given API must comply with > the openGL specification. Names of the API functions and procedures with > the API defined types are set by this openGL group. That seems, on its face, to contradict BrianG's claim: > What you have is a way to do it, but that's not what the OP posted. He had > all procedures named Color, so the user doesn't need to worry about > implementation. (If I use Color for Double and want to change my program to > use Float, I have to change the names of all calls, even if I use calls where > the compiler could determine what I want - and not just calls to Color, many > routines would have the same issue.) This is also what the OpenGL > documentation implies should be done in a language like Ada. But, if he's correct in this earlier post: > (I've tried starting a similar effort, but never got very far. I was using > the OpenGL "red book" as a basis; I find it interesting that the OpenGL > definition recognizes that "some languages like Ada and C++" could implement > names this way, but every Ada library I've seen follows the C naming scheme.) Then my renaming (to get rid of the gl- prefix and parameter-type- postfix) and overloading them all is a valid OpenGL API. > > visitwww.opengl.org > for more information on openGL and the "openGL group" > > Also, you may find the API specifications predefined with examples in C that > you can alter to Ada there as well. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-12 14:17 ` Shark8 @ 2010-07-13 0:45 ` BrianG 2010-07-13 17:50 ` anon 0 siblings, 1 reply; 24+ messages in thread From: BrianG @ 2010-07-13 0:45 UTC (permalink / raw) Shark8 wrote: > On Jul 11, 2:46 pm, a...@att.net wrote: >> In <i1bktn$uc...@speranza.aioe.org>, tmo...@acm.org writes: >>>>>>> Procedure Color ( red, green, blue : in double ); >>>>>>> Procedure Color ( red, green, blue : in float ); >>>> One problem you'll have is if a user wants to make a call with all >>>> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler >>>> won't know which version to use. The best solution I've found (besides >>>> making users specify a type) >>> And what's wrong with requiring the user to be unambiguous by specifying >>> a type? It's unlikely there will be a lot of calls with all literals >>> (unless generated by some program) so it shouldn't be onerous. And >>> "Float'(1.0)" is clearer to the person reading the code five years >> >from now than "Color_F". >> >> What your are forgetting is the openGL is a specification from the openGL >> group ( opengl.org ), it is just like the Ada RM in that respect. For a >> program or package, to be classified as openGL it must comply with "openGL >> group" openGL specification. Changing any API part nullify the use of >> openGL in any part of your system. I'm sorry, I wasn't aware we had a member of the OpenGL police present. Where do I go to pay my fine? BTW, it appears the proper name is OpenGL, not openGL :-). Not that I'm picky. Maybe you ('Anon') ought to actually read the spec you mentioned. The following is a direct quote from that document: "The declarations shown in this document apply to ANSI C. Languages such as C++ and Ada that allow passing of argument type information admit simpler declarations and fewer entry points." (with reference to the GLxxxTypeInterface naming convention.) [http://www.opengl.org/registry/doc/glspec40.core.20100311.pdf] >> >> So, adding or altering any definitions about the given API must comply with >> the openGL specification. Names of the API functions and procedures with >> the API defined types are set by this openGL group. > > That seems, on its face, to contradict BrianG's claim: > >> What you have is a way to do it, but that's not what the OP posted. He had >> all procedures named Color, so the user doesn't need to worry about >> implementation. (If I use Color for Double and want to change my program to >> use Float, I have to change the names of all calls, even if I use calls where >> the compiler could determine what I want - and not just calls to Color, many >> routines would have the same issue.) This is also what the OpenGL >> documentation implies should be done in a language like Ada. > > But, if he's correct in this earlier post: >> (I've tried starting a similar effort, but never got very far. I was using >> the OpenGL "red book" as a basis; I find it interesting that the OpenGL >> definition recognizes that "some languages like Ada and C++" could implement >> names this way, but every Ada library I've seen follows the C naming scheme.) > > Then my renaming (to get rid of the gl- prefix and parameter-type- > postfix) and > overloading them all is a valid OpenGL API. > Not only is it valid, it looks like it's what was expected. I've never seen an implementation that does that. >> visitwww.opengl.org >> for more information on openGL and the "openGL group" >> >> Also, you may find the API specifications predefined with examples in C that >> you can alter to Ada there as well. > What I've been using is the online v1.1 "Redbook" [http://www.glprogramming.com/red/] - since ObjectAda (from Barnes' book) uses that version (last I looked, GNAT/GTKAda didn't provide OpenGL on windows). I've never tried figuring out OpenGL versions - right now the "current edition of the Redbook" is version 2.1, but the same page points to a "Specification Version 4.0". Whatever. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-13 0:45 ` BrianG @ 2010-07-13 17:50 ` anon 2010-07-13 18:37 ` Shark8 0 siblings, 1 reply; 24+ messages in thread From: anon @ 2010-07-13 17:50 UTC (permalink / raw) > >I'm sorry, I wasn't aware we had a member of the OpenGL police present. > Where do I go to pay my fine? BTW, it appears the proper name is >OpenGL, not openGL :-). Not that I'm picky. > >Maybe you ('Anon') ought to actually read the spec you mentioned. The >following is a direct quote from that document: >"The declarations shown in this document apply to ANSI C. Languages such >as C++ and Ada that allow passing of argument type information admit >simpler declarations and fewer entry points." >(with reference to the GLxxxTypeInterface naming convention.) >[http://www.opengl.org/registry/doc/glspec40.core.20100311.pdf] > > May you should understand that people who use Ada know that the we do not want others try to destroy Ada by adding or modifying Ada without the RM direct allowance. So, we as a group should be consider that other may feel the same way about openGL's RM or specifications. And just like Ada uses prefer "Ada' the GL group prefer "openGL". >What I've been using is the online v1.1 "Redbook" >[http://www.glprogramming.com/red/] - since ObjectAda (from Barnes' >book) uses that version (last I looked, GNAT/GTKAda didn't provide >OpenGL on windows). > >I've never tried figuring out OpenGL versions - right now the "current >edition of the Redbook" is version 2.1, but the same page points to > a "Specification Version 4.0". Whatever. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-13 17:50 ` anon @ 2010-07-13 18:37 ` Shark8 0 siblings, 0 replies; 24+ messages in thread From: Shark8 @ 2010-07-13 18:37 UTC (permalink / raw) According to OpenGL's specification (page 14): These examples show the ANSI C declarations for these commands. In general, a command declaration has the form1 rtype Namef\x0f1234gf\x0f b s i i64 f d ub us ui ui64gf\x0fvg ( [args ,] T arg1 , : : : , T argN [, args] ); rtype is the return type of the function. The braces (fg) enclose a series of type descriptors (see table 2.1), of which one is selected. \x0f indicates no type descriptor. The arguments enclosed in brackets ([args ,] and [, args]) may or may not be present. The N arguments arg1 through argN have type T, which corresponds to one of the type descriptors indicated in table 2.1 (if there are no letters, then the arguments’ type is given explicitly). If the final character is not v, then N is given by the digit 1, 2, 3, or 4 (if there is no digit, then the number of arguments is fixed). If the final character is v, then only arg1 is present and it is an array of N values of the indicated type. For example, void Uniformf1234gfifg( int location, T value ); indicates the eight declarations The footnote reads: "1The declarations shown in this document apply to ANSI C. Languages such as C++ and Ada that allow passing of argument type information admit simpler declarations and fewer entry points." Therefore, the very spec that you are claiming to advocate says that I *CAN* use Ada and "simpler declarations and fewer entry points." If you're going to "language-lawyer" at least read the rules/specs that your opponent is citing, otherwise you come off as a jerk who is too [intellectually] lazy to actually consider the problems/statements at hand. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada #2 2010-07-08 2:42 OpenGL in Ada Shark8 ` (2 preceding siblings ...) 2010-07-09 15:11 ` Gene @ 2015-01-15 7:11 ` JillRivas 2015-01-30 14:45 ` OpenGL in Ada Lucretia 4 siblings, 0 replies; 24+ messages in thread From: JillRivas @ 2015-01-15 7:11 UTC (permalink / raw) Great article. Thanks for the info, you made it easy to understand. BTW, if anyone needs to fill out a <a href="http://www.pdffiller.com/6954886-f940--2013pdf-2013-Form-940-User-Forms?utm_source=compgroups.net&utm_medium=newblogsystem&utm_campaign= \"ADA form\" journal" target="_blank" >Ada Form</a>, I found a blank form here. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2010-07-08 2:42 OpenGL in Ada Shark8 ` (3 preceding siblings ...) 2015-01-15 7:11 ` OpenGL in Ada #2 JillRivas @ 2015-01-30 14:45 ` Lucretia 2015-01-30 18:41 ` David Botton 4 siblings, 1 reply; 24+ messages in thread From: Lucretia @ 2015-01-30 14:45 UTC (permalink / raw) I already have the majority of SDL 2.0.3 bound and I already have parsing for the GL XML spec files. I really must get back to them :D Luke. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: OpenGL in Ada 2015-01-30 14:45 ` OpenGL in Ada Lucretia @ 2015-01-30 18:41 ` David Botton 0 siblings, 0 replies; 24+ messages in thread From: David Botton @ 2015-01-30 18:41 UTC (permalink / raw) On Friday, January 30, 2015 at 9:45:53 AM UTC-5, Lucretia wrote: > I already have the majority of SDL 2.0.3 bound and I already have parsing for the GL XML spec files. I really must get back to them :D > > Luke. Please do :) Gnoga is waiting to use it for WebGL :) ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2015-01-30 18:41 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-07-08 2:42 OpenGL in Ada Shark8 2010-07-08 14:15 ` John B. Matthews 2010-07-09 2:18 ` anon 2010-07-12 16:51 ` Warren 2010-07-13 12:26 ` Ludovic Brenta 2010-07-13 13:13 ` Warren 2010-07-09 11:43 ` Gautier write-only 2010-07-09 15:11 ` Gene 2010-07-09 17:38 ` Shark8 2010-07-09 20:54 ` Gene 2010-07-12 17:04 ` Warren 2010-07-10 4:00 ` BrianG 2010-07-10 11:47 ` Gautier write-only 2010-07-11 2:45 ` BrianG 2010-07-11 4:10 ` Gautier write-only 2010-07-11 5:30 ` tmoran 2010-07-11 20:46 ` anon 2010-07-12 14:17 ` Shark8 2010-07-13 0:45 ` BrianG 2010-07-13 17:50 ` anon 2010-07-13 18:37 ` Shark8 2015-01-15 7:11 ` OpenGL in Ada #2 JillRivas 2015-01-30 14:45 ` OpenGL in Ada Lucretia 2015-01-30 18:41 ` David Botton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox