<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>Advogato blog for dajobe</title>
    <link>http://www.advogato.org/person/dajobe/</link>
    <description>Advogato blog for dajobe</description>
    <language>en-us</language>
    <generator>mod_virgule</generator>
    <pubDate>Sat, 18 May 2013 13:51:23 GMT</pubDate>
    <item>
      <pubDate>Thu, 15 Jan 2004 00:30:08 GMT</pubDate>
      <title>15 Jan 2004</title>
      <link>http://www.advogato.org/person/dajobe/diary.html?start=13</link>
      <guid>http://www.advogato.org/person/dajobe/diary.html?start=13</guid>
      <description>&lt;p&gt;&lt;b&gt;Redland and Raptor Bughunt&lt;/b&gt;

&lt;p&gt;All praise &lt;a href="http://valgrind.kde.org/" &gt;valgrind&lt;/a&gt;!
It finally managed to find where &lt;a href="http://www.advogato.org/proj/redland/" &gt;redland&lt;/a&gt;
was crashing when used with &lt;a href="http://www.advogato.org/proj/PHP/" &gt;PHP&lt;/a&gt; and one class.
It was a combination of PHP and &lt;a href="http://www.advogato.org/proj/swig" &gt;SWIG&lt;/a&gt;
conspiring to do the wrong thing with a null string and NULL object
pointer, a configuration error on my part.

&lt;p&gt;This debugging was made much harder by the annoying things that
are threads, which seem to be used more and more with useful shared
libraries, causing debugging nightmares.  Does anyone understand how
to get gdb to do the right thing with this?  I certainly don't,
mostly facing a dead stack trace until the planets align right and
it'll let me set a breakpoint in a shared-library that isn't loaded
yet, let me run the code and stop at the breakpoint.  Bah!

&lt;p&gt;Anyway, onwards.  Added some defensive code to try to catch this
thing again and in the course of updating the debug code, found the
&lt;tt&gt;__func__&lt;/tt&gt; pseudo-variable in C99 which is handy and can
replace a lot of hand-coded bits.

&lt;p&gt;Things seem to be building ok now, and the new MySQL backend for
Redland is looking solid, so it's nearly time for another release.
It always seems to take a week to do that, rather than sling
the code out the door untested.

&lt;p&gt;&lt;b&gt;Planet RDF&lt;/b&gt;

Last week I helped build &lt;a href="http://planetrdf.com/" &gt;Planet RDF&lt;/a&gt;
based on existing code my friends had, with me mostly
providing the additional hacking for fixing the mess that is HTML in
RSS and the glue to make the thing update.  It's looking good.
</description>
    </item>
    <item>
      <pubDate>Sat, 1 Nov 2003 15:19:58 GMT</pubDate>
      <title>1 Nov 2003</title>
      <link>http://www.advogato.org/person/dajobe/diary.html?start=12</link>
      <guid>http://www.advogato.org/person/dajobe/diary.html?start=12</guid>
      <description>&lt;p&gt;&lt;b&gt;Cairo graphics debian packaging&lt;/b&gt;

&lt;p&gt; &lt;p&gt;In a fit of enthusiasm last weekend, I made debian packages (debs)
of the
&lt;a href="http://cairographics.org/" &gt;Cairo project&lt;/a&gt;
sources from CVS in order to get it building for Mono.  Cairo is a
vector graphics library for cross-device output
intended to be similar
to PDF 1.4; it was once called Xr.

&lt;p&gt; &lt;p&gt;I mentioned this to the Cairo people last week and, ta da, I'm now
maintaining them and have CVS access.  The debs for the
&lt;a href="http://cairographics.org/snapshots/" &gt;cairo snapshots&lt;/a&gt;
are presently hosted on
&lt;a href="http://freedesktop.org/~cairo/debian/" &gt;freedesktop.org&lt;/a&gt;
before they move to the main site, after some server reorganising.
So if you add this area to /etc/apt.sources.list with
&lt;pre&gt;deb http://freedesktop.org/~cairo/debian/ ./&lt;/pre&gt;
&lt;p&gt;you can get a one-line install of the Cairo libraries without dependency hell.


&lt;p&gt; &lt;p&gt;&lt;b&gt;Mono&lt;/b&gt;

&lt;p&gt; &lt;p&gt;Pushing the stack back to my original goal, Mono is now building
for me from CVS, although I can't say I've tested the use of Cairo
significantly, Monodoc using GTK# is working.  Although building Mono
from CVS is yet another story...


