bookmark_borderWhat not to write in haXe

You might have notice that during the past few months i’ve written a few articles about haXe, a language and compiler which pits itself as a “toolbox for the web developer”.

Recently I decided to test out haXe’s platform support. I did this by taking my SCUMM interpreter code – which I had previously written for flash 9 – and tried to get it to work on the other two major platforms haXe supports, javascript and neko.

To start off with, I had to remove its dependency on flash. This was achieved by making replacement classes and switching between the two using the conditional pre-processor. i.e.:

#if flash9
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.utils.ByteArray;
import flash.geom.Point;
import flash.geom.Rectangle;
import flash.utils.Timer;
#else neko
import noflash.ByteArray;
import noflash.Bitmap;
import noflash.BitmapData;
import noflash.Point;
import noflash.Rectangle;
import noflash.Timer;
import noflash.TimerEvent;

Most of the modifications to the code looked like this, with liberal sprinklings of “#if flash9 … #end” round the flash specific code.

Eventually I got to the point where things started to look like they were going to compile, or so I thought


“Array too big”

The first problem I encountered was that it wouldn’t compile.

hiscumm/SCUMM6.hx:1870: lines 1870-2127 : This array declaration is too big, try to split it

Array declaration too big? What on earth was it going on about?

| TArrayDecl el ->
if List.length el > 115 then error "This array declaration is too big, try to split it" e.epos;
call p (field p (ident p "Array") "new1") [array p ( (gen_expr ctx) el); int p (List.length el)]

Oh, right. Seems I cannot have arrays declared with more than 115 elements. A seemingly arbitrary limitation that is not referenced anywhere in the documentation – great!

Not needing the opcode table for my little experiment, I commented most of it out. Problem solved.

“32bit? no, 31bit!”

Now the first time I got the interpreter to compile for neko, I thought “Wow, great! Looks like this is going to work.” Unfortunately though, it didn’t. Instead, I got a rather odd exception when reading out of my replacement ByteArray:

Uncaught exception - Overflow

Turns out the problem was with this code here, in neko.Input:

