Re: [PATCH] Scaffold -- some gnome-build leaks fix



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]