On 4/27/21 7:56 PM, William F Pokorny wrote:
> On 4/27/21 6:52 AM, jr wrote:
>> hi,
>>
> 
> Played a few minutes with this just now and you can get your original 
> code to run if you change the tail m_l10 macro to:
> 
> #macro m_l10(i_,n_)




> #end
> 
...
> 
> Parse_String is involved in what's happening, but it's not clear to me, 
> why - some scope issue maybe as it comes after the last "call" to m_l10.
> 

OK.

Not 100% sure, in that I've not proven it by making all the 
'parse_fore.tmp' names unique, but I believe we are reading (or I 
suspect continuing to read) via a now back in scope #include to a common 
file with updated, and longer contents written in the previous deeper 
scope(1).

If in your include we add two lines to 'empty' the included file after 
including / dynamically interpreting the intended string:

#macro fore_exec(s_)
   #local fn_ = "parse_fore.tmp";
   #fopen fp_ fn_ write
   #write (fp_,s_)
   #fclose fp_
   #include fn_
   #fopen fp_ fn_ write  // Making file empty here fixes issue too
   #fclose fp_
#end

The code runs OK.

You ask, "So, this is an issue to which the strings.inc's
Parse_String() macro has always been exposed too?" Yes, I suspect so 
though I've not gone back to older versions of POV-Ray to try and 
reproduce the issue.

Is it worth further chasing and changing, if this is how v3.8 works 
today? I vote NO.

I'm thinking the practical fix is our 'Parse_String()'s should always 
empty the file just included.

We should remember too the Parse_String() method is a hack; It's bad 
practice to be writing and reading the same file name from multiple 
scene 'scopes' or invocations of POV-Ray.

(1) - POV-Ray re-reads files by file positions while working with macros 
and includes. What I think you hit on in changing the tail macro name 
and finding the code working, was changing to a macro name with the same 
(or shorter) length as (all) the earlier ones in the recursion. Meaning 
the file position markers didn't change (with respect to the file 
contents) in a way causing additional characters to be read from the 
'common' parse_fore.tmp file name. This theory can be tested by, say, 
changing the m_l10 name to say ml10 - should run?

Bill P.

Post a reply to this message