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