Hi all,
In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. The pros and cons likely will be slightly biased since I would obviously like to use Vala in Geany, but here they are anyway:
Pros: -----
* Power of high-level OOP language using existing GObject backend with no C boilerplate required * Uses same type-system as existing C code * Automatic memory management * Clean expressive syntax (foreach, as, properties, signals, async, etc.) * Exceptions (which uses C/GError-style exceptions in generated C code) * No extra dependency for release users (generated C code can be shipped) * Can generate Gobject-Introspection bindings automatically allowing use from a bunch of cool languages like Python, JavaScript, etc (and as many other languages as support Gobject-Introspection) for plugins. * Easy to learn for anyone who's used C++, Java, C#, etc. * Uses all existing dependencies as its runtime library (ex. GLib/GIO). * Can generate C/H code that is usable from within existing C code, so no requirement to completely re-write, can just add on modular code as needed. * Can be tuned to output optimized C code, or call optimized C code quite easily * Can sometimes generate clever and/or optimized code that would be tedious to write in C. * Has Autotools and Waf support already, and using from plain GNU Make is trivial. * Actively developed and supported, and having active mailing list and IRC channels. (ex. it's easier to submit a patch to Vala language than ISO C). * AFAIK it generates C89-compliant code :)
Cons: -----
* A fairly new language (since 2006). It's hard to argue against this, but also impossible to move forward without adopting new stuff at some point. * Some dark corners/bugs due to being such a new language (compared to C/C++). * Actively developed so sometimes we probably have to require specific valac versions to support certain features (ie. nothing like c89, c99, c++98, etc but not unlike supporting newer G* versions). * As with above, may require to use fairly modern/specific dependency versions of the G* C libraries (ex. might not work on RHEL or some other LTS distros). * Extra dependency (valac) for maintainers/developers. * Using non-GLib-based libraries requires to write boring but trivial binding .vapi files (not huge deal for existing Geany code). * Can sometimes generate heap-heavy or non-optimized code. * Can sometimes generate C code that causes warnings with common compiler warning flags, would require to disable some compiler warnings on generated C code to have a completely clean build (ex. use -w on all .vala code) * The documentation isn't as great as an ISO language that existed since forever. The official language specification isn't as complete or fleshed-out (ex. has TODOs) as an ISO language. There is lots of documentation out there, for example on the official Wiki, but it's still no substitude for definitive language reference and decades of books/literature on the subject. * More people know C than C++/C#/Java (ie. style of Vala). IMO, this one is untrue since people who use C nowadays are either well-versed embedded programmers who already know the higher-level stuff, C/Gobject/Gtk+ programmers who already know or can easily understand how the higher-level stuff works (ex. by looking at generated C code), high-level-only programmers who for the most part don't need to care about how the underpinnings work and already would know Vala since it's basically C#(/Java), or finally, and I believe the least likely; complete n00bs who would be much safer writing garbage in any high-level language than directly in something like C/C++ anyway.
For more information about Vala, this a good starting point:
https://wiki.gnome.org/Vala/Documentation
If we can cleanly get more +1's than -1's (in principle, and especially from the core developers and active contributors), without wandering off into nitty-gritty details, version-specific bugs encountered that don't/won't specifically apply to Geany, stuff I have specifically accounted for in the pros/cons list, and minutia like we (especially ME) always do, then we can move forward with this and hammer-out those details later during integration, rather than stifflying the idea here in this thread as we (including ME) often do. If one or more of the things you like or dislike is already mentioned, there's no point in specifically responding to it unless you think it's unclear or inaccurate, just give your +1/-1 and see where it goes.
Basically what I'm saying is that if we can keep this discussion on track and people show enthusiasm (or at least not strong distain, in principle) then I will personally volunteer my time to make it happen. If it turns into a zillion message thread about off-topic, or nitty-gritty stuff (which should occur later on, in a different thread) or hate from people who have never tried the language in earnest but still have a strong anti-opinion (especially based on old or presumed information, or general hate for the G* toolkit we already use), then I probably will just forget it, and probably no one else will move this forward.
P.S. Sorry for stupid-sounding discussion rules, it's just an attempt to move something useful forward, productively, with consensus, without wasting our voluntary time discussing deep details too early-on, and based on past similar discussions on this list and knowledge I have about some poeple's existing opinions. Please don't take offense or rant about the stupid "rules", just believe I'm sincere in that I'm trying to organize the discussion more productively than usual (even if failing) :)
Cheers, Matthew Brush
On 10 November 2013 15:44, Matthew Brush mbrush@codebrainz.ca wrote:
Hi all,
In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. The pros and cons likely will be slightly biased since I would obviously like to use Vala in Geany, but here they are anyway:
To help allay your concern about bias I have commented on a few below :)
Pros:
- Power of high-level OOP language using existing GObject backend with no
C boilerplate required
- Uses same type-system as existing C code
- Automatic memory management
Reference counting, not memory management, ie non-cyclic structures only, fine for GTK GUI structures, but not any old structures. And of course it only applies to structures that support reference counting, not simple types as used in most of Geany.
- Clean expressive syntax (foreach, as, properties, signals, async, etc.)
- Exceptions (which uses C/GError-style exceptions in generated C code)
Existing Geany code is not exception safe so this can't be used until all existing code is changed, see the C++ discussion for details.
- No extra dependency for release users (generated C code can be shipped)
But is unusable since its machine generated, ie we can't tell how it will change from Vala version to version, leads to problems like the Glade commit noise if its in the repository, but maybe it could be in the tarballs. But of course you can't fix anything without vala since you would need Geany from git.
- Can generate Gobject-Introspection bindings automatically allowing use
from a bunch of cool languages like Python, JavaScript, etc (and as many other languages as support Gobject-Introspection) for plugins.
But only for those parts of Geany that are gobjectified, which is almost none ATM, Geany object only IIUC.
- Easy to learn for anyone who's used C++, Java, C#, etc.
Its got {} so it *must* be the same (sorry :) in the end its just another object oriented language with its own quirks.
- Uses all existing dependencies as its runtime library (ex. GLib/GIO).
Good point.
- Can generate C/H code that is usable from within existing C code, so no
requirement to completely re-write, can just add on modular code as needed.
But heavily restricted Vala code because it has to interact with existing C code, much care needed.
- Can be tuned to output optimized C code, or call optimized C code quite
easily
- Can sometimes generate clever and/or optimized code that would be
tedious to write in C.
*All* code is tedious in C/C++/Java/ etc :)
- Has Autotools and Waf support already, and using from plain GNU Make is
trivial.
How well does the windows version work, is it up to date, since it includes Glib and GTK which versions are they, and do they match ours? The binaries for windows vala available seem to be 0.12, even my LTS Linux has 0.14, 0.16 and 0.18 valac available, more version hell and windows issues :(
- Actively developed and supported, and having active mailing list and IRC
channels. (ex. it's easier to submit a patch to Vala language than ISO C).
- AFAIK it generates C89-compliant code :)
Cons:
- A fairly new language (since 2006). It's hard to argue against this, but
also impossible to move forward without adopting new stuff at some point.
And not yet complete (by its own admission).
- Some dark corners/bugs due to being such a new language (compared to
C/C++).
- Actively developed so sometimes we probably have to require specific
valac versions to support certain features (ie. nothing like c89, c99, c++98, etc but not unlike supporting newer G* versions).
More version hell, just what we don't need.
- As with above, may require to use fairly modern/specific dependency
versions of the G* C libraries (ex. might not work on RHEL or some other LTS distros).
So how do we handle windows? Of course we could drop it :)
- Extra dependency (valac) for maintainers/developers.
So long as its a version thats in LTS repos and has available binaries for windows that doesn't matter.
- Using non-GLib-based libraries requires to write boring but trivial
binding .vapi files (not huge deal for existing Geany code).
Well, you already have done that for the plugin API IIUC, but still would be needed for the rest of Geany.
- Can sometimes generate heap-heavy or non-optimized code.
So does some of our C code ;) I doubt its a significant issue.
- Can sometimes generate C code that causes warnings with common compiler
warning flags, would require to disable some compiler warnings on generated C code to have a completely clean build (ex. use -w on all .vala code)
Ok if autotools and waf do that for the vala C code, but the existing Geany C code still needs pedantic settings.
- The documentation isn't as great as an ISO language that existed since
forever. The official language specification isn't as complete or fleshed-out (ex. has TODOs) as an ISO language. There is lots of documentation out there, for example on the official Wiki, but it's still no substitude for definitive language reference and decades of books/literature on the subject.
The draft manual at https://wiki.gnome.org/Vala/Manual is a good deal better than the "official" version, it looks almost usable.
- More people know C than C++/C#/Java (ie. style of Vala). IMO, this one
is untrue since people who use C nowadays are either well-versed embedded programmers who already know the higher-level stuff, C/Gobject/Gtk+ programmers who already know or can easily understand how the higher-level stuff works (ex. by looking at generated C code), high-level-only programmers who for the most part don't need to care about how the underpinnings work and already would know Vala since it's basically C#(/Java), or finally, and I believe the least likely; complete n00bs who would be much safer writing garbage in any high-level language than directly in something like C/C++ anyway.
I don't think it matters how many know it, how many are willing to contribute is the issue, and with a mixed language application it needs two languages.
And that leads to what I consider is the biggest problem with the proposal, having a project with parts in one language and parts in another. Maintaining assumptions between them, some made by the vala compiler, some made by C coders, is going to be hard and a source of extra problems and bugs. That alone is enough reason to not just start piling vala onto the existing Geany.
If there is really enough reason to change to vala I would suggest that the right way to do it is to define interfaces between those parts of Geany that are going to stay C for the foreseeable future, eg Scintilla, tagmangler etc and create vapi definitions for them. Then build the basic skeleton of the app in vala, calling the C parts as required. Its not as immediate as allowing random parts to be written in vala but is likely to be much more effective in moving the project forward, and ATM thats what Geany really needs, a good spruce up so new things can be more easily added.
Cheers Lex
PS we discussed the inappropriateness of +-1 as a reply to something this complex on IRC, won't repeat here.
[...]
Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13-11-09 10:49 PM, Lex Trotman wrote:
On 10 November 2013 15:44, Matthew Brush mbrush@codebrainz.ca wrote:
Hi all,
In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. The pros and cons likely will be slightly biased since I would obviously like to use Vala in Geany, but here they are anyway:
To help allay your concern about bias I have commented on a few below :)
Pros:
- Power of high-level OOP language using existing GObject backend with no
C boilerplate required
- Uses same type-system as existing C code
- Automatic memory management
Reference counting, not memory management, ie non-cyclic structures only, fine for GTK GUI structures, but not any old structures. And of course it only applies to structures that support reference counting, not simple types as used in most of Geany.
Reference counting is a valid memory management strategy used in many languages like C++ or Python. Vala handles this fine and provides ways to break cycles or such as expected, and more often than not it's not even a concern while programming in Vala itself.
- Clean expressive syntax (foreach, as, properties, signals, async, etc.)
- Exceptions (which uses C/GError-style exceptions in generated C code)
Existing Geany code is not exception safe so this can't be used until all existing code is changed, see the C++ discussion for details.
Vala exceptions, as mentioned used GError result/out parameters, so there's no change from existing code.
- No extra dependency for release users (generated C code can be shipped)
But is unusable since its machine generated, ie we can't tell how it will change from Vala version to version, leads to problems like the Glade commit noise if its in the repository, but maybe it could be in the tarballs. But of course you can't fix anything without vala since you would need Geany from git.
It means users who are only compiling Geany don't have to install valac, even though it's quite widely available. As usual, if they want to hack on Geany they will need a full development environment including current sources from Git.
- Can generate Gobject-Introspection bindings automatically allowing use
from a bunch of cool languages like Python, JavaScript, etc (and as many other languages as support Gobject-Introspection) for plugins.
But only for those parts of Geany that are gobjectified, which is almost none ATM, Geany object only IIUC.
Which is partially the point of this discussion, simple Gobjectification of Geany's code, without the crufty boilerplate of Gobject/C, moving forward.
- Easy to learn for anyone who's used C++, Java, C#, etc.
Its got {} so it *must* be the same (sorry :) in the end its just another object oriented language with its own quirks.
Yeah, but it's pretty "normal" if you've used any of the simiar-ish languages. It's nothing new or revolutationary (see Haskell) :)
- Uses all existing dependencies as its runtime library (ex. GLib/GIO).
Good point.
- Can generate C/H code that is usable from within existing C code, so no
requirement to completely re-write, can just add on modular code as needed.
But heavily restricted Vala code because it has to interact with existing C code, much care needed.
No, it just generates C/Gobject code like you'd do by hand, just without writing tons of boilerplate.
- Can be tuned to output optimized C code, or call optimized C code quite
easily
- Can sometimes generate clever and/or optimized code that would be
tedious to write in C.
*All* code is tedious in C/C++/Java/ etc :)
Meh, some higher level features are possible (closures, asynchronous methods, garbage collection, etc) in lanugages above C++. With Vala you pay the least amount of cost for it (given existing code), IMO.
- Has Autotools and Waf support already, and using from plain GNU Make is
trivial.
How well does the windows version work, is it up to date, since it includes Glib and GTK which versions are they, and do they match ours? The binaries for windows vala available seem to be 0.12, even my LTS Linux has 0.14, 0.16 and 0.18 valac available, more version hell and windows issues :(
See current issues WRT Windows binaries, not much change with Vala, just one more binary application to track version of.
- Actively developed and supported, and having active mailing list and IRC
channels. (ex. it's easier to submit a patch to Vala language than ISO C).
- AFAIK it generates C89-compliant code :)
Cons:
- A fairly new language (since 2006). It's hard to argue against this, but
also impossible to move forward without adopting new stuff at some point.
And not yet complete (by its own admission).
But completely usable.
- Some dark corners/bugs due to being such a new language (compared to
C/C++).
- Actively developed so sometimes we probably have to require specific
valac versions to support certain features (ie. nothing like c89, c99, c++98, etc but not unlike supporting newer G* versions).
More version hell, just what we don't need.
Not much/any worse than current situation, just more of an excuse not to care about pre-historic, deprecated, unsupported versions of stuff we shouldn't be targetting for new code :)
- As with above, may require to use fairly modern/specific dependency
versions of the G* C libraries (ex. might not work on RHEL or some other LTS distros).
So how do we handle windows? Of course we could drop it :)
I've used it before on Windows, not much different than current situation.
- Extra dependency (valac) for maintainers/developers.
So long as its a version thats in LTS repos and has available binaries for windows that doesn't matter.
For developement version, IMO who the hell cares about old pre-historic LTS versions, we aren't coding for them, but for their newer counterparts. IME Windows support is not bad, at least no worse than existing G* stuff.
- Using non-GLib-based libraries requires to write boring but trivial
binding .vapi files (not huge deal for existing Geany code).
Well, you already have done that for the plugin API IIUC, but still would be needed for the rest of Geany.
No, the rest of Geany would (eventually) be (re)written in modern GObject-style (vala-style) C thus elimitating this problem altogether (as well as the need for hand-coded bindings like we have currently). In the meantime, it's no worse than currently.
- Can sometimes generate heap-heavy or non-optimized code.
So does some of our C code ;) I doubt its a significant issue.
Indeed.
- Can sometimes generate C code that causes warnings with common compiler
warning flags, would require to disable some compiler warnings on generated C code to have a completely clean build (ex. use -w on all .vala code)
Ok if autotools and waf do that for the vala C code, but the existing Geany C code still needs pedantic settings.
Trivial to adjust Vala-specific flags.
- The documentation isn't as great as an ISO language that existed since
forever. The official language specification isn't as complete or fleshed-out (ex. has TODOs) as an ISO language. There is lots of documentation out there, for example on the official Wiki, but it's still no substitude for definitive language reference and decades of books/literature on the subject.
The draft manual at https://wiki.gnome.org/Vala/Manual is a good deal better than the "official" version, it looks almost usable.
Yep, and it gets better all the time.
- More people know C than C++/C#/Java (ie. style of Vala). IMO, this one
is untrue since people who use C nowadays are either well-versed embedded programmers who already know the higher-level stuff, C/Gobject/Gtk+ programmers who already know or can easily understand how the higher-level stuff works (ex. by looking at generated C code), high-level-only programmers who for the most part don't need to care about how the underpinnings work and already would know Vala since it's basically C#(/Java), or finally, and I believe the least likely; complete n00bs who would be much safer writing garbage in any high-level language than directly in something like C/C++ anyway.
I don't think it matters how many know it, how many are willing to contribute is the issue, and with a mixed language application it needs two languages.
And that leads to what I consider is the biggest problem with the proposal, having a project with parts in one language and parts in another. Maintaining assumptions between them, some made by the vala compiler, some made by C coders, is going to be hard and a source of extra problems and bugs. That alone is enough reason to not just start piling vala onto the existing Geany.
But the languages are directly related and directly compatible. It's almost impossible to know one without the other and gradually our source could move towards the other. There's no way around this without just saying "no", no matter which language you choose (including proper GObject-style C code).
If there is really enough reason to change to vala I would suggest that the right way to do it is to define interfaces between those parts of Geany that are going to stay C for the foreseeable future, eg Scintilla, tagmangler etc and create vapi definitions for them. Then build the basic skeleton of the app in vala, calling the C parts as required. Its not as immediate as allowing random parts to be written in vala but is likely to be much more effective in moving the project forward, and ATM thats what Geany really needs, a good spruce up so new things can be more easily added.
The beauty of Vala is that it does allow for this. You can integrate existing C libraries (ex. TM or Scintilla) with or without changing everything to Vala and even just to small parts of new code in Vala and have it be completely compatible and callable from existing C code that hasn't/isnt' to be changed yet. It's like the best of all worlds.
Cheers Lex
PS we discussed the inappropriateness of +-1 as a reply to something this complex on IRC, won't repeat here.
Just to keep down in-depth discussions before higher-level concensus is reached :)
Cheers, Matthew Brush
[...]
Reference counting, not memory management, ie non-cyclic structures only,
fine for GTK GUI structures, but not any old structures. And of course it only applies to structures that support reference counting, not simple types as used in most of Geany.
Reference counting is a valid memory management strategy used in many languages like C++ or Python. Vala handles this fine and provides ways to break cycles or such as expected, and more often than not it's not even a concern while programming in Vala itself.
C++ does not have memory management, and Python has a cycle breaker :) vala is fine by itself, but needs great care in the presence of existing *simple structures* (not gobjects) shared with C code as existing Geany uses.
[...]
Vala exceptions, as mentioned used GError result/out parameters, so there's no change from existing code.
Not what it says here https://wiki.gnome.org/Vala/Manual/Errors and anything that can throw through C code can cause leaks since the C code doesn't clean up. Same as C++, you can't use exceptions mixed with C code.
[...] It means users who are only compiling Geany don't have to install valac, even though it's quite widely available. As usual, if they want to hack on Geany they will need a full development environment including current sources from Git.
Yes, so long as the version in the repos or for windows works fine its not a problem.
[...]
Which is partially the point of this discussion, simple Gobjectification of Geany's code, without the crufty boilerplate of Gobject/C, moving forward.
Which point you failed to mention :)
I'm still to be convinced that gobjectification is automatically going to do much for us, but doing it in vala not C is definitely better.
[...]
- Has Autotools and Waf support already, and using from plain GNU Make is
trivial.
How well does the windows version work, is it up to date, since it includes Glib and GTK which versions are they, and do they match ours? The binaries for windows vala available seem to be 0.12, even my LTS Linux has 0.14, 0.16 and 0.18 valac available, more version hell and windows issues :(
See current issues WRT Windows binaries, not much change with Vala, just one more binary application to track version of.
Yeah, but its a binary which includes Glib and GTK IIUC, so we have to match those. I agree its not much worse than we have now but its not very comforting that the last binaries are 2011 vala version 0.12 when even LTS Linux distros have 0.18.
[...]
More version hell, just what we don't need.
Not much/any worse than current situation, just more of an excuse not to care about pre-historic, deprecated, unsupported versions of stuff we shouldn't be targetting for new code :)
I would prefer to make it *better* than the current situation rather than just replace one problem with another.
[...]
So long as its a version thats in LTS repos and has available binaries for
windows that doesn't matter.
For developement version, IMO who the hell cares about old pre-historic LTS versions, we aren't coding for them, but for their newer counterparts. IME Windows support is not bad, at least no worse than existing G* stuff.
So you propose that Geany only ever work on bleeding edge distros? You were one of those who strongly argued against dropping windows support, but now you want to drop many of the commercial Linux users who have LTS distros?
[...]
Well, you already have done that for the plugin API IIUC, but still would be needed for the rest of Geany.
No, the rest of Geany would (eventually) be (re)written in modern GObject-style (vala-style) C thus elimitating this problem altogether (as well as the need for hand-coded bindings like we have currently). In the meantime, it's no worse than currently.
No it adds another layer of complexity in the meantime with very little upside, tahts why I suggested below that the new design needs to be done first.
[...]
I don't think it matters how many know it, how many are willing to
contribute is the issue, and with a mixed language application it needs two languages.
And that leads to what I consider is the biggest problem with the proposal, having a project with parts in one language and parts in another. Maintaining assumptions between them, some made by the vala compiler, some made by C coders, is going to be hard and a source of extra problems and bugs. That alone is enough reason to not just start piling vala onto the existing Geany.
But the languages are directly related and directly compatible. It's almost impossible to know one without the other and gradually our source could move towards the other. There's no way around this without just saying "no", no matter which language you choose (including proper GObject-style C code).
Ok, so I'm saying "No". Geany doesn't need another language and more complexity, it needs to be properly designed and then progressed to that design. Using another language to do that is a detail only.
[...]
The beauty of Vala is that it does allow for this. You can integrate existing C libraries (ex. TM or Scintilla) with or without changing everything to Vala and even just to small parts of new code in Vala and have it be completely compatible and callable from existing C code that hasn't/isnt' to be changed yet. It's like the best of all worlds.
Which is why I suggested it.
Cheers
Lex
PS we discussed the inappropriateness of +-1 as a reply to something this complex on IRC, won't repeat here.
Just to keep down in-depth discussions before higher-level concensus is reached :)
Its not consensus if you don't know what you are agreeing to :)
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13-11-10 12:09 AM, Lex Trotman wrote:
[...]
Reference counting, not memory management, ie non-cyclic structures only,
fine for GTK GUI structures, but not any old structures. And of course it only applies to structures that support reference counting, not simple types as used in most of Geany.
Reference counting is a valid memory management strategy used in many languages like C++ or Python. Vala handles this fine and provides ways to break cycles or such as expected, and more often than not it's not even a concern while programming in Vala itself.
C++ does not have memory management, and Python has a cycle breaker :) vala is fine by itself, but needs great care in the presence of existing *simple structures* (not gobjects) shared with C code as existing Geany uses.
C++ uses "smart pointers" and RAII for memory managment, both are available or equal to Vala's rendition of it. I'm not sure it has an automatic cycle-breaker but it has unowned vs owned references to break the tie.
[...]
Vala exceptions, as mentioned used GError result/out parameters, so there's no change from existing code.
Not what it says here https://wiki.gnome.org/Vala/Manual/Errors and anything that can throw through C code can cause leaks since the C code doesn't clean up. Same as C++, you can't use exceptions mixed with C code.
Trust me, I generated lots of C code from Vala, when you throw an exception, in the CCode it throws on a GError out/result argument as you'd expect in C Code.
[...] It means users who are only compiling Geany don't have to install valac, even though it's quite widely available. As usual, if they want to hack on Geany they will need a full development environment including current sources from Git.
Yes, so long as the version in the repos or for windows works fine its not a problem.
Yep, same as current dependencies although probably slightly more specific versions.
[...]
Which is partially the point of this discussion, simple Gobjectification of Geany's code, without the crufty boilerplate of Gobject/C, moving forward.
Which point you failed to mention :)
It follows with discussions on ML and IRC about writing more GObject/bindable/cleaner/less crazy code. It helps to have a full toolbox, instead of making your own buggy toolbox and using it despite the runtime you already have available which dwarves your little toolbox.
I'm still to be convinced that gobjectification is automatically going to do much for us, but doing it in vala not C is definitely better.
[...]
- Has Autotools and Waf support already, and using from plain GNU Make is
trivial.
How well does the windows version work, is it up to date, since it includes Glib and GTK which versions are they, and do they match ours? The binaries for windows vala available seem to be 0.12, even my LTS Linux has 0.14, 0.16 and 0.18 valac available, more version hell and windows issues :(
See current issues WRT Windows binaries, not much change with Vala, just one more binary application to track version of.
Yeah, but its a binary which includes Glib and GTK IIUC, so we have to match those. I agree its not much worse than we have now but its not very comforting that the last binaries are 2011 vala version 0.12 when even LTS Linux distros have 0.18.
We could compile own if we need to embeded release, otherwise using something like https://wiki.gnome.org/Vala/Win32CrossBuildSample or billions of other possibilities for creating cross-platform code as well as we do now.
[...]
More version hell, just what we don't need.
Not much/any worse than current situation, just more of an excuse not to care about pre-historic, deprecated, unsupported versions of stuff we shouldn't be targetting for new code :)
I would prefer to make it *better* than the current situation rather than just replace one problem with another.
It's to facilitate writing *Better* code, no at the expense of.
[...]
So long as its a version thats in LTS repos and has available binaries for
windows that doesn't matter.
For developement version, IMO who the hell cares about old pre-historic LTS versions, we aren't coding for them, but for their newer counterparts. IME Windows support is not bad, at least no worse than existing G* stuff.
So you propose that Geany only ever work on bleeding edge distros? You were one of those who strongly argued against dropping windows support, but now you want to drop many of the commercial Linux users who have LTS distros?
Nope, I propose *new* Geany release will only work on *new* dependencies, which are release in *new* distros, which are using *non-deprecated* APIs.
I argue that without using C directly for the most part we can be on-par with existing portability that was using same dependencies.
[...]
Well, you already have done that for the plugin API IIUC, but still would be needed for the rest of Geany.
No, the rest of Geany would (eventually) be (re)written in modern GObject-style (vala-style) C thus elimitating this problem altogether (as well as the need for hand-coded bindings like we have currently). In the meantime, it's no worse than currently.
No it adds another layer of complexity in the meantime with very little upside, tahts why I suggested below that the new design needs to be done first.
Massive upsides including less leaks, bugs, clearer syntax more expressive syntax, more high-level syntax, easier to make abstraction layers, etc.
[...]
I don't think it matters how many know it, how many are willing to
contribute is the issue, and with a mixed language application it needs two languages.
And that leads to what I consider is the biggest problem with the proposal, having a project with parts in one language and parts in another. Maintaining assumptions between them, some made by the vala compiler, some made by C coders, is going to be hard and a source of extra problems and bugs. That alone is enough reason to not just start piling vala onto the existing Geany.
But the languages are directly related and directly compatible. It's almost impossible to know one without the other and gradually our source could move towards the other. There's no way around this without just saying "no", no matter which language you choose (including proper GObject-style C code).
Ok, so I'm saying "No". Geany doesn't need another language and more complexity, it needs to be properly designed and then progressed to that design. Using another language to do that is a detail only.
I don't believe you have ever learned or used Vala, so your "no" carries less weight. Althought I know you are in favour of C++ which is yet another higher-level language, and since you don't have to expend any effort you automatically agree with that, so consider Vala to be C++ for C/Gobject code, like C++ is for normal non-GObject code and we can be happy.
[...]
The beauty of Vala is that it does allow for this. You can integrate existing C libraries (ex. TM or Scintilla) with or without changing everything to Vala and even just to small parts of new code in Vala and have it be completely compatible and callable from existing C code that hasn't/isnt' to be changed yet. It's like the best of all worlds.
Which is why I suggested it.
Cheers
Lex
PS we discussed the inappropriateness of +-1 as a reply to something this complex on IRC, won't repeat here.
Just to keep down in-depth discussions before higher-level concensus is reached :)
Its not consensus if you don't know what you are agreeing to :)
Said the fellow who have never programmed a line of Vala code in his life and who likes a language like C++ which is basically the equivalent to Vala for C/Gobject based applictaions.
Is it fair to consider Lex to be a +/-1 for the sake of keeping discussions on-track?
Cheers, Matthew Brush
[...]
Not what it says here https://wiki.gnome.org/Vala/Manual/Errors and
anything that can throw through C code can cause leaks since the C code doesn't clean up. Same as C++, you can't use exceptions mixed with C code.
Trust me, I generated lots of C code from Vala, when you throw an exception, in the CCode it throws on a GError out/result argument as you'd expect in C Code.
Yes, I understand how the "throws" are implemented in vala, but as I said, the existing C code isn't designed to handle that.
[...]
Yeah, but its a binary which includes Glib and GTK IIUC, so we have to match those. I agree its not much worse than we have now but its not very comforting that the last binaries are 2011 vala version 0.12 when even LTS Linux distros have 0.18.
We could compile own if we need to embeded release, otherwise using something like https://wiki.gnome.org/Vala/Win32CrossBuildSample or billions of other possibilities for creating cross-platform code as well as we do now.
Sure we *can* do anything, but "somebody" has to do it and maintain it.
[...]
Nope, I propose *new* Geany release will only work on *new* dependencies, which are release in *new* distros, which are using *non-deprecated* APIs.
So you want the extra work of backporting bugfixes, or just forget about older platforms?
[...]
Ok, so I'm saying "No". Geany doesn't need another language and more
complexity, it needs to be properly designed and then progressed to that design. Using another language to do that is a detail only.
I don't believe you have ever learned or used Vala, so your "no" carries less weight.
[...]
Said the fellow who have never programmed a line of Vala code in his life and who likes a language like C++ which is basically the equivalent to Vala for C/Gobject based applictaions.
Ad hominem attacks have no place in this discussion list.
Is it fair to consider Lex to be a +/-1 for the sake of keeping discussions on-track?
I would have thought that "no" above was obvious.
To be clear, tinkering with what language is used to tack more bandages on to the current Geany design is a waste of time. Choosing a better language to implement a better design might be worthwhile.
Cheers Lex
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13-11-10 01:44 AM, Lex Trotman wrote:
[...]
Not what it says here https://wiki.gnome.org/Vala/Manual/Errors and
anything that can throw through C code can cause leaks since the C code doesn't clean up. Same as C++, you can't use exceptions mixed with C code.
Trust me, I generated lots of C code from Vala, when you throw an exception, in the CCode it throws on a GError out/result argument as you'd expect in C Code.
Yes, I understand how the "throws" are implemented in vala, but as I said, the existing C code isn't designed to handle that.
Much of the existing code uses GError-style errors, and any existing C code that was made to to call Vala generated code would do the same, no biggie. It's not like we'd throw an exception from a re-written function without updating the caller code, that wouldn't even work, the compiler would have a fit about missing (GError) parameter (unlike with C++ exceptions).
Maybe I misunderstand your point still?
[...]
Yeah, but its a binary which includes Glib and GTK IIUC, so we have to match those. I agree its not much worse than we have now but its not very comforting that the last binaries are 2011 vala version 0.12 when even LTS Linux distros have 0.18.
We could compile own if we need to embeded release, otherwise using something like https://wiki.gnome.org/Vala/Win32CrossBuildSample or billions of other possibilities for creating cross-platform code as well as we do now.
Sure we *can* do anything, but "somebody" has to do it and maintain it.
I'm volunteering. We keep saying "somebody" has to do it, and I'm proposing a way that seems the most sane/best and least time-wasting to do it, and being the "somebody" in this case (although I'm hardly a build system expert).
[...]
Nope, I propose *new* Geany release will only work on *new* dependencies, which are release in *new* distros, which are using *non-deprecated* APIs.
So you want the extra work of backporting bugfixes, or just forget about older platforms?
I guess (according to Columban's message) this is a non-issue, we can target same versions of stuff as before, and even RHEL supports recent Valac, so it should be same old (in theory at least).
[...]
Said the fellow who have never programmed a line of Vala code in his life and who likes a language like C++ which is basically the equivalent to Vala for C/Gobject based applictaions.
Ad hominem attacks have no place in this discussion list.
I didn't mean as an attack, just pointing out the irony that of all people, surprisingly, you seem to be against it the most, being someone who is a strong proponent of a quite similar language, good programming paradigms, and good language design in general :)
Is it fair to consider Lex to be a +/-1 for the sake of keeping discussions on-track?
I would have thought that "no" above was obvious.
Is that "no" because you want to focus on re-design and not getting an in principle agreement on a good language to use? Or you honestly don't think Vala is a good fit at all for new/re-written parts of Geany code?
To be clear, tinkering with what language is used to tack more bandages on to the current Geany design is a waste of time. Choosing a better language to implement a better design might be worthwhile.
That's the idea; choose a better language, agree it can be used, and then start working on the re-factoring/re-design stuff using it. If we get bogged down at this point with deep design discussions and stuff, instead of just agreeing on a language that volunteers (ex. me) are happy/willing[1] to use to roll-out said re-factorings/re-designs, we'll not move forward at all[2].
P.S. Sorry if I was snarky/sarcastic in the last message, it's only because I know roughly your sentiments on the subject from our previous discussions, and could insert any topic for Vala and you'd find some points to disagree about (see most/all RFCs in ML archives) :) I just get frustrated because you're generally against every idea anyone (especially me) has, and it's hard to tell if you're being genuine or just disagreeing for the sake of disagreeing, or you think I'm too stupid to understand what I'm talking about or something.
Cheers, Matthew Brush
[1]: I'd also be willing to do in plain GObject/C but it'd be a lot more boring/long/bug-prone and would result in the exact same code as Valac would generate (or likely worse), and then you'd be pointing out about how it's too much churn, boilerplate, or how G*/C sucks, etc.
[2]: Yes, the design part is fairly independent of the language part, of course we could do it ASM if we wanted, but certain tools make things a lot easier to express/organize, especially when you can type 20 lines of clean readable Vala code instead of 200 lines of organized but boring GObject code, or 150 lines of unstructured, bug/leak-prone, hard-to-follow plain C code[3].
[3]: And yes, it is possible to write structured, non-buggy/leaky, easier to follow code in plain C, but it's a heck of a lot harder, and as shown in existing Geany code, it's easier to be less rigorous when the proper "framework" of the code isn't in place.
[...]
Yes, I understand how the "throws" are implemented in vala, but as I said,
the existing C code isn't designed to handle that.
Much of the existing code uses GError-style errors, and any existing C code that was made to to call Vala generated code would do the same, no biggie. It's not like we'd throw an exception from a re-written function without updating the caller code, that wouldn't even work, the compiler would have a fit about missing (GError) parameter (unlike with C++ exceptions).
Maybe I misunderstand your point still?
No, you said it exactly right, the concern is we can't use Vala "exceptions" without changing the existing C code, which somewhat negates the benefits of Vala.
[...]
We could compile own if we need to embeded release, otherwise using
something like https://wiki.gnome.org/Vala/Win32CrossBuildSample or billions of other possibilities for creating cross-platform code as well as we do now.
Sure we *can* do anything, but "somebody" has to do it and maintain it.
I'm volunteering. We keep saying "somebody" has to do it, and I'm proposing a way that seems the most sane/best and least time-wasting to do it, and being the "somebody" in this case (although I'm hardly a build system expert).
Look forward to its appearance on github.com/codebrainz/geany :)
[...]
Nope, I propose *new* Geany release will only work on *new* dependencies,
which are release in *new* distros, which are using *non-deprecated* APIs.
So you want the extra work of backporting bugfixes, or just forget about older platforms?
I guess (according to Columban's message) this is a non-issue, we can target same versions of stuff as before, and even RHEL supports recent Valac, so it should be same old (in theory at least).
Makes sense that it should work on Linux, and if you make a Windows bundle as above then fine.
[...]
I would have thought that "no" above was obvious.
Is that "no" because you want to focus on re-design and not getting an in principle agreement on a good language to use?
Correct.
Or you honestly don't think Vala is a good fit at all for new/re-written parts of Geany code?
Not yet convinced, and TBH not really convinced about a progressive change to C++ either (my original mention that sparked the thread was meant to be a sarcastic throwaway comment :). I understand your desire to keep the discussion high level, but the devil is in the annoying little details for languages, and their implementations, so you can't make a decision without examining those details.
To be clear, tinkering with what language is used to tack more bandages on
to the current Geany design is a waste of time. Choosing a better language to implement a better design might be worthwhile.
That's the idea; choose a better language, agree it can be used, and then start working on the re-factoring/re-design stuff using it. If we get bogged down at this point with deep design discussions and stuff, instead of just agreeing on a language that volunteers (ex. me) are happy/willing[1] to use to roll-out said re-factorings/re-designs, we'll not move forward at all[2].
As I said, choosing the language first is putting the cart before the horse. As I said in reply to Colomban, I'll start a different thread about the way we want to move, lets see where that goes.
P.S. Sorry if I was snarky/sarcastic in the last message, it's only because I know roughly your sentiments on the subject from our previous discussions, and could insert any topic for Vala and you'd find some points to disagree about (see most/all RFCs in ML archives) :) I just get frustrated because you're generally against every idea anyone (especially me) has, and it's hard to tell if you're being genuine or just disagreeing for the sake of disagreeing, or you think I'm too stupid to understand what I'm talking about or something.
There is definitely nothing personal about any disagreement over things. I guess you see most disagreements simply because you post the most proposals, and thats a positive not a negative. As I said above the devil is usually in the details, and after having been bitten many times I tend to focus on the things that might cause problems, because the things that are right will look after themselves. I guess that can look negative, but its simply trying to prevent issues I see before they happen.
Cheers Lex
Cheers, Matthew Brush
[1]: I'd also be willing to do in plain GObject/C but it'd be a lot more boring/long/bug-prone and would result in the exact same code as Valac would generate (or likely worse), and then you'd be pointing out about how it's too much churn, boilerplate, or how G*/C sucks, etc.
[2]: Yes, the design part is fairly independent of the language part, of course we could do it ASM if we wanted, but certain tools make things a lot easier to express/organize, especially when you can type 20 lines of clean readable Vala code instead of 200 lines of organized but boring GObject code, or 150 lines of unstructured, bug/leak-prone, hard-to-follow plain C code[3].
[3]: And yes, it is possible to write structured, non-buggy/leaky, easier to follow code in plain C, but it's a heck of a lot harder, and as shown in existing Geany code, it's easier to be less rigorous when the proper "framework" of the code isn't in place.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13-11-10 03:02 PM, Lex Trotman wrote:
[...]
Yes, I understand how the "throws" are implemented in vala, but as I said,
the existing C code isn't designed to handle that.
Much of the existing code uses GError-style errors, and any existing C code that was made to to call Vala generated code would do the same, no biggie. It's not like we'd throw an exception from a re-written function without updating the caller code, that wouldn't even work, the compiler would have a fit about missing (GError) parameter (unlike with C++ exceptions).
Maybe I misunderstand your point still?
No, you said it exactly right, the concern is we can't use Vala "exceptions" without changing the existing C code, which somewhat negates the benefits of Vala.
True, but it's not exactly difficult to update/add an argument on a C function, I think the compiler will kindly (or rudely :) even point out all the places that were missed.
[...]
Or you honestly don't think Vala is a good fit at all for new/re-written parts of Geany code?
Not yet convinced, and TBH not really convinced about a progressive change to C++ either (my original mention that sparked the thread was meant to be a sarcastic throwaway comment :). I understand your desire to keep the discussion high level, but the devil is in the annoying little details for languages, and their implementations, so you can't make a decision without examining those details.
I agree about C++, however much of a better language it is, it's not a great fit in Geany as it stands (although could probably be workable using GTKmm). IMO, Vala is the simplest way to get the most bang with least amount of friction with existing code/framework and all of the output C code from Vala is quite readable and for the most part maps 1:1 to what we (at least me) would've wrote anyway.
To be clear, tinkering with what language is used to tack more bandages on
to the current Geany design is a waste of time. Choosing a better language to implement a better design might be worthwhile.
That's the idea; choose a better language, agree it can be used, and then start working on the re-factoring/re-design stuff using it. If we get bogged down at this point with deep design discussions and stuff, instead of just agreeing on a language that volunteers (ex. me) are happy/willing[1] to use to roll-out said re-factorings/re-designs, we'll not move forward at all[2].
As I said, choosing the language first is putting the cart before the horse. As I said in reply to Colomban, I'll start a different thread about the way we want to move, lets see where that goes.
If you're going to renovate a house, it helps to know whether you're going to use lumber or concrete before you start designing the structure :)
I don't think it's putting the cart before the horse, but I agree the two things aren't directly related, either one could happen in either order, just that if we chose to use Vala before any major changes/redesigning, we'd save a lots of pain in the process (to use above metaphor, we could save driving nails into concrete, or pouring lumber into concrete molds :)
Cheers, Matthew Brush
Maybe, rewriting some parts of boating complicated leaky code (e.g. build.c:) isn't bad idea and suitable in this situation. You don't need much bindings for editor and Vala shouldn't be a pain. But AFAIK Geany don't use GObject and writing on Vala may cause deep refactoring that will take your time. Many things in Geany could be rewritten, simplified and improved and it's definitely going to be refactoring while using Vala.
To improve maintainability pure C code could be pre-generated before release for faster and easier build without vala.
From the other side you could scare good C programmers...
About RHEL: defenitely can say that Vala 0.20 works. And some things could be easily compiled.
Hi all,
In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. The pros and cons likely will be slightly biased since I would obviously like to use Vala in Geany, but here they are anyway:
Pros:
- Power of high-level OOP language using existing GObject backend with
no C boilerplate required
- Uses same type-system as existing C code
- Automatic memory management
- Clean expressive syntax (foreach, as, properties, signals, async, etc.)
- Exceptions (which uses C/GError-style exceptions in generated C code)
- No extra dependency for release users (generated C code can be shipped)
- Can generate Gobject-Introspection bindings automatically allowing use
from a bunch of cool languages like Python, JavaScript, etc (and as many other languages as support Gobject-Introspection) for plugins.
- Easy to learn for anyone who's used C++, Java, C#, etc.
- Uses all existing dependencies as its runtime library (ex. GLib/GIO).
- Can generate C/H code that is usable from within existing C code, so
no requirement to completely re-write, can just add on modular code as needed.
- Can be tuned to output optimized C code, or call optimized C code
quite easily
- Can sometimes generate clever and/or optimized code that would be
tedious to write in C.
- Has Autotools and Waf support already, and using from plain GNU Make
is trivial.
- Actively developed and supported, and having active mailing list and
IRC channels. (ex. it's easier to submit a patch to Vala language than ISO C).
- AFAIK it generates C89-compliant code :)
Cons:
- A fairly new language (since 2006). It's hard to argue against this,
but also impossible to move forward without adopting new stuff at some point.
- Some dark corners/bugs due to being such a new language (compared to
C/C++).
- Actively developed so sometimes we probably have to require specific
valac versions to support certain features (ie. nothing like c89, c99, c++98, etc but not unlike supporting newer G* versions).
- As with above, may require to use fairly modern/specific dependency
versions of the G* C libraries (ex. might not work on RHEL or some other LTS distros).
- Extra dependency (valac) for maintainers/developers.
- Using non-GLib-based libraries requires to write boring but trivial
binding .vapi files (not huge deal for existing Geany code).
- Can sometimes generate heap-heavy or non-optimized code.
- Can sometimes generate C code that causes warnings with common
compiler warning flags, would require to disable some compiler warnings on generated C code to have a completely clean build (ex. use -w on all .vala code)
- The documentation isn't as great as an ISO language that existed since
forever. The official language specification isn't as complete or fleshed-out (ex. has TODOs) as an ISO language. There is lots of documentation out there, for example on the official Wiki, but it's still no substitude for definitive language reference and decades of books/literature on the subject.
- More people know C than C++/C#/Java (ie. style of Vala). IMO, this one
is untrue since people who use C nowadays are either well-versed embedded programmers who already know the higher-level stuff, C/Gobject/Gtk+ programmers who already know or can easily understand how the higher-level stuff works (ex. by looking at generated C code), high-level-only programmers who for the most part don't need to care about how the underpinnings work and already would know Vala since it's basically C#(/Java), or finally, and I believe the least likely; complete n00bs who would be much safer writing garbage in any high-level language than directly in something like C/C++ anyway.
For more information about Vala, this a good starting point:
https://wiki.gnome.org/Vala/DocumentationIf we can cleanly get more +1's than -1's (in principle, and especially from the core developers and active contributors), without wandering off into nitty-gritty details, version-specific bugs encountered that don't/won't specifically apply to Geany, stuff I have specifically accounted for in the pros/cons list, and minutia like we (especially ME) always do, then we can move forward with this and hammer-out those details later during integration, rather than stifflying the idea here in this thread as we (including ME) often do. If one or more of the things you like or dislike is already mentioned, there's no point in specifically responding to it unless you think it's unclear or inaccurate, just give your +1/-1 and see where it goes.
Basically what I'm saying is that if we can keep this discussion on track and people show enthusiasm (or at least not strong distain, in principle) then I will personally volunteer my time to make it happen. If it turns into a zillion message thread about off-topic, or nitty-gritty stuff (which should occur later on, in a different thread) or hate from people who have never tried the language in earnest but still have a strong anti-opinion (especially based on old or presumed information, or general hate for the G* toolkit we already use), then I probably will just forget it, and probably no one else will move this forward.
P.S. Sorry for stupid-sounding discussion rules, it's just an attempt to move something useful forward, productively, with consensus, without wasting our voluntary time discussing deep details too early-on, and based on past similar discussions on this list and knowledge I have about some poeple's existing opinions. Please don't take offense or rant about the stupid "rules", just believe I'm sincere in that I'm trying to organize the discussion more productively than usual (even if failing) :)
Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
-- Best regards, Pavel Roschin aka RPG
On 13-11-10 02:00 AM, Pavel Roschin wrote:
Maybe, rewriting some parts of boating complicated leaky code (e.g. build.c:) isn't bad idea and suitable in this situation. You don't need much bindings for editor and Vala shouldn't be a pain. But AFAIK Geany don't use GObject and writing on Vala may cause deep refactoring that will take your time. Many things in Geany could be rewritten, simplified and improved and it's definitely going to be refactoring while using Vala.
To improve maintainability pure C code could be pre-generated before release for faster and easier build without vala.
Yep, this is the default for the Autotools built-in support as well, so no extra work to do it.
From the other side you could scare good C programmers...
True, but I suspect good C programmers will have little trouble with a simple language like Vala.
About RHEL: defenitely can say that Vala 0.20 works. And some things could be easily compiled.
Cool, good to know.
Cheers, Matthew Brush
Disclaimer: I know little to nothing about Vala.
I like how lean Geany is. From the discussion, it sounds like Vala does its own memory management. Currently geany only uses between 9 and 13 MB of memory on my box. Would Vala inadvertantly make geany use more memory? I don't want to use much more of my GBs of memory ;-)
Changing languages almost always adds complexity and my humble opinion is that it should be avoided, but I also don't know enough about vala to say how easy it would be to include it in development.
Thanks,
Steve
On 11/10/2013 12:22 PM, Matthew Brush wrote:
On 13-11-10 02:00 AM, Pavel Roschin wrote:
Maybe, rewriting some parts of boating complicated leaky code (e.g. build.c:) isn't bad idea and suitable in this situation. You don't need much bindings for editor and Vala shouldn't be a pain. But AFAIK Geany don't use GObject and writing on Vala may cause deep refactoring that will take your time. Many things in Geany could be rewritten, simplified and improved and it's definitely going to be refactoring while using Vala.
To improve maintainability pure C code could be pre-generated before release for faster and easier build without vala.
Yep, this is the default for the Autotools built-in support as well, so no extra work to do it.
From the other side you could scare good C programmers...
True, but I suspect good C programmers will have little trouble with a simple language like Vala.
About RHEL: defenitely can say that Vala 0.20 works. And some things could be easily compiled.
Cool, good to know.
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 12 November 2013 03:38, Steven Blatnick steve8track@yahoo.com wrote:
Disclaimer: I know little to nothing about Vala.
I like how lean Geany is. From the discussion, it sounds like Vala does its own memory management. Currently geany only uses between 9 and 13 MB of memory on my box. Would Vala inadvertantly make geany use more memory? I don't want to use much more of my GBs of memory ;-)
Despite what the fans say, Vala does not really do "memory management" in any way different to a C program, but the Vala compiler does write the "free" calls that C programmers forget (and that there has been a bit of a pogrom on lately :). It also uses reference counting for objects that support it (in current Geany thats mostly the GUI widgets). So long as any re-design did not go overboard with the use of such features just because they are there, and are easier to use than in C, then it shouldn't use appreciably more memory.
What it does not do is use garbage collection like Java and therefore Eclipse.
Cheers Lex
Changing languages almost always adds complexity and my humble opinion is that it should be avoided, but I also don't know enough about vala to say how easy it would be to include it in development.
Thanks,
Steve
On 11/10/2013 12:22 PM, Matthew Brush wrote:
On 13-11-10 02:00 AM, Pavel Roschin wrote:
Maybe, rewriting some parts of boating complicated leaky code (e.g. build.c:) isn't bad idea and suitable in this situation. You don't need much bindings for editor and Vala shouldn't be a pain. But AFAIK Geany don't use GObject and writing on Vala may cause deep refactoring that will take your time. Many things in Geany could be rewritten, simplified and improved and it's definitely going to be refactoring while using Vala.
To improve maintainability pure C code could be pre-generated before release for faster and easier build without vala.
Yep, this is the default for the Autotools built-in support as well, so no extra work to do it.
From the other side you could scare good C programmers...
True, but I suspect good C programmers will have little trouble with a simple language like Vala.
About RHEL: defenitely can say that Vala 0.20 works. And some things
could be easily compiled.
Cool, good to know.
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13-11-11 08:38 AM, Steven Blatnick wrote:
[snip]
Changing languages almost always adds complexity and my humble opinion is that it should be avoided, but I also don't know enough about vala to say how easy it would be to include it in development.
[citation needed]
Like provide an example of a past experience/observation where a project switched from a similarly low-level language to a similarly high-level language where it added (rather than severely reduced) complexity.
Cheers, Matthew Brush
Just to elaborate my "sources" ;-)
Personal Experience:
I suppose I should elaborate that the added complexity could be a result of having a mixture of old and new languages by trying to get them to work together so as not to lose all legacy features while migrating.
Without trying to hurt any company's reputation, I work or worked at a company where the main code base was perl, but now they prefer Java. They couldn't just remove all of the legacy code, so getting the two languages to work together makes the code complicated. The other problem is they have adopted several different frameworks over the years, from JSF, JSP, to GWT running on various different services from apache (for the perl), tomcat4, tomcat6 (at the same time!), etc. This may not match up well with vala, since it appears vala is much more c++ compatible. Also, this project is a web service, which requires migrating between the technologies without downtime and without losing any existing data, introducing it's own complexity to the migration.
Basically the problem I see is that with each new direction (caused by changing opinions with new developers over the years, each with their own biases), we end up with a *technicolor-dream-coat of convoluted technology*. I saw this at other jobs too, where each new pet feature/project introduced more dependencies and required different know-how than each of the prior work. While the projects work, they've become very complex with all the passing between the various architectures/structures/technologies. Scrambled eggs, if you will.
Gedit:
When gedit changed from using GTK2 to GTK3 between gedit2 and gedit3, they introduced some regressions. They also required a complete rewrite of all plugins others had developed for the editor. While the new plugin infrastructure is better, I re-evaluated what editor I was using because if I had to rewrite them anyway, then maybe I would do so for another editor. Hence why I am writing plugins to use with geany :-) I also noticed that gedit started to use more memory.
Gnome3/Unity:
Not only did they re-write everything, abandon their user-base, and upset a lot of people, myself included, but they also introduced many regressions and lost a lot of features. I realize we don't intend to change the principles of geany like they did, but making large code changes is bound to lead to us at least considering alternative ways of doing things, which in Gnome3's case wasn't always appreciated by the users.
Really, the *Gnome Civil War* between the programmers and the users, as I like to call it, has been a real sore spot for me and for linux-kind ;-)
I realize these are not identical to switching to vala, but I present it as food for thought anyway.
I guess my concern is that for each time a project changes direction, the code risks introducing regressions, losing/alienating users, and requiring more dependencies.
Not to get too political, especially since this may be lost on some audiences, but not all "Change" is good change. If we make any drastic changes, I suggest starting a new project so we don't essentially overwrite a current one like the Gnome guys did.
All that said, it sounds like nobody is planning that big of a change (I hope).
Thanks,
Steve
On 11/11/2013 03:31 PM, Matthew Brush wrote:
On 13-11-11 08:38 AM, Steven Blatnick wrote:
[snip]
Changing languages almost always adds complexity and my humble opinion is that it should be avoided, but I also don't know enough about vala to say how easy it would be to include it in development.
[citation needed]
Like provide an example of a past experience/observation where a project switched from a similarly low-level language to a similarly high-level language where it added (rather than severely reduced) complexity.
Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
By the way, I should point out that these remarks also apply to the geany direction thread. I also should point out this doesn't necessarily mean I'm opposed to vala, I'm just expressing concerns.
From this thread, it sounds like vala binds pretty well to C++ like python does, but also doesn't add bloat while simplifying the code. I don't think I've noticed python doing much to simplify gtk-centric code though, so would vala do better? If changing to vala is like changing to python, I'd be more inclined against it, although it would be good exerience to gain.
Thanks for all the replies :-)
Steve
Am 12.11.2013 05:52, schrieb Steven Blatnick:
By the way, I should point out that these remarks also apply to the geany direction thread. I also should point out this doesn't necessarily mean I'm opposed to vala, I'm just expressing concerns.
From this thread, it sounds like vala binds pretty well to C++ like python does, but also doesn't add bloat while simplifying the code. I don't think I've noticed python doing much to simplify gtk-centric code though, so would vala do better? If changing to vala is like changing to python, I'd be more inclined against it, although it would be good exerience to gain.
Thanks for all the replies :-)
Vala has the advantage that it compiles down to plain C code. Thus you can trivially call code written in Vala from "legacy" C code. This is also true for C++ (or some subset of it) but not for other languages which need a more complex foreign language interface.
Therefore, if we want to switch to a higher level language without re-write (we don't have the man power for a rewrite) C++ and Vala are good candidates.
Best regards.
That sounds pretty good. Is that a lot like python and gtk? I get the impression its better since I don't think python compiles to equivolent c code?
Thanks,
Steve
On 13-11-11 11:48 PM, Steven Blatnick wrote:
That sounds pretty good. Is that a lot like python and gtk? I get the impression its better since I don't think python compiles to equivolent c code?
If by "better" you mean faster, leaner, and more compatible with existing C code, yep. It literally outputs (fairly) readable GObject/GTK-style C code just like you'd write by hand. With Python not only is it not easily callable from C code, but it's interpreted, and I think the PyGObject/Introspection stuff makes it go through another layer of foreign function interface stuff (libffi I guess) to actually call the GObject C code rather than directly through a CPython extension (could be mistaken on this).
You might like an intro like this video: http://www.youtube.com/watch?feature=player_detailpage&v=6QrGmA_RR4E#t=2...
Cheers, Matthew Brush
I'm thinking vala sounds like a good idea the more I hear about it... :-)
On 11/12/2013 02:36 AM, Matthew Brush wrote:
On 13-11-11 11:48 PM, Steven Blatnick wrote:
That sounds pretty good. Is that a lot like python and gtk? I get the impression its better since I don't think python compiles to equivolent c code?
If by "better" you mean faster, leaner, and more compatible with existing C code, yep. It literally outputs (fairly) readable GObject/GTK-style C code just like you'd write by hand. With Python not only is it not easily callable from C code, but it's interpreted, and I think the PyGObject/Introspection stuff makes it go through another layer of foreign function interface stuff (libffi I guess) to actually call the GObject C code rather than directly through a CPython extension (could be mistaken on this).
You might like an intro like this video: http://www.youtube.com/watch?feature=player_detailpage&v=6QrGmA_RR4E#t=2...
Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
"technicolor-dream-coat of convoluted technology" - best description ever ;)
Steven Blatnick steve8track@yahoo.com wrote:
By the way, I should point out that these remarks also apply to the geany direction thread. I also should point out this doesn't necessarily mean I'm opposed to vala, I'm just expressing concerns.
From this thread, it sounds like vala binds pretty well to C++ like python does, but also doesn't add bloat while simplifying the code. I don't think I've noticed python doing much to simplify gtk-centric code though, so would vala do better? If changing to vala is like changing to python, I'd be more inclined against it, although it would be good exerience to gain.
Thanks for all the replies :-)
Steve
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 10.11.2013 05:44, schrieb Matthew Brush:
Hi all,
In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. The pros and cons likely will be slightly biased since I would obviously like to use Vala in Geany, but here they are anyway:
I'm undecided: on the one hand I would love if we could use Vala for new Gobject-related and OOP code, but on the other hand Geany is full of non-gobject code and Vala is still young, not widespread and un-standardized.
I'm not against going the Vala route but I guess my uncertainty counts as a no.
Perhaps we should first make it easier to write plugins in Vala (heck, merge some bindings already) and see how it plays out.
Best regards.
On 13-11-10 06:25 AM, Thomas Martitz wrote:
Am 10.11.2013 05:44, schrieb Matthew Brush:
Hi all,
In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. The pros and cons likely will be slightly biased since I would obviously like to use Vala in Geany, but here they are anyway:
I'm undecided: on the one hand I would love if we could use Vala for new Gobject-related and OOP code, but on the other hand Geany is full of non-gobject code and Vala is still young, not widespread and un-standardized.
The idea is exactly that; to use it for new/re-factored code, which as its re-factored would become nice maintainable, bindable (for plugins) GObject-style code[1]. Agree it's still young, but as long as it's not just going to vanish[2], it's hard to avoid this with any non-C/C++ language (ex. you could make the same argument against D or Go or any other not really old technology, it's almost a self-fulfilling prophecy when approached like that).
I'm not against going the Vala route but I guess my uncertainty counts as a no.
Perhaps we should first make it easier to write plugins in Vala (heck, merge some bindings already) and see how it plays out.
Any parts of core that are written in Vala would be automatically bindable to plugins (assuming some re-working of the plugin-related code and such), thus reducing the stuff in the manually maintained and already somewhat out of date .vapi file.
Cheers, Matthew Brush
[1]: And to be clear, Geany also does have some GObject-style code, we have several GObjects already, we use a toolkit based on GObject and IIRC Enrico even said before that had he known GObject better at the time, Geany code would be having lots more of the same.
[2]: And if it did vanish, since it's using the same framework we already use, it could trivially (and boringly) be ported 1:1 back to C code.
Le 10/11/2013 05:44, Matthew Brush a écrit :
Hi all,
In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. [...]
Well… it's a little complicated. I agree that features from a higher-level language could help, it being C++, Vala or something. It's definitely shorter to write some things in those languages than in C, and memory management is definitely easier. I see one advantage in Vala over C++: that it actually is C ([1]), just like our current code.
I agree that Vala would help if we want to port the code to something more OOP-style -- since obviously the language supports it by itself. I agree it's probably a good idea. But the port won't happen magically.
The problem I see is that using C from Vala requires a more or less manual interfacing, even if quite easy to write. This adds actual complexity. We could try by porting leaf modules to Vala and see (maybe utils?) -- since calling Vala API from C is native --, but it's probably not the modules that would benefit the most from the language.
To sum up, my point is that having more than one language might add too much of a glue layer for it not to weight down the idea.
Sorry Matthew, but it's kind of an "I like Vala but I don't know" :)
- Actively developed so sometimes we probably have to require specific
valac versions to support certain features (ie. nothing like c89, c99, c++98, etc but not unlike supporting newer G* versions).
Not to mention bugfixes in bindings, that are much less frequent today but weren't rare a dozen months ago or something.
- As with above, may require to use fairly modern/specific dependency
versions of the G* C libraries (ex. might not work on RHEL or some other LTS distros).
I think Vala supports targeting a particular GLib version for what it itself generates (vs. what API you explicitly use in your own code), so it may not be an issue. And I think e.g. GTK is just a lib to Vala's eyes, so you just have to use the part of it that match your preferred version, just like we already do.
Regards, Colomban
[1] so allows to keep full C compatibility without only using an uninteresting subset of the language, unlike the C++ discussion suggested, which was basically "use C++ but nothing in headers that's not C compatible, so excluding classes, and much of the interesting stuff in C++". If you wanna continue on this, use another thread :)
On 13-11-10 07:40 AM, Colomban Wendling wrote:
Le 10/11/2013 05:44, Matthew Brush a écrit :
Hi all,
In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. [...]
Well… it's a little complicated. I agree that features from a higher-level language could help, it being C++, Vala or something. It's definitely shorter to write some things in those languages than in C, and memory management is definitely easier. I see one advantage in Vala over C++: that it actually is C ([1]), just like our current code.
I agree that Vala would help if we want to port the code to something more OOP-style -- since obviously the language supports it by itself. I agree it's probably a good idea. But the port won't happen magically.
Agreed, but one of the reasons I created this thread is to get agreement that we *can* use Vala and then when we do any refactoring, it makes it that much easier. I'm sure you already know I'm bringing this topic up because I'm willing to do a lot of the work :)
The problem I see is that using C from Vala requires a more or less manual interfacing, even if quite easy to write. This adds actual complexity. We could try by porting leaf modules to Vala and see (maybe utils?) -- since calling Vala API from C is native --, but it's probably not the modules that would benefit the most from the language.
This was my same thought. There are lots of "modules" in Geany that could benefit from re-factorings, but even starting with some of the low hanging fruit like utils, uiutils, any of the existing GObjects, including geanyobject.c which as a demo, I converted to Vala reducing the lines of code count from around 400+ to around 40:
Before: https://gist.github.com/codebrainz/7274867
After: https://gist.github.com/codebrainz/7274865
And the C code that uses it needn't even change one bit in this case.
To sum up, my point is that having more than one language might add too much of a glue layer for it not to weight down the idea.
It really depends how it's done. The type of refactorings I'm envisioning (and obviously volunteering to do) wouldn't require much glue as they would clean up individual modules(files) leaving the outside world more or less the same (aside from tweaking the existing C code for slightly different calling conventions/parameters or whatever).
Sorry Matthew, but it's kind of an "I like Vala but I don't know" :)
Basically what I'm asking is; if someone volunteered to cleanup a bunch of the code, make it automatically bindable for plugins, much easier to maintain/read, and did it without adding a bunch of glue (which you actually already wrote a bunch of :), would they be wasting their time and have it blocked just because it's not C, or can we get a basic agreement, in principle, that in this case, we would be open to allowing some Vala in new/re-factored code?
- Actively developed so sometimes we probably have to require specific
valac versions to support certain features (ie. nothing like c89, c99, c++98, etc but not unlike supporting newer G* versions).
Not to mention bugfixes in bindings, that are much less frequent today but weren't rare a dozen months ago or something.
Indeed, although if we did hit some bugs in the bindings (as you said less and less likely as Vala progresses), it's quite easy to fix them and contribute the patch upstream like we do with CTags and Scintilla.
- As with above, may require to use fairly modern/specific dependency
versions of the G* C libraries (ex. might not work on RHEL or some other LTS distros).
I think Vala supports targeting a particular GLib version for what it itself generates (vs. what API you explicitly use in your own code), so it may not be an issue. And I think e.g. GTK is just a lib to Vala's eyes, so you just have to use the part of it that match your preferred version, just like we already do.
That's good to know, should be taken off the "cons" list and moved to the "pros" list then :) And yes GTK is just another lib, any of the stuff in the .vapi binding that isn't used from Vala won't be put into the generated C code, so you're right about that too.
[1] so allows to keep full C compatibility without only using an uninteresting subset of the language, unlike the C++ discussion suggested, which was basically "use C++ but nothing in headers that's not C compatible, so excluding classes, and much of the interesting stuff in C++".
In addition, you literally *can't* mix Vala and C code in the same file, so there's no weirdness about exceptions, GTypes vs C++/stdlib types, and confusion about which language is being used in a given function.
Cheers, Matthew Brush
Am 10.11.2013 20:27, schrieb Matthew Brush:
On 13-11-10 07:40 AM, Colomban Wendling wrote:
Le 10/11/2013 05:44, Matthew Brush a écrit :
Hi all,
In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. [...]
Well… it's a little complicated. I agree that features from a higher-level language could help, it being C++, Vala or something. It's definitely shorter to write some things in those languages than in C, and memory management is definitely easier. I see one advantage in Vala over C++: that it actually is C ([1]), just like our current code.
I agree that Vala would help if we want to port the code to something more OOP-style -- since obviously the language supports it by itself. I agree it's probably a good idea. But the port won't happen magically.
Agreed, but one of the reasons I created this thread is to get agreement that we *can* use Vala and then when we do any refactoring, it makes it that much easier. I'm sure you already know I'm bringing this topic up because I'm willing to do a lot of the work :)
The problem I see is that using C from Vala requires a more or less manual interfacing, even if quite easy to write. This adds actual complexity. We could try by porting leaf modules to Vala and see (maybe utils?) -- since calling Vala API from C is native --, but it's probably not the modules that would benefit the most from the language.
This was my same thought. There are lots of "modules" in Geany that could benefit from re-factorings, but even starting with some of the low hanging fruit like utils, uiutils, any of the existing GObjects, including geanyobject.c which as a demo, I converted to Vala reducing the lines of code count from around 400+ to around 40:
Error 500 :(
Basically what I'm asking is; if someone volunteered to cleanup a bunch of the code, make it automatically bindable for plugins, much easier to maintain/read, and did it without adding a bunch of glue (which you actually already wrote a bunch of :), would they be wasting their time and have it blocked just because it's not C, or can we get a basic agreement, in principle, that in this case, we would be open to allowing some Vala in new/re-factored code?
I have no say in this decision but my personal response would be: Yea, if someone did the bulk work of converting the most obvious cases to Vala I would accept this.
Best regards
On 13-11-10 11:45 AM, Thomas Martitz wrote:
Am 10.11.2013 20:27, schrieb Matthew Brush:
On 13-11-10 07:40 AM, Colomban Wendling wrote:
Le 10/11/2013 05:44, Matthew Brush a écrit :
Hi all,
In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. [...]
Well… it's a little complicated. I agree that features from a higher-level language could help, it being C++, Vala or something. It's definitely shorter to write some things in those languages than in C, and memory management is definitely easier. I see one advantage in Vala over C++: that it actually is C ([1]), just like our current code.
I agree that Vala would help if we want to port the code to something more OOP-style -- since obviously the language supports it by itself. I agree it's probably a good idea. But the port won't happen magically.
Agreed, but one of the reasons I created this thread is to get agreement that we *can* use Vala and then when we do any refactoring, it makes it that much easier. I'm sure you already know I'm bringing this topic up because I'm willing to do a lot of the work :)
The problem I see is that using C from Vala requires a more or less manual interfacing, even if quite easy to write. This adds actual complexity. We could try by porting leaf modules to Vala and see (maybe utils?) -- since calling Vala API from C is native --, but it's probably not the modules that would benefit the most from the language.
This was my same thought. There are lots of "modules" in Geany that could benefit from re-factorings, but even starting with some of the low hanging fruit like utils, uiutils, any of the existing GObjects, including geanyobject.c which as a demo, I converted to Vala reducing the lines of code count from around 400+ to around 40:
Error 500 :(
Yeah, same here, I was hoping it would be back up by the time people visited or wasn't down for them :) I'm sure it'll come back online soon.
Cheers, Matthew Brush
On 13-11-10 11:48 AM, Matthew Brush wrote:
On 13-11-10 11:45 AM, Thomas Martitz wrote:
Am 10.11.2013 20:27, schrieb Matthew Brush:
On 13-11-10 07:40 AM, Colomban Wendling wrote:
Le 10/11/2013 05:44, Matthew Brush a écrit :
Hi all,
In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. [...]
Well… it's a little complicated. I agree that features from a higher-level language could help, it being C++, Vala or something. It's definitely shorter to write some things in those languages than in C, and memory management is definitely easier. I see one advantage in Vala over C++: that it actually is C ([1]), just like our current code.
I agree that Vala would help if we want to port the code to something more OOP-style -- since obviously the language supports it by itself. I agree it's probably a good idea. But the port won't happen magically.
Agreed, but one of the reasons I created this thread is to get agreement that we *can* use Vala and then when we do any refactoring, it makes it that much easier. I'm sure you already know I'm bringing this topic up because I'm willing to do a lot of the work :)
The problem I see is that using C from Vala requires a more or less manual interfacing, even if quite easy to write. This adds actual complexity. We could try by porting leaf modules to Vala and see (maybe utils?) -- since calling Vala API from C is native --, but it's probably not the modules that would benefit the most from the language.
This was my same thought. There are lots of "modules" in Geany that could benefit from re-factorings, but even starting with some of the low hanging fruit like utils, uiutils, any of the existing GObjects, including geanyobject.c which as a demo, I converted to Vala reducing the lines of code count from around 400+ to around 40:
Error 500 :(
Yeah, same here, I was hoping it would be back up by the time people visited or wasn't down for them :) I'm sure it'll come back online soon.
Maybe it's something specific to that Gist, so I re-pasted it in a new one:
https://gist.github.com/codebrainz/7403171
Cheers, Matthew Brush
Am 10.11.2013 21:04, schrieb Matthew Brush:
Maybe it's something specific to that Gist, so I re-pasted it in a new one:
Impressive. Unfortunately only a tiny fraction of Geany's code can be vala'fied like this, right?
Best regards.
On 13-11-11 05:37 AM, Thomas Martitz wrote:
Am 10.11.2013 21:04, schrieb Matthew Brush:
Maybe it's something specific to that Gist, so I re-pasted it in a new one:
Impressive. Unfortunately only a tiny fraction of Geany's code can be vala'fied like this, right?
So trivially, yes. There's a few other GObjects that would be nearly as easy (but frankly are some Geany's nicest code already :), but the rest of the code would actually require writing real logic and stuff into Vala. Although what I was driving at in general wasn't just "porting" Geany's code 1:1 into Vala but re-factoring/re-writing/re-organizing, and using Vala to do it (same as I've talked about before WRT GObject on the list/IRC), so it's not really super important how much code can be directly 1:1 ported or vala-fied like that, I just wanted to give a little taste of the LOC/complexity reductions we could expect with Vala :)
Cheers, Matthew Brush
On 11 November 2013 02:40, Colomban Wendling lists.ban@herbesfolles.orgwrote:
Le 10/11/2013 05:44, Matthew Brush a écrit :
Hi all,
In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. [...]
Well… it's a little complicated. I agree that features from a higher-level language could help, it being C++, Vala or something. It's definitely shorter to write some things in those languages than in C, and memory management is definitely easier. I see one advantage in Vala over C++: that it actually is C ([1]), just like our current code.
I agree that Vala would help if we want to port the code to something more OOP-style -- since obviously the language supports it by itself. I agree it's probably a good idea. But the port won't happen magically.
Yes, what I tried to express was that the problem is the design and organisation of Geany, and just changing the language won't change that without an actual effort to do so. But thats not the subject here so I'll start another thread for it.
The problem I see is that using C from Vala requires a more or less manual interfacing, even if quite easy to write. This adds actual complexity. We could try by porting leaf modules to Vala and see (maybe utils?) -- since calling Vala API from C is native --, but it's probably not the modules that would benefit the most from the language.
Interesting that you say that, I proposed exactly the opposite based on being able to define the APIs of existing leaf C code in vala and a vala skeleton/infrastructure/framework (choose your preferred term :) is guaranteed to be able to call them. Whereas I thought that adding Vala at the leaves meant you had to make the Vala API match the existing C one or you had to change the existing C code to match the Vala API. In the first case you don't get the full Vala benefit as you say [2]. In the second case if the C core calling Vala has to change so it might as well be done in Vala in the first place, but that of course increases the size of each change.
To sum up, my point is that having more than one language might add too much of a glue layer for it not to weight down the idea.
Yes, it makes the way I proposed less progressive I suppose, the vapis need defining and maintaining.
Sorry Matthew, but it's kind of an "I like Vala but I don't know" :)
- Actively developed so sometimes we probably have to require specific
valac versions to support certain features (ie. nothing like c89, c99, c++98, etc but not unlike supporting newer G* versions).
Not to mention bugfixes in bindings, that are much less frequent today but weren't rare a dozen months ago or something.
- As with above, may require to use fairly modern/specific dependency
versions of the G* C libraries (ex. might not work on RHEL or some other LTS distros).
I think Vala supports targeting a particular GLib version for what it itself generates (vs. what API you explicitly use in your own code), so it may not be an issue. And I think e.g. GTK is just a lib to Vala's eyes, so you just have to use the part of it that match your preferred version, just like we already do.
That should always work for Linux, but there is always the Windows issue.
Cheers Lex
[2] and if you are using Vala to mimic existing C interfaces then you are constrained in some of its features as I understand it. For example Vala "exceptions" require an Error return in the function signature, which our existing C functions don't have.
Regards, Colomban
[1] so allows to keep full C compatibility without only using an uninteresting subset of the language, unlike the C++ discussion suggested, which was basically "use C++ but nothing in headers that's not C compatible, so excluding classes, and much of the interesting stuff in C++". If you wanna continue on this, use another thread :) _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
I cannot add much to the vala yes/no question, as the only part of ala I've seen by know are Matthews's plugin in g-p. Two or maybe three things are important to me, in case of:
- Geany needs to keep its small memory footprint - Created code needs to run on all plattforms Geany currently is running on -- At least I know of *BSD, Solaris,, MacOS X, Windows, Linux and we need to stay compatible with curent stable versions of SLES, RHEL etc. which means at least RHEL 5.x and SLES 10. Also at least for the next year we need to keep on running on Debian Squeeze also. - There needs to be a final, let's call it C-only-release (well, having 1.24 in some would be a good idea anyway) - g-p should keep on running: We got a lot of badly maintained, but good used plugins. If a major rewrite is needed for them, I doubt it will be done for a huge number of.
Cheers, Frank
On 13-11-12 07:50 AM, Frank Lanitz wrote:
I cannot add much to the vala yes/no question, as the only part of ala I've seen by know are Matthews's plugin in g-p. Two or maybe three things are important to me, in case of:
- Geany needs to keep its small memory footprint
Yes, I don't think there'd be an appreciable[1] extra amount of memory, it uses all existing libraries we have loaded in memory anyway, and Vala has special annotations and stuff to tailor the generated C code for when you need to optimize for special cases.
- Created code needs to run on all plattforms Geany currently is running
on -- At least I know of *BSD, Solaris,, MacOS X, Windows, Linux and we need to stay compatible with curent stable versions of SLES, RHEL etc. which means at least RHEL 5.x and SLES 10. Also at least for the next year we need to keep on running on Debian Squeeze also.
Yep, it's just GObject code, so anywhere GTK+/GObject runs, the code compiled out of Vala should run just the same.
- There needs to be a final, let's call it C-only-release (well, having
1.24 in some would be a good idea anyway)
+1.
- g-p should keep on running: We got a lot of badly maintained, but good
used plugins. If a major rewrite is needed for them, I doubt it will be done for a huge number of.
Not strictly related to Vala but more to the other thread, I doubt this is feasible/possible with upsetting the plugin API to some degree, given the scope of the changes being discussed there[2]. On the bright side, with the possibility of exposing the plugin API to higher-level, more user-friendly languages (via generatable bindings and such) we could see a boon of nice new plugins, written in much more maintainable languages, by a more diverse class of developers, and much less ability to bring Geany down to a crashing halt with one little pointer mishap :)
Cheers, Matthew Brush
[1]: Of course this is subjective but even just something like using GTK+3 build probably dwarves anything introduced by some additional GObjects generated out of Vala.
[2]: Since so much of Geany's guts/implementation is exposed directly, it'd most likely be impossible to make any non-trivial changes/re-factorings without disturbing the plugin API. And even if we aimed to keep the plugin API mostly stable during the changes, we'd probably end up with maintenance nightmare of all kinds of old backwards compatibility wrappers and such.
I hope I don't have to rewrite my plugins again for this editor ;-) I will admit though, seg faulting all of geany in a plugin gets annoying :-)
Maybe I'm spoiling the party, but like with gnome 2, sometimes sticking with what you have is better than seemingly needless upgrades. I'm running older hardware at home since running linux doesn't require me to upgrade every few years like windows does.
I read an article a while back, sorry I can't remember the source, pointing out how developer's desire to do a rewrite/refactor of code is not a good idea since all regressions and bugs can come back and all of that effort was lost. That said, I'm always suggesting the need for refactoring at every job i've been at, so I may be a hypocrite.
Maybe these comments refer more to the change of direction thread, since it sounds like vala compiles to C anyway, and would just be extending the way we can code things rather than re-writing or re-defining what we are doing.
Thanks,
Steve
On 11/12/2013 03:58 PM, Matthew Brush wrote:
[2]: Since so much of Geany's guts/implementation is exposed directly, it'd most likely be impossible to make any non-trivial changes/re-factorings without disturbing the plugin API. And even if we aimed to keep the plugin API mostly stable during the changes, we'd probably end up with maintenance nightmare of all kinds of old backwards compatibility wrappers and such.
On 13-11-12 03:16 PM, Steven Blatnick wrote:
I hope I don't have to rewrite my plugins again for this editor ;-) I will admit though, seg faulting all of geany in a plugin gets annoying :-)
Maybe I'm spoiling the party, but like with gnome 2, sometimes sticking with what you have is better than seemingly needless upgrades. I'm running older hardware at home since running linux doesn't require me to upgrade every few years like windows does.
I don't think many would argue with you that GNOME2 was vastly superior to the shell thing, but it's a dead-end (except MATE fork of course, which IIRC is using/supporting GTK3 in some capacity).
I read an article a while back, sorry I can't remember the source, pointing out how developer's desire to do a rewrite/refactor of code is not a good idea since all regressions and bugs can come back and all of that effort was lost. That said, I'm always suggesting the need for refactoring at every job i've been at, so I may be a hypocrite.
If it's the article I'm thinking of, it's this: http://www.joelonsoftware.com/articles/fog0000000069.html
But just because some guy wrote it on his blog don't make it automatically true or apply to all projects. IMO of any code I've ever read, Geany's is most due for some re-design/cleanup/re-factoring :)
Maybe these comments refer more to the change of direction thread, since it sounds like vala compiles to C anyway, and would just be extending the way we can code things rather than re-writing or re-defining what we are doing.
Sort of, but it's also a tool that can greatly facilitate the changes being discussed in the other thread.
Cheers, Matthew Brush
[...]
I read an article a while back, sorry I can't remember the source,
pointing out how developer's desire to do a rewrite/refactor of code is not a good idea since all regressions and bugs can come back and all of that effort was lost. That said, I'm always suggesting the need for refactoring at every job i've been at, so I may be a hypocrite.
If it's the article I'm thinking of, it's this: http://www.joelonsoftware.com/articles/fog0000000069.html
But just because some guy wrote it on his blog don't make it automatically true or apply to all projects. IMO of any code I've ever read, Geany's is most due for some re-design/cleanup/re-factoring :)
There is a lot of good industry evidence to support Stevens concern, its far from one blog. But as Matthew points out, any application that has grown organically without a plan is going to need a wash and brush up from time to time. Geany is far from the worst I've seen, and far from the best. The trick is to judge the timing right. If we have equal numbers of upset "Luddites" and upset "fanboys of the new" we might be about right :)
Maybe these comments refer more to the change of direction thread, since
it sounds like vala compiles to C anyway, and would just be extending the way we can code things rather than re-writing or re-defining what we are doing.
Sort of, but it's also a tool that can greatly facilitate the changes being discussed in the other thread.
Its not simply starting to use a new language that will improve things, its the plan for where and how (Vala, C++, Haskell etc) will be used to improve the software design that will give the benefits. And thats indeed what I am trying to get to with the other thread.
Cheers Lex
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13-11-12 05:33 PM, Lex Trotman wrote:
[...]
Maybe these comments refer more to the change of direction thread, since
it sounds like vala compiles to C anyway, and would just be extending the way we can code things rather than re-writing or re-defining what we are doing.
Sort of, but it's also a tool that can greatly facilitate the changes being discussed in the other thread.
Its not simply starting to use a new language that will improve things, its the plan for where and how (Vala, C++, Haskell etc) will be used to improve the software design that will give the benefits. And thats indeed what I am trying to get to with the other thread.
Actually using an easier, more expression, vastly safer, and severly reduced lines of code language would seriously improve things. It would make people not afraid to touch the code/re-factor as new things are added/removed, it facilitate organizing the source code better and more rigourously encapsulated/isolated from the other parts, and it would greatly reduce the amount of manpower and brainpower required to make any significant source code changes.
OT: You keep saying "design" a lot, can you give a concrete example of what you're talking about/thinking of? Like if you had to just off-the-cuff say one thing concretely how you'd personally design/change something (assume you are the sole/BDFL developer), just to make sure we're all talking about the same thing (maybe respond on the other thread, if you're willing).
Cheers, Matthew Brush
Wow, you found the article :-)
From what I've seen of geany, the code looks much better than some code I've seen. It didn't take as long to familiarize myself with the basic structure since the code files are well named and the directory structure is far from deep ;-) One of the reasons I felt so comfortable writing plugins for it is how much easier the code was to read. At least you don't have perl code mixed with java, etc ;-)
I'm a bit wishy-washy on my positions in these threads. Part of me is still healing from the Gnome disaster, and part of me likes moving forward. I hope at least it's good food for thought.
On 11/12/2013 06:16 PM, Matthew Brush wrote:
If it's the article I'm thinking of, it's this: http://www.joelonsoftware.com/articles/fog0000000069.html
But just because some guy wrote it on his blog don't make it automatically true or apply to all projects. IMO of any code I've ever read, Geany's is most due for some re-design/cleanup/re-factoring :)
On 13-11-13 08:21 AM, Steven Blatnick wrote:
Wow, you found the article :-)
From what I've seen of geany, the code looks much better than some code I've seen. It didn't take as long to familiarize myself with the basic structure since the code files are well named and the directory structure is far from deep ;-) One of the reasons I felt so comfortable writing plugins for it is how much easier the code was to read. At least you don't have perl code mixed with java, etc ;-)
To be clear, I don't think Geany's code is actually bad on the whole, it just needs to be ruthlessly cleaned up/re-factored in some places. It's overall layout is good, the individual units/functions are thoughtfully/carefully coded inside, etc. I just think that after many years of no one being able to make major refactorings/changes to the code (90% due to plugin API breakage, I suspect), there's a lot of weird globals and one-off-structures mixed into the code, used to patch functionality onto stuff (for ex. if you change a function to add a parameter, you break the plugin API and/or have to update a bunch of other code, so just add a global shared between two functions), or code that belongs in one file is in another file, and stuff like this.
In addition, there's a lot of lost opportunities to use things which are provided by our toolkit already, that we either don't use because we didn't originally use (GObjects), or that we roll ourselves still or just avoid alltogether because these things weren't available 5 years ago when the toolkit version we "need" to support was current version.
I'm a bit wishy-washy on my positions in these threads. Part of me is still healing from the Gnome disaster, and part of me likes moving forward. I hope at least it's good food for thought.
The difference here is everyone agrees that Geany's UI is awesome and no ones really talking about significant changes on the face, just in the code. It would be more akin to the GTK+2 to 3 transition happening without GNOME-shell in the picture (ie. if GNOME2 just got upgraded to GTK3).
Cheers, Matthew Brush
Am 12.11.2013 23:58, schrieb Matthew Brush:
Not strictly related to Vala but more to the other thread, I doubt this is feasible/possible with upsetting the plugin API to some degree, given the scope of the changes being discussed there[2]. On the bright side, with the possibility of exposing the plugin API to higher-level, more user-friendly languages (via generatable bindings and such) we could see a boon of nice new plugins, written in much more maintainable languages, by a more diverse class of developers, and much less ability to bring Geany down to a crashing halt with one little pointer mishap :)
Well... maybe part of the code restructure of core we could also spent some time to upgrade the plugins.
Cheers, Frank