donscarletti is currently certified at Master level.

Name: Caleb Moore
Member since: 2004-01-19 17:18:42
Last Login: N/A

FOAF RDF Share This

No personal information is available.


Recent blog entries by donscarletti

Syndication: RSS 2.0

I havn't blogged for a very long time, possibly because I've had nothing to say.

Anyway, today I'd like to talk about Mono and its inclusion into Gnome. I have not commented on it in my blog so far, because I only use C and thus have no relevant opinion on the technical merits of the platform and have always thought it best to shut up in these circumstances. Today on the gnome-devel-list I read an email on the subject by someone called Tsume who directed readers to his personal web site containing his views on the issue.

Wow, some insightful stuff there. With brilliant points like "I've nothing against Python. I'm a ruby programmer, but would be very happy with Python" this is sure to raise eyebrows. Also the shocking revelation that Miguel is trying to get Mono into Gnome really set me aghast. The IRC logs especially were a great touch, they proved once and for all that mono has bugs and that some bugs are given lower priority than others because they are seen as more difficult or less harmful.

Sarcasm aside however, all is not lost. It does demonstrate by far the largest problem with mono. Technical merits or the lack thereof aside; mono is a political quagmire. Choosing mono is like painting your bikeshed pink, it's a warm colour and it reflects light well, but it will always be obvious that the bikeshed is pink and the conversation will never be over with people with suggestions as to why it should have been painted a different colour. Mono calls its bytecode files .exe and .dll for a start, while that means nothing more sinister than .jar or .pyc do, it is instantly recognisable as something uncool. Every slashdot article, review and blog will mention it and think they are insightful, just like this guy did. The jeering and booing will be annoying and possibly even affect peoples willingness to participate lest they associate themselves with something that is surrounded with spook stories about Novell and Microsoft (especially young people).

However good mono might or might not be, is it worth it?

Philip (sorry to everyone else syndicating or hosting this blog and are reading strange chatter). What I mean is that the filter primitive element has the attribute id="SourceGraphic" when clearly it is supposed to mean in="SourceGraphic" (i.e. reading the input to this filter primitive from the element the filter is applied on). There is no real reason to set an id on a filter primitive since there is not instanceable anyway. Of cause it was a bug, it was a nasty crasher that could be invoked on valid input, but it wasn't really holding up much functionality since there is no practical reason for that attribute to be there. B.t.w. there is no requirement that all elements have ids which is why there was nothing like that in the test suite.

We messed up a month ago with a regression, we fixed the problem within a day and we rolled out a new version. The fact that you decided not to remove the redundant id attribute "because I don't want to set a precedent for accounting for every minor release of every library" and it caused problems with those unlucky enough to not be able to access the new release hardly makes me feel sympathetic to you that you are being blamed for the crash. Sure, it was within your rights to leave the id attribute in, because it is valid according to the standard, but standing on your rights doesn't exactly help people who's software is crashing all around their heads.

The fact remains, we screwed up. Actually, I'd go so far as to say that I screwed up, being the one who made the regression in question. I screwed up, we fixed the bug within a day of discovery, we then made a new release. You diagnosed the bug exactly as being related to an id attribute on a filter primitive, you evaluated whether to work around it, you decided against it, SUSE users got pissed off. In situations like this where you have users to satisfy, making two blogs about the bug a month apart making it look like you are currently waiting for us to pull our thumbs out of our arses is hardly fair when you had the means to avoid the bug to begin with.

I'm not against people mentioning problems with librsvg, I don't think librsvg is bug free and I don't think anyone else does either. I simply think that mentioning a single, minor bug twice on your blog, the first time in great detail is unrepresentitive of our firm commitment to fixing bugs.

behdad The latest public release is here

