For a university seminar I m currently writing a GUI program to view
fractals based on simple
iterated function systems (only similaritudes allowed). It supports three different drawing algorithms and you can edit the IFS by dragging squares around on the screen. But this post is not about this program (I might present it later), but how
Haskell allowed me to solve a problem very nicely:The first instances of the code had a problem that a lot of GUI programmers know: The drawing of the fractal took quite some time, and during that time the gtk main loop is blocked and the program becomes unresponsive. At first I avoided this problem by manually splitting the drawing function (e.g. by repeatedly increasing the resolution) and kept re-drawing it at higher resolutions in an idle handler, so at least I could interact whenever one resolution has finished drawing. It worked somewhat but it was not easily done for the other, not pixel based, algorithms and it was ugly.So I wanted a way to (a) pause the drawing at any convenient point, to resume it later, and (b) safely abort the drawing if what I m drawing has changed and I need to restart.A common solution to this would be to do the drawing in a separate thread, so (a) is actually not needed, but I did not know if I can safely do (b), and I have heard that threads cause problems with gtk.So I tried to dig deeper for the hidden treasures of advanced haskell programming: I need a monad transformer! I expected the infamous
ContT monad transformer to help, but I couldn t figure out how, and I started to create my own monad transformer, called
CoroutineT.I tried to figure out what an action of type
(CoroutineT IO a) should do, and I came up with this type signature:
pausingAction :: IO (Either (CoroutineT IO a) a)
which means that after the pausingAction is done, it is
Either paused (and I get back another pausingAction to run when I want it), or it is done (and I get the result). Note that I m writing
IO here, but it can be any monad.The definition of the datatype and the monad instance came mostly from trying to make this type work (yay to haskell s type system, less thinking required), and looks like this:
data CoroutineT m a = CoroutineT unCoroutineT :: (m (Either (CoroutineT m a) a))
instance (Monad m) => Monad (CoroutineT m) where
return v = CoroutineT (return (Right v))
a >>= b = CoroutineT $ do
r <- unCoroutineT a
case r of
Left paused -> return $ Left (paused >>= b)
Right unpaused -> unCoroutineT (b unpaused)
This translates to english like this: A call to return is not paused. When an action is already paused, further actions should be run after the paused action is resumed. When an action is not paused, further actions can happen now.Like every well behaving monad transfomer, I also need a "
runCoroutineT" function to start the coroutine. I probably could have used
unCoroutineT directly, but for my use case (GUI drawing) I did not need a return value, so this function is more handy:
runCoroutineT :: Monad m => CoroutineT m () -> m (Maybe (CoroutineT m ()))
runCoroutineT a = either (Just) (const Nothing) liftM unCoroutineT a
Nothing surprising here, basically just turning the
Either into a
Maybe. So it becomes clear how to do (b): We can just throw away the resume action returned by
runCoroutineT (if any). The more interesting thing is how we do (a): We need a pause action of type
(Coroutine m ()). But how should it work? I did not really try to understand why it works, but by looking at the types, I came up with this:
pause :: Monad m => CoroutineT m ()
pause = CoroutineT (return (Left (CoroutineT (return (Right ())))))
Yes, it sounds like some dance step instructions (read the second line out aloud!), but it works somehow.So here is some example code: I have a pausable
IO action that counts from one to ten, pausing after each number. I also have function that resumes an pausable action up to n times:
example n = keepGoingFor n $ do
liftIO $ putStrLn "This is the coroutine"
forM_ [1..10] $ \i -> do
liftIO $ putStrLn $ "Counting to "++ show i ++" while you keep calling it"
pause
where --keepGoing :: Monad m => CoroutineT m () -> m ()
keepGoingFor 0 _ = putStrLn "Here I just abort the run"
keepGoingFor n cor = do
resume <- runCoroutineT cor
case resume of
Just runAgain -> keepGoingFor (n-1) runAgain
Nothing -> putStrLn "Finally stopped"And here is the output of two different runs:
*CouroutineT> example 5
This is the coroutine
Counting to 1 while you keep calling it
Counting to 2 while you keep calling it
Counting to 3 while you keep calling it
Counting to 4 while you keep calling it
Counting to 5 while you keep calling it
Here I just abort the run
*CouroutineT> example 14
This is the coroutine
Counting to 1 while you keep calling it
Counting to 2 while you keep calling it
Counting to 3 while you keep calling it
Counting to 4 while you keep calling it
Counting to 5 while you keep calling it
Counting to 6 while you keep calling it
Counting to 7 while you keep calling it
Counting to 8 while you keep calling it
Counting to 9 while you keep calling it
Counting to 10 while you keep calling it
Finally stopped
So it does really works fine, and it proved very useful in my GUI drawing problem. For that, I created this nice control structure which works like
mapM_, but calls pause every n iterations, and therefore hides the pausing stuff almost completely:
pausingForM_ :: Monad m => Int -> [a] -> (a -> CoroutineT m ()) -> CoroutineT m ()
pausingForM_ period list action = pausing' 0 list
where pausing' _ [] = return ()
pausing' n (x:xs) = do action x
if n==period then pause >> pausing' 0 xs
else pausing' (n+1) xs
I have put the
complete module (including instances omitted here) in the
darcs repository that might later also contain the fractal drawing program.
I've learnt a lot about building MSI files during the last days. In a way, it is very similar to building Debian packages -- you hand some magic tool a directory with files and a directory with meta-information.
The main difference is that MSI files cannot call arbitrary commands in their installation sequence, which serves an useful purpose: as long as they make do with the standard actions provided with the base installer, it is guaranteed that you can undo all changes, and you can get a full overview what the installation will do, without running any untrusted code.
If the standard actions aren't enough (for example, they don't cover driver installation), you can ship a DLL that can be loaded into the installer. You lose a bit of the audit functionality there, but that is not a problem in practice as these plug-ins are signed separately from the package, so for every genuine problem, there is already a plug-in that you can simply "merge" to your package.
Geeks not only designed the Internet, an indisputably revolutionary medium, but also implemented, and continue to maintain it, and then in their copious spare time, also engage in fighting back the political, legal and corporate encroachment which threatens to limit the very revolutionary nature of the Internet (as 
In other words, he seems to think they are allergic to regulation due to their accentuated libertarianism, or are against structure because of their anarchism, neither which is remotely true. I think I found this characterization most ironic and problematic for before Wikipedia was even an entry on a Wiki, projects like Debian (and most other F/OSS projects) were 
I've got most of the build system / packaging stuff done for estron now. There's a basic Yelp manual pending completion of the Estron GNOME application, there are some refreshed screenshots, updated the website CSS and added an icon, updated Glade files using Gtk stock items for the buttons.
Since I didn't find a similar tool for Linux, I've hacked together a tiny tool
to do BPM counting. The usual stuff: tap any key with the music to get a BPM
estimation. There is no music analysis done.
To achieve better results, my tool uses an exponentially weighted average. It
also computes a confidence interval. So if the song changes tempo (and quite
some jazz songs do) or doesn't keep the tempo constantly (live music with human
drummers often shows some tempo drift. It's just the drum computers that keep
their speed very well...) - the tool can handle that quite well, while also
not being overly sensitive to tapping errors (as you can see in the image).I figure there might be even better estimation tricks (e.g. doing some error
detection and removing them), but this one was just very simple to implement.
And by looking at the graph and the error interval it's quite easy to check
that you didn't any recent mistakes and the result is okay.The Python code is about 158 lines SLOC, and a small UI description generated
with Glade. It's built with PyGTK and uses Cairo for the plots, so it should be
very platform independant and even run on Windows.Download will be available sometime when I get around to clean it up a little.
There is for example still the code in there to compute plain averages, which
can't handle songs with multiple tempos at all.[Update: it now also has a tiny 'flasher' icon that will show you the current
tempo estimation. This is great for checking the quality of the result - if it
keeps on flashing in sync with the music after you've stopped tapping, it's
good. I was also pointed to 
By that definition we can certainly see projects like Wine, Mysql, Ghostscript (at one time), and others as fitting into that model, and being quite successful. There’s nothing really wrong with the non-organic software model, although many of them have struggled to make enough money when competing with pure proprietary softare competitors, with MySQL perhaps being the exception which proves the rule.
In most of these cases, though, the project started more as an organic open source, and then transitioned into the non-organic model when there was a desire to monetize the project and/or when the open source programmers decided that it would be nice if they could turn their avocation into a vocation, and let their hobby put food on the family table.
Solaris, of course, is doing something else quite different, though. They are trying to make the transition from a proprietary customer/supplier relationship to trying to develop an Open Source community and what John s candidate statement pointed out is that they weren t really interested in creating an organic open source developer community at all, but they wanted the fruits of an open source community with plenty of application developers, end-users, etc., all participating in that community.
We don t have a lot of precedent for projects who try to go in this direction, but I suspect they are skipping a step when they try to go to the end step without bothering to try to make themselves open to outside developers. And by continuing to act like a corporation, they end up shooting themselves in the foot. For example, the OpenSolaris license still prohibits people from publishing benchmarks or comparisons with other operating systems. Very common in closed-source operating systems and databases, but it discourages people from even trying to make things better, both within and outside of the Open Solaris core team. Instead, they respond to posts like 
I've implemented last night's design, in