 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2020-06-23 à 04:42, jr a écrit :
> hi,
>
> Cousin Ricky <ric### [at] yahoo com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
