[chuck-users] dynamic array crashes for "int ar" but not "int ar"
george.locke.maxmsp at gmail.com
Sat Jul 28 12:09:50 EDT 2012
Thanks for looking into it. I'm picking up what you're putting down,
pretty much. int ar is a reference to nothing, like a null pointer, so
asking the VM to call a method is accessing uninitialized memory, like a
seg fault. I think I shouldn't have said "crashes" when what I meant was,
the thread dies and throws an exception, not that the audicle executable
nor the VM breaks. It's a run-time error and not a syntax error; that's
what I had in mind.
I am glad to understand ChucK a little better.
On Sat, Jul 28, 2012 at 9:42 AM, Kassen <signal.automatique at gmail.com>wrote:
> > Hi,
> Hey George!
> > array.size(int) and the '<<' operator are crashing miniAudicle (version
> > 0.2.0, on Windows 7 pro). (functionality added to chuck in 22.214.171.124,
> > http://chuck.cs.princeton.edu/release/VERSIONS ). miniAudicle tells me
> > running chuck 126.96.36.199.
> > playing around a bit, I now find that if I follow what the example
> > array_dynamic.ck says and replace "int ar" with "int ar", then the
> > works. I guess that means this isn't a bug but a meaningful difference
> > between ar and ar? In any case, I might amend the array_dynamic.ckto
> > say something like
> > "float argh; // must set argh and not argh"
> Well, if ChucK crashes it's a bug; ChucK should not crash if you make
> a syntax error, it should catch it at parsing and inform you. It is
> also not unambiguously clear to me that what you tried is actually a
> error, IMHO this should be fair game, it looks natural and expressive.
> I can tell you what goes wrong though.
> "int ar" creates a reference to a array but does not instantiate it.
> You'd use it in a context like this;
> [1, 2, 3] @=> int ar;
> Evidently ar.size(int a) should instantiate the new array entries if a
> is larger than the old size, which it'll always be for uninstantiated
> arrays so I find what you tried defensible, but ChucK is also a bit
> right to complain about a null-pointer as the reference doesn't point
> to anything yet at that point. Syntactically it seems a bit awkward,
> compared to the rest of ChucK where we don't need to care about memory
> management, though it might also have uses where this kind of explicit
> control is useful.
> I hope that clarifies things a bit? If all of this sounded like
> abracadabra; just use the one that works, that's what this comes down
> to :-)
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users