Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

libiphone python bindings are broken

#84

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.

Reported by Martin S. · November 8th, 2009 @ 10:15 PM

State: resolved
Milestone: 1.0 Release
Assigned to: Matt Colyer Matt Colyer

Activity

  1. Jonathan Beck
    Jonathan Beck

    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.

    November 10th, 2009 @ 07:08 AM

  2. Martin S.
    Martin S.

    Here we go...

    November 10th, 2009 @ 12:48 PM

  3. Martin S.
    Martin S.
    • 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

    November 10th, 2009 @ 03:33 PM

  4. Jonathan Beck
    Jonathan Beck

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

d.keys()
d.values()
d.items()

    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");
a.Append(s);
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 ! :)

    November 10th, 2009 @ 04:53 PM

  5. Martin S.
    Martin S.
    • 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.

    November 11th, 2009 @ 12:45 PM

  6. Martin S.
    Martin S.
    • 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
    http://github.com/MattColyer/libiphone/commit/28d1fcac0eda09e829ef8...

    November 11th, 2009 @ 03:34 PM

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.