Re: [PATCH] Scaffold -- some gnome-build leaks fix
Rui Lopes <[email protected]>
| Newsgroups | gmane.comp.gnome.devtools |
|---|---|
| Message-ID | <1062818469.4819.246.camel@localhost> |
Hellos, On Sex, 2003-09-05 at 10:47, Jeroen Zwartepoorte wrote: > Hi guys, > > Rui: thanks for the patch :) No Problemo :) > Comments below. > > On Fri, 2003-09-05 at 05:07, John (J5) Palmieri wrote: > > On Thu, 2003-09-04 at 22:02, Rui Lopes wrote: > > > Hi all, > > > > > > Here are some gnome-build leaks fixes for am backend. > > > > > > > > > I need you to look at my XXX/TODO comments and tell me what you think! > > > > Looked them over. A couple of comments: > > > > You don't need the \n at the end of g_message/g_error/etc. because it > > already puts it there. > > > > info->build_dir = NULL; /* XXX: Why? */ - Always good to NULL out your > > variables after freeing them because failing to do so may cause a > > process to read invalid data and makes it easier to track down bugs. I > > always see a lot of assert(var!=NULL); but never > > assert(var!="dfhfs#$%f"); Plus NULLing out a variable can't hurt. > > You get all kinds of weird crashes when you reference a variable which > has been freed, but not "reset" to NULL. This is generally a good > practice. Yes, I known all that; I should have noted that we don't need that NULLing because in the next line we are affecting it to a sane value. :) [...] > > /* TODO: These paths should come from a configuration interface .. */ - > > Yes, these should come from gconf. > > Yeah, this is on my TODO list. I want to be able to have Run & Build > configurations in gnome-build. This basically comes down to the > following: a user can define a new Run or Build configurations, specify > which prefixes he wants to use, which parameters etc. I would also like to be able to create several run&build configurations for the same project. > This involves some > heavy hacking in gnome-build. But it has to be done. hehe [...] > > /* XXX: gnu regex do not support utf8, we should use PCRE */ - What is > > PCRE and is it a standard component. We don't want to introduce > > dependencies. Besides why would one need utf8 support for parsing > > sourcecode? I don't know of many languages that use special characters > > out of the ASCII range and internationalized text is usualy taken care > > of in the translation files. > > GNU regex _does_ support UTF-8, as of glibc 2.3 iirc. Otherwise > highlighting of UTF-8 files in GtkSourceView wouldn't work either (try > opening an XML file with UTF-8 text (schemas file for example)). Humm, I will risk to say it would work, since all chars on highlight regexs are ASCII, even if not interpreting the file text as UTF-8. Ok, so say gnuregex supports UTF8, it will work on current locale charset, right? but glib is using UTF-8 :/ Here on FreeBSD, we use gnuregex 0.12 from http://www.gnu.org/directory/text/regex.html with a few changes http://www.freebsd.org/cgi/cvsweb.cgi/src/gnu/lib/libregex/regex.c. By looking at the code I cant say if it supports UTF-8, there is no mention to it in sources :// BTW, while looking at this I found a bug on glimmer(?) that might be related, try this: 1. create a new document 2. write some non ASCII chars, say, ááááá 3. search for one of those chars; You will see that two of them are highlighted, but if you select the "Case sensitive" check-box it will work just fine.. weird. I've looked at the glimmer sources (libglimmerfile/dialogs/glimmer-dialog-find.c) and didn't found a reason for this. :( This works fine on gedit (GtkTextView).. maybe this is a bug in GtkSourceView 0.6.0? > > /* TODO: Get font description from config */ - Again this should come > > from gconf > > The gnome-build plugin in scaffold will eventually add a preference page > to the scaffold preference dialog. Things like the font that's used for > the build output can be configured here. The actual pref will indeed be > stored in gconf. Good, the comment is just for making a hard note on that. ;) > Rui: i'll try and get your patches reviewed/committed by the end of the > weekend. Great! Regards, Rui Lopes