Warning: non-newbies will face palm.  Three times.

In my earliest POVing days, I had scene files on two different 
computers, transporting them back and forth via floppy disks.  Nowadays, 
both sets of files are on one computer, in separate directory trees. 
Over time, I have been gradually syncing the files and merging them into 
one tree.

The biggest challenges have been two #include files.  One of them is my 
3rd generation prefab render rig, and the other is a set of common 
definitions that I used to use a lot.  These two files are not a concern 
for me nowadays because I no longer use them for new scenes; my render 
rig is in its 4th generation, and most of the common definitions have 
found their way into the Object Collection.  But over the years, I had 
made scene-breaking changes to these files, and for the first few months 
(face palm warning) I did not document these changes.

This means that, as I merge old scene files that #include these two 
files, I need to re-render them to see whether they still work, and with 
which #include file versions.  Usually, it's just a matter of setting 
version switches, but lately, I've been merging some of my oldest 
scenes, deep into undocumented updates territory.  I am running into 
multiple levels of intractable incompatibilities.

But this latest snag--it's not even a matter of documentation, as I did 
comment the reason for the change.  I did not provide for backward 
compatibility, because I figured the change was transparent.  I 
originally defined functions Sqr(), Cubed(), and Sign().[1]  Then (two 
face palms incoming) I decided these functions were too slow, so I 
converted them to macros!

The POV-Ray 3.5 reference manual made clear that calling external macros 
incurs overhead.  Based on the date stamps of the scene files that call 
Sqr(), I had already been using POV-Ray for nearly 3 months, plenty of 
time to have learned this.  Where was my head?

And in isosurfaces?  The macros would resolve at parse time, and the 
render halt complaining about an undeclared identifier.  What possessed 
me to write general-purpose macros for use in functions?

All I can think of today is that at the time I figured these functions 
were simple enough that resolving them at parse time would not cause 
complications.  The macro overhead would be irrelevant during the render 
phase.  I must have gotten lucky with the first few scenes I rendered 
with the change.  Either that or I had been so frustrated with the 
slowness of previous isosurface renders that I never bothered 
re-rendering them after changing the #include file.  Anyhow, I pretty 
quickly stopped using these macros in new scenes.  But as I re-render 
the old scenes, the problem surfaces.

In the intervening years, I have decided that if a procedure can be 
defined as either a macro or a function, it is better to define it as a 
function.  One just has to keep in mind POV-Ray's scope leakage 
problems[2] when choosing names:

   - Once a macro is defined, its name cannot be reused as a global or
     local identifier--though it can be reused as a macro formal
     parameter.
   - Once a function is defined, its name cannot be reused as a global
     or local identifier--though it can be reused as a macro formal
     parameter.
   - Once *any* identifier is declared, it cannot be reused as a macro
     name.
   - Once *any* identifier is declared, it cannot be reused as a
     function name.
   - Once *any* identifier is declared, it cannot be reused as a
     function formal parameter.  (If you were unlucky, math.inc 3.5
     would bomb out for this very reason.  Precautions were taken
     starting with math.inc 3.6; for an example, you can take a look
     at function adj_range2().)

Also, document everything!

________________________
[1] I hadn't yet discovered f_sqr() and sgn() from math.inc, but they 
are tangential to the matter anyway.  Fortunately, the existence of 
these functions eases the conversion of the affected scenes.
[2] If you have formal computer science education, you are mortified by 
these restrictions, wondering how people smart enough to create POV-Ray 
could have allowed such boneheaded violations of modular practice.  I am 
assured that the current development team is aware of such problems. 
Yes, I will keep complaining about the scope leakage until it is fixed.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> One just has to keep in mind POV-Ray's scope leakage
> problems[2] when choosing names:
>
>    - Once a macro is defined, its name cannot be reused as a global or
>      local identifier--though it can be reused as a macro formal
>      parameter.
>    - Once a function is defined, its name cannot be reused as a global
>      or local identifier--though it can be reused as a macro formal
>      parameter.
>    - Once *any* identifier is declared, it cannot be reused as a macro
>      name.
>    - Once *any* identifier is declared, it cannot be reused as a
>      function name.
>    - Once *any* identifier is declared, it cannot be reused as a
>      function formal parameter.  (If you were unlucky, math.inc 3.5
>      would bomb out for this very reason.  Precautions were taken
>      starting with math.inc 3.6; for an example, you can take a look
>      at function adj_range2().)

These things are good to know.
Scope can get pretty tricky and anxiety-inducing when I'm using things like
nested loops inside of macros, etc.
I'm never really sure when my identifier is valid/retains its value and when it
gets "released".
One day, when i get other things out of my hair, I'll probably try to write an
example scene that does all sorts of identifier backflips and other other
calisthenics.


> [1] I hadn't yet discovered f_sqr() and sgn() from math.inc,

I'm not sure why things like sgn() aren't in the source code.  It drives me
crazy when certain things I'd consider central to the operation of a lot of code
aren't written in the source code, and need to rely on include files...

And we don't really have very many proper matrix handling macros - which I kind
of found surprising for a 3D graphics package.

Thanks for you summary of the scope issues - these should make their way into
the official documentation.

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> Warning: non-newbies will face palm.  Three times.

:-)

> ...  One just has to keep in mind POV-Ray's scope leakage
> problems[2] when choosing names:
> ...
>    - Once *any* identifier is declared, it cannot be reused as a macro
>      name.

maybe I misunderstand.  the following works on alpha.10064268.unofficial

-----<snip>-----
#version 3.8;

global_settings {assumed_gamma 1}

#declare A = 0;

#undef A

#macro A(b_)
  b_
#end

#declare B = A(1);

#debug concat("B = ",str(B,0,0),"\n")
-----<snip>-----

(if you remove the '#undef', ie try to create macro with same name while the
identifier still _is_in_use_, error "expected undeclared identifier" occurs.
which is as it should be, aiui)

regards, jr.

Post a reply to this message

On 6/22/20 4:18 PM, Cousin Ricky wrote:
> Warning: non-newbies will face palm.  Three times.
> 

I think you're being to hard on yourself. Pretty much anytime I go back 
to something after a while, I see issues with what I did previously! :-)

