Automated unit-testing for Haxe project using Travis-CI

March 19th, 2013  |  Published in Uncategorized  |  2 Comments

What is Travis-CI?

Travis-CI is “a hosted continuous integration service for the open source community”. It is tightly integrated with github, once we enabled its commit hook, whenever there is a new commit, or a pull request, on any branch, it will automatically build and run the unit test and notify us any problem respecting to certain commits.

Why use it?

It gives us an extra level of safety, which safety is what we Haxe users love, after all that’s one of the reasons to use a strictly typed language over a dynamic one. Travis-CI’s unit test on pull request is particularly useful, which we can instantly identify on the github pull request page any incoming changes that breaks our specification.

And did I mention this great hosted service is in fact free for open source projects?

How to use it?

All we have to do is to toggle the repo on in the Travis-CI accounts control panel, and then commit a .travis.yml in the root directory.

Here is an example .travis.yml that test C++, Neko and PHP targets:

# The first thing is to tell which VM environment we want the test to be run on.
# It dosen't quite matter for Haxe, just choose one of the targets our project support (e.g. PHP),
# and than apt-get install the others (e.g. Neko, C++).
# For more info, see http://about.travis-ci.org/docs/user/ci-environment/
language: php
 
# Install Haxe before running the test.
before_script:
  - sudo apt-get update                                # run update before installing anything
  - sudo apt-get install python-software-properties -y # for the next command
  - sudo add-apt-repository ppa:eyecreate/haxe -y      # add the ubuntu ppa that contains haxe
  - sudo apt-get update                                # pull info from ppa
  - sudo apt-get install haxe -y                       # install haxe (and neko)
  - sudo apt-get install gcc-multilib g++-multilib -y  # VM is 64bit but hxcpp builds 32bit
  - mkdir ~/haxelib                                    # create a folder for installing haxelib
  - haxelib setup ~/haxelib
  - haxelib install hxcpp                              # install hxcpp to test C++ target
  - mkdir bin                                          # create an output folder if needed
 
# Run the test!
script:
  - haxe travis.hxml

Note that at the time of writing, Travis-CI is running 64bit Ubuntu 12.4 VMs, and the ppa we used above will install Haxe 3.0RC and Neko 2.0.

Every command specified in the “script” section is actual test and should exit with code 0 if it pass or non-0 if fail. The above example simply try to compile the project. We can specify subsequent command to run a Haxe written test case, which we can use Sys.exit(allPass ? 0 : 1) to properly inform the test result.

Finally, we can check the repo page on Travis-CI for the test result. By default, if the test failed, an email will be sent to the commit author and the committer.

Existing Haxe project using Travis-CI

Some Haxe projects have been using the Travis-CI service for some time, for example flambeHaxePunk and Ash-HaXe. We will soon re-enabled the TravisCI test of NME too! Hope it will help Haxe to become more solid every day, every commit ;)

Tags:

hxml tricks every haxe user should know

March 4th, 2013  |  Published in Uncategorized

Haxe projects usually are compiled with a hxml file, which basically contains compiler arguments. So most of the tricks I am going to show is actually compiler arguments tricks, which may also applicable to nmml file or IDE that does not use hxml (though they should).

1. Run project right after compilation

Being able to do so is critical to rapid development. The simple trick to use -cmd, which run the a command after successful compilation. For different target, you have to use different command:

  • Neko

    -neko Test.n
    -main Test
    -cmd neko Test.n

    Or there is actually a shortcut that performs exactly the same as above:
    -x Test

  • C++

    -cpp bin
    -main Test
    -cmd ./bin/Test

    Notice the resulting file will be Test-debug if you compile with -debug.

  • JavaScript

    -js Test.js
    -main Test
    -cmd phantomjs Test.js

    Here we use phantomjs to run the JS file, the trace will output to the terminal. In case it is something graphical, you have to launch a browser with a HTML file that loads the script.

  • PHP

    -php bin
    -main Test
    -cmd php bin/index.php

    I guess you already knew you can execute a php script this way?

  • Flash

    -swf Test.swf
    -main Test
    -cmd path/to/FlashDebugger Test.swf

    Or if you're on Mac, you can actually use -cmd open Test.swf, it will do the same as you double clicked on a swf file (or any other file!).

  • Java

    -java bin
    -main Test
    -cmd java -jar bin/Test.jar

    Notice the resulting file will be Test-Debug.jar if you compile with -debug.

  • C#

    -cs bin
    -main Test
    -cmd mono bin/bin/Test.exe

    Mac/Linux has to use Mono to execute it. Windows should able to run it with -cmd bin\bin\Test.exe.
    Notice the resulting file will be Test-Debug.exe if you compile with -debug.

