Hi!
I create this new thread because the original one was not really about this, so please read that thread for some details, particularly my previous mail: http://lists.uvena.de/pipermail/geany-devel/2010-November/003567.html
Although I know it's probably not the best time for such huge changes (Christmas and release coming soon, ...), but now's the news, now's the mail :)
So, now the interesting stuff.
As you (might) already know, I've got the tagmanager to work in memory, opening a little more the way to real-time symbols updating. For convenience, I join the patch here (can be found in the previous thread) as 0001-First-tagmanager-move-to-MIO-I-O.patch.
From here, the next step is to use the in-memory capabilities and
reparse in (almost-)real-time. Here comes two more patches:
1) 0002-Enable-in-memory-tag-parsing.patch which is really tiny and enables in-memory tag parsing
2) 0003-Update-tag-list-on-IDLE-time-right-after-any-documen.patch which updates the tag list on IDLE time after any change in the document. This patch is not really good (allowing a timeout and a user setting would be probably a good idea), but it is here mostly for being able to test.
So with these on, you can test the in-memory tag parsing, and notice that... it updates in real-time, yes, but the symbol list flickers a lot, and it's very annoying. So here comes 5 (!) more patches:
1) 0004-Improve-implementation-of-hide_empty_rows-to-do-all-.patch: this one is not needed, simply improves the implementation of hide_empty_rows() -- note that it may be applied alone too;
2) 0005-Make-TMTag-reference-counted.patch and... 3) ...0006-Provide-a-GType-for-TMTag-and-use-it.patch: these two makes TMTags reference-counted and add a GType for them, allowing the tree tag store to keep a reference to them, so they never become invalid. I needed it for the implementation of the last patch, read ahead;
4) 0007-Don-t-remove-and-add-the-symbols-tree-view-if-we-re-.patch: this ones avoids removing and re-addind the tag view upon update if the final state is the same as the original one, avoiding a part of the flickering. Note that it applies alone as well;
5) and finally, 0008-Update-the-symbol-list-rather-than-clearing-and-re-b.patch: this is the huge part of the thing: it re-implements tag store updating to avoid clearing and re-filling the list, rather updating the rows when possible. Apart avoiding flickering, this also keeps user's selection and folding :) As you might read at the top of the patch, this implementation is probably not the better possible, but avoids lot of refactoring in a code I'm not sure to understand perfectly well (add_tree_tag()) -- note that I suggest another implementation in the patch's comment, and I have a working sample (but not with the symbol list...) if somebody's interested. About this patch, there is a question (as a FIXME in the patch): why did you detached the tag store from the tag view before updating it? Was it for performance reasons or what? I dropped this since it (obviously) led to flickering, and it seems to work well, but I'm wondering.
Well! If you apply all these patches, you should have a working, real-time, in-memory tag parsing that should look good :)
So, what's left? Testing of course, lot of it. Also, for now it doesn't update tag list before the first save (for new documents). I've not investigating the issue yet though.
So I'll stop here, thank you for your time reading and let you test this, right? :)
Regards, Colomban
PS: for the inpatients of you, I included a patch (0000-In-memory-tag-parsing-all-together.patch) that combines all the 8 patches together.
On 19.12.2010 16:05, Colomban Wendling wrote:
So I'll stop here, thank you for your time reading and let you test this, right? :)
Regards,
Great! Do you have an up-to-date public git repo I can clone or do I have to apply all patches by hand? The one on gitorious.org seems out of date.
Best regards.
Le 19/12/2010 16:58, Thomas Martitz a écrit :
On 19.12.2010 16:05, Colomban Wendling wrote:
So I'll stop here, thank you for your time reading and let you test this, right? :)
Regards,
Great! Do you have an up-to-date public git repo I can clone or do I have to apply all patches by hand? The one on gitorious.org seems out of date.
For now I have only a local repository, but perhaps I could push this somewhere in a public place. However, I currently rebase my changes on top of geany's ones (git pull --rebase) for my commits to be on top (make easy to find them, format-patch them, etc), so not sure it's good for a public repo... thought?
About the Gitorious repo, yes it is out-of-date because the repo I cloned from was not updated since June (Jiří?), so not really usable.
So yes, currently I suggest you to apply the patches (or the combined patch), but again, I may push this somewhere.
Regards, Colomban
On 19.12.2010 17:26, Colomban Wendling wrote:
So yes, currently I suggest you to apply the patches (or the combined patch), but again, I may push this somewhere.
I didn't see the combined one, sorry!
Best regards.
Le 19/12/2010 17:42, Thomas Martitz a écrit :
On 19.12.2010 17:26, Colomban Wendling wrote:
So yes, currently I suggest you to apply the patches (or the combined patch), but again, I may push this somewhere.
I didn't see the combined one, sorry!
Seems to be my fault, I shouldn't have prefixed it 0000 (that make it look like the others), sorry.
Le 19/12/2010 16:05, Colomban Wendling a écrit :
[...]
So I'll stop here, thank you for your time reading and let you test this, right? :)
I forgot to link to MIO, the tiny library used for in-memory operations. Obviously, you'll need it: http://gitorious.org/mio
Also, I created a small patch to make the Waf build system work with the changes (thanks Thomas for pointing this out), you can find it joined as 0001-Update-Waf-build-system-form-in-memory-tag-parsing-c.patch
Regards, Colomban
Still me...
In a close topic, I just found how to fix the suffix of anonymous strucs/enums symbols in C-style languages, patch attached.
However, I wonder why it was like it was before, was there a reason? I mean, the variable (contextual_fake_count) pas properly initialized, but in initialize*Parser() (which is called only once per language). I feel weird about this being an accident... I see 3 possibilities: 1) it was actually an accident, fixing it is good; 2) the behavior of the tagmanager changed and initialise*Parser() was used to be called before each parse, so fixing it is good; 3) it was intentional for some reasons, so "fixing" it is probably wrong.
As a possible reason for 3, I'd think that it was perhaps to avoid having two anonymous symbols with the same name in a workspace. But I don't see why it'd be a problem to have those "conflicts", since name clash is not an issue with the TM workspace...
What do you know/think?
Regards, Colomban
On Mon, 20 Dec 2010 23:44:26 +0100, Colomban wrote:
Still me...
In a close topic, I just found how to fix the suffix of anonymous strucs/enums symbols in C-style languages, patch attached.
Fix the suffix? What was wrong?
However, I wonder why it was like it was before, was there a reason? I mean, the variable (contextual_fake_count) pas properly initialized, but in initialize*Parser() (which is called only once per language). I feel weird about this being an accident... I see 3 possibilities:
- it was actually an accident, fixing it is good;
- the behavior of the tagmanager changed and initialise*Parser() was
used to be called before each parse, so fixing it is good; 3) it was intentional for some reasons, so "fixing" it is probably wrong.
As a possible reason for 3, I'd think that it was perhaps to avoid having two anonymous symbols with the same name in a workspace. But I don't see why it'd be a problem to have those "conflicts", since name clash is not an issue with the TM workspace...
What do you know/think?
Not sure. If I read the SVN log correctly, Nick committed it as backport of Anjuta code (svn diff -r1194:1195).
Regards, Enrico
Le 30/01/2011 14:02, Enrico Tröger a écrit :
On Mon, 20 Dec 2010 23:44:26 +0100, Colomban wrote:
Still me...
In a close topic, I just found how to fix the suffix of anonymous strucs/enums symbols in C-style languages, patch attached.
Fix the suffix? What was wrong?
The number used as suffix for anonymous structures and unions. It currently always increase and is never reset to 0. It's not a real problem, but it the tag list get update in live-time, it grows very fast and easily reaches 1000, 5000 or worst -- only depends on the number of reparsing and anonymous enum/structs in the file.
However, I wonder why it was like it was before, was there a reason? I mean, the variable (contextual_fake_count) pas properly initialized, but in initialize*Parser() (which is called only once per language). I feel weird about this being an accident... I see 3 possibilities:
- it was actually an accident, fixing it is good;
- the behavior of the tagmanager changed and initialise*Parser() was
used to be called before each parse, so fixing it is good; 3) it was intentional for some reasons, so "fixing" it is probably wrong.
As a possible reason for 3, I'd think that it was perhaps to avoid having two anonymous symbols with the same name in a workspace. But I don't see why it'd be a problem to have those "conflicts", since name clash is not an issue with the TM workspace...
What do you know/think?
Not sure. If I read the SVN log correctly, Nick committed it as backport of Anjuta code (svn diff -r1194:1195).
Right, thanks for finding the commit! :) However, it doesn't easily tell which of the 3 possibilities is the one, maybe initialize*Parser() used to be called before each and every parsing. Or maybe Anjuta uses a separate process for tag parsing, in which case it isn't a concern since it is automatically reset between parsings?
Cheers, Colomban
On Sun, 30 Jan 2011 14:22:49 +0100, Colomban wrote:
Le 30/01/2011 14:02, Enrico Tröger a écrit :
On Mon, 20 Dec 2010 23:44:26 +0100, Colomban wrote:
Still me...
In a close topic, I just found how to fix the suffix of anonymous strucs/enums symbols in C-style languages, patch attached.
Fix the suffix? What was wrong?
The number used as suffix for anonymous structures and unions. It currently always increase and is never reset to 0. It's not a real problem, but it the tag list get update in live-time, it grows very fast and easily reaches 1000, 5000 or worst -- only depends on the number of reparsing and anonymous enum/structs in the file.
Ah ok. Thanks for clarifying.
However, I wonder why it was like it was before, was there a reason? I mean, the variable (contextual_fake_count) pas properly initialized, but in initialize*Parser() (which is called only once per language). I feel weird about this being an accident... I see 3 possibilities:
- it was actually an accident, fixing it is good;
- the behavior of the tagmanager changed and initialise*Parser()
was used to be called before each parse, so fixing it is good; 3) it was intentional for some reasons, so "fixing" it is probably wrong.
As a possible reason for 3, I'd think that it was perhaps to avoid having two anonymous symbols with the same name in a workspace. But I don't see why it'd be a problem to have those "conflicts", since name clash is not an issue with the TM workspace...
What do you know/think?
Not sure. If I read the SVN log correctly, Nick committed it as backport of Anjuta code (svn diff -r1194:1195).
Right, thanks for finding the commit! :) However, it doesn't easily tell which of the 3 possibilities is the one, maybe initialize*Parser() used to be called before each and every parsing. Or maybe Anjuta uses a separate process for tag parsing, in which case it isn't a concern since it is automatically reset between parsings?
No idea, sorry. But I guess you tested your fix and didn't find any problems? If so, I think we should apply it.
Regards, Enrico
Le 30/01/2011 14:44, Enrico Tröger a écrit :
However, I wonder why it was like it was before, was there a reason? I mean, the variable (contextual_fake_count) pas properly initialized, but in initialize*Parser() (which is called only once per language). I feel weird about this being an accident... I see 3 possibilities:
- it was actually an accident, fixing it is good;
- the behavior of the tagmanager changed and initialise*Parser()
was used to be called before each parse, so fixing it is good; 3) it was intentional for some reasons, so "fixing" it is probably wrong.
As a possible reason for 3, I'd think that it was perhaps to avoid having two anonymous symbols with the same name in a workspace. But I don't see why it'd be a problem to have those "conflicts", since name clash is not an issue with the TM workspace...
What do you know/think?
Not sure. If I read the SVN log correctly, Nick committed it as backport of Anjuta code (svn diff -r1194:1195).
Right, thanks for finding the commit! :) However, it doesn't easily tell which of the 3 possibilities is the one, maybe initialize*Parser() used to be called before each and every parsing. Or maybe Anjuta uses a separate process for tag parsing, in which case it isn't a concern since it is automatically reset between parsings?
No idea, sorry. But I guess you tested your fix and didn't find any problems? If so, I think we should apply it.
Yep, I run this patch since I wrote it, and didn't noticed any problem :)
Cheers, Colomban
On 19.12.2010 16:05, Colomban Wendling wrote:
Hi!
I create this new thread because the original one was not really about this, so please read that thread for some details, particularly my previous mail: http://lists.uvena.de/pipermail/geany-devel/2010-November/003567.html
How's this patch going? It works just fine for me. I hope it can be upstream'd.
Best regards.
On Thu, 20 Jan 2011 20:17:18 +0100, Thomas wrote:
On 19.12.2010 16:05, Colomban Wendling wrote:
Hi!
I create this new thread because the original one was not really about this, so please read that thread for some details, particularly my previous mail: http://lists.uvena.de/pipermail/geany-devel/2010-November/003567.html
How's this patch going? It works just fine for me. I hope it can be upstream'd.
Me too. I didn't have a look at it but it sounds great. Most probably a great new feature in Geany (and a big performance boost for those users working with remote files).
Though I won't manage to review and commit these patches due to lack of spare time :(. Hopefully Nick finds more time.
Regards, Enrico
Hi!
Le 30/01/2011 14:04, Enrico Tröger a écrit :
On Thu, 20 Jan 2011 20:17:18 +0100, Thomas wrote:
On 19.12.2010 16:05, Colomban Wendling wrote:
Hi!
I create this new thread because the original one was not really about this, so please read that thread for some details, particularly my previous mail: http://lists.uvena.de/pipermail/geany-devel/2010-November/003567.html
How's this patch going? It works just fine for me. I hope it can be upstream'd.
Me too. I didn't have a look at it but it sounds great. Most probably a great new feature in Geany (and a big performance boost for those users working with remote files).
Though I won't manage to review and commit these patches due to lack of spare time :(. Hopefully Nick finds more time.
Well so... Nick, have you anything to say about this? Want you to see this merged? Will you have the time to review it? Do you need any additional information? Maybe a repository from where you can pick up the patches would be useful?
Cheers, Colomban
Le 19/12/2010 16:05, Colomban Wendling a écrit :
[...]
Well! If you apply all these patches, you should have a working, real-time, in-memory tag parsing that should look good :)
So, what's left? Testing of course, lot of it. Also, for now it doesn't update tag list before the first save (for new documents). I've not investigating the issue yet though.
So I'll stop here, thank you for your time reading and let you test this, right? :)
I found a few days ago that one of my patches (0006-Provide-a-GType-for-TMTag-and-use-it.patch) introduced 3 quite big memory leaks (some TMTags references never released). Here's the fix (0001-Fix-leaking-tags-when-fetching-them-from-the-symbols-model-.patch). I strongly recommend to any user of my previous patches to apply this one, because the leak can become really visible when working with files with many tags.
Also, while at it I found a small leak in the C tag parser, also joined the fix (0001-Plug-a-memory-leak-in-the-C-tag-parser.patch). This one probably also applies alone.
All these patches may get a little confusing with time, so if a summary mail would be appreciated, I can do it :)
Regards, Colomban
On 12/19/10 07:05, Colomban Wendling wrote:
So I'll stop here, thank you for your time reading and let you test this, right? :)
I've been testing for a little bit and it seems to be working well, symbols go straight into the symbol list immediately without having to save, and auto-complete is updating immediately also. It feels more responsive now and the symbol list doesn't flash at all here.
What would happen with the little MIO library? Would it become an external dependency or should it be statically compiled into Geany? Does it have use outside Geany/Tagmanager (I didn't look at the code)?
Hopefully others test this and it gets added to Geany. It's easy to test, just install MIO from here:
And apply the attached patch and rebuild Geany.
To Colomban, the patch is the one you paste binned to me, is it available from elsewhere, more official, combined like that?
Cheers, Matthew Brush
Hi Matthew,
Which platforms and which languages have you tested with?
Cheers Lex
On 18 February 2011 10:07, Matthew Brush matthewbrush@gmail.com wrote:
On 12/19/10 07:05, Colomban Wendling wrote:
So I'll stop here, thank you for your time reading and let you test this, right? :)
I've been testing for a little bit and it seems to be working well, symbols go straight into the symbol list immediately without having to save, and auto-complete is updating immediately also. It feels more responsive now and the symbol list doesn't flash at all here.
What would happen with the little MIO library? Would it become an external dependency or should it be statically compiled into Geany? Does it have use outside Geany/Tagmanager (I didn't look at the code)?
Hopefully others test this and it gets added to Geany. It's easy to test, just install MIO from here:
And apply the attached patch and rebuild Geany.
To Colomban, the patch is the one you paste binned to me, is it available from elsewhere, more official, combined like that?
Cheers, Matthew Brush
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 18/02/2011 00:21, Lex Trotman a écrit :
Which platforms and which languages have you tested with?
I personally use my patches since I wrote them, so I tried them with mostly C but also Python, SH, Makefile, Vala, PHP and C++ (and probably others, but less).
I didn't saw much problems, and I fixed the ones I found :)
Cheers, Colomban
Le 18/02/2011 00:07, Matthew Brush a écrit :
On 12/19/10 07:05, Colomban Wendling wrote:
So I'll stop here, thank you for your time reading and let you test this, right? :)
I've been testing for a little bit and it seems to be working well, symbols go straight into the symbol list immediately without having to save, and auto-complete is updating immediately also. It feels more responsive now and the symbol list doesn't flash at all here.
Again, thanks for testing! More the people test, more bugs are found (and are fixed :p). And I'm glad you feel good using it :)
What would happen with the little MIO library? Would it become an external dependency or should it be statically compiled into Geany? Does it have use outside Geany/Tagmanager (I didn't look at the code)?
I wrote it only for this particular purpose, so it has no other use (that I know of) yet. I think it should probably be packed in as a static library (or even as simple new files in the tagmanager) to follow Geany's policy on dependencies, at least since its not wide spread.
To Colomban, the patch is the one you paste binned to me, is it available from elsewhere, more official, combined like that?
Not yet, thanks to post it here. However, a patch like this is only useful for testing without bothering to apply many patches in sequence. For reviewing there is way too much changes and no context to (easily) understand everything.
Cheers, Colomban
Le 19/12/2010 16:05, Colomban Wendling a écrit :
[...]
- and finally,
0008-Update-the-symbol-list-rather-than-clearing-and-re-b.patch: this is the huge part of the thing: it re-implements tag store updating to avoid clearing and re-filling the list, rather updating the rows when possible. Apart avoiding flickering, this also keeps user's selection and folding :) As you might read at the top of the patch, this implementation is probably not the better possible, but avoids lot of refactoring in a code I'm not sure to understand perfectly well (add_tree_tag()) -- note that I suggest another implementation in the patch's comment, and I have a working sample (but not with the symbol list...) if somebody's interested. About this patch, there is a question (as a FIXME in the patch): why did you detached the tag store from the tag view before updating it? Was it for performance reasons or what? I dropped this since it (obviously) led to flickering, and it seems to work well, but I'm wondering.
I found a few days ago that my first implementation had serious performance problems with very large token trees [1]. So, there is a patch to improve it (it's still not the implementation I suggested originally, but simply an improvement of the current one), and it is now significantly better [2].
So here's the patch (yet another one :D).
Cheers, Colomban
[1] e.g. a 8000+ lines Vala VAPI file with 6000+ tags took 18s (!!) to update, and a 64000+ lines C file with 9000+ tags took about 10s to update
[2] same files now takes about 250ms for the Vala file and the C one 1600ms (not that good, but it's 64k lines...). Note that with unmodified version of Geany, the same thing takes respectively 400ms and 2700ms, so there's a benefit.
Hi all!
Le 19/12/2010 16:05, Colomban Wendling a écrit :
Hi!
[...]
Well! If you apply all these patches, you should have a working, real-time, in-memory tag parsing that should look good :)
So, what's left? Testing of course, lot of it. Also, for now it doesn't update tag list before the first save (for new documents). I've not investigating the issue yet though.
So I'll stop here, thank you for your time reading and let you test this, right? :)
I'm happy to announce that I've now committed these patches to trunk, with some little improvements -- an option in the Preference dialog to configure it, MIO integrated, better code in some places, etc.
This means two things: 1) you no longer need to use these patches to have the feature, simply use Geany's trunk; 2) if you applied the patches, I suggest you to drop them before updating from trunk, because it's likely you'd get some conflicts.
Don't hesitate to report any bug you find, as usual!
Regards, Colomban
On 03/05/11 15:57, Colomban Wendling wrote:
I'm happy to announce that I've now committed these patches to trunk, with some little improvements -- an option in the Preference dialog to configure it, MIO integrated, better code in some places, etc.
Thank you for working on this, it's *extremely* useful.
Don't hesitate to report any bug you find, as usual!
Only thing to note is this warning during compilation:
sidebar.c: In function 'on_taglist_tree_selection_changed': sidebar.c:889: warning: passing argument 1 of 'tm_tag_unref' discards qualifiers from pointer target type ./../tagmanager/include/tm_tag.h:330: note: expected 'struct TMTag *' but argument is of type 'const struct TMTag *'
Looking at the source, tm_tag_unref() is called on a 'const TMTag *tag', I guess it depends what happens in gtk_tree_model_get(), you would know better than me :)
Thanks again, Matthew Brush (codebrainz)
Le 06/03/2011 11:51, Matthew Brush a écrit :
On 03/05/11 15:57, Colomban Wendling wrote:
I'm happy to announce that I've now committed these patches to trunk, with some little improvements -- an option in the Preference dialog to configure it, MIO integrated, better code in some places, etc.
Thank you for working on this, it's *extremely* useful.
Don't hesitate to report any bug you find, as usual!
Only thing to note is this warning during compilation:
sidebar.c: In function 'on_taglist_tree_selection_changed': sidebar.c:889: warning: passing argument 1 of 'tm_tag_unref' discards qualifiers from pointer target type ./../tagmanager/include/tm_tag.h:330: note: expected 'struct TMTag *' but argument is of type 'const struct TMTag *'
Looking at the source, tm_tag_unref() is called on a 'const TMTag *tag', I guess it depends what happens in gtk_tree_model_get(), you would know better than me :)
Not sure how I missed this one, thanks for reporting :) However it wasn't a big problem, I just forgot to remove the const part in one of the patches.
Cheers, Colomban
On Sun, 06 Mar 2011 00:57:32 +0100, Colomban wrote:
Hi all!
Le 19/12/2010 16:05, Colomban Wendling a écrit :
Hi!
[...]
Well! If you apply all these patches, you should have a working, real-time, in-memory tag parsing that should look good :)
So, what's left? Testing of course, lot of it. Also, for now it doesn't update tag list before the first save (for new documents). I've not investigating the issue yet though.
So I'll stop here, thank you for your time reading and let you test this, right? :)
I'm happy to announce that I've now committed these patches to trunk, with some little improvements -- an option in the Preference dialog to configure it, MIO integrated, better code in some places, etc.
Great stuff!
A few comments: - I fixed the Waf build script and the Windows Makefiles, there were just minor adjustments necessary and now it builds with Waf and on Windows. Yay. - you use va_copy() in MIO. va_copy is C99 while all the other va_* functions are C89. So far, we tried to stay compatible with C89 even though it is old (and it is old, and old). At least some years ago, there were actually users who had to use a C89 compiler. Maybe we should just stop C89 support as we are in 2011 in the meantime...
Most important things is the licence of MIO. I think it's possible to release Geany as GPLv2+ with MIO included even though it's GPLv3. What I don't know is what's the overall licence of the Geany package is then. I'm not that good in licencing stuff :). And where do we need to state Geany contains GPLv3 code?
Regards, Enrico
Am 06.03.2011 14:25, schrieb Enrico Tröger:
On Sun, 06 Mar 2011 00:57:32 +0100, Colomban wrote:
Hi all!
Le 19/12/2010 16:05, Colomban Wendling a écrit :
Hi!
[...]
Well! If you apply all these patches, you should have a working, real-time, in-memory tag parsing that should look good :)
So, what's left? Testing of course, lot of it. Also, for now it doesn't update tag list before the first save (for new documents). I've not investigating the issue yet though.
So I'll stop here, thank you for your time reading and let you test this, right? :)
I'm happy to announce that I've now committed these patches to trunk, with some little improvements -- an option in the Preference dialog to configure it, MIO integrated, better code in some places, etc.
Great stuff!
A few comments:
- I fixed the Waf build script and the Windows Makefiles, there were
just minor adjustments necessary and now it builds with Waf and on Windows. Yay.
- you use va_copy() in MIO. va_copy is C99 while all the other va_*
functions are C89. So far, we tried to stay compatible with C89 even though it is old (and it is old, and old). At least some years ago, there were actually users who had to use a C89 compiler. Maybe we should just stop C89 support as we are in 2011 in the meantime...
Most important things is the licence of MIO. I think it's possible to release Geany as GPLv2+ with MIO included even though it's GPLv3. What I don't know is what's the overall licence of the Geany package is then. I'm not that good in licencing stuff :). And where do we need to state Geany contains GPLv3 code?
Since you link statically, the whole binary package is GPLv3 since GPLv3 is not compatible to v2. For the source distribution it's up to each individual source file.
IMO it would be wiser to put mio GPLv2+ also. If it's ever packaged separately it can be changed to GPLv3.
OTOH I don't suppose you sue each other for GPLv2 vs GPLv3 issues, do you? :)
Best regards.
Am 06.03.2011 15:05, schrieb Thomas Martitz:
Since you link statically, the whole binary package is GPLv3 since GPLv3 is not compatible to v2. For the source distribution it's up to each individual source file.
http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility has a nice overview about this.
Best regards.
Am 06.03.2011 15:08, schrieb Thomas Martitz:
Am 06.03.2011 15:05, schrieb Thomas Martitz:
Since you link statically, the whole binary package is GPLv3 since GPLv3 is not compatible to v2. For the source distribution it's up to each individual source file.
http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility has a nice overview about this.
And this also shows that it doesn't matter whether you link statically or dynamically, so I stand corrected. Incorperating GPLv3 code always implies making the whole project GPLv3 (unless the project is LGPLv2(+), then how linkage is done matters).
Best regards.
On Sun, 06 Mar 2011 15:05:51 +0100, Thomas wrote:
Am 06.03.2011 14:25, schrieb Enrico Tröger:
On Sun, 06 Mar 2011 00:57:32 +0100, Colomban wrote:
Hi all!
Le 19/12/2010 16:05, Colomban Wendling a écrit :
Hi!
[...]
Well! If you apply all these patches, you should have a working, real-time, in-memory tag parsing that should look good :)
So, what's left? Testing of course, lot of it. Also, for now it doesn't update tag list before the first save (for new documents). I've not investigating the issue yet though.
So I'll stop here, thank you for your time reading and let you test this, right? :)
I'm happy to announce that I've now committed these patches to trunk, with some little improvements -- an option in the Preference dialog to configure it, MIO integrated, better code in some places, etc.
Great stuff!
A few comments:
- I fixed the Waf build script and the Windows Makefiles, there were
just minor adjustments necessary and now it builds with Waf and on Windows. Yay.
- you use va_copy() in MIO. va_copy is C99 while all the other va_*
functions are C89. So far, we tried to stay compatible with C89 even though it is old (and it is old, and old). At least some years ago, there were actually users who had to use a C89 compiler. Maybe we should just stop C89 support as we are in 2011 in the meantime...
Most important things is the licence of MIO. I think it's possible to release Geany as GPLv2+ with MIO included even though it's GPLv3. What I don't know is what's the overall licence of the Geany package is then. I'm not that good in licencing stuff :). And where do we need to state Geany contains GPLv3 code?
Since you link statically, the whole binary package is GPLv3 since GPLv3 is not compatible to v2. For the source distribution it's up to each individual source file.
IMO it would be wiser to put mio GPLv2+ also. If it's ever packaged separately it can be changed to GPLv3.
OTOH I don't suppose you sue each other for GPLv2 vs GPLv3 issues, do you? :)
Most likely not, but the licencing isn't only an issue of ourselves but also quite relevant for third parties like these strange guys like users or packagers :D.
Regards, Enrico
Le 06/03/2011 14:25, Enrico Tröger a écrit :
On Sun, 06 Mar 2011 00:57:32 +0100, Colomban wrote:
Hi all!
Le 19/12/2010 16:05, Colomban Wendling a écrit :
Hi!
[...]
Well! If you apply all these patches, you should have a working, real-time, in-memory tag parsing that should look good :)
So, what's left? Testing of course, lot of it. Also, for now it doesn't update tag list before the first save (for new documents). I've not investigating the issue yet though.
So I'll stop here, thank you for your time reading and let you test this, right? :)
I'm happy to announce that I've now committed these patches to trunk, with some little improvements -- an option in the Preference dialog to configure it, MIO integrated, better code in some places, etc.
Great stuff!
A few comments:
- I fixed the Waf build script and the Windows Makefiles, there were
just minor adjustments necessary and now it builds with Waf and on Windows. Yay.
Strange for waf I'm quite sure I tried it... maybe not then. Anyway, thanks for reviewing and fixing these :)
- you use va_copy() in MIO. va_copy is C99 while all the other va_*
functions are C89. So far, we tried to stay compatible with C89 even though it is old (and it is old, and old). At least some years ago, there were actually users who had to use a C89 compiler. Maybe we should just stop C89 support as we are in 2011 in the meantime...
Ah, right... I'll see if I can fix this (e.g. maybe GLib have proper stuff somewhere).
Most important things is the licence of MIO. I think it's possible to release Geany as GPLv2+ with MIO included even though it's GPLv3. What I don't know is what's the overall licence of the Geany package is then. I'm not that good in licencing stuff :). And where do we need to state Geany contains GPLv3 code?
Actually, I relicensed MIO under v2+ for this purpose, but it seems I forgot to import the new COPYING file, my bad. Fixed in SVN now.
Cheers, Colomban
On Sun, 06 Mar 2011 15:29:24 +0100, Colomban wrote:
- you use va_copy() in MIO. va_copy is C99 while all the other va_*
functions are C89. So far, we tried to stay compatible with C89 even though it is old (and it is old, and old). At least some years ago, there were actually users who had to use a C89 compiler. Maybe we should just stop C89 support as we are in 2011 in the meantime...
Ah, right... I'll see if I can fix this (e.g. maybe GLib have proper stuff somewhere).
If not, we might simply drop C89 support.
Most important things is the licence of MIO. I think it's possible to release Geany as GPLv2+ with MIO included even though it's GPLv3. What I don't know is what's the overall licence of the Geany package is then. I'm not that good in licencing stuff :). And where do we need to state Geany contains GPLv3 code?
Actually, I relicensed MIO under v2+ for this purpose, but it seems I forgot to import the new COPYING file, my bad. Fixed in SVN now.
Cool, this makes it way easier :D.
Regards, Enrico
Le 06/03/2011 15:49, Enrico Tröger a écrit :
On Sun, 06 Mar 2011 15:29:24 +0100, Colomban wrote:
- you use va_copy() in MIO. va_copy is C99 while all the other va_*
functions are C89. So far, we tried to stay compatible with C89 even though it is old (and it is old, and old). At least some years ago, there were actually users who had to use a C89 compiler. Maybe we should just stop C89 support as we are in 2011 in the meantime...
Ah, right... I'll see if I can fix this (e.g. maybe GLib have proper stuff somewhere).
If not, we might simply drop C89 support.
I like C89 :) And no worries, it's fixed in SVN now: no more va_copy(), no more vsnprintf(). Thanks for finding this out :)
Most important things is the licence of MIO. I think it's possible to release Geany as GPLv2+ with MIO included even though it's GPLv3. What I don't know is what's the overall licence of the Geany package is then. I'm not that good in licencing stuff :). And where do we need to state Geany contains GPLv3 code?
Actually, I relicensed MIO under v2+ for this purpose, but it seems I forgot to import the new COPYING file, my bad. Fixed in SVN now.
Cool, this makes it way easier :D.
It was exactly my thought, and I had no real reason to chose v3, so... everybody's happy now :)
Cheers, Colomban
On Mon, 07 Mar 2011 03:50:29 +0100, Colomban wrote:
Le 06/03/2011 15:49, Enrico Tröger a écrit :
On Sun, 06 Mar 2011 15:29:24 +0100, Colomban wrote:
- you use va_copy() in MIO. va_copy is C99 while all the other va_*
functions are C89. So far, we tried to stay compatible with C89 even though it is old (and it is old, and old). At least some years ago, there were actually users who had to use a C89 compiler. Maybe we should just stop C89 support as we are in 2011 in the meantime...
Ah, right... I'll see if I can fix this (e.g. maybe GLib have proper stuff somewhere).
If not, we might simply drop C89 support.
I like C89 :) And no worries, it's fixed in SVN now: no more va_copy(), no more vsnprintf(). Thanks for finding this out :)
Just by accident...I just walked over the files to check the includes to ensure we don't miss anything to check for in the build systems. And so stumbled upon va_copy :).
Regards, Enrico