Re: [oglbase-discuss] Vote results: 1 YES, 2 A

2000-04-06 Thread Leath Muller

 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.



Re: [oglbase-discuss] Vote results: 1 YES, 2 A

2000-04-05 Thread Leath Muller

 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
 Totals  3   5   4
 
 Winner: B

This is definitely the preferable way for me to go. I know there is
a lot of concern about legacy applications and their compatibility,
but quite simply, I would rather get things 'right'. (i.e.: vote C, B
then A)

Being primarily a windows developer moving slowly into Linux, I have
to say that I don't think that the support of legacy applications is
really that important (uh oh -- better jump into a pool full of flame
retardant liquid!!!  :)

I know that sounds harsh and possibly detrimental in some areas, but
from what I can see from current Linux applications, you can very
easily fix them -- lets face it, you have to be a programmer at heart
to develop on Linux at all -- fixing older problems won't be hard, and
a few years down the track when Linux become the major development
platform for most companies (I can hope... :) they will be much happier
with a solid solution... and yes, I know that isn't the most solid
ground for my decision, but it's definitely what I am comfortable with.

'C' works best for me as I won't have to change anything with all my
current development projects such as the tools, main engine, and
research code...

'B' and 'A' are almost identical from my point of view, and to be
perfectly honest I just prefer 'B' because it appears that it can
work exactly the same way as 'A' anyway... is this right? With 'B'
it appears that I can do a #define GL_OGLBASE_EXTENSIONS and have
the glext.h included, or include it myself in the application exactly
the same way 'A' works (seemingly making 'A' moot).

If you want a second vote, mine is as above.

Leathal.



Re: [oglbase-discuss] VOTE: glext.h/preprocessor handling

2000-03-29 Thread Leath Muller

--- (clip, fill in, and respond with this part only) ---

Ballot:

I vote Yes on vote #1.
I vote 'C' on vote #2.  (Then 'B', then 'A')

Leathal.

---



Re: [oglbase-discuss] Updated GL_EXT_get_proc_address spec

1999-10-17 Thread Leath Muller

 Even if this were not true, and memory corruption occurred - a bug is a bug
 is a bug.  I don't think we should design the interface to prevent buggy
 programs from crashing.

Ok, I'm a lurker on this list -- but as an application programmer,
I see no problem with getting proc addresses from context dependent
visuals... If I require a routine that aids in the creation of new
visuals, then I am happy to either:

i) create a dummy visual to grab the function pointer (messy but Ok)
ii) use a specialised platform dependent proc address function

Why can't there be both?  Admitadely, it may be getting a little more
obfuscated than it needs to be, but we are talking about extensions which
are only used by people who are familiar with the API and how it works.

Has anybody considered having two options with the possibility of one
becoming deprecated in future?

For what it's worth, I agree with Michael -- DON'T design an API call
that is trying to fix application bugs, that's our (well, mine anyway)
job as the application programmer. I would feel safer knowing that the
API call would just work as specified, and not do anything overly
'tricky'...

Of course, I might have missed this argument pretty much and am just
talking fud... :)

Leathal.