<div dir="ltr">Yuck, it behaves badly on Mac, but even worse on RPi. I get to maybe 30 shreds before it tanks... rs</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 23, 2014 at 5:33 PM, Michael Heuer <span dir="ltr"><<a href="mailto:heuermh@gmail.com" target="_blank">heuermh@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oops, forgot to increment count<br>
<br>
<<<"count", count++>>>;<br>
<br>
...<br>
<br>
$ chuck --silent examples/dmxBug.ck<br>
[chuck](VM): removing shred: 2 (spork~exp)...<br>
count 0<br>
[chuck](VM): removing shred: 3 (spork~exp)...<br>
count 1<br>
<div class="">...<br>
[chuck](VM): removing shred: 144 (spork~exp)...<br>
</div>count 142<br>
<div class="">[chuck](VM): removing shred: 145 (spork~exp)...<br>
</div>count 143<br>
<div class="im HOEnZb">[chuck](VM): removing shred: 146 (spork~exp)...<br>
Segmentation fault: 11<br>
<br>
<br>
</div><div class="HOEnZb"><div class="h5">On Mon, Jun 23, 2014 at 5:31 PM, Michael Heuer <<a href="mailto:heuermh@gmail.com">heuermh@gmail.com</a>> wrote:<br>
> Interesting find, even this simple example blows for me<br>
><br>
> dmxBug.ck:<br>
><br>
> fun void blink()<br>
> {<br>
> while (true)<br>
> {<br>
> 50::ms => now;<br>
> }<br>
> }<br>
><br>
> Shred shred;<br>
> spork ~ blink() @=> shred;<br>
><br>
> 0 => int count;<br>
><br>
> while (true)<br>
> {<br>
> 200::ms => now;<br>
> <a href="http://shred.id" target="_blank">shred.id</a>() => Machine.remove;<br>
> spork ~ blink() @=> shred;<br>
> <<<"count", count>>>;<br>
> }<br>
><br>
> $ chuck --silent examples/dmxBug.ck<br>
> ...<br>
> [chuck](VM): removing shred: 144 (spork~exp)...<br>
> count 0<br>
> [chuck](VM): removing shred: 145 (spork~exp)...<br>
> count 0<br>
> [chuck](VM): removing shred: 146 (spork~exp)...<br>
> Segmentation fault: 11<br>
><br>
> michael<br>
><br>
><br>
> On Mon, Jun 23, 2014 at 5:17 PM, Ryan Supak <<a href="mailto:ryansupak@gmail.com">ryansupak@gmail.com</a>> wrote:<br>
>> Update: I eliminated everything I could from the Shreds that were being<br>
>> Sporked, and I still get the exact same error (at exactly 147 Shreds.)<br>
>><br>
>> Here is what I shortened the Shreds to:<br>
>><br>
>> fun void Blink()<br>
>> {<br>
>> while( true )<br>
>> {<br>
>> 50::ms => now;<br>
>> }<br>
>> }<br>
>><br>
>> fun void LFOMod()<br>
>> {<br>
>> while( true )<br>
>> {<br>
>> 50::ms => now;<br>
>> }<br>
>> }<br>
>><br>
>><br>
>> On Mon, Jun 23, 2014 at 4:22 PM, Ryan Supak <<a href="mailto:ryansupak@gmail.com">ryansupak@gmail.com</a>> wrote:<br>
>>><br>
>>> Thanks for the thorough reply. I'm doing one safer, even than "voice<br>
>>> stealing": each Spork is, at most, reconfiguring a single global oscillator.<br>
>>><br>
>>> Attached is the entire source. Lines 128-142 contain initialization code<br>
>>> that creates a Shred to make an LED blink by sending a MIDI message within a<br>
>>> time loop, and another Shred that sets the frequency of an LFO, polls it<br>
>>> every ten milliseconds, and sends some Serial output based on the LFO<br>
>>> position.<br>
>>><br>
>>> Anytime that the parameters controlling the blinking rate and the LFO<br>
>>> rate/phase have occasion to change (when MIDI events come in to change<br>
>>> them), the "old" Shreds are Machine.Remove'd and they're recreated<br>
>>> immediately following. You can see this at lines 343 and 589.<br>
>>><br>
>>> Notice that the LFOMod function and the Blink function aren't creating<br>
>>> anything new (with the exception of local arguments being instantiated), but<br>
>>> if you think those local arguments could be causing my problem I'll<br>
>>> eliminate them too.<br>
>>><br>
>>> Please see the attached.<br>
>>> rs<br>
>>><br>
>>><br>
>>> On Mon, Jun 23, 2014 at 11:59 AM, Perry R Cook <<a href="mailto:prc@cs.princeton.edu">prc@cs.princeton.edu</a>><br>
>>> wrote:<br>
>>>><br>
>>>> I have lots of programs that spork hundreds or thousands<br>
>>>> of shreds without this error. So, without seeing your<br>
>>>> code, my guesses (and questions) are as follows:<br>
>>>><br>
>>>> Are you running this on a small memory architecture? Since<br>
>>>> you say headless, I'm guessing maybe Raspberry Pi? It<br>
>>>> could be that you're running out of memory, so see next<br>
>>>> question.<br>
>>>><br>
>>>> Does the shred that you're sporking declare new UGs or<br>
>>>> require memory to be allocated (arrays, lots of string<br>
>>>> manipulation, etc.)? In general, this is a bad idea if you<br>
>>>> can avoid it. ChucK does no garbage collection, which<br>
>>>> means that you need to be cautious about declaring memory.<br>
>>>><br>
>>>> So even a shred as simple as:<br>
>>>><br>
>>>> fun void mySine() {<br>
>>>> SinOsc s => dac;<br>
>>>> Math.random2f(100,1000) => s.freq;<br>
>>>> second => now;<br>
>>>> s =< dac;<br>
>>>> }<br>
>>>><br>
>>>> will eat up memory, because even though the SinOsc<br>
>>>> is unchucked and never computes again, the memory<br>
>>>> for that structure is still around. We want, someday<br>
>>>> to make ChucK a proper garbage collecting language,<br>
>>>> but it's hard, especially for real-time systems.<br>
>>>><br>
>>>> If this turns out to be your issue, then one way to<br>
>>>> handle this is to make a global pool of fixed<br>
>>>> resources and have your shred grab from that.<br>
>>>> Like classic "round robin voice stealing" in<br>
>>>> synthesizers:<br>
>>>><br>
>>>> SinOsc s[100];<br>
>>>> 0 => int next2Use;<br>
>>>><br>
>>>> fun void mySine() {<br>
>>>> next2Use => int thisOne;<br>
>>>> 1 +=> next2Use;<br>
>>>> if (next2Use > 99) 0 => next2Use;<br>
>>>> s[thisOne] => dac;<br>
>>>> Math.random2f(100,1000) => s[thisOne].freq;<br>
>>>> second => now;<br>
>>>> s[thisOne] =< dac;<br>
>>>> }<br>
>>>><br>
>>>> // to test:<br>
>>>> while (1) {<br>
>>>> Math.random2f(0.01,0.1) :: second => now;<br>
>>>> spork ~ mySine();<br>
>>>> }<br>
>>>><br>
>>>> I just fired up a few dozen of these running in<br>
>>>> parallel, VM showed 2600 total shreds running,<br>
>>>> no problem (and no clicks or dropouts!!).<br>
>>>><br>
>>>> Hope this helps, if none of this applies, then you<br>
>>>> may have discovered a strange bug. Source code please,<br>
>>>> and we can all scratch our heads on it.<br>
>>>><br>
>>>> Thanx!! PRC<br>
>>>><br>
>>>><br>
>>>> Today's Topics:<br>
>>>><br>
>>>> 1. 147th shred removed...segmentation fault? (Ryan Supak)<br>
>>>> _______________________________________________<br>
>>>> chuck-users mailing list<br>
>>>> <a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br>
>>>> <a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
>>><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> chuck-users mailing list<br>
>> <a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br>
>> <a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
>><br>
_______________________________________________<br>
chuck-users mailing list<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
</div></div></blockquote></div><br></div>