Please find attached my initial attempt at a Unix/Linux tarball for the 
povr branch of POV-Ray.

It will unpack into a directory called povray2 due my own development 
naming. Supposing you unpack into /tmp/povray2 , it should be you can cd 
into that directory and do something like:

./configure COMPILED_BY="wfp" --prefix=/tmp/povr
make
make check

Optionally:
make install

The install size is 4-5MB. There is a script called povr in the root 
directory. After a little editing, it can be used to run the compile 'in 
place' or from an 'installed' compile result. Copy povr to your bin 
directory or otherwise get it into your $PATH. After which, unix help: 
povr --help

There are a couple of scenes in the scenes directory which should run 
with 'povr fog.pov', say, once you have the povr script set up. A 
reminder povr, often as not, breaks compatibility with existing POV-Ray 
scenes.

A work in progress, but it's getting there. At this point I'm mostly 
interested in whether others can get through 'make check' OK given the 
necessary development libraries are installed local to your machine (see 
./unix/README.md).

Bill P.

Post a reply to this message

Attachments:
Download 'povray2_f9bc4ef7.tar.gz' (1641 KB)

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please find attached my initial attempt at a Unix/Linux tarball for the
> povr branch of POV-Ray.

:-)

> It will unpack into a directory called povray2 due my own development
> naming. Supposing you unpack into /tmp/povray2 , it should be you can cd
> into that directory and do something like:
>
> ./configure COMPILED_BY="wfp" --prefix=/tmp/povr
> make
....
disp_x11.cpp:53:57: fatal error: xpovicon.xpm: No such file or directory

a quick 'find' confirmed that the icon's missing.


regards, jr.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> A work in progress, but it's getting there. At this point I'm mostly
> interested in whether others can get through 'make check' OK given the
> necessary development libraries are installed local to your machine (see
> ./unix/README.md).

found a 'xpovicon.xpm' in the 3.5c source, copied that, and both the make and
make check went through.

thanks.  will play with it, a little, over the coming days.


regards, jr.

Post a reply to this message

On 7/4/20 12:05 PM, jr wrote:
> 
> found a 'xpovicon.xpm' in the 3.5c source, copied that, and both the make and
> make check went through.
> 
> thanks.  will play with it, a little, over the coming days.
> 

Thanks much! In my testing I only needed the .xbm files. Must of only 
searched for xbgmap.xpm when deciding to lose both the *.xpm files...

---
Aside: In the whither thread you gently tossed an arrow at the Simple 
DirectMedia Layer use. I've done a little debug work around 1.2 hangs 
and povr/hgpovray have SDL2.0 and x11 support thanks to Jerome.

https://github.com/POV-Ray/povray/issues/118

https://github.com/POV-Ray/povray/issues/142

My understanding is that SDL1.2 was chosen for v3.7 because of problems 
with x11 at the time - which perhaps are not all that different from 
what we still see with x11 today.

In my povr/POV-Ray use all three display options still have issues with 
x11 being the worst behaving. The x11 and SDL1.2 options suffer from 
occasional hangs requiring a kill command to stop with x11 being worse. 
Not seen the hangs in SDL2.0, but there is once in a while a had row of 
pixels usually in the upper left on scaling to fit a window. I recommend 
SDL2.0 use today if you have a choice.

Others can speak to it better than me, but I believe some of the issues 
come to our code architecture being non-standard with respect to 
interface handling. It would be more normal to have x11/SDL - or 
whatever interface handler be the main loop from which everything else 
is spawned.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/4/20 12:05 PM, jr wrote:
> > found a 'xpovicon.xpm' in the 3.5c source, copied that, and both the make and
> > make check went through.  ...
>
> Thanks much!

a real pleasure, actually.  (see below)

> ...
> Aside: In the whither thread you gently tossed an arrow at the Simple
> DirectMedia Layer use. ...
> My understanding is that SDL1.2 was chosen for v3.7 because of problems
> with x11 at the time - which perhaps are not all that different from
> what we still see with x11 today.

that, I think needs .. re-stating.  :-)

I'm not a betting person, but would put good money on: if you were to create a
VM and installed either Slackware (of course!  :-)) or some BSD-derived Linux,
or Solaris, you'd find no "problems with x11"[*].  I think that rather than from
the X Windows system, problems will occur when using a Ubuntu.  (Mark
Shuttleworth tried too hard to become the "cock on the midden"  :-))  (although,
having said that, who knows, perhaps it goes back to Debian)

[*] that's not to say that the API isn't .. cumbersome, or perfect.  O'Reilly
published a really good set of references to X11R5 and X11R6.

