Re: [Dar-libdar_api] Problems with the Python bindings

[Denis C. <dar...@fr...>]

Martin Bergner wrote:
> Hi,

Hello Martin,

I cannot bring you much help about the Python bidings (I don't speak
(yet?) Python :-) ). I guess, Wesley Leggette could help as he is the
author of this bindings, however he does not seem to be subscribed to
this mailing-list. At the bottom of the page [1] you can find a link to
contact Wesley.

Sorry not being able to help you much more. If however I misunderstood
the problem or if you think the problem is linked to libdar itself (not
to the Python bindings), please let me know.

Kind Regards,
Denis.

> 
> I'm one of the developers of HUBackup [0] in Ubuntu. As the program is
> written in Python, we now decided that it would be nice if we used the
> DAR Python bindings [1]. 
> 
> However, there seem to be some problems with the bindings themselves. I
> could fix some, but I'm now at a point where I don't really know where
> the problem is exactly. 
> 
> The problems I fixed were:
> 1. The bindings wouldn't compile in one step. Once invoking "make"
> failed, doing it a second time worked. The fix was a small %import
> statement in user_interaction.i
> 
> 2. The bindings wouldn't work with the default Debian mode of 64. I
> fixed that by changing the Makefiles and adjusting one or two *.i files.
> The bindings now compile and load with every mode.
> 
> 3. The bindings didn't work when specifying a user_interaction object.
> As python does not work with something like that:
> 
> test.py:
> *********************************
> #!/usr/bin/env python
> def fun_test(param1):
>     print param1
> 
> def fun_fail(param1):
>     if param1 == None:
>         fun_test = None
>     else:
>         fun_test(param1)
> 
> fun_fail("Bla")
> 
> *********************************
> But that was also easily fixable.
> I will attach a small patch that fixes these problems when the patch is
> applied. I deleted the Perl and Ruby bindings stuff since it is not
> really necessary.
> 
> Our code now successfully uses the List job and I can even see all the
> files in an dar archive so that works correctly. However, I can not use
> the Extract Job. When I set Verbose to "true" I get the message
> "Extracting contents from the archive" but that is it. The dar archive
> is small enough so that it shouldn't take long to extract something.
> However, the "Extracting ..." is the last message that I get. (My
> interaction stuff is ok since it works with the list job).
> 
> I suspect that there is a problem with the masks. I get a lot of
> "swig/python detected a memory leak of type 'std::string *', no
> destructor found." warnings which I think appear in mask. Also, I can't
> use the list job with a specific mask to only show parts of the files in
> the archive.
> 
> I currently use the following code snippet to access the extract object:
> 
> Excerpt from hurestore.py:
> *********************************
> from dar import job
> class hurestore:
>     restore(self):
>         job_extract = job.Extract()
>         job_extract.interaction = gtk_interaction(self.window)
>         job_extract.root_path = self.path_to_which_restoring
>         job_extract.archive_path = self.path_where_archive_is
>         job_extract.archive_name = self.archive_name
>         job_extract.verbose = True
>         job_extract.selection = True
>         job_extract.run()
> *********************************
> 
> This gives me the above behaviour.
> 
> This is all the information I think are interesting so far but if you
> need more, just ask.
> 
> Thanks in advance, 
> Martin
> 
> [0] https://launchpad.net/hubackup
> [1] http://darbinding.sourceforge.net
> 
>