POV-Ray doesn't have name spaces which would be a help with name 
collisions.

That said, the major issue I see is not having a 100% reliable way to
avoid a declare in an include causing problems for a function parameter
in another include or scene. Namely something like:

//---
// #declare _a = 1.0; // Causes issue for Fn*s

#declare Fn00 = function (_a,_b) { _a*_b }
#declare Fn01 = function (_a,_b) { _a+_b }

#declare _a = 1.0;  // This OK
#macro Mc00 (_a,_b) (_a*_b) #end
#macro Mc01 (_a,_b) (_a+_b) #end

#debug concat("Fn00(3,3) = ",str(Fn00(3,3),2,3)," () \n")
#debug concat("Fn01(3,3) = ",str(Fn01(3,3),2,3)," () \n")
#debug concat("Mc00(3,3) = ",str(Mc00(3,3),2,3)," () \n")
#debug concat("Mc01(3,3) = ",str(Mc01(3,3),2,3)," () \n")

#error "\nStop before render."
//---

We have the convention today users should not declare IDs with lower 
case characters because such things might become, or might already be, 
SDL keywords. What I'm thinking about for povr is adding checking such 
that users cannot declare/local a name with only (lower case ascii, _) 
characters. #declare _a =... would be a parsing error.

With this in place, I think it would then be the case we could always 
use something like _<lowercase_parm> for all our parameters without 
worry of collisions. The _ leading character would never be part of a 
keyword.

Am I missing something with this planned approach?

Your post touches on other changes I've made in povr. You mentioned 
math.inc defining - via our scene description language - functions
which look like fully inbuilt keywords/functions. We have also the all
lower case eval_pigment macro. I think these lower case names bad form
and I've changed them to have upper case characters in addition to 
moving the functions from math.inc to functions.inc. Plus eval_pigment I 
moved to math.inc, as Eval_Pigment, because it's a macro not a function.

Using your example, instead of the following in math.inc :

// Adjusts values in a specified range [Rmn, Rmx] to the specified
// range [Min, Max]
#declare adj_range2 =
   function (x, y, z, _Math_INC_OMn, _Math_INC_OMx) {
  ((x - y)/(z - y))*(_Math_INC_OMx - _Math_INC_OMn) + _Math_INC_OMn
   }

I have in functions.inc :

// Adjusts passed (x) values relative to a specified range [Rmn, Rmx]
// to a new value relative the specified range [Min, Max]. Normally (x) 
// in input range, but it need not be.
#declare F_adj_range2 = function (x,y,z,_mn,_mx) {
   ((x-y)/(z-y))*(_mx-_mn)+_mn
}

I want to get to where f_ prefixed functions indicate inbuilt functions. 
The F_ prefixed functions indicate SDL defined functions shipped in povr 
include files.

Something I've stumbled over is seeing odd(...) in a scene file and 
thinking it's an SDL keyword - but then not seeing any documentation for 
it. I might not always be getting today's math.inc odd() in any case. At 
least if I see the F_ prefix I'll know it's something defined in an
include and I need to be careful.

Bill P.

Post a reply to this message

Le 2020-06-23 à 04:42, jr a écrit :
> hi,
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> Warning: non-newbies will face palm.  Three times.
> 
> :-)
> 
>> ...  One just has to keep in mind POV-Ray's scope leakage
>> problems[2] when choosing names:
>> ...
>>     - Once *any* identifier is declared, it cannot be reused as a macro
>>       name.
> 
> maybe I misunderstand.  the following works on alpha.10064268.unofficial
> 
> -----<snip>-----
> #version 3.8;
> 
> global_settings {assumed_gamma 1}
> 
> #declare A = 0;
> 
> #undef A
> 
> #macro A(b_)
>    b_
> #end
> 
> #declare B = A(1);
> 
> #debug concat("B = ",str(B,0,0),"\n")
> -----<snip>-----
> 
> (if you remove the '#undef', ie try to create macro with same name while the
> identifier still _is_in_use_, error "expected undeclared identifier" occurs.
> which is as it should be, aiui)
> 
> regards, jr.
> 
> 

Well, that's precisely the purpose of #undef.
After the #undef statement, you are in a state similar to that of that 
identifier never having even existed.

Post a reply to this message

On 2020-06-22 5:00 PM (-4), Bald Eagle wrote:
> 
> Thanks for you summary of the scope issues - these should make their way into
> the official documentation.

You're welcome; and egregious design flaw though they be, yes, these 
booby traps should be documented.

Post a reply to this message

On 2020-06-23 4:42 AM (-4), jr wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> ...
>>     - Once *any* identifier is declared, it cannot be reused as a macro
>>       name.
> 
> maybe I misunderstand.  the following works on alpha.10064268.unofficial
> 
> -----<snip>-----
> #version 3.8;
> 
> global_settings {assumed_gamma 1}
> 
> #declare A = 0;
> 
> #undef A
> 
> #macro A(b_)
>    b_
> #end
> 
> #declare B = A(1);
> 
> #debug concat("B = ",str(B,0,0),"\n")
> -----<snip>-----

Of course you can reuse any identifier after you undefine it.  But why 
should you have to go through such nonsense?

> (if you remove the '#undef', ie try to create macro with same name while the
> identifier still _is_in_use_, error "expected undeclared identifier" occurs.
> which is as it should be, aiui)

No. It. Shouldn't.

What if the macro was defined in an include file written by someone 
else? If the user declares A, they obviously have no need for macro A, 
so why should they have to worry about whether a macro by that name 
already exists?

But this is less serious an issue; the fact remains that if you declare 
a *local* variable with the same name as a macro, the scene will not 
parse.  This means that anyone who writes a macro must make sure they do 
not use local variables with the same name as a macro in any other 
include file--even include files written by total strangers.  The same 
goes for function formal parameters.

This TOTALLY 100% defeats the purpose of local variables and formal 
parameters!  In order to write a robust POV include file, you must 
essentially read the mind of every POVer on the planet.

This is why I complain about scope leakage.  As far as I'm concerned, 
the only acceptable level of scope leakage is ZERO.

Post a reply to this message

