My thoughts are that this is a constructive solution to the
problem. Can you put together some suggested code changes that I can
put into SVN?
I am still concerned about the ghost of Edsger Dijkstra, but I will
not allow that to stand in the way of doing the right thing.
On 10/27/2010 9:33 PM, Chris Marshall wrote:
> I took another look at the issues around
> the setjmp/longjmp and user defined error
> handler for non-fatal error handling for
> First, I reviewed all the places where
> fgError was called in the FreeGLUT 2.6
> sources, here are the number of occurances
> by the keyword searched (each corresponds
> to a call of fgError):
> 134 FREEGLUT_EXIT_IF_NOT_INITIALISED
> 3 FREEGLUT_INTERNAL_ERROR_EXIT_IF_NOT_INITIALISED
> 18 FREEGLUT_EXIT_IF_NO_WINDOW
> 13 FREEGLUT_INTERNAL_ERROR_EXIT
> 28 fgError
> The result of this analysis was that the
> vast majority of the fgError (i.e. exit-based
> error handling) usage was for user code
> problems that are fatal in FreeGLUT:
> forgetting to call glutInit() or calling
> glutInit() more than once. The rest were
> more of the internal error type of a resource
> that was needed and not available.
> All were reasonable candidates for a user
> defined error handler: in the case of a
> perl language binding, a call to the perlapi
> croak() routine to allow the user program
> within the perl interpreter to detect and
> handle the error condition as required.
> After that analysis, I realized that the
> simplest implementation protecting the
> existing GLUT API standard would be the
> addition of two new init functions:
> and the addition of the corresponding
> defaults in the fgState structure. With
> the addition of these two routines and the
> modification of fgError() and fgWarning()
> to call the user defined handler if set,
> we have a clear, simple method to extend
> the FreeGLUT error handling to support
> more embedded applications such as the
> perl language binding.
> The fact that the two functions are in
> the glutInit* family of routines even
> allows for the fact that they need be
> called *before* glutInit() itself.
> On 7/11/2010 10:55 AM, Chris Marshall wrote:
>> I updated the Feature Request with this idea:
>>> I though of a better/cleaner way to handle this issue
>>> without breaking the GLUT API. I realized that this
>>> change in error handling would need to be handled
>>> *before* the glutInit() call in order to work for
>>> glutInit too.
>>> The idea is to add a command line flag to change
>>> the behavior of glutInit on errors to not exit but
>>> instead return immediately with an error message in the
>>> argc/argv. If the glutInit completes successfully, a
>>> standard-ish glutSetOption could be used to control the
>>> error handling from that point on.
>>> A bit of a kludge for the first part but it doesn't
>>> break existing glutInit usage except for the possible
>>> change to the argc/argv values but this would only
>>> happen if the -softinit (or whatever the option is
>>> called) were passed to the glutInit call.
>> The main user visible difference to FreeGLUT would
>> be that glutInit would handle failure differently
>> if it was passed the -softinit argument. In that
>> case it would return with the error returned as an
>> amendment to the argv value.
>> That would allow for non-fatal embedding of glutInit
>> in other applications. Once glutInit has succeeded,
>> the remainder of the fix would be adding the ability
>> to set an alternate fgError mode (maybe a routine to
>> call before the exit).
>> I think this approach "answers the mail" and keeps
>> any grave turning over to a minimum.... :-)
>> P.S. Is there a way to search archives of the list?
>> I have not found any easy way to review back discussions.
>> On 7/9/2010 10:22 AM, Fay, John F Dr CTR USAF AFMC AAC/XRS wrote:
>>> There was a discussion of "setjmp" and "longjmp" but it wasn't resolved.
>>> I thought I heard Edsger Dijkstra turning over in his grave and I don't
>>> know that we wanted to disturb his ghost further. Has that changed?
>>> - John
>>> -----Original Message-----
>>> From: Chris Marshall [mailto:chm@...]
>>> Sent: Thursday, July 08, 2010 5:33 PM
>>> To: FreeGLUT developers list
>>> Subject: [Freeglut-developer] add fgError() exit callback/routine
>>> This is regarding to an entry on the Feature Request
>>> tracker at sf.net:
>>> 2116152 add fgError() exit callback/routine
>>> I just got bit by this one again. The problem is
>>> that fgError always exit(1) from FreeGLUT kills the
>>> perl interpreter in the binding.
>>> The thought was to have some way to add a user
>>> specified exit routine to be called instead for
>>> fgError. For our perl bindings, that could be
>>> die which can be caught and processed for an
>>> exception handler.
>>> In the meantime, I'm working around the problem by
>>> duplicating the glutInit code so that I can catch
>>> the exceptions myself before passing control to
>>> the glutInit() routine. That way the inputs should
>>> be good and glutInit won't kill perl if something
>>> goes wrong.
>>> This would be a problem for most any embedded
>>> freeglut mode of operation. I can submit a code
>>> proposal....or am I missing some obvious way to
>>> fix this problem in a portable way?
>>> Thanks in advance,
>>> Chris Marshall
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> Freeglut-developer mailing list
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 9.0.830 / Virus Database: 271.1.1/2996 - Release Date: 07/11/10 02:36:00
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps& games for the Nokia N8 for consumers in U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> Freeglut-developer mailing list