After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 686590 - Folks is unusable through GObject Introspection ( Python )
Folks is unusable through GObject Introspection ( Python )
Status: RESOLVED OBSOLETE
Product: folks
Classification: Platform
Component: libfolks
0.6.x
Other Linux
: Normal normal
: Unset
Assigned To: folks-maint
folks-maint
Depends on:
Blocks:
 
 
Reported: 2012-10-21 19:33 UTC by Amanda Cameron
Modified: 2018-09-21 15:59 UTC
See Also:
GNOME target: ---
GNOME version: 3.3/3.4


Attachments
libfolks GI test code. (328 bytes, text/x-python)
2012-10-21 19:33 UTC, Amanda Cameron
Details

Description Amanda Cameron 2012-10-21 19:33:43 UTC
Created attachment 226942 [details]
libfolks GI test code.

I'd like to tie one of my projects into libfolks, and I've been trying off and on since it was put into the public eye. However it's not usable through GObject Introspection, not in python, at least.

It causes a sigsegv, as outlined here:
https://mail.gnome.org/archives/libgee-list/2012-January/msg00007.html

Example code is attached. Thanks for your time.
Comment 1 Philip Withnall 2012-11-04 22:18:19 UTC
This seems to be a problem with PyGI rather than with folks, unless you can provide a backtrace which shows a problem in folks? Could you please be more specific about what is failing?
Comment 2 Martin Pitt 2013-01-14 14:56:14 UTC
For me it crashes in the iter.get() call in the list_individuals callback. If I comment this out, and just do

   print(iter, iter.get)

it works:

list_individuals <IndividualAggregator object at 0x7ffff53de690 (FolksIndividualAggregator at 0xb4c0c0)>
iter <__main__.GeeHashMapEntryIterator object at 0x7ffff548d230 (GeeHashMapEntryIterator at 0xfe3540)> <bound method __main__.GeeHashMapEntryIterator.get of <__main__.GeeHashMapEntryIterator object at 0x7ffff548d230 (GeeHashMapEntryIterator at 0xfe3540)>>

Can you confirm this finding, i. e. is it the iter.get() call which is triggering this?

Honestly I'm a bit lost here how that maps to an actual method in Gee-1.0.gir. However, I was told that this corresponds to

  http://git.gnome.org/browse/libgee/tree/gee/hashmap.vala#n544

At first this smelled like a wrong transfer annotation; all the *_get() methods have transfer-ownership="full", while the Vala code just returns a reference to the internal node. But if I just hack the .gir to replace them all with "none", it still crashes the same way.

It seems there is already some analysis in https://mail.gnome.org/archives/libgee-list/2012-January/msg00007.html from someone who actually has a clue what Gee is and how it works.
Comment 3 Martin Pitt 2013-01-14 15:11:27 UTC
I'm trying to reduce this to a test case that only involves Gee, not Folks plus Gee. I think there has been some work on providing GI fixes in current Gee, but as Folks doesn't currently want to work with Gee > 0.6, it's hard to test this with current versions.

But, looking how Gee's .gir is full of "gpointer" types, and Gee's Vala API is full of templates, and that I'm unable to even instantiate something like a Gee Hash

>>> Gee.HashMap
TypeError: must be an interface

etc. I'm a bit lost here. Does someone have a pointer how to use Gee objects from Python?
Comment 4 Jasper St. Pierre (not reading bugmail) 2013-01-14 15:17:11 UTC
libgee is really an API designed for Vala, not an introspectable API. In my opinion, we should just stop using libgee.
Comment 5 Philip Withnall 2013-01-14 15:34:20 UTC
(In reply to comment #4)
> In my opinion, we should just stop using libgee.

…and replace it with? :)
Comment 6 GNOME Infrastructure Team 2018-09-21 15:59:04 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/folks/issues/46.