Dear list, I've decided to give "bus error" a proper kenning: "Clemow's Bane." Observe: //------------------------------------------------------------- // GrainDef version of tableMusic SinOsc s; fun void trig( float f ) { f => s.freq; } //------------------------------------------------------------- // osc event creator function fun OscEvent createOscEvent( string address, int port ) { OscRecv recv; port => recv.port; recv.listen(); recv.event( address ) @=> OscEvent oe; return oe; } // shred reference Shred ltrig; // chfreq shred definition fun void listenTrig() { createOscEvent( "/test, f", 12345 ) @=> OscEvent oe; while( oe => now ) { if( oe.nextMsg() ) { oe.getFloat() => float f; spork ~ trig( f ); } me.yield(); } } // this is the interesting bit... //------------------------------------------------------------- spork ~ listenTrig() @=> ltrig; // I KILL CHUCK V1.2.1.2 // spork ~ listenTrig(); // I DO NOT KILL CHUCK V1.2.1.2 me.yield(); while( true ) { 1::second => now; } //------------------------------------------------------------- This is generally how I do OSC servers in Chuck. I have to remove the shred reference in the latest version, however, or else my code crashes chuck hard. I haven't been able to test this out on a Linux box yet, but my guess is that someone should be able to make it barf something more helpful than "bus error." Kas, do you think that this is related to the bus errors we were getting assigning objects in that GrainPattern class? Cheers, Mike -- http://semiotech.org http://semiotech.org/michael
Hey mike!
I've decided to give "bus error" a proper kenning: "Clemow's Bane."
Ow, come on, the bus errors like you, they just want to play.
Kas, do you think that this is related to the bus errors we were getting assigning objects in that GrainPattern class?
I wouldn't be surprised. Something seems to be rather wrong with assignment these days. This kind of structure (assigning a sporked function to a Shred object) did work with that syntax in the past so it could be the new reference counting being over-active again. I just simplified your code to make the real culprit come out; //================8<================== fun void dummy() { while(1) { second => now; } } Shred foo; //this runs //spork ~ dummy(); //I get a segmentation fault at this on Ubuntu spork ~ dummy() @=> foo; hour => now; //==============8<================== I really think this used to work. To make matters worse this (assuming the same function) seems to work ok; //============================= spork ~ dummy() @=> Shred foo; hour => now; //=============================== I wouldn't be surprised if it was at least related because I can't think of anything else that would break this. At least it should help pinpoint the culprit. I suggest add it to the Wiki bug page and we try sprinkling some variation of the working version with some "@" signs. Sprinkling magical "@" signs seems to pacify this bug ;¬). Yours, Kas.
Kas,
I really think this used to work. To make matters worse this (assuming the same function) seems to work ok;
//============================= spork ~ dummy() @=> Shred foo; hour => now; //===============================
So, if we declare the Shred reference at the same time it doesn't
cause an error?? This might be the work-around for the time being...
Thanks!
-Mike
On Sun, Oct 12, 2008 at 4:17 PM, Kassen
Hey mike!
I've decided to give "bus error" a proper kenning: "Clemow's Bane."
Ow, come on, the bus errors like you, they just want to play.
Kas, do you think that this is related to the bus errors we were getting assigning objects in that GrainPattern class?
I wouldn't be surprised. Something seems to be rather wrong with assignment these days. This kind of structure (assigning a sporked function to a Shred object) did work with that syntax in the past so it could be the new reference counting being over-active again.
I just simplified your code to make the real culprit come out;
//================8<================== fun void dummy() { while(1) { second => now; } }
Shred foo; //this runs //spork ~ dummy();
//I get a segmentation fault at this on Ubuntu spork ~ dummy() @=> foo;
hour => now; //==============8<==================
I really think this used to work. To make matters worse this (assuming the same function) seems to work ok;
//============================= spork ~ dummy() @=> Shred foo; hour => now; //===============================
I wouldn't be surprised if it was at least related because I can't think of anything else that would break this.
At least it should help pinpoint the culprit. I suggest add it to the Wiki bug page and we try sprinkling some variation of the working version with some "@" signs. Sprinkling magical "@" signs seems to pacify this bug ;¬).
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Yup, that totally worked on a Mac too.
That's WEIRD.
Thanks Kas!
-Mike
On Sun, Oct 12, 2008 at 4:41 PM, mike clemow
Kas,
I really think this used to work. To make matters worse this (assuming the same function) seems to work ok;
//============================= spork ~ dummy() @=> Shred foo; hour => now; //===============================
So, if we declare the Shred reference at the same time it doesn't cause an error?? This might be the work-around for the time being...
Thanks! -Mike
On Sun, Oct 12, 2008 at 4:17 PM, Kassen
wrote: Hey mike!
I've decided to give "bus error" a proper kenning: "Clemow's Bane."
Ow, come on, the bus errors like you, they just want to play.
Kas, do you think that this is related to the bus errors we were getting assigning objects in that GrainPattern class?
I wouldn't be surprised. Something seems to be rather wrong with assignment these days. This kind of structure (assigning a sporked function to a Shred object) did work with that syntax in the past so it could be the new reference counting being over-active again.
I just simplified your code to make the real culprit come out;
//================8<================== fun void dummy() { while(1) { second => now; } }
Shred foo; //this runs //spork ~ dummy();
//I get a segmentation fault at this on Ubuntu spork ~ dummy() @=> foo;
hour => now; //==============8<==================
I really think this used to work. To make matters worse this (assuming the same function) seems to work ok;
//============================= spork ~ dummy() @=> Shred foo; hour => now; //===============================
I wouldn't be surprised if it was at least related because I can't think of anything else that would break this.
At least it should help pinpoint the culprit. I suggest add it to the Wiki bug page and we try sprinkling some variation of the working version with some "@" signs. Sprinkling magical "@" signs seems to pacify this bug ;¬).
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
2008/10/12 mike clemow
Yup, that totally worked on a Mac too.
That's WEIRD.
No, that's good! I want as little difference between the versions as possible. I'm already juggling; Linux, commandline (latest greatest, canonical) Linux, Mini (my own build with the latest version of the CK source, seems to work... so far) Windows (latest greatest but modded to use ASIO, needs to run in compatibility mode) Windows Mini (official version, so lagging one version of ChucK). I need yet more differences between versions like I need a ice-pick to the ear. it's great that the core stuff is identical and we can trade and share code.
Thanks Kas!
You're welcome, pinpointing was hardly any effort here. If you'd like; add your catch to the Wiki for tracking. It's a nice one, will make a fine trophy. :¬) Kas.
I'm glad it's the same bug cross platforms, I just think it's a weird
bug, that's all.
Do I add to the bottom of the bugs page or the top?
-Mike
On Sun, Oct 12, 2008 at 5:03 PM, Kassen
2008/10/12 mike clemow
Yup, that totally worked on a Mac too.
That's WEIRD.
No, that's good! I want as little difference between the versions as possible. I'm already juggling; Linux, commandline (latest greatest, canonical) Linux, Mini (my own build with the latest version of the CK source, seems to work... so far)
Windows (latest greatest but modded to use ASIO, needs to run in compatibility mode) Windows Mini (official version, so lagging one version of ChucK).
I need yet more differences between versions like I need a ice-pick to the ear. it's great that the core stuff is identical and we can trade and share code.
Thanks Kas!
You're welcome, pinpointing was hardly any effort here. If you'd like; add your catch to the Wiki for tracking. It's a nice one, will make a fine trophy. :¬)
Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Mike, I'm glad it's the same bug cross platforms, I just think it's a weird
bug, that's all.
Yeah, it's probably the garbage/reference stuff. I had no idea the problem was quite that bad.
Do I add to the bottom of the bugs page or the top?
I'd take the "hopefully fixed for the next release" page and somewhere in the "open" section? I think it's a pretty bad one, it must've been broken by the latest version. Kas.
Hi kas and mike, I run mike's chuck patch and didn't get a bus error... but did get it with kassen's code. However I could get rid of the error if the shred is declared but not "initilised", thus using a reference when declaring it. I think that's been always the case..., can't remember though. So adding Shred @ foo; to kassen's code let's assign to shred later. The resulting code would be: fun void dummy() { while(1) { second => now; } } Shred @ foo; spork ~ dummy() @=> foo; <<< foo.id()>>>; hour => now; eduard On Oct 12, 2008, at 11:25 PM, Kassen wrote:
Mike,
I'm glad it's the same bug cross platforms, I just think it's a weird bug, that's all.
Yeah, it's probably the garbage/reference stuff. I had no idea the problem was quite that bad.
Do I add to the bottom of the bugs page or the top?
I'd take the "hopefully fixed for the next release" page and somewhere in the "open" section? I think it's a pretty bad one, it must've been broken by the latest version.
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hi kas and mike,
Hey, Eduard.
I run mike's chuck patch and didn't get a bus error... but did get it with kassen's code.
I believe the proper term here is "WHAT?!". Could you verify the version of ChucK you are running and your OS? We now seem to be in very strange territory, I'm hoping you are on Windows so at least don't have another unknown variable. Also; I got "segmentation fault", not a "bus error" on Linux. However I could get rid of the error if the shred is declared but not
"initilised", thus using a reference when declaring it. I think that's been always the case..., can't remember though.
That would've been my next attempt as well. At least I can report that your version runs fine for me. That's at least some coherency... This is getting quite strange, and we are not even trying to do something excessively weird, this is just about the most simple thing you can do with a Shred object. I propose we set up a dragnet to catch this bug. Anyone with another data-point? Yours, Kas.
Eduard; weird... I do get a "bus error" now.
I am on OS X (intel)
Curiouser and curiouser! After such a bug I shall think nothing of the grasshopper I found on my keyboard last week¹. Yours, Kas. ¹3cm long bright green grasshoppers aren't native to urban areas in The Netherlands, perhaps some of you see them every day but I don't...
participants (3)
-
eduard aylon
-
Kassen
-
mike clemow