<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Intrepid Blog &#187; hack</title>
	<atom:link href="http://blog.affien.com/archives/tag/hack/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.affien.com</link>
	<description>A few thoughts</description>
	<lastBuildDate>Mon, 01 Mar 2010 00:58:01 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Unicode to ASCII (1)</title>
		<link>http://blog.affien.com/archives/2009/06/19/unicode-to-ascii-1/</link>
		<comments>http://blog.affien.com/archives/2009/06/19/unicode-to-ascii-1/#comments</comments>
		<pubDate>Fri, 19 Jun 2009 13:19:10 +0000</pubDate>
		<dc:creator>Bas Westerbaan</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[hack]]></category>
		<category><![CDATA[python]]></category>
		<category><![CDATA[unicode]]></category>

		<guid isPermaLink="false">http://blog.affien.com/?p=387</guid>
		<description><![CDATA[When I want to generate usernames from real names, which can contain non-ascii characters, you can&#8217;t simply ignore the unicode characters.  For instance, danielle@blaat.org is the right e-mail address for Daniëlle, danille@blaat.org isn&#8217;t.
There&#8217;s  trick.  Unicode has got a single code for ë itself, but it has also got a code which (simplified) [...]]]></description>
			<content:encoded><![CDATA[<p>When I want to generate usernames from real names, which can contain non-ascii characters, you can&#8217;t simply ignore the unicode characters.  For instance, danielle@blaat.org is the right e-mail address for Daniëlle, danille@blaat.org isn&#8217;t.</p>
<p>There&#8217;s  trick.  Unicode has got a single code for ë itself, but it has also got a code which (simplified) adds ¨ on top of the previous character.  The unicode standard defines a normal form in which (at least) all such characters, which can be, are represented using such modifiers.  If you then simply ignore the non-ascii representable codes, you&#8217;ll get the desired result.</p>
<p>In python: <code>unicodedata.normalize('NFKD', txt).encode('ASCII', 'ignore')</code>.</p>
<p>However, this isn&#8217;t <em>the</em> right solution. For instance, in german, one prefers ue as a replacement of ü over u.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.affien.com/archives/2009/06/19/unicode-to-ascii-1/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>GStreamer: accurate duration</title>
		<link>http://blog.affien.com/archives/2009/04/19/gstreamer-accurate-duration/</link>
		<comments>http://blog.affien.com/archives/2009/04/19/gstreamer-accurate-duration/#comments</comments>
		<pubDate>Sun, 19 Apr 2009 13:26:01 +0000</pubDate>
		<dc:creator>Bas Westerbaan</dc:creator>
				<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[duration]]></category>
		<category><![CDATA[gstreamer]]></category>
		<category><![CDATA[hack]]></category>
		<category><![CDATA[python]]></category>

		<guid isPermaLink="false">http://blog.affien.com/?p=371</guid>
		<description><![CDATA[When decoding, for instance, a variable-bitrate MP3, gstreamer reported durations are, to say the least, estimates.  I&#8217;ve tried to get a better result in a few ways.  First off, some files yield a duration tag, but even if you&#8217;re lucky and it is there, there are no guaranties about precision.  After that [...]]]></description>
			<content:encoded><![CDATA[<p>When decoding, for instance, a variable-bitrate MP3, gstreamer reported durations are, to say the least, estimates.  I&#8217;ve tried to get a better result in a few ways.  First off, some files yield a <code>duration</code> tag, but even if you&#8217;re lucky and it is there, there are no guaranties about precision.  After that I tried seeking to the end (<code>GST_SEEK_END</code>) of the stream and querying the position, which gstreamer didn&#8217;t like.  Finally, routing the audio into a <code>fakesink</code>, waiting for the end of stream and then querying for the position gives the right result.  It&#8217;s not the prettiest method, but it works.</p>
<p><a href='http://blog.affien.com/wp-content/uploads/2009/04/gst-duration.py'>This</a> is a Python script that prints the duration of a media to stdout.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.affien.com/archives/2009/04/19/gstreamer-accurate-duration/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Spacing up- and downarrow properly for up- and downsets</title>
		<link>http://blog.affien.com/archives/2009/03/24/spacing-up-and-downarrow-properly-for-up-and-downsets/</link>
		<comments>http://blog.affien.com/archives/2009/03/24/spacing-up-and-downarrow-properly-for-up-and-downsets/#comments</comments>
		<pubDate>Tue, 24 Mar 2009 22:34:44 +0000</pubDate>
		<dc:creator>Bas Westerbaan</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[hack]]></category>
		<category><![CDATA[LaTeX]]></category>

		<guid isPermaLink="false">http://blog.affien.com/?p=365</guid>
		<description><![CDATA[ is ugly, but  is nice!  The solution: prefix \uparrow with \mathopen.
]]></description>
			<content:encoded><![CDATA[<p><img src='/wp-latexrender/pictures/dfd7ffe5be268423b112ca959b81b779.png' title='f(\uparrow x)' alt='f(\uparrow x)' align=absmiddle> is ugly, but <img src='/wp-latexrender/pictures/2050c367e48b116441583fd62a004658.png' title='f(\left\uparrow x\right.)' alt='f(\left\uparrow x\right.)' align=absmiddle> is nice!  The solution: prefix <code>\uparrow</code> with <code>\mathopen</code>.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.affien.com/archives/2009/03/24/spacing-up-and-downarrow-properly-for-up-and-downsets/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>&#8220;waiting for x server to begin accepting connections&#8221;</title>
		<link>http://blog.affien.com/archives/2008/06/29/waiting-for-x-server-to-begin-accepting-connections/</link>
		<comments>http://blog.affien.com/archives/2008/06/29/waiting-for-x-server-to-begin-accepting-connections/#comments</comments>
		<pubDate>Sun, 29 Jun 2008 17:19:58 +0000</pubDate>
		<dc:creator>Bas Westerbaan</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[gentoo]]></category>
		<category><![CDATA[gnome]]></category>
		<category><![CDATA[hack]]></category>
		<category><![CDATA[X]]></category>

		<guid isPermaLink="false">http://blog.w-nz.com/?p=317</guid>
		<description><![CDATA[Try DisallowTCP = false under [Security] in /etc/X11/Sessions/Gnome/custom.conf or similar for other window managers.  Obviously this isn&#8217;t a very desirable solution, emerge --emptytree gnome might do the trick too. 
(and obviously this might be just one of the many underlying causes for the very generic symptom of X not accepting connections)
]]></description>
			<content:encoded><![CDATA[<p>Try <code>DisallowTCP = false</code> under <code>[Security]</code> in <code>/etc/X11/Sessions/Gnome/custom.conf</code> or similar for other window managers.  Obviously this isn&#8217;t a very desirable solution, <code>emerge --emptytree gnome</code> might do the trick too. </p>
<p>(and obviously this might be just one of the many underlying causes for the very generic symptom of X not accepting connections)</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.affien.com/archives/2008/06/29/waiting-for-x-server-to-begin-accepting-connections/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Java crashing on xcb_xlib_unlock.</title>
		<link>http://blog.affien.com/archives/2007/12/17/java-crashing-on-xcb_xlib_unlock/</link>
		<comments>http://blog.affien.com/archives/2007/12/17/java-crashing-on-xcb_xlib_unlock/#comments</comments>
		<pubDate>Mon, 17 Dec 2007 22:34:31 +0000</pubDate>
		<dc:creator>Bas Westerbaan</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[crash]]></category>
		<category><![CDATA[hack]]></category>
		<category><![CDATA[java]]></category>
		<category><![CDATA[linux]]></category>
		<category><![CDATA[X]]></category>
		<category><![CDATA[xcb]]></category>

		<guid isPermaLink="false">http://blog.w-nz.com/archives/2007/12/17/java-crashing-on-xcb_xlib_unlock/</guid>
		<description><![CDATA[When Java applications crash on linux with xcb_xlib_unlock: Assertion `c->xlib.lock' failed you should upgrade to libxcb-1.1 and add LIBXCB_ALLOW_SLOPPY_LOCK=1 to the environment.
]]></description>
			<content:encoded><![CDATA[<p>When Java applications crash on linux with <code>xcb_xlib_unlock: Assertion `c->xlib.lock' failed</code> you should upgrade to <code>libxcb-1.1</code> and add <code>LIBXCB_ALLOW_SLOPPY_LOCK=1</code> to the environment.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.affien.com/archives/2007/12/17/java-crashing-on-xcb_xlib_unlock/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
