Le 28/10/2010 18:47, Colomban Wendling a écrit :

Le 28/10/2010 18:08, Nick Treleaven a écrit :

...

Hi, I just tried running ./autogen.sh and got this:

checking for GIO... configure: error: Package requirements (gio-2.0) were not met:

No package 'gio-2.0' found ... make[1]: *** [config.status] Error 1

I think this may be due to build/treebrowser.m4 not disabling itself if GIO is not found.

Hum, right. It seems that if the ACTION-IF-NOT-FOUND of PKG_CHECK_MODULES is provided but empty, it still does the default action... Because this dependency isn't necessary.

Anyway, I had a patch to make the build of treebrowser conditional, but wasn't applied yet (AFAICT, Adrian didn't understood the changes enough to make a decision -- and I wouldn't certainly blame him for this, it's quite complicated ATM...). Just needed to update it a bit, so here it is. It includes the fix not to strongly depend on GIO (just put stuff as the ACTION-IF-NOT-FOUND arg, here a notification). If you (Adrian, Nick, whoverer) don't like the full the conditional build, you can just take this part (or I can provide a patch).

woops, the patch for real now.

Le 28/10/2010 19:11, Nick Treleaven a écrit :

On Thu, 28 Oct 2010 18:48:51 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

...

...

I think this may be due to build/treebrowser.m4 not disabling itself if GIO is not found.

Hum, right. It seems that if the ACTION-IF-NOT-FOUND of PKG_CHECK_MODULES is provided but empty, it still does the default action... Because this dependency isn't necessary.

Anyway, I had a patch to make the build of treebrowser conditional, but wasn't applied yet (AFAICT, Adrian didn't understood the changes enough to make a decision -- and I wouldn't certainly blame him for this, it's quite complicated ATM...). Just needed to update it a bit, so here it is. It includes the fix not to strongly depend on GIO (just put stuff as the ACTION-IF-NOT-FOUND arg, here a notification). If you (Adrian, Nick, whoverer) don't like the full the conditional build, you can just take this part (or I can provide a patch).

woops, the patch for real now.

Thanks for the patch, works fine :) I just tried the treebrowser for the first time, looks great.

Please go ahead and apply the patch.

I'm not the Treebrowser author, so I'm not sure I should do it? But if everybody's fine with me committing this, I can do so for sure :) Adrian, any thoughts?

Regards, Colomban

PS: make distcheck on geany-plugins doesn't work, fails on translation extraction, is it a known issue?

On Thu, 28 Oct 2010 19:15:14 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:

PS: make distcheck on geany-plugins doesn't work, fails on translation extraction, is it a known issue?

Not yet, will have a look.

Cheers, Frank

Le 30/10/2010 13:20, Frank Lanitz a écrit :

On Sat, 30 Oct 2010 13:01:07 +0200 Frank Lanitz frank@frank.uvena.de wrote:

...

On Thu, 28 Oct 2010 19:15:14 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

PS: make distcheck on geany-plugins doesn't work, fails on translation extraction, is it a known issue?

Not yet, will have a look.

OK, well. I guess my knowledge about make is too low here to fix this issue. however, this is the error I can reproduce on my local test system.

make[1]: Entering directory `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build' Making check in po make[2]: Entering directory `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build/po' INTLTOOL_EXTRACT=/usr/bin/intltool-extract srcdir=../../po /usr/bin/intltool-update --gettext-package geany-plugins --pot xgettext: Öffnen der Datei »../../po/../updatechecker/src/updatechecker.c« zum Lesen fehlgeschlagen: Datei oder Verzeichnis nicht gefunden ERROR: xgettext failed to generate PO template file. Please consult error message above if there is any. make[2]: *** [geany-plugins.pot] Fehler 1 make[2]: Leaving directory `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build/po' make[1]: *** [check-recursive] Fehler 1 make[1]: Leaving directory `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build' make: *** [distcheck] Fehler 1

I'd better understand with LANG=C :D

Anyway, I searched a little and found the problem, and it's quite simple (no need to be a make guru): updatechecker is not integrated with the Autotools build system, so it doesn't get into the tarball of make dist. Then, make po fails from this tarball because it uses a file that doesn't exist.

I join 2 patches: 1) export GEANY_VERSION so it can be used in plugin's Makefiles 2) properly add updatechecker to the Autotools build system

You can commit them, or I can do it, as you want.

Regards, Colomban

On Mon, 15 Nov 2010 22:58:02 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:

On Mon, 15 Nov 2010 14:04:12 +0100, Colomban wrote:

...

Le 30/10/2010 13:20, Frank Lanitz a écrit :

...

On Sat, 30 Oct 2010 13:01:07 +0200 Frank Lanitz frank@frank.uvena.de wrote:

...

On Thu, 28 Oct 2010 19:15:14 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

PS: make distcheck on geany-plugins doesn't work, fails on translation extraction, is it a known issue?

Not yet, will have a look.

OK, well. I guess my knowledge about make is too low here to fix this issue. however, this is the error I can reproduce on my local test system.

make[1]: Entering directory `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build' Making check in po make[2]: Entering directory `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build/po' INTLTOOL_EXTRACT=/usr/bin/intltool-extract srcdir=../../po /usr/bin/intltool-update --gettext-package geany-plugins --pot xgettext: Öffnen der Datei »../../po/../updatechecker/src/updatechecker.c« zum Lesen fehlgeschlagen: Datei oder Verzeichnis nicht gefunden ERROR: xgettext failed to generate PO template file. Please consult error message above if there is any. make[2]: *** [geany-plugins.pot] Fehler 1 make[2]: Leaving directory `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build/po' make[1]: *** [check-recursive] Fehler 1 make[1]: Leaving directory `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build' make: *** [distcheck] Fehler 1

I'd better understand with LANG=C :D

Anyway, I searched a little and found the problem, and it's quite simple (no need to be a make guru): updatechecker is not integrated with the Autotools build system, so it doesn't get into the tarball of make dist. Then, make po fails from this tarball because it uses a file that doesn't exist.

Agreed.

...

I join 2 patches:

1. export GEANY_VERSION so it can be used in plugin's Makefiles

This would make it compiling but not working. At least not as it should. If the plugin uses the GEANY_VERSION to detect the version of Geany to check against newer versions, this would mean that it always checks with a fixed version of Geany: those which was available at the system where the plugin was compiled. This can be completely independent from the system where Geany with the plugin loaded actually runs.

To solve the problem, I think it'd be necessary to read Geany's version at *runtime* to really get the running version and not the compiled in GEANY_VERSION macro. To do this, probably a new API function is necessary (though I didn't really check if it might be possible already).

I talked with Frank about this already in a private mail, also joining a patch to integrate it in the autotools build. Now he has two patches to choose :).

Well, I leave it up to you. To be honest I do not care much about as well as I don't have any clue about the autotools-stuff. So I cannot say, what's the best way of solve the issue.

Cheers, Frank

On Mon, 15 Nov 2010 23:13:31 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:

Le 15/11/2010 23:06, Frank Lanitz a écrit :

...

On Mon, 15 Nov 2010 22:58:02 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:

...

On Mon, 15 Nov 2010 14:04:12 +0100, Colomban wrote:

...

Le 30/10/2010 13:20, Frank Lanitz a écrit :

...

On Sat, 30 Oct 2010 13:01:07 +0200 Frank Lanitz frank@frank.uvena.de wrote:

...

On Thu, 28 Oct 2010 19:15:14 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:

> PS: make distcheck on geany-plugins doesn't work, fails on > translation extraction, is it a known issue?

Not yet, will have a look.

OK, well. I guess my knowledge about make is too low here to fix this issue. however, this is the error I can reproduce on my local test system.

