Today I learnt…

…how neural networks (think brains) can do differentiation by using temporal inhibition – i.e. by using a delayed signal. In the figure below, the node α will send a signal to two nodes. One of them – β – will pass on an inhibitory signal of the same strength as its input signal, but with a delay. Thus, when β‘s signal gets sent to the final node, α will at the same time be sending its “next” output signal to the final node.

“Differentiation” by using delayed inhibition. Solid lines indicate excitatory signals and the dotted line an inhibitory signal.

Therefore, the final node will receive two signals: the current output of α and the inverted previous output of α. If the final node sums these together its output will therefore be α‘s current value minus its old value – i.e. positive if α‘s output signal is increasing and negative if it is decreasing. Simple and beautiful!

To correct this embarrassing fact I quickly wrote a version in Haskell using the GLUT bindings.

Conway's Game of Life

It is very simple, but it works.

import Graphics.UI.GLUT hiding (get)
import Graphics.Rendering.GLU.Raw (gluOrtho2D)
import Data.IORef
import System.Random
 
-- dimensions of our cellular space
width  = 80 :: Int
height = 60 :: Int
 
-- takes a two-dimensional list and returns the neighbours of (x,y)
neighbours :: [[a]] -> (Int,Int) -> [a]
neighbours m (x,y) = map (\(x',y') -> m !! y' !! x') $ filter valid neighbours'
    where height'       = length m
          width'        = length (head m)
          valid (x',y') = x' >= 0 && x' < width' && y' >= 0 && y' < height'
          neighbours'   = [(x-1,y-1),(x,y-1),(x+1,y-1), -- neighbours over
                           (x-1,y),(x+1,y),             -- neighbours left/right
                           (x-1,y+1),(x,y+1),(x+1,y+1)] -- neighbours under
 
-- updates all cells according to the rules in liveOrDead
update :: IORef [[Bool]] -> IO ()
update c = do
    cells <- readIORef c
 
    let coords = [(x,y) | y <- [0..(height-1)], x <- [0..(width-1)]]
 
    nextGen <- mapM (\(x,y) -> do
            let cell = cells !! y !! x
            let ns   = neighbours cells (x,y)
            return $ liveOrDead cell ((length . filter id) ns)
        ) coords
 
    writeIORef c (nLists width nextGen)
    display c
 
-- survival rule: a live cell only lives on if it has 2 or 3 live neighbours
-- birth rule: a dead cell becomes a live cell if it has 3 live neighbours
liveOrDead :: Bool -> Int -> Bool
liveOrDead True nLive = nLive `elem` [2,3]
liveOrDead False nLive = nLive == 3
 
-- utility function: split a list into sublists of length n
nLists :: Int -> [a] -> [[a]]
nLists _ [] = []
nLists n ls = take n ls : nLists n (drop n ls)
 
-- utility function: draws a square at (x,y) with size w×h
drawQuad :: GLdouble -> GLdouble -> GLdouble -> GLdouble -> IO ()
drawQuad x y w h =
    renderPrimitive Quads $ do
        vertex (Vertex3  x     y    0)
        vertex (Vertex3 (x+w)  y    0)
        vertex (Vertex3 (x+w) (y-h) 0)
        vertex (Vertex3  x    (y-h) 0)
 
-- draw each cell as a coloured square
display :: IORef [[Bool]] -> IO ()
display c = do
    cells <- readIORef c
 
    let h = fromIntegral height
    let w = fromIntegral width
 
    mapM_ (\(n,b) -> do
        if b
          then currentColor $= Color4 1.0 0.8 0.6 1.0
          else currentColor $= Color4 0.4 0.5 0.4 1.0
        let x = 1/w*fromIntegral (n `mod` width)
        let y = 1-(1/h*fromIntegral (n `div` width))
        drawQuad x y (1/w) (1/h)
        ) (zip [0..] $ concat cells)
 
    swapBuffers
 
main :: IO ()
main = do
    g <- newStdGen
    _ <- getArgsAndInitialize
 
    -- random starting values
    cells <- newIORef ((nLists width . take (width*height) . randoms) g)
 
    _ <- createWindow "Conway's Game of Life"
    initialDisplayMode    $= [DoubleBuffered]
    windowSize            $= Size 800 600
    displayCallback       $= display cells
    idleCallback          $= Just (update cells)
    gluOrtho2D 0 1 0 1    -- orthogonal projection
    mainLoop              -- start main loop

One of the things I found really interesting was how Douglas Crockford recommended code reading as a way to avoid having confused programmers in a project that aren’t aware of their own situation before it’s too late. According to Crockford it also helps by making sure that the really good programmers mentor other people on their team. The procedure is very simple:

Seibel: Can you talk a bit about how you conduct a code reading?

Crockford: At each meeting, someone’s responsible for reading their code, and they’ll walk us through everything, and the rest of us will observe. It’s a really good chance for the rest of the team to understand how their stuff is going to have to fit with that stuff.

We get everybody around the table; everybody gets a stack of paper. We also blow it up on the screen. And we all read through it together. And we’re all commenting on the code as we go along. People say, “I don’t understand this comment”, or, “This comment doesn’t seem to describe the code.” That kind of stuff can be so valuable because as a programmer you stop reading your own comments and you’re not aware that you’re misdirecting the reader. Having the people you work with helping to keep you code clean is a huge service—you find defects that you never would have found on your own.

I think an hour of code reading is worth two weeks of QA. It’s just a really effective way of removing errors. If you have someone who is strong reading, then the novices around them are going to learn a lot that they wouldn’t be learning otherwise, and if you have a novice reading, he’s going to get a lot of really good advice.

[...]

For one thing it makes it easier to track the project, because we can actually see what progress people are making. And we can see much sooner if they’re going off the rails or not.

I simply loved this idea and would love to test it in practice. I know that I personally would find it highly motivating, both with respect to the quality of my own code and for the project as a whole by so explicitly seeing what the others are doing.

This is probably not going to work for all projects and teams, but for a relatively small team (working at the same location) aiming to produce code of a high quality I really believe this approach can work.

If anyone has experience with this, or similar approaches, I would love to hear your thoughts.

// BEGIN USER CONFIGURATION
var cfgIndentCase = true; // indent ‘case’ and ‘default’ in a switch?
var cfgIndentNamespace = true; // indent after ‘namespace’?
var cfgAutoInsertStar = false; // auto insert ‘*’ in C-comments
var cfgSnapSlash = false; // snap ‘/’ to ‘*/’ in C-comments
var cfgAutoInsertSlashes = false; // auto insert ‘//’ after C++-comments
// END USER CONFIGURATION

To set these options one would first have to actually find the indenting scripts under /usr/share, then copy it to one’s home directory to be able to modify it, and then modify the javascript source. This could – of course – be done in a much better way. In an ideal world options like these should be available in Kate’s settings as check boxes. It should also be possible to have non-boolean options, like choosing a value from a list of possible values for a setting.

I would love to see something like the following:

registerSetting(“Indent ‘case’ and ‘default’ in switch statements”, “cfgIndentCase”,  “boolean”);

produce

☑ Indent ‘case’ and ‘default’ in switch statements

in Kate’s settings.

I don’t have the time myself, but I don’t think it would be very hard, and I’m sure that many people would be a bit happier. Me and the other Kate developers would glady be of assistance. ☺

Dear “Katevim” users.  Kate’s Vi Mode is steadily improving and I want to take a moment to tell what’s on the horizon for KDE 4.4. There has been quite a few bugs fixed since 4.3, but some major new features have also been introduced:

The Comma Text Object

This is something that I have been missing in Vim. The comma text object makes it easy to modify parameter lists in C-like languages and other comma separated lists. It is basically the area between two commas or between a comma and a bracket. In the line below, the three ranges this text object would cover is highlighted in red.

Comma text object ranges. If the cursor is over, say, "arg2", pressing c i , ("change inner comma") would delete "double arg2" and place the cursor between the two commas in insert mode. A very convenient way to change a function's parameter

