Re: [sc-dev] Re: Still occasional memory corruption...

[Jonatan Liljedahl <lijon@xxxxxxxxxxxx>]

Another update:

(
f = { |x,g|
    g.()
};

f.(2,{ var foo = 111, abc = 123;
    f.(42,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{
f.(2, { "abc is %".format(abc).postln; 3})})})})})})})})})})})})})})
})
)

abc is a Function
3

On Wed, Nov 20, 2013 at 4:56 PM, Jonatan Liljedahl <lijon@xxxxxxxxxxxx> wrote:
> Also interesting:
>
> (
> f = { |x,g|
>     g.()
> };
>
> f.(2,{ var abc = "this";
>
> f.(42,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{f.(2,{
> f.(2, { "abc is %".format(abc).postln; 3})})})})})})})})})})})})})})})
> )
>
> abc is 42
> 3
>
> So then we know which frame the value is coming from.
>
> Also, with Main.tailCallOptimize = false, I get random results.
>
> On Wed, Nov 20, 2013 at 4:18 PM, James Harkins <jamshark70@xxxxxxxxx> wrote:
>> On Nov 20, 2013 7:06 PM, "Miguel Negrão"
>> <miguel.negrao-lists@xxxxxxxxxxxxxxxxx> wrote:
>>> I'm afraid I can't help much at all, but just so you feel less lonelly,
>>> I was at some point getting similar behaviour from sclang. At some point
>>> the same variable, without being changed, would output completelly
>>> random results.
>>>
>>> https://github.com/supercollider/supercollider/issues/999
>>
>> This sounds related. My code is racking up some quite deep stack traces,
>> dispatching OSC messages through multiple Protos, often by way of
>> NotificationCenter. Proto is especially demanding on the stack, since
>> pseudo-method dispatch through doesNotUnderstand "use"-s the Proto,
>> incurring frames for protect and prTry. Multiple layers of notifications are
>> involved as well. It wouldn't surprise me if the stack approached a hundred
>> frames.
>>
>> So the million dollar question is: Does anybody know enough about this to
>> trace it in gdb and check the state of the stack? I sure don't.
>>
>>> Stating the obvious, indeed one of the advantages of using a mainstream
>>> language is that you have people that can look into this sort of stuff
>>> that know exactly what is going on, freeing the sc developers to focus
>>> on the musical aspect of things. But then again, I'm afraid there will
>>> never be consensus on a language... sclang is kind of the glue that
>>> keeps us together, for the better or worse ;-)
>>
>> I guess, it's "whose consensus." I could go with ruby, lua or Haskell (with
>> Haskell being the least likely to gain traction among the user base as a
>> whole).
>>
>> hjh
>
>
>
> --
> /Jonatan
> http://kymatica.com



-- 
/Jonatan
http://kymatica.com

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/