When working with Parse_String from strings.inc I noticed that you 
cannot use it to create multiple macros on the fly. This is because the 
macro overwrites the file it parses from every time, and so the filename 
for each macro (which is saved internally IIRC) is the same. The errors 
you'll get are a bit confusing, though :)

It's of course no problem to get around this:

<POV>
//parse string macro which parses each time from a different file
#declare so_ParseStringCount = 0;

#macro so_ParseString(S)
     #local Filename = 
concat("so_parsestring",str(so_ParseStringCount,0,0),".tmp");
     #fopen PARSEFILE Filename write
         #write(PARSEFILE,S)
     #fclose PARSEFILE
     #include Filename
     #declare so_ParseStringCount = so_ParseStringCount + 1;
#end
</POV>

I just thought I'd post this workaround in case somebody else is having 
similar problems. Perhaps I'd would be a good idea to add a note to the 
documentation, too, saying that you can't use it to create multiple 
macros on the fly.

BTW: Seems one can't live without Parse_String when it comes to create 
stuff in POV for which the SDL was not made/intended. I love it :)

Happy POVing,
Florian

Post a reply to this message

Florian Brucker <tor### [at] torfboldcom> wrote:
> BTW: Seems one can't live without Parse_String when it comes to create 
> stuff in POV for which the SDL was not made/intended. I love it :)

  That's why it should be an internal function. The current implementation
is more a hack, and it's very inefficient.
  I wouldn't be surprised if it was made an internal function some time
in the future. :)

  By the way, the problem with your "solution" is that if you call
Parse_String a million times in a loop, you can imagine what happens...

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

>   That's why it should be an internal function. The current implementation
> is more a hack, and it's very inefficient.
>   I wouldn't be surprised if it was made an internal function some time
> in the future. :)
Would be great :) But I think it's already cool that the SDL supports 
such stuff ;)

>   By the way, the problem with your "solution" is that if you call
> Parse_String a million times in a loop, you can imagine what happens...
Yep. I thought about a cleaning-routine, too, but it is (in my case) 
unnecessary (I only call it <20 times). Aside from that, I use "normal" 
Parse_String when I know it'll work (for everything but macros).

Long live the SDL,
Florian

Post a reply to this message