Lately I have seen there are lots of places in the code where we have:
return …expression… ? Qtrue : Qfalse
I think all of these cases may be replaced by
I can script the change if you agree, and even add some autotest at
build time to check there are no new such things?
I have replaced all “foo == Qnil” by “NIL_P(foo)”. I think it might
be useful to add some autotest to keep that clean in the future, what
do you think?
Recently, I have also fixed a method implemented with the variable
arguments list form but attached to the ruby class with a fixed
arguments list. I can script a check and add an autotest for it.
Also, I have fixed a couple of memory leaks in gdk-pixbuf-scale, gtk
returned a newly allocated object and we need special magic on it; for
that, I would suggest to share the “special magic” with a special
macro, for example NEWGOBJ2RVAL; and also, I think we need an
automatized way to track all these memory leaks; what do you think of
making use of the scheme definitions used in pygtk? they use
“caller-owns-return #t” to indicate where a new allocation supposed to
be freed later is performed
I have seen that when using RARRAY(foo)->ptr or other pointer
dereferencing on a Ruby array, often there is “Check_Type(foo,
T_ARRAY)” before. However, I cannot find “official” rb_check_type
documentation to understand what it does exactly (is there any ruby
development API documentation available? I repeatedly bump into that).
Anyway, I suppose Check_Type is a good thing™, so I’d like to also
add an autotest to check that all RARRAY(foo)->ptr use cases are
always following a Check_Type, what do you think?
Phew, enough rg2 brainstorming for today
 would that be ok to write these scripts in perl?
Guillaume C. - http://zarb.org/~gc/
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.