On 2020-06-23 7:28 AM (-4), William F Pokorny wrote:
> POV-Ray doesn't have name spaces which would be a help with name 
> collisions.

Yes, that certainly would help!  It could resolve the disagreement I 
have with jr. over macro name persistence.  I would love it, although it 
would be massive work for the dev team.  Fixing the local variable and 
function formal parameter problem is far more important and should be 
prioritized.

> That said, the major issue I see is not having a 100% reliable way to
> avoid a declare in an include causing problems for a function parameter
> in another include or scene. Namely something like:
> 
> [snip]
> 
> We have the convention today users should not declare IDs with lower 
> case characters because such things might become, or might already be, 
> SDL keywords. What I'm thinking about for povr is adding checking such 
> that users cannot declare/local a name with only (lower case ascii, _) 
> characters. #declare _a =... would be a parsing error.
> 
> With this in place, I think it would then be the case we could always 
> use something like _<lowercase_parm> for all our parameters without 
> worry of collisions. The _ leading character would never be part of a 
> keyword.
> 
> Am I missing something with this planned approach?

I suppose it could work.  It could potentially break old scenes, but I 
don't suppose many such scenes exist.  None of the stock include files 
have any such names that I can find.

How widespread are you recommending this convention?  It would violate 
the existing Object Collection namespace conventions, unless we amend 
the conventions.  Since Chris Bartlett disappeared, I don't know if we 
even have a formal mechanism for deciding Object Collection policy.

> Your post touches on other changes I've made in povr. You mentioned 
> math.inc defining - via our scene description language - functions
> which look like fully inbuilt keywords/functions. We have also the all
> lower case eval_pigment macro. I think these lower case names bad form
> and I've changed them to have upper case characters in addition to 
> moving the functions from math.inc to functions.inc.

The problem with renaming functions and macros is that it would break 
older scenes.  But keeping the old names alongside the new names would 
solve that problem.  Since these old names are already part of the 
POV-Ray canon, avoiding new keywords with these names should not be a 
problem.

> Plus eval_pigment I 
> moved to math.inc, as Eval_Pigment, because it's a macro not a function.

It seems to me that Eval_Pigment() belongs in textures.inc.

> I want to get to where f_ prefixed functions indicate inbuilt functions. 
> The F_ prefixed functions indicate SDL defined functions shipped in povr 
> include files.
> 
> Something I've stumbled over is seeing odd(...) in a scene file and 
> thinking it's an SDL keyword - but then not seeing any documentation for 
> it. I might not always be getting today's math.inc odd() in any case. At 
> least if I see the F_ prefix I'll know it's something defined in an
> include and I need to be careful.

I personally use fn_ or Fn_, because I already use f_ for finishes.  Of 
course, I can always distinguish between my finish and inbuilt functions 
by noting the one or more capital letters in my finish.

What do you think of e and o in consts.inc?  I think o would be better 
as O, because the Cartesian origin is normally denoted with a capital O. 
  But Euler's constant is always lowercase e.  Would it be worth making 
a keyword?

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2020-06-23 4:42 AM (-4), jr wrote:
> > Cousin Ricky <ric### [at] yahoocom> wrote:
> >> ...
> > maybe I misunderstand.  ...
>
> Of course you can reuse any identifier after you undefine it.  But why
> should you have to go through such nonsense?
>
> > (if you remove the '#undef', ie try to create macro with same name while the
> > identifier still _is_in_use_, error "expected undeclared identifier" occurs.
> > which is as it should be, aiui)
>
> No. It. Shouldn't.

hm, we all see things differently.  fwiw, the fact that POV-Ray is .. lax enough
to allow me to do:

#declare A = "foo";
#declare A = <1,2,3>;
#declare A = 0;

without complaint, makes me unhappy.  I'd much prefer "stronger" typing.

> What if the macro was defined in an include file written by someone
> else? If the user declares A, they obviously have no need for macro A,
> so why should they have to worry about whether a macro by that name
> already exists?

for the same reason one would be careful when including some library header in a
C translation unit?  given the absence of namespaces (as you note else-thread),
there's only careful design and documentation of .inc file, to alleviate the
situation.

need to think, and perhaps experiment, re "scope leakage".


regards, jr.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> How widespread are you recommending this convention?

It might help obviate "reading the mind of every Povver" if some mechanism were
implemented to prepend/append some designation to the variables to make them
"unique" to any given include file.

BE23062020inc_var1 = pow(e, i*pi);

Verbose, more work, jr will have an apopleptic fit, but serves as a functional
workaround.

I would love to be able to declare identifiers using some form of formula or
concatenation - though I don't know what that would involve in the source code.

If I wanted a01 through a10, then I could write a for loop that would declare
those identifiers.

#for (N, 1, 10)
#declare Identifier ("a" + str(N)) = pow(N, 2);
#end

(not proper syntax, but you get the _idea_)

And if THAT were possible, then at the top of the include file, one could
#declare INC_PREFIX = "BE23062020inc_";
write a small macro to prepend that to any identifier name, and then

#declare INC(a) = 0;

would be the/a way you'd handle all of the names in that file.

I know we have that parse thing (the name always escapes me) that writes to a
file and includes it back in...

> > Your post touches on other changes I've made in povr. You mentioned
> > math.inc defining - via our scene description language - functions
> > which look like fully inbuilt keywords/functions. We have also the all
> > lower case eval_pigment macro. I think these lower case names bad form
> > and I've changed them to have upper case characters in addition to
> > moving the functions from math.inc to functions.inc.

Why not make them ... fully inbuilt keywords/functions?

> The problem with renaming functions and macros is that it would break
> older scenes.  But keeping the old names alongside the new names would
> solve that problem.  Since these old names are already part of the
> POV-Ray canon, avoiding new keywords with these names should not be a
> problem.

How much does it take to implement an alias system?
It would be ever so nice to be able to rename inbuilt keywords and functions.

> > Plus eval_pigment I
> > moved to math.inc, as Eval_Pigment, because it's a macro not a function.
>
> It seems to me that Eval_Pigment() belongs in textures.inc.

Move it into source code!  :)

