Re: recursion limit

At 07:36 PM 7/15/2011 +0200, nicky van foreest wrote:
>Hi,
>
>I ran into a RuntimeError: maximum recursion depth exceeded in cmp
>with Trellis in this (simple) piece of code.

I ran the code and it does not produce an error for me; it just runs.


>I think I can repair this by resetting the recursion depth. However, I
>suppose this will not work if I run a simulation with a 10e6 jobs. Why
>actually does trellis run into this problem?

Since I'm not able to reproduce the problem, I couldn't 
say.  However, if you are getting recursion in a comparison, it's 
possible that it's because you are using a __cmp__ or other 
comparison method in your code that's not in the sample you sent me, 
wherein that comparison relies on trellis properties.  (OTOH, if that 
were the case, then changing the recursion depth wouldn't fix it.)


>  It makes me a bit
>suspicious about the scaleability of trellis, or should I not worry
>about this?

I don't think so.  The recalculation algorithm is only recursive if 
you request calculation of a value that has not previously been 
calculated.  That is, if you set up a chain of a million items, and 
only then request some info about the last one, *and* the values it 
depends on are lazy (that is, they don't get automatically computed 
just by initializing their owner object), then yes, it will have to 
recurse to one million depth (times a constant).

So, if you are going to set up a heavily chained calculation, you can 
make it non-recursive simply by ensuring that the desired property is 
calculated eagerly, e.g. by using trellis.maintain().  This will both 
amortize the initial calculation over your setup time, *and* ensure 
that any subsequent read operations can't end up being recursive.


>thanks for any hints.

FYI, there is potentially a bug in your code if a Job's 'prev' 
attribute can be changed.  As your code stands, changing a job's 
'prev' attribute will leave its calculations linked to the old 
'prev', until something causes the rules to be recalculated.  (At 
which time they'll link to the new 'prev'.)  You should make 'prev' a 
Trellis attribute if it's not a constant.  Then, changing it will 
cause the appropriate recalcuations to occur.