Please find attached an updated tarball.

Attempting no lower case #declare, #local identifier idea. Hope is 
user's function and macro arguments made _<lower case> form will be 
immune to name collisions.

With a thought toward eventual real time modeling, continuous real time 
rendering enabled as it has been in window's versions since v37. Added a 
rtr_kla.pov sample scene for the feature.

The rtr_kla.pov scene implements an alternative to the persistent 
keyword marking idea of uberpov. While the continuous / real time 
rendering only supports multiple camera positions today, multiple frames 
can be rendered with one scene parse where more than the camera changes.

The idea is to create multiple fixed sets in which changes are made and 
where a camera is appropriately placed in each. Mentally one must, of 
course, still keep track of what is persistent and what is not, but we'd 
not need a new keyword and the code infrastructure behind it - supposing 
eventual frame capture capability. Simpler, perhaps, to look at the 
sample scene to get the idea.

Corrections to the DOINGMAKECHECK=YES build implementation - thanks jr.

I've not seen an x11 display issue in the week since adding the 
XInitThreads() call - thanks jr. Thinking of making x11 the default as 
it's windowing behavior is more consistent with my Ubuntu environment.

Added an inbuilt f_toupie() function supporting 1-15 as integer 
exponents where f_toupie() usually uses 3. Provides for a range of 
shapes lemon like, torus like (exactly the torus at 2), toupie like and 
button-ish shapes.

Bill P.

Post a reply to this message

Attachments:
Download 'povray2_f6b1c13e.tar.gz' (1636 KB)

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please find attached an updated tarball.

thanks.  compiles.  will properly make + install sometime later this week.

one thing I noticed, 'povr' links against an older version of libpng, unlike the
"stock" POV-Ray.

jr@swift:13:~$ ldd /usr/local/bin/povray-3.8.0-alpha.10064268
    ...
    libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f6cc19c5000)
    ...
jr@swift:14:~$ ldd POVr/bin/povray2
    ...
    libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fb50195f000)
    ...
jr@swift:15:~$

the updated version too links to 1.2.50, when 1.6.37 is available.

> Attempting no lower case #declare, #local identifier idea. Hope is
> user's function and macro arguments made _<lower case> form will be
> immune to name collisions.

(crestfallen..)  hope 'a_' will be as acceptable as '_a'.

> ...
> I've not seen an x11 display issue in the week since adding the
> XInitThreads() call - thanks jr. Thinking of making x11 the default as
> it's windowing behavior is more consistent with my Ubuntu environment.

+1.  :-)


regards, jr.

Post a reply to this message

On 7/20/20 8:54 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> Please find attached an updated tarball.
> 
> thanks.  compiles.  will properly make + install sometime later this week.
> 
> one thing I noticed, 'povr' links against an older version of libpng, unlike the
> "stock" POV-Ray.
> 
> jr@swift:13:~$ ldd /usr/local/bin/povray-3.8.0-alpha.10064268
>      ...
>      libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f6cc19c5000)
>      ...
> jr@swift:14:~$ ldd POVr/bin/povray2
>      ...
>      libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fb50195f000)
>      ...
> jr@swift:15:~$
> 
> the updated version too links to 1.2.50, when 1.6.37 is available.

Interesting find. :-) Unsure why you see a difference in library used.

It's my understanding when there are multiple versions of a library in 
place on a system there is usually a sym link established from a generic 
name to the 'official' one for the particular linux distribution. It 
would be normal then for the official distribution version to be picked 
up first. This is not necessarily the newest (or oldest) one if you have 
multiple development library versions on a system(1).

(1) - Not all that common, but certainly happens. I have only one libpng 
version on my Ubuntu 18.04 system.

There are certainly ways to override which library gets picked up 
explicitly. Hmm, wonder, if you've got multiple libraries and no symlink 
to a version-less name like libpng.so.1 I'm unsure how one library would 
be picked over another? Do you have the common sym link name given you 
have two libpngs?

> 
>> Attempting no lower case #declare, #local identifier idea. Hope is
>> user's function and macro arguments made _<lower case> form will be
>> immune to name collisions.
> 
> (crestfallen..)  hope 'a_' will be as acceptable as '_a'.
> 

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_ :-).

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/20/20 8:54 AM, jr wrote:
> > ...
> > one thing I noticed, 'povr' links against an older version of libpng, unlike the
> > "stock" POV-Ray.
> > ...

> ... Hmm, wonder, if you've got multiple libraries and no symlink
> to a version-less name like libpng.so.1 I'm unsure how one library would
> be picked over another? Do you have the common sym link name given you
> have two libpngs?

bingo.  yes, the "version-less" names ('libpng.{la,so}') were pointing to the
old(est) version; guess must have happened when I re-compiled/re-installed
1.6.37.  cheers.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 7/20/20 8:54 AM, jr wrote:
> > > ...
> > ... Hmm, wonder, if you've got multiple libraries and no symlink
> > to a version-less name like libpng.so.1 I'm unsure how one library would
> > be picked over another? Do you have the common sym link name given you
> > have two libpngs?
>
> bingo.  yes, the "version-less" names ('libpng.{la,so}') were pointing to the
> old(est) version; guess must have happened when I re-compiled/re-installed
> 1.6.37.  cheers.

right, and now we're getting to the bit where it gets .. strange.  :-)

built the new version of 'povray2', checked libpng link - ok, and 'make check'
ran fine, so installed.  went back into the scenes directory, and all three
scenes now fail with:
  ...
  Trace Time:       0 hours  0 minutes  0 seconds (0.354 seconds)
              using 4 thread(s) with 1.388 CPU-seconds total
Cannot allocate PNG data structures
Cannot allocate PNG data structures
Render failed

:-)  everything works as normal until it needs to write the disk file.

unfortunately cannot try those scenes with alpha.10064268, but checked that, and
other programs linking to 'libpng16', still work.  and 'povray2' output to, say,
jpeg, is ok.

'make check' succeeded because it doesn't actually try to write to disk?


regards, jr.

Post a reply to this message

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