GNOME.org
 

Re: [anjuta-devel] Sharing code between Nemiver and Anjuta

Hi Dodji,
That's a long but interesting email to understand your point of view. I have tried to clarify my position and I have a few questions. I have not decided anything for the moment. 


Le 23/06/2013 13:27, Dodji Seketeli a écrit :

For the record, Jonathon Jongsma, the Nemiver co-maintainer had this
discussion with you guys a few years ago and it didn't went far,
mainly because we are in C++ and you guys are in C/GObject;


Yes, I remember this, I'm checking how things have changed.



It's not impossible for Anjuta to use UI elements from Nemiver, but I
think it's important to understand that the they are tied to the
nemiver::IDebugger (C++) interface of the debugger backend.
I think I understand it. Nemiver architecture is quite similar to Anjuta, Anjuta has a IAnjutaDebugger interface too, the main difference is that Nemiver is using C++ while Anjuta is using GObject. 



Heh.  I wouldn't have proposed that myself, by fear of sounding maybe
unfriendly to my peers who have sunk so much of their time in the
current Anjuta's debugger  :-)
Don't worry, I have done most of the work and I know that people have different opinions. 



More seriously though, just speaking for Nemiver, I wouldn't go for an
IPC based way to do this.  I'd rather embed the relevant Nemiver bits
via a C++ library.  If you guys still don't want to switch to c++,
then it'll take devising a C/GObject wrapper around that library.
I agree with that. We already use gdb through IPC and it needs quite some code. 



But really, maybe you guys should consider switching progressively to
C++.  If even GCC did it, I think it can be possible for Anjuta.
It's a much more important topic than just using Nemiver code inside Anjuta. I understand your point and I agree that it's one of the two best solutions to share code, I think you can imagine the other :).
It must be done progressively but at the end, this is a big amount of work, something needing at least a few motivated hackers and an agreement of other Anjuta developers.
GCC is using only libc. Anjuta uses GLib which provide much more functions, including a lots of container objects without the need of STL. 



Yes, I think it'll need some changes, indeed.  It'll need to ironing
out of some idiosyncrasies from the interface.  And if you don't want
to switch to C++ for the Anjuta core, I guess it'll need some major
C/GOBject wrapping.  It's doable, but I don't fancy doing that myself
because I don't think that holds much value, ultimately -- and it's a
lot of work.  I won't oppose the inclusion of such a library, of
course.
I think wrapping only IDebugger interface shouldn't be too difficult. But I don't expect much improvements for the user.
The main target is rather to see how in practice we could use Nemiver GUI too. Then, if we consider that wrapping it will be to difficult anyway, I think it's less interesting. 



Just curious, what widget exactly?
I haven't any particular widget in mind. I just think about sharing the GUI instead of using only the IDebugger interface. 



You mean you are ready to use C++ in Anjuta code base?

Good question.
Yes, Scintilla is already in C++ since ages, but there is a difference between using C++ and building Anjuta on C++. 



Hmmh, actually, not exactly.  We are using Gtk+, yes, but only through
Gtkmm. I am not pushing for Gtkmm for religious reasons.  Rather, it's
ultimately to have a code base that crashes and leaks less, without
having to spend "big" amounts of time doing testing.
Yes, I see you use only Gtk+ not the whole GObject platform. I understand your point but, just out of curiosity, why do you use gtkmm instead of Qt if you think C++ is much better?
I have the impression that gtkmm has less maintenance than Gtk+ and you need a few additional conversion to pass some data.
Moreover, why do you rely on a library, Gtk+, written using C and so having more crashes and leaks? Do you think that are much more resource on Gtk+ to do all tests? 



For instance, having the compiler tell you straight away that the
"data" argument that you passed to your signal handler is of the wrong
type (for instance, after you did some refactoring) is a huge
improvement over silently overlooking that until you users experiment
the inevitable resulting crash down the way is a *huge* selling point
in my book.
This is an improvement for sure but I think I spend much more time thinking and checking corner cases than fixing type errors. I agree that it's difficult to evaluate because it has some additional consequences. You need more time to find an error at run time than at compile time, refactoring will need a bit more time too.... On the other hand, compiling C++ takes more time and GLib is doing quite a lots of checks at run time. 



And having that, while sitting on the giant shoulders of
C, in such a way that you can just copy-paste code from C code bases,
compile it and use is w/o *needing* to wrap feels like another silver
bullet.  And of course, we can rely on a mature and versatile
toolchain these days.


Yes, but C is even better in this regards and the toolchain is more mature.
Another option is vala, the toolchain is no very mature, but I think it's easier to write than C++.
Then gobject introspection provide this advantage to quite common languages like javascript or Python. And if you want to write code faster, I think it's a much better option than C++. 



Yeah.  Assuming we can devise a library for the stuff you guys find
worthwile, if there is value for Nemiver to use that library, I'd be
glad to have a library external to Nemiver, that Nemiver depends on.
Anjuta could then depend on that same library, too.
Good but it's not very useful for Anjuta unless people from Nemiver work on this library which has to be in C. Are you willing to program or fix bugs in C for a library used by Nemiver? GDL by example? 



