Re: save and load bug.

[Xavier Delacour]

On Sun, Dec 28, 2008 at 6:20 AM, David Bateman <address@hidden> wrote:
> 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.

I would be happy to, except a couple of issues still prevent it I
think (it's been a while since I looked closely).

- The SWIG shadow classes require at least destructors, in order call
underlying C++ destructors. "Handle classes" in the new class scheme
released in matlab 2008 support this, but my understanding is that
old-style OOP (all that is supported by Octave) doesn't.

- Without the new-style class support, each wrapped (member) function
would imply a generated m-file. For wrapping even modestly large
libraries (where SWIG is very useful), this means processing an
interface file would generate hundreds of files. The current
implementation just generates a single C++ file per module (that
compiles to .oct), and other SWIG languages (e.g., Python) generate a
single .py and C++ file per module. With the new classdef syntax I
think it would be possible to approach that, ie, generate single .m
file per module or per wrapped class.

I suppose one can imagine patching Octave to get around the first
point, and ignoring the second.. but I would prefer to avoid that and
stick to the official language, and even migrate the C++ side to use
the mex interface. That way SWIG generated bindings would compile for
matlab as well (quite a few people have emailed asking for that since
octave support was released).

I know Michael Goffioul started on classdef support, maybe he can
comment on the status of that project.

Anyway, for purposes of save/load functions that warn or silently do
nothing, it's a half dozen line patch I think (to
Lib/octave/octrun.swg in the swig tree). I'll look into that next week
when I have a bit more time.

Xavier

>
> 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)
>
>