GNOME.org
 

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

Hi,
Thank, I think I have a good view of the possibilities now. I think I need to look some code and see with other Anjuta developers what can we do. 


Le 27/06/2013 10:35, Dodji Seketeli a écrit :

Well, GCC also has an extensive "library" functions set that is comparable
to what GLIB offers in terms of containers and things like that.
I respectfully disagree here :-) The containers of libstdc++ have
properties like compile-time type checking that GLIB won't have
tomorrow.  And to me, that's a killer feature.
I don't think the containers of GLIB are better and I cannot argue that it's better to have run time check. My point is that we are in a better situation than GCC because we don't have to maintain our containers, they are part of GLib. 

To make it more clear, I will try to explain it with a few equations:
  You have told:  C++ > GCC
  I have replied: GLib > GCC
  You reply:    C++ > GLib
                C++ - GLib = killer
  I reply:      C++ > GLib > GCC
                C++ - GLib = good
No real disagreement, only a different evaluation function and I agree with all advantages of C++ that you have listed. 



Yeah, at the risk of
repeating myself, I guess you must have noticed by now that I really
want that compiler buddy to assist me with this type-checking business
;-)
I understand and I appreciate this too. Perhaps, I have used much worst language (TCL by example which has no compiler) so I think the C compiler is already doing a good job. 



Do you think that are much more resource on Gtk+ to do all tests?

Well, testing in Gtk+ is certainly an open issue I'd say.  :-)  Other
than that, I don't really know how to answer that question.


I was kidding a bit.



OK, that was an exercise in sophism -- even if I think there is some
amount of truth in it ;-).  I apologize.  My point is that I prefer
doing that check at compile time (at the expense of an extended compile
time -- that toolchain people are working to reduce by the way) rather
than relying on runtime checks.


I do not prefer to do check at run time neither :)



Not only is the toolchain not mature at all (the debugging experience
for instance is a joke to me), but the tool falls short in the
reuse-of-C department.  As things stand today, I'd choose C++ over Vala
any day -- if the question is to e.g, progressively convert the C code
base of Anjuta to something else, as this is what I was talking about.
I fully agree with you. I think debugging is really important and it takes quite a long time to support C++ correctly. I agree that it's fine now. I don't know when we could get something working for Vala but I'm afraid not in a near future.
I will not support the idea of writing the core of Anjuta in Vala but it correspond roughly only to libnemivercommon, all functions are provided by plugins. As Vala uses GObject, we already have plugins written in Vala, like support for Vala itself. 



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


I have never said that I wanted to write code *that* faster.  I want to
write code as fast as I can, but not faster.  ;-)
Yes, it is a purposely misunderstanding of "using your time in an efficient way". I see where you put the balance and I rather agree. But other people prefer different trade-off. I think it's interesting to allow them to write an Anjuta plugin using a dynamic languages, especially as it costs almost nothing to us, except perhaps not using C++ :). 



We use GDL(mm) in Nemiver already, so yeah I am not opposed to that
chasing and fixing bugs in GDL.  The real prerequisite is to understand
the code somehow ;-)
I have improved the documentation recently, but I don't really like to write it so it is deficient. It's on my todo list but I could find more interesting to try interfacing Nemiver and Anjuta or do something else, we have plenty of bugs to fix too. 



Do you agree to add more features in Nemiver code base even if they
are not really useful for Nemiver itself?

Of course yes.  I guess it'll have to be decided on a case by case
basis.


Sure.



I disagree.  It does lead to more bugs.  If you have to write it, you
can write it wrong.
Yes, on the principle, I agree but the code usage is important. I don't believe that you have as much bugs by line in a multi threads part and in boilderplate code. 



*But* you guys have it in place
already so there is no more issue there.  The paragraph you are replying
to was meant as a general statement about GObject boilerplate.  Not
something directed at Anjuta specifically.
The point is that if you use Anjuta to write your program, Anjuta can generate this code for you (like the C++ compiler if you want). Then you can still edit it an add errors which is not the case with the C++ compiler but it's still an improvement even if personally I don't use it. 



I disagree again.  Why do you need to see the thing if you never have to
interact with it?  This is a case of abstraction failure to me.
You need to understand it because it has an effect in your code. Then you can learn a list of rules to avoid unexpected behavior but I think it's better to understand how it is working to deduce the issues that you can hit. 



Generally speaking, the ABI for libgdbmod would be tied to the
nemiver::IDebugger interface (API).  So if you wrap IDebugger into a
GObject thingy, then you wouldn't have to worry about libgdbmod itself.
You'd just use IDebugger.  And tomorrow when there is a new debugger
backend (other than GDB) that we need to support, you'll get its support
'free' when someone write that libnewdebuggermod that exposes the
nemiver::IDebugger interface.

So really, I don't thing it's a good idea to consider libgdbmod itself.
I think libgdmod implement the IDebugger interface, so I can use it after rewriting the DynamicModule part of libnemivercommon and it will work if another backend is implemented. Anyway, I have enough information at the moment, I need to look at the code and understand it to go further. 



* No need for bindings for using GObject libraries.

Well, with some compiler support to expose the API/ABI of a library
(written C or C++) in a serialized and easily consumable form (maybe
something like XML), you wouldn't need GObject for this, would you?  OK,
granted, you don't have such support today, but you never now.  I am
just asking the question to see if we are on the same page, in theory.


I agree it should be possible without GObject in theory.



* Bindings in various language almost for free with GObject
introspection

This would be addressed by my question above.
The first point was rather the advantage of using other GObject libraries in Anjuta. While this point is the opposite using Anjuta code from other languages.
As Nemiver is an application and not a library, I understand that it's not really important. Anjuta is a bit between so it's more important. We already have a plugin written in Vala. I have written quite some time ago a Python debugger backend plugin using winpdb for Anjuta in Python. 



* Very complete set libraries well adapted to our need

Well, this is in the eyes of the beholder :-)


Yes, but you use some of them too so how many eyes do you have? :-)



I think that can be achieved by something like what I talked about
above.  If I really need that, I'd try to push the support in GCC
directly instead of doing something GObject specific only.
I think it would be quite difficult to get it here, especially if you want to make it general. GObject provides a common base and several limitations compared to plain C or C++. 



But yes, I agree that GObject instrospection is nice if you are in the
GObject world and really need dynamic languages support.
Anjuta is in the GObject world and has at least one plugin in Vala currently. Then interfacing with dynamic languages is not mandatory but I consider this at least as an useful feature. 



Hehe, we have Glib::ustring in Gtkmm that does pretty much all what you
are saying ;-) Oh, and for the utf8 handling, it uses GLIB.  Sitting on
the shoulders of giants.
Yes, that's why I have paid attention that you have compared std::string and not GLib::ustring. :) 



But at the risk of repeating
myself, C++ is the closest I want to get to C for this kind of
application development, at least.


Yes, I understand.



Then I guess if this code sharing business is taking place, given that
you want to keep C/GObject for your core and I see that as too expensive
at Nemiver's level the only path left would be to write GObject wrappers
like what the Webkit/GObject folks are doing.
No, I have not decided myself yet, I have written it at the beginning on my previous mail.
I need to look at Gtkmm to see how C and C++ are mixed. But I see no big issue, except doing it, to write a wrapper around Nemiver. Adding C++ inside the core of Anjuta will need an agreement among other Anjuta developers. 


Best Regards,

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