On 7/30/20 8:44 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Just back from a few days at real life. Back at povr for real tomorrow -
>> or the day after. Ahead of me getting back...
> 
> Is it possible, and is there a security issue related to providing a means to
> create a subdirectory in a write-permitted directory?
> 
> #write creates a file.  Can we create a directory by a similar means?
> Just something to think about.
> 

Yes, and no security issue with unix/linux/*x at least(1).

(1) - Maybe some obscure ways to disable a file system if one works at it.

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...

I'll further hedge. Again due my tcl wrapper, I've not used the POV-Ray 
based IO all that much. You and others, understand SDL IO better than me.

Aside:
My few, true animations I've done with my wrapper so I can do other 
frame to frame work in tcl (as jr suggested useful) and more so to 
see/work with the "as calculated" per-frame scene files while 
debugging/developing. Being able to get an after SDL(tcl) 'runs' scene 
representation is helpful.

My pure POV-Ray animation use has been: Creating a few frames where 
early images are used in a final one; Tickets and promo stuff for an 
arts program; A large puzzle piece image for a town treasure/scavenger 
hunt where the 'animation' created the puzzle piece images which were 
printed on smaller photo sized paper edge to edge. POV-Ray and its 
animation capability is very useful for such projects.

Bill P.

Post a reply to this message

On 7/31/20 12:55 PM, Le_Forgeron wrote:
> Le 31/07/2020 à 16:40, jr a écrit :
>> hi,
>>
>> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>> ...
...
>> have been thinking about (wishing for) for a 'system()' type function for a long
>> time.  but reading the above made me realise that a modified '#fopen' which
>> supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
>> "everything" anyway.  then we could write, eg:
>>
>> #fopen FP "| program" rdwr
>>
>> to communicate with 'program', making creating a directory, all sorts of stuff,
>> easy and convenient.  for instance write some calculated parameters to 'program'
>> and read back new, derived values.
...
> 
> "Danger Will Robinson"
> 
> This could lead to some system corruption... A reason that there is
> already io-restrictions: to protect the innocent.
> 

Though I've used *x systems for a long time, I make no claims on being a 
system image / os expert. I get that there might have been reasons for 
the io restrictions long ago, but how much protection do the io 
restrictions 'really' offer these days?

A properly set up unix/linux/*x system - whether POV-Ray is installed or 
not - already sets permissions which prevent regular users from reading 
and writing system directories and files.

Excepting, when they are allowed to run as root, in which case they 
already have an infinite number of ways to corrupt the system. And, as 
root, they can even do it using POV-Ray too as it ships/is-packaged today.

On systems, true multi-user or not, a regular user can fill up /tmp for 
example. They can chew up all the real ram, perhaps even all the swap 
with enough time (assuming the system admins are not running monitors 
which kill bad acting processes).

I look at our io restrictions and I think they likely cause as many 
users problems as they solve(1), while making it only a little easier 
for POV-Ray as an entity to say "it's unlikely POV-Ray wiped out your 
system."

(1) - When users or well intention-ed system admins prevent folks from 
being able to read and write where they should be able to read and write.

What am I missing?

Bill P.

Post a reply to this message

On 7/31/20 4:19 AM, jr wrote:
> hi,
...
> 
> no, for me it's just[*] the lower/uppercase stuff.  basically, each of my old
> scenes I tried, failed.  I thought about modifying scene code, but since they
> work I'll find it easier not to use (the new version of) 'povr'.
> 
> [*] at present.
> 
>> Are there actual conflicts/problems with the approach; or examples where
>> it's very inconvenient?
> 
> just inconvenient.  eg, to "fix" the scene I used when I ran into the X11
> animation issue, would be a lot of work, made worse by the fact that I got that
> scene from the web, ie it's not even my code.
> 
>> The functionality is still hacked in - because I'm trying it too. :-)
>> But, thus far, I'm liking the behavior.
> 
> 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.

Bill P.

Post a reply to this message

On 7/31/20 6:29 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> Please find attached an updated tarball.
>> ...
> 
> ran into a problem with some code I was sent.
> 
> ==== [Parsing...] ==========================================================
> #include "spheresweep.inc" //version 1.2
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Possible Parse Error:
> Cannot find file 'Wrapper.inc', even after trying to append file type extension.
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Parse Error:
> Cannot open include file Wrapper.inc.
> Fatal error in parser: Cannot parse input.
> Render failed
> 
> 
> regards, jr.
> 
Ah, dang. Thanks!

While I'm working on new inbuilt functions, I use the Wrapper.inc 
include. It's found via my own POVINI variable setting and is used to 
point to a git tracked functions.inc file instead of the normal 
./include directory. The latter is not at the moment code controlled - 
though that's the plan.

In short, Wrapper.inc is a hack that lets me develop without having to 
create a build package on inbuilt function re-compiles. This mistake 
happened when I implemented an inbuilt f_supertorus() and updated the 
existing Supertorus shapes.inc macro to call it over, the old explicit 
function {} isosurface code.

I reviewed the other povr shipped includes just now - and I found one 
other mistake... I'd un-commented, or as likely commented in the wrong 
directory, the const.inc include in rand.inc and it declares 'e' which 
fails the lower case check. That include const.inc isn't needed today 
even in POV-Ray best as I can tell(1).

(1) - 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. 


Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> The more tangled part is what would a command set supporting directories
> look like.

I don't use any of the shellout commands, but I would imagine it would just be a
call to the "DOS" to create the specified directory.
mkdir "newDirectory"

#CreateDirectory "newDirectory"

The only bell-and-whistle thing I could envision would be opening a file for
writing in a subdirectory that doesn't yet exist, and automagically creating the
necessary directory branches for the file.  Probably wisest to purposefully
enable this feature to guard against simple typographical errors.

> Then we'd have the implementation of those commands,

I'm guessing you mean the actual POV-Ray source code

> documentation and training of users.

Which would be --- 3 or 4 lines of text?  :D
I mean, I know that packages of food come with instructions nowadays, "1. tear
open package 2. remove contents 3. eat" but I'm pretty sure most of it ought to
be "self-evident".

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

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

Yes, and some don't have prerequisite include statements for their dependencies.
  I think that the segment of torus object needs something in another shapesN
include file and that include file isn't in the file "header".

Some of the other include files / insert files have some mysterious blocks of
code that I haven't deciphered/translated [yet].  IIRC, FL's analytic geometry
has a few near the end...

I was trying to figure out a way to create a monolithic include file that could
selectively include whatever you specified, but I haven't figured out the best
way to do that.

Post a reply to this message

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

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/29/20 2:16 PM, jr wrote:
> ...
> regarding that, I did a
> > 'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
> > call (including surrounding conditional) the only thing that would need to be
> > added to allow the _f9bc4ef7 version to function safely wrt X11?
>
> As safely as the newer release, yes.
> ...

not sure you will be as pleased as I am, but I've successfully downgraded to a
patched _f9bc4ef7.  I've used it to re-run the animation, no problems.  and it
is, for that code, faster than stock POV-Ray.  for the parsing, 'povr' needed
around 13.2 seconds per frame, while the alpha took around 13.8; for a 360 frame
animation, that alone has saved more than three minutes.  the total times (360
frames) were:
      alpha.10064268     povr
real    204m9.135s     181m32.384s
user    547m30.221s    470m55.856s
sys     0m3.471s       0m6.385s

another "interesting" thing is the output of 'ps'.  a big difference in the
virtual memory size, 'povr' barely 2% of POV-Ray's size.  and, puzzling this,
while the thread count ('nlwp') for POV-Ray fluctuates (6 to 10), 'povr's always
reads 1.

and regarding my previous post, I feel I should not have just given the car
analogy and left it at that; another instance of (me) communicating poorly.  I
guess it is, for me, about choice.  if, in the documentation, early and
prominently, there was a section regarding "interoperability", a paragraph on
name collisions and concerns, and one on the naming convention chosen to
(almost) always prevent name clashes, that should suffice. in my case, virtually
all SDL code I write is exclusively for my own consumption/entertainment, hence
my .. feeling bolshie re mandated uppercase, I guess.  :-)  if I write something
I think might be useful and decide to publish, then I'd have no objection to
writing that code to adhere to given guidelines. so, I hope the feature can be
made a selectable option, because I'd like to keep following along on the ..
'povr' journey.  :-)  (I guess I might even use the feature, to check whether
the code "passes")


regards, jr.

Post a reply to this message

On 8/2/20 7:33 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 7/29/20 2:16 PM, jr wrote:
>> ...
>> regarding that, I did a
>>> 'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
>>> call (including surrounding conditional) the only thing that would need to be
>>> added to allow the _f9bc4ef7 version to function safely wrt X11?
>>
>> As safely as the newer release, yes.
>> ...
> 
...
> 
> another "interesting" thing is the output of 'ps'.  a big difference in the
> virtual memory size, 'povr' barely 2% of POV-Ray's size.  and, puzzling this,
> while the thread count ('nlwp') for POV-Ray fluctuates (6 to 10), 'povr's always
> reads 1.
> 

Thank you for information on parsing and render times! I welcome all the 
feedback.

The 2% of normal POV-Ray memory use is surprising/unlikely as is the 1 
thread - given the actual results.

First the obvious, might you have been looking at 'povr' the script and 
not the real running povray command? Otherwise I'm not completely sure.
Something with animation perhaps. Animations do drop back to one thread 
when parsing and memory use would drop there too - initially.

If using photons, the thread use is different in that phase too.

Mostly these days I use top (linux) or htop (Raspberry (now with 8gb 
models and a promise of a true 64bit OS!)). For an artificially long 
running biscuit scene, I do see smaller sizes with top when using -y x11 
- which is not too surprising.

Virtual memory(a) KiB
     1120456 -> 754484 ---> -32.66%
Real memory
      47576  ->  32372 ---> -31.96%

(a) - always a little 'wide' of the mark in my experience.

In news to me. When I look at threads specifically with 'ps -eLf | grep 
povr' I do see a difference between SDL1.2 (v38) and SDL2.0 (povr) in 10 
to 14 active threads on my 2 core 4 thread machine. For me, POV-Ray 
proper normally runs with 10 threads in the final render phase. Six of 
threads are mostly idle. For reasons unknown to me, SDL2.0 has 4 more 
mostly idle threads? A question for the 'someday-maybe look at it 
further' list. :-)

Bill P.

Post a reply to this message

I haven't had much time to explore all of the forks and other projects - but
while they are under development, maybe I could throw some old and new ideas
out.

SO many people have asked to have values like the camera location be available.

As it is a vector, having the ability to have such a value be translated,
rotated, etc. and then queried for the result reminds me that having a point or
vector object that can be manipulated using standard SDL commands would be very
useful for a lot of folks who need to do that kind of thing.

Working on Yadgar's code, I realized that it might be an interesting and useful
thing to be able to access the current memory usage and the current number of
tokens parsed - for reporting, but also to define a bailout so as not to crash
the system, etc.

Obviously there have been many requests for vector functions, and that leads me
to bring this up:
#macro eval_pigment(pigm, vec)
    #local fn = function { pigment { pigm } }
    #local result = (fn(vec.x, vec.y, vec.z));
    result
#end

Somehow this magically returns a vector quantity, rather than a scalar.  :O

Matrix objects would be very nice for certain 3D graphics calculations and
transformations.  Maybe a matrix convolution function for image processing.  I
can see this being closely related to the recent work on function gradients as
well.

1D and 2D fast Fourier transforms.
Paul Bourke already has 2D in-place FFT code in c++ posted on his site.
http://paulbourke.net/miscellaneous/dft/

Just throwing out ideas, as these are inherently source code edits and
additions.

Post a reply to this message