![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: An updated povr tarball for Unix/Linux. f6b1c13e
Date: 1 Aug 2020 09:16:05
Message: <5f256b15@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 7/30/20 8:44 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymous org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: An updated povr tarball for Unix/Linux. f6b1c13e
Date: 1 Aug 2020 10:06:06
Message: <5f2576ce$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 7/31/20 12:55 PM, Le_Forgeron wrote:
> Le 31/07/2020 à 16:40, jr a écrit :
>> hi,
>>
>> "Bald Eagle" <cre### [at] netscape net> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: An updated povr tarball for Unix/Linux. f6b1c13e
Date: 1 Aug 2020 10:12:13
Message: <5f25783d$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: An updated povr tarball for Unix/Linux. f6b1c13e
Date: 1 Aug 2020 10:54:45
Message: <5f258235$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 7/31/20 6:29 PM, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymous org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
William F Pokorny <ano### [at] anonymous org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
William F Pokorny <ano### [at] anonymous org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
William F Pokorny <ano### [at] anonymous org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
William F Pokorny <ano### [at] anonymous org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: An updated povr tarball for Unix/Linux. f6b1c13e
Date: 3 Aug 2020 09:40:01
Message: <5f2813b1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 8/2/20 7:33 PM, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymous org> 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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |