I don’t understand. Why did almost nobody list their ideas on the Mentored Projects page? There was all kinds of discussion about what projects should be in the Google Summer Of Code, and lots of potential mentors didn’t have their favourite projects chosen. So, give the task another chance.

As GUADEC approaches, it’s really time for me to update my hackergotchi so people don’t tell me afterwards that they wished I had been there.

Unfortunately this also means that less people will meet me and remember me as particularly wise and with a German accent too. If you’ve had that experience already then you’ve actually met Matthias Clasen, who indeed does the work of two people.

That’s three or four years of not looking half normal while simultaneously being between a camera and a plain background. I did my best with the normal-looking, but I plan to be dissatisfied with this one for another few years.

This takes me ages to do in GIMP. If anybody would like to do a better job, here is the original:

Update: Mark Slater made a better one, though it shows up with a black background in WordPress when I import it into WordPress. Let’s see how it looks online:

I had an email discussion recently with Anne Østergaard about the major lack of female involvement in GNOME, and free software in general. I’m so proud of our community and how it lets talented people get involved, without all the obstacles that they find in the offline world. But it’s obvious that women are not yet taking advantage of this opportunity. I feel ashamed of that.

I tend to blame schools, universities, parents, and society for not encouraging young women to be enthusiastic about engineering and software. In view of of our openness, plus our general left/liberal leaning I feel sure that we are part of the solution rather than part of the problem. Even if we can’t influence kids when they are young enough to start forming these opinions, surely we should be seeing the few women who are determined enough to get involved despite all the problems. But why isn’t that happening yet?

I don’t know how to personally help fix this problem. I don’t find new open source developers directly. They usually find us. Do we need to change something about how they see us or find us? Are there organisations that are trying to fix this problem that we should make contact with?

I don’t believe that this is about emphasizing different activities. It would be wrong to say “Here are some less demanding tasks for the girls”. And as long as the atmosphere is not actively sexist, I don’t think it’s a problem that we spend our time discussing technical stuff. I don’t think there’s anything particularly male about technology, or how we approach it. (We do need to get more non-technical people involved, but not for this reason.)

But clearly there’s something wrong in my theories, or I am overlooking something, because we should be doing better.

Update: Jeff pointed me at this Flosspols report. It’s fairly readable and has some interesting conclusions and recommendations, despite the unfortunately small sample size, but I think Callum does a better job of saying much the same thing.

One contradiction that troubles me is that we a) obviously need to do something proactive, but b) we apparently discourage some women simply by giving them too much help, making them feel uncomfortably singled out. But on balance, I don’t think we can make things much worse than the current 1%, and we can’t be more unjust than what we have now, so some kind of affirmative action must be worth a try. Maybe some kind of group project, like a women-only Summer Of Code in which the students are allowed to work together? If someone had a plan then us F/OSS veterans could try to make it happen.

Or should we advise women to try to conceal their gender online?

I posted this to gtkmm list today. I’ll repeat it here because smart people read planet GNOME.

I have recently done some work to optimize gtkmm for code size, for use on embedded devices, such as Nokia’s 770 internet table. I was concerned that, for instance:

• the _stripped_ code size of gtkmm 2.6’s libgtkmm .so is 2.5M on i686,
• which is comparable to the size of libgtk-x11’s .so (version 2.8 is 2.9M).

It didn’t seem right that the wrapper is as big as the thing it wraps, because our method implementations are so small.

I have discovered that a large part of this code size is explained simply by the size of our API, and we have a lot of extra convenience API compared to GTK+. Simply exporting a symbol adds to the code size. I shaved a few 100K off the .so size just by using the static keyword on private functions, to stop them being exported. The 2.5M number above is including these easy optimizations.

Optional API

I also added some glibmm configure options to remove rarely-used API. Remember, nothing will change on regular linux distros, because they won’t use these options:

• –enable-api-properties=no
  You can use get/set_property<>(“propertyname”) instead.
• –enable-api-vfuncs=no
  These are rarely needed. You can use the C function pointer instead.
• –enable-api-exceptions=no
  Methods that throw an exception have an extra std::auto_ptr& output parameter when this option is used. This allows use of the “-fno-exceptions” CXXFLAGS, which does not have much affect, but being able to use “-fno-exceptions” means that “-g -Os” (Optimize for code size) can start to be significant. Together they reduce code size by about 15%.
• –enable-deprecated-api=no
  Do not build deprecated API, such as Gtk::FileSelector. This option has been in tarballs for a few months already. This must be specified to gtkmm as well as glibmm.

These options will soon be in releases of glibmm 2.6, 2.8, and 2.10. Necessary changes will be in gtkmm 2.6, 2.8, and 2.9/2.10. Until Cairo is fully optimized, people are using GTK+/gtkmm 2.6 on embedded platforms, but some are using glib/glibmm 2.10.

Together, with the mentioned CXXFLAGS, these reduce total code size for all of the gtkmm 2.6 .so files by around 800K, or 23%.

Virtual methods

However, there is another huge gain to be made by removing default signal handlers, such as Gtk::Button::on_clicked(). The problem is that they are virtual methods, so we have to pay for them even if we don’t use them. We must pay for them in – code size: That’s a lot of symbols in libgtkmm, and the symbols must be listed in applications that use libgtkmm. – load time: the symbols must be resolved by applications that use libgtkmm.

Gtk::Widget has about 60 signals, so that’s at least 60 virtual methods for each widget. As far as I can tell, this increases the code size of each derived class, even if a derived-of-derived class, maybe due to multiple inheritance.

I have not yet committed this configure option to cvs, because this is the most disruptive option. Overriding virtual methods, instead of connecting signals, is quite convenient, but I don’t think it’s worth the cost on an embedded platform just for convenience. I might commit it later. The patch is here: http://bugzilla.gnome.org/show_bug.cgi?id=341380

It removes an extra approx. 500K from the libgtkmm code size.

I also have a simple patch to remove libatkmm, which is not yet very useful on embedded devices.

Failed attempts

• I have not noticed any significant reduction in code size by using the -fno-inline CXXFLAGS. I had thought that there might be a lot of RefPtr or sigc:: inlining, but I guess that the implementations of these functions are not significantly larger than a function call itself.
• I have tried ripping libsigc++ apart to reduce the number of templates and template parameters that are used, with almost no effect. Based on this, and my other code-size investigations, I no longer believe the commonly-mentioned theory that libgtkmm is large because of too many template instantiations. I’d gladly be proven wrong.
• I can strip a few more 100K from the code size by turning the /private/*.h callbacks into functions instead of class methods, and marking them as static, but I would then need to make various protected parts of the classes public.
• I tried hacking libtool to allow me to use regex to exclude anything with “Anonymous” in the name, to exclude anonymous namespaces, but it made no difference to code size, though the symbols no longer showed up in the nm output. Obviously there’s more to it than that.
• I tried various values with -falign-functions, but could not achieve anything other than making the code size larger.
• -fvisibility-inlines-hidden increases the size of libgtkmm by about 20%.

Summary

I believe that the remaining code size is just a fact of life of using C ++, and of having such a large (capable) API. In particular, we must list all those symbol names, and C++ symbol names are larger than C symbol names, due to the (wanted) namespaces and mangling. I can imagine that the linker/ELF could some kind of compression, but that would slow down load times.

But it is rather difficult to analyze code size: https://www.murrayc.com/blog/permalink/2006/02/15/c-code-size/ so I hope that some of you have some more ideas.

These options (and the patch) do at least mean that developers would not have to pay for things they don’t use. That is the C++ philosophy.