Moving to blogspot.com Mon Sep 22 09:55:08 CEST 2008
Please change your subscription URL to
Removing CHS based access from windows boot loaders Sat Dec 22 12:22:48 CET 2007
Recently, I had troubles to migrate my Windows installation from
VMWare to VirtualBox. When booting
the vmware created partition in virtualbox, I got "NTLDR not found".
So I sharpened the knives and got down to business with vmware's gdb
interface and virtualbox's internal debugger. Tracing the execution
showed that the BIOSes of the two products reported different
geometries on the INT 13h interface. The generic method contained in
the boot loader to read a sector from disk is "clever" as it checks
whether the sector is below the maximum sector index that is reachable
with the CHS geometry reported by the BIOS. If not, it uses the LBA
interface of the BIOS. If yes, the cleverness of the boot loader
suddenly vanishes. Instead of using the BIOS reported geometry to
break the absolute sector down into its CHS components, the boot
loader uses a geometry stored in the so called BIOS parameter
block. That's a section of the first sector embedded into the boot
loader that hard codes such values as head per cylinder and sectors
per heads into the boot loader. If the hard coded values are different
from the ones used by the BIOS, the calculation produces wrong values.
So, if you move your partition to a BIOS that exposes a different
geometry to the boot loader than is hard coded in the boot loader the
whole thing blows up. Brilliant Microsoft design, as ever.
X11-xft, also for XMonad Thu Nov 15 22:38:54 CEST 2007
Haskell bindings for Xft are on their way. They don't cover 100% of
the API yet, because some of the API relies on the only briefly covered
Xrender and FreeType APIs. But the whole thing is sufficiently usable
to get nice FreeType rendered fonts in xmonad! Here is the pr0n.
darcs get http://clemens.endorphin.org/X11-xft/Enjoy. Depressing Sun Sep 30 22:28:12 CEST 2007
After the most expensive car check and maintenance in my car owner
history few weeks ago, my car died. Right in the middle of nowhere. And even worse,
on my way to ICFP07.
Liskell Task List Fri Sep 28 18:05:59 CEST 2007Liskell apparently has its first developer (next to me). I was surprised to see a post on liskell-devel by Jason Miller that implements a macro to give Liskell better syntactic support for monads. In pure Liskell, programming with monads looks like
(>>= (getEnv "HOME")
(lambda (homepath)
(>>= (readFile (++ homepath "/.foobarrc"))
(lambda (content)
(process content)))))
As you can see the indention level piles up when you have a cuple of
expressions. Jason proposed an alternative syntax,
(do (<- homepath (getEnv "HOME")) (<- content (readFile (++ homepath "/.foobarrc"))) (process content))He also posted the resulting macro code. I'm surprised and glad that someone obviously can make sense of Liskell, even -- shame on me -- with the little documentation I have made available. At the moment, I'm pondering about the future of Liskell. The simple question how to support 'eval' lead to a series of other questions. I shouldn't be surprised that an eval/apply mechanism magically complicates things just as any potentially self referential construct does. But before I start to chat about trouble with supporting eval, the benefits from eval are just too obvious from the Lisp world, that Task #1 is to support eval at compile-time and run-time. When using eval, you want the expression to evaluate in the current module's compiler state, otherwise you would only be able to use bare naked Liskell primitives expression without any syntax backed by parse tree transformers. My current train of thinking goes into the direction of modelling a compiler/universe state that pervades the boundary between compile- and run-time. I might solve this by borrowing from Lisp again. In the Lisp world, there are rarely object files nor linked libraries (packages) as we have them in Haskell. The usual way of conducting business is that you fire up a Lisp process and start to load Lisp source files until you have all the code in the Lisp process you need. Usually loading also compiles the code. When done, you dump the hole process state to disk and reload it whenever you need to restart the application. So, most Lisp dialects statically link the code in the process image and -- more important -- there is no distinction between compilation- and run-time. The state of the Lisp process next to all the loaded code is also dumped and reloaded, hence saved. This method can not be ported to Haskell easily. There is only a limited state concept in a Haskell compiler. The source code visible state -- I don't mean compilation/optimization/code generation options here -- is only the scope or environment. Importing modules and defining new top-level function/variables modifies the environment. But we can only extend the environment with more knowledge and also this knowledge that must not contradict existing knowledge (redefine functions or give multi-line equations with different types). As I was coding my little toy Scheme compiler, I recognized that I wanted to modify the compiler state when certain modules were imported. I had in mind that SchemeCore would bring in the basic Scheme syntax constructs such as (define-scheme ...). define-scheme defines functions and variables with Scheme semantics separated in its own Scheme sub-universe that Liskell code can enter via runScheme. runScheme runs the SchemeMonad that supports a global mutable environment, IO and also continuations -- so callCC should be implementable here. Next to SchemeCore, I wanted to create modules of Scheme code. When importing these modules, they should modify the Scheme compiler state (not the Liskell/Haskell compiler state) so that the Scheme functions compiled become part of the global mutable environment. To make this vision reality, here is Task #2: Liskell should feature an extensible mutable compiler state (LiskellMonad?) The LiskellMonad -- 'the universe monad' that might replace and embed IO -- should support another feature I love about Lisp: hot code swapping or code replacement as the Erlang camp calls it. The LiskellMonad should support to replace top level definitions with new code. To keep things tidy, the basic idea is to revert all evaluated WHNF to thunks that in some way depend on expression changed. This approach guarantees a consistent universe. Without reverting to thunks, you might have two top-level expressions (define x (f 3)) and (define y (f 3)) that end up with different WHNF, for instance whenever x was evaluated before your change to the function f. Of course, we can't allow that to happen in a pure universe. Task #3: allow mutable top-level definitions. What we can't get right (at least not without a bit more work) is crossing IO monad boundaries with that concept. Whenever you write the result of (f 3) to a file and change the function f later on, Liskell does not rerun the code that wrote the file content (and also the user would be pretty surprised if it would do so). So by definition, IO is a bit out of reach at the moment, but for a subclass of IO operations we might be able to do it. These operations must not have any visible side effects to the 'outside world', such as putStr. If we exclude those operations, the only operations remain that affect the 'inside world'. These IO operations could be rerun quite easily, just think of Prelude.readFile, executing this twice won't cause unintented behaviour. I'm not sure at the moment whether this idea makes sense beyond Prelude.readFile, but it would have an appealing similarity to STM's way of rerunning code. And last but not least, the packaging issue is not solved for Liskell. Simon Peyton-Jones suggested to make Liskell a user of GHC API. GHC API needs to be modified to make a good host for Liskell, and as we all know, forming good APIs takes time and a fair bit of discussion. As Liskell is too experimental to flesh out a stable set of API requirements, I think that it is the best option to distribute Liskell as a modification to GHC. These modifications are confined to the 'ghc' package. Creating a fork of this package is the best option for the moment. Liskell can shared base/rts and all the other core and auxiliary packages with a GHC installation. I hope I can work through this task in the next few months. If you have any reading suggestion with respect to existing design, I would be happy for a few pointers. Ah and yes, for the next few days, I will be in Freiburg attending ICFP07. Stabilizing Firefox for beta quality plugins (Flash) Tue Sep 25 20:54:32 CEST 2007
Using the recent Adobe Flash plugin in Firefox is a two edged
sword. On one hand, it gives you the never ending joy of useless YouTube
videos, but on the other hand it crashes your browser every 24h on
average (only if you are also using Flashblocker
which reduces flash content activation by 80%, namely all the annoying ads).
QT RLE hits ffmpeg SVN Tue Sep 11 15:31:53 CEST 2007
My last drive-by-software-hacking turned out to be useful at the
end. I hacked up a basic QT RLE (aka Animation) encoder for ffmpeg,
sent the patch to ffmpeg-devel but without further intentions to work
on merging. Thanks go to Alexis Ballier for stepping up and refining
my patch until it was polished enough.
Lisplab.at dies Fri May 18 10:53:19 CEST 2007
lisplab.at dies in 3 days. I can't
justify spending 25 EURs on extending the domain subscription, as nobody of my co-developers showed any partical interested in fueling this social attractor.
Liskell at the International Lisp Conference 2007, Cambridge, UK Thu May 17 20:05:30 CEST 2007
It's been over a month since I returned from Cambridge and still I
have not found time to blog an epilogue for this trip.
And finally a few photos in my semi-private flickr stream. liskell.org Mon May 14 13:47:47 CEST 2007Liskell — my favorite Lisp+Haskell pet — has a new website, namely http://liskell.org. There you will find a new branch of Liskell based on GHC-6.6 and a new Liskell development mailing list liskell-devel@liskell.org. |
