Ryan's sandbox, round 2

This week turned out to be SDL 1.2 time…

…this will move to the main repo after some testing.

–ryan.

What happened to SDL_mixer and friends in round 1?
hg.libsdl.org/SDL_mixer seems very quiet. :-POn 08/22/2011 07:01 AM, Ryan C. Gordon wrote:

This week turned out to be SDL 1.2 time…

What happened to SDL_mixer and friends in round 1?
hg.libsdl.org/SDL_mixer seems very quiet. :stuck_out_tongue:

Making a basic pass over SDL’s bugzilla seemed more important. I’ll do
SDL_mixer soon.

–ryan.

…this will move to the main repo after some testing.

This is in the main repo now.

–ryan.

Hi Ryan,

Any chance of removing the #pragma pack(push,4) and #pragma pack(pop) in
include/begin_code.h and include/close_code.h ?

Maybe a note to the people, or something notifying them about it.

Right now this is causing just pain for writing and support FFI libs
(64-bit, 32-bit) - especially when more compilers are used.

One example - SDL compiled with MINGW would need different FFI bindings
than one compiled with MSVC

Here is how I’m declaring my FFI in luajit for SDL (1.3):
https://github.com/malkia/ufo/blob/master/ffi/SDL.lua

Also when possible using enum{} instead of #define might be easier on
the FFI bindings - certain languages can almost directly include the "C"
code as long as there is no preprocessor magic (and sometimes there is
no other way - strings and floats).

Thanks,
Dimiter “malkia” Stanev.On 8/21/11 9:01 PM, Ryan C. Gordon wrote:

This week turned out to be SDL 1.2 time…

  • Lots of pending 1.2 patches from Bugzilla.
  • Some other 1.2 easy fixes.
  • One or two minor 1.3 tweaks.
  • All the Mac OS X 10.6 deprecated stuff is cleaned out.

http://hg.icculus.org/icculus/SDL-experimental/shortlog

…this will move to the main repo after some testing.

–ryan.

Any chance of removing the #pragma pack(push,4) and #pragma pack(pop) in
include/begin_code.h and include/close_code.h ?

Right now this is causing just pain for writing and support FFI libs
(64-bit, 32-bit) - especially when more compilers are used.

Ironically, those are there so it works with multiple compilers.

Without it, structs don’t line up when you build an app with (for
example) Watcom C++, using an SDL.dll compiled with Visual Studio.

However:
http://luajit.org/ext_ffi_api.html

“C declarations [via ffi.cdef] are not passed through a C pre-processor,
yet. No pre-processor tokens are allowed, except for #pragma pack.”

Can you just specify packing in here?

–ryan.

Thanks Ryan!

I’m aware of the luajit’s ffi pack pragmas, it’s just that the library
itself won’t tell with what it was compiled to know whether the pragma
should be in effect or not - gcc (cygwin/mngw) compiled vs. other window
compilers.

But I already saw in my other post, that you consider omitting GCC from
the packing an error, so I’ll wait and see :slight_smile:

Cheers!On 8/25/2011 11:14 AM, Ryan C. Gordon wrote:

Any chance of removing the #pragma pack(push,4) and #pragma pack(pop) in
include/begin_code.h and include/close_code.h ?

Right now this is causing just pain for writing and support FFI libs
(64-bit, 32-bit) - especially when more compilers are used.

Ironically, those are there so it works with multiple compilers.

Without it, structs don’t line up when you build an app with (for
example) Watcom C++, using an SDL.dll compiled with Visual Studio.

However:
http://luajit.org/ext_ffi_api.html

“C declarations [via ffi.cdef] are not passed through a C pre-processor,
yet. No pre-processor tokens are allowed, except for #pragma pack.”

Can you just specify packing in here?