2. Commenting a hxml file

Use a hash (i.e. #) to comment out the rest of the line. Despite of being useful to put documentation, it can let us switch between different compilation configurations:

-js Main.js
-main Main
### comment out one of the following logging levels
#-D my-log-error
#-D my-log-warning
-D my-log-info

And in the source file:

public function attack(target:Monster, power:Int):Void {
    if (target == null) {
        #if (my_log_error || my_log_warning || my_log_info)
        trace("target is null");
        #end
        return;
    }
    if (power <= 0) {
        #if (my_log_warning || my_log_info)
        trace("attack power should be positive");
        #end
        return;
    }
    mp -= power;
    target.hp -= power;
    #if my_log_info
    trace("attacked " + target + " by " + power);
    #end
}

3. Append extra compiler argument when using the command line

Another useful trick to switch between compilation configurations, is to simple supply more arguments after the hxml file. For example temporarily switch to debug mode:

haxe project.hxml -debug

4. Multiple compilations at once

The majority knows the existence of  --next, used for separating different builds:

all.hxml
-js script/MainPage.js
-main MainPage
-lib jQueryExtern
--next
-js script/ContactPage.js
-main ContactPage
-lib jQueryExtern
--next
-js script/AlbumPage.js
-main AlbumPage
-lib jQueryExtern

There is an --each option, which reduce the repeating params. It is used in the haxe compiler unit test hxml. Rewriting the above, we will get:

all.hxml
-lib jQueryExtern
--each
-js script/MainPage.js
-main MainPage
--next
-js script/ContactPage.js
-main ContactPage
--next
-js script/AlbumPage.js
-main AlbumPage

But really, separating each of them in different hxml is easier to maintain and has better compatibility with code completion (because many editors don't read hxml with --next very well). So we may use the following instead:

MainPage.hxml
-js script/MainPage.js
-main MainPage
-lib jQueryExtern

ContactPage.hxml
-js script/ContactPage.js
-main ContactPage
-lib jQueryExtern

AlbumPage.hxml
-js script/AlbumPage.js
-main AlbumPage
-lib jQueryExtern

all.hxml
MainPage.hxml
--next
ContactPage.hxml
--next
AlbumPage.hxml

Switch the hxml for code completion when working in different pages, and use the "all.hxml" to compile at once.

Tags: ,

Improving Haxe Syntax Highlighting Support of Pygments

February 26th, 2013  |  Published in Uncategorized

3 months ago I have started to rewrite the Haxe laxer in Pygments, which is a syntax highlighter written in Python, used in both Github and Bitbucket. Pygments included initial Haxe support back in 2010, but sadly is not complete. Haxers should have seen some broken highlighting like the following:

Poor old haxe syntax highlight in Github

Surely it is less than optimal, so I fixed it as the following:

Great new improved Haxe syntax highlighting

Looks nice? I also took the chance to include 100% Haxe 3 support (and still backward compatible for highlighting Haxe2 code), which includes Array/Map comprehension, import wildcard, macro-reification and even string interpolation! In fact I’ve tested ALL 1589 Haxe source files appeared in the source of Haxe, including the core std library of Haxe and its unit test files. So it is guaranteed to be as complete as possible, supporting all tiny Haxe features you may have never noticed (and I myself indeed learned a few tricks and even detected some typos in the Haxe std lib when running the test!).

I’ve made a pull request to Pygments, which hopefully they will merge it soon. But even when they’ve merged it, it will still take some time to let the Github guys updates their internal Pygments. But don’t be sad, the future is here: I created a Chrome extension, Pygmentx, that replace the Haxe codes on Github (and Gist) with the improved one. It only supports the normal file view at the moment, not diff view nor the previews on Gist user page at the moment. Btw, thanks Tong (a.k.a disktree) again for his chrome.extension Haxe externs ;)

 

Tags: ,