Re: [Geany-Devel] Spawn module API
On 23.6.2015 г. 02:25, Matthew Brush wrote: [...] One thing I forgot: the plugin API currently exports utils_spawn_[a]sync, and a few plugins use utils_spawn_sync. These functions were (partially correct) wrappers around the old glib/win32 spawn, and are now wrappers around spawn_[a]sync. Someday, in the distant future, they should be obsoleted... I get what you're saying but I also feel uneasy about blanket exporting of APIs with no current users of it, so we don't know exactly what really needs to be exported. Well, with nothing from spawn exported, we can be pretty sure that all plugins _will_ be using utils_spawn and g_spawn instead. :) We should make Colomban decide :) The leading developers should decide - including you. -- E-gards: Jimmy ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [Geany-i18n] String freeze of Geany core and Geany-Plugins for 1.25
Hi, As with git commit 5c2740d74c527dca8272124f4e0a7b4bde4e03de we needed to update some strings on geany-plugins. I will not update the po files inside git as this might will conflict with your local translations and changes done. So please rerun make update-po or waf updatepo on geany-plugins (if you are translating) on current head of geany-plugins' git or give it one more day and find updated po-files on http://i18n.geany.org/plugins. Cheers, Frank Am 21.06.2015 13:38:20, schrieb Frank Lanitz: Hi translators and friends of Geany, As by Colomban's mail we are only two weeks away from upcoming, new, amazing 1.25 release of Geany! It's scheduled for 2015-07-12. In prior of that we have to ensure, all translations of Geany and it's plugins are up to date and as complete as possible to get a great user experience using Geany. In preparation of that I've update po-files for Geany core as well as the geany-plugins project inside github repositories and asking you whether you could update translations, review them or maybe add new ones. I'd be very happy if you could send a patch, a pull request or single file with translation to either the geany-i18n mailing list or direct to me within the next two weeks so we can include it to the next release. Deadline will be 2015-07-11 CEST. To get most recent files you could just clone the repositories from Geany: https://github.com/geany/geany Geany-Plugins: https://github.com/geany/geany-plugins This can be done e.g. with git clone https://github.com/geany/geany.git or for the plugins git clone https://github.com/geany/geany-plugins.git Also at http://i18n.geany.org or http://i18n.geany.org/plugins for plugins are statistics and daily updated files available If your language was translated by two or more in past, please double check directly with them or by pinging me, so we don't need to translate same things two or three times. Also please feel to ping me for every question or if you like to start a new translation for an unsupported language. If you have any questions, don't hesitate to ping me directly via IRC: geany @freenode Jabber/XMPP: fr...@jabber.ccc.de or via Mail: look above or some of the mailing lists. @Plugin Maintainer: Please don't add new strings by now as they most likely will be properly translated for next release. Thanks and happy translating Frank ___ I18n mailing list i...@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/i18n ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
Le 24/06/2015 00:18, Matthew Brush a écrit : […] I think the general policy is to export stuff on demand as plugins need it. Seeing as you wrote the API in question, I'm assuming you know best the stuff you will need, so I don't personally see much problem preemptively exposing that stuff[0]. From you're previous email you mentioned the stuff checked with [x] below: [ ] spawn_get_program_name() [ ] spawn_check_command() [x] spawn_kill_process() [ ] spawn_async_with_pipes() [ ] spawn_async() [x] spawn_with_callbacks() [x] spawn_write_data() [ ] spawn_get_exit_status() [ ] spawn_sync() [x] SpawnFlags [x] SpawnReadFunc [x] SpawnWriteData Seems to make sense, only spawn_write_data() doesn't strike me as totally required, but I understand. TLDR version below. Is that sufficient, or is there other stuff? I will remove the /** from anything that is not expected to be needed, if nobody objects. IMO, spawn_with_callbacks() is *the* key API from spawn, what makes it great. spawn_async_with_pipes() can be nice, but most people probably shouldn't use them as they have same IO trickery most IO layers have, where you have to take care of not filling up any pipes (write) or forget to empty them (read). The only real difference wit g_spawn_async*() is that it uses native API on Windows (which indeed solves some issues so is useful, but that's not my point). Inside Geany, we can rely on the GLib main loop to be running so anyone can use the handier spawn_with_callbacks(). BTW, I just noticed that on Windows spawn_async_with_pipes() requires the GLib main loop to be running if child_pid=NULL (well, it registers a watch func, not sure what happens if it doesn't execute -- zombie?). We probably don't care much though. spawn_async() doesn't seem so much useful to me, as it doesn't (seem) to have so much advantages over g_spawn_async(), which works okay (as there is no pipes involved). Also, it's a thin wrapper around spawn_async_with_pipes(). I don't know about speed or anything though. spawn_sync() is nice because it allows to easily pipe through a process (send some data to stdin and and read the output). How often is this useful for everyone I don't know -- but any plugin wanting to call a filter command might benefit from it. Also, it's not that hard to reproduce using spawn_with_callbacks() as that one has SPAWN_SYNC, so only the communication callbacks have to be implemented. spawn_get_exit_status_cb() seem useless to the API IMO. It's a trivial function currently only used by spawn itself. It might even be sensible to make it completely internal. I would have said that spawn_write_data() wasn't really required because it's relatively simple and not used by Geany outside of spawn, but it's indeed probably handy in combination with spawn_with_callbacks() to anyone wanting to feed a simple buffer to stdin. spawn_get_program_name() is only used in spawn itself and doesn't seem to be a strict requirement. spawn_check_command() seem nice to validate a user command before actually running it, so it might be useful to anyone wanting to run user-supplied commands through the spawn API, to e.g. check for issues right when the user defines the command (like how we do it in the custom commands dialog). We should make Colomban decide :) The leading developers should decide - including you. Well you know my opinion :) I think everyone pretty much agrees we shouldn't expose stuff unrelated to the plugin API, and I think we all also agree it's stupid for plugins to have to copypaste code that exists already or else use an inferior version. I also think everyone agrees that a separate utility library would be a good idea. I'm everyone and all :) Regards, Colomban ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
Le 24/06/2015 01:57, Lex Trotman a écrit : Colomban, Correct me if I'm wrong, but despite my loudly voiced misgivings :) doesn't the spawn_* series do command quoting and g_spawn* not? If that the case they should not be mixed on the same platform otherwise the user has to know which commands are run with which function to know if they need to do the quoting themselves. Well, those support an additional command parameter that indeed is read in a platform-dependent manner. (this was a discussion point and ended like this). They however also support argvs just fine, so you can use those too and they would work the same. With this, you can also imagine using g_shell_parse_argv() on all platforms if you like, just like you would do with g_spawn(). So well, yes, the user has to know which syntax is needed, but that's basically true already. Cheers, Colomban ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
On 2015-06-23 09:04 AM, Dimitar Zhekov wrote: On 23.6.2015 г. 02:25, Matthew Brush wrote: [...] One thing I forgot: the plugin API currently exports utils_spawn_[a]sync, and a few plugins use utils_spawn_sync. These functions were (partially correct) wrappers around the old glib/win32 spawn, and are now wrappers around spawn_[a]sync. Someday, in the distant future, they should be obsoleted... +1 I get what you're saying but I also feel uneasy about blanket exporting of APIs with no current users of it, so we don't know exactly what really needs to be exported. Well, with nothing from spawn exported, we can be pretty sure that all plugins _will_ be using utils_spawn and g_spawn instead. :) I think the general policy is to export stuff on demand as plugins need it. Seeing as you wrote the API in question, I'm assuming you know best the stuff you will need, so I don't personally see much problem preemptively exposing that stuff[0]. From you're previous email you mentioned the stuff checked with [x] below: [ ] spawn_get_program_name() [ ] spawn_check_command() [x] spawn_kill_process() [ ] spawn_async_with_pipes() [ ] spawn_async() [x] spawn_with_callbacks() [x] spawn_write_data() [ ] spawn_get_exit_status() [ ] spawn_sync() [x] SpawnFlags [x] SpawnReadFunc [x] SpawnWriteData Is that sufficient, or is there other stuff? I will remove the /** from anything that is not expected to be needed, if nobody objects. About the WIF* macros, those (at present) are not officially part of the plugin API as they have no Doxygen comments, though they will still be visible to plugins since they're macros and bypass the linker trick we use to hide functions. I think it would be best to add documentation to those (and possible define them into the GEANY_ 'namespace'?), at the very least to ensure nobody accidentally moves or hides them. Just the other day I tried to move them into spawn.c thinking they were there on accident, but then I left them because another .c file uses them so they need to be in a (not necessarily public) header. We should make Colomban decide :) The leading developers should decide - including you. Well you know my opinion :) I think everyone pretty much agrees we shouldn't expose stuff unrelated to the plugin API, and I think we all also agree it's stupid for plugins to have to copypaste code that exists already or else use an inferior version. I also think everyone agrees that a separate utility library would be a good idea. The problem I have is that once this API makes it into the next release, it's forever stuck inside Geany and we'll have to keep it indefinitely, regardless if something possibly better[1] like GProcess comes available to us, and we don't even use it internally anymore. Cheers, Matthew Brush [0]: At least until we establish a policy around what belongs in the plugin API or not. [1]: I have no idea if it's better, just an example. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
On 2015-06-23 01:40 PM, Lex Trotman wrote: On 24 June 2015 at 02:04, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On 23.6.2015 г. 02:25, Matthew Brush wrote: [...] One thing I forgot: the plugin API currently exports utils_spawn_[a]sync, and a few plugins use utils_spawn_sync. These functions were (partially correct) wrappers around the old glib/win32 spawn, and are now wrappers around spawn_[a]sync. Someday, in the distant future, they should be obsoleted... I get what you're saying but I also feel uneasy about blanket exporting of APIs with no current users of it, so we don't know exactly what really needs to be exported. In a previous post Dimitar has listed the API he requests for his plugin, so that (at least) should be made available in 1.25. It is spurious to make him and therefore any potential windows users wait for another release cycle. He listed some of the API that is exposed. There's nothing spurious about being cautious about mass-exporting API that nobody even asks for, IMO. Well, with nothing from spawn exported, we can be pretty sure that all plugins _will_ be using utils_spawn and g_spawn instead. :) Yes, the argument that nothing uses it is also spurious given the API only just came into existence. Nobody made any argument that nobody uses, I just mentioned that nobody is using it YET (since they could've, as it's all exported for plugins ATM in Git master), so we could therefore unexpose it without causing anybody grief. There's nothing spurious going on here. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
On 24 June 2015 at 10:06, Colomban Wendling lists@herbesfolles.org wrote: Le 24/06/2015 01:57, Lex Trotman a écrit : Colomban, Correct me if I'm wrong, but despite my loudly voiced misgivings :) doesn't the spawn_* series do command quoting and g_spawn* not? If that the case they should not be mixed on the same platform otherwise the user has to know which commands are run with which function to know if they need to do the quoting themselves. Well, those support an additional command parameter that indeed is read in a platform-dependent manner. (this was a discussion point and ended like this). They however also support argvs just fine, so you can use those too and they would work the same. With this, you can also imagine using g_shell_parse_argv() on all platforms if you like, just like you would do with g_spawn(). Then Geany should be changed to do that too, for all commands (IIRC build commands already do it). Note by user I mean the end user, not the plugin programmer. Having the end user need to know if they should quote commands or not is bad (tm). If that is already the case then it should be fixed. Cheers Lex So well, yes, the user has to know which syntax is needed, but that's basically true already. Cheers, Colomban ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
