hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/31/20 4:19 AM, jr wrote:
> > ...
> > cannot say the same.  guess I'm "allergic" to uppercase.  :-)
> >
> > (could this behaviour be enabled/disabled via a 'povray.conf' setting instead?)
> >
>
> Maybe in the near term, but the whole idea is to offer a way to code
> function and macro parameters which will never collide. This method only
> works if people cannot turn off the case checking.
>
> I don't think there is any magic here. Name spaces, or whatever method,
> any fix(es) for indentifier name collisions will require changes to
> existing code and coding habits.

while I agree that the "method only works if", and that, ultimately, "existing
code and coding habits" would (will?) need to change as part of a process, I
found myself thinking about a car analogy, the time when what are now "classic"
cars had to be retrofitted with seat belts[*]; and I wonder whether, like with
the seat belt, the primary victim of car-based incidents, the pedestrian, will
not actually benefit.  </rant>  (:-))

[*] and since they weren't designed with "attach points" in mind, other problems
arose.

I'll address a couple of other points here too.

> I fact looked to me as if several POV-Ray shipped includes are doing
> pointless includes which of course burns parse time for no reason.

yes.  I now tend to simply cut+paste the one or two bits I need from a given
POV-Ray include file into the scene, to get that efficiency.  Bald Eagle makes a
good point about a "monolithic" include, if we had a stand-alone parser,
conceivably, one could write a scene file "optimiser" using that.

in reply to Le Forgeron you write wrt permissions: "A properly set up
unix/linux/*x system..".  just to add for completeness that unlike past setups,
where Alice and Bob were in the (primary) 'users' group, these days it is common
for Alice and Bob to be in their own respective groups, with 'users' membership
being additional; ie even safer by default (assuming system is set up +
maintained).

and lastly, on the 'system()'/'#fopen' .. speculations.

> The more tangled part is what would a command set supporting directories
> look like. Then we'd have the implementation of those commands,
> documentation and training of users. I saw too jr's suggestion for
> system commands. I don't know...

the .. hankering after :-) a 'system()' function, which would have allowed eg BE
to write "system("mkdir -p new/sub/tree")", was long-term.  but I had my "road
to Damascus" moment when I read BE's post, and now think that modifying '#fopen'
to allow bi-directional access to a command would be both a "sympathetic"
extension of the SDL, and a very useful one in that it would permit (promote?) a
completely different way of writing scene code; you already do something
similar, so can vouch for the "useful" aspect.


regards, jr.

Post a reply to this message