Extension fails to link on OSX64

[bil-bas]

Works fine on win32, of course.

Error is: ld: duplicate symbol _rb_cColor in color.o and ashton.o for architecture x86_64

[jlnr]

I do not get this error, but a duplicate _sin_lookup because it is defined in a header. It should be extern there, and be defined in fast_math.c.

[bil-bas]

Ah, I'll sort that out, thanks! Hate that different C compilers seem let me get away with different things...bah!

[jlnr]

FWIW the latest git head linked fine for me on 64-bit OS X.

[jlnr]

But then it crashed at runtime for this one example:

mini:examples jlnr$ ruby particle_emitter_example.rb 
dyld: lazy symbol binding failed: Symbol not found: _fast_sin_deg
  Referenced from: /Users/jlnr/.rvm/gems/ruby-1.9.3-p286/gems/ashton-0.0.1alpha/lib/ashton/1.9/ashton.bundle
  Expected in: flat namespace

dyld: Symbol not found: _fast_sin_deg
  Referenced from: /Users/jlnr/.rvm/gems/ruby-1.9.3-p286/gems/ashton-0.0.1alpha/lib/ashton/1.9/ashton.bundle
  Expected in: flat namespace

Trace/BPT trap: 5

[bil-bas]

Thanks for reporting that; I thought it all worked now. Not having a Mac is a pain, especially since your compiler is a biscuit ;)

[bil-bas]

@jlnr Can you give that example another go at compiling and running on OSX please? I got rid of inlining, so that function shouldn't be any different to any other now.

I get to render 125k particles @ 60fps in that example on Linux, which is a lot better than on Windows, which is nice! However, I get a segfault or GC exception after a while (on that example or the particle emitter benchmark), so something is still very, very wrong!

[jlnr]

Yep, it works now. It crashes after a while but until then I get ~123k particles at 50 FPS. Not as nice as your score but good enough :)

[jlnr]

FWIW the debugger points to if(particle->time_to_live > 0)

So the particle has probably been released already. Or may be the compiler just notices the unaesthetically missing space between if and ( and spits its latte all over the binary. :P

[bil-bas]

The particles don't get released. When you create the emitter, you set the max number of particles and it creates an array of structures and re-uses them. A particle that is destroyed has its time to live set to -1 or something. Saves a lot of creation and destruction, though whether it is really any faster is anyone's guess.

[bil-bas]

Incidentally, there are at least 5 lines that have if(particle->time_to_live > 0) in them :P

[jlnr]

This is the top of backtrace before the Ruby VM internals begin:

update_vbo [inlined] () at /Users/jlnr/.rvm/gems/ruby-1.9.3-p362/gems/ashton-0.0.1alpha/ext/ashton/particle_emitter.c:452
452         if(particle->time_to_live > 0)
(gdb) backtrace
#0  update_vbo [inlined] () at /Users/jlnr/.rvm/gems/ruby-1.9.3-p362/gems/ashton-0.0.1alpha/ext/ashton/particle_emitter.c:452
#1  0x0000000102f2cab0 in Ashton_ParticleEmitter_update (self=<value temporarily unavailable, due to optimizations>, delta=<value temporarily unavailable, due to optimizations>) at particle_emitter.c:781

[bil-bas]

Thanks. I think I've caught that one now (and pushed a fix), but there is another segfault happening now which doesn't give useful info in the standard report. Need to work out how to use gdb with it 😊 Windows, where I did the initial development of Ashton, just doesn't care about its memory, obviously!