Am 04.12.2018 um 03:57 schrieb Kenneth:

> That macro construction looks like a compact 'shorthand' way to avoid coding
> separate #write/#read statements (doing away with #read altogether), while
> producing the same results (?). Pasting that short macro *into* scene code would
> do away with #include as well.

The macro is /not/ a shorthand for a `#read`/`#write` combination - the 
`#include` is indispensable. You can put it directly into the scene, but 
you can't do without it.

The primary trick here is that e.g. instead of writing the keyword `png` 
verbatim in your scene, you can instead include a file that contains the 
keyword (and nothing but the keyword).

The secondary trick is that you can create such a file with arbitrary 
content "on the fly" using `#write`.

Wrapping it all in a single macro is just a matter of convenience.

Post a reply to this message

Am 03.12.2018 um 02:06 schrieb Kenneth:

> I think the "\n" line feeds are necessary to even see the #debugged message;
> there is an older post about how the absence of them causes the message pane to
> ignore #debug...sometimes ;-) The details were somewhat complicated, IIRC.

In a first approximation, the details are actually quite simple:

- Any `#debug` statement that does not end in a `\n` will be 
concatenated with the next one.

- Any `#debug` output after the last `\n` may be truncated.


> Note: Up to (and including) version 3.7.0, contrary to the documentation (and on
> all platforms) backslashes lost their special meaning where a file name is
> expected, except when preceding a double quote. For backward compatibility, this
> behaviour is still retained for scenes specifying a #version of 3.70 or lower,
> but a warning will be issued.
> 
> ---
> 
> The only remaining mystery for me is whether or not a line feed "\n" should use
> a forward slash as well; I don't see that distinction in the docs.

No, the "use forward slashes instead" rule only applies to filenames; 
the change was made /specifically/ so that `\n` is always interpreted as 
a line feed (as opposed to a path separator followed by the lowercase 
letter `n`).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 04.12.2018 um 03:57 schrieb Kenneth:
>
> > ...Pasting that short macro *into* scene code would
> > do away with #include as well.
>
> The macro is /not/ a shorthand for a `#read`/`#write` combination - the
> `#include` is indispensable. You can put it directly into the scene, but
> you can't do without it.
>
Oops, I see now that my sentence wasn't clear; sorry. What I meant was, by
pasting the macro itself directly into a scene file, the   #include
"Strings.inc"  line could be eliminated from the scene (NOT the #include line
that's *in* the macro.)

I.e., just...

#macro Parse_String(String)
    #fopen FOut "parse_string.tmp" write
    #write(FOut,String)
    #fclose FOut
    #include "parse_string.tmp"
#end

(then the macro invocation(s) later)

It's also a *little* faster to parse this way-- the entire "Strings.inc" file
doesn't have to be pulled from disc or processed.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Stephen <mca### [at] aolcom> wrote:
> > On 02/12/2018 16:26, Kenneth wrote:

> I could never figure out a
> way to get a string construction to 'create' a POV-Ray keyword. I assume it
> can't be done-- but it would be an interesting feature to add in the future (if
> possible!)  ;-)
>
Have you tried parse_string?
It is slow if you have lot to do.

Post a reply to this message