Haptic joystick "hotpluging" bug (RFC for fix suggestions)

SDL Development
21

If you can’t manage a linked list without someone else doing it for
you, IMO you need to spend a little less time on pretty graphics and
a little more time on fundamentals.

The issue here isn’t whether or not SDL should implement linked
lists?it has done so repeatedly because it’s a basic and common
implementation detail. The question is whether or not it should have
three or four copies of basically identical code to do it. Those who
recognize the inefficiency of this on every level (i.e., most of us)
agree that it should not.

The wheel was invented a long time ago, and several have been
installed in SDL. Someone argued that they should be the same brand.
And now we’re arguing about whether or not changing them constitutes
reinventing them or whether or not anyone’s concept of wheelness
falls under Copyright compatible with SDL.

What constitutes the concept of how to write a linked list is NOT
subject to Copyright, patent, or other intellectual property because
it is in no way novel, unique, or any sort of invention. Read some
examples of code showing how it’s done, understand them, and then
write it. You won’t have “copied” any of them unless you could be
said to have copied all of them. There’s only a couple of ways to do
a linked list, and they’re fundamentally all the same.

All this talk of using someone’s implementation is silly, because
every developer within eyeshot of this message should either be able
to write one or be taking this opportunity to learn how. Linked
lists are one of the basic building blocks of software development.
Any cleverness you may find in a given C-based implementation really
are attempt to circumvent the lack of abstraction in the language.

I’ve now devoted about three to five times the effort of doing the
work and testing it just writing this message. And, although I did
not personally test it myself, someone else DID actually write one
example of the code necessary already.

JosephOn Wed, Feb 05, 2014 at 05:23:28PM +0100, Daniel Gibson wrote:

“That’s easy, let’s just roll our own implementation instead of using
something existing that’s known to work” is pretty much the
definition of NIH.

But I don’t really care in the end, it’s not my time that’s being
wasted by reinventing the wheel :slight_smile:

Cheers,
Daniel

Am 05.02.2014 17:17, schrieb Melker Narikka:

I don’t think it makes much sense to try and rationalise the inclusion
of a whole library for something as straightforward as linked lists.
A “just one more header” approach doesn’t sound too clever to me.

–
Melker

On Wed, Feb 5, 2014 at 2:34 PM, Daniel Gibson wrote:

Am 05.02.2014 13:29, schrieb Gabriel Jacobo:

2014-02-05 Daniel Gibson <metalcaedes at gmail.com
<mailto:metalcaedes at gmail.com>>:

Am 04.02.2014 22:49, schrieb Ryan C. Gordon:


        (perhaps for 2.0.3?).  I'll have some spare time in a week
        and a half,
        so perhaps I can write a patch for one of these two options.


    I don't think we need a third-party library for linked lists.

    --ryan.


NIH?

Cheers,
Daniel

Dependency hell, actually. One of the main under advertised features of
SDL is that “it just builds” :slight_smile:

–
Gabriel.

sglib is just one header.
It could just be added to the SDL source => no additional external dependency.

Cheers,
Daniel

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

22

To follow Joseph’s point, In my programming methodology, I implement simple code patterns regularly without any regard for “reinventing the wheel”, for instance I’ve typed a simple hash bucket insert
implementation into my code in so many places that I’ve lost count - it takes less time to type in than it does to attempt to utilize an abstracted version of the implementation - an abstracted
version would also often bring with it a host of memory management annoyances as well - container programming is non-trivial and hard to tune properly.

Patterns are used throughout programming for good reason, yes we might be typing in a variation of the same thing a dozen times, but it’s still more practical (and practicality is key) than attempting
to abstract a solution to a problem, I won’t even get into the performance implications of these patterns but suffice to say that containers should usually be “inline” and there is nothing more
"inline" than typing it again.

In my 20+ years of game programming I have lost any respect I ever had for “clever” and “elegant” solutions to a problem, instead seeing them as “dangerous” and “unmaintainable” respectively, if you
can’t easily answer the questions of a junior programmer working on code you wrote a few years prior, your priorities were likely suspect.

This is why I have limited respect for C++ as a systems engineer, but that’s a rant for another day.On 02/05/2014 12:46 PM, T. Joseph Carter wrote:

If you can’t manage a linked list without someone else doing it for you, IMO you need to spend a little less time on pretty graphics and a little more time on fundamentals.

The issue here isn’t whether or not SDL should implement linked lists?it has done so repeatedly because it’s a basic and common implementation detail. The question is whether or not it should have
three or four copies of basically identical code to do it. Those who recognize the inefficiency of this on every level (i.e., most of us) agree that it should not.

The wheel was invented a long time ago, and several have been installed in SDL. Someone argued that they should be the same brand. And now we’re arguing about whether or not changing them
constitutes reinventing them or whether or not anyone’s concept of wheelness falls under Copyright compatible with SDL.

What constitutes the concept of how to write a linked list is NOT subject to Copyright, patent, or other intellectual property because it is in no way novel, unique, or any sort of invention. Read
some examples of code showing how it’s done, understand them, and then write it. You won’t have “copied” any of them unless you could be said to have copied all of them. There’s only a couple of
ways to do a linked list, and they’re fundamentally all the same.

All this talk of using someone’s implementation is silly, because every developer within eyeshot of this message should either be able to write one or be taking this opportunity to learn how. Linked
lists are one of the basic building blocks of software development. Any cleverness you may find in a given C-based implementation really are attempt to circumvent the lack of abstraction in the
language.

I’ve now devoted about three to five times the effort of doing the work and testing it just writing this message. And, although I did not personally test it myself, someone else DID actually write
one example of the code necessary already.

Joseph

