|
From: | GARY FORBIS |
Subject: | RE: save and load bug. |
Date: | Sun, 28 Dec 2008 17:09:14 +0000 |
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) > |
[Prev in Thread] | Current Thread | [Next in Thread] |