=?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

"jr" <cre### [at] gmailcom> wrote:
perhaps a new version 2 of the macro could (should?)
> be added to the POV-Ray/povr distributions, putting the user "in charge".  eg:

A "new  version 2" should handle it all in memory, with no requirement for
write-to-disk.

Some other similar function simply to be able to access identifier values with
their text names would be useful.
#local _vector = evaluate_id ("myVector");

Identifying the type/cast of the variable would be great too, as well as some
internal identifier number (for use in loops, arrays, etc).

Post a reply to this message

On 9/28/20 1:16 PM, Bald Eagle wrote:
> "jr" <cre### [at] gmailcom> wrote:
> perhaps a new version 2 of the macro could (should?)
>> be added to the POV-Ray/povr distributions, putting the user "in charge".  eg:
> 
> A "new  version 2" should handle it all in memory, with no requirement for
> write-to-disk.
> 
> Some other similar function simply to be able to access identifier values with
> their text names would be useful.
> #local _vector = evaluate_id ("myVector");
> 
> Identifying the type/cast of the variable would be great too, as well as some
> internal identifier number (for use in loops, arrays, etc).
> 
> 
Jr and Bill, good ideas.

I updated my povr version so it accepts an optional argument for the 
file name. This forces users to at least think about it because they 
must at least add a comma given how the optional argument feature works 
as in:

Parse_String("THING1",)

but hopefully what they'll do is use something like:

Parse_String("THING1","/tmp/Scene22_wibblyWobbly_parse_stringyWingy")

and if /tmp is a ramdisk as it is on my system, it speeds up the 
operation considerably.

Something future thing all in memory better, but someday...

With respect to evaluate_id unsure. If you are just an ID to and ID you 
can do this today:

#declare THING1 = 0.111;
#declare THING2 = THING1;

If want to do this with a string you can use:

#declare THING2 = Parse_String("THING1",);

Getting the internal type could be done I guess. A number too. But with 
both these and the latter more than the former - it would start to bind 
how and what changes could be made within the parser code. Down the list 
I think.

Bill P.

Post a reply to this message