&lt;p&gt; &lt;p&gt;&lt;tt&gt;hacking life&lt;/tt&gt;

&lt;p&gt; &lt;p&gt;And finally, as the #cairo channel on Freenode was discussing the
&lt;a href="http://www.cafeshops.com/freedesktop" &gt;hacker glider logo apparel&lt;/a&gt; (proceeds to EFF)
I came up with the &lt;em&gt;hacking life&lt;/em&gt; slogan for it.  I think
that works pretty well.  The logos were, of course, made using
Cairo.


</description>
    </item>
    <item>
      <pubDate>Wed, 20 Aug 2003 19:29:44 GMT</pubDate>
      <title>20 Aug 2003</title>
      <link>http://www.advogato.org/person/dajobe/diary.html?start=11</link>
      <guid>http://www.advogato.org/person/dajobe/diary.html?start=11</guid>
      <description>&lt;p&gt;&lt;b&gt;Redland and Debian Packaging&lt;/b&gt;

&lt;p&gt; &lt;p&gt;Phew!  My RDF/XML parser &lt;a href="http://www.advogato.org/proj/raptor/" &gt;raptor&lt;/a&gt; (a C library, depends
on &lt;a href="http://www.advogato.org/proj/libxml/" &gt;libxml&lt;/a&gt; and 
&lt;a href="http://www.advogato.org/proj/cURL/" &gt;cURL&lt;/a&gt;) has been in Debian
sid/unstable for a few months now so it was time to attempt
the big beast, &lt;a href="http://www.advogato.org/proj/redland/" &gt;redland&lt;/a&gt;. That's my main RDF
system and as well as the C library, it has 6 other language
interfaces - perl, python, ruby, java, tcl, php and I'm
working on CLI/C#.

&lt;p&gt; &lt;p&gt;This list has felt a bit daunting for me to deal with, however
after the raptor experience I was confident the C library part would
at least be straightforward.  Over the last 4 days I've added some of
the languages slowly, while studying the mysteries of the Debian perl
and python policies.  To that I've added waiting for sid/unstable
to be buildable so I can use pbuilder to check that I have
all the correct dependencies, and decoding various packages
to see how they did things.

&lt;p&gt; &lt;p&gt;So the current state is that I've got the C (and -dev), perl,
python and ruby
&lt;a href="http://www.redland.opensource.ac.uk/dist/binaries/debian/" &gt;debian packages&lt;/a&gt;
building without error in pbuilder, "&lt;em&gt;lintian clean&lt;/em&gt;"
and working once installed.  The next step is to see about
getting them into sid/unstable when my very busy sponsor
&lt;a href="http://www.advogato.org/person/edd/" &gt;edd&lt;/a&gt; has enough time to check them.
</description>
    </item>
    <item>
      <pubDate>Mon, 24 Mar 2003 20:13:31 GMT</pubDate>
      <title>24 Mar 2003</title>
      <link>http://www.advogato.org/person/dajobe/diary.html?start=10</link>
      <guid>http://www.advogato.org/person/dajobe/diary.html?start=10</guid>
      <description>&lt;p&gt;&lt;b&gt;Raptor&lt;/b&gt; - a little tune up

&lt;p&gt;I've been doing a bit of &lt;a href="http://www.advogato.org/proj/raptor/" &gt;raptor&lt;/a&gt; tuning to get down
the CPU and memory usage on large files.  I was always afraid of
premature optimisation and knew that things could be improved a lot
if I did some profiling and cut down the big problems.  The results
on a 550,000 triple rdf/xml file went from 172.8s for Raptor 0.9.8 as
released to 7.3s with the CVS sources - over 23x faster.  The
improvement was mostly due to:
&lt;ul&gt;
&lt;li&gt;A lot less strlen() on strings I already had the length for elsewhere
&lt;li&gt;Removal of many short-lifetime malloc()/free() pairs (thanks to &lt;a href="http://dmalloc.com/" &gt;dmalloc&lt;/a&gt;)
&lt;li&gt;using a set for &lt;tt&gt;rdf:ID&lt;/tt&gt; checking, rather than a list.
&lt;/ul&gt;
</description>
    </item>
    <item>
      <pubDate>Tue, 18 Mar 2003 23:30:15 GMT</pubDate>
      <title>18 Mar 2003</title>
      <link>http://www.advogato.org/person/dajobe/diary.html?start=9</link>
      <guid>http://www.advogato.org/person/dajobe/diary.html?start=9</guid>
      <description>&lt;p&gt;&lt;b&gt;Raptor&lt;/b&gt; and web libraries

