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

[Sébastien Granjoux <seb sfo free fr>]

Hi Abderrahim,

Le 03/10/2010 23:50, Abderrahim KITOUNI a écrit :
> > (in short, I'm saying I like this part of the design)

Ok, good :)

> > Not really, for me the "bookkeeping" methods are all methods defined in
> I seems we have a different definition of "bookkeeping" ;-)

Indeed, we have several different definitions :) but that's fine.

> 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.

At least in the autotools backend, I think there isn't much difference 
between ianjuta_project_save_node (not a "bookkeeping" method) and 
ianjuta_project_add_node_after (a "bookkeeping" method).

In autotools project, the group node keeps a parse tree of the makefile. 
So calling ianjuta_project_add_node_after to add a target by example, 
will modify the parse tree owned by the parent group node. The changes 
are not local to the node.

I don't see much difference with ianjuta_project_save_node which is just 
writing the parse tree. The save function is executed in a thread 
because it writes something on the disk.

Then, you can implement these methods just by setting some flags in the 
not data but it's not mandatory.

> > 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".

I'm doing something special in the autotool project backend now.


> I think this discussion won't bring much. Let's keep them gobjects for now
> (but see below for Python GIL fun).

Ok. The new interface is committed in the new project branch and I'm not 
mainly working on the autotool backend. I think the proxy stuff is still 
not completely right but remaining should be fine.


> Since you've gone the trouble to define your own, let's just polish it
> a bit instead of reinventing everything :-)

Ok, do not hesitate to propose some polish.


> 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 it needs to be renamed anjuta_project_node_get_group_from_file. I 
have no problem with this.


> 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.

Indeed, it's completely wrong. I have forgotten this function. And as 
I'm working on the backend with a small command line program using the 
project interface I have missed this.

Before the last change in the project interface, the new and the add 
functions were different. So in this function, I was calling the backend 
to create a new node that I can return immediately and was adding the 
node later.


I haven't found a good way to handle this.

1. Remove the AnjutaProjectNode* return value:
It's an easy solution. It needs to change the class generator and the 
project wizard plugin. Both plugins still need to creates nodes, so they 
could connect on the project and get the new nodes. But, they cannot 
really know if the new nodes has been created by the add function.

2. Create a proxy node:
Create a proxy node associated with this command and return it. When the 
node is created, the proxy can be replaced by the real node. This needs 
more thought to make it works. Moreover I'm not sure it can really work 
because the class generator expect a real GFile corresponding to the 
node, only the project backend knows this.

3. Call ianjuta_project_add_node if possible:
There is a problem only if the worker thread is running, if a save or a 
load is in progress. In this case, we can wait until the thread is 
completed, I don't know if it's possible to keep the interface running 
during that time. If no thread is running, the ianjuta_project_add_node 
function can be called immediatly and return a node.

4. Call ianjuta_project_add_node immediately:
The backend needs to take care that the ianjuta_project_load or 
ianjuta_project_save function can be running. It's always possible, the 
backend can keep the add operation in a queue if the worker thread is 
running to do it when the thread is completed. But I'm annoyed to let 
this on the backend side.

5. Add ianjuta_project_new_node:
It was the solution used in the previous interface. It's not very 
different from the solution 4. It's just more easier to understand that 
ianjuta_project_new_node should be able to work even if the load or the 
save function is running in another thread. There is an issue to define 
if the new node is owned by the project (should be kept in a special 
list), the caller or floating.

Do you have another solution?



> 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?

I don't know. It's sure that I need to use thread in the project 
manager. It's especially useful to reading package content, there are 
lots of files and it takes perhaps one or two minutes on anjuta project 
here (There are lots of debugging messages too).

It's a problem that I have with Python and other script languages. A 
lots of things are much more easy to do but a few things are really 
difficult and I don't know it before I bump in it.


> Because of this, I'm about to give up writing a project backend in
> Python,

It's a bit a pity. I could move all thread functions in the backend so 
it's will not be mandatory. But I'm afraid it will make it much more 
difficult to do.


> but I still think improving the GI annotations was worth the
> effort.

Sure, I think the interface is better now (except the error above).

Regards,

Sébastien