On 6 August 2011 14:11, Matthew Brush mbrush@codebrainz.ca wrote:
On 08/05/11 21:01, Lex Trotman wrote:
[...]
Otherwise I guess it "shouldn't" be too hard to add the extra functionality to Geany but getting stuff from the module is spread around a bit and you would need to be sure the module wasn't unloaded unexpectedly as well.
How can it be unloaded?
Well I didn't read plugins.c in detail but I suspected that ATM when you deactivate a plugin in the plugin manager it will unload the module, but that would be bad for a shared module.
In fact seems to close and re-open whenever you toggle the activate checkbox, see pm_plugin_toggled() calls plugin_free() which closes the module.
Just means that you need to be careful when you patch it that the Python plugin isn't unloadable without unloading all its dependent plugins.
I think it'll be ok if it's using g_module_make_resident[1], which should ensure that first Python interpreter (libpythonX.X.so) would never get unloaded, and so always be Py_IsInitialized(). Basically, I don't care if you can't reclaim your XX megabytes of RAM until you restart Geany :)
Sounds fair, I havn't used more than about 2Gb of my 4Gb that I have noticed, despite firefox's best efforts.
BTW what are the restrictions on what Python can be used when Geany calls a Python callback, I guess everything has to be a function that runs to completion. Can it be a closure, can it use yield, can it use threads, can it do async I/O so as not to block Geany?
Cheers Lex
[1] http://www.geany.org/manual/reference/pluginutils_8h.html#ac402e1d165036aaeb...
Cheers, Matthew Brush _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel