gofr

Well it turns out that gofr does exactly what I want. so yay to the author, and yay for my little pet project, looks like most of the Yak's will have to be shaved another day.

What bugs me about Go

Putting language design aside entirely, because lets face it every programmer has a different idea of what should, and should not, be in the perfect language, there is one thing that is beginning to really bug me about go.

And that is how poorly documented the command line tools are. Firstly see the Plan 9 docs at http... is positively useless to me when I'm on the train with no internet access. Which is a good percentage of the time.

I've been wresting for several days with trying to set up a build system for a multi package project. The documentation for cgo says see the make file, which was not at all illustrative, especially as the make file does not seem to contain any rules that actually call the cgo! All we seem to get is a lot of messing about with intermediary C files. And trying to dig deeper just ends up at the completely undocumented gomake program.

Then my second problem is that I don't want to install the resultant package globally I'm using it in exactly one particular project. Installing it globally for my system is completely the wrong thing to do, especially as I'll be going back an making frequent changes to it, And my ultimate aim is to produce a standalone executable.

The depressing thing is that in this particular instance even the mailing list seems to be of little help. Searching through the archive suggests that no one has gotten an answer to this question. Every thread I found is filled with people saying yes I have this problem too. And the odd, the I have this problem too so I've started writing a build tool variation. I've started yet another thread about this though, just in case I have better results .

So far the only tool I've found that at least claims to handle cgo is gofr. Sadly it seems to be a little out of date at the moment and won't actually compile at. All in all my pet project is delayed, because I've got a Yak or two to shave...


PS: Yes I know its open source, and I would happily contribute documentation, if I actually knew how to solve the problem. Which sadly I do not.

More NCurses

Since someone actually commented on my original post here is a status update
I've actually moved to starting again from scratch, with a wrapper that is more modern than the one I found (It still had semicolons at the end of each line). My new version is already somewhat more comprehensive though nowhere near complete.

One of the changes I've made is to allow method chaining so instead of adding the move and do X method for every single operation I have a Mv and Color and Set (as in attrset) which return the window you called them on. This allows calls like:

window.Mv(10,10).Set(curses.A_BOLD).COLOR(4).AddStr("Hello World")

or better yet:

fmt.FPrintf(window(10,10).Set(curses.A_BOLD).COLOR(4), "Hello World")

Yes I made Ncurses Window type implement the Writer interface : )

And as to releasing it back. I absolutely plan too. Though I still have a few Items I want to get working first such as:

1. Make my InitScreen take configuration options so that it can set things like CBreak, NoEcho and Keypad for you (I already have it initilising the color system if required.
2. Implement the border drawing primitives though this is just fairly mechanical work.
3. Add basic wrappers for the related panel, and menu libraries. I'm still trying to decide how all this should be packaged.
   

Messing about NCurses and Go

So recently I update by go installation and then installed an ncurses library. I quickly discoverd that the ncurses wrapper is incomplete and tends to not be very goanic.

So far I've added a whole host of missing methods and changed a few others. I also added a Write method which lets ncurses Windows work with the methods in the fmt package. I'll have to see if the original author is interested in my changes as I do seem to be taking the wrapper in a slightly different direction.

All together it has been an interesting way of playing with the go language.

Why Go is a good thing

I've seen quite a few posts and comments on blogs along the lines of go is just a crap version of X I can't understand why google is wasting time on it, instead of (just using | improving) X. There are several answers to this.

Firstly Go is probably different from X and does not have the same stated goals as X. Especialy where X turns out to be a high level programming language that has a very large runtime, or runs in a VM or is interpreted.

Secondly Diversity is good. Think of Go as just another mutation of C, which has some new and useful features. Having written a few tiny programs I can see two so far. The first is that even though we are statically typed it is amazing how rarely a type actually appears outside of a method signature. The implicit typing that occurs when you set variables to initial values gets things correct an awful lot of the time. And the big one is concurrency. Everyone knows that programming concurrent software is hard. As the trend these days seems to be to multi core CPU's it is also becoming a very important area. Big thing is that Every program I have written so far has included gorouteens. they are a great way to generate data (if any place you would be inclined to use a generator in Python you'll be creating a go routine.

It occurs to be that a list comprehension style syntax for defining generators would by handy here. But thats just sugar as it where and I can definitely live without it, much as I have been able to live without anonymous functions in python.

I think that Go is a worth while addition to the programming language ecosystem. And this is true weather it survives or becomes extinct.

Generics or Bust

I have to add my voice to the choir calling for generics to be added to Go. As others have noted Go contains no fewer than four parametrized types: arrays, slices, maps and channels. Such types are so mandatory that it seems impossible to build a programming language without them.

And it is an annoying asymmetry that I as a programmer can't define an equally parametrized linked list or binary tree type. I expect that these will come eventually. My hope is that it will be sooner rather than later though.

The Go Language

So there is a new language in town. Having gone through all of the docs I have to say it looks interesting. The need to destinguish between new and make is a little messy, the language FAQ agnoledge this however.

I like the type system, with the implicitly implemented interfaces. It does look like Go programs will involve quite frequent casting. Ditto for the built in concurrency primitives, and I expect that most programs will make quite frequent use of them. Where in Pthon I might use a generator I could well see myself using a goroutine in Go, and getting my generated items from a channel.

A lot of effort has been made to make the language terse, which is a nice feature for a low level language to have. And yes making switch statements default to breaking at the end of each case unless told otherwise. Thank you finally a language that reflects how switch is actually used!

Personally i don't see why they didn't just call the looping construct loop, rather then for. seeing as it is a general purpose looping construct that can be invoked in several ways that look nothing like a traditional for loop. Still this is a minor thing.

What does look certain is that Go programs aren't going to look much like C or java, once enough people learn how to use the language natively. The basic constructs are just different.

Now that I've gotten this far its time to try some actual programming in Go. To this end I've retrieved the list of 99 Lisp problems and I'll see how I go in solving them using Go. Step one will be to build a linked list typo work with. It will be interesting to see how much mindshare Go can capture. And when we can expect a Windows version, lets face it lack of Windows support is glaring omission at present, even if I don't use Windows I still recognise its importance in the marketplace. (Now there's a scary thought Go.net ... its only a matter of time i suspect.)

An RPG in JavaScript

I've spent my train time for the last two weeks working on an wrting an JavaScript RPG (Thats Role Playing Game) system. The end result is intended to be a cross between the system used by Kingdom of Loathing and a traditional text adventure.

So far I've been boged down with a lot of low level mechanics, and ensuring that all my objects can round trip between JavaScript and XML. E4X makes this far less painful then it would otherwise be. The plan is to have a JavaScript game engine that executes XML based adventure files. Why XML? because JavaScript can allready parse it and it will be less cryptic then JSON. I'm musing that an adventure creator would also be nice, and would give me an excuse to play with XUL.

E4X means that at the moment my engine will only run in Firefox. But then this is a hobby project and I have better things to do then deal with the Pandora's Box of cross browser issues. Especially as Firefox 3 already implements so many goodies from HTML5 and ECMAScript 5th Edition.

Though I can't wait for the next beta of Firefox 3.5 and the @font-face CSS property. That and border images Should really come in handy when I get around to putting an interface page together.

JSEXT

I've been playing with a javascript library, which works as both a command line, and server-side execution Environment. Its called JSEXT and is a rather interesting beast. plus you can call your server side functions from script that executes in the browser, and JSEXT will generate the boilerplate needed for the AJAX call automatically.

For one thing it provides an incredible amount of auto loading magic, which sees it find not only functions in other javascript files but also in C header files. Any C library will effectively be usable form javascript. That got me thinking Cairo is a C library

Getting the helloworld example from the Cairo FAQ going was reletivly simple. But JSEXT provides something better, an OO wrapper for the Cairo library. Granted I did have to check the source out from SVN and compile it to get them, and then sort out a couple of minor bugs in the wrapper.

Anyway the following code is a slight modification of the basic example. This script is intended to be accessed from a web browser as title.jsx?"Insert your text here" and yes it works perfectly fine if you set the src attribute of an img tag.

function(str){
    this.responseHeaders.contentType = "image/png";

    var surf = new JSEXT1.Cairo.Surface.image("ARGB32", 800, 80);
    var cr = surf.context();

    with(cr){
        selectFontFace("serif", "normal", "bold");
        fontSize = 32;
        source = [0, 0, 1];
        moveTo(10, 50);
        showText(str);
    }
    surf.writeToPNG(stdout);

}

Yes this is a file containing one anonymous function. This is one of the more curious features of JSEXT. You can give it a directory tree and it will walk it and build a set of Javascript objects based on what it finds. This does requie one method per file, which is somewhat unusual. But seems to work alright in practice. It is also uses lazy loading so only the methods you actually use get loaded into the runtime.

Javascript Solution

I've been doing two things recently. Messing with CORBA and adding a small JavaScript effect to a web page. Working with CORBA is technical and challenging, and you would think interesting. To tell the truth CORBA has a somewhat unjustified bad reputation round the office. It dosn't fit perfectly to python, that is true, but it is still a very fast and reasonably secure way to do RPC.

The little JavaScript solution was suprisingly more enjoyable. Now I don't do much fornt end work so I had to look up essentially everything, and had one approach not work, for no obvious reason that I could see. But on the whole it was more enjoyable. I suspect that the immediate visible feedback provided by making a change, reloading the page and seeing what would happen, had a lot to do with it.

I'm think I can see more web design work in my near future. And more javascript. wxJavascript or GLUEScript as it is to be know from the next version onwards is worth a look. Especially as I like the wxWidget toolkit. Don't know if I'll be sufficently motivated to build it myself though.

PicoLisp in a chroot

Picolisp has a nifty feature where you can include inline c code, and it will be automatically compiled for you, and just work.

Unfortunately I'm on a 64 system, and pico dosn't at the moment compile under 64 bit. Now I'm told that if I install the right things and tweak the right options I can get 32 bit binaries to compile anyway. But that involves modifying the upstream source and I don't like doing that, unless I plan to submit a patch.

In this case It seemed somewhat pointless. So I though I'd try setting pico up in a chrooted environment. I came accross the following post on the matter: Installing apps in a 32-bit chroot in AMD64 Debian systems.

I followed most of step 1, with the following exceptions:

• I skipped step 1.3 (decided not to mess with my main gcc instalation.
• Installed gcc, and build-essentials into the chroot. (also locals and less which didn't get installed by default.
  
• Installed dchroot into my real system ( I think this is soemthing the tutorial does later).
• Compiled picolisp in the chroot enviroment and installed it to /usr/local/
  
• Added some scripts to my real path which would execute picolisp and psh in the chroot.

All in all it was a surprisingly easy process and at the end of it I have a fully functional picoLisp. which is accessible form anywhere. even the scripting is easy.

!#/bin/bash
dchroot --preserve-environment <> "$@"

This lets me run pico the same way weather I'm in the chroot or in the main system. And there are no gremlins. I started a picolisp server in the chroot, started firefox (I mean Iceweasel) in the main system, and everything worked, even the ondemand compilation of c from inside pico.

Partially I did this because I wanted to learn how to do it, and now that I have a 32 bit chroot I'll probably move my IceWeasel into it and install flash.

Hmm, I wonder which I'll see first, 64 bit PicoLisp or 64bit Flash? I have it on good authority that they are both in development.

Programming is not that different.

It seems I'm not the only one who thinks programming is
just anther form of composition.

Applying Strunk and White to programming - absolutely inspired (I wish I'd through of it first).

I have seen a few places aregue that Design Patterns, as they are commonly used, are a complete missinterpreatation of A Pattern Language by Christopher Alexander.

Just two examples of how Programming is not that different from everything else. And why Extreme Programming is a step too far.

PIcolisp Cookbook

One thing which picoLisp needs is a Cookbook. A set of recepies on how to use its quite rich set of primitives to solve particular problems. Currently most of this information is somewhat implicit in the Reference docs. And requires making some big inferences after considering which sets of functions have links to each other.

All of the built in functions are documented, what is missing at the moment however is the various idioms for using them in practice. Thankfully you can usually get a prompt answer on the mailing List.

I came acrose one such are the other day. I was trying to break a circular list, built by fifo, into a plain list. In Common Lisp I'd do this with set. so I tried it to no avail. In Pico (set (cdr A) NIL) actually sets the 2nd element of the lsit A to nil.

It turns out that to set the cdr portion of a cell I want a function called con. My first reaction to that was ... well that's annoying. But then I got to thinking that its not actually a bad thing. Essentially we have to setting functions which are subtly different.

set: is used for setting values, and con is used for manipulating structure. Yes things get a little confusing if you use cells to build a tree structure where both the car and cdr contain pointers to other cells. That aside I when reading code I can assume that calls to set will change values but not alter the underlyign datastructures, while calls to con will alter structure.

The more I think about it the more I like this distinction. It adds something usful to the code. In the end the only thing which tripped me up was documentation. The Picolisp docs are good as far as they go, but missing a few bits.

Alex, the maintainer of PicoLisp, seems somewhat reluctant to make the official documentation more verbose. Well we may have to agree to disagree on that one. But there has been talk of building a picoLisp wiki (powered by picoLisp). And this may go some way to adding the Cookbook style reference that appears to be needed.

Anonymous Recursive Function

I thought I'd give the 99 Lisp Problems a spin as a way of exploring Pico Lisp. One of my first outings came up with the discovery that if you call a function without enough arguments the remaining arguments get set to NIL this can be used to do default arguments as follows:

(de fun (X Y)
(let (Y (or Y 5))
  (+ x Y)))

(fun 1 2) -> 2

(fun 1) -> 6

I did this to simulate an accumulator argument in a recursive function. But then i got to thinking, I'm executing the let on each recursive call, which seems kind of a waste as it is only needed on the first call. Well Pico has an answer for this recur and recurse which allows you to define an anonymous recursive function. Now this is something you don't find in your garden variety common lisp!

a list reverse (yes I know its built in but it see the 99 Python problems above) is then implemented like this;

(de my-rev (lst)
 (let (res ())
   (recur (lst res)
          (if (pair lst)
            (recurse (cdr lst) (cons (car lst) res))
            res))))

That is one neat way to make do without auxiliary functions.

Lisp is addictive

A week or so of Pico Lisp and I'm addicted again. Now the label was right, this is no common Lisp. Part of this means that a lot of built in functions have different names but then lets be honest, 'filter' is a much better name then 'remove-if-not'. I also found that there is no 'reduce' function but it was trivial to implement.

I have to say that having having one name space for functions and variables works, and using quote as lambda is growing on me. Pico lisp is proving to be a very succinct lisp to program in, which is a good thing.

Time permitting I'll be doing a lot more pico lisp hacking in the near future, port a few scripts I've done in python as practice and then on to some more interesting stuff. I've got some pointers on how to mix pico lisp and c code, which will is bound to prove useful

Been away from Lisp too long.

Yes I'm sad to say that I've spent too long without messing about in Lisp. Now that I'm trying with pico lisp theres a lot of basic logic which seems to be bogging me down, such as when to quote and unquote things (though Pico lisp seems to be a little different in this regard).

Another omission, from the point of view of convenience, is the lack of a well developed string formatting function. Granted the built in symbol manipulation primitives are more general then a format function but in simple cases they lead to more verbose code. Note Pico Lisp does have a function called format but it is restricted to formating a single number as a fixed precision decimal.

Still I'm working slowly in adapting some examples from a Common Lisp book into Pico Lisp, and if nothing else its an enjoyable exercise.

It looks like I am on the Pico lisp mailing list, though I never got notified that my subscription request was accepted. Still I got to ask my question now, which is good.

White space

I came across an interesting blog post the other this morning: Python Indentation considered boneheaded I like meaningful indentation. Because I find it easier to think that way. I had coded in other languages for quite some time before discovering python.

This means that I have probably spent weeks of accumulated time going back and adding semicolons to statements because I forgot to terminate them the first time round.

As for using python on larger projects. Well the answer is internal standards. If you try to contribute to C projects like GTK they come out and say things about standards right up front.
If you submit a patch and it doesn't meet the coding standards then we are going to reject it out of hand. Its quite a reasonable position to take.

Moreover a good editor will support a whitespace delimited language. My examples are from vim, though I assume that Emacs can do similar things as well (no need for another editor flame war).

• Auto indentation sticks consistent indents on my lines.
• Editor can highlight lines that mix tabs and spaces in their indents.
  
• Files can carry a special comment which defines indentation rules.
• If all else fails you can switch to a mode where whitespace characters are rendered so they are visible.
  

In my day jobs all the code is python. The code base is quite large and has probably had over twenty developers working on it over the last nine years. For reasons which are lost to history we use tabs only in all the files, and it works. Some developers do seem to feel strongly about the tabs vs spaces debate. Before starting here I used spaces, but when it comes done to it I really don't have a preference. About the only Thing I will attest to is that you should not mix the two approaches in the one file.

I had to write some java a while back, only a small simple problem, and after python I found it unbelivably hard. I realise this is largely personal preference, but iit felt like the syntax was fighting against me rather than helping me.

At the end of the day a good syntax is one which you don't notice. Foe me being a visual person seeing well indented code gives me a quick graps of what the code is supposed to do. One of my egocentricities in this regard is that I prefer:

if foo:
  return
else:
 # do something else

to:

if foo:
  return
# do something else

Python will behave the same way in both cases, however for me the first option is more explicit. as I can see that we have an else branch without having to reach the code. If the body of the if is long enough it could be easy to miss that pesky return statement.

Pico Lisp

In my continuing search for a language to play with, other than python, I came accross Pico Lisp the other day. A very intriguing lisp dialect for several reasons:

• Fully interpreted and yet faster then compiled lisp in some usecases
• Persistent storage (essentially an object database)
• built in Prolog.
  
• built in web server and support for online applications.
  
• No floating point numbers ?
  

That last point seems a little curious. but then i got to thinking how many applications out there really need floating point numbers? Well there are really a lot of applications that don't. In my day job I deal with online payments. No floating point numbers here, just express things as cents and be done with it.

Using floating point in financial circles is in general a big no-no, people get a lttle tucky when your working with money and make rounding errors. Also its a little hard to do anything with a fraction of a cent.

Graphics. Well yes and no. Fixed precision might be quite good enough. Heck there's a 3d flight simulator application to prove it even. The Documentation claims it can be easily extended with C, including writing C functions inline, unfortunately exactly how this is done, or what the limitations are, is not explained. Once I get onto the mailing list I plan to ask.

First impressions are that this is a very small, neat and yet still useful language. Time will tell if I can do something interesting with it though.

What Erlang is bad at

Recently I wanted to write a program which would take sections from a texmacs document and run them through the style command. And then process the results to get a particular set of statistics.

This includes some additional crunching on what style produces. As it was my language of the month as it where I thought I'll do it in Erlang, but after spending a train trip searching the documentation I found that making system calls in a subshell is not somthing that erlang can do at all easily. I certainly couldn't find a way which did not involve writing a c wrapper around in any case.

So it was back to python for this one and a usable script done in about an hour. Lessons learned: Erlang is not a good language for quick and dirty scripts. I'm not saying that it can't be but the standard library dosn't seem to support such a use case.

An aquantence who is also programmer told me once that he is also tempted to look at Erlang now and then, but he can never seem to find a project that he really wants to implement in it. More often then not he ends up in exactly this position "Man this would be so much simpler in Python" and so that is what he uses.

I think I have a new point to add to my list of what makes a good language:

"Can be used to solve small problems easily"

In this regard anything which requires copious poilerplate or is missing simple ways to interact with standard in and out looses instantly.

Virtual Machines

In the recent debate about weather or not languages should ship with there own virtual machines, or use an established one. I'm with diversity here. Put simply different languages have different needs. Just because the JVM is good for java it doesn't follow that it will be good for Erlang. And Erlang is sufficently different to warrant it's own vm.

1. An Erlang vm can assume that memory will not be modified. I expect his has a big impact on how you manage memory
   
2. An Erlang vm requires tail recursion optimization. if you don't have this your code will be slow and use up more stack space.
   
3. Every Erlang process has a message queue. Most VM's will not provide a message queue out of the box.
   

A lot of the same things also apply to Haskell, you can't expect a functional language to work optimally on a vm designed for procedural languages. the code optimizations and memory management strategy needed is radically different. In this I'm quite in agreement with the following post:

Making it stick.: Huh?: "The fact that it runs on its own interpreter, bad."