help-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] [PATCH] determine whether we are handling an error


From: Heinrich Schuchardt
Subject: Re: [Help-glpk] [PATCH] determine whether we are handling an error
Date: Fri, 6 Nov 2015 12:47:50 +0100

Hello Andrew,

will you be sending error messages to stderr in the next release?

Best regards

Heinrich Schuchardt

http://www.xypron.de

Am 06.11.15 um 12:38 schrieb Andrew Makhorin

> On Thu, 2015-11-05 at 22:57 +0100, Jeroen Demeyer wrote:
> 
> > On 2015-11-05 22:20, Heinrich Schuchardt wrote:
> 
> > > Hello Jeroen,
> 
> > >
> 
> > > could you, please, describe the use case for the patch.
> 
> > 
> 
> > My use case is really for using GLPK through SageMath, which is a 
> 
> > mathematical program with an interactive Python interface. I want to 
> 
> > convert GLPK errors to Python exceptions. For this I install an error 
> 
> > hook and a term hook. But I need to distinguish between normal messages 
> 
> > and error messages.
> 
> 
> 
> Thank you for your suggestion and the patch provided.
> 
> 
> 
> I will add the following API routine:
> 
> 
> 
> ------------------------------------------------------------------------
> 
> NAME
> 
> 
> 
> glp_at_error - check for error state
> 
> 
> 
> SYNOPSIS
> 
> 
> 
> int glp_at_error(void);
> 
> 
> 
> DESCRIPTION
> 
> 
> 
> The routine glp_at_error checks if the GLPK environment is at error 
> 
> state, i.e. if the call to this routine is (indirectly) made from the
> 
> glp_error routine via an user-defined hook routine.
> 
> 
> 
> RETURNS
> 
> 
> 
> If the GLPK environment is at error state, the routine glp_at_error
> 
> returns non-zero, otherwise zero.
> 
> ------------------------------------------------------------------------
> 
> 
> 
> > 
> 
> > > Currently both normal messages and error messages are sent to stdout,
> 
> > > which does not match usual usage of output streams.
> 
> > >
> 
> > > I propose to store the information if an error message is written in
> 
> > > env->term_out and to use a new value GLP_ERROR = 2 to indicate an error
> 
> > > message.
> 
> > >
> 
> > > This value then should be used in glp_puts to decide if a message shall
> 
> > > be sent to stdout or stderr.
> 
> > >
> 
> > > An API function could be provided to read env->term_out. The return
> 
> > > value could be used in the terminal hook function.
> 
> > 
> 
> > Sure, I don't really care so much *how* this feature is added. I 
> 
> > implemented it the way I did mainly because it was the simplest solution.
> 
> > 
> 
> > 
> 
> > Jeroen.
> 
> > 
> 
> > _______________________________________________
> 
> > Help-glpk mailing list
> 
> > address@hidden
> 
> > https://lists.gnu.org/mailman/listinfo/help-glpk
> 
> > 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 
> Help-glpk mailing list
> 
> address@hidden
> 
> https://lists.gnu.org/mailman/listinfo/help-glpk



reply via email to

[Prev in Thread] Current Thread [Next in Thread]