> In my povr/POV-Ray use all three display options still have issues with
> x11 being the worst behaving. The x11 and SDL1.2 options suffer from
> occasional hangs requiring a kill command to stop with x11 being worse.
> Not seen the hangs in SDL2.0, but there is once in a while a had row of
> pixels usually in the upper left on scaling to fit a window. I recommend
> SDL2.0 use today if you have a choice.

well now, "povr -y x11 ..." works beautifully here.  :-)  the only difference I
see is that the x11 gives me window that starts with a transparent background,
while the (default) SDL2 window is black when empty.

and _I_ really like that the X functionality is making a comeback.

first impressions, have only run a handful of scenes for quick trying out that
it "just works".  fully installed ~4.2M -- nice!  it feels quite .. sprightly,
the difference to the 10064268.alpha seems to be ~5% faster parse and ~10%
faster render.

I'll play some more in the week, then post a list of .. issues.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ...
> I'll play some more in the week, then post a list of .. issues.

turns out that, so far, there are only two things on that list.  :-)

one is that 'povr' displays "povray: I/O restrictions are disabled".  confused.
the 'povray.conf' file contains (edited):

[File I/O Security]
;none       ; all read and write operations on files are allowed.
;read-only  ; uses the "read+write" directories for writing (see below).
restricted  ; uses _only_ "read" and "read+write" directories for file I/O.

; [Shellout Security] determines whether POV-Ray will be allowed to call
; scripts (e.g. Post_Frame_Command) as specified in the documentation.
; Specify one of the 2 following values:
; - "allowed" means that shellout will work as specified in the documentation.
; - "forbidden" means that shellout will be disabled.
[Shellout Security]
;allowed
forbidden


have not yet tested whether it's just the displayed info.

the second problem is a "third party" scene which fails:

==== [Parsing...] ==========================================================
FILE FOUND - Including ../...../L_01_04.inc
File '/home/jr/POVr/share/povray-3.8/include/transforms.inc' line 92:
Parse Error:
Cannot pass uninitialized identifier to non-optional LValue.
Fatal error in parser: Cannot parse input.
Render failed

that scene works fine with 10064268.alpha.

have not, so far, found the time to re-read the various newsgroup posts wrt
'povr' specific features and changes[*], so will probably use it just as an
alternative to the 10064268.alpha.

[*] maybe you can put all those together, in some text file.


regards, jr.

Post a reply to this message

On 7/10/20 11:12 AM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> ...
>> I'll play some more in the week, then post a list of .. issues.
> 
> turns out that, so far, there are only two things on that list.  :-)
> 
> one is that 'povr' displays "povray: I/O restrictions are disabled".  confused.
> the 'povray.conf' file contains (edited):
> 
...
> 
> the second problem is a "third party" scene which fails:
> 
> ==== [Parsing...] ==========================================================
> FILE FOUND - Including ../...../L_01_04.inc
> File '/home/jr/POVr/share/povray-3.8/include/transforms.inc' line 92:
> Parse Error:
> Cannot pass uninitialized identifier to non-optional LValue.
> Fatal error in parser: Cannot parse input.
> Render failed
> 
> that scene works fine with 10064268.alpha.
> 
> have not, so far, found the time to re-read the various newsgroup posts wrt
> 'povr' specific features and changes[*], so will probably use it just as an
> alternative to the 10064268.alpha.
> 
> [*] maybe you can put all those together, in some text file.
> 

Thanks! The first and likely the second issue(2) are the same problem.

There were updates to the code so that "make check" less often fails or 
is fooled by a previous install on the system doing the compile. Say an 
existing 'system level' functions.inc, a user setting of POVINI or 
whatever. Those changes required the introduction of a new internal only 
environment variable which when set (I think) turns off all the normal, 
nearly fanatical internal attempts to find existing .conf, .ini and .inc 
files(1) with which to run.

I screwed up the setting of the variable in the Makfile - and then 
covered up that mistake with another in the code hiding the fact I'd 
broken the normal setting of paths given I usually run with an uncommon 
POVINI setting. I believe the issue now fixed in my code.

(1) - Related. I am taking a run at no longer installing .conf and ini 
defaults in a user's HOME directory. Doing this makes it hard to run 
several POV-Ray versions side by side - though I have hacks to do it.

(2) - It might also be this second case is some actual incompatibility. 
I've made changes so more often the code will kick out the actual 
offending identifiers to make things easier to debug. On removal of old 
keywords, for example the errors should complain about the specific 
keyword. It's obviously still not reporting the identifier in your case.

Aside: Some of the bad command line flag / ini setting errors are now 
being reported too where they've long not been on unix platforms. Jerome 
added a workaround years back to kick out the command line text on 
errors, but that's less helpful than getting the more specific error text.

