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

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

Hi Abderrahim,

Le 04/10/2010 23:33, Abderrahim Kitouni a écrit :
> > So it needs to be renamed anjuta_project_node_get_group_from_file. I
> > have no problem with this.
> Maybe anjuta_project_node_get_node_from_file, but you see the idea.

Ok, I have called it group/target/source because I'm not sure that 
another node with a different type cannot have the same GFile object.


> > 4. Call ianjuta_project_add_node immediately:
> The fact that the project backend can be called from two different
> threads is a bit scary.

Yes, I would like to avoid this too but I haven't really a better 
solution yet.

> Right now, the GUI thread only calls
> get_node_info which is supposed to return a constant list (and even
> then, the python GIL can get in the way) but having more 'multithreaded'
> calls is asking for trouble.

Not exactly, the GUI thread can use most anjuta_project_node function, 
like anjuta_project_node_get_file, anjuta_project_node_first_child...


> > 5. Add ianjuta_project_new_node:
> This can reasonably be done, making new_node another 'constant return'
> method. However, the node should definitely be owned by the caller : it
> makes it easier to avoid memory leaks (at the cost of one added
> g_object_unref call).

That's fine for me if the node is owned by the caller. The issue is that 
I would like to have only a single owner for each node. I don't know how 
to enforce this with GObject. Most of the time a node is owned by the 
project which can change it at any time (in a thread). Creating a node 
not owned by the project will be useful in such case to be sure that the 
project will no change it.

The closest thing possible can be to return a floating node with 
ianjuta_project_new_node and get the project get a reference on it only 
when ianjuta_project_add_node is used. It's possible in Python and quite 
simple in C. But it's still possible to add additional reference on the 
node and keep them after adding the node in the project which I would 
prefer to avoid.

Another issue is that ianjuta_project_new_node is node not really a 
constant return. The plugins using this function needs the GFile 
associated with the node, this GFile depends on the parent of the node. 
So ianjuta_project_new_node needs the parent and will at least read it. 
It's possible to make it works but it needs some care.


> 6. Make the function async, that is, pass a callback to the pm method,
> and the callback will be called when the node is ready to be used. The
> problem with this approach is that it can make things look like the user
> command was ignored when saving/loading takes too much time.

Yes, moreover it's more difficult to use and I think callback could be 
annoying for bindings too.


> This seemed like a lot of wasted time for me. What do you mean exactly
> by 'reading package contents'?

It means make the list of all files in all directories needed by a 
package (the .pc file in the lib/pkgconfig directory).


> But thinking again about it, maybe we can do without threads. This may
> look like a crazy idea, but it may work after all. It seems that the
> autotools backend reads one makefile at a time, so it might be not that
> bad (maybe by using async gfile methods for not blocking in I/O, but the
> rest should be fine).

I don't think it's a crazy idea but the project manager is already quite 
slow, currently the packages are already loaded in thread (inside the 
symbol-db plugin) and the CPU trend is clearly to have more cores. I 
think it must be possible use thread for a project backend.

Then, we can make possible to implement the interface with a thread. Or 
you can use processes instead of thread. The current GBF interface load 
the project with perl script running in a different process and exchange 
data with XML file. I think it's quite complex but perhaps something 
similar can be done in python.


> > 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.
> Right. What would be even more difficult is changing the current
> implementation.

While I'm replying to this mail, I think that probably the interface is 
not right now. It needs too much explanations. I have a new proposal.

Remove all thread stuff from the project manager and move it in the 
backend part. I suppose I can move this stuff in libanjuta and avoid 
duplicate code anyway. But, it means using thread is not mandatory and I 
don't have to split add_node and new_node function. I could keep the 
same interface than now, just that all functions, including load_node 
and save_node are called in the GUI thread.

It must be possible to use threads to implement these functions. So 
returning from ianjuta_project_load_node doesn't mean that the node is 
loaded (and same for ianjuta_project_save_node).

Perhaps, I can rename the node_updated signal to node_loaded signal, 
emitted when the node is loaded. Note that some of its children can be 
not fully loaded.

Currently, the project is automatically reloaded if the project files 
change on disk and the node_loaded will be emitted when the load is 
completed. Should we have another signal like node_changed and wait for 
a ianjuta_project_load_node call to reload the project ?

Do we need a node_saved signal ?

Instead of those signal, we could use callback, for node_saved that's 
fine. For node_loaded, it's not so obvious because it's nice to have 
this signal as soon as possible, when a part of the project is loaded, 
and still be able to get for other nodes which need more time to be loaded.

What do you think ?

It's will change the interface one more time but I have already changed 
it so many time. Anyway, I would like to progress on the autotools 
backend, so I will not change it immediately.

Regards,

Sébastien