hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> Stephen <mca### [at] aolcom> wrote:
> > On 03/12/2018 01:06, Kenneth wrote:
> > >
> > > 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.
> > >
> >
> > Have you tried? ;)
> >
>
> I just did!  :-P
>
> #debug concat ("/n","my_image",str(frame_number,-4,0),".png","/n")
>
> ....and no debug message shows up. So I guess line feeds can't use the forward
> slash after all. (I'm guessing that line feeds are 'different animals' than
> library-path separators.)

your "guess" is good.  see 3.3.2.7.2 "Text Formatting" for the list of "escape
sequences".  the path separator is just a "normal" character, albeit different
for each (it seems) os.


regards, jr.

Post a reply to this message

On 03/12/2018 12:03, Kenneth wrote:
> Stephen <mca### [at] aolcom> wrote:
>> On 03/12/2018 01:06, Kenneth wrote:
>>>
>>> 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.
>>>
>>
>> Have you tried? ;)
>>
> 
> I just did!  :-P
> 
> #debug concat ("/n","my_image",str(frame_number,-4,0),".png","/n")
> 
> ....and no debug message shows up. So I guess line feeds can't use the forward
> slash after all. (I'm guessing that line feeds are 'different animals' than
> library-path separators.)
> 
> 
> 
As Thomas and jr said. :)
But I think that you are showing your age calling them line feeds. o_O

I remember the time when you had to type CR+LF because if you typed 
LF+CR your Teletype 33 would not return the carriage to the beginning of 
the line before the machine would start printing the next character.

-- 

Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 03.12.2018 um 02:06 schrieb Kenneth:
>
> > That 'png' is a keyword (or sort of like one), and I could never figure
> > out a way to get a string construction to 'create' a POV-Ray keyword...
>
> See `Parse_String` macro in `strings.inc`.

Hey, that does work beautifully!

#include "Strings.inc"
image_map{
Parse_String("png") concat("my_image",str(frame_number - 1,-4,0),".png")

(although, I probably wouldn't use it in this *particular* context, as the
keyword   png   would simply be easier; but it's a great way to generate
keywords in general.) Thanks for the hint!

The macro is a nice one: It simply #writes the string to a file, then
immediately #includes that file back into the SDL code line.

But what baffles me at the moment is why it DOES work, when
     image_map{concat("png ","my_image",str(frame_number - 1,-4,0),".png")
does not-- since both constructions involve strings, in what *appears* to be a
similar way.

SO... I'm thinking that the  concat  keyword is the problem-- not specifically
concat, but that the initial image_map{  expression expects the BITMAP_TYPE to
be the first thing it sees, not some other 'thing'.  Not even  str("png")

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> But what baffles me at the moment is why it DOES work, when
>      image_map{concat("png ","my_image",str(frame_number - 1,-4,0),".png")
> does not-- since both constructions involve strings, in what *appears* to be a
> similar way.

When you do it the cancat way - POV-Ray sees it as a string.
When you do it the #include way - it parses it as a keyword.

Maybe something handy would be to have something like

keyword (my_keyword) so the whole write/read/parse sequence could be avoided

in the far far future   ;)

Post a reply to this message

On 03/12/2018 20:27, Bald Eagle wrote:
> in the far far future;)

Made me smile. :D


-- 

Regards
     Stephen

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> When you do it the cancat way - POV-Ray sees it as a string.
> When you do it the #include way - it parses it as a keyword.

Apparently so. In some miraculous and secretive way, known only to the Gods :-P
>
> Maybe something handy would be to have something like
>
> keyword (my_keyword) so the whole write/read/parse sequence could be avoided
>

What interests me about the Parse_String macro is that it does two seemingly
separate operations simultaneously (well, one after the other)-- #write and
#include. For some strange reason, I thought that the parsing/processing of a
macro would have to go past its #end statement, before anything actually
happened (with the result that an error would be encountered at the #include
line);  but that's not the case. It's a happy (if late) new discovery for me.
;-)

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.

Post a reply to this message

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