Not sure about linux, but I know that for darwin linking of 32 bit binaries to 64 bit binaries is impossible. In the best case, you will have to do all sorts of tricks at the kernel level to allow 64 bit code (with pointers possibly way way up in the address space) to run in 32 bit mode. Your particular seg-fault issue may be related to an invalid alignment problem. If your OBJ_MEMBER_DATA macro evaluates to a value that isn't a multiple of the unsigned long size (8 bytes), then OBJ_MEMBER_UINT could effectively be causing an invalid instruction to be generated. You could add a check to make sure that the value OBJ_MEMBER_DATA returns in OBJ_MEMBER_UINT is a multiple of 8. _Mark On Apr 28, 2007, at 3:48 PM, Ken Restivo wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Apr 28, 2007 at 05:06:29PM -0400, Ge Wang wrote:
data is a struct. He said, basically, this is C, not C++, regardless of what
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 - 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?
These are fair criticisms in general, but sometimes we do have our own reasons for implementing things the way we do. In other instances, we probably should adopt better practices. In the end, it's just how our warped minds work. Our goal isn't necessarily to make C++ happy, but rather to make ChucK users happy (and fitter, and more productive).
No prob. Love the Radiohead reference too. And thanks for taking the time to reply, amidst preparing for your oral dissertation defense.
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.
I think it's gonna take a system-wide evaluation/fixing/testing to make things robustly 64-bit. Until then it's hard to say what needs to be done. We are fully planning to do that at some future point. For now, is it possible to compile ChucK in 32-bit mode under linux (similar to the 64-bit Apple G5)?
That was the first thing I tried, last week: compiling with -m32. Everything compiled, but the final link step failed, because it was apparently trying to link to the 32-bit versions of the JACK libraries, which obviously don't and can't exist on this system. Maybe there's some way to convince GCC to link a bunch of 32- bit .o's to 64-bit libraries?
Ironically, I got interested in ChucK because CSound seemed a very kludgy way to do audio programming. - Oh well, there's always SuperCollider ;)
We think it's a good idea to learn as many languages as possible. Different tools tailored for different tasks!
And, for what I'm doing, I find ChucK a far more natural and user- friendly language. So, I'll spend some time trying to get it running.
- -ken -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFGM89Me8HF+6xeOIcRAlBfAKDXqXtJ1VoImwgGFtaBIi9HLSi2qgCeMGdT EorX3o9C+iQqZmzQYtKAhNM= =KhYk -----END PGP SIGNATURE----- _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users