From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM,PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5b7ee26df9f9c357 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news4.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!.POSTED!not-for-mail From: Warren Newsgroups: comp.lang.ada Subject: Re: OpenGL in Ada Date: Mon, 12 Jul 2010 17:04:39 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <68dd0333-f502-4351-9e50-4ec83bddc44e@k39g2000yqd.googlegroups.com> <2074b3a5-12f3-4260-a2ad-f15ed251e378@d16g2000yqb.googlegroups.com> Injection-Date: Mon, 12 Jul 2010 17:04:39 +0000 (UTC) Injection-Info: mx03.eternal-september.org; posting-host="9f8M0iN5t54V+4DF/iqO8g"; logging-data="16840"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+NSR51bEKhmfwA5PNah/0pLcPWK+DC5bU=" User-Agent: Xnews/5.04.25 X-Face: &6@]C2>ZS=NM|HE-^zWuryN#Z/2_.s9E|G&~DRi|sav9{E}XQJb*\_>=a5"q]\%A;5}LKP][1mA{gZ,Q!j Cancel-Lock: sha1:rv0gNWVBkZeB/T0o0dT7pYllAE0= Xref: g2news1.google.com comp.lang.ada:12348 Date: 2010-07-12T17:04:39+00:00 List-Id: Gene expounded in news:2074b3a5-12f3-4260-a2ad-f15ed251e378@d16g2000yqb.googlegroups.com: > On Jul 9, 1:38�pm, Shark8 wrote: >> On Jul 9, 9:11�am, Gene wrote: >> > On Jul 7, 10:42�pm, Shark8 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