thehelix112.com
---------------


Welcome to my website/rubbish tip: A place for me to put random messy crap.  Email me: thehelix112 [[at]] thehelix112 [[period]] com.


#9: First car event 6/24/2015
-----------------------------

First event with the new GT-R coming up this Sunday.  Super excited.  Got my shiny new helmet:

Got my shiny new tyre pyrometer.  Got my harness to install.  Then will be good to go!  Super excited.  This means I absolutely have to launch the car with the wife in it beforehand.  Will follow-up with the video of that :D


#8: New car! 11/25/2014
-----------------------

About 2 weeks ago I got my dream car.  With the loving support of my wife.  Black 2014 Nissan GT-R Black Edition.

GT-R in Malibu


Fits the baby in the back amazingly.  This photo is a pit-stop (nappy change in the boot) when we were out driving around Malibu last Sunday.   Pretty damn excited.  Will hopefully keep this space updated with mods and experiences.  Trying to get some dosh together for a clear-bra before my first track day. :)


#7: Wow it's been a while 10/15/2013
------------------------------------

Holy crap it's been almost 2 years since I updated this site.  That's unfortunate.
Since I last updated I've changed jobs.  I now work at EdgeCast. Very different than the last place, mostly in a better way. :)

It's super fun to be playing with thousands of servers, and to see real-world benefits to your work, almost immediately.  I will try to update this more frequently later on. :)


#6: LuaJIT FFI = Awesome 12/12/2011
-----------------------------------

I spent the last couple of days playing with this: http://luajit.org/ext_ffi.html.  This is some great stuff.  Not fool-proof as of yet, but still pretty damn slick.  It basically boils down to a call to ffi.cdef(), to which you pass a multi-line string that defines the C structures and functions you want access to.  You can refer to Mike's examples for more information: http://luajit.org/ext_ffi_tutorial.html. But something like this:

> ffi.cdef('int write(int fd, const void *buf, size_t count)')
> ffi.C.write(0, 'hi there', 8)
hi there>

Tidbit: the declaration's trailing semi-colon is only required if you use are supplying multiples.

Additionally, and this will be important later, as every declaration is processed, every type mentioned in each function prototype must already have been defined.

Now, assuming we want access to our entire project's structures and functions, there are a couple of options for integrating this with your entire project:

ONE:
Manually copy and paste your struct and function declarations into a new file.  The natural consequence of this is you end up maintaining a copy of every .h file in your project, and additionally, every type you use that is from an external .h file.  Oh yeah.  You need to go and bring in the definition of all these other types as well.

No thanks. 