make[1]: Entering directory `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build' Making check in po make[2]: Entering directory `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build/po' INTLTOOL_EXTRACT=/usr/bin/intltool-extract srcdir=../../po /usr/bin/intltool-update --gettext-package geany-plugins --pot xgettext: Öffnen der Datei »../../po/../updatechecker/src/updatechecker.c« zum Lesen fehlgeschlagen: Datei oder Verzeichnis nicht gefunden ERROR: xgettext failed to generate PO template file. Please consult error message above if there is any. make[2]: *** [geany-plugins.pot] Fehler 1 make[2]: Leaving directory `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build/po' make[1]: *** [check-recursive] Fehler 1 make[1]: Leaving directory `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build' make: *** [distcheck] Fehler 1

I'd better understand with LANG=C :D

Anyway, I searched a little and found the problem, and it's quite simple (no need to be a make guru): updatechecker is not integrated with the Autotools build system, so it doesn't get into the tarball of make dist. Then, make po fails from this tarball because it uses a file that doesn't exist.

Agreed.

...

I join 2 patches:

1. export GEANY_VERSION so it can be used in plugin's Makefiles

This would make it compiling but not working. At least not as it should. If the plugin uses the GEANY_VERSION to detect the version of Geany to check against newer versions, this would mean that it always checks with a fixed version of Geany: those which was available at the system where the plugin was compiled. This can be completely independent from the system where Geany with the plugin loaded actually runs.

To solve the problem, I think it'd be necessary to read Geany's version at *runtime* to really get the running version and not the compiled in GEANY_VERSION macro. To do this, probably a new API function is necessary (though I didn't really check if it might be possible already).

I talked with Frank about this already in a private mail, also joining a patch to integrate it in the autotools build. Now he has two patches to choose :).

Well, I leave it up to you. To be honest I do not care much about as well as I don't have any clue about the autotools-stuff. So I cannot say, what's the best way of solve the issue.

I didn't saw Enrico's patch, but as I understand the thing it is more about updatechecker code change than autotools stuff.

My patches only tries to make the plugin compile, and I think, work as it would work when compiled with Waf (so "as expected"). But if the plugin should not use the compile-time Geany version, my patches should probably be changed a bit (the first become useless, and the second would then have to be updated not to depend on the first).

So... up to you I think :)

Well, I just committed both as they did make sense to me (but in fact, it was more like rolling dice ...). Thanks very much :)

Cheers, Frank

Am 15.11.2010 23:49, schrieb Colomban Wendling:

Le 15/11/2010 23:35, Frank Lanitz a écrit :

...

On Mon, 15 Nov 2010 23:13:31 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 15/11/2010 23:06, Frank Lanitz a écrit :

...

On Mon, 15 Nov 2010 22:58:02 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:

...

On Mon, 15 Nov 2010 14:04:12 +0100, Colomban wrote:

...

Le 30/10/2010 13:20, Frank Lanitz a écrit : > On Sat, 30 Oct 2010 13:01:07 +0200 > Frank Lanitz frank@frank.uvena.de wrote: > >> On Thu, 28 Oct 2010 19:15:14 +0200 >> Colomban Wendling lists.ban@herbesfolles.org wrote: >> >>> PS: make distcheck on geany-plugins doesn't work, fails on >>> translation extraction, is it a known issue? >> Not yet, will have a look. > OK, well. I guess my knowledge about make is too low here to fix > this issue. however, this is the error I can reproduce on my > local test system. > > make[1]: Entering directory > `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build' > Making check in po make[2]: Entering directory > `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build/po' > INTLTOOL_EXTRACT=/usr/bin/intltool-extract > srcdir=../../po /usr/bin/intltool-update --gettext-package > geany-plugins --pot xgettext: Öffnen der Datei > »../../po/../updatechecker/src/updatechecker.c« zum Lesen > fehlgeschlagen: Datei oder Verzeichnis nicht gefunden ERROR: > xgettext failed to generate PO template file. Please consult > error message above if there is any. make[2]: *** > [geany-plugins.pot] Fehler 1 make[2]: Leaving directory > `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build/po' > make[1]: *** [check-recursive] Fehler 1 make[1]: Leaving > directory > `/daten/quellen/git/geany-plugins/geany-plugins/geany-plugins-0.20/_build' > make: *** [distcheck] Fehler 1 I'd better understand with LANG=C :D

Anyway, I searched a little and found the problem, and it's quite simple (no need to be a make guru): updatechecker is not integrated with the Autotools build system, so it doesn't get into the tarball of make dist. Then, make po fails from this tarball because it uses a file that doesn't exist.

Agreed.

...

I join 2 patches:

1. export GEANY_VERSION so it can be used in plugin's Makefiles

This would make it compiling but not working. At least not as it should. If the plugin uses the GEANY_VERSION to detect the version of Geany to check against newer versions, this would mean that it always checks with a fixed version of Geany: those which was available at the system where the plugin was compiled. This can be completely independent from the system where Geany with the plugin loaded actually runs.

To solve the problem, I think it'd be necessary to read Geany's version at *runtime* to really get the running version and not the compiled in GEANY_VERSION macro. To do this, probably a new API function is necessary (though I didn't really check if it might be possible already).

I talked with Frank about this already in a private mail, also joining a patch to integrate it in the autotools build. Now he has two patches to choose :).

Well, I leave it up to you. To be honest I do not care much about as well as I don't have any clue about the autotools-stuff. So I cannot say, what's the best way of solve the issue.

I didn't saw Enrico's patch, but as I understand the thing it is more about updatechecker code change than autotools stuff.

My patches only tries to make the plugin compile, and I think, work as it would work when compiled with Waf (so "as expected"). But if the plugin should not use the compile-time Geany version, my patches should probably be changed a bit (the first become useless, and the second would then have to be updated not to depend on the first).

So... up to you I think :)

Well, I just committed both as they did make sense to me (but in fact, it was more like rolling dice ...).

Well... cool then ^^ Anyway, I'd think that updating Updatechecker to use a runtime Geany version is probably another task than making it compile -- though, it is true that a part of the build system update would be useless after the update.

Well, agreed. In most cases it should work fine with compiled in version number as most cases the API/ABI is changing with some major release. But of course this will go into trouble with minor releases as we had them with 0.19.1 or if anybody is remembering the 10.x ones :)

Well, however. I think a simple function which returns the version string into plugin API would be enought or am I wrong? something that is just doing a return GEANY_VERSION;

Cheers, Frank

On Tue, 16 Nov 2010 15:13:03 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:

Le 16/11/2010 09:23, Frank Lanitz a écrit :

...

Well, agreed. In most cases it should work fine with compiled in version number as most cases the API/ABI is changing with some major release. But of course this will go into trouble with minor releases as we had them with 0.19.1 or if anybody is remembering the 10.x ones :)

Well, however. I think a simple function which returns the version string into plugin API would be enought or am I wrong? something that is just doing a return GEANY_VERSION;

I think it is better to return major, minor and micro version (or something that fits the versionning scheme) as plain integers. The advantage is that it becomes easy to use this version for any check, where a string is quite tedious to use. geany_get_version(gint *major, gint *minor, gint *micro) for example, or 3 variables, not sure.

Well, even it looks a bit dirty in my eyes (maybe we can put this into a struct) it would solve users from use the parsing over and over again as I did inside updatechecker with static void parse_version_string(const gchar *ver, gint *major, gint *minor, gint *micro, gchar **extra)

So I'm pro ;)

Cheers, FRank

Le 16/11/2010 23:32, Lex Trotman a écrit :

On 17 November 2010 03:11, Frank Lanitz frank@frank.uvena.de wrote:

...

On Tue, 16 Nov 2010 15:13:03 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 16/11/2010 09:23, Frank Lanitz a écrit :

...

Well, agreed. In most cases it should work fine with compiled in version number as most cases the API/ABI is changing with some major release. But of course this will go into trouble with minor releases as we had them with 0.19.1 or if anybody is remembering the 10.x ones :)

Well, however. I think a simple function which returns the version string into plugin API would be enought or am I wrong? something that is just doing a return GEANY_VERSION;

I think it is better to return major, minor and micro version (or something that fits the versionning scheme) as plain integers. The advantage is that it becomes easy to use this version for any check, where a string is quite tedious to use. geany_get_version(gint *major, gint *minor, gint *micro) for example, or 3 variables, not sure.

Well, even it looks a bit dirty in my eyes (maybe we can put this into a struct) it would solve users from use the parsing over and over again as I did inside updatechecker with static void parse_version_string(const gchar *ver, gint *major, gint *minor, gint *micro, gchar **extra)

So I'm pro ;)

Just a question, shouldn't plugins be checking the ABI version was what they conpiled with not the Geany version?

I think this is not the question: Updatechecker wants to know the Geany version to check whether there is a newer one, it's not a plugin development need, but a goal.

Of course, to check a functionality at runtime, a plugin should use the API version (and then getting the Geany version is quite specific).

BTW since you speak of this, I think API version should be made more visible. The API version in which each function appeared should appear in the doc rather than the Geany version it appeared in. This would make easier for plugin developers to know for which version check. Also, perhaps a compile-time check would be interesting, it would allow things like "if Geany version is too old for this, it's not fatal, we will do without" -- stop me if it already exists.

Regards, Colomban