> > I want to get to where f_ prefixed functions indicate inbuilt functions.
> > The F_ prefixed functions indicate SDL defined functions shipped in povr
> > include files.
> >
> > Something I've stumbled over is seeing odd(...) in a scene file and
> > thinking it's an SDL keyword - but then not seeing any documentation for
> > it. I might not always be getting today's math.inc odd() in any case. At
> > least if I see the F_ prefix I'll know it's something defined in an
> > include and I need to be careful.

odd, even, and those sorts of functions should be in source code.
I find it ridiculous to include a whole file simply for one little function.
Or have to hunt down the include file to copy/paste the code.

> What do you think of e and o in consts.inc?  I think o would be better
> as O, because the Cartesian origin is normally denoted with a capital O.
>   But Euler's constant is always lowercase e.  Would it be worth making
> a keyword?

YES

Post a reply to this message

On 6/23/20 2:25 PM, Bald Eagle wrote:
> 
...
> 
Aside: I see my response is one where the formatting got wonky. Unsure 
why it happens. I've looked for offending settings in thunderbird. Maybe 
particular newsgroups or original quoted text with certain characters a 
trigger? I don't know. Apologies, but I don't see the issue on sending.

-----------

First, reminding everyone 'povr' is not POV-Ray. I'm combining my 
responses and when I start to think about major revisions to POV-Ray's 
SDL, I begin to think seriously about bindings to lua, tcl and python.

--- The _<lowercase> arguments would be the way to avoid parameter 
collisions. Nothing required, but if you don't want trouble...

--- On the idea of per include file generated unique names(1) and 
sorting on include order as a way to decide which 'Thing1' you want. 
Includes very often include other files. It can be an unstable tangle. 
The 'topological sort' can change relative to low level includes based 
on adding other includes, user settings, macro settings, etc. We 
struggle with these same ordering issues in c, c++ header files as jr 
pointed out. Most programming languages have collision issues / scope 
issues which you have to understand(2) - even with namespace support(3).

(1) - In my tcl library I have a UniqueName command which uses a global 
counter to create unique names. The counter value gets used as a suffix 
to create, say, 'Union_0123' and there are options for padding and 
delimiting characters. This generated unique id approach works well in 
languages with good 'list' (c++ std::vector) support. It has the 
exposure things can blow up storage wise if you aren't careful. I've 
found it easy to duplicate.  Today, POV-Ray internally flattens / 
duplicates - excepting meshes and a few other things. Perhaps, not a bad 
approach practically - if we had the list support.

(2) - Excepting those languages which never allow re-definition/undef 
within any given scope. This is the central concept used in functional 
programming languages. I'm toying with povr working in this way - for 
non SDL programming elements (objects, textures, macros, functions). 
Namely all name collisions and undefs being illegal for classes of 
things not needed for program control.  Toying != knowing how. :-)

(3) - Most namespace languages to which I've been exposed support a 
'using <namespace>::min' sort of declaration. These often get used - 
because people don't like to type - but, allowing the shorthand can 
weaken the namespace protections.

--- On jr's point about no type checking. I think we are not too 
exposed. While there is no strict up front type checking, it looks to me 
like the parser tracks the current id types so you cannot incorrectly 
use the wrong type due a bad/unfortunate assignment somewhere.

--- On making the lower case named functions in math.inc inbuilt. I 
might with some/all. I'm ever refining. Everything takes time and nearly 
always more than I first imagine. Step one for me was just getting clear 
what they really were and moving them to functions.inc where I've 
already slowly been changing f_agate and similar wrappers to inbuilt 
functions.

--- On eval_pigment / Eval_Pigment (and alias capability). I've never 
liked eval_pigment! It's not inbuilt, but we talk about it like it is. 
The functionality is already inbuilt. It's this:

     #include "strings.inc"
     #declare Vec  = <1,2,3>;  //                       *** ***
     #declare FnPig00 = function { pigment { rgb <0,1,0,0.2,0.3> } }
     #declare Rslt = FnPig00(Vec.x,Vec.y,Vec.z);
     #debug concat("   ",CRGBFTStr(Rslt,2,2),"\n")

The problem with things like eval_pigment and alias capability is they 
hide the actual code/functionality mostly on the argument of less 
typing(4). If you want to type less, add hot key sequences to your 
editor to insert code templates.  There's a place for the ability to 
alias or redefine inbuilt functionality in a language, but it should not 
be generally used. It makes things harder to learn and harder to debug. 
I was once handed code to debug where the user had, almost completely, 
redefined the actual input language with aliases.

I cannot add Eval_Pigment to texture.inc. The only include files 
currently packaged with povr are:

     arraycoupleddf3s.inc  functions.inc  rand.inc    strings.inc
     arrays.inc            math.inc       shapes.inc  transforms.inc

My povr approach is includes will be in their own code repository. 
Except rarely where what's in the include is essential to core 
functionality. I've moved Eval_Pigment to math.inc for now as core 
functionality, but it's on my 'maybe it should just go away' list.

(4) - And, yep. I don't like the DBL, SNGL in our source code since 
v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request 
years back which then never got adopted. PRECISE_FLOAT now needs to be 
yanked at some point from povr and I'd like to drop DBL and SNGL too. 
Today you can find the bare 'foat/double' declarations in the source 
code depending on who wrote what. This makes it unlikely we can really 
ever change DBL to be anything but double, for example. Certainly not 
without a lot of type conversions even if, by some chance, everything 
works correctly.

--- On additional lower case constants becoming in-built. I'm not 
opposed so long as they are very common. V38 added tau.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/23/20 2:25 PM, Bald Eagle wrote:
> >
> ...
> First, reminding everyone 'povr' is not POV-Ray. I'm combining my
> responses and when I start to think about major revisions to POV-Ray's
> SDL, I begin to think seriously about bindings to lua, tcl and python.

so, it is late and I had too much coffee, probably..  :-)

how about replacing the SDL, wholesale?!

not knowing the codebase[*], but if the "SDL" was simply a (Tcl) "safe
interpreter", with all the SDL language constructs as commands, then we could
write something like:

set version 3.8

array set global_settings {
  assumed_gamma 1
}

light_source {-1 0 -1 10e5} {color {1 1 1} parallel}