(*) - It's a hack at the moment, but I do have a povrTextDocumentation 
directory in the root compilation directoy which includes primarily 
areas of povr different than POV-Ray. If something exists there, it 
behaves differently in some way from the official POV-Ray. The 
exceptions to this rule in the inbuilt function changes are all 
documented in functions.inc and the density file stuff is on the wiki.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/10/20 11:12 AM, jr wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> >> ...
> >> I'll play some more in the week, then post a list of .. issues.
> > ...
> Thanks! The first and likely the second issue(2) are the same problem.
> ...
> I believe the issue now fixed in my code.

looking forward to your posting an updated version.

> (1) - Related. I am taking a run at no longer installing .conf and ini
> defaults in a user's HOME directory. Doing this makes it hard to run
> several POV-Ray versions side by side - though I have hacks to do it.

agree that a user 'povray.conf' is not needed/useful.

feel different about the 'povray.ini', find it convenient to have a set of
defaults, for that login, which I can override on a case-by-case basis.  (could
you not install a 'povr.ini' in '~/.povray/3.8/'?  would get round the naming
issue)

> (2) - It might also be this second case is some actual incompatibility.
> I've made changes so more often the code will kick out the actual
> offending identifiers to make things easier to debug. On removal of old
> keywords, for example the errors should complain about the specific
> keyword. It's obviously still not reporting the identifier in your case.

I'll be happy to try that scene again, after installing the update.

> ...
> (*) - It's a hack at the moment, but I do have a povrTextDocumentation
> directory in the root compilation directoy which includes primarily
> areas of povr different than POV-Ray. If something exists there, it
> behaves differently in some way from the official POV-Ray. The
> exceptions to this rule in the inbuilt function changes are all
> documented in functions.inc and the density file stuff is on the wiki.

ok.  I had hoped for something included in the tarball.

and another "rant" :-), this time regarding the install locations.

what is wrong with '/usr/local/doc/'?  what is the rationale for
'/usr/local/share/doc/' and '/usr/local/share/man/'?  it cannot be the "shared"
aspect, because then, logically, other shared directories would belong there
too, eg '/usr/local/share/bin/'!  plain weird.  (and yes, I know it's an Ubuntu
thing, not your decision, per se)


regards, jr.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> In my povr/POV-Ray use all three display options still have issues with
> x11 being the worst behaving. The x11 and SDL1.2 options suffer from
> occasional hangs requiring a kill command to stop with x11 being worse.

have still not seen any "hangs", but managed to get an error; when beginning
render of 2nd frame in animation.

povr +L/usr/local/share/povray-3.8/include +a0.1 +w960 +h720 \
        +o/tmp/render/frm_ +iTorusKnotMinimal35.pov +kc +kfi0 +kff359

....
X error: BadLength (poly request too large or internal Xlib length error)
.... [message repeats another eight times]
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been
called
[xcb] Aborting, sorry about that.
povray2: xcb_io.c:259: poll_for_event: Assertion
`!xcb_xlib_threads_sequence_lost' failed.
/home/jr/bin/povr: line 14: 845235 Aborted    ${INSTALLDIR}/bin/povray2 -y x11
$@


regards, jr.

Post a reply to this message

On 7/11/20 5:31 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> In my povr/POV-Ray use all three display options still have issues with
>> x11 being the worst behaving. The x11 and SDL1.2 options suffer from
>> occasional hangs requiring a kill command to stop with x11 being worse.
> 
> have still not seen any "hangs", but managed to get an error; when beginning
> render of 2nd frame in animation.
> 
> povr +L/usr/local/share/povray-3.8/include +a0.1 +w960 +h720 \
>          +o/tmp/render/frm_ +iTorusKnotMinimal35.pov +kc +kfi0 +kff359
> 
> ....
> X error: BadLength (poly request too large or internal Xlib length error)
> .... [message repeats another eight times]
> [xcb] Unknown sequence number while processing queue
> [xcb] Most likely this is a multi-threaded client and XInitThreads has not been
> called
> [xcb] Aborting, sorry about that.
> povray2: xcb_io.c:259: poll_for_event: Assertion
> `!xcb_xlib_threads_sequence_lost' failed.
> /home/jr/bin/povr: line 14: 845235 Aborted    ${INSTALLDIR}/bin/povray2 -y x11
> $@
> 
> 
> regards, jr.
> 

Thanks. I've not done any animations with the x11 display. I'll try it 
myself later today. I'd make a moderate bet from your output it's again 
the architectural problem of x11/sdl* not being at the top thread-wise, 
so to speak.

Bill P.

Post a reply to this message