public function readInt32() {
  var ch1 = readChar();
  var ch2 = readChar();
  var ch3 = readChar();
  var ch4 = readChar();
  if( (ch4 & 128) != 0 ) {
    if( ch4 & 64 == 0 ) throw Error.Overflow;
    return ch1 | (ch2 << 8) | (ch3 << 16) | ((ch4 &#38; 127) << 24);
  } else {
    if( ch4 &#38; 64 != 0 ) throw Error.Overflow;
    return ch1 | (ch2 << 8) | (ch3 << 16) | (ch4 << 24);

So basically the reader was trying to stuff the whole 32 bit value into a neko Integer, which is actually 31 bits. Oddly enough though, the value being read was identical to a value I specified in the code.

But haXe never bothered to complain about an overflow!

This can be demonstrated by the following code, which prints “-766623411” instead of the expected “1380860237”.


Thankfully, a solution exists. There is an “Int32” type which properly handles 32bit integers. However there is a really big snag with it – it’s a class.

That means you cannot use any fancy inbuilt operators with it – you have to use a set of functions instead.

import neko.Int32;

var result: Int = 1 + 2; // simple
var result32: Int32 = Int32.add(Int32.ofInt(1), Int32.ofInt(2)); // aaaarrrghh!!!

result += 1; // simple
result32 += 1; // don't even think about it, it won't work

And to top it all off, this “Int32” class only exists for the neko platform, you cannot use it with flash or javascript. Unless you write it yourself, but that is besides the point. It should at least have been there to fill in the gap.


If you are looking at writing code in haXe and want it to work across all 3 of its supported platforms (flash, neko and javascript), then beware if you are reading, writing, or otherwise processing 32bit integers.

In addition watch out for mysterious arbitrary limitations such as the 115 item limit for declared arrays.

bookmark_borderAccounting with Luca

A while ago now, I stumbled across a web based double entry accounting solution called Luca (not to be confused with the Mac Application).

Unfortunately though, the documentation was a bit sparse. However with a bit of persistence, I have just about managed to figure out how to use it.

Starting out

(note that for this little walkthrough I am using Luca 1.02, so don’t be surprised if you are using a later version and things look that bit different)

Assuming you have managed to download and install Luca, as well as log in, you’ll be presented with this rather interesting interface:

Luca main menu

Whoah! Lots of options to choose from, but which of those do we need to start off with?

First things first, you’ll need to create a chart of accounts, so select the “Charts of accounts” option. You’ll be presented with a list of charts, which should be empty. Click on “Add new chart”, and your screen will look something like this:

Luca new chart

The only 2 values which are of interest are “Description” and “Format mask”, the former of which can be anything you like. The latter is a bit more tricky, and it took me a while to figure out. It seems that the “Format mask” is basically a sequence of 9’s using dots as separators. The more dots you use, the more you can nest your accounts.

For reference, I put the following values in this form:

  • Description: LucaCorp
  • Format Mask: 9999.99 (i.e. 2 levels one using four digits, the other using two)

You should now have a chart you can use. But to be of any use, it needs to be assigned to an Organization. To do this, go back to the main menu, and select “Organizations”. Then select “Add new Organization”. Your screen should now look something like this:

Luca new organization

Give your Organization a name, a remark if you like, and of course a chart of accounts. The values I used are as follows:

  • Name: LucaCorp
  • Remarks: blank
  • Chart of Accounts: LucaCorp

Note that you will also need to give yourself (and anyone else you trust with a user account) permission to use the Organization when entering transactions. This can be done in the “Users X Organizations” screen.

Creating accounts

Now would be a good idea to actually make some accounts. To do this, go back to the main menu and select “Accounts of the chart”. Then for the “Parent chart being edited:” field, select your chart of accounts. Your screen should now look something like this:

Luca add account

For each account you want to create, click on “Add Account” and fill in the form, which should look something like this:

Luca add account

The “Class” is the type of account to be created. You can make Accounts for Assets, Liabilities, Equity, Revenue, and Expenses (note that this list can be altered by playing about with the “Account classes”).

The “Std. journal” corresponds to an id of a “Standard Journal Description” which you can make in “Standard Journal Descriptions”. From what I can tell this allows you to save on typing repetitive descriptions when entering transactions, though I have not really found a use for it yet.

“Code” is the identifier of this account. It needs to correspond to the “Format Mask” you created earlier, e.g. in my case, “1234” and “1234.01” would both be acceptable.

“Parent account” is the code of the account you wish to be the parent. You can use this to create complex hierarchies of accounts, something which I assume Accountants love to do.

The rest of the fields are pretty obvious, apart from “Mobile clients” which I can only assume allows people using Luca’s bluetooth functionality to enter transactions on the account (note though that I have not tried this out).

So now you can create accounts at will. As for which accounts to create, it’s really up to you. However if you are a bit stuck, below is a table of values you can enter to reproduce a set of accounts from of one of my favourite tutorials on Double Entry Accounting written by Joseph Mack.

RocketScience LLC Accounts

Class Code Parent Description Small description
Asset 1234 cash cash
Asset 1234.01 1234 Joseph Mack, withdrawing jm_withdrawing
Asset 1234.02 1234 check account check_account
Asset 1234.03 1234 petty cash petty_cash
Liabilities 1235 liabilities liabilities
Liabilities 1235.01 1235 Joseph Mac, capital jm_capital
Equity 1236 equity equity
Equity 1236.01 1236 accumulated profit and loss acc_profit_loss
Equity 1236.02 1236 clo profit and loss profit_loss
Revenue 1237 revenue revenue
Revenue 1237.01 1237 fees earned fees_earned
Expenses 1238 expenses expenses
Expenses 1238.01 1238 advertising advertising
Expenses 1238.02 1238 food,entertainment food_entertainment
Expenses 1238.03 1238 office supplies office_supplies

Entering transactions

To enter transactions in Luca, you’ll need to first create a Batch. To do this, from the main menu select “Batches”. Then on the next screen, select your Organization and click on “Add new batch”. Your screen should look something like this:

Luca add batch

As you might have noticed, there is not much to a batch. The only thing to look out for is the dates you enter, which need to be in the format “yyyy/mm/dd”, and need to lie within the organization’s active period (the default being 1970/01/01 -> 1970/01/01).

If you ever want to change the date range of the active period, all you need to do is select “Active Period” from the main menu, then click on “Edit” next to the relevant accounting period for your organization. Your screen should look something like this:

Luca edit accounting period

Then all you need to do is enter an initial and final date. It’s as simple as that!

For my first batch, I used the following:

  • Description: First batch!
  • Initial date: 1970/01/01
  • Final date: 1970/01/01
  • Checksum: 0
  • Status: Open
  • Type: Normal batch

Now you can start entering your transactions, which in Luca are referred to as Journals. To do this, from the main menu select “Journals”. Then on the next screen, select your Organization and Batch, then click on “Add new journal”. Your screen should look something like this:

Luca add journal

So to sum this up:

“DB account” and “CR account” mean “Account to debit” and “Account to credit” respectively. I’m going to assume you know enough about double entry accounting to figure out which accounts you credit and which you debit.

“Std. journal” I already mentioned when creating accounts.

“Cost center” I have yet to figure out, best to leave this as 1 unless you really need it set.

“Date”, “Description”, “Value”, and “Status” are all pretty obvious.

You can enter as many journals as you like in a batch. It is also interesting to note that you don’t have to enter both a credit and debit for an entry – you can quite easily add multiple debit or credits in a row.

Profit and Loss

At the end of the accounting year, you’ll probably want to determine profit and loss, which usually involves folding revenue and expense accounts into a single profit and loss account. This is otherwise known as “closing out the accounts”.

So how does one do this in Luca? Quite simply in fact. Select “Balance closing” from the main menu, and your screen should look something like this:

Luca closing balance

So basically all you need to do is select your organization, enter in start and end dates, then click “Prepare to close balance”.

However you’ll probably bump into a few issues first time, as three conditions need to be satisfied:

  1. You need an account which contains “clo” somewhere in its description to store the closing values.
  2. The period you specify needs to be within the current active period.
  3. All batches in the specified period need to be set to “Closed”

The first condition is rather easy to satisfy. All you need to do is make an equity account named something like “clo Profit and Loss”.

The last two conditions we more or less went over when talking about batches.

Assuming you got the balance to close, your “Profit and Loss” equity account should now look something like this:

Luca profit and loss ledger

To sum it all up

Luca is a pretty promising accounting solution. It does accounting, reports, and also includes a bit of multiuser management too. In contrast to other solutions, it doesn’t try to do everything – which I believe is one of its strengths. It’s a relief not having to wade through a swamp of CRM to do something as simple as sorting out the accounts.

Sadly though Luca doesn’t appear to have a very active community, and from what I can tell Elvis Pfützenreuter puts most of the work into it.

Still from what I have been able to gather Luca is still under development so with any luck it’ll gain more useful features in the future such as multiple currency support.