:-)

[*] assuming that the source except 'frontend' and 'parser' stuff would be
(relatively) unaffected.

added, potential, incentives: storing the distribution .inc files,
pre-processed, in a Sqlite db; using a zip VFS for managing/distributing
projects with many files; "reflected channel" to read compressed .inc files (for
large meshes, or Hilbert curves :-)).

flights of fancy..

> ...
> (1) ... if we had the list support.

would be built in.  ;-)

> ...
> (3) - Most namespace languages to which I've been exposed support a
> 'using <namespace>::min' sort of declaration. These often get used -
> because people don't like to type - but, allowing the shorthand can
> weaken the namespace protections.

a typical "Problem Exists Between Chair And Keyboard" problem.

> --- On jr's point about no type checking. I think we are not too
> exposed. While there is no strict up front type checking, it looks to me
> like the parser tracks the current id types so you cannot incorrectly
> use the wrong type due a bad/unfortunate assignment somewhere.

sure, I just think that, just like for regular arrays, when an identifier has
been "cast" to type A, a subsequent assigning of type B should output a warning
(preferably cause an error).  because, in all likelihood, it'll be a typo or
logic error.

> ...
> --- On eval_pigment / Eval_Pigment (and alias capability). I've never
> liked eval_pigment! It's not inbuilt, but we talk about it like it is.

naive question.  calling the macro returns the colour in pigment at given point.
 but what good is that information, given that lighting is not part of the
process?


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> so, it is late and I had too much coffee, probably..  :-)

Too much _something.
WTH is "too much coffee?"   :P


> how about replacing the SDL, wholesale?!

That has its merits, and may be a method of addressing all of the double/single
issues in the process...


> sure, I just think that, just like for regular arrays, when an identifier has
> been "cast" to type A, a subsequent assigning of type B should output a warning
> (preferably cause an error).  because, in all likelihood, it'll be a typo or
> logic error.

Could be.   But I like the flexibility afforded by re-casting things on the fly.
Learning good coding practices aside, allowing scenes to WORK (newbies to
POV-Ray in mind) is something we should encourage.
Issue warnings and suggestions - but full stop halts of parsing can be a real
bummer.

> > --- On eval_pigment / Eval_Pigment (and alias capability). I've never
> > liked eval_pigment! It's not inbuilt, but we talk about it like it is.

I like the capability, but I agree with the obfuscation.  I've learned SO much
from WP and the do-it-from-scratch ShaderToy community.  Perhaps eval pigment
should be an example scene illustrating how to write functions that process
patterns.
But also, given that we often use it with things like ("large") images in
image_pattern, I'd like to see a speed improvement by moving something like that
to source, so that an array of RGB values can be accessed and acted upon
speedily, via compiled code.

> naive question.  calling the macro returns the colour in pigment at given point.
>  but what good is that information, given that lighting is not part of the
> process?


Because you're not trying to jump ahead in time beyond when the lighting and
ambient occlusion get applied.  You're looking to inspect the "color
composition" of the base object.

perhaps for pattern purposes.
http://news.povray.org/povray.binaries.images/thread/%3Cweb.52ede41cd6fcc84f7a3e03fe0@news.povray.org%3E/?mtop=391443&m
off=7
http://news.povray.org/povray.binaries.images/message/%3C3b8946fd%40news.povray.org%3E/#%3C3b8946fd%40news.povray.org%3
E
http://news.povray.org/povray.binaries.images/thread/%3C5078802b%40news.povray.org%3E/

or for use as a map to place objects
http://www.povcomp.com/entries/124.php
http://news.povray.org/povray.binaries.images/message/%3C409135b4%40news.povray.org%3E/



Similar questions have been raised:
http://news.povray.org/povray.general/thread/%3C5be81e8e%241%40news.povray.org%3E/

If you want lighting, you can render, and then use eval pigment on the rendered
image, which obviously has the lighting effects in the final computation of the
pixel color value.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > so, it is late and I had too much coffee, probably..  :-)
>
> Too much _something.
> WTH is "too much coffee?"   :P

</grin>

> > ...  because, in all likelihood, it'll be a typo or logic error.
>
> Could be.   But I like the flexibility afforded by re-casting things on the fly.
> Learning good coding practices aside, allowing scenes to WORK (newbies to
> POV-Ray in mind) is something we should encourage.
> Issue warnings and suggestions - but full stop halts of parsing can be a real
> bummer.

the flip side is, every such "flexibility" comes, somewhere down the line, at
some cost.  for instance, allowing:
#declare A = "foo";
....
#declare A = <1,2,3>;

gives flexibility, but also means that (automatically) optimising code has
become too costly (in time), if not impossible altogether.


> > > --- On eval_pigment / Eval_Pigment (and alias capability).
> Similar questions have been raised:  ...

interesting thread, thanks.


regards, jr.

Post a reply to this message

On 6/24/20 8:12 PM, jr wrote:
...
>> First, reminding everyone 'povr' is not POV-Ray. I'm combining my
>> responses and when I start to think about major revisions to POV-Ray's
>> SDL, I begin to think seriously about bindings to lua, tcl and python.
> 
> so, it is late and I had too much coffee, probably..  :-)
> 
> how about replacing the SDL, wholesale?!
> 

Suppose the short answer is it's harder than it looks... And I agree 
with Bald Eagle about there never being enough coffee. When did I last 
drink water, straight... :-)

I have a somewhat complete set of tcl wrappers for POV-Ray 'SDL' 
creation which I use about as often as POV-Ray's SDL itself when 
creating scenes. It's an effort started as a small limited utility which 
grew into something to explore what a tcl scene description language 
might be like. It's an experiment so approaches drift and change. Some 
parts are now quite old/dated.

There are a good many subtle things POV-Ray's language (the parser) does 
to help us code that are not easy to replicate even supposing one knows 
what they all are... I guarantee I've still got lots of bugs in this 
aspect of my wrapping.

With respect to actual bindings, the source code is better partitioned 
than it was - thanks mostly to Christoph. Still, any bindings reasonably 
complete are a ways off from doable in my opinion. This doesn't mean 
it's not possible to create particular bindings today. Somewhere I have 
an experiment where I was binding particular shape functions for testing 
purposes. A kind of tcl unit test, but it's work since gone cold.

