[chuck-users] Anyone else running ChucK dual-core in 64-bit mode?
ken at restivo.org
Sat Apr 28 13:55:30 EDT 2007
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, Apr 27, 2007 at 11:09:50AM -0700, Ken Restivo wrote:
> On Fri, Apr 27, 2007 at 06:00:10PM +0200, Michel Koppelaar wrote:
> > Hi,
> > I seem to be having the same problem. I've been trying to get ChucK to run on AMD64/Linux these last few days. Tried alsa, oss and jack build options: segfaults in each case. More details:
> > Hopefully this can be sorted out. I'm really interested in trying out ChucK.
> Hmm, I dug around a bit, not really knowing what I'm doing, but I suspect that the culprit is probably an assumption about the size of UINTS... a 32-bit vs 64-bit issue. My eye was drawn to that OBJ_MEMBER_UINT() macro, and I took a shimmering journey into the through-the-looking-glass world of defines on top of defines on top of defines:
> #define OBJ_MEMBER_UINT(obj,offset) (*(t_CKUINT *)OBJ_MEMBER_DATA(obj,offset))
> #define t_CKUINT t_CKDWORD
> #define t_CKDWORD unsigned long
> There's also this:
> #define OBJ_MEMBER_DATA(obj,offset) (obj->data + offset)
> So, if offset just happens to be a 32-bit value, that smells to me like a likely source of a segfault. Offset probably needs to be a long long, doesn't it?
I asked a friend who does a lot of C++ work to take a brief look at this.
He shook his head sadly at the use of macros instead of inline functions, the use of casts to obliterate type safety, of #define's instead of typedefs, and the obscuring of the likelihood that ->data is a struct. He said, basically, this is C, not C++, regardless of what the file extension says. I poked around some more and it looks like a lot of the Ugen code was lifted from another, older project-- maybe that was C code?
He also didn't hold out much hope that any of its developers would show any interest in fixing this stuff either. The OBJ_MEMBER_UINT's are all over the filter, osc, xxx(?!), and stk ugens, as well as the Std lib. The obj->data stuff is in chuck_instr.cpp but nowhere else. But it's hard to tell how much stuff like this is lurking elsewhere in the code.
I'd be willing to do the gruntwork of search-and-replacing code, if someone who knows what they're doing wants to tell me pretty much exactly what to do. If nobody jumps up to do that over the next day or two, it'd probably be a better use of time to start learning CSound instead, and maybe have another look at ChucK in a few years if anyone gets it 64-bit safe by then.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the chuck-users