Le 17/11/2010 01:03, Lex Trotman a écrit :

On 17 November 2010 10:22, Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 16/11/2010 23:32, Lex Trotman a écrit :

...

On 17 November 2010 03:11, Frank Lanitz frank@frank.uvena.de wrote:

...

On Tue, 16 Nov 2010 15:13:03 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 16/11/2010 09:23, Frank Lanitz a écrit :

...

Well, agreed. In most cases it should work fine with compiled in version number as most cases the API/ABI is changing with some major release. But of course this will go into trouble with minor releases as we had them with 0.19.1 or if anybody is remembering the 10.x ones :)

Well, however. I think a simple function which returns the version string into plugin API would be enought or am I wrong? something that is just doing a return GEANY_VERSION;

I think it is better to return major, minor and micro version (or something that fits the versionning scheme) as plain integers. The advantage is that it becomes easy to use this version for any check, where a string is quite tedious to use. geany_get_version(gint *major, gint *minor, gint *micro) for example, or 3 variables, not sure.

Well, even it looks a bit dirty in my eyes (maybe we can put this into a struct) it would solve users from use the parsing over and over again as I did inside updatechecker with static void parse_version_string(const gchar *ver, gint *major, gint *minor, gint *micro, gchar **extra)

So I'm pro ;)

Just a question, shouldn't plugins be checking the ABI version was what they conpiled with not the Geany version?

I think this is not the question: Updatechecker wants to know the Geany version to check whether there is a newer one, it's not a plugin development need, but a goal.

Ah Ha!! I see, I'd missed the actual purpose of the plugin :-D

In that case I guess the three ints and some chars would be best for relative comparison, assuming thats how Geany is going to continue to do its versioning.

...

Of course, to check a functionality at runtime, a plugin should use the API version (and then getting the Geany version is quite specific).

BTW since you speak of this, I think API version should be made more visible. The API version in which each function appeared should appear in the doc rather than the Geany version it appeared in.

Agree. But also "in which version did the functions parameters and/or semantics change" is more important. If that change is newer than the plugin then the plugin shouldn't try to run.

I think that a simple update of the API version for this function is good enough for this. And anyway, I think that the current API scheme of Geany doesn't allow such changes without a function rename, so it would probably never happen, would it?

This would make

...

easier for plugin developers to know for which version check. Also, perhaps a compile-time check would be interesting, it would allow things like "if Geany version is too old for this, it's not fatal, we will do without" -- stop me if it already exists.

The plugin only depends on the ABI it wants to use, so in a perfect world it would be able to check the each function it wants to call for the version in which it last changed. This will allow plugins to continue to operate as long as possible without rebuilding.

At initialisation the plugin could simply present a list of functions and Geany could then return a list of versions for them (from a table extracted from the doc comments). It is then up to the plugin to avoid functions it can't use, eg by not running at all or by limiting functionality to avoid using functions that are too new, too old or don't exist.

I think this is probably overkill, and would make the plugin development really hard it it is a runtime check. Why? because you loose all the compile-time safety that tells us if we use an undefined symbol, if it isn't compatible and so on. It would need the plugin to something like "dynamically load Geany", while assuming that Geany has an unstable API. This is IMHO really complicated to deal with correctly, and I don't think that not having to recompile a plugin is a sufficient gain for such a pain.

I personally think that protecting code with something like #if GEANY_CHECK_API_VERSION(421) ... #endif is enough. Saying this makes me remember that Geany uses a macro for each function in the plugin API, so it is actually already possible to do a similar check: #ifdef a_geany_function ... #endif

Well... this gives lot of stuff to think about :D

My 2 cents, Colomban

Le 17/11/2010 02:17, Lex Trotman a écrit :

...

It would need the plugin to something like "dynamically load Geany", while assuming that Geany has an unstable API. This is IMHO really complicated to deal with correctly, and I don't think that not having to recompile a plugin is a sufficient gain for such a pain.

Recompiling is not (much of?) a pain for us developers, but it is a pain for other people who use Geany for non-C development. They might not even have a C development environment, especially on Windows. Using Geany or plugins should not be dependent on being able to build it.

Under a Linux distribution, it is most likely a non-power-user is using it's distribution's packages for both Geany and plugins, and the distribution should take care of such things. Under Windows, I don't think that upgrading plugins from a binary installer is much work for somebody that upgrades it's Geany.

An I personally feel quite OK about plugins for a software to evolve together with the software. But it's my opinion.

The static version dependency means that either plugin development is stalled if it needs newer API, or older versions of Geany are not supported.

In fact even if no new features are used, a new geany_plugins release will no longer run with an old version.

Why? AFAIK as far as the Geany ABI hasn't changed, it should still work if the plugin depend on a compatible API number, shouldn't it?

To support older versions of Geany, plugin devs need to maintain multiple versions of their plugin and backport bugfixes, lotsa work and doesn't fit into geany_plugins combined releases. I'm not talking about very old versions of Geany, the problem happens immediately at release of a new version. Geany maintains compatibility with *ancient* versions of GTK, why then does it require itself to be the latest version?

Well, well, well... I don't really feel good with the idea of a plugin that removes a feature of itself when running with some versions of Geany. I don't think it is easily understandable for users that to get a feature of a plugin they got to upgrade Geany. But well, why not.

But does new API really matters? If a plugin writer wants to keep being compatible with old Geany versions, she just have not to use new API -- as far as the ABI hasn't changed.

...

I personally think that protecting code with something like #if GEANY_CHECK_API_VERSION(421) ... #endif is enough.

Yes if you are compiling.

...

Saying this makes me remember that Geany uses a macro for each function in the plugin API, so it is actually already possible to do a similar check: #ifdef a_geany_function ... #endif

Well... this gives lot of stuff to think about :D

Yes, isn't it past your bedtime again??

No, but close to it :D

Regards, Colomban

On 18 November 2010 03:36, Colomban Wendling lists.ban@herbesfolles.org wrote:

Le 17/11/2010 02:17, Lex Trotman a écrit :

...

...

It would need the plugin to something like "dynamically load Geany", while assuming that Geany has an unstable API. This is IMHO really complicated to deal with correctly, and I don't think that not having to recompile a plugin is a sufficient gain for such a pain.

Recompiling is not (much of?) a pain for us developers, but it is a pain for other people who use Geany for non-C development.  They might not even have a C development environment, especially on Windows. Using Geany or plugins should not be dependent on being able to build it.

Under a Linux distribution, it is most likely a non-power-user is using it's distribution's packages for both Geany and plugins, and the distribution should take care of such things. Under Windows, I don't think that upgrading plugins from a binary installer is much work for somebody that upgrades it's Geany.

An I personally feel quite OK about plugins for a software to evolve together with the software. But it's my opinion.

But they don't. Not even all the plugins in Geany-plugins.

...

The static version dependency means that either plugin development is stalled if it needs newer API, or older versions of Geany are not supported.

In fact even if no new features are used, a new geany_plugins release will no longer run with an old version.

Why? AFAIK as far as the Geany ABI hasn't changed, it should still work if the plugin depend on a compatible API number, shouldn't it?

ATM how does an older plugin know that a new API is compatible unless its been re-compiled??

...

To support older versions of Geany, plugin devs need to maintain multiple versions of their plugin and backport bugfixes, lotsa work and doesn't fit into geany_plugins combined releases.  I'm not talking about very old versions of Geany, the problem happens immediately at release of a new version.  Geany maintains compatibility with *ancient* versions of GTK, why then does it require itself to be the latest version?

Well, well, well... I don't really feel good with the idea of a plugin that removes a feature of itself when running with some versions of Geany. I don't think it is easily understandable for users that to get a feature of a plugin they got to upgrade Geany. But well, why not.

I guess I'm more thinking that a new plugin feature won't be available if it needs a feature that an older Geany doesn't support rather than removal of existing features.

But does new API really matters? If a plugin writer wants to keep being compatible with old Geany versions, she just have not to use new API -- as far as the ABI hasn't changed.

But ATM how does a plugin check that without being re-compiled?

...

...

I personally think that protecting code with something like  #if GEANY_CHECK_API_VERSION(421)  ...  #endif is enough.

Yes if you are compiling.

...

Saying this makes me remember that Geany uses a macro for each function in the plugin API, so it is actually already possible to do a similar check:  #ifdef a_geany_function  ...  #endif

Well... this gives lot of stuff to think about :D

Yes, isn't it past your bedtime again??

No, but close to it :D

Cheers Lex

Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

