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

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/11/20 5:31 AM, jr wrote:
> > have still not seen any "hangs", but managed to get an error; ...
>
> Thanks.

(I think I might have heard you <sigh>.  :-))

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

thanks.  wish I knew/understood more about the code, 'disp_x11.*' etc.  naively,
after the initialisation, just bracketing the worker thread's call to update the
window (a buffer-to-buffer move, I assume?) with calls to 'XLockDisplay' +
companion should do, no?


regards, jr.

Post a reply to this message

On 7/11/20 11:04 AM, jr wrote:
...
>> 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.
> 
> thanks.  wish I knew/understood more about the code, 'disp_x11.*' etc.  naively,
> after the initialisation, just bracketing the worker thread's call to update the
> window (a buffer-to-buffer move, I assume?) with calls to 'XLockDisplay' +
> companion should do, no?
> 

:-) I suspect you know more than me. I'm no expert with X11, having only 
surfaced hacked now and again on code using X11. At a high level, if we 
have all the locking / unlocking in place to prevent thread safety 
issues while asking x11 to do stuff and visa versa, things would work.
;-)

What I'm testing is what the nice, verbose error message from X 
suggested - XInitThreads. This seems to add lock / unlocks around all 
the x11 interactions. Thus far, it's working(1).

(1) - The other x11 issues routinely seen OK too - so far.

I was able to duplicate your animation / X11 fails easily - thanks 
(without the sigh this time :-)). Start up an animation and then create 
many interrupts by moving the window hitting keys and such and somewhere 
in the first 20 frames - almost always - boom! Having something which 
fails reliably is very useful. I wasn't able to get there with the prior 
SDL1.2 github issues.

I'll run with the x11 display for a few days and we'll see if the 
XInitThreads() fix holds up.

In reading about it, it looks like it's not the efficient approach and 
likely there is additional exposure to hangs where an interrupt 
generating a lock happens elsewhere during a lock introduced by using 
XInitThreads(). The latter particular locks perhaps not strictly necessary.

The underlying issue tangled here, given our current code architecture, 
is the interrupt handing happening in ways that cause a deadlock of 
locks and hence occasional hangs. For users not generating large numbers 
of interface interrupts, I believe such hangs are rare.

Aside: An idea on my 'maybe someday' wish list is POV-Ray run-able in a 
continuous loop(2) while accepting scene updating input. Re-reading and 
rendering a scene file as edits/updates are made. I think it possible to 
do limited modeling (spline editing say) without jumping up to Blender, 
Moray or whatever tool to do it.

(2) - Similar in behavior to animation today, but where modeling not 
animation is the aim. No image output, just continuous re-rendering of a 
changing scene to the display. Yes, ugly, partial hacks of this can be 
achieved today.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> What I'm testing is what the nice, verbose error message from X
> suggested - XInitThreads. This seems to add lock / unlocks around all
> the x11 interactions. Thus far, it's working(1).
> (1) - The other x11 issues routinely seen OK too - so far.

that man page merits close reading.  it only speaks about 'Xlib', the "client
library", not (the underlying) X (server).  another pertinent man page, re the
event/interrupt issues snipped from below, is 'XIfEvent(3)'.  my understanding
(from somewhat dim, 20+ years old memory) is that whenever the window "object"
is accessed, you'll need some kind of mutex/XLockDisplay guard arrangement,
still.

another "rant" re "nice, verbose error message".  a few days ago, in an email,
needed to ask what the person (also an Ubuntu user, as it happens) got in reply
when executing "$ which badname", since "badname" did not seem to work.  answer:
"nothing (an empty line)".  the default behaviour for 'which' is to print (to
stderr) a message like "which: no badname in ($PATH)".  what I do not understand
is why the Ubuntu maintainers expend "man-hours"/time + effort on making s/ware
_less_ informative, and therefore less valuable, to the user.  (it sort of
boggles the mind, and that's before the "conspiracy" paranoia kicks in!  :-))

> ...
> Aside: An idea on my 'maybe someday' wish list is POV-Ray run-able in a
> continuous loop(2) while accepting scene updating input. Re-reading and
> rendering a scene file as edits/updates are made. I think it possible to
> do limited modeling (spline editing say) without jumping up to Blender,
> Moray or whatever tool to do it.

a "hacked" Tclsh?!  ;-)  like the idea though, to be able to interactively build
up scenes would be way cool.


regards, jr.

Post a reply to this message