#84 ✓resolved
Martin S.

libiphone python bindings are broken

Reported by Martin S. | November 8th, 2009 @ 10:15 PM | in 1.0 Release

As reported on the ML:

$ python
Python 2.6.4 (r264:75706, Nov  2 2009, 14:38:03)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> from libiphone.iPhone import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/dist-packages/libiphone/iPhone.py", line 7,
in <module>

import _iPhone

ImportError: /usr/lib/python2.6/dist-packages/libiphone/iPhone.so: undefined symbol: ZTIN5PList10DictionaryE

I fixed it by adding the libplist++ libs to the swig/Makefile.am _LIBADD. Is that the proper solution?
Is it really required to have libplist++ in order to build libiphone python bindings? Aren't the C functions enough or does the C++ stuff have benefits?

P.S.: Forgive the freaking layout but lighthouseapp.com plain sucks at markup parsing.

Comments and changes to this ticket

  • Jonathan Beck

    Jonathan Beck November 10th, 2009 @ 07:08 AM

    Yes, this is the proper way to fix libiphone binding.

    The new plist python binding is entirely based on the C++ stuff. It benefits are a good object model, standard conaitners/iterators and most importantly has a lot better integration in SWIG (and thus feels a lot batter from the python side).

    Please provide a patch to be integrated in libiphone.

  • Martin S.
  • Martin S.

    Martin S. November 10th, 2009 @ 03:33 PM

    • State changed from “new” to “open”
    • Assigned user set to “Jonathan Beck”

    Actually, attempting to port python-iphonesync to the newer API wrapper, I noticed a few issues.

    Could you give an example on how one would work with the C++ API to create a basic dictionary with a key and string value and output it as XML? I can't really see how that should be possible with the current state of bindings.

    Also why is there the Utils class vs. the Structure class?
    Shouldn't the Node class rather conform to some "IPListSerializable" interface which dictates ToXML(), FromXML(), ToBinary(), FromBinary() methods? So one can do ToXML() on any node type and get appropriate serialization? You would also get recursive serialization for free.

    E.g.: PList::String::ToXML -> value

    The other option, if you planned to have the PList::Structure class as a "serialization container", would be to merge FromXml, FromBin as static methods and get rid of PList::Utils.

    So the workflow would be:

    • Create a PList::Structure (act's as "root node")
    • Add PList::Node instances to the structure (maybe Node->AddChild() is much easier here than SomeNode->SetParent(the_structure_instance_of_step_1))
    • print PList::Structure::ToXML, which generates the XML representation of it's associated nodes
  • Jonathan Beck

    Jonathan Beck November 10th, 2009 @ 04:53 PM

    Please consider the following snippet of python code to see how to use the new python binding:

    #!/usr/bin/env python
    # -*- coding: utf-8 -*-
    from libplist.PList import *
    a = Array()
    a.append( String("SDMessageSyncDataClassWithDevice") )
    a.append( String("com.apple.Contacts") )
    a.append( String("---") )
    a.append( String("2009-01-13 22:25:58 +0100") )
    a.append( Integer(106) )
    a.append( String("___EmptyParameterString___") )
    print a.to_xml()
    d = Dictionary()
    d['Boolean 1'] = Boolean(True)
    d['Boolean 2'] = Boolean(False)
    d['string key'] = String('string value')
    print d.to_xml()
    print d['string key'].get_value()

    The FromXml and FromBin can very well be moved in the Structure Class, but the FromPlist function should stay in utils.
    The PList::Structure class is a serialization container, scalar node should not be serialized.

    Also the SetParent() method should not have been public. I forgot to move it to private as a friend method as it is only used internally (when calling Insert() or Append() on structured types).
    Also keep in mind that PList::Strucutre is abstract and cannot be instantiated as is.

    the workflow is quite close to what you mention :
    - Create a structured type to act as "root node" : either PList::Array or PList::Dictionary. - Call Insert() or Append()

    PList::Array a = new Array();
    PList::String s = new String("some string");
    delete s;

    I am not quite happy with the trailing delete but I guess this is non avoidable. In python we do not have this. - Call ToXml() on the structured type (Array or Dictionary)

    I hope I made it clear ! :)

  • Martin S.

    Martin S. November 11th, 2009 @ 12:45 PM

    • Assigned user changed from “Jonathan Beck” to “Matt Colyer”

    Great, thanks for the explanation.
    Agree about the parent function and serialization then.
    Perhaps that example would fit well into the README.

    Assigning to Matt regarding the patch now though.

  • Martin S.

    Martin S. November 11th, 2009 @ 03:34 PM

    • State changed from “open” to “resolved”

    (from [28d1fcac0eda09e829ef8c8b46fad0e45590af16]) Require libplist++ in order to fix linking of Python bindings

    [#84 state:resolved]

    Signed-off-by: Matt Colyer matt@colyer.name

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

A project around supporting the iPhone in Linux.

See http://libimobiledevice.org

People watching this ticket


Referenced by