Nemiver is indeed organized around dynmods (short name for
DynamicModule s).  A dynmod exposes an interface that is a C++ header
that contains classes that are only pure interfaces, or classes with
inline functions only.
Yes, I have seen. Anjuta uses something similar, the user code has only to link with libanjuta and can load any plugins. It uses GObject macros and we need some boilerplate code though. But, this code is not maintain by us and provide more features: interfaces defined at run time, binding in various languages.
Moreover the code handling plugins in Anjuta is more powerful than the DynamicModule of Nemiver, the module are selected based on their interface but we could add additional attributes, like supported mime type for a file loader plugin, we handle dependencies between plugin, various profiles.
These additional features are probably not useful for Nemiver but they are needed by Anjuta. Do you agree to add more features in Nemiver code base even if they are not really useful for Nemiver itself? 



Yes, I am not a fan of GObject at the application development level
because the macro soup that comes with it makes it too error prone,
leading to a more crashy user experience than I'd like to accommodate.
Obviously there is much less type checks are compile time but there are quite a lots of checks are run time, it makes the code a bit slower but it allows to detect most issues. 



Nemiver thus defines a lot of ad-hoc types.  It's as easy as doing
class foo : some_base class {};  No GObject boilerplate shit.  But we
do use a lot of libstdc++ and gtkmm types, too.
Boilerplate code is a bit annoying to write but it could be partially generated (Anjuta do it) and it is quite straight forward, I don't think it leads to more bugs. One advantage is that you can see it, while in C++ this code mostly exist but is generated by the compiler directly in assembler. 



As I implied above, what the client consumes is not libgdbmod.  It's
rather the interface it exposes, which is nemiver::IDebugger.
Yes, but nemiver::IDebugger is a C++ interface while I need a GObject interface currently. So I think one option is to load libgdbmod and wrap it inside a GObject. Do you see an issue with that? Do you agree to keep a stable ABI for libgdmod? 



I am not interested in consuming GObject at the application level in
Nemiver because from where I sit today, and seeing all the advantages
we are experiences from using a C++ interface like IDebugger, I hardly
see any value in going back to something as low level as GObject.
I'd like to hear opinions that would proved me wrong, though.
I see GObject at a higher level that C++ object, it provides much more features and is quite close to object in dynamic languages. I think it has some advantages compared to C++: 

* No need for bindings for using GObject libraries.
* Bindings in various language almost for free with GObject introspection
* Very complete set libraries well adapted to our need
Then, I agree that C++ write most of the boiler code for you and do much more type checks at compile time. 



Just curious; there are scripts that generate C/GObject wrappers from
a C++ interface?
Currently, I think none. So it's more difficult for Anjuta to re-use Nemiver code. We have to write a wrapper case by case or write some scripts to generate wrappers automatically.
On your side, you already have wrappers to use GObject in C++ and you use them for GDL and Gtk+ 



But, I tend to think that a C/GObject library that would wrap
nemiver::IDebugger would need to be hand crafted.  Automation is not
everything; the wrapper's interface will need to be properly designed
as well.
I have been really impressed by GObject introspection, you write some code in C and you can use directly in Python without writing anything else.
The bindings are generated at run time, so it's not very fast but it is already in Python so that's not the goal, for UI it's fine. 

Depending of the API, the library could look a bit alien but it's working.
You need to add some special comments to your functions, typically who is the owner of each object but that's not very difficult and it's even interesting to make the API unambiguous.
I imagine it's possible to write something similar for Nemiver interface. Now, I don't know how difficult it is. I need to look at Gtk+ bindings for C++. 



And get something that is more error prone, probably takes more source
code (e.g, handling strings in C vs using std::string, for a quick
shot) just to achieve the same result.  And the result won't even be
faster.

Really, unless I get some strong arguments about what we'll get as
technical superiority and robustness from within Nemiver by doing
this, I fear I won't buy much into getting back to C/GObject for
something that we /already/ have in C++ and is doing the job.
I agree with you. You will probably need more source code as you will need more boilerplate code even if you can remove some parts already done in GObject. The result won't be faster, I think GObject is slower even if it doesn't make a big difference.
I don't believe that one way is technically superior on every point, the trade-off are different. I think there are some arguments for using GObject, I have given them above but I don't believe it can justify a rewrite of Nemiver using GObject.
By the way, I think std::string is a quite good example. Indeed comparing to pure C which has a quite limited support for strings, and in particular doesn't take care of allocating the memory, std::string is a big improvement. Now comparing to Glib string functions and string object, std::string cannot handled UTF8, miss printf format string, case insensitive compare, strip spaces, escape characters... In fact, std::string is so good that I think every C++ library has written its own string class. So it's nice to have std::string but it's no really comparable to GLib, you need something else to compete. 



I am not against using C, mind you.  My willingness to re-use C is
what got me in this C++ business in the first place.  :-) But to me,
up to a certain point, the more C++ I can use at application level,
the better.
I understand your point but it makes the code of Nemiver more difficult to share as it forces people to use C++. 



Emacs is the ILE (integrated Life Environment) where I live so, as a
programmer, I am not really interested in hacking on an IDE.  But a
graphical debugger (that I launch from within Emacs everyday), I can
hack on.  :-)


Ok, personally, I prefer vi:)


Regards,

Sébastien
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]