:
-
From: Michael Gold [EMAIL PROTECTED]
Subject: RE: [oglbase-discuss] Vote results: 1 YES, 2 A
Date: Tue, 4 Apr 2000 03:02:04 -0700
...
My order of preference is c, b, a.
-
From: [EMAIL PROTECTED]
Date: Tue, 4 Apr 2000 09:57:44 -0700
Subject: Re
Jon,
My order of preference is C, B , A.
- Mark
In your message of 10 April 2000 you write:
Three topics follow, and hopefully resolution of the A/B/C vote.
First, since we're approaching completion of the debate over the
exact shape of glext.h, I've started generating a copy automatically
from the extension registry. It's at
Thomas Roell wrote:
In your message of 10 April 2000 you write:
Three topics follow, and hopefully resolution of the A/B/C vote.
First, since we're approaching completion of the debate over the
exact shape of glext.h, I've started generating a copy automatically
from the
On Mon, Apr 10, 2000 at 07:57:49AM -0600, Thomas Roell wrote:
1. The defines (types/tokens) should be per extensions, and guarded
properly, so that they are only defined, if the extension has not
been defined yet in gl.h. I know that in theory there should never
be conflicts, but it
In your message of 10 April 2000 you write:
On Mon, Apr 10, 2000 at 07:57:49AM -0600, Thomas Roell wrote:
1. The defines (types/tokens) should be per extensions, and guarded
properly, so that they are only defined, if the extension has not
been defined yet in gl.h. I know that in
On Mon, 10 Apr 2000, Thomas Roell wrote:
http://oss.sgi.com/projects/ogl-sample/ABI/glext.h
Two things that should be changed:
1. The defines (types/tokens) should be per extensions, and guarded
properly, so that they are only defined, if the extension has not
been defined
From: Stephen J Baker [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 10, 2000 12:52 PM
2. Explicite function prototypes should go away. Either you use
wglGetProcAddress() or glXGetProcAddressARB() to retieve the
extension functions. Hence there are no external declarations
On Mon, 10 Apr 2000, Michael Gold wrote:
One caveat: If gl.h defines the extension, it will not be redefined in
glext.h. This is bad because the prototype function pointer typedef will
therefore not be defined.
Yuk! Good point.
The cleanest solution IMO is that gl.h should not
define
In your message of 10 April 2000 you write:
The cleanest solution IMO is that gl.h should not
define any extensions when glext.h is in use.
...Or the prototype function pointer could be left outside of the guardian
ifdef in glext.h since gl.h won't define function *pointers* only the
In your message of 10 April 2000 you write:
On Mon, 10 Apr 2000, Thomas Roell wrote:
In your message of 10 April 2000 you write:
The cleanest solution IMO is that gl.h should not
define any extensions when glext.h is in use.
...Or the prototype function pointer could be
On Mon, 10 Apr 2000, Thomas Roell wrote:
...Or the prototype function pointer could be left outside of the guardian
ifdef in glext.h since gl.h won't define function *pointers* only the
functions themselves.
This would cause a problem with gl.h implementations that include
In your message of 10 April 2000 you write:
On Mon, 10 Apr 2000, Thomas Roell wrote:
...Or the prototype function pointer could be left outside of the guardian
ifdef in glext.h since gl.h won't define function *pointers* only the
functions themselves.
This would cause
I don't see how it's less arbitrary for Michael to invoke an
Australian ballot, or whatever this method is, than any other method we
^^
could use to break a tie, but what the heck.
HEY!!! Watchit buddy!!!
:)
Leathal.
My order of preference is c, b, a.
Here's the results of the sample poll (obviously I will wait for people to
state their actual preferences and not rely on my opinions):
A B C
Michael 0 1 2
Steve 2 1 0
Thomas 1 2 0
Leath 0 1 2
I don't see how it's less arbitrary for Michael to invoke an
Australian ballot, or whatever this method is, than any other method we
could use to break a tie, but what the heck.
My voting order is A, B, C.
Jon Leech
SGI
On Wed, 5 Apr 2000, Jon Leech wrote:
I don't see how it's less arbitrary for Michael to invoke an
Australian ballot, or whatever this method is, than any other method we
could use to break a tie, but what the heck.
Yes. I'd like to start another ballot in which votes for 'A' count
as 2
On Tue, 4 Apr 2000, Michael Gold wrote:
If I were tasked with interpreting the results, I would note that at least
one person who voted for (a) preferred (b). So (c) wins, 6-5-1.
Yes - but that person voted (a) *specifically* to avoid (c) - so to use
that tactical vote as a way to get (c)
In your message of 3 April 2000 you write:
Vote summary:
Vote 1 Vote 2
Who YES NO A B C
Jon Leech x x
Stuart Anderson x x
Mark Kilgardx x
Michael Gold
On Tue, Apr 04, 2000 at 09:51:52AM -0600, Thomas Roell wrote:
| ... I would now be intrested
| why the 2C voters think that having a -DGL_INCLUDE_NO_EXTENSIONS type
| define is preferrable over a -DGL_INCLUDE_EXTENSIONS type
| define. ...
I asked "What
Michael Gold wrote:
...snip...
This thing doesn't need to go on for another month as Jon fears, but I
personally don't mind a couple more days to reach a compromise solution, or
at least a less arbitrary tie-breaker.
As one of the 143 who did not vote, I would like to emphasis that
respect
It should be also clear that using option c is no guarantee for
forcing an application programmer to update the source-code to be
compliant with the standard, as the following code (as it is today)
might still compile and work (if the libGL.so exports the right
symbols):
#ifdef WIN32
On Tue, 4 Apr 2000, Thomas Roell wrote:
#ifdef GL_EXT_point_parameters
#ifdef WIN32
pfn = wglGetProcAddress("glPointParameterfEXT");
#else
#ifdef GLX_ARB_get_proc_address
pfn = glXGetProcAddressARB("glPointParameterfEXT");
#else
pfn = glPointParameterfEXT;
#endif
23 matches
Mail list logo
