|
From: Bernard B. <ber...@gm...> - 2010-02-11 22:50:50
|
Sorry, I was not at all available for trying to trace this problem on the MacOS 9 version. I agree with Anthony that it is very unlikely that recursive use of retro() causes a bug because it has been carefully checked. The only bad news is that the program crashes before being able to tell the user that it has no more available memory. This was well-managed in the MacOS 9 version but now we are running it in an entire new environment with a specific memory management, and this security remains to be redesigned. Quite uneasy because the machine may slow down tremendously before crashing, so that in the end it becomes out of control even though it still has resources.
To control the depth of the recursion there are several methods amounting to limiting the number of times a rule is fired. For this you can use a decreasing weight such as <100-1> thereby meaning that the rule weight is 100 in the start and it decreases by one unit each time it is fired, so after 100 times the rule is dead. Since the rule is not in competition with another one, changing its weight has no incidence on its probability, except of course once the weight becomes nil.
A more sophisticated way is to use a flag that may also be decreased by a certain number of units in one or several rules and will block rules that use it as a firing condition once its value goes down to zero. A cute example of using flags is: "-gr.trial.mohanam".
I hope this helps. I will send more details if it is not clear...
Bernard Bel
>I started to debug this about 2 weeks ago and then was distracted.
>
>The problem seems to be that the function PrintArgSub() in DisplayArg.c is
>being called recursively to a very great depth. When I last paused the
>derivation, it had recursed 300 times and had not yet crashed, but the
>program was running so slowly in the debugger that I put it on hold. So, I
>have not found the exact spot where it is crashing yet, but it may crash in
>different locations depending on how much memory is available anyways.
>
>My first intuition here was that the grammar must be looping somehow and
>causing an infinite recursion. This would eventually cause the stack to
>grow so large that the program would crash. Looking at the grammar more
>closely though, I do not see any possibility for looping in the derivation,
>so maybe it does not recurse infinitely. But it is still recursing too
>deeply I think.
>
>Right now, the BP2 I have on hold in the debugger is using about 205MB of
>virtual memory which is not a huge amount but it will probably grow out of
>control if I let it continue to run.
>
>Incidently, I think I also tried Bernard's modification to the grammar and
>that ran fine to completion and generated some music. I am going to try
>reducing the number of Y's in the start rule and see if I can get the
>original grammar down to a size that does not crash.
>
>Unless this deep recursion is actually a bug, I suspect the only way to
>protect against this sort of problem might be to have BP2 check how deeply
>it is recursing and ask the user if they want to continue when the number
>gets large.
>
>Anthony
>
>Bernard Bel wrote on 1/25/10 6:17 AM:
>
>> I will try this grammar with both BP2.9.7 and BP2.9.6 to see whether the
>> crash has anything to do with the new code.
>>
>> Meanwhile I am wondering whether the writing of the retro parts is
>> exactly what you wish. Perhaps you mean:
>>
>> gram#1[3] X --> (=Motif1) T Tempo R {(:Motif1)} T Tempo R {(:Motif1)} T
>> Tempo R {(:Motif1)} T Tempo R {(:Motif1)} T Tempo R {(:Motif1)}
>>
>> Using the curled backets implies that the retro (in R) will concern only
>> (:Motif1) and not the rest of the string - which already may contain
>> several retros.
>>
>> However, even if you syntax does not reflect your intention, it is
>> abnormal that the program crashes! I'll let you know soon.
>>
>> Bernard
>>
>>
>>> Hi Guys
>>> Have managed to break the new BP2 - well, maybe confuse it a little 8-)
> >> I get a crash when I run the grammar below. I'm just playing with
>>> transpositions via homomorphisms, inversions via _keyxpand(), etc. T1, T2
>>> ansd T3 are modal transpositions defined in the alphabet.
>>> The crash began after I added the two variables controlling the
>>> appearance (or not) of _retro. It all worked fine until then. Have tried
>>> without gram#1[8], but it still crashes. Have tested _retro, and it seems
>>> OK.
>>> Am I simply being too heavy of the re-definitions of variables?
>>> (Oct 2008 2.8GHz iMac, 4G RAM, OS10.5.8)
>>>
>>> Thanks and Cheers
>>>
>>> Rob
>>>
>>> RND
>>> _mm(120) _striated
>>> gram#1[1] S --> Y Y Y Y Y Y
>>> gram#1[2] Y --> {X XPND X}
>>> gram#1[3] X --> (=Motif1) T Tempo R (:Motif1) T Tempo R (:Motif1) T Tempo R
>>> (:Motif1) T Tempo R (:Motif1) T Tempo R (:Motif1)
>>>
>>> gram#1[4] Motif1 --> Ee43 Ee44
>>>
>>> gram#1[5] XPND --> _keyxpand(C#3, -1)
>>> gram#1[6] XPND --> _keyxpand(C#3, 1)
>>>
>>> gram#1[7] R --> _retro
>>> gram#1[8] R --> lambda
>>> ------------------------------
>>> RND
>>> gram#2[1] Tempo --> _tempo(0.5)
>>> gram#2[2] Tempo --> _tempo(1)
>>> gram#2[3] Tempo --> _tempo(1)
>>> gram#2[4] Tempo --> _tempo(2)
>>> ---------------------------------
>>> RND
>>> gram#3[1] T --> T2 T2
>>> gram#3[2] T --> T3 T2
>>> gram#3[3] T --> T3 T3
>>> gram#3[4] T --> T3 T3 T1
>>> gram#3[5] T --> T3 T3 T2
>>> gram#3[6] T --> T3 T3 T3
>>> gram#3[7] T --> T3 T3 T3 T1
>>> gram#3[8] T --> T3 T3 T3 T2
>>> gram#3[9] T --> T3 T3 T3 T3
>>> gram#3[10] T --> T3 T3 T3 T3 T3
>>> --------------------------------
>>> ORD
>>> gram#4[19] Ee43 --> {1, D#2 D2 C2 D2}
>>> gram#4[20] Ee44 --> C#2
>
>
>------------------------------------------------------------------------------
>SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
>Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
>http://p.sf.net/sfu/solaris-dev2dev
>_______________________________________________
>bolprocessor-devel mailing list
>bol...@li...
>https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
|