On Wed, Feb 05, 2014 at 05:23:28PM +0100, Daniel Gibson wrote:

“That’s easy, let’s just roll our own implementation instead of using something existing that’s known to work” is pretty much the definition of NIH.

But I don’t really care in the end, it’s not my time that’s being wasted by reinventing the wheel :slight_smile:

Cheers,
Daniel

Am 05.02.2014 17:17, schrieb Melker Narikka:

I don’t think it makes much sense to try and rationalise the inclusion
of a whole library for something as straightforward as linked lists.
A “just one more header” approach doesn’t sound too clever to me.

–
Melker

On Wed, Feb 5, 2014 at 2:34 PM, Daniel Gibson wrote:

Am 05.02.2014 13:29, schrieb Gabriel Jacobo:

2014-02-05 Daniel Gibson <metalcaedes at gmail.com
<mailto:metalcaedes at gmail.com>>:

Am 04.02.2014 22:49, schrieb Ryan C. Gordon:


        (perhaps for 2.0.3?).  I'll have some spare time in a week
        and a half,
        so perhaps I can write a patch for one of these two options.


    I don't think we need a third-party library for linked lists.

    --ryan.


NIH?

Cheers,
Daniel

Dependency hell, actually. One of the main under advertised features of
SDL is that “it just builds” :slight_smile:

–
Gabriel.

sglib is just one header.
It could just be added to the SDL source => no additional external dependency.

Cheers,
Daniel

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

23

To follow Joseph’s point, In my programming methodology, I implement simple code patterns regularly without any regard for “reinventing the wheel”, for instance I’ve typed a simple hash bucket insert
implementation into my code in so many places that I’ve lost count - it takes less time to type in than it does to attempt to utilize an abstracted version of the implementation - an abstracted
version would also often bring with it a host of memory management annoyances as well - container programming is non-trivial and hard to tune properly.

I was not arguing for using an abstract linked list implementation that
is used throughout SDL (even though IMHO that makes sense) - others
before me agreed that this should be done.
I was arguing for using an existing abstract linked list implementation
instead of creating a new abstract linked list implementation.

Patterns are used throughout programming for good reason, yes we might be typing in a variation of the same thing a dozen times, but it’s still more practical (and practicality is key) than attempting
to abstract a solution to a problem, I won’t even get into the performance implications of these patterns but suffice to say that containers should usually be “inline” and there is nothing more
"inline" than typing it again.

In my 20+ years of game programming I have lost any respect I ever had for “clever” and “elegant” solutions to a problem, instead seeing them as “dangerous” and “unmaintainable” respectively, if you
can’t easily answer the questions of a junior programmer working on code you wrote a few years prior, your priorities were likely suspect.

I can understand this, I’ve seen enough code using boost etc that was
very hard to read and even harder to debug (and also hard to enhance),
while code that was simpler (and a bit longer, thus by some people’s
standards less clever and elegant) was much easier to deal with :slight_smile:

This is why I have limited respect for C++ as a systems engineer, but that’s a rant for another day.

If you can’t manage a linked list without someone else doing it for you, IMO you need to spend a little less time on pretty graphics and a little more time on fundamentals.

I know that writing a linked list implementation isn’t exactly rocket
science and everyone should be able to do that and it was obviously done
several times throughout the SDL code (btw, I guess I’m better at
fundamentals than at pretty graphics…).

(OTOH most bugs you find in any software are simple things done wrong…
off-by-one errors, dereferencing NULL pointers, stuff like that happens
all the time)

However, creating an abstract solution in macros is a bit harder (and I
don’t see another way of creating an inline linked list in C - and I
guess no one wants the overhead of something like struct elem { struct
elem* next; void data*; } that needs twice as much allocations and
casting of the data pointer all the time).
Sure, it’s still absolutely doable, but the code is a bit harder to read
and especially harder to debug.
Furthermore I guess it’s not trivial to create a set of macros that
provide an easy to use API.
All this has been done by other people before… their code is tested and
the API probably was improved multiple times after experience and
feedback from users.

As LordHavoc said - (abstract) container programming is non-trivial.

Cheers,
DanielAm 05.02.2014 21:58, schrieb Forest Hale:

On 02/05/2014 12:46 PM, T. Joseph Carter wrote:

The issue here isn’t whether or not SDL should implement linked lists?it has done so repeatedly because it’s a basic and common implementation detail. The question is whether or not it should have
three or four copies of basically identical code to do it. Those who recognize the inefficiency of this on every level (i.e., most of us) agree that it should not.

The wheel was invented a long time ago, and several have been installed in SDL. Someone argued that they should be the same brand. And now we’re arguing about whether or not changing them
constitutes reinventing them or whether or not anyone’s concept of wheelness falls under Copyright compatible with SDL.

What constitutes the concept of how to write a linked list is NOT subject to Copyright, patent, or other intellectual property because it is in no way novel, unique, or any sort of invention. Read
some examples of code showing how it’s done, understand them, and then write it. You won’t have “copied” any of them unless you could be said to have copied all of them. There’s only a couple of
ways to do a linked list, and they’re fundamentally all the same.

All this talk of using someone’s implementation is silly, because every developer within eyeshot of this message should either be able to write one or be taking this opportunity to learn how. Linked
lists are one of the basic building blocks of software development. Any cleverness you may find in a given C-based implementation really are attempt to circumvent the lack of abstraction in the
language.

I’ve now devoted about three to five times the effort of doing the work and testing it just writing this message. And, although I did not personally test it myself, someone else DID actually write
one example of the code necessary already.

Joseph

24

I don’t think we need a third-party library for linked lists.

NIH?

If you say so.

–ryan.