Librsvg 2.13.2 was released late last night, it has a rewritten text subsystem and now supports trefs, it also judges the size of unspecified sized images far better and parsing should be a little more robust with malformed input. Also, dimensions specified in the SVG that are specified relative to the viewport or dpi are handled far better. Internally it's a hell of a lot cleaner as we consolidate the core in preparation for DOM level 1 support. Dynamic SVG support is getting very close with recent work, I sure hope people actually use it when we support it. Also this version has improved external reference support when used with the rsvg command, the command line utility is no longer worse than the x program/browser plugin at handling relative paths for resources.

I installed Tango a few days ago, I find it to be very nice, though to be honest I think I'll switch back to Gartoon soon since it's just so much of an awesome theme. For some reason I'm not to fussed on those grey folders, but that's just personal preference. Despite the grey folders, I think it possesses style, consistency and class. Now I think about it, I'm not fussed on the "lock screen" icon either but you know, worse things happen at sea. Tango also lead to my weirdest experience ever on bugzilla when I fixed a bug relating to tango but everyone else involved did not want to let me close it because I refused to acknowledge that it was a major problem before I fixed it. I don't know if this was sort of like a Alcoholics Anonymous step one of twelve where recovery cannot be made unless the problem was acknowledged. Or maybe everyone finally got sick of my insufferable arrogance and are trying to teach me a little humility, I don't know.

While I'm talking about bugs I've fixed, I'm amazed to see Philip Langdale making a second blog mention about a single closed bug in librsvg, especially when that bug was invoked by the misspelling of "in" as "id" in the document in question. Of cause we are grateful that this bug has been disclosed so it could be fixed, because our library should not crash on any input, no matter how unlikely. But to be honest I still don't get why the file in question was not adjusted by simply having a single line changed to work around the bug (and make the file make a lot more sense) but then again that's none of my business. I guess he's just trying to let everybody know that the crash isn't his fault, which is very fair in this situation. By the way, the version of librsvg 2.12 that fixed that problem came out in Ubuntu a couple of days after it was reported iirc. But then again, this may be just another case of me trying to understate the severity of bugs for my own personal gratification.

Magic Eye renderer

I renamed my deformed pattern stereogram renderer "Palantír", which is like the most awesome name for a renderer ever (in my personal opinion). I havn't actually brought out a version with that name, but I wanted to boast about the name I'm using anyhow. I sure hope Tolkien's estate doesn't have a crack team of lawyers out to kick my butt over this though. The next version to be released will use diffuse lighting for preview generation instead of making a heightmap. I've modified it to be able to render things in front of the focal plane, so they actually pop out at the viewer when seen with crossed (rather than diverged) eyes. As far as I know, I'm the first person to ever create images like this which is really cool and it is all open source of cause. You can see the stanford bunny in this way here.


I still don't have my cheap Nokia 770 yet, which sucks because I've already written stuff for it. It's probably because I live in Australia, I might have to get one by proxy.

Magic Eye Renderer

I checked up with "the man" and I'm allowed to release my "special project A" GPL. So here it is!

Source code to the actual renderer

A shallow, easy to view cone.

The Stanford bunny ~60k polygons.

The Stanford dragon ~1M polygons.

If you have not encountered these types of images before and wonder what is so special about them, they are a type of 3d optical illusion. You should be able to find viewing instructions for them somewhere.

25 older entries...


donscarletti certified others as follows:

  • donscarletti certified cinamod as Master
  • donscarletti certified sdodji as Master
  • donscarletti certified Uraeus as Master
  • donscarletti certified Stevey as Master
  • donscarletti certified donscarletti as Master

Others have certified donscarletti as follows:

  • cinamod certified donscarletti as Master
  • Uraeus certified donscarletti as Master
  • elanthis certified donscarletti as Master
  • sdodji certified donscarletti as Journeyer
  • Penix certified donscarletti as Journeyer
  • jarashi certified donscarletti as Journeyer
  • strider certified donscarletti as Journeyer
  • donscarletti certified donscarletti as Master
  • kclayton certified donscarletti as Journeyer
  • adl certified donscarletti as Master

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page