fixtr – linux utility to show FIX protocol messages

I recently implemented a standalone FIX message parser in C++ as I wanted to answer a few questions I had myself about the design on the protocol.

To define the protocol [what messages, fields, values are allowed] I use the same XML format that QuickFix and QuickFix/J use.  This is a more compactly rendered subset of the information provided in the fixprotocol.org XML repository.

The spec itself is most easily browsed via the foxprotocol.org’s ‘Fiximate’ site, or download the full PDF specification.

I did notice that QuickFix and QuickFix/J seem to come only with FIX 4.0 through FIX 4.4 definitions… After some pain wrangling XML with perl I created FIX50SP2 which should match the most recent FIX specification.

You can find the full source, and the FIX 5 XML definition on the google code project page.

Note : BSD licence, uses gnu C++ on Linux, makefile build, depends on libXML2 for SAX2 parsing of XML

enjoy, and happy gnu year!

gord.

picolisp? nanolisp? femtolisp? – all taken! … vfuncs attolisp is born

The embarrassment of riches truly astounds in the domain of ahem ‘very small’ lisp implementations… and who am I to refuse to fill an obvious missing link in the series?  We got small covered…

Yes, I have in fact begun a super cut down lisp implementation for vfuncs, which I think will be a nice way to express such idioms as map [hey, lisp invented map, right? – maybe not, better check ]

I’ve uploaded the new files atto.c, atto.h, attotest.c to the vfuncs project page – grab v0.6.7.

Some of the earlier blog comments around vfuncs got me to wondering.. How would you implement closure and currying in straight C so it could be used in useful array verbs?  It seems what you need is to replace some verb params with values from the ‘environment’.  That way the verb can use both runtime args and design time args easily… I did hack up something, but it began to look more and more like I was writing an interpreter… so I decided the ‘honest, unenlightened hacker’ way to proceed was to actually _write_ an interpreter for as simple a language as I could think of…

The core guts of lisp is, well – calling functions with args, when any of those args could be a const, a variable or another function.  So, the atto-kernel of lisp is something like this grammar [a comment pasted from the C source] –

//      expr : left func args right // (func arg0 arg1 arg2 )
//      args : arg args | empty // args is any length 0..n
//      arg  : ident | const | expr // each arg can be an expr itself – nested calls

In the spirit of ‘start small, get it working and add features’, this cut-down grammar allows you to parse expressions like the following –

//     “(sqrt (add (sqr 3.0) (sqr 4.0)) )”

This is the ‘lisp way’ – everything is in prefix notation ie. (* a b) not (a * b).  You get used to it, and it is very consistent [and the reason lisp macros are more part of the language than say C/C++ macros].