Re: [Geany-devel] editing big files can be too slow with tag reparsing
On 28/09/2011 00:45, Lex Trotman wrote: Nick, Thomas, [...] 0001-Per-document-real-time-symbols-setting.patch: Adds a per-document setting for real-time updates and a menu item in the Document menu. There is still a FIXME in it, feel free to give ideas :) @Nick, there are lots of large generated files a programmer might want to check, especially XMLs and logs, saying there is an xxxGb maximum is wrong, it depends on the machine the user has. Forcing them to have to go use another editor or to not have highlighting is bad. You edited out my reply which addressed that: On 27/09/2011 17:17, Nick Treleaven wrote: 1. Very big files x MB - I don't think we need to support that case specially, Geany is a programmer's editor. The user can just open as filetype none if they only want basic editing. In the open dialog, choose filetype None and you can easily open big files, plus it will be faster as syntax highlighting won't be enabled. @Thomas, and since the problem is with a specific large file, Colomban is right it is per document, since you only need to turn off the one that is too large. @Nick, therefore not per filetype either For large files an auto-disable reparsing feature would work fine. 0002-Tell-the-user-if-real-time-reparsing-is-slow-and-let.patch: This one adds the check for the updating duration and asks the user. It is WIP, and I'm not really convinced by the dialog, as you can read in a TODO. Apart that, it seems to work pretty OK. This is more what I meant. I'm not so sure an extra dialog is needed, but if people want one that's ok. Would a don't ask me again checkbox be a good idea (if it doesn't already). @Thomas, While I still think automatic changing of settings is a last resort, and as Nick said what performance number is acceptable? If we do add it, the user must be notified, but a don't tell me again is ok (for the session) Perhaps I was wrong with 0.2s, maybe 0.5s (I didn't check Colomban's code to see what he used). @Nick no one reads the status bar, sadly A dialog is too intrusive. Consider opening 10 slow files and having to click the dialog for each one. Status bar is fine - as you sometimes say programmers don't need to be treated like newbies. Not having tag reparsing enabled will mean a few invalid bug reports at worst. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] editing big files can be too slow with tag reparsing
On 28/09/2011 12:03, Nick Treleaven wrote: @Nick, there are lots of large generated files a programmer might want to check, especially XMLs and logs, saying there is an xxxGb maximum is wrong, it depends on the machine the user has. Forcing them to have to go use another editor or to not have highlighting is bad Sorry, I missed the bit where you said no highlighting is bad. But in that case, auto-disable works fine. In any case, there is no xxx Gb maximum, I just meant that we shouldn't have a document menu option that is only for disabling reparsing when it can be done automatically. Also I'm not sure whether Scintilla handles very big files well. I don't think we need to be concerned about that. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Bug on utils_string_replace()?
On Sun, 25 Sep 2011 20:11:06 +0200
Colomban Wendling lists@herbesfolles.org wrote:
Le 25/09/2011 20:01, Colomban Wendling a écrit :
Le 25/09/2011 19:36, Thomas Martitz a écrit :
Am 25.09.2011 19:20, schrieb Frank Lanitz:
Hi folks,
I found a possible issue with changes done on
utils_string_replace-* functions i've added a workaround to
geanysendmail with svn r2214.
I was digging a bit and I guess I found the smoking gun.
Unfortunately I'm not 100 sure how to fix it without breaking
anything.
This is what I found:
/* Replaces @len characters from offset @a pos.
* len can be -1 for str-len.
* returns: pos + strlen(replace). */
gint utils_string_replace(GString *str, gint pos, gint len, const
gchar *replace)
{
g_string_erase(str, pos, len);
g_string_insert(str, pos, replace);
return pos + strlen(replace);
}
is not checking whether replace is != NULL so its failing with a
segfault. I was able to reproduce it on geanysendmail with this
backtrace:
#0 0x004b9bd4 in utils_string_replace
#(str=0x31518c0,
pos=117, len=2,
replace=0x0) at ../src/utils.c:1561
#1 0x004b9c6b in utils_string_replace_all
(haystack=0x31518c0,
needle=0x7fffe7b3e68c %r, replace=0x0)
at ../src/utils.c:1588
#2 0x7fffe7b3d619 in send_as_attachment
#(menuitem=0xb692c0,
gdata=0x0)
at ../geanysendmail/src/geanysendmail.c:152
#3 0x75d1de7e in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
#4 0x75d2f8d7 in ?? ()
#from /usr/lib/libgobject-2.0.so.0 5 0x75d38d05 in
#g_signal_emit_valist ()
from /usr/lib/libgobject-2.0.so.0
#6 0x75d38ed3 in g_signal_emit () from
/usr/lib/libgobject-2.0.so.0
However. I'd add a g_return_val_if_fail (replace != NULL, pos);
but not sure whether this will break anything. Opinions?
Cheers,
Frank
The caller should be fixed, passing NULL makes no sense at all.
Agreed (though one might argue about treating NULL as an alias of
, but huh...).
However, I'm not against adding a g_return_val_if_fail(). This is
meant for defensive programming, while still showing it's not
correct -- g_return*_if_fail() will emit a warning (or do nothing,
depending on a build-time setting).
Hum, I should have blamed the file before answering. Actually the
behaviour of utils_string_replace_all() seems to have changed, because
it seems it used to accept NULL (and I guess it was treated as ).
I think then we should restore the previous behaviour not to break the
plugin API -- e.g., and as Frank noticed, now all plugins passing NULL
will start to segfault while they worked seamlessly using 0.20.
Any opinion? (Nick?)
Just want to bring it up again. Release is near so at least we should
add a comment to api documentation about this.
Cheers,
Frank
--
http://frank.uvena.de/en/
pgp3m18AwDeEF.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] Use GtkBuilder
On Mon, 26 Sep 2011 12:33:30 +1000 Lex Trotman ele...@gmail.com wrote: On 26 September 2011 01:26, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: When we upgrade (someday) to 2.16, why not make VTE a compile time option only? I can understand why somebody would like to compile Geany without vte support, but since all novadays gtk+ terminal emulators are based on vte, making it a run-time option seems like overkill to me. It was a good thing, several years ago... The problem with this is that means that all binary packages now depend on vte. Of course. However: - when using binary packages, you should be prepared for some extra dependencies - again, all novadays gtk+ terminal emulators are libvte based. If you might want to compile it out, then you might not want to install it. Hmmm... Just how many programs have you seen that can be compiled --with-libfoo but started without libfoo? Aside from Geany, I only know of mplayer which can be compiled with win32 dll-s support, but started even if no dll-s are present, for obvious reasons. If you want to install it out, compile it out. Or there would need to be several binary packages, with and without VTE compiled in which is more maintenance. No sane package maintainer will bother. When checking the various preferences or something, I found 2 crashes when vte is compiled but not loaded. That kind of hints how many people use Geany with vte compiled but not installed... With the runtime check VTE does not need to be installed. Indeed. :) Let's hope there aren't any more crashes. Not that anyone will notice them. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Bug on utils_string_replace()?
Le 28/09/2011 19:36, Frank Lanitz a écrit : On Sun, 25 Sep 2011 20:11:06 +0200 [...] Just want to bring it up again. Release is near so at least we should add a comment to api documentation about this. Right. Fixed now in r5965, thanks. If we want to deprecate the use of NULL here, I think we better do it after the release so plugin developers have a chance to fix their use until next-next release. Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] editing big files can be too slow with tag reparsing - HTML
On Tue, Sep 27, 2011 at 14:17, Nick Treleaven nick.trelea...@btinternet.com wrote: On 26/09/2011 23:00, Colomban Wendling wrote: Le 26/09/2011 13:48, Nick Treleaven a écrit : I'm reduced to using Windows. I guess the reason is the regex code that is really old which is used for Windows builds. Maybe yeah, but I find it a little weird you see *so much* slowness... For comparison, on my machine [1] parsing and updating the list takes less than 60ms for geany.html. Just to be sure, are you seeing the 'built-in regex' debug message: 12:42:07: (null) INFO : GTK 2.22.0, GLib 2.26.0, built-in regex It might help to update it from CTags (we had a patch from Jiri Techet but it didn't look like it would build on Windows, i.e. wasn't from CTags). Maybe we could use GRegex now we have a GLib recent enough? Anyway tagamanger/regex.c looks like a few glibc source file concatenated with a 0xff separator, I'd then guess any POSIX RE implementation (e.g. today's glibc's one) would do, wouldn't it? That's probably what Jiri did, but I noticed CTags had some modifications to build on Windows. Perhaps glibc would work, but I think taking it from ctags is safer. Basically I took the (then) latest versions of the regex files plus the makefile from ctags. The patch still applies by the way. I've just diffed the result of my patch with the ctags regex and there aren't big differences. What I've forgotten include into my patch is a conditional include under windows in regex_internal.h so if you want to use my patch, substitute this file with the ctags one. I haven't tested it under Windows myself so I don't know what happens. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Use GtkBuilder
Hi Dimitar, [...] When checking the various preferences or something, I found 2 crashes when vte is compiled but not loaded. That kind of hints how many people use Geany with vte compiled but not installed... With the runtime check VTE does not need to be installed. Indeed. :) Let's hope there aren't any more crashes. Not that anyone will notice them. Ok, if thats the case lets ignore the possibility of runtime loading and just compile it in/out. Cheers Lex -- E-gards: Jimmy ___ 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
