Re: [anjuta-devel] Code assistance plugin

[Jesse van den Kieboom <jessevdk gnome org>]

2012/5/10 Sébastien Granjoux <seb sfo free fr>

Hi Jesse,


Le 10/05/2012 13:08, Jesse van den Kieboom a écrit :

Sorry for not replying earlier to this thread, I hope I can still
provide some useful insights.

Thank for your answer, it is really interesting. I have sent several messages to get some reaction but there is no urgency.

It's true that currently gcp contains the binding with
gedit. But it also contains an infrastructure which is used to implement
the backends, which is mostly (but not completely) independent from gedit.

I have looked a bit at gcp and it's useful to have such library. There isn't really such thing in Anjuta perhaps because a part is using the symbol-db plugin which handle all languages in the same way using ctags. But each language support plugin re-implement some common parts for sure.

So you think it could be changed to be completely independent of gedit and gtksourceview?

It should not be very hard to separate at least the interfaces part, by which the backends communicate their functionality. I guess the main thing is that current Gcp.Document contains a Gedit.Document, simply because it was easier that way. But I think we can move that outside.

 

Yes, and that is a shame! You should consider using libpeas :)

libpeas appears several years after the plugin system in Anjuta. I don't really see advantages to switch to libpeas. I'm even afraid that some feature will be missing.

I see a lot of advantages. libpeas really releases the burden of managing a complete plugin system (in GObject C). Furthermore, it uses gobject introspection which allows it to very easily support multiple languages if those languages support gobject introspection. More important though, we can focus development of this now on just one library, instead of having each application implementing their own system. Many GNOME applications have switched to using libpeas now and it works great. Another great thing is that having a common library for plugins is also going to allow us, for example, to write a common remote plugin repository which all applications using libpeas can then benefit from. At last, there is no reason to be afraid. If some feature is missing, we can implement it, it's open source after all :)

 

The way we try to manage this a bit is by slowly merging
functionality that was developed as a plugin (because it's just much
faster) in a library (most notably gtksourceview). This library can then
be easily reused, given it exposes the proper API.

Using a plugin is not more difficult than a library and it is more flexible. By example if you merge everything in gtksourceview, we will have to re implement it for Scintilla.

There are a few things here that I think are wrong argumentation. First, I think using a premise that you want to support both gsv and scintilla is not fair. To me this seems a really unnecessary feature. Just choose one and stick with it. If you don't like the feature set of one of those then choose the other. You can abstract every single piece of code, but a one-fits-all approach is almost never a good design. The problem with plugins is that you can usually not easily reuse them, that's all. Merge it in a library that multiple people can use is definately the way to go. A single place to maintain.

 

1) Make it a very shallow wrapper around libclang. This can be done, but
is it really interesting to do? If you use vala you can simply use the
.vapi file that I wrote and you can access all the libclang API in an
object oriented way from vala, no GObject needed. Also, there wouldn't
be any code sharing really, the shallow bindings would not be where most
of the work is done.

I'm agree. We can use such library without troubles but the gain is small, I'm even not sure it worths it. Especially because clang is already designed as a library, so we don't need a complex wrapper.

2) Make a common abstraction layer for these kind of compiler services
which can be reused by multiple projects. This is much more interesting
in the end, but also much more difficult to do. I think it will be
difficult (but not impossible) to merge the ideas from Anjuta and from
gcp into a library providing a standard API/interfaces for building and
using language assistance. These interfaces should then be used by both
projects.

Ok, we can try to define something like this. I'm not really working on it currently and I haven't write the language support part in Anjuta. I have started the discussion because we have one GSoC student, Moritz, working on it.

Ideally, neither project would have their own abstraction
layer on top of this library because abstractions of abstractions ==
bad. I know Anjuta kind of likes this (i.e. having support for both
Scintilla and GtkSourceView), but I really, really strongly feel this is
the wrong way to go (do you like wxWidgets?).

