Re: clobbered (and parallelized Octave)

[John W. Eaton]

On  2-Nov-2000, Andy Jacobson <address@hidden> wrote:

| >>>>> "John" == John W Eaton <address@hidden> writes:
| 
|     John> After commenting out the <STUFF DELETED> lines in your
|     John> example, it compiled fine on my system (gcc 2.95.2, Debian
|     John> GNU/Linux).  Can you please provide a complete example that
|     John> demonstrates the problem?  The details that you omitted are
|     John> probably important...
| 
| Good idea, I should have thought of trying to compile that skeletal
| fraction myself.  This led me to discover that it is the presence of
| the following command which causes these compiler errors:
| 
|       F77_XFCN (dgenunf, DGENUNF, (0.0, 1.0, ranval));

If I replace the <STUFF DELETED> comments with this line, I am still
able to compile without warnings.

Can you please send a *complete* example that demonstrates the
problem?

| I peaked under the hood of f77-fcn.h and I suppose this has something
| to do with the setjmp call, but I've never worked with that before.
| Anyway, I suppose the right question to ask is whether there might be
| a different, standardized way of accessing Fortran routines from an
| .oct file?

F77_FCN can also be used to call Fortran functions.  F77_XFCN is
useful when the function you are calling can call XSTOPX, which is a
subroutine that I used to replace all STOP statements in the Fortran
code used by Octave.  F77_XFCN calls setjmp to mark where the call
happens, then if the Fortran code does something that would have
caused it to stop, XSTOPX eventually calls a C function that sets a
flag and does a longjmp back to the location of the call, and Octave
can raise an error and continue instead of aborting.  If you know that
the code you wish to call will never execute XSTOPX, then you can use
F77_FCN instead.

| All is not lost, however.  I think I can use the functions in
| load-save.cc to just read/write octave_values to a simple buffer.
| What I'm doing is setting up an ostream to write to a char* buffer.
| (I sure hope that's what the functions defined in strstream.h are
| for.)  I would like to call the do_save (or perhaps save_binary_data)
| function with that ostream:
| 
|   symbol_record *sr=curr_sym_tab->lookup (variable_name,0,0);
| 
|   char buf[expected_length];
|   
|   strstreambuf ssbuf(buf,expected_length);
|   ostream os(&ssbuf,NULL);
| 
|   do_save(os,sr,LS_BINARY,0);

You should be able to do this with

  ostrstream buf;
  do_save (buf, sr, LS_BINARY, 0);
  buf.ends ();
  char *s = buf.str ();
  // Use s ...
  delete [] s;

instead, and not have to predict the size of the buffer.

| So some test code to do this is in place right now, but I can't get it
| to link.  This I don't understand: if I give a prototype in my .cc
| file, and a function which matches that prototype is in
| liboctinterp.a, why can't I link to it?  And where IS the prototype
| for, e.g., do_save() anyway?

There isn't a public declaration because it is declared static in
load-save.cc.  It is declared static because it was intended as a
private internal function.  If it is really useful elsewhere, I don't
see a reason to keep it static, but it might be good to think about
what the public interface to load and save be.

jwe



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------