&lt;p&gt; &lt;p&gt;Unlike in Java, Perl, Python and all those higher level languages,
in C when you want to do something like retrieve a web page, there is
a lot more to do.  There aren't &lt;tt&gt;stdurl&lt;/tt&gt; or &lt;tt&gt;stdweb&lt;/tt&gt;
libraries around that you can assume are always available.  Since
&lt;a href="http://www.advogato.org/proj/raptor/" &gt;raptor&lt;/a&gt; is a parser for an XML language,
&lt;a href="http://www.advogato.org/proj/libxml/" &gt;libxml&lt;/a&gt; is one likely thing that is usable and it has a
tiny HTTP implementation, sufficient for GET.  There is the defacto
portable web library lib&lt;a href="http://www.advogato.org/proj/cURL/" &gt;cURL&lt;/a&gt; and so I make that also
configurable plus the &lt;a href="http://www.advogato.org/proj/W3C%20Libwww/" &gt;W3C libwww&lt;/a&gt; which is common but
rather large.  So problem solved.

&lt;p&gt; &lt;p&gt;Or so I thought.  It turns out that all those APIs except for the
W3C libwww are &lt;em&gt;push&lt;/em&gt; - they take the thread of control from
the caller and return data to it via callbacks.  However I wanted the
more I/O stream-like &lt;em&gt;pull&lt;/em&gt; i.e. the user application does
&lt;tt&gt;while(...) { get stuff; do stuff }&lt;/tt&gt;.  You can wrap a push API
around a pull one quite easily and efficiently, but not the other way
around - you need to store all the pushed content then deliver it
pull-by-pull.  So, I'm going to have to live with that - provide both
and warn users that the pull interface will suck up memory.

</description>
    </item>
    <item>
      <pubDate>Thu, 27 Feb 2003 00:35:42 GMT</pubDate>
      <title>27 Feb 2003</title>
      <link>http://www.advogato.org/person/dajobe/diary.html?start=8</link>
      <guid>http://www.advogato.org/person/dajobe/diary.html?start=8</guid>
      <description>&lt;p&gt;&lt;b&gt;FOAFBot lives, nearly&lt;/b&gt;

&lt;p&gt; &lt;p&gt; &lt;p&gt;I had another go at getting
&lt;a href="http://www.advogato.org/person/edd/" &gt;edd&lt;/a&gt;'s &lt;a href="http://www.advogato.org/proj/FOAFbot/" &gt;FOAFbot&lt;/a&gt;
running again with the updated &lt;a href="http://www.advogato.org/proj/redland/" &gt;Redland&lt;/a&gt; 0.9.12 API and it
now seems to not crash as much after I hand-edited some bugs that it
found in the latest version.  This is a good thing since I
&lt;em&gt;found&lt;/em&gt; the bugs and fixed them.  Of course that just leaves
the issue of why it runs and doesn't work.

</description>
    </item>
    <item>
      <pubDate>Sun, 16 Feb 2003 19:54:15 GMT</pubDate>
      <title>16 Feb 2003</title>
      <link>http://www.advogato.org/person/dajobe/diary.html?start=7</link>
      <guid>http://www.advogato.org/person/dajobe/diary.html?start=7</guid>
      <description>&lt;p&gt;&lt;b&gt;Redland and Raptor&lt;/b&gt;

&lt;p&gt; &lt;p&gt;What day is it?  Oh yeah, I released some software last week
- new versions of my &lt;a href="http://www.advogato.org/proj/redland/" &gt;redland&lt;/a&gt; and &lt;a href="http://www.advogato.org/proj/raptor/" &gt;raptor&lt;/a&gt;
RDF general and parser libraries respectively.  Took only
nine months since the last release of Redland, lots of bug fixing
and testing.  Plus all the pain of automake, autoconf, uploading to
SourceForge, writing Freshmeat news, announcements, release notes,
checking it works across solaris, linux, FreeBSD, OSX.  The latter
was a real pain - not quite UNIX enough for me.  Then I made
some RPMs and new debs.

&lt;p&gt; &lt;p&gt;So onwards to more releases.  I've already got some patches
received for win32 support for &lt;a href="http://www.advogato.org/proj/raptor/" &gt;raptor&lt;/a&gt; and I wanted
to move it on to the latest autotools, which seems to be working OK.
For &lt;a href="http://www.advogato.org/proj/redland/" &gt;redland&lt;/a&gt; I'm ready to rip out more code such as
the old repat parser, a bit obsolete.

&lt;p&gt; &lt;p&gt;I also just released that I've implemented SAX2 for C inside
&lt;a href="http://www.advogato.org/proj/raptor/" &gt;raptor&lt;/a&gt; since &lt;a href="http://www.advogato.org/proj/libxml/" &gt;libxml&lt;/a&gt; and &lt;a href="http://expat.sourceforge.net/" &gt;expat&lt;/a&gt;
only ever had SAX1-style interfaces - no XML Namespaces.  I should
think what to do with this, maybe talk to &lt;a href="http://www.advogato.org/proj/DV/" &gt;DV&lt;/a&gt;.

</description>
    </item>
    <item>
      <pubDate>Sat, 2 Nov 2002 19:42:29 GMT</pubDate>
      <title>2 Nov 2002</title>
      <link>http://www.advogato.org/person/dajobe/diary.html?start=6</link>
      <guid>http://www.advogato.org/person/dajobe/diary.html?start=6</guid>
      <description>&lt;p&gt;&lt;b&gt;Raptor&lt;/b&gt;

&lt;p&gt;At last, got another release of &lt;a href="http://www.advogato.org/proj/raptor/" &gt;raptor&lt;/a&gt; out the door
after about 5 months and lots of changes (new RDF datatyping,
collections, URI updates, internal improvements, bug fixes).  It took
a while till it had the features I wanted to add, the changes I
wanted to make internally and after all that, to make it stable and
working.

&lt;p&gt;Releasing software is such a pain, especially in the free
software / open source world.  Since in particular, it is your
reputation that is being demonstrated - "&lt;em&gt;show me the code!&lt;/em&gt;"
- and the source code you make available to the world is what counts.


&lt;p&gt;Of course, talking about reputation on advogato is just asking for
trouble. :)



</description>
    </item>
    <item>
      <pubDate>Tue, 22 Oct 2002 22:23:56 GMT</pubDate>
      <title>22 Oct 2002</title>
      <link>http://www.advogato.org/person/dajobe/diary.html?start=5</link>
      <guid>http://www.advogato.org/person/dajobe/diary.html?start=5</guid>
      <description>&lt;p&gt;&lt;b&gt;Raptor&lt;/b&gt;

&lt;p&gt;A short update on various code refactorings of my
&lt;a href="http://www.advogato.org/proj/raptor/" &gt;raptor&lt;/a&gt; RDF parser over the last month or so.  I have
been pulling apart an 140K C source file into chunks by
functionality.  This was needed for a bunch of reasons, mostly
because it had been evolved rather than designed, and was getting
embarassing to look at.

&lt;p&gt;The result is that the API is smaller and more flexible and I can
soon pull out the &lt;a href="http://www.advogato.org/proj/redland/" &gt;redland&lt;/a&gt; URI dependencies, so that the
same raptor library can be used standalone in applications while
working efficiently in redland.

&lt;p&gt;Apart from moving the same code around I also got time to improve
the XML error handling so that it can deal with XML it doesn't
understand, so it now handles all the libxml XML tests without
falling over.  And killing a bunch of other bugs.  The bug list
is actually getting shorter.
</description>
    </item>
    <item>
      <pubDate>Thu, 29 Aug 2002 12:10:33 GMT</pubDate>
      <title>29 Aug 2002</title>
      <link>http://www.advogato.org/person/dajobe/diary.html?start=4</link>
      <guid>http://www.advogato.org/person/dajobe/diary.html?start=4</guid>
      <description>&lt;p&gt;&lt;b&gt;Redland&lt;/b&gt;

&lt;p&gt;A few weeks since last hacking update on my &lt;a href="http://www.advogato.org/proj/redland/" &gt;redland&lt;/a&gt;
RDF library. I long wanted the (C) library to be able to return error
messages and so on to the higher language interfaces (perl, python,
java, tcl, ruby, ...).  In this case, I've got my head around the C
interfaces to callbacks for perl and python so that now any errors
result in native perl and python subroutines / functions / exceptions
working.  This means that the CGI demo programs that used to just
chuck errors to stderr can return them to the web interface.

&lt;p&gt;&lt;b&gt;Raptor&lt;/b&gt;

&lt;p&gt;Most recently I've mostly been banging on my &lt;a href="http://www.advogato.org/proj/raptor/" &gt;raptor&lt;/a&gt;
RDF parser and writing test cases to find the bugs that have been
known about but not diagnosed.  I also took the opportunity to try to
split out some code from the very large main source file.  Tricky
doing this from evolved code.

</description>
    </item>
  </channel>
</rss>