The aim with what I have is that every scene entity is a definable item 
with an ID. POV-Ray started with this approach and then dropped this 
concept when certain features were added - radiosity, warps, etc. - over 
time. Not sure of all the whys. With define-ability in place you can 
define RadiosityQuick and RadiosityFinal for example and then pick in 
the 'SDL/Tcl' which to use by name.

The start of a scene with my wrappers looks like:

set FID "FIDmain"
DefVersion        Version      $FID "3.8" -unofficial povr
DefGlobalSettings Global00     $FID -assumed_gamma 1.0
DefBackground     Background00 $FID -color Grey50

DefLight Light00 $FID -location 50.0,150.0,-250.0 -color White
#... ending with:
Scene tmp.pov $FID -i Version -i Background00 -i Global00
	-i Camera00 -i Light00

Every command has inbuilt help; fairly extensive checking; most have 
inbuilt examples which can be used for testing and some have specific
test scenes too. Where you see -color the color definition is created on 
the fly when not already done from a large library of color names. What 
gets included in any particular scene/include file is based on 
dependencies from the -i, -d and -c Scene flags.

Anyway. Details not that important. The point is I've been playing with 
a wrapper for a long time (10 years on and off now) - and while 
extensive, it's not complete. Parts of it I look at today and want to 
rework, but where it's mostly working, I leave it. It's an experiment.

It's not quite what you posted example wise, but I do sometimes wonder 
how far one might get creating a tcl intepreter supporting POV-Ray's 
commands as is. Meaning, aiming more for a parser replacement without 
trying to address existing shortcomings from the start.

Bill P.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> the flip side is, every such "flexibility" comes, somewhere down the line, at
> some cost.  for instance, allowing:
> #declare A = "foo";
> ....
> #declare A = <1,2,3>;
>
> gives flexibility, but also means that (automatically) optimising code has
> become too costly (in time), if not impossible altogether.

I don't know how it gets optimized, or why allowing recasting would break that.

If I can envision a macro that checks if an identifier that I'm trying to use is
defined - and if it is, then first I undefine it, and then proceed as usual -
then I would imagine that such a  thing could be done in C / c++.

It would be very nice indeed if we had a way in SDL (or povr) to determine the
type of an identifier.  This would be _extremely_ useful when importing data
with #read and probably other cases as well.

As much as I like the programming aspect of POV-Ray, it is of course, a
raytracer, and the point is to make renders, not pedantically ram "best coding
practices" down some newbie doodler's throat.

At that point, perfect becomes the mortal enemy of good, and we lose a lot of
otherwise new USERS - which POV-Ray will die without.  Having recently been
thrust into coding the Arduino, which is supposed to be designed for "beginners"
and kids - dealing with all of the esoteric BS involved with strings and serial
input, buffers, types, etc --- it's a REAL PITA to even perform otherwise simple
tasks.  And I'll bet some people simply give up out of frustration.

Do we really want to repel people with an even steeper learning curve?

I mean, I see us stuck between accessibility, speed, and accuracy.
And the multithreaded source code has already become a vast, organically
interwoven behemoth.  It's hard to say what the best route to take is.

Post a reply to this message

On 24.06.2020 19:53, William F Pokorny wrote:
> (4) - And, yep. I don't like the DBL, SNGL in our source code since 
> v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request 
> years back which then never got adopted. PRECISE_FLOAT now needs to be 
> yanked at some point from povr and I'd like to drop DBL and SNGL too. 
> Today you can find the bare 'foat/double' declarations in the source 
> code depending on who wrote what. This makes it unlikely we can really 
> ever change DBL to be anything but double, for example. Certainly not 
> without a lot of type conversions even if, by some chance, everything 
> works correctly.

Except, that is not why they are there: DBL is in the source code 
because there was a time when you could not depend on "double" actually 
doing what you wanted it to do. A time when certain CPUs had 80 bit 
floating point numbers, and other odd things with software emulated 
floating-point. In this world it was essentially that the floating-point 
representation could be changed. These days are long over, but the code 
just happens to be so old that it still has these leftovers.

Thorsten

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/24/20 8:12 PM, jr wrote:
> ...
> >> First, reminding everyone 'povr' is not POV-Ray. I'm combining my
> >> responses and when I start to think about major revisions to POV-Ray's
> >> SDL, I begin to think seriously about bindings to lua, tcl and python.
> >
> > so, it is late and I had too much coffee, probably..  :-)
> > how about replacing the SDL, wholesale?!
>
> Suppose the short answer is it's harder than it looks... And I agree
> with Bald Eagle about there never being enough coffee. When did I last
> drink water, straight... :-)

:-)

> ...
> It's not quite what you posted example wise, but I do sometimes wonder
> how far one might get creating a tcl intepreter supporting POV-Ray's
> commands as is. Meaning, aiming more for a parser replacement without
> trying to address existing shortcomings from the start.

thanks for giving me/us some insight in to your "personal" tools.

on parser replacement, I guess that's what I meant by a "safe" interpreter
pre-loaded with commands; the example was just off the top the head.  in fact,
had I thought ahead, I'd written:

set version 3.8
include colors.inc
array set global_settings {...}
light_source location {-1 1 -1 10e5} color white mods {parallel shadowless}

ie use 'dict' style lists as arguments, throughout.

anyway, personally, I look forward to more Tcl .. influence on development.

(re lists.  I think a distribution .inc file implementing an i/f similar to Tcl
lists would (could?) be sufficient/"good enough")


regards, jr.

Post a reply to this message

On 6/26/20 1:43 AM, Thorsten wrote:
> On 24.06.2020 19:53, William F Pokorny wrote:
>> (4) - And, yep. I don't like the DBL, SNGL in our source code since 
>> v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request 
>> years back which then never got adopted. PRECISE_FLOAT now needs to be 
>> yanked at some point from povr and I'd like to drop DBL and SNGL too. 
>> Today you can find the bare 'foat/double' declarations in the source 
>> code depending on who wrote what. This makes it unlikely we can really 
>> ever change DBL to be anything but double, for example. Certainly not 
>> without a lot of type conversions even if, by some chance, everything 
>> works correctly.
> 
> Except, that is not why they are there: DBL is in the source code 
> because there was a time when you could not depend on "double" actually 
> doing what you wanted it to do. A time when certain CPUs had 80 bit 
> floating point numbers, and other odd things with software emulated 
> floating-point. In this world it was essentially that the floating-point 
> representation could be changed. These days are long over, but the code 
> just happens to be so old that it still has these leftovers.
> 

Yes, thanks. A good point.

It's easy to forget while playing with code today that those who created 
POV-Ray were working in a much tougher, unstable environment. Plus we 
now have ready access to so much more information - Wikipedia, papers, 
on line code, etc.

Bill P.

Post a reply to this message

> Yes, thanks. A good point.
> 
> It's easy to forget while playing with code today that those who created 
> POV-Ray were working in a much tougher, unstable environment. Plus we 
> now have ready access to so much more information - Wikipedia, papers, 
> on line code, etc.

Ah, the same things existed back then. They were called books ;-)

Thorsten

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> One just has to keep in mind POV-Ray's scope leakage

> [2] If you have formal computer science education, you are mortified by
> these restrictions, wondering how people smart enough to create POV-Ray
> could have allowed such boneheaded violations of modular practice.  I am
> assured that the current development team is aware of such problems.
> Yes, I will keep complaining about the scope leakage until it is fixed.

This is an area where I've harbored suspicions and trepidation, due to
subconscious knowledge gathered from reading the newsgroups and docs over the
past years.

Jr and I have recently been working on some code, and while implementing /
rewriting a macro, some recursion was introduced, and a variable identifier was
passed back into the macro as an argument.  Debugging hilarity ensued.

If I understand it all correctly:
When you #declare variable N to have some value, and then use N as the
"temporary" variable name of what gets passed into the macro, and then use
#local to declare N's new in-macro / in-loop value ....  the global / higher
level value of N gets redeclared.
So apparently "POV SDL apparently makes no distinction between passing-by-value
and passing-by-reference, as other languages do."

Or maybe I have that wrong somehow - because reading the docs seems to
contradict that assertion:
2.2.2.2.3 Identifier Name Collisions
http://www.povray.org/documentation/view/3.6.1/237/

Perhaps we can have some more educated and astute (than I am) commentary on
this?
This goes back to a point I've made many times.   Documentation is fine - but
code examples give you something that is undeniable and that you have far less
likelihood of misunderstanding.

THIS works (as expected intended):

THIS does not: (because...)

THESE are a few tricky examples....:


Now here's the interesting part - which I had NO IDEA was even a thing:
"turns out, there's a (documented *) way to force POV-Ray to always treat a
macro argument as pass-by-value.  Add a '+' in front of the identifier name and
voila, POV-Ray is not "not allowed" to pass-by-reference because we're not using
an identifier, but an expression.

so:
     A(+N)
will leave N alone."

http://www.povray.org/documentation/view/3.6.1/243/
* "Consider these examples.

  #declare Value=5.0;
  MyMacro(Value)     //MyMacro can change the value of Value but...
  MyMacro(+Value)    //This version and the rest are not lone
  MyMacro(Value+0.0) // identifiers. They are float expressions
  MyMacro(Value*1.0) // which cannot be changed.
Although all four invocations of MyMacro are passed the value 5.0, only the
first may modify the value of the identifier."

Post a reply to this message

On 2020-06-27 11:05 AM (-4), Bald Eagle wrote:
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> One just has to keep in mind POV-Ray's scope leakage
> 
>> [2] If you have formal computer science education, you are mortified by
>> these restrictions, wondering how people smart enough to create POV-Ray
>> could have allowed such boneheaded violations of modular practice.  I am
>> assured that the current development team is aware of such problems.
>> Yes, I will keep complaining about the scope leakage until it is fixed.
> 
> This is an area where I've harbored suspicions and trepidation, due to
> subconscious knowledge gathered from reading the newsgroups and docs over the
> past years.
> 
> Jr and I have recently been working on some code, and while implementing /
> rewriting a macro, some recursion was introduced, and a variable identifier was
> passed back into the macro as an argument.  Debugging hilarity ensued.

Ah, yes, I've run across this before.  Take a look at macro CH2RGB() in 
colors.inc.  The parameter HH used to be H before I blundered into the 
pass-by-reference trap and my scene file fell into an infinite loop. 
Thanks to Jerome for figuring out the problem, and to whoever fixed it 
in time for the POV-Ray 3.7 release.

I ran across it again in Lightsys IV.  (That bug was also fixed in 2012.)

Which area are you concerned about, scope leakage, or accidental 
pass-by-reference?

> If I understand it all correctly:
> When you #declare variable N to have some value, and then use N as the
> "temporary" variable name of what gets passed into the macro, and then use
> #local to declare N's new in-macro / in-loop value ....  the global / higher
> level value of N gets redeclared.
> So apparently "POV SDL apparently makes no distinction between passing-by-value
> and passing-by-reference, as other languages do."

I would say that it does, but the distinction is not explicit; the 
distinction manifests in how you express the argument, as you have 
discovered below.

> [snip]
> 
> Now here's the interesting part - which I had NO IDEA was even a thing:
> "turns out, there's a (documented *) way to force POV-Ray to always treat a
> macro argument as pass-by-value.  Add a '+' in front of the identifier name and
> voila, POV-Ray is not "not allowed" to pass-by-reference because we're not using
> an identifier, but an expression.
> 
> so:
>       A(+N)
> will leave N alone."
> 
> http://www.povray.org/documentation/view/3.6.1/243/
> [snip]

I have no problem with this.  At the *very* worst, it's a "I don't like 
the way this works so it must be a bug," but I won't even go that far. 
While pass-by-reference is dangerous if misused, it is still an 
important tool, and making POV-Ray strictly pass-by-value would 
compromise its flexibility.  C can be strictly pass-by-value it because 
one can pass an address to effect pass-by-reference.