On 18 November 2010 10:16, Colomban Wendling lists.ban@herbesfolles.org wrote:

Le 17/11/2010 23:09, Lex Trotman a écrit :

...

On 18 November 2010 03:36, Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 17/11/2010 02:17, Lex Trotman a écrit :

...

...

It would need the plugin to something like "dynamically load Geany", while assuming that Geany has an unstable API. This is IMHO really complicated to deal with correctly, and I don't think that not having to recompile a plugin is a sufficient gain for such a pain.

Recompiling is not (much of?) a pain for us developers, but it is a pain for other people who use Geany for non-C development.  They might not even have a C development environment, especially on Windows. Using Geany or plugins should not be dependent on being able to build it.

Under a Linux distribution, it is most likely a non-power-user is using it's distribution's packages for both Geany and plugins, and the distribution should take care of such things. Under Windows, I don't think that upgrading plugins from a binary installer is much work for somebody that upgrades it's Geany.

An I personally feel quite OK about plugins for a software to evolve together with the software. But it's my opinion.

But they don't.  Not even all the plugins in Geany-plugins.

...

...

The static version dependency means that either plugin development is stalled if it needs newer API, or older versions of Geany are not supported.

In fact even if no new features are used, a new geany_plugins release will no longer run with an old version.

Why? AFAIK as far as the Geany ABI hasn't changed, it should still work if the plugin depend on a compatible API number, shouldn't it?

ATM how does an older plugin know that a new API is compatible unless its been re-compiled??

Well, if the API is there it can guess it's compatible, can't it? So as a C think if all plugin's symbols are resolved, it should work.

Yes but it can only know its there at compile time, and I'm not so sure its a good idea to assume compatibility.

...

...

...

To support older versions of Geany, plugin devs need to maintain multiple versions of their plugin and backport bugfixes, lotsa work and doesn't fit into geany_plugins combined releases.  I'm not talking about very old versions of Geany, the problem happens immediately at release of a new version.  Geany maintains compatibility with *ancient* versions of GTK, why then does it require itself to be the latest version?

Well, well, well... I don't really feel good with the idea of a plugin that removes a feature of itself when running with some versions of Geany. I don't think it is easily understandable for users that to get a feature of a plugin they got to upgrade Geany. But well, why not.

I guess I'm more thinking that a new plugin feature won't be available if it needs a feature that an older Geany doesn't support rather than removal of existing features.

Hum... yes, it is what I thought: given version V of Geany and version V' of the plugin, if user wants feature F that exists in version V' of the plugin, she has to upgrade her Geany to version V''.

Yes, we can't get around that, but ATM the plugin has no way of also working with the previous version of Geany albeit without feature F.

...

...

But does new API really matters? If a plugin writer wants to keep being compatible with old Geany versions, she just have not to use new API -- as far as the ABI hasn't changed.

But ATM how does a plugin check that without being re-compiled?

What what what? :D If a plugin compiles with version 0.18 and Geany doesn't detect a problem when comparing the ABI version it was built against, it IS compatible, no? And if the same plugin is compiled against Geany 0.19 (assuming the ABI hasn't changed), it will still work with Geany 0.18...

Yes, but ANY change to the API/ABI even in areas that the plugin doesn't use changes the version and makes the plugin incompatible with older Geany.

Cheers Lex

Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

On 19 November 2010 03:16, Colomban Wendling lists.ban@herbesfolles.org wrote:

Le 18/11/2010 01:18, Lex Trotman a écrit :

...

On 18 November 2010 10:16, Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 17/11/2010 23:09, Lex Trotman a écrit :

...

On 18 November 2010 03:36, Colomban Wendling lists.ban@herbesfolles.org wrote:

...

But does new API really matters? If a plugin writer wants to keep being compatible with old Geany versions, she just have not to use new API -- as far as the ABI hasn't changed.

But ATM how does a plugin check that without being re-compiled?

What what what? :D If a plugin compiles with version 0.18 and Geany doesn't detect a problem when comparing the ABI version it was built against, it IS compatible, no? And if the same plugin is compiled against Geany 0.19 (assuming the ABI hasn't changed), it will still work with Geany 0.18...

Yes, but ANY change to the API/ABI even in areas that the plugin doesn't use changes the version and makes the plugin incompatible with older Geany.

Okay, I think I got your point, reading this and some other mails in this thread: you want to prevent ABI bumps to break plugins that are not directly affected.

Yes, an ABI bump break every plugin that was compiled before it. If it isn't affected, it has to be rebuild.

But I'm with Enrico here: I don't think ABI bumps will/should happen often.

That means as soon as you expose something its frozen, you have to get it complete and exactly right the first time, no incremental development. I think thats setting a pretty large barrier for a small project like Geany.

And as more goes into plugins the difficulty increases, it doesn't decrease.

And finally, if you want to protect from ABI breakage, you have to protect every symbol, not only functions, but also structures and structure members (even enums values may need this then).

Each function in *Funcs in plugindata.h

Just structures (ie each pointer in GeanyData), no need to protect individual members because over time structures should be removed from the API because they expose implementation details that are then frozen. They should use accessors to read/write only the information the plugin needs and new fields should be exposed that way rather than in the structures.

Similarly types internal to Geany should not be exposed, except perhaps as an opaque typename needed for some functions (ie returned by one call and passed to another).

Enums don't need it since changing one changes the struct/function that uses it so they are protetcted that way. (if they are not used in a visible struct/function why are they exposed??)

So... while I'm not (and never was) against having a very flexible dependency mechanism, I still think it's overkill, and won't it to make everything complicated. If backbard compatibility is this important, I'd prefer to simply keep the whole ABI stable, even if it may cost some deprecated things and some "old and now useless stuff": it isn't really nice either, but still seems less bloated to me.

But I'd be curious to see how you would implement this :)

Well this is a first thought only :-)

Have a set of structs parallel to GeanyData and *Funcs structures, with same member names and all unsigned ints. Lets call them say GeanyDataVersion and *FuncsVersion. Collectively called the *Version structs.

Also have API and ABI numbers for GeanyData and *Funcs struct, that handles additions (changes API) and removals (changes ABI) to the struct itself. This needs only one struct with members named after the structures, lets call it the StructVersions struct.

plugindata.h has #defines for each value to go in the *Version structs eg #define GEANYAPPVERSION 12345 to use the first struct in GeanyData as the example and similar symbols for the StructVersions values. This allows plugins to still do static checks if they want to.

plugins.c has the *Version and StructVersions structs initialised with these symbols.

Each plugin has an array of:

