Re: possible bug: stack dump with <<-String, #{...} and large loops

>>>>> "n" == nobu nokada <[e-mail]> writes:

n> Yes, but is it really a problem?  And it will be a dvar even if
n> DASGN is added in top_local_init().

 No, you make the confusion between an effect at compile time and runtime.

 Dynamic variables are managed at compile time *and* run time

 If you look at [ruby-core:00042]

   dyna_push() is the compile time part, but because it's in
   top_local_init() it will not affect ruby_dyna_vars *after* NODE_DSTR
   (more precisely after compile()), this is why `x' will not be a dynamic
   variable

   ruby_eval_tree = block_append(ruby_eval_tree, 
                                 NEW_DASGN(0, NEW_LIT(0)));

   this is the run time part, and if you look at NEW_DASGN you'll see that
   this pseudo-dynamic variable (0, 0) is created *only* if it don't exist

   This is something that you can't do with [ruby-core:00043] or
   [ruby-core:00043]

 Do you have understood why I hate this patch :-)))


n> If a variable has been defined in eval as non-dynamic, its
n> location may conflict with a variable defined in NODE_EVSTR
n> compiled by anothrer thread.

 Hmmm, I'll must look at this more seriously : do you have an example ?


Guy Decoux