RE: save and load bug.

[GARY FORBIS]

Thanks all.  Eliminating one issue lets me focus better.
 
I'm still looking.  I'm very new to Octave even though I tried
loading it in the spring of 2008.  I didn't get as far as I've gotten now when
trying to run the software I was using to learn more about ANNs and MathLab
at the same time.  I gave  up quickly.
 
I don't understand the structure of the files on sourceforge.
I'm having a bit of trouble getting started.  It's one more thing to learn.
I saved octave-forge-bundle-20080831.tar.gz to my cygwin home directory, unzipped,
and untarred it.  It looks like the various pieces are tarred and zipped inside the package.
 
I guess I can just recursively unzip an untar the files.  Is there some documentation about
where things are in the source files?
 
My first guess was that the file was read a record at a time then parsed and I had hit a
16 bit limit.  This didn't make much sense to me so I tried positive numbers and I was able
to write records with many more numbers in them and load them back in.  Negative number
with few significant digits had less poblems as well.

> Date: Sun, 28 Dec 2008 12:20:55 +0100
> From: address@hidden
> To: address@hidden
> CC: address@hidden; address@hidden; address@hidden; address@hidden
> Subject: Re: save and load bug.
>
> Søren Hauberg wrote:
> > søn, 28 12 2008 kl. 11:12 +0100, skrev David Bateman:
> >
> >> Either don't save all of the variables or don't have database or ftp
> >> that rely on SWIG loaded.... The swig packages don't have the code to
> >> save the swig objects.. Perhaps these packages shouldn't be marked as
> >> autoloaded
> >>
> >
> > I don't know this part of the code, so this might be a silly question.
> > How hard would it be to extend the swig code to support saving variables
> > such that when the user tries to save these variables a warning is
> > printed saying that the variables won't be saved?
> >
> > Søren
> >
> >
> >
> Reading ftp_wrap.cpp I see the following
>
> // octave_swig_type plays the role of both the shadow class and the class
> // representation within Octave, since there is no support for classes.
> //
> // These should really be decoupled, with the class support added to
> Octave
> // and the shadow class given by an m-file script. That would
> dramatically
> // reduce the runtime complexity, and be more in line w/ other modules.
>
> class octave_swig_type:public octave_base_value {
> struct cpp_ptr {
> void *ptr;
> bool destroyed;
> cpp_ptr(void *_ptr):ptr(_ptr), destroyed(false) {
> }};
>
> So it seems the solution is to implement the comment about the shadow
> class being written as OOP code in octave and then the load/save of SWIG
> objects would be implemented ass OOP objects can be loaded and saved in
> Octave 3.1.51+... Xavier Delacour wrote this stuff perhaps he'd be
> willing to look at this conversion.
>
> Note however this seems to be unrelated to the original issue in this
> thread.
>
> Regards
> David
>
> --
> David Bateman address@hidden
> 35 rue Gambetta +33 1 46 04 02 18 (Home)
> 92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob)
>