This has actually been in Kate’s Vi Mode for a while now, but since it has not been announced until now, I guess I am the only one using it.

Limited Normal Mode Mapping Support

It is now possible to add mappings in normal mode (:nnoremap in Vim). There are still some flaws, such as the fact that one cannot map a keypress to “:somecommand<enter>“, but hopefully people who are using dvorak/colemake can make use of the vi mode now.

It is now possible to map keypresses in normal mode

Command Line Mode Commands

Yes, really! Kate’s Vi Mode finally support some of the most command commandline mode commands from Vim. What can be done from the Kate editor part is limited by the fact that it can’t control its hosting application, but Kate – the application – has now gotten support for the following commands:

• q, qa
  
• w, wq, wa, wqa
  
• x, xa
  
• bn, bp
  
• new, vnew
  
• edit

Kate showing help text for a command line mode command

(Ok, not really.)

Kate’s maintainer, Christoph Cullmann, shared a funny story over a beer one of the first days here at GCDS.

In ye olden days, what is now Kate and Kwrite was one application called “KWrite – KDE’s Advanced Text Editor”. However, the author of Kwrite mysteriously disappeared. Christoph forked Kwrite and continued working on it and after some time it greatly surpassed Kwrite’s capabilities and was becoming more of a power tool. A name change was long overdue.
Being a good German, Christoph decided to name it after the philosopher Immanuel Kant, so in KDE 2.1 the editor “Kant” was born.
For some strange reason, probably easier to understand for native English speakers, it was renamed to “Kate” in KDE 2.2. And thus what still is KDE’s Advanced Text Editor was born.

It’s not a simple, 27 line python script any more, but now it’s much more usable. (unless there are some stupid bugs I have overlooked. )

As suggested I uploaded it to KDE Look: http://www.kde-look.org/content/show.php?content=104182, so you can install it from the “Add widgets…” dialogue or download it and install it with plasmapkg -i gcal-1.1.plasmoid.

The login is just a quick hack, btw. This pretty much sums it up:

src = src.replace("id="Email"",
    "id="Email" value=""+self.settings['username']+""")
src = src.replace("id="Passwd"",
    "id="Passwd" value=""+self.settings['password']+""")
src = src.replace("id="gaia_loginform"",
    "id="gaia_loginform" name="gaia_loginform"")
src = src.replace("",
src = src.replace("</body>",
    "<script>document.gaia_loginform.submit()</script></body>")

I also tried the ninja trick from Ariya’s blog to get a transparent webview, but Google’s 1995 gif logo pretty much destroyed the appearance, so I dropped that.

http://hamberg.no/erlend/2009/05/07/google-calendar-plasmoid-take-two/

In case anyone is interested:

I made a simple Plasmoid for viewing coming events from Google Calendar. It’s simply a webview showing the iPhone version of Google Calendar. It’s written in Python and took 10 minutes to write (27 lines of code) by following the excellent tutorial on techbase.

You can download it here: http://hamberg.no/erlend/files/gcal.zip. If you improve it or make another Google Calendar plasmoid: let me know!

Oh, btw. To install it run plasmapkg -i gcal.zip.

P.S: openSuse users: I had to install python-dev to actually run a python plasmoid. Don’t know why.

Tourists in front of Angkor Wat.

Among the new books I’ll bring there will also be at least one wikibook. Yes, a real, physical wikibook.
You see, I have been using the x86 disassembly wikibook quite often, and recently I read that there were a “a collection for print-on-demand publishing from PediaPress” available for the book. Being curious, I had to click the link to see what that actually meant…

It turns out that PediaPress will print a copy of a wikibook for a very fair price. It can even be your own compilation of parts of books (and Wikipedia support is coming, according to their webpage). Printing and shipping of the book (200 pages) to Norway was a little over 10 EUR.

I’m now sitting with three printed wikibooks in front of me, and the quality of the printed book are very good. Needless to say, I’m very happy. They even donate a portion of the proceeds to the Wikimedia Foundation (though, they don’t say how much).

Shiny new books

Okteta is of course mentioned