octave-dev — GNU Octave developers' list

[OctDev] bode plots

[torsten <to...@in...>]

http://octave.sourceforge.net/index/index.html


Not Found
The requested URL /index/f/bode.html was not found on this server.

Apache/1.3.26 Server at octave.sourceforge.net Port 80

[OctDev] help debugging mex file compat. problem

[Chris C. <ch...@ch...>]

I would appreciate some help from the more experienced octave/octave-forg=
e=20
developers determining where to look for a problem that is plaguing my=20
attempts to port a package from Matlab to Octave.

I have a package of functions developed by someone else a few years ago,=20
probably Matlab 5.X time frame, consisting of about two dozen m files, pl=
us=20
half a dozen C files each implementing a separate function.

The symptom of the problem is a segmentation fault at some point after th=
e C=20
function returns.
The C file I am concentrating on right now declares a static mxArray=20
*outputMatrix =3D0 and *stateMatrix=3D0 at the beginning of the file, the=
n=20
later assigns outputMatrix=3DmxCreateDoubleMatrix (similarly for=20
stateMatrix).
The end of the function assigns plhs[0] =3D outputMatrix and=20
plhs[1]=3DstateMatrix.
I put printf statements in the C file to make sure it made it all the way=
=20
past the assignment, and it does, so it is somewhere after the function=20
assigns the matrix of output data to plhs and ends that the segmentation=20
fault is triggered.  I am fairly new to octave, so I don't know yet how t=
o=20
debug into octave itself.  Is there a way I can recompile octave with=20
debugging enabled and use gdb to set break points at the entry and exit=20
from my C file to see if a pointer is hosed somewhere?

This is on a Red Hat 8.0 machine, so gcc 3.2, octave built from=20
octave-2.1.36-9.src.rpm, octave-forge built from=20
octave-forge-2002.11.30.tar.gz.
Any known compatibility problems with those version?  I didn't see anythi=
ng=20
in the mailing list archives that looks like it would apply to this=20
problem.

I have considered porting the C files completely to octave, but that isn'=
t=20
my top choice yet, because I don't have any mex programming background, s=
o=20
I'm afraid I would have to learn mex and oct programming interfaces at th=
e=20
same time, and really all I want to do is get this function useable as=20
quickly as possible.

Any help appreciated.
thanks,
--=20
Chris Caudle

[OctDev] ellipke with negative arguments

[Jaakko R <jaa...@we...>]

Hi,

Many years ago, after calculating the magnetic field produced by a 
circular loop, I was wondering why Matlab doesn't support complete 
elliptic integrals with negative arguments.

I would suggest to improve octave-forge's version.  Could someone step 
in and drop a patch for a vectorized version, or should I give it a try?

It should be something like this for a scalar version 
if m<0,
   [k, e] = ellipke(-m./(1-m))
   k = 1/sqrt(1-m)*k;
   e = sqrt(1-m)*e;
end

The following equations can be seen to be correct by the substitution 
theta=pi/2-theta'.  Comments?

Cheerio,
-Jaakko


Complete elliptic integral of first kind
\begin{equation}
   \label{eq:ellkint}
   K(m) = \int_0^{\pi/2} [1-m\sin^2(\theta)]^{-1/2}\,d\theta.
\end{equation}

\begin{equation}
   \label{eq:ellk}
   K(-m) = \frac{1}{\sqrt{1+m}}\,K\left(\frac{m}{1+m}\right)
\end{equation}

Complete elliptic integral of second kind
\begin{equation}
   \label{eq:elleint}
   E(m) = \int_0^{\pi/2} [1-m\sin^2(\theta)]^{1/2}\,d\theta.
\end{equation}

\begin{equation}
   \label{eq:elle}
   E(-m) = \sqrt{1+m}\,E\left(\frac{m}{1+m}\right)
\end{equation}

[OctDev] overloaded functions

[Paul K. <pki...@us...>]

I've added dispatch.cc to octave-forge/main/miscellaneous.  
This adds the ability to overload functions in octave.

E.g.,

    mark_as_command dispatch
    dispatch sin string g
    function g,'g',end
    sin('x')
    # ==> g
    sin(3)
    # ==> 0.14112
    dispatch min string g
    min([1 2 3])
    # ==> 1
    min('x')
    # ==> g
    dispatch reshape string g
    reshape(1:6,2,3)
    # ==> [1 3 5; 2 4 6 ]
    reshape('x',2,3)
    # ==> g
    help sin
    # ==>
sin is a builtin function
 - Mapping Function:  sin (X)
     Compute the sin of each element of X.
   Overloaded function string:g

If you are using octave 2.1.40 compile it with mkoctfile -DOCTAVE2140
dispatch.cc, otherwise use octave 2.1.43.

Now we need PKG_ADD to contain the appropriate dispatch functions
for octave forge, such as "dispatch find sparse spfind".

Paul Kienzle
pki...@us...

Re: [OctDev] octave-forge: inline problem

[John W. E. <jw...@be...>]

On 11-Jan-2003, Andy Adler <ad...@nc...> wrote:

| John W. Eaton wrote:
| 
| > But it looks like you might be
| >using --traditional?  Then it also fails for me.  Ah, the bug is the
| >difference in parsing spaces inside [ ].  One fix is:
| >
| >   argstr = ["x,",(sprintf ("P%i,",1:n))];
| >
| >Another is to remove the space between sprintf and ( in that
| >statement.
| >  
| >
| Yes. The problem is from --traditional.
| I've just checked in this change.

There is also another problem that Peter pointed out to me another
message, but it is really a bug with Octave.  If implict_str_to_num_ok
is nonzero, then isnumeric ('some string') will return true, because
it is possible to use 'some string' as a numeric value (with
conversion) at least in some contexts.  But I think it should not
really return true.  I'll fix that for 2.1.44.

jwe

Re: [OctDev] octave-forge: inline problem

[Andy A. <ad...@nc...>]

John W. Eaton wrote:

> But it looks like you might be
>using --traditional?  Then it also fails for me.  Ah, the bug is the
>difference in parsing spaces inside [ ].  One fix is:
>
>   argstr = ["x,",(sprintf ("P%i,",1:n))];
>
>Another is to remove the space between sprintf and ( in that
>statement.
>  
>
Yes. The problem is from --traditional.
I've just checked in this change.

andy

[OctDev] octave-forge: inline problem

[John W. E. <jw...@be...>]

On 11-Jan-2003, Peter Brinkmann <bri...@ma...> wrote:

| Hi!
| I just tried Octave 2.1.42 with octave-forge under Windows 2000, and I've
| got a problem with the function inline.m from octave-forge. Here's
| what happened:
| 
| >> f=inline('x.*x','x')
| parse error near line 32 of file /usr/share/octave/2.1.42/m/miscellaneous/inline.m
| 
| >>>     argstr = ["x,",sprintf ("P%i,",1:n)];
|                                        ^
| error: `inline' undefined near line 1 column 3
| 
| I'm using the Octave binaries from Andy Adler's website.
| Any help would be appreciated.

This seems to work fine with my current sources and the current
version of inline.m from the octave-forge CVS archive, at least when I
start Octave without any arguments.  But it looks like you might be
using --traditional?  Then it also fails for me.  Ah, the bug is the
difference in parsing spaces inside [ ].  One fix is:

   argstr = ["x,",(sprintf ("P%i,",1:n))];

Another is to remove the space between sprintf and ( in that
statement.

jwe

Re: [OctDev] .oct files and octave compilation

[Paul K. <pki...@ja...>]

Oops! I think the --enable-lite-kernel option is no longer valid. 

You needed --enable-lite-kernel before because oct-files could not override
built-in oct-files, but they can override DLD functions which are later on
the path.

The --enable-shared I believe is required for all since oct-files are
not linked against the executable and the executable is not compiled
in such a way that it exports symbols (but it could be).   --enable-shared
is supposed to be the default on all systems which support it, but I don't
know if that is indeed the case.

- Paul

On Tue, Dec 03, 2002 at 03:29:30PM +0000, Etienne Grossmann wrote:
> 
>   Hello,
> 
> the file FIXES/README says that :
> 
> ======================================================================
> The oct-files included herein cannot be loaded unless octave has been
> configured with --enable-shared --enable-lite-kernel. 
> ======================================================================
> 
> is that true only of .oct files in the FIXES dir, or of all?
> 
>   Cheers,
> 
>   Etienne
> 
> -- 
> Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

[OctDev] .oct files and octave compilation

[Etienne G. <et...@is...>]

  Hello,

the file FIXES/README says that :

======================================================================
The oct-files included herein cannot be loaded unless octave has been
configured with --enable-shared --enable-lite-kernel. 
======================================================================

is that true only of .oct files in the FIXES dir, or of all?

  Cheers,

  Etienne

-- 
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne

[OctDev] octave-forge 2002-11-30

[Paul K. <pki...@ja...>]

octave-forge 2002-11-30 release.

Now requires octave-2.1.40 to work correctly.  
Some functions may work with older versions of Octave.  
Use make -k to build whatever can be built ignoring the rest.

Latest release notes available at:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/octave/octave-forge/main/RELEASE-NOTES?rev=HEAD&content-type=text/plain

2002-11-30 for Octave 2.1.40 =================================================

New functions

        * general/ndims: compatibility function
        * image/imginfo: determines size of image using 'convert'
        * image/colfilt: image block filtering function
        * image/im{rotate,translate,shear}: image transformations
        * miscellaneous/inline: generate a function from an expression
        * miscellaneous/slurp_file: loads a file into a string
        * miscellaneous/{rotv,rotparams}: parameterize 3D rotation matrices
        * plot/contour.f: filled contours
        * sparse/{sprand,spdiags,issparse}: sparse functions
        * specfun/lambertw: Lambert's W function: x=w(x)*exp(w(x))
        * specfun/betaln: log beta
        * splines/pchip: Piecewise Cubic Hermitian Interpolating Polynomial
        * statistics/{boxplot,scatter}: statistical plots
        * symbolic/{cheb,chebwin}: Dolph-Chebyshev windows
        * vrml/vmesh: 3D visualization of a surface
        * vrml/*: represent and show 3D objects as VRML code (needs FreeWRL)

Extended interfaces

        * audio/au{load,save}: support floating point .wav formats
        * image/colorgradient: allow instantaneous transitions (weight 0)
        * optim/wpolyfit: option to fit through origin
        * signal/{ellip,ellipord}: compatible interfac
        * sparse/spy: accept dense matrices
        * strings/mat2string: accept [] and complex
        * symbolic/*: relational operators
        * time/datestr: more format codes; handle vectors of dates

Changed interfaces

        * image/bwlabel: C++ version---may be different from m-file interface
        * extra/ode: moved from v1.06 to v1.14
        * optim/*: unified interface supporting options
        * optim/wpolyfit: don't return yf
        * optim/wpolyfit: return row vectors for compatibility with polyfit
        * signal/nellip: replaced by ellip, ellipord
        * OCTAVE_FORGE_VERSION is now an ordered integer: yyyymmdd
	* FIXES/fsolve: removed because it hasn't been updated to 2.1.40

extra/tsa

        * significance test and confidence intervals for PACF
        * added histogram functions for multicolumn data
        * support for new releases of octave and matlab
        * bug fixes

extra/NaN

        * added TRIMEAN, NORMPDF, NORMCDF and NORMRND
        * extended NANTEST
        * significance test and confidence intervals for CORRCOEF
        * faster RANKS
        * support for new releases of octave and matlab

Internal changes

        * extra/symband: eigenvector bug removed
        * io/dlmread: returned matrix was transposed
        * general/rat: display 1/0 for infinity
        * plot/ginput: m-file version based on grab.cc
        * plot/legend: give gnuplot time to respond to parameter request
        * signal/{buttord,fir1}: bug fixes
        * sparse/spy: prettier graph
        * gcc 3.2 updates
        * octave 2.1.40 updates
        * remove functions and fixes that are now in octave

Administration

        * vrml/doc: LaTeX tutorial on 3D visualization tools 
        * Octave for Windows FAQ updates
        * INSTALL.WINDOWS installation notes
        * support for static build under Windows

Paul Kienzle
pki...@us...

Re: [OctDev] [PATCH] CVS-octave-forge and GCC3.2

[John W. E. <jw...@be...>]

On 27-Nov-2002, Paul Kienzle <pki...@ja...> wrote:

| I do find it ugly having to decide for each loop whether or not an octave
| quit is desired.  The alternative approach is garbage collection is it
| not?  Assuming sigsetjmp/siglongjmp work as advertised, then with a 
| garbage collection system you could eventually clean up after an interrupt.
| You would have to be careful to write your resource allocator code safely:
| 
| allocate_resource() {
| 	allocating = 1
| 	grab resource and register it
| 	allocating = 0
| 	if (interrupted) siglongjump
| }
| 
| interrupt_signal() {
| 	if (interrupted) return
| 	if (allocating) interrupted=1
| 	else siglongjmp
| }
| 
| eval_once() {
| 	if (sigsetjmp()) collect garbage
| 	else do next operation
| }
| 
| Then the bulk of your code, and your numeric code in particular,
| doesn't have to glance obsessively at the quit flag to see whether
| the user has become bored of waiting yet.  This should make your
| code faster and easier to write.  In this case, resource allocation
| include things like unwind_protect as it is currently used to
| protect global variables as well as fopen, and malloc.
| 
| Would this be any better than sprinkling BEGIN/END_INTERRUPT and
| OCTAVE_QUIT all over the code?

The method above requires doing something special for all resource
allocations and then undoing that at the point of deallocation.  This
would be in addition to whatever already happens in the constructor
and destructor (which now may or may not be called).

  * Which way adds less overhead?  It may be more expensive to
    add/delete tags in every constructor/destructor pair than it is to
    check the interrupt state in a few strategic locations.

  * Is it easier or harder to write and maintain?  Every allocation,
    not just memory allocations, must be tagged specially.

  * Is it more reliable?  It might not be practical to modify all the
    constructors for all the classes so that they can register the
    resources that they allocate)?

My guess is that the method above requires more care than the way
Octave currently works (with the signal handler setting the interrupt
state and OCTAVE_QUIT to check it).  If you omit OCTAVE_QUIT in some
long-running loop, Octave is just unresponsive to interrupts.  If you
forget to register an allocation, then we will have resource leaks,
and potentially, you could leave the interpreter in an inconsistent
state.

jwe

Re: [OctDev] [PATCH] CVS-octave-forge and GCC3.2

[Paul K. <pki...@ja...>]

On Wed, Nov 27, 2002 at 01:38:22PM -0600, John W. Eaton wrote:
> On 26-Nov-2002, Nix <ni...@es...> wrote:
> | (Hell, there's a worse case than that: the SIGINT is asynchronous, so it
> | can arrive in the middle of a malloc(). If it does that, we're
> | completely screwed and the heap is fubared. But this, too, has always
> | been the case, and there don't seem to be many bug reports that can be
> | traced to screwed heaps. So I guess this is rare enough to ignore.)
> 
> Right.  This is one of the reasons it is bad to jump out of a signal
> handler.  If instead the signal handler sets some flag indicating that
> it has been called and returns so that the jump only happens when it
> is safe, we are OK.  But unless SuperLU is written with signal
> handling in mind, then this will require some changes.

I do find it ugly having to decide for each loop whether or not an octave
quit is desired.  The alternative approach is garbage collection is it
not?  Assuming sigsetjmp/siglongjmp work as advertised, then with a 
garbage collection system you could eventually clean up after an interrupt.
You would have to be careful to write your resource allocator code safely:

allocate_resource() {
	allocating = 1
	grab resource and register it
	allocating = 0
	if (interrupted) siglongjump
}

interrupt_signal() {
	if (interrupted) return
	if (allocating) interrupted=1
	else siglongjmp
}

eval_once() {
	if (sigsetjmp()) collect garbage
	else do next operation
}


Then the bulk of your code, and your numeric code in particular, doesn't
have to glance obsessively at the quit flag to see whether the user has
become bored of waiting yet.  This should make your code faster and easier to
write.  In this case, resource allocation include things like unwind_protect
as it is currently used to protect global variables as well as fopen, and malloc.

Would this be any better than sprinkling BEGIN/END_INTERRUPT and OCTAVE_QUIT
all over the code?

- Paul

Re: [OctDev] [PATCH] CVS-octave-forge and GCC3.2

[John W. E. <jw...@be...>]

On 26-Nov-2002, Nix <ni...@es...> wrote:

| On Mon, 25 Nov 2002, Paul Kienzle yowled:
| 
| > If this works, I can push out a new octave-forge very soon,
| > but Ctrl-C will not be responsive within superLU.
| > 
| > For Ctrl-C we need to put OCTAVE_QUIT in all the inner loops of *.{cc,h}
| 
| No need :)

Why not?  I think they do need to be in the Octave interface glue
code.

| > and wrap calls to superLU with BEGIN/END_INTERRUPT_WITH_EXCEPTIONS.
| > At least I think that's what we are supposed to do.

Yes.  I updated my copy of the octave-forge code from CVS and it looks
like Paul has done the right thing, though it could probably be
improved to handle freeing resources in more places in the Octave glue
code.  But, as Paul mentioned, whether we should actually do that work
depends on whether we are going to actually integrate the SuperLU code
in Octave.

I think the SuperLU code is now at least as good as it was with the
previous interrupt handling model (which was generally very bad
because of the jump out of the signal handler).

| No need for any of that; the _IMMEDIATELY_ variants of those macros set
| up a setjmp() / throw layer. The Octave signal handlers in
| src/sighandlers.cc spot that we're inside an _IMMEDIATELY_ wrapper
| (because `octave_interrupt_immediately' is nonzero) and (sig)longjmp
| there for us.
| 
| > It's not clear how we can clean up a superLU malloc which was interrupted
| > during initialization.  I believe that's why garbage collection was
| > invented.
| 
| You can't clean that up, but then we've *never* been able to clean that
| up. At least this way destructors for C++ objects get called :)
| 
| (Hell, there's a worse case than that: the SIGINT is asynchronous, so it
| can arrive in the middle of a malloc(). If it does that, we're
| completely screwed and the heap is fubared. But this, too, has always
| been the case, and there don't seem to be many bug reports that can be
| traced to screwed heaps. So I guess this is rare enough to ignore.)

Right.  This is one of the reasons it is bad to jump out of a signal
handler.  If instead the signal handler sets some flag indicating that
it has been called and returns so that the jump only happens when it
is safe, we are OK.  But unless SuperLU is written with signal
handling in mind, then this will require some changes.

The "jump from the signal handler" model is generally OK for the old
Fortran 77 numerical code because in most cases that code doesn't
acquire any resources.  All memory allocations are handled outside of
the call to the Fortran 77 subroutine and most of the old Fortran
numerical code doesn't open files or even modify global variables.

| I got stalled by wondering how best to wrap *all* calls into SuperLU. I
| guess that a thin C++ wrapper around SuperLU is indicated, each of which
| does careful BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE /
| END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE calls.
| 
| --- oh, this is only needed in computationally expensive stuff. In cheap
| calls we can just ignore it and leave the calls undecorated, because the
| user won't interrupt in there and won't notice the delay even if he
| does. (Decorating such calls is probably a bad idea, actually, because
| the setup and teardown for the _INTERRUPT_IMMEDIATELY_ stuff isn't
| free.)

Right.  This is the same as the choice we have with calls to Fortran
code.  We either use F77_XFCN (sets up for a potential longjmp call,
so should be used for expensive calls, or ones where we can't easily
determine how long they will take) or F77_FUNC (no longjmp setup, so
we expect it to return quickly).

jwe

Re: [OctDev] [PATCH] CVS-octave-forge and GCC3.2

[John W. E. <jw...@be...>]

On 27-Nov-2002, Paul Kienzle <pki...@ja...> wrote:

| I've sprinkled very ugly OCTAVE_QUIT and BEGIN/END_INTERRUPT_IN_FOREIGN_CODE
| macros throughout the sparse functions.
| 
| sp_test continues to work, even after Ctrl-C.  But if you have top running,
| you can see that Ctrl-C leads to big memory leaks.

This would have been true with the old method of handling interrupts
too, only it would have been even worse because it just jumped back to
the top level, ignoring all resource allocations on the way back to
the top.  Only those that were explicitly added to Octave's
unwind_protect stack would have been deallocated/restored, and in most
cases, Octave's unwind_protect stack is used not to protect resource
allocations, but to ensure that temporary modifications to global
variables are restored.

Now you can control where OCTAVE_QUIT is called.  The resource
allocation problem can be solved by ensuring that resources are
allocated in constructors and deallocated in destructors.  If that's
not possible, then another approach would be to do something like

  if (octave_interrupt_state)
    {
      // Deallocate resources/restore state/etc here.

      octave_interrupt_state = 0;
      octave_throw_interrupt_exception ();
    }

instead of using OCTAVE_QUIT (which is the same as the code above,
except it doesn't explicitly deallocate or restore any resources).

| There is a new debug_on_interrupt flag.  I have confirmed that it will
| drop you into a debug prompt on Ctrl-C, but I haven't checked that it
| is in a valid state when you do.  In particular, I don't know if the
| current line has been run to completion, or if dbg_cont will cause it
| to be executed again.  The few simple tests I did (sp_test followed
| by Ctrl-C followed by dbg_cont) seem to work.

I think it should be OK, because when debug_on_interrupt is set, the
SIGINT handler just does

  octave_debug_on_interrupt_state = true;

and returns.  Unless you send another interrupt before entering the
debugger, octave_interrupt_state will not be set, and Octave will
continue executing until the statement evaluation loop is hit, where
we check the value of octave_debug_on_interrupt_state.  At that point,
we are preparing to evaluate the next statement, so everything
should be in a sane state.

| I don't know how to generate internal sparse errors, so I don't know that
| I have SuperLU compiled correctly to throw fatal errors through C
| code.

For testing, I suppose you could just modify the SuperLU code to
generate one of these errors for a valid call, or modify the way
SuperLU is called so that the call will generate an error.  We have
the same problem with testing what happens when Lapack code is called
with incorrect arguments.  Normally there is not supposed to be any
way to make that happen from Octave, so to test it you have to
introduce an error in code, then remove it after testing is done.

| I'm hoping that these errors will all be memory errors so that throwing a 
| bad_alloc exception is appropriate.

OK.  I haven't really looked at SuperLU, so I don't know, but if there
are other possible errors, it would be nice to distinguish between bad
allocations and other problems.

| Elsewhere sparse is using SP_FATAL_ERROR rather than laboriously 
| returning the error up the stack.  E.g., sparse(1,1,[1,2])
| Since it is SP_FATAL_ERROR which is throwing the bad_alloc exception,
| this is erroneously labeled a "memory exhausted" error.  I'm willing
| to live with that for the moment, but I'm happy to accept patches to
| fix it properly.

OK.

| I don't want to put to much energy into it until I know which sparse
| package John is going to use in Octave.  I've seen reports on the web that
| umfpack and mumps are both faster than superlu, so maybe we will change
| packages.  I know in particular that umfpack does propogates error codes
| rather than punting to a fatal error handler, which will remove at least
| some of the problems in the code.

I will try to respond later today to your other message about sparse
packages that we might be able to use.

Thanks,

jwe

Re: [OctDev] Brighten (beta,map) patch

[Paul K. <pki...@ja...>]

On Wed, Nov 27, 2002 at 10:39:59AM +0200, Simon Cross wrote:
> Greetings,
> 
> I've altered brighten so that the two argument version is now brighten 
> (beta,map).  Since the old brighten (map,beta) didn't seem to work this 
> shouldn't cause any problems.  Putting beta first agress with the tex-info 
> documentation and it seems more logical to put optional arguments at the 
> end.

Regardless, the equivalent function in matlab is brighten(cmap,beta).
Unless there is a good reason to introduce an incompatibility, we
should follow the matlab convention.

> 
> Also, the two argument version now writes the result to the current 
> colormap if the result is not assigned to variable.

Okay.

> 
> *** START DIFF of brighten-old.m against brighten-new.m ***

Could you please use a context diff: diff -c old new

Even with a context diff, the patch still wouldn't apply in this
case because your are changing the same things that have already
been changed in CVS. See:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/octave/octave-forge/main/image/brighten.m?rev=HEAD&content-type=text/plain

You will need an octave version of at least 2.1.37? in order to use
the new varargin/varargout style of processing.  Sorry :-(

> 
> 18,20c18,25
> < ## @deftypefn {Function File} @var{map}= brighten (@var{beta},@var{map})
> < ## darkens or brightens the current colormap. 
> < ## The argument @var{beta} should be a scalar between -1...1,
> ---
> > ## @deftypefn {Function File} @var{map_out}= brighten 
> (@var{beta},@var{map})
> > ## @deftypefnx {Function File} @var{map_out}= brighten (@var{beta})
> > ## darkens or brightens the given colormap.
> > ## If the @var{map} argument is omitted, the function is applied to the
> > ## current colormap.
> > ## Should the resulting colormap @var{map_out} not assigned, it will be
> > ## written to the current colormap.
> > ## The argument @var{beta} should be a scalar between -1 and 1,
> 23,24c28
> < ## If the @var{map} argument is omitted,
> < ## the function is applied to the current colormap
> ---
> > ##
> 30c34
> < function [...] = brighten (m, beta)
> ---
> > function [...] = brighten (beta, m)
> 35d38
> <     beta = m;
> 39,48c42,43
> <     if (nargout == 0)
> <       usage ("map_out=brighten(map,beta)")
> <     endif
> < 
> <     if !(is_scalar (beta) || beta < -1 || beta > 1)
> <       error ("brighten(...,beta) beta must be a scalar in the range 
> -1..1");
> <     endif
> < 
> <     if !( is_matrix (m) && size (m, 2) == 3 )
> <       error ("brighten(map,beta) map must be a matrix of size nx3");
> ---
> >     if ( (!is_matrix (m)) || (size (m, 2) != 3) )
> >       error ("brighten(beta,map): map must be a matrix of size nx3.");
> 52c47,51
> <     usage ("brighten(...) number of arguments must be 1 or 2");
> ---
> >     usage ("brighten(...) number of arguments must be 1 or 2.");
> >   endif
> > 
> >   if ( (!is_scalar (beta)) || (beta <= -1) || (beta >= 1) )
> >     error ("brighten(beta,...) beta must be a scalar in the range 
> (-1,1).");
> 62c61
> <     __current_color_map__ = __current_color_map__ .^ gamma;
> ---
> >     __current_color_map__ = m .^ gamma;
> 64c63
> <     vr_val (map .^ gamma);
> ---
> >     vr_val (m .^ gamma);
> 
> *** END DIFF ***
> 
> Schiavo
> Simon
> --
> The fact that one can live a life where morality is solely a human affair;
> where the natural world offers beauty in abundance; and where life is even
> more precious for being finite is one all freethinkers know, and that's
> why religion doesn't matter. 
> 					       - coljac on www.kuro5hin.org
> 
> [ email:   ten.az.noulg@nomis                      Reversed to foil
>   tel:	   (c) 4979 486 380   (w) 3123 056 (120)   spambots          ]
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

Re: [OctDev] Bugreports

[Paul K. <pki...@ja...>]

I'm not keen on being dependent on source forge features which are not
easily transferable to a new platform.

Having said that, I recently set up an octave-tracker list so that we
can listen for bug reports without having to remember to check the
tracker to see if there are new bugs.

Now if only I could remember the password so that I could administer
the list.

Anyone know enough about mailman to request a new password?

- Paul

PS, I fixed the bug you reported, so the example fir1 filter works again.

On Wed, Nov 27, 2002 at 09:37:54AM +0100, Per Persson wrote:
> Hi all,
> I was just thinking about bugreports.
> Shouldn't we encourage people to submit bugreports via the bug tracker? 
> Having them in the tracker is a way to make sure they don't get lost. 
> It is also a lot easier to refer to them later by their number than to 
> a post to a mailing list?
> 
> Comments?
> 
> /Per 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

[OctDev] Brighten (beta,map) patch

[Simon C. <si...@li...>]

Greetings,

I've altered brighten so that the two argument version is now brighten 
(beta,map).  Since the old brighten (map,beta) didn't seem to work this 
shouldn't cause any problems.  Putting beta first agress with the tex-info 
documentation and it seems more logical to put optional arguments at the 
end.

Also, the two argument version now writes the result to the current 
colormap if the result is not assigned to variable.

*** START DIFF of brighten-old.m against brighten-new.m ***

18,20c18,25
< ## @deftypefn {Function File} @var{map}= brighten (@var{beta},@var{map})
< ## darkens or brightens the current colormap. 
< ## The argument @var{beta} should be a scalar between -1...1,
---
> ## @deftypefn {Function File} @var{map_out}= brighten 
(@var{beta},@var{map})
> ## @deftypefnx {Function File} @var{map_out}= brighten (@var{beta})
> ## darkens or brightens the given colormap.
> ## If the @var{map} argument is omitted, the function is applied to the
> ## current colormap.
> ## Should the resulting colormap @var{map_out} not assigned, it will be
> ## written to the current colormap.
> ## The argument @var{beta} should be a scalar between -1 and 1,
23,24c28
< ## If the @var{map} argument is omitted,
< ## the function is applied to the current colormap
---
> ##
30c34
< function [...] = brighten (m, beta)
---
> function [...] = brighten (beta, m)
35d38
<     beta = m;
39,48c42,43
<     if (nargout == 0)
<       usage ("map_out=brighten(map,beta)")
<     endif
< 
<     if !(is_scalar (beta) || beta < -1 || beta > 1)
<       error ("brighten(...,beta) beta must be a scalar in the range 
-1..1");
<     endif
< 
<     if !( is_matrix (m) && size (m, 2) == 3 )
<       error ("brighten(map,beta) map must be a matrix of size nx3");
---
>     if ( (!is_matrix (m)) || (size (m, 2) != 3) )
>       error ("brighten(beta,map): map must be a matrix of size nx3.");
52c47,51
<     usage ("brighten(...) number of arguments must be 1 or 2");
---
>     usage ("brighten(...) number of arguments must be 1 or 2.");
>   endif
> 
>   if ( (!is_scalar (beta)) || (beta <= -1) || (beta >= 1) )
>     error ("brighten(beta,...) beta must be a scalar in the range 
(-1,1).");
62c61
<     __current_color_map__ = __current_color_map__ .^ gamma;
---
>     __current_color_map__ = m .^ gamma;
64c63
<     vr_val (map .^ gamma);
---
>     vr_val (m .^ gamma);

*** END DIFF ***

Schiavo
Simon
--
The fact that one can live a life where morality is solely a human affair;
where the natural world offers beauty in abundance; and where life is even
more precious for being finite is one all freethinkers know, and that's
why religion doesn't matter. 
					       - coljac on www.kuro5hin.org

[ email:   ten.az.noulg@nomis                      Reversed to foil
  tel:	   (c) 4979 486 380   (w) 3123 056 (120)   spambots          ]

[OctDev] Bugreports

[Per P. <per...@ma...>]

Hi all,
I was just thinking about bugreports.
Shouldn't we encourage people to submit bugreports via the bug tracker? 
Having them in the tracker is a way to make sure they don't get lost. 
It is also a lot easier to refer to them later by their number than to 
a post to a mailing list?

Comments?

/Per 

Fwd: [OctDev] Brighten (beta,map)

[Kai H. <kai...@gm...>]

--- Weitergeleitete Nachricht / Forwarded Message ---
Date: Wed, 27 Nov 2002 07:52:05 +0200 (SAST)
From: Simon Cross <si...@li...>
To: Octave Developers List <oct...@li...>
Subject: [OctDev] Brighten (beta,map)

> Greetings,
> 
> The brighten(beta,map) function (main/image/brighten.m) appears to be
> fooked in all sorts of amusing ways.  Where should I send 
> patches/bug-reports?
> 
> Schiavo
> Simon

Hi Simon,

send here to the list or to me. Indeed the texinfo desciption is wrong. It
should be brighten(map,beta) and the function doesn't work here for: 
>image
>brighten(0.5)

Bye Kai

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!

[OctDev] Brighten (beta,map)

[Simon C. <si...@li...>]

Greetings,

The brighten(beta,map) function (main/image/brighten.m) appears to be
fooked in all sorts of amusing ways.  Where should I send 
patches/bug-reports?

Schiavo
Simon
--
The fact that one can live a life where morality is solely a human affair;
where the natural world offers beauty in abundance; and where life is even
more precious for being finite is one all freethinkers know, and that's
why religion doesn't matter. 
					       - coljac on www.kuro5hin.org

[ email:   ten.az.noulg@nomis                      Reversed to foil
  tel:	   (c) 4979 486 380   (w) 3123 056 (120)   spambots          ]

Re: [OctDev] [PATCH] CVS-octave-forge and GCC3.2

[Paul K. <pki...@ja...>]

I've sprinkled very ugly OCTAVE_QUIT and BEGIN/END_INTERRUPT_IN_FOREIGN_CODE
macros throughout the sparse functions.

sp_test continues to work, even after Ctrl-C.  But if you have top running,
you can see that Ctrl-C leads to big memory leaks.

There is a new debug_on_interrupt flag.  I have confirmed that it will
drop you into a debug prompt on Ctrl-C, but I haven't checked that it
is in a valid state when you do.  In particular, I don't know if the
current line has been run to completion, or if dbg_cont will cause it
to be executed again.  The few simple tests I did (sp_test followed
by Ctrl-C followed by dbg_cont) seem to work.

I don't know how to generate internal sparse errors, so I don't know that
I have SuperLU compiled correctly to throw fatal errors through C code.
I'm hoping that these errors will all be memory errors so that throwing a 
bad_alloc exception is appropriate.

Elsewhere sparse is using SP_FATAL_ERROR rather than laboriously 
returning the error up the stack.  E.g., sparse(1,1,[1,2])
Since it is SP_FATAL_ERROR which is throwing the bad_alloc exception,
this is erroneously labeled a "memory exhausted" error.  I'm willing
to live with that for the moment, but I'm happy to accept patches to
fix it properly.

I don't want to put to much energy into it until I know which sparse
package John is going to use in Octave.  I've seen reports on the web that
umfpack and mumps are both faster than superlu, so maybe we will change
packages.  I know in particular that umfpack does propogates error codes
rather than punting to a fatal error handler, which will remove at least
some of the problems in the code.

I can now build octave-forge against 2.1.40 without error, at least
the subset that I'm installing.  Please test and report any errors.

Paul Kienzle
pki...@us...

On Tue, Nov 26, 2002 at 09:33:12PM +0000, Nix wrote:
> On Mon, 25 Nov 2002, Paul Kienzle yowled:
> > On Mon, Nov 25, 2002 at 08:35:11PM +0000, Nix wrote:
> >> ... oh, damn and blast, SuperLU is C. I didn't notice and thought it was
> >> C++.
> > 
> > Maybe all is not lost.  I forgot that we are recompiling superlu ourselves.
> > When I tested this a couple of years ago, I found that I could do something
> > like:
> 
> [throw through C]
> > This seems to still work.  I don't know what to throw though.
> 
> Yes, this will always work; we'd be in some trouble being ISO C++
> compliant otherwise --- the Standard requires throws through
> std::qsort() and std::bsearch() to work, in s17.3.4.8.2 --- and POSIX
> has a good few callback-style routines, which it would be nice to allow
> exceptions to be thrown through.
> 
> I guess we could have done it by reimplementing qsort() and bsearch() in
> libstdc++-v3, but that would have been ugly.
> 
> (Obviously, exception throws through non-GCC-compiled C code won't work,
> except on the IA64, which has hardware support for exceptions. :) )
> 
> 
> One problem is that this is a rather GCC-specific solution :( I'm sure
> there are compilers out there that *don't* support throwing through C
> code.
> 
> But luckily we don't need to do this at all. (See below.)
> 
> > 
> > 	octave_throw_interrupt_exception() ?
> > 	octave_throw_bad_alloc() ?
> 
> Neither.
> 
> > If this works, I can push out a new octave-forge very soon,
> > but Ctrl-C will not be responsive within superLU.
> > 
> > For Ctrl-C we need to put OCTAVE_QUIT in all the inner loops of *.{cc,h}
> 
> No need :)
> 
> > and wrap calls to superLU with BEGIN/END_INTERRUPT_WITH_EXCEPTIONS.
> > At least I think that's what we are supposed to do.
> 
> No need for any of that; the _IMMEDIATELY_ variants of those macros set
> up a setjmp() / throw layer. The Octave signal handlers in
> src/sighandlers.cc spot that we're inside an _IMMEDIATELY_ wrapper
> (because `octave_interrupt_immediately' is nonzero) and (sig)longjmp
> there for us.
> 
> > It's not clear how we can clean up a superLU malloc which was interrupted
> > during initialization.  I believe that's why garbage collection was
> > invented.
> 
> You can't clean that up, but then we've *never* been able to clean that
> up. At least this way destructors for C++ objects get called :)
> 
> (Hell, there's a worse case than that: the SIGINT is asynchronous, so it
> can arrive in the middle of a malloc(). If it does that, we're
> completely screwed and the heap is fubared. But this, too, has always
> been the case, and there don't seem to be many bug reports that can be
> traced to screwed heaps. So I guess this is rare enough to ignore.)
> 
> Leaving the bit below because it's still relevant:
> 
> >> OK, C that counts as foreign code, so calls into SuperLU will require
> >> BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE /
> >> END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE wrapped around them. That
> >> should let the code flow when interrupted by SIGINT within SuperLU go
> >> 
> >> SIGINT -> signal handler in octave's src/sighandlers.cc ->
> >> octave_jump_to_enclosing_context() -> longjmp() to the
> >> END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE -> Octave's toplev.cc.
> >> 
> >> > The macros to do this are in quit.h, but I don't know the exact magic.
> >> 
> >> I think I've decrypted it.
> >> 
> >> > Let me know if you are going to persue this, because it is top of my list
> >> 
> >> It's top of mine too. Patch in an hour or so (this box is running rather
> >> slowly right now, alas, and it would be inurbane for me to antinice
> >> everyone else into oblivion).
> 
> I got stalled by wondering how best to wrap *all* calls into SuperLU. I
> guess that a thin C++ wrapper around SuperLU is indicated, each of which
> does careful BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE /
> END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE calls.
> 
> --- oh, this is only needed in computationally expensive stuff. In cheap
> calls we can just ignore it and leave the calls undecorated, because the
> user won't interrupt in there and won't notice the delay even if he
> does. (Decorating such calls is probably a bad idea, actually, because
> the setup and teardown for the _INTERRUPT_IMMEDIATELY_ stuff isn't
> free.)
> 
> So probably that's just a few potentially-expensive SuperLU calls we
> need to decorate.
> 
> Any idea which they are? I haven't much of a clue :)
> 
> -- 
> `I keep hearing about SF writers dying, but I never hear about SF
>  writers being born.  So I guess eventually there'll be none left.'
>                                     -- Keith F. Lynch
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

Re: [OctDev] [PATCH] CVS-octave-forge and GCC3.2

[Nix <ni...@es...>]

On Mon, 25 Nov 2002, Paul Kienzle yowled:
> On Mon, Nov 25, 2002 at 08:35:11PM +0000, Nix wrote:
>> ... oh, damn and blast, SuperLU is C. I didn't notice and thought it was
>> C++.
> 
> Maybe all is not lost.  I forgot that we are recompiling superlu ourselves.
> When I tested this a couple of years ago, I found that I could do something
> like:

[throw through C]
> This seems to still work.  I don't know what to throw though.

Yes, this will always work; we'd be in some trouble being ISO C++
compliant otherwise --- the Standard requires throws through
std::qsort() and std::bsearch() to work, in s17.3.4.8.2 --- and POSIX
has a good few callback-style routines, which it would be nice to allow
exceptions to be thrown through.

I guess we could have done it by reimplementing qsort() and bsearch() in
libstdc++-v3, but that would have been ugly.

(Obviously, exception throws through non-GCC-compiled C code won't work,
except on the IA64, which has hardware support for exceptions. :) )


One problem is that this is a rather GCC-specific solution :( I'm sure
there are compilers out there that *don't* support throwing through C
code.

But luckily we don't need to do this at all. (See below.)

> 
> 	octave_throw_interrupt_exception() ?
> 	octave_throw_bad_alloc() ?

Neither.

> If this works, I can push out a new octave-forge very soon,
> but Ctrl-C will not be responsive within superLU.
> 
> For Ctrl-C we need to put OCTAVE_QUIT in all the inner loops of *.{cc,h}

No need :)

> and wrap calls to superLU with BEGIN/END_INTERRUPT_WITH_EXCEPTIONS.
> At least I think that's what we are supposed to do.

No need for any of that; the _IMMEDIATELY_ variants of those macros set
up a setjmp() / throw layer. The Octave signal handlers in
src/sighandlers.cc spot that we're inside an _IMMEDIATELY_ wrapper
(because `octave_interrupt_immediately' is nonzero) and (sig)longjmp
there for us.

> It's not clear how we can clean up a superLU malloc which was interrupted
> during initialization.  I believe that's why garbage collection was
> invented.

You can't clean that up, but then we've *never* been able to clean that
up. At least this way destructors for C++ objects get called :)

(Hell, there's a worse case than that: the SIGINT is asynchronous, so it
can arrive in the middle of a malloc(). If it does that, we're
completely screwed and the heap is fubared. But this, too, has always
been the case, and there don't seem to be many bug reports that can be
traced to screwed heaps. So I guess this is rare enough to ignore.)

Leaving the bit below because it's still relevant:

>> OK, C that counts as foreign code, so calls into SuperLU will require
>> BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE /
>> END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE wrapped around them. That
>> should let the code flow when interrupted by SIGINT within SuperLU go
>> 
>> SIGINT -> signal handler in octave's src/sighandlers.cc ->
>> octave_jump_to_enclosing_context() -> longjmp() to the
>> END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE -> Octave's toplev.cc.
>> 
>> > The macros to do this are in quit.h, but I don't know the exact magic.
>> 
>> I think I've decrypted it.
>> 
>> > Let me know if you are going to persue this, because it is top of my list
>> 
>> It's top of mine too. Patch in an hour or so (this box is running rather
>> slowly right now, alas, and it would be inurbane for me to antinice
>> everyone else into oblivion).

I got stalled by wondering how best to wrap *all* calls into SuperLU. I
guess that a thin C++ wrapper around SuperLU is indicated, each of which
does careful BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE /
END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE calls.

--- oh, this is only needed in computationally expensive stuff. In cheap
calls we can just ignore it and leave the calls undecorated, because the
user won't interrupt in there and won't notice the delay even if he
does. (Decorating such calls is probably a bad idea, actually, because
the setup and teardown for the _INTERRUPT_IMMEDIATELY_ stuff isn't
free.)

So probably that's just a few potentially-expensive SuperLU calls we
need to decorate.

Any idea which they are? I haven't much of a clue :)

-- 
`I keep hearing about SF writers dying, but I never hear about SF
 writers being born.  So I guess eventually there'll be none left.'
                                    -- Keith F. Lynch

Re: [OctDev] [PATCH] CVS-octave-forge and GCC3.2

[Paul K. <pki...@ja...>]

On Mon, Nov 25, 2002 at 08:35:11PM +0000, Nix wrote:
> On Sun, 24 Nov 2002, Paul Kienzle said:
> > The reason that won't work is because you need to something to catch it.
> 
> But the catcher is in octave/toplev.cc; it throws right through our code
> and out the other side.
> 
> (I'm sort of assuming that our destructors do all the necessary cleanup;
> if not, we'll need the occasional catch-and-rethrow ourselves.)
> 
> Of course this code only handles errors, not interrupts. For that, see
> below :)
> 
> > That requires putting trapping code around each call to superLU to set
> > the jump return address and reset it when done.  Plus any loops outside
> > of superLU need to have periodic checks if an interrupt has been triggered.
> 
> ... oh, damn and blast, SuperLU is C. I didn't notice and thought it was
> C++.

Maybe all is not lost.  I forgot that we are recompiling superlu ourselves.
When I tested this a couple of years ago, I found that I could do something
like:

main.cc:

#include <iostream>

extern "C" { void throw_back(void); }
extern "C" { void C_stuff(void); }

class myexception {};
void throw_back(void) { throw myexception(); }

int main(int argc, char *argv[])
{
   try {
	C_stuff();
	std::cout << "not caught" << std::endl;
   } catch (myexception) {
        std::cout << "caught" << std::endl;
   }
   return 0;
}

lib.c:

void C_stuff(void)
{
  void throw_back(void);

  throw_back();
}

Makefile:

all: main.o lib.o
	g++ main.o lib.o -o throw_back

main.o: main.cc
	g++ -c main.cc -o main.o

lib.o: lib.c
	gcc -c -fexceptions lib.c -o lib.o


This seems to still work.  I don't know what to throw though.

	octave_throw_interrupt_exception() ?
	octave_throw_bad_alloc() ?

If this works, I can push out a new octave-forge very soon,
but Ctrl-C will not be responsive within superLU.  

For Ctrl-C we need to put OCTAVE_QUIT in all the inner loops of *.{cc,h}
and wrap calls to superLU with BEGIN/END_INTERRUPT_WITH_EXCEPTIONS.
At least I think that's what we are supposed to do.

It's not clear how we can clean up a superLU malloc which was interrupted
during initialization.  I believe that's why garbage collection was
invented.

> 
> OK, C that counts as foreign code, so calls into SuperLU will require
> BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE /
> END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE wrapped around them. That
> should let the code flow when interrupted by SIGINT within SuperLU go
> 
> SIGINT -> signal handler in octave's src/sighandlers.cc ->
> octave_jump_to_enclosing_context() -> longjmp() to the
> END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE -> Octave's toplev.cc.
> 
> > The macros to do this are in quit.h, but I don't know the exact magic.
> 
> I think I've decrypted it.
> 
> > Let me know if you are going to persue this, because it is top of my list
> 
> It's top of mine too. Patch in an hour or so (this box is running rather
> slowly right now, alas, and it would be inurbane for me to antinice
> everyone else into oblivion).
> 
> > (right behind family and work that is, which in this season puts it 
> > much too far back ;-)
> 
> :)
> 
> -- 
> `I keep hearing about SF writers dying, but I never hear about SF
>  writers being born.  So I guess eventually there'll be none left.'
>                                     -- Keith F. Lynch
> 

Re: [OctDev] [PATCH] CVS-octave-forge and GCC3.2

[Nix <ni...@es...>]

On Sun, 24 Nov 2002, Paul Kienzle said:
> The reason that won't work is because you need to something to catch it.

But the catcher is in octave/toplev.cc; it throws right through our code
and out the other side.

(I'm sort of assuming that our destructors do all the necessary cleanup;
if not, we'll need the occasional catch-and-rethrow ourselves.)

Of course this code only handles errors, not interrupts. For that, see
below :)

> That requires putting trapping code around each call to superLU to set
> the jump return address and reset it when done.  Plus any loops outside
> of superLU need to have periodic checks if an interrupt has been triggered.

... oh, damn and blast, SuperLU is C. I didn't notice and thought it was
C++.

OK, C that counts as foreign code, so calls into SuperLU will require
BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE /
END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE wrapped around them. That
should let the code flow when interrupted by SIGINT within SuperLU go

SIGINT -> signal handler in octave's src/sighandlers.cc ->
octave_jump_to_enclosing_context() -> longjmp() to the
END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE -> Octave's toplev.cc.

> The macros to do this are in quit.h, but I don't know the exact magic.

I think I've decrypted it.

> Let me know if you are going to persue this, because it is top of my list

It's top of mine too. Patch in an hour or so (this box is running rather
slowly right now, alas, and it would be inurbane for me to antinice
everyone else into oblivion).

> (right behind family and work that is, which in this season puts it 
> much too far back ;-)

:)

-- 
`I keep hearing about SF writers dying, but I never hear about SF
 writers being born.  So I guess eventually there'll be none left.'
                                    -- Keith F. Lynch

Re: [OctDev] [PATCH] CVS-octave-forge and GCC3.2

[Paul K. <pki...@ja...>]

The reason that won't work is because you need to something to catch it.
That requires putting trapping code around each call to superLU to set
the jump return address and reset it when done.  Plus any loops outside
of superLU need to have periodic checks if an interrupt has been triggered.

The macros to do this are in quit.h, but I don't know the exact magic.
Let me know if you are going to persue this, because it is top of my list
(right behind family and work that is, which in this season puts it 
much too far back ;-)

- Paul

On Sun, Nov 24, 2002 at 09:46:18PM +0000, Nix wrote:
> [Apologies for lack of References:, I am not a member of this list.]
> 
> octave-forge needs adjustment to handle the new exception-based
> interrupt model in the latest CVS octave. I think this fixes it:
> 
> 2002-11-24  Nix  <ni...@es...>
> 
> 	* make_sparse.h (SP_FATAL_ERR): Use octave_throw_interrupt_exception()...
> 	* make_sparse.h (includes): ... declared in quit.h.
> 
> Index: octave-forge/main/sparse/make_sparse.h
> ===================================================================
> RCS file: /cvsroot/octave/octave-forge/main/sparse/make_sparse.h,v
> retrieving revision 1.9
> diff -u -r1.9 make_sparse.h
> --- octave-forge/main/sparse/make_sparse.h	5 Nov 2002 19:21:07 -0000	1.9
> +++ octave-forge/main/sparse/make_sparse.h	24 Nov 2002 21:40:14 -0000
> @@ -89,7 +89,7 @@
>  // Thanks to To: Paul Kienzle <pki...@ki...>
>  // for help with error handling 
>  #define SP_FATAL_ERR(str) { error("sparse: %s", str);  \
> -                            jump_to_top_level ();  \
> +                            octave_throw_interrupt_exception ();  \
>                              panic_impossible (); }
>  
>  // The SuperLU includes need to be first,
> @@ -132,6 +132,7 @@
>  #include <octave/ov-complex.h>
>  #include <octave/ov-re-mat.h>
>  #include <octave/ov-cx-mat.h>
> +#include <octave/quit.h>
>  #include <octave/pager.h>
>  #include <octave/pr-output.h>
>  #include <octave/symtab.h>
> 
> -- 
> `I keep hearing about SF writers dying, but I never hear about SF
>  writers being born.  So I guess eventually there'll be none left.'
>                                     -- Keith F. Lynch
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev