Wolfgang Wieser wrote:
> Thorsten Froehlich wrote:
> 
> 
>>In article <411a62cc@news.povray.org> , Wolfgang Wieser
>><wwi### [at] nospamgmxde>  wrote:
>>
>>
>>>POVRay for UNIX does not exit with a non-zero exit status when an Error(..)
>>>occurs (such as during parsing).
>>
>>One could also just call exit ... on the other hand, a clean way would
>>certainly be to assign the error code to a variable an return that.  Your
>>code certainly is not a clean solution.
>>
> 
> Well... UNIX povray actually will never exit() but instead go though some 
> longjmp into the cooperate funcion which will then return to main or throw 
> some exception. It took me some time until I finally figured out what was 
> actually going on here and I was really wondering if the present state 
> can be called a "clean solution"...
> 
> But I'm sure, Nicolas will come up with something better. :)
> 
> Wolfgang
> 
can i assume this might have a bearing on problems found using 
emacs/xemacs pov-mode 2.10 and pov-ray 3.6

previously reported/posted and pooh-poohed(sp?) as a possible problem
istr a suggestion of contacting pov-mode author as well

oh well time for ROFL

stephen

Post a reply to this message

> But I'm sure, Nicolas will come up with something better. :)

	Honestly, I'm not sure of that, since I have myself a hard
time with those cooperate stuffs and I'm still surprised it somehow
works currently  ;-)  {well it works because Thorsten wrote the
main() and cooperate-related functions, not me}

	BTW I saw some time ago on your pages that you already had
problems with the exit code, but I simply didn't get an idea of how
to cleanly solve that.  And I don't like much the way you do it,
though I'm unable to propose anything better at the moment...

	Another BTW, there's a little glitch on the povray.org
download page, since the current UNIX version is 3.6.1 and the
corresponding sources are there:

ftp://ftp.povray.org/pub/povray/Official/Unix/povray-3.6.1.tar.gz
ftp://ftp.povray.org/pub/povray/Official/Unix/povray-3.6.1.tar.bz2

	I can also provide with diffs from 3.6 to 3.6.1, on a per
request basis.

	- NC

Post a reply to this message

In article <411a84ff@news.povray.org> , Wolfgang Wieser 
<wwi### [at] nospamgmxde>  wrote:

> Well... UNIX povray actually will never exit() but instead go though some
> longjmp into the cooperate funcion which will then return to main or throw
> some exception. It took me some time until I finally figured out what was
> actually going on here and I was really wondering if the present state
> can be called a "clean solution"...

Well, it certainly is given how the code is separated into a frontend and
backend.  It also certainly is not trivial to understand.  In short the
frontend is pure C++ while the backend has to suit C.  If you would check,
you would find that povray_exit is only called with three different
parameters (0, 1, 2) in four places.  Two signals a user about, one an
error.  So all you need to do if you desire a return value for a
command-line version (for a GUI version it does not matter) returned via
main, you either exit directly (the default macro implementation), or, if
you desire to perform proper cleanup (and displaying all other messages) you
simply return -n via the longjmp and return that.  No adding of some magic
values.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Nicolas Calimet wrote:

>> But I'm sure, Nicolas will come up with something better. :)
> 
> Honestly, I'm not sure of that, since I have myself a hard
> time with those cooperate stuffs and I'm still surprised it somehow
> works currently  ;-)  {well it works because Thorsten wrote the
> main() and cooperate-related functions, not me}
> 
After thinking about it: What about completely sending all that 
longjmp stuff to hell (grin...) and simply use: 

-----------------------------------------------------------------------------
struct ExitPovrayException
{
    int code;
    ExitPovrayException(int _c) : code(_c) {}
};

/*
 * POVMS stuff.
 */
#define POVRAY_BEGIN_COOPERATE  try {
#define POVRAY_END_COOPERATE    } catch(ExitPovrayException ex) \
                                  {  throw(ex.code);  }
#define EXIT_POVRAY(n)          throw ExitPovrayException(n);
-----------------------------------------------------------------------------

Maybe one could even get along without the ExitPovrayException and use 
the "throw (int)" construct directly: 

-----------------------------------------------------------------------------
/*
 * POVMS stuff.
 */
#define POVRAY_BEGIN_COOPERATE  /*empty*/
#define POVRAY_END_COOPERATE    /*empty*/
#define EXIT_POVRAY(n)          throw int(n);
-----------------------------------------------------------------------------

I don't have a full overview over the use of exceptions in POVRay, so 
I was trying to be careful with the first variant here. In this case one 
should probably add a further catch(ExitPovrayException ex) in main(). 
However, the second variant at least works for my simple tests. 

> BTW I saw some time ago on your pages that you already had
> problems with the exit code, but I simply didn't get an idea of how
> to cleanly solve that.  And I don't like much the way you do it,
> though I'm unable to propose anything better at the moment...
> 
I don't know exactly what you're referring to but the POVRay exit code 
issue for versions 3.1g an 3.5.. already cost me some sleepness nights 
while trying to make RendView know what to do with the output file 
(was it failure or complete? can we resume the render? etc.)...

