 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoo com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
