hi,

"jr" <cre### [at] gmailcom> wrote:
> ...
> right, and now we're getting to the bit where it gets .. strange.  :-)

ignore.  the problem was the symlinks in /usr/include not pointing to the
correct headers.  :-(  re-built 'povray2' and all three test scenes ok.


regards, jr.

Post a reply to this message

hi,


William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Sure. You can continue to use any names you want for function and macro
> parameters. The _<lower> is the suggestion because it won't collide with
> future SDL keywords where some other lower case string might eventually
> - though probably not a_ :-).

I find I'm not .. getting on with the forced uppercase stuff (sorry), and would
prefer to go back to the first version you posted.  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?


regards, jr.

Post a reply to this message

On 7/29/20 2:16 PM, jr wrote:

Hi,
Just back from a few days at real life. Back at povr for real tomorrow - 
or the day after. Ahead of me getting back...

> 
> I find I'm not .. getting on with the forced uppercase stuff (sorry), and would
> prefer to go back to the first version you posted.  

Could you be more specific?

Povr breaks compatibility with as little as possible - but still quite a 
lot. My aim is to keep behavior near v3.8, but there is certainly more 
compatibility breakage to come. Is it more than wanting to continue to 
use lower case and/or includes which already have lower case?

Are there actual conflicts/problems with the approach; or examples where 
it's very inconvenient?

The functionality is still hacked in - because I'm trying it too. :-) 
But, thus far, I'm liking the behavior. In fact, I recently fixed a miss 
with command line declares letting lower case declare IDs still happen. 
That said, I've not run much old stuff with it as yet. Plus, suppose I 
wasn't in the habit of using lower case locals/declares to begin with.

Our SDL usage is different. I've not much jumped on the newer array, 
dictionary stuff, for example, mostly because it came well after my tcl 
wrapper - which already had that functionality.

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.

There are other fixes and improvements relative to the prior release 
you'll be missing in using the first, but stuff should work except where 
there was already incompatible change - ie fog, inbuilt functions,...

Bill P.

Post a reply to this message

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.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/29/20 2:16 PM, jr wrote:
>...
> > I find I'm not .. getting on with the forced uppercase stuff (sorry), and would
> > prefer to go back to the first version you posted.
>
> Could you be more specific?
>
> Povr breaks compatibility with as little as possible - but still quite a
> lot. My aim is to keep behavior near v3.8, but there is certainly more
> compatibility breakage to come. Is it more than wanting to continue to
> use lower case and/or includes which already have lower case?

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?)

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

thanks, I'll try that then, sometime this weekend.


regards, jr.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> 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.

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.


regards, jr.

Post a reply to this message

Le 31/07/2020 à 16:40, jr a écrit :
> hi,
> 
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> ...
>> 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.
> 
> 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.


You already have "shell-out" capability, with pre & post, scene & frame
level, so grouping actions should be doable to have all you need.

http://wiki.povray.org/content/Reference:Shell_Command_Options

Post a reply to this message

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 31/07/2020 à 16:40, jr a écrit :
> > ... 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.

:-)  true.  otoh, the imagined '|program' form of '#fopen' could be made subject
to the same '[Shellout Security]' setting as the pre/post commands.

> You already have "shell-out" capability, with pre & post, scene & frame
> level, so grouping actions should be doable to have all you need.

also true, I guess, that those commands can be used to do "everything".  still,
there are differences.  for instance, now, if I need to pass multiple/many
calculated values to 'program', I have to write a temporary file to be processed
by 'program', and then read the results on the next frame.  a modified '#fopen'
would allow a different programming style, and would in the example obviate the
need for temporary file(s) and animation control.


regards, jr.

Post a reply to this message

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.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> 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

That's a _weird_ error, especially since line 20 of shapes.inc is
#include "shapes_old.inc"

And there's no reference to 'Wrapper.inc' in either file.

Maybe if you have a reference to that, just comment it out?

Post a reply to this message