save and load bug.

David Bateman dbateman at dbateman.org
Sun Dec 28 05:20:55 CST 2008


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                                dbateman at dbateman.org
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)



More information about the Help-octave mailing list