POV-Ray : Newsgroups : povray.binaries.images : New Characters for Master of Puppets Font Server Time
28 Mar 2024 11:33:52 EDT (-0400)
  New Characters for Master of Puppets Font (Message 21 to 27 of 27)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: William F Pokorny
Subject: Re: New Characters for Master of Puppets Font
Date: 9 Apr 2022 13:40:28
Message: <6251c50c$1@news.povray.org>
On 4/9/22 00:10, jr wrote:
> William F Pokorny<ano### [at] anonymousorg>  wrote:
>> ...
>> Took me a while, but I now see it. I have to set
>>
>> #declare MOP_UseFrenchQuoteMarks = yes;
>>
>> in quote.pov as setting it to no works OK for me.
> yes, same here.  and suspect you're right about it being .. entangled with the
> macro caching mechanism (that macro is large, 118K+ over (close to) 3100 lines.
> :-))
> 

I think I now understand the cause of the seek errors, though not yet 
all the gritty code details.

In v3.8, work was done in the parser to recognize fixed conditional 
states and to skip (not parse) inactive blocks and store 
pre-seek-indexes into the file(s) defining macros.

In jr's code he has:

#include "masterofpuppetsfont_Apr07_2022.inc"

#declare MOP_Gap                 = .14;
#declare MOP_Space               = .65;
#declare MOP_FontRadius          = .0625;
#declare MOP_UseFrenchQuoteMarks = yes;

However, given Dave added:

#ifndef (MOP_UseFrenchQuoteMarks)
     #declare MOP_UseFrenchQuoteMarks = no;
#end

to the bottom of the include, the macros in the include are parsed and 
'seek indexes' are set up into the run time include file(s) as if 
MOP_UseFrenchQuoteMarks is a fixed 'no'.

Changing jr's code to:

#declare MOP_Gap                 = .14;
#declare MOP_Space               = .65;
#declare MOP_FontRadius          = .0625;
#declare MOP_UseFrenchQuoteMarks = yes;

#include "masterofpuppetsfont_Apr07_2022.inc"

such that the include comes after the declare works.

---
The deeper tangle here is there is a general implication for v3.8 onward 
for macros and includes.

If some global value setting - ones not passed to a macro, but evaluated 
as a global when the macro/include is first read - can effectively 
change the size of the macro (the stored macro 'file') due the parsing 
skip optimizations, we should force the definition << before >> the 
include is first parsed.

Or! Pass the conditional value to the macro(a) to avoid optimizations. 
In other words use a passed parameter value over the globally declared 
setting.

I believe Dave's font include file needs at a minimum to have the 
defaulting changed to:

#ifndef (MOP_UseFrenchQuoteMarks)
     #if (version >= 3.8)
         #error "MOP_UseFrenchQuoteMarks must be pre-declared yes or no."
     #else
         #declare MOP_UseFrenchQuoteMarks = no;
     #end
#end

Further, checking in 3.8 onward that the definition is truly in the 
global namespace a good idea too, but it's not shown.

Strictly, even value settings could change the stored macro file(s) if 
there are related conditionals. It's not too likely in practice.

(a) - I've not yet tried passing the setting to the macro to see if it 
fixes the problem as expected...

Not sure there is any general source code fix here beyond rolling back 
all the v3.8 parser optimizations which 'might' cause problems.

If I get time to do some confirmation of more detailed-cause, it might 
be we could detect and warn/error on conditional optimization which 
depend upon global definitions. In other words, force such conditional 
values to be passed on the macro call, but such a 'fix', would sometimes 
complain about otherwise valid code.

I'll let this issue bang around in my skull for a while I guess.

Bill P.

---
Aside for those wondering:

Why do <v3.8 version work with jr's original code?

I believe it's because the entire file in which the macro is defined is 
read again on each reference to the macro therein. This is slow, 
especially if a using a spinning physical disk drive(b).

(b) - These days, with solid state drives and heavy memory caching of 
files both ivia the OS and disk hardware, I expect the re-read of the 
defining file on every call much less noticeable as a penalty.


Post a reply to this message

From: jr
Subject: Re: New Characters for Master of Puppets Font
Date: 9 Apr 2022 16:15:00
Message: <web.6251e82b80354cb35834ab476cde94f1@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Changing jr's code to:
> ...
> such that the include comes after the declare works.

wow.  (thank you v much for working this out)  it works, though I'd lie if I
said I understood why; in particular, can't fathom why the order makes no
difference for MS users, apparently (but never mind, it works :-)).


regards, jr.


Post a reply to this message

