[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: save and load bug.
From: |
Xavier Delacour |
Subject: |
Re: save and load bug. |
Date: |
Mon, 29 Dec 2008 02:19:55 -0500 |
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)
>
>
- RE: save and load bug., (continued)
- RE: save and load bug., GARY FORBIS, 2008/12/27
- Re: save and load bug., Ben Abbott, 2008/12/27
- Message not available
- Re: save and load bug., Ben Abbott, 2008/12/27
- Re: save and load bug., David Bateman, 2008/12/28
- Re: save and load bug., Søren Hauberg, 2008/12/28
- Re: save and load bug., David Bateman, 2008/12/28
- RE: save and load bug., GARY FORBIS, 2008/12/28
- Re: save and load bug., Jaroslav Hajek, 2008/12/28
- RE: save and load bug., GARY FORBIS, 2008/12/28
- Re: save and load bug., Jaroslav Hajek, 2008/12/29
- Re: save and load bug.,
Xavier Delacour <=
- RE: save and load bug., Sergei Steshenko, 2008/12/28
RE: save and load bug., GARY FORBIS, 2008/12/28