TWO:
You could use gcc -E to preprocess all the macros down for each .h file.  Then you have explicit definitions for everything you use (and a bunch of things you don't use).  

This seems like a good solution, but alas, it presents two problems: 

1: gcc -E results in some processing artifacts that ffi does not like.  For example, if you have a file file1.h with:

#include <stdio.h>

and you run:

$ gcc -E file1.h -o file1.hffi

the first few lines end up as:

$ head -n 10 file1.hffi  # 1 "file1.h"
# 1 "<built-in>"
# 1 "<command-line>" 

ffi does not like these lines:

> f = io.open('file1.hffi', 'r')
> ffi.cdef(f:read('*all'))
stdin:1: unexpected symbol near ''

But you can use a sed line to keep ffi happy:

$ sed -ie 's/^#/\/\/ #/g' file1.hffi [1]

2: if you have two .h files in your project that include the same external .h (which I think is reasonably likely, if you have two files that call printf for example), you cannot cdef both of those files.  The multiple definitions of the included types will cause ffi to error out.

Let's assume you have two copies of file1.h from above (includes stdio.h).

$ gcc -E file1.h -o file1.hffi
$ gcc -E file2.h -o file2.hffi
...
> f = io.open('file1.hffi', 'r')
> ffi.cdef(f:read('*all'))
> f = io.open('file2.hffi', 'r')
> ffi.cdef(f:read('*all'))
stdin:1: attempt to redefine '_IO_marker' at line 208

But no worries, we can solve these with:

THREE:
You can fix the issue with --2-- by concatenating everything into a single compilation unit (file), so that the single gcc -E call will not result in redefinitions.  One corollary here is that you now have your entire ffi interface in one file.  

Unfortunately you can well end up with the following issue:

> ffi.cdef(f:read('*all'))
stdin:1: table overflow

As I did.  I believe this is simply because there are too many declarations in this file to be held in a lua table. 

So I finally settled on a cobbled together solution:

FOUR:
Sed out the #includes from each .h file individually:

$ sed -ie 's/#[ ]*include/\/\/ #include/' each_file.h

Preprocess with gcc to run the macros:

$ gcc -E each_file.h -o each_file.hffi

Post process out the artifacts:

sed -ie 's/^#/\/\/ #/g' each_file.hffi

Then you are more or less good to go, and you can load in each .hffi file that defines the functions and structures you want to use.

This is a working solution in my particular case, but is not without it's disadvantages:

1, the lack of include means that you are limited to structures you define, and any use of an external structure will fail.
2, as each .h file results in a separate .hffi file, you need to load in file into the luajit interpreter individually.


Helpers:

Thankfully, a couple of small helpers go a way to easing the second disadvantage.  I wrote a small script to do all the repetitive heavy lifting on paths, it went something like:

loaddir = '/project/install/dir/'

function project_ffi(...)
    if not ffi then
        -- ffi not registered yet
        ffi = require('ffi')
    end
    files = {...}  -- expand lua variadic args [2]
    for _,file in pairs(files) do
        -- for each file
        f = io.open(loaddir..file, 'r')
        if not f then
            -- file not opened
            error('Failed to open file: '..file)
        end
        ffi.cdef(f:read('*all'))
    end
end

You can then use this like:

> dofile('my_helper.lua')
> project_ffi('file1.hffi', 'file2.hffi')

Another small issue I found was that Lua has no facility for casting, and no integral type for pointers, leaving you with issues like this:

> ffi.cdef('void memcpy(void *dst, const void *src, size_t len)')
> i = ffi.new('int')           
> j = ffi.new('int')
> ffi.C.memcpy(i, j, 8)
stdin:1: bad argument #1 to 'memcpy' (cannot convert 'int' to 'void *')

I wrote a small C helper does the trick:

void *to_ptr(lua_Integer a_num)
{
    return (void *)a_num;
};

> ffi.cdef('void *to_ptr(lua_Integer a_num)')
> ffi.C.memcpy(to_ptr(i), to_ptr(j), 8)
>

If someone finds out a better way to do this, or anything above, please let me know. :)

Footnotes:



#5: Tune Up 3/11/2011
---------------------

I got a tune-up and new tyres (Continental Gran Prix 4000S) for my bike today at bikeeffect.com.  Larry was very helpful and did a fantastic job.  Gained an easy 1-2mph for free, judging by the ride home.  Could've been freak wind, but I don't think so.  Also set a new downhill speed record for myself, 39.48MPH in thongs (flip flops for the muricans).  Can't wait to see what it's like to ride some more!


#4: Bash for Dev Workflow 27/11/2011
------------------------------------

Bash is awesome.  It is ubiquitous, simple, and I kinda feel like it is in keeping with the unix spirit.  If written well it seems like you quickly find yourself building new things based on stringing together past things you've already written.  I do like that.

My current project is a series of scripts for automating development workflow at my work.  Basically a bunch of scripts that allow us to automatically keep in sync the issue tracking system (redmine) and git.  For example, when you start work on an issue, it creates a local branch tracking a remote branch, and indicates the branch name in the issue.  Working pretty well thus far, and already starting to save devs time.

Next up is integration with IRC so the reviewer of the issue is notified.  Kinda fun, and quite a change from C++. :)  Gunna investigate `supyboy.Tail' tomorrow for the IRC integration I think: https://ubottu.com/supydocs/plugins/Tail.html


#3: WTF Google? 27/11/2011
--------------------------

Google sites is a complete piece of crap.  What is this, 1998?  Very sad.  Taken me 30 minutes of dicking about to get this extremely interesting and attractive setup:
Oh well.  I guess there is an element of simplicity that is appealing if you squint hard enough.




#2: Doctors 13/7/2011
---------------------

About 8 years ago whilst I was doing my PhD I wrote a small referencing system to manage my dissertation's bibliography.   I only just got around to pulling it off of the laptop it was residing on and uploading it somewhere a bit more permanent.   It was a nice break from writing and coding up my thesis, and can be found here: http://code.google.com/p/doctors/

Its all PHP, and the layout was inspired by something else I've forgotten, but primarily it uses `hidden' directories and files (starting with a period) to keep the source files less visible.

That is all.


#1: Inaugural Post 3/7/2011
---------------------------

Been meaning to get a website for a while.  Done so.