struct detailed_versions_needed { size_t item_to_check; // offset of a member of GeanyDataVersion or *FuncsVersion, NULL to end unsigned int required_version; // version must equal this };

initialised with the required offsets and versions, and the plugin also has a StructVersion struct initialised as required.

A macro PLUGIN_DETAILED_VERSION_CHECK defines a function that runs through the array and the struct doing the checks.

Geany checks if the plugin has the plugin_detailed_version_check symbol and only calls it if it does, otherwise it calls the normal plugin_version_check.

Something like this approach does not force plugins to change immediately, it can happen over time. Also it allows a simple tool to check that a plugin dev has listed all the functions and structs she used.

We should not force immediate change on the plugins, but the plugins won't start changing until the facility is made available :-) and the sooner it is the easier for new plugin developers.

Cheers Lex

Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

On Fri, 19 Nov 2010 18:37:37 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:

On Fri, 19 Nov 2010 09:56:21 +1100 Lex Trotman elextr@gmail.com wrote:

...

Just structures (ie each pointer in GeanyData), no need to protect individual members because over time structures should be removed from the API because they expose implementation details that are then frozen. They should use accessors to read/write only the information the plugin needs and new fields should be exposed that way rather than in the structures.

I haven't been following this thread (subject no longer applies, methinks), but I don't really think we should add accessors for all fields.

After thinking a bit more about this during weekend, I agree.

Cheers, Frank

On Mon, 22 Nov 2010 08:24:13 +1100 Lex Trotman elextr@gmail.com wrote:

, but I don't really think we should add accessors for

...

...

all fields.

@Nick,

Well you have in the past commented negatively about making structures visible. As you sagely said either you constrain your implementation or yuo have to spend the effort "faking" the structure for plugin purposes.

It depends on what fields we're talking about. For a getter function for a pref, there's not much you can do if the behaviour of the pref changes or the pref is removed, the function will be no better than the field.

Getting groups of prefs is different. One solution for overridden prefs is editor_get_indent_prefs(): http://www.geany.org/manual/reference/editor_8h.html#db89e1ea679531fb35ba13e...

Perhaps this would be a good approach for other pref groups.

Fields in the API generally should not be set. There is a stronger argument for adding setter functions than getter functions, if plugins need to set something.

I'm not saying any of this needs to happen yesterday, but if we don't start thinking about it nothing will ever happen. And as more plugins are being made, adding significant capability to Geany the problems of updating them in sync will get worse.

Nick

On Tue, 23 Nov 2010 09:20:35 +1100 Lex Trotman elextr@gmail.com wrote:

...

...

, but I don't really think we should add accessors for

...

...

all fields.

@Nick,

Well you have in the past commented negatively about making structures visible.  As you sagely said either you constrain your implementation or yuo have to spend the effort "faking" the structure for plugin purposes.

It depends on what fields we're talking about. For a getter function for a pref, there's not much you can do if the behaviour of the pref changes or the pref is removed, the function will be no better than the field.

Yes semantic changes breaks the item, but ATM all you can do is break the whole ABI.

If a field is removed from a structure the getter function may still be able to compute it or get it from the new location instead of another structure needing to be exposed.

True, but we have a lot of fields in the API, it seems a bit ugly to have tons of getter functions.

...

Getting groups of prefs is different. One solution for overridden prefs is editor_get_indent_prefs(): http://www.geany.org/manual/reference/editor_8h.html#db89e1ea679531fb35ba13e...

Perhaps this would be a good approach for other pref groups.

Yes, as time and inclination permits.

I have been meaning to add editor_get_prefs() as a future-proofing function. It would be much tidier than core functions like editor_get_long_line_*() which are specialized and just check whether to use project or global prefs.

Nick

On Wed, 24 Nov 2010 09:09:57 +1100 Lex Trotman elextr@gmail.com wrote:

...

...

...

It depends on what fields we're talking about. For a getter function for a pref, there's not much you can do if the behaviour of the pref changes or the pref is removed, the function will be no better than the field.

Yes semantic changes breaks the item, but ATM all you can do is break the whole ABI.

If a field is removed from a structure the getter function may still be able to compute it or get it from the new location instead of another structure needing to be exposed.

True, but we have a lot of fields in the API,

But you only need getter and setters for ones that are used, the sooner its started the less plugins there will be, the less fields used and the less effort involved to change things. Leave it too late and it will be logistically impossible :-(

it seems a bit ugly to

...

have tons of getter functions.

True but they can be logically grouped with one function handling multiple fields of the same type. Or where several fields are logically used together, one function may return multiple fields at once. In other words the API can be tailored for the users, not reflect the current internal implementation.

Also getters can return copies of data so that accidental (or deliberate) sets are not possible.

This is basically what editor_get_indent_prefs() does.

This is of course in line with the direction of GTK.

GTK has to be more robust. The plugin API was designed for easy maintenance.

...

...

...

Getting groups of prefs is different. One solution for overridden prefs is editor_get_indent_prefs(): http://www.geany.org/manual/reference/editor_8h.html#db89e1ea679531fb35ba13e...

Perhaps this would be a good approach for other pref groups.

Yes, as time and inclination permits.

I have been meaning to add editor_get_prefs() as a future-proofing function. It would be much tidier than core functions like editor_get_long_line_*() which are specialized and just check whether to use project or global prefs.

Agree.

I've added an implementation to the core. It doesn't have all the per-document overrides yet so I haven't exposed it to the API.

Nick

On 23 November 2010 02:36, Colomban Wendling lists.ban@herbesfolles.org wrote:

Le 18/11/2010 23:56, Lex Trotman a écrit :

...

On 19 November 2010 03:16, Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 18/11/2010 01:18, Lex Trotman a écrit :

...

On 18 November 2010 10:16, Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 17/11/2010 23:09, Lex Trotman a écrit :

...

On 18 November 2010 03:36, Colomban Wendling lists.ban@herbesfolles.org wrote: > But does new API really matters? If a plugin writer wants to keep being > compatible with old Geany versions, she just have not to use new API -- > as far as the ABI hasn't changed. >

But ATM how does a plugin check that without being re-compiled?

What what what? :D If a plugin compiles with version 0.18 and Geany doesn't detect a problem when comparing the ABI version it was built against, it IS compatible, no? And if the same plugin is compiled against Geany 0.19 (assuming the ABI hasn't changed), it will still work with Geany 0.18...

Yes, but ANY change to the API/ABI even in areas that the plugin doesn't use changes the version and makes the plugin incompatible with older Geany.

Okay, I think I got your point, reading this and some other mails in this thread: you want to prevent ABI bumps to break plugins that are not directly affected.

Yes, an ABI bump break every plugin that was compiled before it. If it isn't affected, it has to be rebuild.

But I'm with Enrico here: I don't think ABI bumps will/should happen often.

That means as soon as you expose something its frozen, you have to get it complete and exactly right the first time, no incremental development.  I think thats setting a pretty large barrier for a small project like Geany.

Not exactly. You can still happen members to structs (but see below for thoughts about structs) without breaking the A[PB]I, and I think that this doesn't really apply for functions. In a library POV, I think that functions' signature should be got right the first time (it isn't easy, but…); and I still think that it'd be overkill to handle such changes from a plugin.

Well you can of course declare that any function in the API *is* correct and add another function to accommodate the changes.

...

And as more goes into plugins the difficulty increases, it doesn't decrease.

...

And finally, if you want to protect from ABI breakage, you have to protect every symbol, not only functions, but also structures and structure members (even enums values may need this then).

Each function in *Funcs in plugindata.h

Just structures (ie each pointer in GeanyData), no need to protect individual members because over time structures should be removed from the API because they expose implementation details that are then frozen.  They should use accessors to read/write only the information the plugin needs and new fields should be exposed that way rather than in the structures.

I agree, exposing members is generally a pain.

...

Similarly types internal to Geany should not be exposed, except perhaps as an opaque typename needed for some functions (ie returned by one call and passed to another).

Agreed.

...

Enums don't need it since changing one changes the struct/function that uses it so they are protetcted that way. (if they are not used in a visible struct/function why are they exposed??)

Well, right.

...

...

So... while I'm not (and never was) against having a very flexible dependency mechanism, I still think it's overkill, and won't it to make everything complicated. If backbard compatibility is this important, I'd prefer to simply keep the whole ABI stable, even if it may cost some deprecated things and some "old and now useless stuff": it isn't really nice either, but still seems less bloated to me.

But I'd be curious to see how you would implement this :)

Well this is a first thought only :-)

Have a set of structs parallel to GeanyData and *Funcs structures, with same member names and all unsigned ints.  Lets call them say GeanyDataVersion and *FuncsVersion. Collectively called the *Version structs.

Also have API and ABI numbers for GeanyData and *Funcs struct, that handles additions (changes API) and removals (changes ABI) to the struct itself.  This needs only one struct with members named after the structures, lets call it the StructVersions struct.

plugindata.h has #defines for each value to go in the *Version structs eg #define GEANYAPPVERSION 12345 to use the first struct in GeanyData as the example and similar symbols for the StructVersions values. This allows plugins to still do static checks if they want to.

plugins.c has the *Version and StructVersions structs initialised with these symbols.

Each plugin has an array of:

struct detailed_versions_needed {     size_t item_to_check;              // offset of a member of GeanyDataVersion or *FuncsVersion, NULL to end     unsigned int required_version;  // version must equal this };

initialised with the required offsets and versions, and the plugin also has a StructVersion struct initialised as required.

A macro PLUGIN_DETAILED_VERSION_CHECK defines a function that runs through the array and the struct doing the checks.

Geany checks if the plugin has the plugin_detailed_version_check symbol and only calls it if it does, otherwise it calls the normal plugin_version_check.

Something like this approach does not force plugins to change immediately, it can happen over time.  Also it allows a simple tool to check that a plugin dev has listed all the functions and structs she used.

Wouldn't manually checking for /everything/ be a PITA? Or at least, provide a trivial way to say "if this functions isn't present, I can't run". Or I miss something?

I guess the word "tool" in the preceding sentence :-)

It would not be hard to extract the list of names in the interface from plugindata.h and geanyfunctions.h and find all that occur in the plugin.

But the general consensus seems to be that people are happy to use static versioning and to keep conpiling (well it is the developer list) and either manually checking what has changed in an API/ABI break or (more probably) to hope that C's leaky type system catches any problem.

Cheers Lex

...

We should not force immediate change on the plugins, but the plugins won't start changing until the facility is made available :-) and the sooner it is the easier for new plugin developers.

Right.

Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

On 24 November 2010 23:54, Nick Treleaven nick.treleaven@btinternet.com wrote:

On Tue, 23 Nov 2010 09:09:59 +1100 Lex Trotman elextr@gmail.com wrote:

...

But the general consensus seems to be that people are happy to use static versioning and to keep conpiling (well it is the developer list) and either manually checking what has changed in an API/ABI break or (more probably) to hope that C's leaky type system catches any problem.

ABI checking is automatic, not manual (assuming the PLUGIN_VERSION_CHECK() macro is used and not manually implemented wrongly).

What I meant was that if the version fails, my guess is that most plugin devs just bump the version in their plugin and recompile and hope that the compiler catches any incompatible changes. Only the really conscientious ones will check which functions changed and if it affects their code.

I would probably accept a patch for a runtime check of Geany's API number. I'm not sure how it would be useful ATM.

Urm, PLUGIN_VERSION_CHECK() generates a function that is a runtime check doesn't it??

Don't you use:

#if GEANY_ABI_VERSION != xxx /* or whatever conditions */ #error ABI mismatch #endif

for compile time check??

Cheers Lex

Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

On 26 November 2010 04:07, Nick Treleaven nick.treleaven@btinternet.com wrote:

On Thu, 25 Nov 2010 10:54:07 +1100 Lex Trotman elextr@gmail.com wrote:

...

On 24 November 2010 23:54, Nick Treleaven nick.treleaven@btinternet.com wrote:

...

On Tue, 23 Nov 2010 09:09:59 +1100 Lex Trotman elextr@gmail.com wrote:

...

But the general consensus seems to be that people are happy to use static versioning and to keep conpiling (well it is the developer list) and either manually checking what has changed in an API/ABI break or (more probably) to hope that C's leaky type system catches any problem.

ABI checking is automatic, not manual (assuming the PLUGIN_VERSION_CHECK() macro is used and not manually implemented wrongly).

What I meant was that if the version fails, my guess is that most plugin devs just bump the version in their plugin and recompile and hope that the compiler catches any incompatible changes.  Only the really conscientious ones will check which functions changed and if it affects their code.

No, plugins should not have any ABI number constant in their source. See the source for PLUGIN_VERSION_CHECK().

That checks that the version of geany loading the plugin matches the version the plugin was compiled with. It doesn't check that the recompiled plugin works with the new ABI which is what I'm talking about. Only the compiler (if you are lucky) or manual checks can do that.

...

...

I would probably accept a patch for a runtime check of Geany's API number. I'm not sure how it would be useful ATM.

Urm, PLUGIN_VERSION_CHECK() generates a function that is a runtime check doesn't it??

It generates a function that returns the API required by the plugin. If it is above Geany's API provided, then Geany won't load it.

I meant a function plugins could call at any time to ask for Geany's API number, but maybe it wouldn't be useful anyway.

Ok, that could be useful

...

Don't you use:

#if GEANY_ABI_VERSION != xxx /* or whatever conditions */ #error ABI mismatch #endif

for compile time check??

There is no need to try to do that if plugins use the PLUGIN_VERSION_CHECK macro (which all should), and xxx would need to be read from Geany anyway, so that can't be done with the preprocessor.

1. PLUGIN_VERSION_CHECK is a runtime check, this is a compile time check

2. GEANY_ABI_VERSION and GEANY_API_VERSION *are* read from Geany, they are in plugindata.h and as noted above there isn't a runtime way of reading them. The xxx is the version the plugin uses and has to be a constant in the source.

3. GEANY_VERSION_CHECK requires GEANY_ABI_VERSION match what it was compiled with, it can't check that its a version the plugin can use or refuse to compile if it isn't.

Cheers Lex

Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

On 27 November 2010 23:46, Nick Treleaven nick.treleaven@btinternet.com wrote:

On Fri, 26 Nov 2010 07:06:12 +1100 Lex Trotman elextr@gmail.com wrote:

...

On 26 November 2010 04:07, Nick Treleaven nick.treleaven@btinternet.com wrote:

...

On Thu, 25 Nov 2010 10:54:07 +1100 Lex Trotman elextr@gmail.com wrote:

...

On 24 November 2010 23:54, Nick Treleaven nick.treleaven@btinternet.com wrote:

...

On Tue, 23 Nov 2010 09:09:59 +1100 Lex Trotman elextr@gmail.com wrote:

...

But the general consensus seems to be that people are happy to use static versioning and to keep conpiling (well it is the developer list) and either manually checking what has changed in an API/ABI break or (more probably) to hope that C's leaky type system catches any problem.

ABI checking is automatic, not manual (assuming the PLUGIN_VERSION_CHECK() macro is used and not manually implemented wrongly).

What I meant was that if the version fails, my guess is that most plugin devs just bump the version in their plugin and recompile and hope that the compiler catches any incompatible changes.  Only the really conscientious ones will check which functions changed and if it affects their code.

No, plugins should not have any ABI number constant in their source. See the source for PLUGIN_VERSION_CHECK().

That checks that the version of geany loading the plugin matches the version the plugin was compiled with.  It doesn't check that the recompiled plugin works with the new ABI which is what I'm talking about.  Only the compiler (if you are lucky) or manual checks can do that.

When we break the ABI we try to do it so the compiler would catch any problems - usually we would remove the old field name or function name.

I guess thats ok if you guarantee to never change the behavior of anything, always adding a new function if you want modified behavior.

Probably needs to go in Hacking.

OTOH If we are sticking with the requirement to recompile then using:

#if GEANY_ABI_VERSION != xxx #error Can't compile with this version of Geany, needs 0.99999.1 #endif

is a more user friendly error than some miscellaneous type error.

(Plugin devs don't need to bump anything when the ABI changes.)

It has that advantage.

...

...

...

Don't you use:

#if GEANY_ABI_VERSION != xxx /* or whatever conditions */ #error ABI mismatch #endif

for compile time check??

There is no need to try to do that if plugins use the PLUGIN_VERSION_CHECK macro (which all should), and xxx would need to be read from Geany anyway, so that can't be done with the preprocessor.

1. PLUGIN_VERSION_CHECK is a runtime check, this is a compile time check

2. GEANY_ABI_VERSION and GEANY_API_VERSION *are* read from Geany, they

are in plugindata.h and as noted above there isn't a runtime way of reading them.  The xxx is the version the plugin uses and has to be a constant in the source.

3. GEANY_VERSION_CHECK requires GEANY_ABI_VERSION match what it was

compiled with, it can't check that its a version the plugin can use or refuse to compile if it isn't.

I think it's too complicated to have a plugin compatible with 2 or more ABIs. It's asking for trouble.

Hmmm, its a bit rude to say that plugin devs are not smart enough to write

#if GEANY_ABI_VERSION > xxx // get the data I need the new way #else // get the data I need the old way #endif

Cheers Lex

Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Am 17.11.2010 01:03, schrieb Lex Trotman:

On 17 November 2010 10:22, Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 16/11/2010 23:32, Lex Trotman a écrit :

...

On 17 November 2010 03:11, Frank Lanitz frank@frank.uvena.de wrote: Just a question, shouldn't plugins be checking the ABI version was what they conpiled with not the Geany version?

I think this is not the question: Updatechecker wants to know the Geany version to check whether there is a newer one, it's not a plugin development need, but a goal.

Ah Ha!! I see, I'd missed the actual purpose of the plugin :-D

In that case I guess the three ints and some chars would be best for relative comparison, assuming thats how Geany is going to continue to do its versioning.

Personally I don't see any big need for a change here.

...

Of course, to check a functionality at runtime, a plugin should use the API version (and then getting the Geany version is quite specific).

BTW since you speak of this, I think API version should be made more visible. The API version in which each function appeared should appear in the doc rather than the Geany version it appeared in.

Agree. But also "in which version did the functions parameters and/or semantics change" is more important. If that change is newer than the plugin then the plugin shouldn't try to run.

This would make

...

easier for plugin developers to know for which version check. Also, perhaps a compile-time check would be interesting, it would allow things like "if Geany version is too old for this, it's not fatal, we will do without" -- stop me if it already exists.

The plugin only depends on the ABI it wants to use, so in a perfect world it would be able to check the each function it wants to call for the version in which it last changed. This will allow plugins to continue to operate as long as possible without rebuilding.

Well, I'm not 100% sure whether its this easy given a binary blob In fact when chaning some minor thing inside data strcutre you might need to update all flags for all functions which might introduc other failures. I'm not this euphoric about doing something like this.

This is not existing in a general view. Also I'm not 100% sure where this would make sense as you should always you up to date API. Maybe you can bring a litle light into darkness with an example.

Frank,

As Geany is getting more and more functionality in plugins there needs to be more thought in general about the need to lock Geany versions and plugin versions.

If they are locked together then users can't upgrade Geany until their plugins support the new version and can't upgrade plugins without upgrading Geany.

As I said in another post, as Geany is used for more than C development it is becoming less acceptable to assume that all users can re-compile Geany or plugins so any system needs to work at runtime as well as at compile time.

So there needs to be thought about how to allow any version of Geany and any version of a plugin to continue to work as long as the functions that they *use* have not been changed. This means that a single API/ABI number for the whole interface is not enough, it needs to be per function. Then smart plugin developers can make their plugins adapt themselves at runtime to the features available from Geany.

Cheers Lex

Cheers, Frank _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

On 18 November 2010 04:49, Frank Lanitz frank@frank.uvena.de wrote:

On Wed, 17 Nov 2010 19:52:40 +1100 Lex Trotman elextr@gmail.com wrote:

...

...

This is not existing in a general view. Also I'm not 100% sure where this would make sense as you should always you up to date API. Maybe you can bring a litle light into darkness with an example.

Frank,

As Geany is getting more and more functionality in plugins there needs to be more thought in general about the need to lock Geany versions and plugin versions.

If they are locked together then users can't upgrade Geany until their plugins support the new version and can't upgrade plugins without upgrading Geany.

As I said in another post, as Geany is used for more than C development it is becoming less acceptable to assume that all users can re-compile Geany or plugins so any system needs to work at runtime as well as at compile time.

So there needs to be thought about how to allow any version of Geany and any version of a plugin to continue to work as long as the functions that they *use* have not been changed.  This means that a single API/ABI number for the whole interface is not enough, it needs to be per function.  Then smart plugin developers can make their plugins adapt themselves at runtime to the features available from Geany.

Well, sounds reasonable. Is this possible with C?

Sure, Geany basically already has all the mechanisms except the version per function and data structure since everything is made available to plugins through pointers.

The structures containing the pointers need two version numbers for the structure.

These two numbers indicate the newest and oldest compatible versions. If additions are only made to the end of the structures then the oldest compatible is not changed when new things are added but the newest version is. Function/data pointers would only be removed occasionally as the structures got too big or messy, that would of course be a breaking change and would change the oldest compatible version to current.

Then we need a structure with a version number for each function/data. This version number needs to be changed anytime that the function/data is changed in a manner that is not compatible. Plugins need to check that they have the right version number and a non-null pointer to use the function/data.

It would be possible to create a simple tool to assist plugins with checking everything they use.

Cheers Lex

Cheers, Frank -- http://frank.uvena.de/en/

---

Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

2010/11/18 Enrico Tröger enrico.troeger@uvena.de:

On Wed, 17 Nov 2010 19:52:40 +1100, Lex wrote:

Hey,

I don't want to go too deep into this discussion, just my cents:

To keep it shorter, I'm 100% agree with Colomban's statements.

...

As Geany is getting more and more functionality in plugins there needs to be more thought in general about the need to lock Geany versions and plugin versions.

Yes. But not at all costs.

...

If they are locked together then users can't upgrade Geany until their plugins support the new version and can't upgrade plugins without upgrading Geany.

As I said in another post, as Geany is used for more than C development it is becoming less acceptable to assume that all users can re-compile Geany or plugins so any system needs to work at runtime as well as at compile time.

As already said, most users probably use distribution packages and/or Windows binaries. I think we can ignore (don't get me wrong here :D) Windows users as there updating Geany is really simply: download installers, execute them, done.

Assuming that Geany and all plugins have been updated, that means that plugin devs have to update the plugins every time Geany updates and at the same time. Effectively Geany and geany-plugins and any plugins not in geany-plugins have to be the same package since they have to remain in lockstep.

The distribution packages users also can easily upgrade provided that the package maintainers do their job, out of our responsibility.

But they can't package anything unless we provide them with updated everything, so giving Geany and plugin devs more work. Or you get the problems that have currently happened with Debian where some plugins were not updated in time to make the release so they didn't get in the package :-( Thats not Debians fault.

And then, there are those users who compile from source. I think it doesn't matter for which languages they use Geany, either the compile Geany from source or they do not. If they do, they can do it again if anything is incompatible, especially for SVN version users.

Agree, I'm not worried about people like you and me who can compile things, we don't count :-)

Don't get me wrong, I'm not against making compiling Geany +Plugins even more easy for users. But at some point I think code maintainability (is this a real word? :D) is also important.

Maintainability is indeed a word and an important one, and by decoupling plugins and Geany you reduce maintenance since things don't have to keep on being updated to ensure that they work, instead they make the decision themselves.

...

So there needs to be thought about how to allow any version of Geany and any version of a plugin to continue to work as long as the functions that they *use* have not been changed.  This means that a single API/ABI number for the whole interface is not enough, it needs to be per function.  Then smart plugin developers can make their plugins adapt themselves at runtime to the features available from Geany.

This leads to tons of #ifdefs or even worse,

Only if a plugin dev decides to use the facility, otherwise the plugin just says, "oh, wrong version of the function, sorry I can't run." If I was a plugin dev I'd check all version numbers in my plugin init function and fall over if incompatible or at most would have only a couple of flags that remove new functionality if required versions are not available.

if you really want to have

per-function checks at runtime, if conditions in the code. I think this makes maintenance of such code much harder and so it easier tends to break which makes users even more sad.

There are lots of requests by plugin devs for access to more of Geany, that changes the API/ABI version and that should make all other plugins fail until they are updated (but doesn't always, which is risky).

Cheers Lex

IMO.

Regards, Enrico

-- Get my GPG key from http://www.uvena.de/pub.asc

---

Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

2010/11/18 Enrico Tröger enrico.troeger@uvena.de:

On Thu, 18 Nov 2010 09:55:35 +1100, Lex wrote:

...

2010/11/18 Enrico Tröger enrico.troeger@uvena.de:

...

On Wed, 17 Nov 2010 19:52:40 +1100, Lex wrote:

Hey,

I don't want to go too deep into this discussion, just my cents:

To keep it shorter, I'm 100% agree with Colomban's statements.

...

As Geany is getting more and more functionality in plugins there needs to be more thought in general about the need to lock Geany versions and plugin versions.

Yes. But not at all costs.

...

If they are locked together then users can't upgrade Geany until their plugins support the new version and can't upgrade plugins without upgrading Geany.

As I said in another post, as Geany is used for more than C development it is becoming less acceptable to assume that all users can re-compile Geany or plugins so any system needs to work at runtime as well as at compile time.

As already said, most users probably use distribution packages and/or Windows binaries. I think we can ignore (don't get me wrong here :D) Windows users as there updating Geany is really simply: download installers, execute them, done.

Assuming that Geany and all plugins have been updated, that means that plugin devs have to update the plugins every time Geany updates and at the same time.  Effectively Geany and geany-plugins and any plugins not in geany-plugins have to be the same package since they have to remain in lockstep.

Why? The last releases indeed broke ABI compatiblity each time (IIRC). But it's not meant to be the normal case. At some point the plugin API should be stable enough to not break ABI every now and then.

You are more optimistic than me :-)

And once

we reach this point, I don't see any required lockstep here.

...

...

The distribution packages users also can easily upgrade provided that the package maintainers do their job, out of our responsibility.

But they can't package anything unless we provide them with updated everything, so giving Geany and plugin devs more work.  Or you get the

We are talking about releases, right? Some time ago, we said that at least for now we try to keep Geany and Geany-Plugins releases together as long as it's possible. That's not strictly a technical requirement, more or less just for users' and developers' convenience. Again, AFAIK there is no technical requirement.

...

problems that have currently happened with Debian where some plugins were not updated in time to make the release so they didn't get in the package :-(  Thats not Debians fault.

Side note, the geany-plugins 0.19 package entered Debian Squeeze last weekend because of the heavy efforts of its Debian maintainer. Doesn't relate to the discussion but is worth mentioning anyway :).

Yes it is.

Thanks Evgeni!

And partly I'm trying to reduce the amount of work required.

...

...

And then, there are those users who compile from source. I think it doesn't matter for which languages they use Geany, either the compile Geany from source or they do not. If they do, they can do it again if anything is incompatible, especially for SVN version users.

Agree, I'm not worried about people like you and me who can compile things, we don't count :-)

Bah, always hearing the same: you don't count!

An editor is an end-user program (even if the end users are developers) so only the users matter :-) (and I did say WE :-)

(j/k)

...

...

Don't get me wrong, I'm not against making compiling Geany +Plugins even more easy for users. But at some point I think code maintainability (is this a real word? :D) is also important.

Maintainability is indeed a word and an important one, and by

:)

...

decoupling plugins and Geany you reduce maintenance since things don't

I don't see any strict coupling you are talking about. Except the above mentioned release policy but this isn't that strict.

But it is effectively forced because any change to the ABI prevents plugins from working, so they have to be updated. And an ABI change might only be a bugfix. Requiring the whole ABI stability is a pretty onerous requirement.

...

...

...

So there needs to be thought about how to allow any version of Geany and any version of a plugin to continue to work as long as the functions that they *use* have not been changed.  This means that a single API/ABI number for the whole interface is not enough, it needs to be per function.  Then smart plugin developers can make their plugins adapt themselves at runtime to the features available from Geany.

This leads to tons of #ifdefs or even worse,

Only if a plugin dev decides to use the facility, otherwise the plugin just says, "oh, wrong version of the function, sorry I can't run."  If

This already happens, partly on compile-time, partly on runtime at loading the plugin. Even though Geany says: "oh, plugin can't be loaded, sorry'.

Yes, but at the level of the whole interface, I'm not suggesting any wildly new technology, just reduce the level of granularity. I only suggested an implementation to show that it exists, could be implemented lots of ways.

Cheers Lex

...

if you really want to have

...

per-function checks at runtime, if conditions in the code. I think this makes maintenance of such code much harder and so it easier tends to break which makes users even more sad.

There are lots of requests by plugin devs for access to more of Geany, that changes the API/ABI version and that should make all other plugins fail until they are updated (but doesn't always, which is

This already happens, at least for API/ABI changes. For API additons, it doesn't matter.

Regards, Enrico

-- Get my GPG key from http://www.uvena.de/pub.asc

---

Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Hi Frank,

Both your posts combined reply so quote marks are wrong.

if you really want to have

...

per-function checks at runtime, if conditions in the code. I think this makes maintenance of such code much harder and so it easier tends to break which makes users even more sad.

There are lots of requests by plugin devs for access to more of Geany, that changes the API/ABI version and that should make all other plugins fail until they are updated (but doesn't always, which is risky).

Well, this is not true in most cases as of two reasons: 1. We try to keep the A[P|B] for any minor release the smae 2. ABI/API changes are done with new releases so a recompilation is reasonable. In most cases there don't need to be any code touched on plugin.

So you are saying that all plugins should be part of and maintained by Geany or Geany Plugins so that recompiles remain in sync?? Have you got the maintenance effort??

On 21 November 2010 09:26, Frank Lanitz frank@frank.uvena.de wrote:

On Thu, 18 Nov 2010 11:03:37 +1100 Lex Trotman elextr@gmail.com wrote:

...

But it is effectively forced because any change to the ABI prevents plugins from working, so they have to be updated.  And an ABI change might only be a bugfix.  Requiring the whole ABI stability is a pretty onerous requirement.

If you need to break ABI with a bugfix, I assume also your suggestion will end up in a recompilation of plugins as its really appears to be a major problem.

Yes but why do you have to recompile all plugins that don't use the function/struct that was bugfixed??

Cheers Lex

Cheers, Frank -- Frank Lanitz frank@frank.uvena.de

---

Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

On Thu, 18 Nov 2010 11:03:37 +1100, Lex wrote:

Hi,

...

...

decoupling plugins and Geany you reduce maintenance since things don't

I don't see any strict coupling you are talking about. Except the above mentioned release policy but this isn't that strict.

But it is effectively forced because any change to the ABI prevents plugins from working, so they have to be updated. And an ABI change might only be a bugfix. Requiring the whole ABI stability is a pretty onerous requirement.

Just to make sure, an ABI version bump doesn't necessarily require plugins' code to be updated, only the binary, i.e. they simply need to be recompiled.

Regards, Enrico

On 17.11.2010 23:29, Enrico Tröger wrote:

On Wed, 17 Nov 2010 19:52:40 +1100, Lex wrote:

Hey,

I don't want to go too deep into this discussion, just my cents:

To keep it shorter, I'm 100% agree with Colomban's statements.

I also 100% agree. Plugin development shouldn't be a PITA.

The current capabilities plus the ability to query the Geany version (perhaps even svn revision or built date) at runtime are good enough for the vast majority of problems.

Best regards.

Am 16.11.2010 23:32, schrieb Lex Trotman:

On 17 November 2010 03:11, Frank Lanitz frank@frank.uvena.de wrote:

...

On Tue, 16 Nov 2010 15:13:03 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 16/11/2010 09:23, Frank Lanitz a écrit :

...

Well, agreed. In most cases it should work fine with compiled in version number as most cases the API/ABI is changing with some major release. But of course this will go into trouble with minor releases as we had them with 0.19.1 or if anybody is remembering the 10.x ones :)

Well, however. I think a simple function which returns the version string into plugin API would be enought or am I wrong? something that is just doing a return GEANY_VERSION;

I think it is better to return major, minor and micro version (or something that fits the versionning scheme) as plain integers. The advantage is that it becomes easy to use this version for any check, where a string is quite tedious to use. geany_get_version(gint *major, gint *minor, gint *micro) for example, or 3 variables, not sure.

Well, even it looks a bit dirty in my eyes (maybe we can put this into a struct) it would solve users from use the parsing over and over again as I did inside updatechecker with static void parse_version_string(const gchar *ver, gint *major, gint *minor, gint *micro, gchar **extra)

So I'm pro ;)

Just a question, shouldn't plugins be checking the ABI version was what they conpiled with not the Geany version?

Geany is checking whether a plugin is compiled with right ABI on loading time.

Cheers, Frank

On Thu, 18 Nov 2010 00:14:20 +0100, Thomas wrote:

On 15.11.2010 22:58, Enrico Tröger wrote:

...

I talked with Frank about this already in a private mail, also joining a patch to integrate it in the autotools build. Now he has two patches to choose :).

IMO you (core) developers talk too much in private sometimes. The development process, including discussions, should be open and transparent.

I do agree. It was not to hide the discussion or anything. I was just making some changes to the plugins' build system or tested something or whatever and stumpled upon the error. So I made the little patch, sent it to Frank and added a note that even after compiling the plugin wouldn't work correctly because of the compiled-in Geany version.

Honestly, I assumed Frank would just apply the patch, would have answered: yes, I'll fix it and voila. At this point I didn't know and expect the current lengthy discussion on the list.

Mea culpa.

Regards, Enrico

On Thu, 18 Nov 2010 00:40:04 +0100, Thomas wrote:

On 18.11.2010 00:31, Enrico Tröger wrote:

...

I do agree. It was not to hide the discussion or anything. I was just making some changes to the plugins' build system or tested something or whatever and stumpled upon the error. So I made the little patch, sent it to Frank and added a note that even after compiling the plugin wouldn't work correctly because of the compiled-in Geany version.

Honestly, I assumed Frank would just apply the patch, would have answered: yes, I'll fix it and voila. At this point I didn't know and expect the current lengthy discussion on the list.

Mea culpa.

I think it's OK if it happens once in a while; often you just don't think about it when you're discussing and sometimes the topic appears to be not important enough.

This is how it goes. Nick, Frank and me doesn't coomunicate that much in private, at least not about Geany :). The remaining things most often should kept private, haha.

But it's not the first time I notice that there's been quite some talk behind the themes. I feel it happens a lot (e.g. you never see discussions when it comes to upgrading the integrated scintilla copy, but yet it happens), and that makes me feel the development process is

Er, no. Not really as far as I remember. I think to remember that I wrote once in a while Nick a mail like 'any objections in updating Scintilla', he answered no and I did. Something like this, not really intensive discussions. What we did also in private sometimes was talking about releases, i.e. when to release what everyone has still to do and time to make the release. We could have done this on the list but I think the benefit would have been small. This was really more organisational.

(in fact, all FOSS projects do) benefits from involving the community as much as possible.

And that is how it should be and should stay. I can speak only for myself: I didn't want to exclude the community in any decisions at any point. There are just a few, little and not so important things which don't need a 200 mails thread on the list. Again, when this happened, this was nothing critical to Geany.

I'm sorry to hear you got the feeling there is anything happening behind the scenes.

Regards, Enrico