Hi Chuckists,
A question about arrays in Chuck: the manual briefly mentions "functions that have arrays as arguments or return type" but I can't seem to find an actual example of a function with an array as a return type. Does anyone know if this works, or there is a way to make it work?
If I call the function below, for instance, I get a "NullPointerException: (array access)" when I do anything with the result:
fun float[] t(float x,float nn[]) {
float rr[];
for(0 => int n;n
David,
I think the problem may be that you are returning an array that is local to
your function and it is getting deallocated when the function returns.
If you used the same syntax to instead return an object's member variable
which is an array, I think it would work as expected.
Hope that helps.
----------
Colin
2012/2/23 David Ogborn
Hi Chuckists,
A question about arrays in Chuck: the manual briefly mentions "functions that have arrays as arguments or return type" but I can't seem to find an actual example of a function with an array as a return type. Does anyone know if this works, or there is a way to make it work?
If I call the function below, for instance, I get a "NullPointerException: (array access)" when I do anything with the result:
fun float[] t(float x,float nn[]) { float rr[]; for(0 => int n;n
rr[n]; } return rr; } Yours truly, David
------------------------------------------------------------------- Dr. David Ogborn, Assistant Professor Communication Studies & Multimedia Director, Cybernetic Orchestra & ESP Studio McMaster University, Hamilton, Canada
ogbornd --at-- mcmaster.ca http://davidogborn.net http://twitter.com/ogbornd http://esp.mcmaster.ca (Cybernetic Orchestra) 1-905-525-9140 ext 27603
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On Thu, Feb 23, 2012 at 12:27:22PM -0800, Colin Sullivan wrote:
David,
I think the problem may be that you are returning an array that is local to your function and it is getting deallocated when the function returns.
That's what I thought too, and that certainly can happen. In that case a extra assignment (using @) can increase the reference count, tricking the simple CC. That's not "good form" just a workaround while some of that stuff is a bit dodgy. That's not the issue here though, at least not the primary one. The primary issue here is that rr gets defined without a length and so apparently doesn't get initiated. Editing the relevant line to read; float rr[nn.size()]; makes sure all floats are initiated and for my tests it works. I think the issue is not with returning, the reported error is refering -I suspect- to the moment when we try to chuck the result of the addition to the array location, the error just isn't indicating that, obfuscating what went wrong. I hope that helps (I also hope it's correct ;-) ) Yours, Kas.
Yes, ditto to what Kassen said. (I'm too slow... ;)
fun float[] t(float x,float nn[]) {
float rr[nn.size()];
for(0 => int n;n
On Thu, Feb 23, 2012 at 12:27:22PM -0800, Colin Sullivan wrote:
David,
I think the problem may be that you are returning an array that is local to your function and it is getting deallocated when the function returns.
That's what I thought too, and that certainly can happen. In that case a extra assignment (using @) can increase the reference count, tricking the simple CC. That's not "good form" just a workaround while some of that stuff is a bit dodgy.
That's not the issue here though, at least not the primary one. The primary issue here is that rr gets defined without a length and so apparently doesn't get initiated. Editing the relevant line to read;
float rr[nn.size()];
makes sure all floats are initiated and for my tests it works.
I think the issue is not with returning, the reported error is refering -I suspect- to the moment when we try to chuck the result of the addition to the array location, the error just isn't indicating that, obfuscating what went wrong.
I hope that helps (I also hope it's correct ;-) )
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Alternatively, you can implement this will the append operator:
fun float[] t(float x,float nn[]) {
// assign with zero length
float rr[0];
for(0 => int n;n
Yes, ditto to what Kassen said. (I'm too slow... ;)
fun float[] t(float x,float nn[]) {
float rr[nn.size()];
for(0 => int n;n
nn[n] + x => rr[n];
}
return rr;
}
<<< t(4.5, [7.,8.,9.])[2] >>>; // should print 13.5
http://michaelclemow.com http://semiotech.org
On Thu, Feb 23, 2012 at 3:45 PM, Kassen
wrote: On Thu, Feb 23, 2012 at 12:27:22PM -0800, Colin Sullivan wrote:
David,
I think the problem may be that you are returning an array that is local to your function and it is getting deallocated when the function returns.
That's what I thought too, and that certainly can happen. In that case a extra assignment (using @) can increase the reference count, tricking the simple CC. That's not "good form" just a workaround while some of that stuff is a bit dodgy.
That's not the issue here though, at least not the primary one. The primary issue here is that rr gets defined without a length and so apparently doesn't get initiated. Editing the relevant line to read;
float rr[nn.size()];
makes sure all floats are initiated and for my tests it works.
I think the issue is not with returning, the reported error is refering -I suspect- to the moment when we try to chuck the result of the addition to the array location, the error just isn't indicating that, obfuscating what went wrong.
I hope that helps (I also hope it's correct ;-) )
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Great - thanks! Yours truly, David On 2012-02-23, at 3:59 PM, mike clemow wrote:
Alternatively, you can implement this will the append operator:
fun float[] t(float x,float nn[]) {
// assign with zero length float rr[0];
for(0 => int n;n
<<< t(4.5, [7.,8.,9.])[2] >>>; // should print 13.5
http://michaelclemow.com http://semiotech.org
On Thu, Feb 23, 2012 at 3:56 PM, mike clemow
wrote: Yes, ditto to what Kassen said. (I'm too slow... ;)
fun float[] t(float x,float nn[]) {
float rr[nn.size()];
for(0 => int n;n
nn[n] + x => rr[n];
}
return rr;
}
<<< t(4.5, [7.,8.,9.])[2] >>>; // should print 13.5
http://michaelclemow.com http://semiotech.org
On Thu, Feb 23, 2012 at 3:45 PM, Kassen
wrote: On Thu, Feb 23, 2012 at 12:27:22PM -0800, Colin Sullivan wrote:
David,
I think the problem may be that you are returning an array that is local to your function and it is getting deallocated when the function returns.
That's what I thought too, and that certainly can happen. In that case a extra assignment (using @) can increase the reference count, tricking the simple CC. That's not "good form" just a workaround while some of that stuff is a bit dodgy.
That's not the issue here though, at least not the primary one. The primary issue here is that rr gets defined without a length and so apparently doesn't get initiated. Editing the relevant line to read;
float rr[nn.size()];
makes sure all floats are initiated and for my tests it works.
I think the issue is not with returning, the reported error is refering -I suspect- to the moment when we try to chuck the result of the addition to the array location, the error just isn't indicating that, obfuscating what went wrong.
I hope that helps (I also hope it's correct ;-) )
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
------------------------------------------------------------------- Dr. David Ogborn, Assistant Professor Communication Studies & Multimedia Director, Cybernetic Orchestra & ESP Studio McMaster University, Hamilton, Canada ogbornd --at-- mcmaster.ca http://davidogborn.net http://twitter.com/ogbornd http://esp.mcmaster.ca (Cybernetic Orchestra) 1-905-525-9140 ext 27603
On Thu, Feb 23, 2012 at 03:59:40PM -0500, mike clemow wrote:
Alternatively, you can implement this will the append operator:
I have been really enjoying that form lately (in Scheme, but the principle is the same). This is very nice when we have a function that is to transform a musical theme. WIth this way (and not with the straight indez-based loop) we can replace a single note with two new ones or remove it, based on some condition. I like that. Kas.
Ah, yes ye olde ref count bug. :)
On Thu, Feb 23, 2012 at 4:12 PM, Kassen
On Thu, Feb 23, 2012 at 03:59:40PM -0500, mike clemow wrote:
Alternatively, you can implement this will the append operator:
I have been really enjoying that form lately (in Scheme, but the principle is the same).
I noticed you've been using fluxus a lot the last couple of years. Lisp/Scheme is a really interesting language. I've been trying to code Chuck in as terse and elegant a manner as possible lately. I'm working on some examples that make use of some interesting Chuck easter eggs and feel that I'm bound to run into that ref count bug again. With regard to array assignment, I've been getting a lot of mileage out of using multiline statements to create arrays using the append notation. SomeObject objs[0]; objs << iReturnSomeObject(param1, param2) << iReturnSomeObject(param3, param4) << iReturnSomeObject(param5, param6) << iReturnSomeObject(param7, param8); // iterate over objs... They're great for stacks too. "<<" is like "push" and although the popBack() method just removes the last element, you can implement a proper pop() function like this. fun SomeObject pop(SomeObject objs[]) { objs[objs.size()-1] @=> SomeObject so; objs.popBack(); return so; } (This will likely get you in trouble with that ref count bug if you use it for objects. For primitives, it should work just fine.) Perhaps we can write a Scheme interpreter in Chuck? ;) -Mike
This is very nice when we have a function that is to transform a musical theme. WIth this way (and not with the straight indez-based loop) we can replace a single note with two new ones or remove it, based on some condition. I like that.
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On Thu, Feb 23, 2012 at 04:29:35PM -0500, mike clemow wrote:
(This will likely get you in trouble with that ref count bug if you use it for objects. For primitives, it should work just fine.)
Interesting!
Perhaps we can write a Scheme interpreter in Chuck? ;)
That would be pleasantly perverse... but I wouldn't try, if I were you.... I'm finding that my Scheming and my ChucKing has been quite distinct. Lately I've been working on something like SC's "patterns", except way more simple and with more focus on interacting with with running processes. Scheme seems natural for that, with its REPL. Every once in a while I think about the original design for the ChucK-shell, which seemed to be not unlike that sort of interaction, except with the option to navigate the namespace of the running program like a sort of directory tree. That seems like something that might integrate well with your "stack" idea... Kas.
Whatever became of the Chuck shell?
-mike
http://michaelclemow.com
http://semiotech.org
On Thu, Feb 23, 2012 at 4:44 PM, Kassen
On Thu, Feb 23, 2012 at 04:29:35PM -0500, mike clemow wrote:
(This will likely get you in trouble with that ref count bug if you use it for objects. For primitives, it should work just fine.)
Interesting!
Perhaps we can write a Scheme interpreter in Chuck? ;)
That would be pleasantly perverse... but I wouldn't try, if I were you....
I'm finding that my Scheming and my ChucKing has been quite distinct. Lately I've been working on something like SC's "patterns", except way more simple and with more focus on interacting with with running processes. Scheme seems natural for that, with its REPL.
Every once in a while I think about the original design for the ChucK-shell, which seemed to be not unlike that sort of interaction, except with the option to navigate the namespace of the running program like a sort of directory tree. That seems like something that might integrate well with your "stack" idea...
Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On Thu, Feb 23, 2012 at 03:56:36PM -0500, mike clemow wrote:
Yes, ditto to what Kassen said. (I'm too slow... ;)
Ha! I thought about you here, because I think you first found that reference count bug. I thought "Ah, this one I know!" trying exactly what Colin said too. It was a slightly tricky one, but the VM was correct here. Error reporting could have been better. Kas.
Hi Kas and Colin, Thanks for your help! When I properly initialized the array (local to the function, at least at first) it works - without any need for bumping up the reference count. Yours truly, David On 2012-02-23, at 3:45 PM, Kassen wrote:
On Thu, Feb 23, 2012 at 12:27:22PM -0800, Colin Sullivan wrote:
David,
I think the problem may be that you are returning an array that is local to your function and it is getting deallocated when the function returns.
That's what I thought too, and that certainly can happen. In that case a extra assignment (using @) can increase the reference count, tricking the simple CC. That's not "good form" just a workaround while some of that stuff is a bit dodgy.
That's not the issue here though, at least not the primary one. The primary issue here is that rr gets defined without a length and so apparently doesn't get initiated. Editing the relevant line to read;
float rr[nn.size()];
makes sure all floats are initiated and for my tests it works.
I think the issue is not with returning, the reported error is refering -I suspect- to the moment when we try to chuck the result of the addition to the array location, the error just isn't indicating that, obfuscating what went wrong.
I hope that helps (I also hope it's correct ;-) )
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
------------------------------------------------------------------- Dr. David Ogborn, Assistant Professor Communication Studies & Multimedia Director, Cybernetic Orchestra & ESP Studio McMaster University, Hamilton, Canada ogbornd --at-- mcmaster.ca http://davidogborn.net http://twitter.com/ogbornd http://esp.mcmaster.ca (Cybernetic Orchestra) 1-905-525-9140 ext 27603
On Thu, Feb 23, 2012 at 03:59:51PM -0500, David Ogborn wrote:
Hi Kas and Colin,
Thanks for your help! When I properly initialized the array (local to the function, at least at first) it works - without any need for bumping up the reference count.
Great! I think I remember that the reference count thing only starts affecting things for non-primitives. Floats are primitives and their references work differently internally, I think. Here "differently" should probably be read as "quite well" ;-) Yours, Kas.
participants (4)
-
Colin Sullivan
-
David Ogborn
-
Kassen
-
mike clemow