From wdouglass at carnegierobotics.com Tue Nov 2 18:11:29 2021 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Wed, 3 Nov 2021 01:11:29 +0000 Subject: [CM] C Stack Unwinding Message-ID: Hey all, I have a question about s7 error handling in C. consider the attached c file. It uses `s7_call_with_catch` to call a function that's defined in C, but has an error. The error handler gets invoked, but the result of it is returned at line 4, from s7_eval_c_string, and not from s7_call_with_catch at line 23. also, an "unknown operator" error gets printed. I made the (bad) assumption that s7 used some setjmp/longjmp magic to unwind the C stack when an error gets invoked to the catch location. lesson learned. Is there a more elegant way to detect errors then "check after every s7 function call"? am i missing something here? Thanks so much, Woody Douglass. -------------- next part -------------- A non-text attachment was scrubbed... Name: testerror.c Type: text/x-csrc Size: 951 bytes Desc: testerror.c URL: From bil at ccrma.Stanford.EDU Wed Nov 3 06:47:09 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 03 Nov 2021 06:47:09 -0700 Subject: [CM] C Stack Unwinding In-Reply-To: References: Message-ID: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> There is a bug in s7 -- it did not protect against a stack underflow because it incorrectly assumed the s7_call_with_catch was in a context where some scheme code was awaiting a result, not all by itself (hence the "unknown operator" or "stack underflow"). I need to test my bugfix -- I will try to make a new version of s7 later today. With that fixed, s7_call_with_catch returns #t because the error was caught -- "ret" in bad_func is #f, bad_func displays "#f\n", then returns #t. So "result" is #t. Thanks very much for the bug report! From wdouglass at carnegierobotics.com Wed Nov 3 08:03:58 2021 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Wed, 3 Nov 2021 15:03:58 +0000 Subject: [CM] C Stack Unwinding In-Reply-To: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> Message-ID: <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> I think i may still be missing something -- shouldn't the stack unwind past the display call in bad_func, and return the #f from the error function directly from s7_call_with_catch? alternatively, is there a general way to determine if a given s7 call returned an object from an error handler? I'm trying to treat `s7_call_with_catch` in C the same way i'd treat `catch` in scheme, but it seems i'll have to make a bunch of intermediate error checks anyway...is this true? Thanks again, Woody On Wed, 2021-11-03 at 06:47 -0700, bil at ccrma.Stanford.EDU wrote: > There is a bug in s7 -- it did not protect against a stack underflow > because it incorrectly assumed the s7_call_with_catch was in a > context where some scheme code was awaiting a result, not all by > itself > (hence the "unknown operator" or "stack underflow"). I need to test > my > bugfix -- I will try to make a new version of s7 later today. > > With that fixed, s7_call_with_catch returns #t because the error was > caught -- "ret" in bad_func is #f, bad_func displays "#f\n", then > returns #t. So "result" is #t. > > Thanks very much for the bug report! > From bil at ccrma.Stanford.EDU Wed Nov 3 10:37:33 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 03 Nov 2021 10:37:33 -0700 Subject: [CM] C Stack Unwinding In-Reply-To: <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> Message-ID: <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> If you had called s7_error, rather than s7_eval_c_string, it would have behaved as you expect, but s7_eval interposes its own set_jmp, so s7_eval_c_string jumps to it. It might be possible to make these more consistent. But it's easy to get around this -- just include a catch in the scheme code, return an error indication from scheme, and return from bad_func if one is seen. From wdouglass at carnegierobotics.com Wed Nov 3 13:04:20 2021 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Wed, 3 Nov 2021 20:04:20 +0000 Subject: [CM] C Stack Unwinding In-Reply-To: <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> Message-ID: I see -- thank you very much! -Woody On Wed, 2021-11-03 at 10:37 -0700, bil at ccrma.Stanford.EDU wrote: > If you had called s7_error, rather than s7_eval_c_string, > it would have behaved as you expect, but s7_eval interposes > its own set_jmp, so s7_eval_c_string jumps to it. > It might be possible to make these more consistent. > But it's easy to get around this -- just include a > catch in the scheme code, return an error indication > from scheme, and return from bad_func if one is seen. > From wdouglass at carnegierobotics.com Thu Nov 4 05:16:11 2021 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Thu, 4 Nov 2021 12:16:11 +0000 Subject: [CM] C Stack Unwinding In-Reply-To: References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> Message-ID: <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> Bill, I think I found one more issue. It appears that error unwinding behaves differently depending on if the function was added via `s7_make_function` or `s7_define_function`. Consider the revised C file attached. I expect the format line (line 26) to print the same value for both calls, but the value is different. Thanks for taking one more look, Woody On Wed, 2021-11-03 at 20:04 +0000, Woody Douglass wrote: > I see -- thank you very much! > > -Woody > > On Wed, 2021-11-03 at 10:37 -0700, bil at ccrma.Stanford.EDU wrote: > > If you had called s7_error, rather than s7_eval_c_string, > > it would have behaved as you expect, but s7_eval interposes > > its own set_jmp, so s7_eval_c_string jumps to it. > > It might be possible to make these more consistent. > > But it's easy to get around this -- just include a > > catch in the scheme code, return an error indication > > from scheme, and return from bad_func if one is seen. > > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- A non-text attachment was scrubbed... Name: testerror.c Type: text/x-csrc Size: 1086 bytes Desc: testerror.c URL: From bil at ccrma.Stanford.EDU Thu Nov 4 05:56:04 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 04 Nov 2021 05:56:04 -0700 Subject: [CM] C Stack Unwinding In-Reply-To: <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> Message-ID: Argh -- this is two problems. First the documentation is incomplete or incorrect (depending on whether you've had lunch), and has been for a long time -- s7_define_function returns the function name as a symbol, whereas s7_make_function returns the function. The comment in s7.h is also wrong. Sorry about that! The second bug is that you didn't get an error when the catch process tried to apply the symbol to the error info arguments. I don't know why not yet. If you turn on S7_DEBUGGING, you'd get a complaint about trying to apply a symbol. From bil at ccrma.Stanford.EDU Thu Nov 4 06:00:03 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 04 Nov 2021 06:00:03 -0700 Subject: [CM] C Stack Unwinding In-Reply-To: <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> Message-ID: Looking back, I think s7_define_function returns the symbol because that's the way define used to work, back in 2008 -- backwards compatibility, followed by forgetfulness. From wdouglass at carnegierobotics.com Thu Nov 4 06:26:57 2021 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Thu, 4 Nov 2021 13:26:57 +0000 Subject: [CM] C Stack Unwinding In-Reply-To: References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> Message-ID: things just got even weirder. to get around the symbol problem i added define_func = s7_let_ref(s, s7_rootlet(s), define_func); so that define_func was the function and not a symbol. Now, the results are still not consistent -- instead of getting #f #t like i did before this change, i now get division-by-zero #t instead of my catch being called, it seems like the default one is being called I'd eventually like to write a wrapper for s7_eval that looks something like this bool s7_eval_errorcheck(s7_scheme *s, s7_pointer arg, s7_pointer *out); which returns true if out is the result of an error handler, and false if not. that way, c functions can do something like s7_pointer in, out; //initialize in here if (s7_eval_errorcheck(s, in, &out)) { //do any c unwinding/cleanup, and then re-raise the //error to get back to where we started s7_error(s, s7_car(out), s7_cdr(out)); } I'm still trying to figure out how feasible this is, any advice is appreciated! Thanks again, Woody On Thu, 2021-11-04 at 05:56 -0700, bil at ccrma.Stanford.EDU wrote: > Argh -- this is two problems. First the documentation > is incomplete or incorrect (depending on whether you've > had lunch), and has been for a long time -- s7_define_function > returns the function name as a symbol, whereas s7_make_function > returns the function. The comment in s7.h is also wrong. > Sorry about that! The second bug is that you didn't get > an error when the catch process tried to apply the symbol > to the error info arguments. I don't know why not yet. > If you turn on S7_DEBUGGING, you'd get a complaint > about trying to apply a symbol. > From wdouglass at carnegierobotics.com Thu Nov 4 06:37:17 2021 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Thu, 4 Nov 2021 13:37:17 +0000 Subject: [CM] C Stack Unwinding In-Reply-To: References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> Message-ID: Sorry for the message flood, but I have one more thing to show. See the attached C file It seems consecutive calls to s7_call_with_catch carry some state; consecutive calls with the same arguments and no global state manipulation show different results. Thanks again, and sorry again for the email avalanche! Woody On Thu, 2021-11-04 at 13:26 +0000, Woody Douglass wrote: > things just got even weirder. to get around the symbol problem i > added > > define_func = s7_let_ref(s, s7_rootlet(s), define_func); > > so that define_func was the function and not a symbol. Now, the > results > are still not consistent -- instead of getting > #f #t > like i did before this change, i now get > division-by-zero #t > > instead of my catch being called, it seems like the default one is > being called > > > I'd eventually like to write a wrapper for s7_eval that looks > something > like this > > bool s7_eval_errorcheck(s7_scheme *s, s7_pointer arg, s7_pointer > *out); > > which returns true if out is the result of an error handler, and > false > if not. that way, c functions can do something like > > s7_pointer in, out; > //initialize in here > if (s7_eval_errorcheck(s, in, &out)) { > //do any c unwinding/cleanup, and then re-raise the > //error to get back to where we started > s7_error(s, s7_car(out), s7_cdr(out)); > } > > I'm still trying to figure out how feasible this is, any advice is > appreciated! > > Thanks again, > Woody > > On Thu, 2021-11-04 at 05:56 -0700, bil at ccrma.Stanford.EDU wrote: > > Argh -- this is two problems. First the documentation > > is incomplete or incorrect (depending on whether you've > > had lunch), and has been for a long time -- s7_define_function > > returns the function name as a symbol, whereas s7_make_function > > returns the function. The comment in s7.h is also wrong. > > Sorry about that! The second bug is that you didn't get > > an error when the catch process tried to apply the symbol > > to the error info arguments. I don't know why not yet. > > If you turn on S7_DEBUGGING, you'd get a complaint > > about trying to apply a symbol. > > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- A non-text attachment was scrubbed... Name: testerror3.c Type: text/x-csrc Size: 909 bytes Desc: testerror3.c URL: From bil at ccrma.Stanford.EDU Thu Nov 4 06:52:03 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 04 Nov 2021 06:52:03 -0700 Subject: [CM] C Stack Unwinding In-Reply-To: References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> Message-ID: <22ce1b27e2cbf818f9e8340bf569a9d7@ccrma.stanford.edu> I think these are the same bug as before (stack underflow) -- I didn't fix it correctly yesterday -- will poke at it. From j_hearon at hotmail.com Fri Nov 5 10:59:39 2021 From: j_hearon at hotmail.com (James Hearon) Date: Fri, 5 Nov 2021 17:59:39 +0000 Subject: [CM] mus-chebyshev-u-sum Message-ID: Hi, I'm trying and failing to get my head around mus-chebyshev sums. For predictability I was trying to achieve the square wave output but getting hung up. The manual says mus-chebyshev-tu-sum and friends perform the same function as partials->polynomial, but it takes a coeffs vector too, so I'm confused about how you would perform additive synthesis (as square wave) with it? I get the parts about phase, and ability to set individual partial amps etc., but can't quite figure what coeffs needs. My three tries for the coeffs vector don't seem to work. I guess I'm thinking phase and amps are not all that critical as long as the coeffs are correct, but I could be wrong. But maybe it's the other way round where you can only do it thru phase and amps and the coeffs are not that critical. (with-sound (:srate 48000 :channels 1 :play #t) (let* ((dur 1.0) (samps (seconds->samples dur)) (coeffs (partials->polynomial (float-vector 1 1 3 1/3 5 1/5 7 1/7 9 1/9) mus-chebyshev-second-kind)) ;(coeffs (float-vector 1 1 3 1/3 5 1/5 7 1/7 9 1/9)) ;(coeffs #r(0.8349206349206351 0.0 -2.082539682539683 0.0 18.43809523809524 0.0 -40.63492063492063 0.0 28.44444444444444 0.0)) (x 0.0) (incr (hz->radians 200.0)) ) (do ((i 0 (+ i 1))) ((= i samps)) (outa i (* 0.01 (mus-chebyshev-u-sum x coeffs))) (set! x (+ x incr)) ))) Thank you, Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Fri Nov 5 11:32:14 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Fri, 05 Nov 2021 11:32:14 -0700 Subject: [CM] mus-chebyshev-u-sum In-Reply-To: References: Message-ID: <16aa033847bc626a9c43c09bff6196fb@ccrma.stanford.edu> mus-chebyshev-u-sum takes a list of partial (harmonic) amplitudes: (with-sound (:srate 48000 :channels 1 :play #t) (let* ((dur 1.0) (samps (seconds->samples dur)) (coeffs (float-vector 0 1 0 1/3 0 1/5 0 1/7 0 1/9)) (incr (hz->radians 200.0))) (do ((i 0 (+ i 1)) (x 0.0 (+ x incr))) ((= i samps)) (outa i (* 0.1 (mus-chebyshev-u-sum x coeffs)))))) From wdouglass at carnegierobotics.com Wed Nov 10 08:30:38 2021 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Wed, 10 Nov 2021 16:30:38 +0000 Subject: [CM] C Stack Unwinding In-Reply-To: <22ce1b27e2cbf818f9e8340bf569a9d7@ccrma.stanford.edu> References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> <22ce1b27e2cbf818f9e8340bf569a9d7@ccrma.stanford.edu> Message-ID: Bill, See the attached patch which is against git revision 15849c52b4ee59eacae99a72f7486cc9f877b845. The patch keeps a jmp_buf with each catch object, so that if a longjmp is required, it won't return to the wrong place. It seems to work in the trivial testing i've done, but it's very possible I've missed something. One thing this doesn't address is cleaning up data that may exist in functions that called s7_eval that get "jumped over" as part of the catch process -- maybe a seperate stack of "cleanup functions" with signature `void (*)(void *)` so 'free' could be passed? Let me know what you think! Thanks, Woody On Thu, 2021-11-04 at 06:52 -0700, bil at ccrma.Stanford.EDU wrote: > I think these are the same bug as before (stack > underflow) -- I didn't fix it correctly yesterday -- > will poke at it. > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Store-a-Jmp_Buf-with-each-catch-object-and-jump-to-i.patch Type: text/x-patch Size: 4390 bytes Desc: 0001-Store-a-Jmp_Buf-with-each-catch-object-and-jump-to-i.patch URL: From bil at ccrma.Stanford.EDU Wed Nov 10 10:43:52 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 10 Nov 2021 10:43:52 -0800 Subject: [CM] C Stack Unwinding In-Reply-To: References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> <22ce1b27e2cbf818f9e8340bf569a9d7@ccrma.stanford.edu> Message-ID: Thanks -- that looks interesting. One problem is that a Jmp_Buf takes 200 bytes, so the s7_cell size is now 240 bytes (rather than 48) -- I think we'd want a pointer to a Jmp_Buf. From wdouglass at carnegierobotics.com Wed Nov 10 10:52:13 2021 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Wed, 10 Nov 2021 18:52:13 +0000 Subject: [CM] C Stack Unwinding In-Reply-To: References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> <22ce1b27e2cbf818f9e8340bf569a9d7@ccrma.stanford.edu> Message-ID: that makes a ton of sense, i guess we could just point to the buffer that's already on the stack. I'll send a revised patch in a bit On Wed, 2021-11-10 at 10:43 -0800, bil at ccrma.Stanford.EDU wrote: > Thanks -- that looks interesting. One problem is that > a Jmp_Buf takes 200 bytes, so the s7_cell size is now > 240 bytes (rather than 48) -- I think we'd want a > pointer to a Jmp_Buf. > From wdouglass at carnegierobotics.com Wed Nov 10 11:11:16 2021 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Wed, 10 Nov 2021 19:11:16 +0000 Subject: [CM] C Stack Unwinding In-Reply-To: References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> <22ce1b27e2cbf818f9e8340bf569a9d7@ccrma.stanford.edu> Message-ID: Ok, attached is the revised patch. I did have to resort to making a copy of the jmp_buf on the (C) stack, but it's better then one in every cell! let me know what you think. Thanks, Woody On Wed, 2021-11-10 at 18:52 +0000, Woody Douglass wrote: > that makes a ton of sense, i guess we could just point to the buffer > that's already on the stack. I'll send a revised patch in a bit > > On Wed, 2021-11-10 at 10:43 -0800, bil at ccrma.Stanford.EDU wrote: > > Thanks -- that looks interesting. One problem is that > > a Jmp_Buf takes 200 bytes, so the s7_cell size is now > > 240 bytes (rather than 48) -- I think we'd want a > > pointer to a Jmp_Buf. > > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Store-a-Jmp_Buf-with-each-catch-object-and-jump-to-i.patch Type: text/x-patch Size: 4772 bytes Desc: 0001-Store-a-Jmp_Buf-with-each-catch-object-and-jump-to-i.patch URL: From bil at ccrma.Stanford.EDU Wed Nov 10 13:08:44 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 10 Nov 2021 13:08:44 -0800 Subject: [CM] C Stack Unwinding In-Reply-To: References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> <22ce1b27e2cbf818f9e8340bf569a9d7@ccrma.stanford.edu> Message-ID: <3b952c096b021a5f07c9b3ad1ccccd70@ccrma.stanford.edu> I merged in your changes, and they pass all my bazillion tests. One timing test is 2% slower -- callgrind blames fprintf, but there is no fprintf! I made other changes, so this is probably something unrelated to your code. Thanks again for the improvement! From wdouglass at carnegierobotics.com Wed Nov 10 13:23:02 2021 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Wed, 10 Nov 2021 21:23:02 +0000 Subject: [CM] C Stack Unwinding In-Reply-To: <3b952c096b021a5f07c9b3ad1ccccd70@ccrma.stanford.edu> References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> <22ce1b27e2cbf818f9e8340bf569a9d7@ccrma.stanford.edu> <3b952c096b021a5f07c9b3ad1ccccd70@ccrma.stanford.edu> Message-ID: Cool! thanks so much! One thing I have noticed in my testing today is that result1 = s7_call_with_catch(s, tag, make_func, catch); behaves differently from result1 = s7_eval_c_string(s, "(catch #t bad-func error-handler)"); now. I suspect that one (or more) of the catch_cstack(p) = NULL; lines i added to s7.c needs to change, but i'm not sure which (all?) I'll have more information in the morning, i'm still wrapping my head around it. Thanks again for merging! -Woody On Wed, 2021-11-10 at 13:08 -0800, bil at ccrma.Stanford.EDU wrote: > I merged in your changes, and they pass all my bazillion > tests. One timing test is 2% slower -- callgrind > blames fprintf, but there is no fprintf! I made other > changes, so this is probably something unrelated to > your code. Thanks again for the improvement! > From wdouglass at carnegierobotics.com Thu Nov 11 05:11:28 2021 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Thu, 11 Nov 2021 13:11:28 +0000 Subject: [CM] C Stack Unwinding In-Reply-To: References: <577c160e8b9285fcedf23fef353a0732@ccrma.stanford.edu> <637f4cf6b92802c86f4e3181e5781011fc5ac313.camel@carnegierobotics.com> <40249fdcde054ddbfcab8aafb28c7cdc@ccrma.stanford.edu> <9bbc0e8b2acefefc9969d54234070e296c496851.camel@carnegierobotics.com> <22ce1b27e2cbf818f9e8340bf569a9d7@ccrma.stanford.edu> <3b952c096b021a5f07c9b3ad1ccccd70@ccrma.stanford.edu> Message-ID: <6a2d6df27fd77f18753af1e29da773f0f2d3437e.camel@carnegierobotics.com> I think i may have solved the issue i mentioned below. It looks like a catch always needs to carry a jmp_buf pointer, so that nested eval statements are handled properly. consider the attached patch, and the C file that tests it. Thanks, Woody On Wed, 2021-11-10 at 21:23 +0000, Woody Douglass wrote: > Cool! thanks so much! > > One thing I have noticed in my testing today is that > > result1 = s7_call_with_catch(s, tag, make_func, catch); > > behaves differently from > > result1 = s7_eval_c_string(s, "(catch #t bad-func error- > handler)"); > > now. I suspect that one (or more) of the > > catch_cstack(p) = NULL; > > lines i added to s7.c needs to change, but i'm not sure which (all?) > > I'll have more information in the morning, i'm still wrapping my head > around it. Thanks again for merging! > > -Woody > > On Wed, 2021-11-10 at 13:08 -0800, bil at ccrma.Stanford.EDU wrote: > > I merged in your changes, and they pass all my bazillion > > tests. One timing test is 2% slower -- callgrind > > blames fprintf, but there is no fprintf! I made other > > changes, so this is probably something unrelated to > > your code. Thanks again for the improvement! > > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-always-store-the-jump-point-with-a-catch.patch Type: text/x-patch Size: 6327 bytes Desc: 0001-always-store-the-jump-point-with-a-catch.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testerror5.c Type: text/x-csrc Size: 1134 bytes Desc: testerror5.c URL: From chris.actondev at gmail.com Mon Nov 15 16:29:39 2021 From: chris.actondev at gmail.com (Christos Vagias) Date: Tue, 16 Nov 2021 01:29:39 +0100 Subject: [CM] Multiple s7_gc_protect/unprotect leading to segfault Message-ID: Hi Bil, I stumbled upon a case where s7 is segfaulting. See the attached files. g++ -o main ./main.cpp s7.o -ldl -I. ./main 1000 # ok ./main 10000 # seg fault Thanks, Christos -------------- next part -------------- A non-text attachment was scrubbed... Name: main.cpp Type: text/x-c++src Size: 2121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.scm Type: text/x-scheme Size: 631 bytes Desc: not available URL: From bil at ccrma.Stanford.EDU Tue Nov 16 02:37:08 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 16 Nov 2021 02:37:08 -0800 Subject: [CM] =?utf-8?q?Multiple_s7=5Fgc=5Fprotect/unprotect_leading_to_se?= =?utf-8?q?gfault?= In-Reply-To: References: Message-ID: I haven't had my coffee yet this morning, but I think you're calling free_vec in s7_free; it tries to unprotect an object, but the sc->protected_objects vector in s7 has already been freed by s7_free. From bil at ccrma.Stanford.EDU Tue Nov 16 05:24:30 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 16 Nov 2021 05:24:30 -0800 Subject: [CM] =?utf-8?q?Multiple_s7=5Fgc=5Fprotect/unprotect_leading_to_se?= =?utf-8?q?gfault?= In-Reply-To: References: Message-ID: I think this can be fixed by moving the c_objects list to the top of s7_free, so any C++ deallocators have everything in s7 available to them. From chris.actondev at gmail.com Tue Nov 16 11:19:09 2021 From: chris.actondev at gmail.com (Christos Vagias) Date: Tue, 16 Nov 2021 20:19:09 +0100 Subject: [CM] Multiple s7_gc_protect/unprotect leading to segfault In-Reply-To: References: Message-ID: Oh! So simple! Indeed, moved the gp = sc->c_objects; .. to the top and it's working fine! Thanks! On Tue, 16 Nov 2021 at 14:24, wrote: > > I think this can be fixed by moving the c_objects list > to the top of s7_free, so any C++ deallocators have > everything in s7 available to them. > > From bil at ccrma.Stanford.EDU Tue Nov 16 11:56:35 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 16 Nov 2021 11:56:35 -0800 Subject: [CM] Snd 21.9 Message-ID: <13904a983b3a9dab5bdbb358c74a0a6c@ccrma.stanford.edu> Snd 21.9 s7: mainly work on error handling checked: Ubuntu 21.10, notcurses 2.4.5|7|8, sbcl 2.1.10, Fedora 35 Thanks!: Christos Vagias, Woody Douglass From j_hearon at hotmail.com Thu Nov 18 16:48:33 2021 From: j_hearon at hotmail.com (James Hearon) Date: Fri, 19 Nov 2021 00:48:33 +0000 Subject: [CM] mus-chebyshev-u-sum Message-ID: re: mus-chebyshev-u-sum takes a list of partial (harmonic) amplitudes: (with-sound (:srate 48000 :channels 1 :play #t) (let* ((dur 1.0) (samps (seconds->samples dur)) (coeffs (float-vector 0 1 0 1/3 0 1/5 0 1/7 0 1/9)) (incr (hz->radians 200.0))) (do ((i 0 (+ i 1)) (x 0.0 (+ x incr))) ((= i samps)) (outa i (* 0.1 (mus-chebyshev-u-sum x coeffs)))))) Sorry, I had not replied "thank you" for this info re: the input format of the float-vector. I was able to dig deeper and get a better understanding of the output values for mus-chebyshev-u-sum by looking carefully at clm.c. From what I gather, the sum result simply sets the amp level of each sample in the timedomain. I'm still not completely clear on the role phase plays per sample, but I'll keep thinking about that. I'm amazed at how much chebyshev there is in Snd. I hadn't taken notice of that until recently. Polywave, Chebyshev sums, Chebyshev Coefficients, Chebyshev Filters etc. regards, Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdouglass at carnegierobotics.com Fri Nov 19 08:10:23 2021 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Fri, 19 Nov 2021 16:10:23 +0000 Subject: [CM] *s7* 'cpu-time Message-ID: Bill et al., while benchmarking come code, under debian with glibc 2.28, I noticed that (*s7* 'cpu-time) didn't return what i expect. I'm still not sure why; i think the code as written should work; however, i can fix my issue with the attached patch Thanks, Woody Douglass -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-use-my_clock-for-s7-cpu_time.patch Type: text/x-patch Size: 1198 bytes Desc: 0001-use-my_clock-for-s7-cpu_time.patch URL: From bil at ccrma.Stanford.EDU Fri Nov 19 09:45:24 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Fri, 19 Nov 2021 09:45:24 -0800 Subject: [CM] *s7* 'cpu-time In-Reply-To: References: Message-ID: The manpage claims clock is implemented on top of clock_gettime, so I wouldn't expect them to be very different. clock is very slow for some reason, so I went down a level in my_clock (using clock_gettime) mainly for the profiler. I'll use my_clock in the cpu-time calc. From iainduncanlists at gmail.com Sat Nov 27 14:39:18 2021 From: iainduncanlists at gmail.com (Iain Duncan) Date: Sat, 27 Nov 2021 14:39:18 -0800 Subject: [CM] Scheme for Pd is "officially" released Message-ID: Hi friends, I have now "officially" released Scheme for Pd, with binaries available for Mac and Windows (linux builds with make), and tutorial videos up on youtube on installation and first steps. It ports most of Scheme for Max, but is more minimal so much more hacker friendly if one wanted to extend it. (The internals are dramatically simplified by Pd's single thread model). Project and binaries live here: https://github.com/iainctduncan/scheme-for-pd Bill, if you don't mind updating the s7.html page to mention that it's now both Max and Pd, that would be lovely! Thanks again tp everyone who helped make this possible with your contributions and answers. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: