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