From: Dave Blandston
Subject: Re: New Characters for Master of Puppets Font
Date: 10 Apr 2022 02:45:00
Message: <web.62527cad80354cb3ee1b05ae607c1b34@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:
> wow.  (thank you v much for working this out)  it works, though I'd lie if I
> said I understood why; in particular, can't fathom why the order makes no
> difference for MS users, apparently (but never mind, it works :-)).


This has gone way beyond my comprehension but if I understand correctly the
include file is useable as-is so long as the settings are declared before the
file is included, so as of right now I won't make any changes.

Have a delightful day folks!

Kind regards,
Dave Blandston


Post a reply to this message

From: William F Pokorny
Subject: Re: New Characters for Master of Puppets Font
Date: 10 Apr 2022 04:36:17
Message: <62529701@news.povray.org>
On 4/10/22 02:43, Dave Blandston wrote:
> "jr"<cre### [at] gmailcom>  wrote:
>> wow.  (thank you v much for working this out)  it works, though I'd lie if I
>> said I understood why; in particular, can't fathom why the order makes no
>> difference for MS users, apparently (but never mind, it works :-)).
> 
> This has gone way beyond my comprehension but if I understand correctly the
> include file is useable as-is so long as the settings are declared before the
> file is included, so as of right now I won't make any changes.

Beyond mine too at the moment - if you push me to describe the exact 
source code paths involved and all that can happen. :-) Any real 
investigation of code and behavior will take me days more at a minimum.

I have doubts about the windows claim order making no difference, but 
I've never been a windows POV-Ray user - and the claim could be true for 
any particular release version of window's POV-Ray binary for many 
reasons I can imagine. I'm not chasing that rabbit.

---
Related: I woke up this morning remembering something in the shipped 
rand.inc on my "it bothers me" list. There is a declare of Gauss_Next 
sitting in that file which 'looks' to me to count on a re-read/parse of 
the entire rand.inc(a) file for proper operation after the first call to 
some of the macros therein.

This rand.inc, question at least, touches on the fundamental point that 
v3.8 onward does a sort of 'pre-process/pre-compile' of the include files.

In other, oversimplified words, just as you cannot configure and compile 
a release of POV-Ray without a certain feature and then at run time 
expect to use it; we now cannot later change the SDL / indexes sitting 
in memory via later changes in macro 'declare driven configurations'(b). 


(a) - I doubt even in v3.7 the entire file gets read again... I suspect 
offset indexes into each include file are already in use with v3.7, but 
it's not something I've verified. The rand.inc file is the one povr 
shipped include I've mostly left as is for not knowing what I should 
really do with all of it.

(b) - And I go on to wonder if this one of the reasons v3.8 supports 
optional defaulted macro parameters...

Me thinking aloud - FWIW. My understanding is vague enough I don't 
completely trust what I've written.

Bill P.


Post a reply to this message

From: jr
Subject: Re: New Characters for Master of Puppets Font
Date: 10 Apr 2022 08:25:00
Message: <web.6252cbc480354cb35834ab476cde94f1@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/10/22 02:43, Dave Blandston wrote:
> > "jr"<cre### [at] gmailcom>  wrote:
> >> ... can't fathom why the order makes no difference for MS users, apparently
> ...
> I have doubts about the windows claim order making no difference, but
> I've never been a windows POV-Ray user - and the claim could be true for
> any particular release version of window's POV-Ray binary for many
> reasons I can imagine. I'm not chasing that rabbit.

(feeling defensive, all of a sudden.. :-))  I don't use/have access to MS
Windows either.  what lead me to think order might not matter there, were the
two posts by AM.  after I posted the code to alert DB, AM wrote "when I try to
render your scene, I get this error..".  then, after your "sleuthing", DB issued
an update and AM confirmed "works well in version 3.8".  I assume that AM did
not move the include, hence my .. supposition.  (maybe Alain will read + reply).


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: New Characters for Master of Puppets Font
Date: 10 Apr 2022 18:01:34
Message: <625353be$1@news.povray.org>
On 4/10/22 08:21, jr wrote:
> (feeling defensive, all of a sudden.. :-))  I don't use/have access to MS
> Windows either.

Understand.

No missiles were launched.

Water balloons, an unwashed sock and one tiny, tiny rock... :-)

---
To be clear, I appreciate your error reports. Thank you.

You are almost always right about something being amiss. It's why I 
cringe when you report an issue or puzzling question. ;-)

Bill P.


Post a reply to this message

From: jr
Subject: Re: New Characters for Master of Puppets Font
Date: 11 Apr 2022 03:05:00
Message: <web.6253d2a980354cb35834ab476cde94f1@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> It's why I
> cringe when you report an issue or puzzling question. ;-)

that I can understand :-).  cheers.


regards, jr.


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.