POV-Ray : Newsgroups : povray.text.scene-files : foreach macro : Re: foreach macro Server Time
15 May 2021 20:50:25 EDT (-0400)
  Re: foreach macro  
From: William F Pokorny
Date: 28 Apr 2021 09:48:29
Message: <608967ad$1@news.povray.org>
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.


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 

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_

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

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.