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