> Another BTW, there's a little glitch on the povray.org
> download page, since the current UNIX version is 3.6.1 and the
> corresponding sources are there:
> 
Yes, actually, I noticed and upgraded just some minutes after having 
sent the initial posting. All the patches on my website are already 
against 3.6.1 :)

> ftp://ftp.povray.org/pub/povray/Official/Unix/povray-3.6.1.tar.gz
> ftp://ftp.povray.org/pub/povray/Official/Unix/povray-3.6.1.tar.bz2
> 
> I can also provide with diffs from 3.6 to 3.6.1, on a per
> request basis.
> 
Thanks for the offer. I made the diff myself using my university account. 
This reduced the download size for my slow home connection to about 12% 
of the initial size. 

Wolfgang

Post a reply to this message

In article <411a894e$1@news.povray.org> , Nicolas Calimet 
<pov### [at] freefr>  wrote:

>  Honestly, I'm not sure of that, since I have myself a hard
> time with those cooperate stuffs and I'm still surprised it somehow
> works currently  ;-)  {well it works because Thorsten wrote the
> main() and cooperate-related functions, not me}

Well, it all would be a lot easier to understand if one could think of it as
happening in two communicating threads rather than one.  Of course, this
cannot be changed for the 3.x Unix versions of POV-Ray :-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> Well, it certainly is given how the code is separated into a frontend and
> backend.  It also certainly is not trivial to understand.  In short the
> frontend is pure C++ while the backend has to suit C.  If you would check,
> you would find that povray_exit is only called with three different
> parameters (0, 1, 2) in four places.  Two signals a user about, one an
> error.  
>
I see. At least that's a clear and resonable decision. 

> So all you need to do if you desire a return value for a 
> command-line version (for a GUI version it does not matter) returned via
> main, you either exit directly (the default macro implementation), or, if
> you desire to perform proper cleanup (and displaying all other messages) you
> simply return -n via the longjmp and return that.  No adding of some magic
> values.
> 
Well, at least the "magic number 1" needs to be added since longjmp cannot 
be used to return the value 0. This is because 0 is used as setjmp return 
value to indicate direct return (i.e. not due to a call to longjmp).

-------<manual>-------
longjmp() cannot cause 0 to be returned.  If longjmp is invoked with a 
second argument of 0, 1 will be returned instead. 
-----------------------

Wolfgang

Post a reply to this message

In article <411a97ec@news.povray.org> , Wolfgang Wieser 
<wwi### [at] nospamgmxde>  wrote:

> Well, at least the "magic number 1" needs to be added since longjmp cannot
> be used to return the value 0. This is because 0 is used as setjmp return
> value to indicate direct return (i.e. not due to a call to longjmp).

No, you need an if/else and return something positive in this case (i.e.
"1").  While not documented, you are practically promised the exit function
is only called with zero or positive values.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <411a968f@news.povray.org> , Wolfgang Wieser 
<wwi### [at] nospamgmxde>  wrote:

> After thinking about it: What about completely sending all that
> longjmp stuff to hell (grin...) and simply use:

Not a good idea.  While it may work, the problem is the side effect of an
exception - it calls all the appropriate destructors.  However, as POV-Ray
cleans up itself, this is not exactly desired...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> In article <411a968f@news.povray.org> , Wolfgang Wieser
> <wwi### [at] nospamgmxde>  wrote:
> 
>> After thinking about it: What about completely sending all that
>> longjmp stuff to hell (grin...) and simply use:
> 
> Not a good idea.  While it may work, the problem is the side effect of an
> exception - it calls all the appropriate destructors.  However, as POV-Ray
> cleans up itself, this is not exactly desired...
> 
Hmm... I don't completely understand that. 
(1) the objects destroyed by the exception are all allocated on the stack. 
   How could that harm?
(2) There are quite a lot of "throw (int)" in the code and I don't see the 
   difference (without having had a look at the scattered catch constructs). 

Wolfgang

Post a reply to this message

In article <411a9cf3@news.povray.org> , Wolfgang Wieser 
<wwi### [at] nospamgmxde>  wrote:

>> Not a good idea.  While it may work, the problem is the side effect of an
>> exception - it calls all the appropriate destructors.  However, as POV-Ray
>> cleans up itself, this is not exactly desired...
>>
> Hmm... I don't completely understand that.
> (1) the objects destroyed by the exception are all allocated on the stack.
>    How could that harm?

Because those objects might be used elsewhere in unexpected ways that might
not even be completely legal.  Note that I do not say this is the case, just
that it is a can of worms that should be left closed.

> (2) There are quite a lot of "throw (int)" in the code and I don't see the
>    difference (without having had a look at the scattered catch constructs).

You are confusing the frontend code with the core code.  I would recommend
to look at one of the two threaded implementations of frontend and core - in
the Windows or Mac OS sources.  The separation of work is better to
understand there (I would recommend the Mac implementation because it was
entirely written for this while the Windows version is modified 3.5 code).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message