While I admit it would be nice for POV-Ray to have an explicit 
distinction between pass-by-value and pass-by-reference, I would give it 
a low priority.  POV-Ray's implicit distinction is clearly defined and, 
as you have noted, well documented, confusing though it may be.  As long 
as you are careful with your coding, it is not a problem.

Scope leakage is a different matter.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> >> Yes, I will keep complaining about the scope leakage until it is fixed.
> >
> > This is an area where I've harbored suspicions and trepidation, due to
> > subconscious knowledge gathered from reading the newsgroups and docs over the
> > past years.
> >
> > Jr and I have recently been working on some code, and while implementing /
> > rewriting a macro, some recursion was introduced, and a variable identifier was
> > passed back into the macro as an argument.  Debugging hilarity ensued.

> Which area are you concerned about, scope leakage, or accidental
> pass-by-reference?

> Scope leakage is a different matter.

Scope leakage.
Pass-by method is fine so long as it's stable and reliable and constant.

Not knowing what scope I'm working in - that can be a real issue.
I'll have to think about the permutations and write a pov and inc file to see
how I can try to either break or retain the scope of a given variable between
the two files, and with loops and macros throw into each as well.

Post a reply to this message

On 6/26/20 7:05 PM, Thorsten wrote:

>> It's easy to forget while playing with code today that those who 
>> created POV-Ray were working in a much tougher, unstable environment. 
>> Plus we now have ready access to so much more information - Wikipedia, 
>> papers, on line code, etc.
> 
> Ah, the same things existed back then. They were called books ;-)

    And we can call 911-COMPU$ERVE :)


-- 
+-------------------------------------------------------------------+
http://weblog.mixart-myrys.org/?post/2021/01/Laissez-nous-exister-%21
+-------------------------------------------------------------------+

Post a reply to this message

Am 23.06.2020 um 19:25 schrieb Cousin Ricky:
> On 2020-06-23 7:28 AM (-4), William F Pokorny wrote:
...
>> We have the convention today users should not declare IDs with lower 
>> case characters because such things might become, or might already be, 
>> SDL keywords. What I'm thinking about for povr is adding checking such 
>> that users cannot declare/local a name with only (lower case ascii, _) 
>> characters. #declare _a =... would be a parsing error.
>>
>> With this in place, I think it would then be the case we could always 
>> use something like _<lowercase_parm> for all our parameters without 
>> worry of collisions. The _ leading character would never be part of a 
>> keyword.
>>
>> Am I missing something with this planned approach?

Been there. Done that.
Curesed a lot.

> I suppose it could work.  It could potentially break old scenes, but I 
> don't suppose many such scenes exist.  None of the stock include files 
> have any such names that I can find.

Look harder.
`functions.inc` is what made me put the idea on the back burner.

Post a reply to this message

Am 24.06.2020 um 19:53 schrieb William F Pokorny:

> (4) - And, yep. I don't like the DBL, SNGL in our source code since 
> v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request 
> years back which then never got adopted. PRECISE_FLOAT now needs to be 
> yanked at some point from povr and I'd like to drop DBL and SNGL too.

I'm trying to jog my memory here to recall what that PRECISE_FLOAT was 
all about, but for the love of it I can't find no reference to it, 
except mentions by you yourself: One in 2019-02-17 in povray.beta-test 
where you posted a snippet apparently from a custom 
`polynomialsolver.cpp` where it appears in a comment, and one in a pull 
request from LeForgeron, titled "fix for FS324, regression on triangle" 
(pull request #358), where you mentioned "the new PRECISE_FLOAT compile 
hook" on 2019-06-06.

Can you help me out which pull request of yours that would have been, 
for which I suggested the use of PRECISE_FLOAT?

The Interwebkraken knows nothing else about it, GitHub can't seem to dig 
it up, and even in all my dozen unpublished half-finished branches that 
spun off at different times in history and still reside on my computer, 
none of them seems to contain the character sequence "PRECISE_FLOAT".


Is there a publicly accessible repo for your povr branch? Seeing where 
you're using the thing might bring my memory back up to speed.

Post a reply to this message

On 5/26/21 10:58 PM, clipka wrote:
> Can you help me out which pull request of yours that would have been, 
> for which I suggested the use of PRECISE_FLOAT?

Related to selective use of long doubles where the hardware supports 
80/96 bits or more.

There is today no value to you or the POV-Ray code mainstream to dig 
into this. It's my code base stuck with something once thought might be 
of value which - knowing what I know today - isn't. It doesn't hurt 
anything other than my code's esthetics to have it sitting in there. It 
just bugs me that it is there.

Bill P.

Post a reply to this message

On 5/26/21 9:23 PM, clipka wrote:
> Am 23.06.2020 um 19:25 schrieb Cousin Ricky:
>> On 2020-06-23 7:28 AM (-4), William F Pokorny wrote:
> ...
>>> We have the convention today users should not declare IDs with lower 
>>> case characters because such things might become, or might already 
>>> be, SDL keywords. What I'm thinking about for povr is adding checking 
>>> such that users cannot declare/local a name with only (lower case 
>>> ascii, _) characters. #declare _a =... would be a parsing error.
>>>
>>> With this in place, I think it would then be the case we could always 
>>> use something like _<lowercase_parm> for all our parameters without 
>>> worry of collisions. The _ leading character would never be part of a 
>>> keyword.
>>>
>>> Am I missing something with this planned approach?
> 
> Been there. Done that.
> Curesed a lot.
> 
>> I suppose it could work.  It could potentially break old scenes, but I 
>> don't suppose many such scenes exist.  None of the stock include files 
>> have any such names that I can find.
> 
> Look harder.
> `functions.inc` is what made me put the idea on the back burner.

Yes, there's that and more for complications. I've had some success with 
it and it's how I've been running day to day for near a year now(1). 
Twiddle with the hacked in code now and again as I pick up some detail - 
recently performance impacts doing millions of calls to macros. Made it 
better, but, thinking now even when compiled in there should perhaps be 
a run time switch - but given how our macros work even simple that would 
be seen performance wise in the worst cases.

Today, I'd say it'll stay in as a configure option for sure, but we'll see.

Bill P.

(1) - It lines up with my coding style/aim where it won't with all.

Post a reply to this message