Hi(gh)!

In my POVEarth main script, I have to compose the name of the terrain 
slice mesh2 (for example, n41e043) to be tested against a trace vector 
from the integer part of the geographic camera position. I know that 
this is not possible by default, but I remember having used a special 
include file years ago which facilitates concatenating identifiers. 
Unfortunately, I don't remember the name of this include file...

See you in Khyberspace!

Yadgar

Post a reply to this message

hi,

Yadgar wrote:
> ...
> include file years ago which facilitates concatenating identifiers.

do you mean the 'Parse_String()' macro in 'strings.inc'?


regards, jr.

Post a reply to this message

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
>
> In my POVEarth main script, I have to compose the name of the terrain
> slice mesh2 (for example, n41e043) to be tested against a trace vector
> from the integer part of the geographic camera position. I know that
> this is not possible by default, but I remember having used a special
> include file years ago which facilitates concatenating identifiers.
> Unfortunately, I don't remember the name of this include file...

Try macro Parse_String() in strings.inc.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>
> Yadgar wrote:
> > ...
> > include file years ago which facilitates concatenating identifiers.
>
> do you mean the 'Parse_String()' macro in 'strings.inc'?

JINX!

Post a reply to this message

hi,

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> >
> > Yadgar wrote:
> > > ...
> > > include file years ago which facilitates concatenating identifiers.
> >
> > do you mean the 'Parse_String()' macro in 'strings.inc'?
>
> JINX!

YIKES!  ;-)


regards, jr.

Post a reply to this message

This Parse_String(...) macro is new to me, so I played around with it, to see
what it could do. It's quite powerful, and opens up a lot of possibilities.

Btw, I like to take small chunks of code (like macros) out of include files and
put them directly into my scenes; this saves a *little* bit of parsing time--
and I can easily refer to them.

Some simple examples of the macro's use. (You can run all of these as a scene,
to see the results on-screen and in the messages pane):
//---------
#version 3.8; // or whatever

// the macro
#macro Parse_String(String)
    #fopen FOut "parse_string.tmp" write // or "MY_FILE.inc" for example
    #write(FOut,String)
    #fclose FOut
    #include "parse_string.tmp" // ditto
//------

// some initial values to work with
#declare S = seed(37);
#declare T = 6 + sqrt(4) + rand(S);
#declare MY_TEXT = concat("Hello"," ", "world!","  ",str(T,0,5)) // ANY kind of
// string

------
// a text object
text{
ttf "timrom.ttf" // or   internal 1
Parse_String("MY_TEXT"),.2,0 // needs the double quotes here, because the
// macro's written file doesn't create those
translate <-4,0,15>
texture{pigment{rgb 1}finish {ambient 1 emission 0 diffuse 0}}
}
//--------
// Using the macro to CREATE a #declare statement. The macro (invisibly)
// inserts the statement  #declare ZZ = 4;  into the
// scene here-- not as a 'string', but as an actual command with a
// usable 'R-value'
#declare P = "#declare XX = 4;"
Parse_String(P) // using the macro
#declare TEST_1 = XX + 6; // The result is  10  as expected

// to test this final value
#debug concat("\n","TEST_1 = ",str(TEST_1,1,3),"\n")
//--------

// and similarly... writing TWO #declare statements on separate lines...
#declare P = concat("#declare XX = 4;","\n","#declare YY = 20;")
Parse_String(P)
#declare TEST_2 = XX + YY; // the result is   24  as expected

// to test this final value
#debug concat("\n","TEST_2 = ",str(TEST_2,1,5),"\n")

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> This Parse_String(...) macro is new to me, so I played around with it, to see
> what it could do. It's quite powerful, and opens up a lot of possibilities.

So, due to my addi...  affliction, I actually had a dream about this macro -
using it to describe an identifier as well as output its value.

As in #debug concat ("U", " = ", str (U, 0, 0), "\n")
It would be handy to have a simple macro that you could just pass  _ U _ to, but
U the text character and U the scalar value are separate and distinct.

So my short dream was about implementing Parse_String to create such a macro...

I think I ran out of dried frog pills.....

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > This Parse_String(...) ...= ", str (U, 0, 0), "\n")
> It would be handy to have a simple macro that you could just pass  _ U _ to, but
> U the text character and U the scalar value are separate and distinct.
>
> So my short dream was about implementing Parse_String to create such a macro...
>
> I think I ran out of dried frog pills.....

not quite what you thought of, the "wrong way round"?  :-)

Script started on Mon 28 Sep 2020 11:05:25 BST

jr@goose:4:tmp$ c### [at] bepov
#version 3.8;

global_settings {assumed_gamma 1}

#include "strings.inc"

#macro Abc(s_)
  #debug concat(s_, " = ", str(Parse_String(s_),0,2), "\n")
#end

#declare name_ = "U";

Parse_String(concat("#declare ", name_, " = 123.45;"));

Abc(name_)


jr@goose:5:tmp$ povparse be.pov
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.9945627.unofficial
   ...
==== [Parsing...] ==========================================================
U = 123.45
File 'be.pov' line 8: Parse Warning: No objects in scene.
==== [Rendering...] ========================================================


regards, jr.

Post a reply to this message

On 9/28/20 6:18 AM, jr wrote:
...
> 
> #include "strings.inc"
> 
> #macro Abc(s_)
>    #debug concat(s_, " = ", str(Parse_String(s_),0,2), "\n")
> #end
> 
> #declare name_ = "U";
> 
> Parse_String(concat("#declare ", name_, " = 123.45;"));
> 
> Abc(name_)
> 
...

Expect most know, but on seeing this thread I added the follow comments 
to povr's string.inc file:

// Parse a string you create (i.e., = concat(...)) - while parsing.
// Use carefully. This macro a hack using a file which can collide
// by name across invocations of povray or during multiple
// simultaneous povray commands. Further, in opening and closing a
// file it is also inefficient if done many times. Often it's
// better to use the same "include defined strings for parsing"
// idea by writing many 'to be parsed strings' to a file and then
// include that single file by a name which you know and control.
#macro Parse_String(String)
     #fopen FOut "parse_string.tmp" write
     #write(FOut,String)
     #fclose FOut
     #include "parse_string.tmp"
#end

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/28/20 6:18 AM, jr wrote:
> > ...
> > Parse_String(concat("#declare ", name_, " = 123.45;"));
> > ...
>
> Expect most know, but on seeing this thread I added the follow comments
> to povr's string.inc file:
>
> // Parse a string you create (i.e., = concat(...)) - while parsing.
> // Use carefully. This macro a hack using a file which can collide
> // by name across invocations of povray or during multiple
> // simultaneous povray commands. Further, in opening and closing a
> // file it is also inefficient if done many times. Often it's
> // better to use the same "include defined strings for parsing"
> // idea by writing many 'to be parsed strings' to a file and then
> // include that single file by a name which you know and control.
> ...

wondering whether the recommendation should not follow Kenneth's preference (ie
cut/paste macro in to scene) since it is "self-modifying" code.  also thinking,
wrt file name collision(s), perhaps a new version 2 of the macro could (should?)
be added to the POV-Ray/povr distributions, putting the user "in charge".  eg:

#macro Parse_String_2(Fname, String)
  #fopen FP Fname write
  #write(FP, String)
  #fclose FP
  #include Fname
#end


regards, jr.

Post a reply to this message