I don't see it like this. I don't think that less abstractions is better, I think we need the right quantity of abstraction. If we haven't abstract Scintilla, the use of GtkSourceView would have been really difficult, it would have been a pity, no?

No, I don't think so. Yes, maybe it would have taken a bit more time to migrate from scintilla to gtksourceview, but on the other hand, you spent time now to write the abstraction layer and to maintain it so you have a common denominator for two widgets which provide different functionality. Then you need to not just have the abstraction layer, but also an implementation layer translating from the abstract concepts to the concrete backend implementation. I agree that you need the right quantity of abstraction, but I don't agree with your idea of the "right quantity" :)

 

I'm probably the main responsible for keeping Scintilla working in Anjuta. I see an IDE rather as just some glue allowing you to use existing tools (editor, debugger, make...) in an easy way. So I think it makes sense. If you see GEdit as an editor around GtkSourceView, like SciTE for Scintilla, indeed it is less useful.

I agree mostly with your view of an IDE, it's even in the name "Integrated" development environment. It should integrate several components together. This does not mean however that you need to integrate all possible things together. Again, having two widgets for text editing doing almost the same is in my opinion useless. You only need one tool for each task, if there are more than one, then you pick the one you think is the best.

 

1) I read about rewriting parts of the gcp plugin to C, this is a _bad_
idea. Use vala, really. It's not really worth it anymore to write these
kinds of things in C, the boilerplate is mindboggling. vala will compile
nicely to GObject C, you can generate a .gir for you lib and generate a
gi typelib, then use your vala library from any introspection supported
language.

For me, C is already a high level language. Comparing to vala, the additional codes is tedious but not really difficult to write. Moreover it is still easier to compile C than vala at least using autotools, I imagine debugging could be easier in C too.

Well, please tell me what language (other than assembly and punch cards) could be more low level than C. I'm sorry, but C is really not a highlevel language. Don't get me wrong, I love writing in C, if it suits the task, but we have better technologies now that allow you to be far more productive. Vala is completely integrated in autotools (http://www.gnu.org/software/automake/manual/html_node/Vala-Support.html) and works fine. You can have a look at the gcp autotools setup. Debugging with gdb is probably easier in C because vala translates in a bunch of C which then doesn't easily translate back into the original source. Then again, you will have far less use of a debugger with vala anyway because it has better compile time checks (static analysis) and memory management.

 

2) Don't shun from thinking about collaborating on this. I know how this
normally goes (I do this myself), it's much easier to just write a
little plugin using clang to use just for Anjuta. But in the end we'll
be maintaining two things separately. Now is the time to think about how
to provide general compiler services for GNOME applications. Having a
common library we could even think about writing dbus services to
organize things globally at some point.

Ok. I think that such library should be independent of obviously Gedit and GtkSourceView too as it would be useful for Scintilla. Do you agree with this?

Independent of gedit, yes. Independent of gtksourceview, I'm not so sure. We are trying to build applications for the GNOME platform and use GNOME technologies to do it. Adding abstractions for other toolkits is in my opinion not interesting and will just lead to more duplicate code and more artificial constructs than you would need otherwise.

 

Currently in Anjuta, all interfaces and the related code in contained one library: libanjuta. We could probably add this libgcp library too.

I would not merge it into libanjuta, because then other people need to depend on libanjuta and will get all the anjuta specific things as well. It should be a standalone library in my opinion.

 

3) I saw some ideas of merging the gedit and Anjuta applications. This I

think will not really be possible.

Ok.

4) I've noticed some performance and memory issues with using libclang.

It looks like clang is used a lots but I have expected a much better documentation. I have found mainly tutorials using different version libclang. So I'm not surprised.

Yes, the lack of documentation is a bit worrysome. It seems like it's not really a completely endorsed project from llvm, so I don't know if we should rely on it completely. There are probably some things we can improve if we write our own version of libclang, like not having to copy whole text buffers or better caching of translation units of sources that have not changed.

 

Regards,

Sébastien