[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mapper functions for 3.1
From: |
David Bateman |
Subject: |
Re: mapper functions for 3.1 |
Date: |
Sat, 16 Feb 2008 02:07:51 +0100 |
User-agent: |
Thunderbird 2.0.0.6 (X11/20070914) |
John W. Eaton wrote:
> On 14-Feb-2008, David Bateman wrote:
>
> | In fact it seems to me that it wouldn't be hard to add a c++ exception
> | in this case, or in fact in the general liboctave case. For the mapper
> | functions only the F77_XFCN can cause an error, and if we add an
> | exception in this case, then with the corresponding catch in
> | pt-stmt.cc(tree_statement_list::eval) this would be fairly trivial. In
> | fact we could modify the lo-error.cc (set_liboctave_error_handler)
> | function so that it wrapped the function that was passed in another
> | function that also threw an exception. Is it really that simple? Am I
> | missing something?
> |
> | In any case the proposed change will be likely to slow the mapper
> | function down as the check on error_state now needs to call an
> | additional function, whereas the exception idea will speed if up as we
> | will not have to check the error_state for each element in the loop.
>
> That could be avoided by just allowing direct access to the variable.
>
> But anyway, throwing an exception is probably best, and as you say, if
> we just set liboctave_error_handler to a function that prints the
> message and throws an exception instead of setting it to the error
> function defined in /src/error.cc, then I think that will do most of
> what we need with minimal impact. We'll need to catch the exception
> and then call Octave's error function again (so that error_state is
> set properly). We'll also need to do whatever is necessary to handle
> exceptions that are thrown in callback functions that are executed by
> non-C++ code (for example, the user-defined functions used by fsolve,
> quad, lsode, daspk, etc.). I'm not sure, but I think that means
> catching them in the callback and setting a global variable indicating
> an exception has occurred, calling longjmp, then rethrowing the
> exception. This is similar to what is supposed to happen for
> allocation exceptions in callbacks, so I think it can be handled the
> same, and will only require changing the macros in f77-fcn.h and
> quit.h in the libcruft/misc directory, possibly with the addition of a
> helper function or two. Would you like for me to work on this part?
>
> jwe
>
>
Here is an update to the mapper patch implementing your idea..
D.
patch7539.bz2
Description: BZip2 compressed data
- Re: mapper functions for 3.1, (continued)
- Re: mapper functions for 3.1, David Bateman, 2008/02/11
- Re: mapper functions for 3.1, David Bateman, 2008/02/11
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/11
- Re: mapper functions for 3.1, David Bateman, 2008/02/13
- Re: mapper functions for 3.1, David Bateman, 2008/02/13
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/13
- Re: mapper functions for 3.1, David Bateman, 2008/02/14
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/14
- Using C++ exceptions in liboctave (was: Re: mapper functions for 3.1), John W. Eaton, 2008/02/14
- Using C++ exceptions in liboctave (was: Re: mapper functions for 3.1), John W. Eaton, 2008/02/14
- Re: mapper functions for 3.1,
David Bateman <=
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/16
- Re: mapper functions for 3.1, David Bateman, 2008/02/16
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/16
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/16
- Re: mapper functions for 3.1, David Bateman, 2008/02/17
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/18
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/20