Re: [anjuta-devel] New project interface and introspection

[Abderrahim KITOUNI <a kitouni gmail com>]

Hello Sébastien,

Le 26 septembre 2010 10:25, Sébastien Granjoux <seb sfo free fr> a écrit :
> Hi Abderrahim,
>
> Le 25/09/2010 23:38, Abderrahim Kitouni a écrit :
> > You scared me. I thought all node methods will really have an additional
> > argument. But looking below, I only see the load/save/add/remove have
> > moved back to the project interface.
>
> Yes, all methods allowing to move in the project tree don't need a specific implementation and are working 
> the same whatever is the project, so they don't get the project pointer.

> > These are here to actually load from/save to the filesystem. They make
> > sense here to avoid making assumptions about the actual project format.
>
> Do you mean the project format in the memory (not on disk) ?
No, I meant on disk :-)
As an example, take autotools, if we save a "target" node, we will
need to write the Makefile.am in the directory and maybe the top-level
configure.ac, other build software (ant comes to mind) use only a
top-level. So saving is a project operation and not a node operation.
(in short, I'm saying I like this part of the design)

> > And these methods are just for "bookkeeping", right? I mean that, in
> > simple backends, they could have a default implementation that just
> > forwards calls to the actual node.
>
> Not really, for me the "bookkeeping" methods are all methods defined in
I seems we have a different definition of "bookkeeping" ;-) What I meant is
that these methods are implemented in the backend (rather than having the
project manager use AnjutaProjectNode API directly) in order for the backend
to keep track of what's happening.

> The two add methods are very important, because they are the only way to
> create a new node. Creating a new node is specific to the backend.
Right, I overlooked this.

> The remove method can be implement in a generic way, setting the remove
> flag, it's done like this currently, but I think it could be useful to
> do something special.
"do something special" is exactly what I mean by "bookkeeping".

> Could you give me a example of such case ?
> [...]
> I don't see 'manual' free. Do you see some of them ?
I think this discussion won't bring much. Let's keep them gobjects for now
(but see below for Python GIL fun).


> Could you propose your ideal interface for project backend ?
Since you've gone the trouble to define your own, let's just polish it
a bit instead of reinventing everything :-)


> > (and btw, even if you end up using this,
> > by all means avoid adding generic to the function name, that breaks
> > conventions).
>
> No problem, I'm trying to find good name but it's not easy.
What I meant is functions like anjuta_project_group_get_node_from_file,
(and your proposed anjuta_project_generic_node_new) : we don't actually
have an AnjutaProjectGroup class, so these function end up incorrectly
namespaced in G-I as Anjuta.project_group_get_node_from_file

------
So I spent this weekend trying to implement a sample project backend
in Python, fixing what crashed on me in the process. I ended up with :

 13 files changed, 292 insertions(+), 575 deletions(-)

(this includes removing leftovers from GObject/GBoxed tests)

In the end, I found myself hacking on the project manager itself, but
before I can start sending patches, I need to better understand how it
works.

Trying to debug a crash I found this function:

AnjutaProjectNode *
anjuta_pm_project_add_group (AnjutaPmProject *project,
AnjutaProjectNode *parent, AnjutaProjectNode *sibling, const gchar
*name, GError **error)
{
        AnjutaProjectNode *node;
        
        g_return_val_if_fail (project->project != NULL, NULL);
        
        pm_project_push_command (project, ADD, parent, sibling,
ANJUTA_PROJECT_GROUP, NULL, name);

        return node;
}

No need to explain why using the returned node crashes Anjuta. Still,
I can't see a good way to implement this : the fact that the real work
is done in a separate thread, I can't see how to return a meaningful
result from here. And since the project manager interface implementation
relies on this method, we'll need to either rewrite it to compute the
GFile differently or somehow make it async (but the latter seems to be
much work without much benefit).

Which brings us to another problem with threads : the Python Global
Interpreter Lock (GIL). Most time I spent was fighting the GIL as
I seem to see behaviour I can't understand : one thread released the
GIL but another is still blocked waiting for it.
Activating another Python plugin seems to "unblock" things a bit, but
this isn't something that really solves the problem. From googling,
it seems that the new GIL implementation in py3k can solve the problem,
but can we rely on that either?

Because of this, I'm about to give up writing a project backend in
Python, but I still think improving the GI annotations was worth the
effort. I'll try to split the changes I have into smaller commits
before sending patches.

Regards,
Abderrahim