Re: [Geany-devel] GeniusPaste, new plugin
On Sat, 28 Apr 2012 18:14:33 +0200 Enrico enrico@gmail.com wrote: If you consider this plugin interesting enough, I'd like to know what should I do to make it part of the Geany-Plugins project. I think it can be useful to have it inside the geany-plugins project. If you like to, just clone the geany-plugins project on github [1] and add you plugin into its structure and resend a pull request to the project. You can have a look onto other plugins if its about adding build support for waf and autotools - both are much appreciated. But if one of them is missing, there might somebody who will add it for you ;) Cheers, Frank [1] https://github.com/geany/geany-plugins -- http://frank.uvena.de/en/ pgpoqGrZ8AyZg.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] tagmanager changes
On 29/04/2012 14:07, Lex Trotman wrote: On 29 April 2012 22:07, Nick Treleavennick.trelea...@btinternet.com wrote: On 27/04/2012 06:30, Lex Trotman wrote: I don't see this myself, I see some complicating issues which could be resolved (and I'm willing to work on them), but generally a sound design for what it provides and for extra things we may want to add. Maybe my problem is simply the attempt to simulate object orientation and inheritance in C makes it look complicated for a spoilt C++ programmer :) Eh? Tagmanager isn't OOP. I expect the design is better in some respects (and to be fair I didn't look for better things), but finding a tag based on its name is something we are always going to want to be fast. Even for scope completion, you still need to lookup a tag structure from a name string. So I think we will always want a sorted array of tags per document that we can bsearch (or something equally fast). Yes, we could have one name table and then prune the results to the scope required, or a name table per scope (which makes the tables smaller and simple searches faster). It seems to me that if we supported proper scope completion then we could still have one array per document, sorted first by scope, then by name. I don't know, but we still need fast tag lookup based on name. If O(n) scope lookup is too slow, we will need additional data structures arranged differently, but whatever we have should have something like O(log n) lookup for names as this is by far the most common operation. Agree, name lookup should be as fast as possible, O(log n) what about O(1) like compilers :) Well since we can't use hashes due to the need to identify prefixes, a radix trie seems the best since it can be as fast as a hash ie two passes through the key, and that gives a sub-trie that begins with the prefix. But as you say thats orthogonal to the question of scope layout. I only know about a simple trie, but wouldn't that use a lot more memory? I don't think we want name lookup 'as fast as possible', just no slower than we have already. * tags (and most types) are reference-counted (so they aren't necessarily duplicated, e.g. in the multicache backend); I don't really understand src/symbols.c since the real-time parsing change, so don't really understand why this is needed. Blame C++ and overloaded names I think. I looked at the thread about that, and from what I could tell, the problem was for reparsing unsaved files. Wasn't the order OK for files that have just been saved? (Also I don't follow what that has to do with reference counting). Hmm, you're right, looks like Colomban is duplicating tags in nested caches, so all searches are just one cache, but in fact they are not duplicated, but reference the same tag using a reference count to tell when to destroy it. I am not sure where the reference to real time parsing comes from? Sorry, I meant reparsing not real time updates. But is your problem with overloaded symbols OK when the file is parsed after saving, i.e. the order is only wrong on reparsing? ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] tagmanager changes
On 29/04/2012 15:42, Colomban Wendling wrote: * it support asynchronous parsing (though not concurrent parsing); What's the difference? Also, what does it buy us? What I meant when saying it's asynchronous but not concurrent is that it supports launching the parsers in a separate thread, but it cannot launch several parsers at once. This is because CTags parsers aren't thread-safe (have a lot of global states and no locks). What asynchronous parsing gives us is quite simple: no blocking. This means that a slow parser (like e.g. the HTML one on Windows before you changed the regex library) wouldn't lock Geany. Same for project plugins that want to parse thousands of files: this would still take a long time, but Geany would be still usable in the meantime. Ok. It seems a good idea to support this, but for parsing tags in open documents it doesn't seem particularly useful, as this ought to be fast. The regex problem was unusual IMO and due to an old version of GNU regex. I don't understand why tagmanager has to be replaced, why not just replace the parts you want to improve? Rewriting it is likely to lead to a new set of bugs and be hard to review and merge changes from master. I think Lex and Matthew probably summarize it quite correctly: it's not that TM is bad or has to be replaced; it is that (I'm) unable to understand it enough to fix anything in it, like scope completion. Maybe it's only me, but I tried hard :) And the only reason why maybe TagManager would need replacement/large changes is asynchronous parsing. I'm not sure how hard it would be to get it with TM -- but again, maybe it's only that I don't understand it enough. Not sure about this, but I think the only messy part of TM is when it updates the workspace array, which I think could be removed (I'll explain this in another reply). * there is 2 backends as of today: - a simple one that is simple and that doesn't waste (too much) memory, but that searches in O(n); Linear searching seems like a bad idea when we currently have O(log n). Removing x tags is O(n * x) by the look of it. I agree it's not interesting regarding performances, and this backend isn't meant for it. I needed an implementation for early testing, so I wrote it simple. And it showed useful for testing later on too, since because of it's simplicity it isn't bugged -- just slow :) Ok. BTW, how does TagManager do fast searches? I always though it did a sorting with new attributes each time they changed, so in such situations it's even worse than O(n), isn't it? For searching, it doesn't do any sorting ever. For adding tags the work object (i.e. document tags) have to be sorted, which I think is good, but also the workspace tags are currently resorted, which I think may be a bad design. - a multi-cache one that, as its name suggests, maintains multiple caches (sorted tags arrays). it uses a little more memory and is slower on insertion since it maintains several sorted lists, but a search on an already existing cache is very fast. Won't this be slow for adding many tags at once? How is this design better than tagmanager? Well, adding a tag would require a bsearch() on each cache, yes. However, adding tags is mostly done in a separate thread (if async parsing it used), so it can be less of a problem. I haven't studied your design, but I would prefer that any design is efficient on all threads, so the user's computer can use remaining performance for compiling whatever else they want. Also, what about global tags? Those can add a lot of tags all at once. And a search is simply a bsearch() (O(n log n), right?) given the cache already exists. If the cache doesn't exist, it has to be created so yeah on the first search it's slow. If it can be slow enough for the user to notice this is probably bad. I don't see why having two is better. The memory overhead for a pointer array is not much vs. the size of the tag structures. Fast searching is important. Multiple backends isn't really useful probably. As said above, the first was mostly a testing one, and I wanted to be able to keep both during development for better testing. At one point I also though maybe there could be some backends optimized for particular situations, like fast search, fast insertion, low memory consumption, etc., but I don't see much use for this anymore. Ok. * tags (and most types) are reference-counted (so they aren't necessarily duplicated, e.g. in the multicache backend); I don't really understand src/symbols.c since the real-time parsing change, so don't really understand why this is needed. BTW here I meant reparsing document tags without saving, sorry for any confusion. It's not strictly needed, but it makes some memory management easier, and fits well with GTK memory management. And this last point helps a lot to maintain the GtkTreeStore on src/symbols.c, now tags are updated and not
Re: [Geany-devel] tagmanager changes
On 29/04/2012 15:47, Colomban Wendling wrote: Le 26/04/2012 18:53, Nick Treleaven a écrit : On 26/04/2012 16:02, Nick Treleaven wrote: On 24/04/2012 22:31, Colomban Wendling wrote: * it uses the same tag parsers tagmanager used, in ctagsmanager/ctags; BTW this is a good idea to clearly separate CTags from tagmanager. If this change can be applied separately, perhaps it could be merged into master. It should be quite easy -- though it won't still be a vanilla CTags of course, my own isn't either (yet?). I just thought it was a separate change from the TM rewrite. We have a lot of changes from CTags e.g. new languages and improvements to existing parsers (and even CTags itself) which IMO we can't throw away. It is possible to merge some changes from CTags but for e.g. c.c this has become pretty difficult. I tried this once but it ended up breaking the parser and I didn't work out why. IMO the biggest issue with CTags is that it isn't really maintained and they rarely accept patches even when it fixes an important bug (e.g. a fix to regex callback parsing with ignored matches). For avoiding resorting of workspace tags when only reparsing one source object, we can remove the source object's old tags merge the new tags. This is all O(n) for the workspace array. I haven't looked into implementing this yet because now it's clear you're working on a competing change. Another option is to remove the workspace array altogether and just have Geany collate tags from each (sorted) source object when needed. Not sure the implications of this yet but it would simplify tagmanager. Well, tagmanager needs to know all tags to perform e.g. scope completion beyond file's boundaries. And for search too, it would need us to pass it everything, or to perform a search on each document's tags and then merge the result. Doesn't sound sensible at a first glance, but maybe I'm missing something. It comes to a trade off between merging/sorting results from multiple tag arrays and merging/sorting the whole workspace array even when only one document is reparsed. Actually I suppose the first one can cause lags which the user could notice if there are a lot of results, whereas the second one only causes problems on reparsing, which is less often than searching. I'm undecided. The second one can be more serious if the calling code doesn't handle e.g. save all specially and the workspace array size is quite big. The special handling is to not update the workspace array until all documents have been parsed, then to resort it. If it's only save all, we can cope, but there may be other ways this can happen. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Rewrite reflow
On Sat, 31 Mar 2012 13:48:59 +0400 Eugene Arshinov earshi...@gmail.com wrote: Hi all. A couple of weeks ago in Geany mailing list a discussion was raised about reimplementing Reflow paragraph command more correctly and consistently with Line breaking. Here is a link: [1] Finally I got to it and created pull request #35 [2]. As always, suggestions are welcome. [1]: http://lists.uvena.de/geany/2012-March/007960.html [2]: https://github.com/geany/geany/pull/35 -- Best regards, Eugene. A reminder for myself: after the pull request is accepted (if it happens anytime), it would be good to check bug report [3]. This bug report is about cursor positioning after reflow. Also, it would be good to check cursor positioning after Join lines. [3]:http://sf.net/tracker/index.php?func=detailaid=2875092group_id=153444atid=787791 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
