<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>Advogato blog for yole</title>
    <link>http://www.advogato.org/person/yole/</link>
    <description>Advogato blog for yole</description>
    <language>en-us</language>
    <generator>mod_virgule</generator>
    <pubDate>Wed, 22 May 2013 20:35:14 GMT</pubDate>
    <item>
      <pubDate>Wed, 28 Mar 2001 13:46:42 GMT</pubDate>
      <title>28 Mar 2001</title>
      <link>http://www.advogato.org/person/yole/diary.html?start=1</link>
      <guid>http://www.advogato.org/person/yole/diary.html?start=1</guid>
      <description>&lt;b&gt;We have a very nice exception handling system... except 
for it doesn't work&lt;/b&gt;&lt;p&gt;
Today, finally, after a couple of days of totally 
unproductive coding and a sudden inspiration, I've fixed 
the exception emulation system in the C++ libraries of our 
project at work.&lt;p&gt;
We have a set of class libraries that is supposed to be 
portable between Win32 and various hand-held devices (Palm, 
EPOC, WinCE), but the small devices do not provide C++ 
exception handling, and the libraries rely on it heavily. 
So last summer we implemented a complex exception emulation 
framework with more or less complete support for stack 
unwinding. It worked very fine, pushing objects on the 
stack and pulling them from there, except for one minor 
thing: every time you threw an exception, it crashed.&lt;p&gt;
Nobody did any active development for the devices, so 
nobody pushed too hard to get this thing fixed, but now the 
time came that my colleagues needed the code working. The 
project that I promised to do in two or three days 
(updating the code for the latest version of the Symbian 
platform and fixing the exceptions) stretched into more 
than two weeks of Web surfing, complaining about the 
bloated emulator that loads for 3 minutes and hangs your PC 
to death once in a while and other not really productive 
tasks. Well, I did write some code, but not too much of 
it...&lt;p&gt;
And today at last, after my colleague advised me to look if 
the problem could be reproduced in a minimal test under 
Win32, I found the reason of the problem in just some half 
an hour... (When working on something that is totally 
uninteresting and unmotivating, I sometimes feel like I'm 
doing everything possible to avoid getting the problem 
solved. Not a really professional attitude, I guess.)&lt;p&gt;
When I saw the reason, I first thought that it was 
theoretically impossible to get the problem fixed. But once 
I explained the problem in details to my friend over ICQ, I 
immediately came up with the solution... So much for having 
someone to listen to you, even if he doesn't say a word.</description>
    </item>
    <item>
      <pubDate>Tue, 27 Mar 2001 11:55:24 GMT</pubDate>
      <title>27 Mar 2001</title>
      <link>http://www.advogato.org/person/yole/diary.html?start=0</link>
      <guid>http://www.advogato.org/person/yole/diary.html?start=0</guid>
      <description>&lt;b&gt;Infinity Explorer takes revenge on its creator&lt;/b&gt;&lt;p&gt;
I've just fixed a very... hmmm... funny bug in &lt;a href="http://infexp.sourceforge.net" &gt;Infinity 
Explorer&lt;/a&gt;. When I was working on it the last time, I 
noticed that the ChangeLog file was somehow lost. That 
time, I just thought that I accidentally deleted it. Today 
the same situation repeated, but this time I couldn't 
explain it by saying that I've accidentally pressed some 
wrong keys. And when the TODO file miraculously got lost, I 
started debugging...&lt;p&gt;
It turned out that the code that was supposed to clean up 
unpacked savegames was called also for savegames that were 
never unpacked. Since the unpacked path was an empty string 
for such savegames, it deleted all the files in the 
current directory. But it just silently ignored failures to 
delete files that were locked, so I didn't notice the 
problems earlier.&lt;p&gt;
And because I didn't commit to SourceForge for quite a 
while, the only version of TODO that I still have is a 
quite dated one, and I'm not sure I can fully restore the 
TODO file from memory. Fortunately, the source code of 
InfExp was stored in a subdirectory of the directory 
containing the executable, and the savegame cleanup code 
was not smart enough to recurse subdirectories...</description>
    </item>
  </channel>
</rss>
