[Geany-devel] C++ setters/getters generation plugin using Clang
Hello, i have written a simple plugin to generate C++ setters and getters using Clang for parsing C++ code. You can check it out from github: https://github.com/itakingiteasy/geany-setters-getters-generator-plugin You also will need clang and llvm version 2.8+ (not sure, i have tested it only with 3.0-trunk) to build it. This is my first real C project, so sorry for code quality, i am still learning %) ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Performance issues?
On Wed, 23 Mar 2011 23:49:41 +1100 Lex Trotman ele...@gmail.com wrote: Thats a bit harder, probably Yura, the plugin writer will need to take a look at the problem I'd say. I looked at the problem: 1) geanyprj act only on document-open, document-save, document-activate callbacks 2) geanyprj add a lot of TMWorkObject objects using tm_workspace_add_object() to Geany 3) Geany call update_tags_from_buffer() very often. I think this function somehow reparse a lot of objects because of update_parent param. I am not sure what this param actualy mean but if I change function this way performance is back to normal (I don't say we need to change it, it is just research): --- a/src/document.c +++ b/src/document.c @@ -2263,7 +2263,7 @@ static gboolean update_tags_from_buffer(GeanyDocument *doc) /* we copy the whole text into memory instead using a direct char pointer from * Scintilla because tm_source_file_buffer_update() does modify the string slightly */ sci_get_text(doc-editor-sci, len, text); - result = tm_source_file_buffer_update(doc-tm_file, (guchar*) text, len, TRUE); + result = tm_source_file_buffer_update(doc-tm_file, (guchar*) text, len, FALSE); g_free(text); #endif return result; -- Yura Siamashka yura...@gmail.com ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Performance issues?
On 27 March 2011 12:31, Yura Siamashka yura...@gmail.com wrote: On Wed, 23 Mar 2011 23:49:41 +1100 Lex Trotman ele...@gmail.com wrote: Thats a bit harder, probably Yura, the plugin writer will need to take a look at the problem I'd say. I looked at the problem: 1) geanyprj act only on document-open, document-save, document-activate callbacks 2) geanyprj add a lot of TMWorkObject objects using tm_workspace_add_object() to Geany And tm_workspace_add_object sets the parent to be the whole workspace! 3) Geany call update_tags_from_buffer() very often. I think this function somehow reparse a lot of objects because of update_parent param. I am not sure what this param actualy mean but if I change function this way performance is back to normal (I don't say we need to change it, it is just research): --- a/src/document.c +++ b/src/document.c @@ -2263,7 +2263,7 @@ static gboolean update_tags_from_buffer(GeanyDocument *doc) /* we copy the whole text into memory instead using a direct char pointer from * Scintilla because tm_source_file_buffer_update() does modify the string slightly */ sci_get_text(doc-editor-sci, len, text); - result = tm_source_file_buffer_update(doc-tm_file, (guchar*) text, len, TRUE); Because of item 2) above I think this will reparse all open files. The question is can problems be introduced by not reparsing things, eg if we are editing a .h file, can that affect the symbols of the .c files that include it ... probably possible AFAICT. Is there some easy way of triggering re-parsing of dependencies when the sidebar is about to swap to a different file? That way real-time update only needs to do the one file being edited, but no artifacts are introduced due to inconsistencies between when tags were parsed. Cheers Lex + result = tm_source_file_buffer_update(doc-tm_file, (guchar*) text, len, FALSE); g_free(text); #endif return result; -- Yura Siamashka yura...@gmail.com ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Split Window Patches
On 03/26/11 17:31, Colomban Wendling wrote: #0002 Enable Scintilla's default popup editor menu on the split window editor so that there's a way to copy/paste/undo/redo/etc. Closes bug #2983145[2] although the keybindings and main menu items still don't work in the split window. Not sure about this one since the menu is neither translatable nor look like other Geany's menus. Maybe manually implementing a basic menu would be better? Should a bug/feature request also be reported to Scintilla? #0003 Remove the widget reparenting in an attempt to make the plugin work on Windows again. Although I can't test on Windows, I think there's a good chance this will fix the issues and it seems to work fine on Linux as well. I base this on an old GTK+ FAQ entry[3]. If someone can confirm, it will close bug #2725342[4] and the plugin can be re-enabled on the Windows build. Not sure about this, what was the issues before (the one the code talked about)? I'd prefer one of the original authors to review this one if possible... Nick (or Enrico, seems you also worked on this), could you check this/tell what was exactly the issue? See r3161 and r3163. also the bug report for this and FAQ entry linked from original message. I think it's best to have original authors (especially someone who is able to build on windows) to check this also. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] g_thread_init()?
On 27 March 2011 15:59, Matthew Brush mbr...@codebrainz.ca wrote: Hi, Should Geany be calling g_thread_init() for the plugins? There is now 4 plugins at least affected[1][2][3][4]. Its safe to call g_thread_init multiple times, but ... Well, g_thread_init should not be called in plugin_init since that can be called from a signal callback and thats a no-no according to the docs. There are also a list of other issues about when it can be called, right at the beginning of the program is a really good place. And the link options need to be different for programs using g_thread_init, and having the plugins linked differently to the main app might have other issues. So in general, if any plugin uses glib from threads then yes Geany should use g_thread_init once for all the program, and Geany and plugins should link with pkg-config --libs gthread-2.0 And since you have identified four that do use threads ... Cheers Lex [1] https://github.com/codebrainz/geany-plugins/commit/99afbc6d0286081c7586e75c829c18b69e26731f#L1R420 [2] https://github.com/codebrainz/geany-plugins/blob/5b4b64b3d193f5fb5293a99ddc8503343586c9fe/geany-plugins/devhelp/src/plugin.c [3] http://pastebin.com/9MV5i0Gw [4] James Geboski is working on a new plugin and he got caught by this also. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Split Window Patches
Not sure about this one since the menu is neither translatable nor look like other Geany's menus. Maybe manually implementing a basic menu would be better? Should a bug/feature request also be reported to Scintilla? Its not really Scintilla's problem that Geany menus look different :-) And Scintilla/Scite has its own translation system which we havn't integrated, see http://code.google.com/p/scite-files/wiki/Translations Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Split Window Patches
On 03/26/11 22:44, Lex Trotman wrote: Not sure about this one since the menu is neither translatable nor look like other Geany's menus. Maybe manually implementing a basic menu would be better? Should a bug/feature request also be reported to Scintilla? Its not really Scintilla's problem that Geany menus look different :-) Well, I didn't mean because the appearance :) And Scintilla/Scite has its own translation system which we havn't integrated, see http://code.google.com/p/scite-files/wiki/Translations Ah ok. I'm not very knowledgeable about translation stuff. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
