Hi
Attached is a piece of useless code that confuses me. Should it matter
where class kidA is defined? Is this a bug?
--
peace, love & harmony
Atte
http://www.atte.dk | quartet: http://www.anagrammer.dk
http://www.atte.dk/gps | compositions: http://www.atte.dk/compositions
class A{
fun void greet(){
<<<"hello">>>;
}
}
// works when defined here
//class kidA extends A {}
class B{
fun void greet(){
}
}
class kidB extends B{
3 => int nb_kids;
kidA kids[nb_kids];
fun void greet(){
for(0 => int i; i
Hi Atte, The example you provided reveals a bug in chuck: order of declaration mattering when it should not. It's now noted to be fixed. Sorry for the confusion. Thanks! Best, Ge! On Jul 8, 2006, at 6:24 PM, Atte André Jensen wrote:
Hi
Attached is a piece of useless code that confuses me. Should it matter where class kidA is defined? Is this a bug?
-- peace, love & harmony Atte
http://www.atte.dk | quartet: http://www.anagrammer.dk http://www.atte.dk/gps | compositions: http://www.atte.dk/compositions class A{ fun void greet(){ <<<"hello">>>; } }
// works when defined here //class kidA extends A {}
class B{ fun void greet(){ } }
class kidB extends B{ 3 => int nb_kids; kidA kids[nb_kids];
fun void greet(){ for(0 => int i; i
// doesn't work when defined here class kidA extends A {}
/* A a; a.greet();
kidA kid_a; kid_a.greet(); */
kidB kid_b; kid_b.greet();_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On 7/11/06, Ge Wang
Hi Atte,
The example you provided reveals a bug in chuck: order of declaration mattering when it should not. It's now noted to be fixed. Sorry for the confusion.
There are more problems of that type. If you have some sporked function that chucks some value to a parameter of a ugen and you define the ugen below the function it will compile, then crash the VM as soon as the sporked function tries to write to the parameter. I can't remember seeing that mentioned but it happens to me a lot if I'm not carefull. IMHO correct behaviour would be simply "swalowing" that order of declaring stuff. The one case (as far as I can see) where that could run into issues if we would declare two ugens the same name but the VM already files a complaint if we do that. Currently I need to have a block labeled "define stuff before refering to it" at the top of my files. Admittedly this is "correct" in a way but it does lead to stuff getting defined far away from it's context which leads to hard to read and hard to debug constructions. Kas.
The example you provided reveals a bug in chuck: order of declaration mattering when it should not. It's now noted to be fixed. Sorry for the confusion.
There are more problems of that type. If you have some sporked function that chucks some value to a parameter of a ugen and you define the ugen below the function it will compile, then crash the VM as soon as the sporked function tries to write to the parameter.
Yes, this is a related (but ultimately different) bug. We hope to pick it up in this summer's chug-fix-a-thon. Best wishes, Ge!
participants (3)
-
Atte André Jensen
-
Ge Wang
-
Kassen