sofaware - software from a sofa.

Playing some more…

So, in my last post I showed how easy it was (or at least will be) to use SWF/SWC libraries in haXe. And this time I just wanted to quickly demonstrate that not only can you use the libraries, but you can just as easy extend them without much hassle!

So, once again I’ll be using minimalcomps as an example because I needed to have a sortable and editable version of the List component.

So what I did was:

1. Extend the List component to become a SortableList.
2. Extend the ListItem component to become an EditableListItem.

And I’m just surprised how problem free this was, at least as long as I don’t need to override any getters or setters. And I can even statically type the list items!

Instead of having all the code embedded (as there’s a few classes) you may find my example here as gist. Hopefully one day github will accept haXe as a language that should be color coded as well…

Playing with some haXe updates.

I know this isn’t official yet, but I’m just excited about the changes to come in haXe.

The last couple of days Nicolas committed some interesting updates to the SWF linker. This is the first steps to the upcoming SWC input support.

So, I had to give it a go, and since I’m a fan of Keiths minimalcomps library, I thought it would make a perfect example.

The first obstacle though was that the updates included changes in the dependency libraries for haXe, so first I had to update rewrite my Homebrew Formula to use official repositories for the dependencies so it’ll be prepared for further updates in the long run. It took me a while, and the formula still need some cleanup, but it works rather well by now, hurrah!

And the next step was to follow the instructions of Nicolas email to use a SWC library:

1. We need to use the SVN version of haXe, which fortunately is very easy to do with homebrew:

   # brew install haxe --HEAD
   

   or, if you prefer, the official way:

   # wget http://haxe.org/file/install.ml && ocaml install.ml
   

2. I’m making a little test project:

   # mkdir sofaware
   # cd sofaware
   

3. Get the SWC you want:

   # wget http://minimalcomps.googlecode.com/files/MinimalComps_0_102.swc
   

4. Extract the SWC (it’s really only a zipped file) and rename it (library.swf is a bit too generic for my tastes):

   # unzip MinimalComps_0_102.swc
   # mv library.swf minimalcomps-0.102.swf
   

5. Create our test file, Comps.hx:

   # mate Comps.hx
   

   Paste in our little “Hello Keith”-example:

   class Comps extends flash.display.Sprite {  
       public function new() {
           super();
           new com.bit101.components.PushButton(this,0,0,"Hello Keith!",function(e){
               trace( "Hello there!" );
           });
       }
   
       static function main() {
           flash.Lib.current.stage.align = flash.display.StageAlign.TOP_LEFT;
           flash.Lib.current.stage.scaleMode = flash.display.StageScaleMode.NO_SCALE;
           var c = new Comps();
           flash.Lib.current.addChild( c );
       }
   }
   

6. Compile it and see it in all it’s linked library glory!

   # haxe -main Comps -swf comps.swf -swf-version 10 -swf-lib minimalcomps-0.102.swf
   # open comps.swf
   

Now that was quite easy, right? And I presume that soon it will be even easier as the SWC will be able to be linked directly. But why not enjoy the upcoming fruits of haXe already? Well, one reason might be file size as it currently links everything even if it’s not used or imported which is something that will be fixed when this feature finally arrives.

Homebrew is the new macports

Yeah, you heard me! I’ve made the switch and so should you! Or, you don’t have to, but it is a really sweet and simple solution for dealing with packages for Mac OS X.

So of course I’ve rewritten the haxe/neko port to a Homebrew formula! Unfortunately, until they’ve added it to the official repository you’ll gonna have to go through some extra steps to get haxe and neko using brew install haxe:

1. Install homebrew using the instructions here (unless you have already): http://github.com/mxcl/homebrew/

2. Install git (no need if you already had it installed):

   # brew install git

3. cd into the directory where you installed homebrew:

   # cd `brew --prefix`

4. Pull in my github fork:

   # git remote add slaskis git://github.com/slaskis/homebrew.git
   # git pull slaskis master

5. Install haxe (it will install neko as well as it’s a dependency):

   # brew install haxe

   or (if you want to use the latest source from the svn trunk)

   # brew install haxe --HEAD

6. Follow the instructions from the install to get haxelib working properly.

By the way, I’ve only really tested this on OS X 10.6 so let me know if it’s working on 10.5 as well!

If you vote for the formula it might be accepted a bit faster.

Minimal Comps

I just pushed up a haXe port of Keiths excellent minimalcomps library.

It was a bit tricky to port, even though most of the hard work was done by the as3tohaxe tool I had to rewrite it from using inheritence (i.e. extending flash.display.Sprite) to using composition (i.e. wrap a flash.display.Sprite object and repoint all the methods to it) as haXe doesn’t like the getters and setters that AS3 (and the Flash Player) uses. Or rather, it doesn’t like to override them as getters and setters behave very differently in haXe. It does give some unexpected features (bugs some might call them, see the “known issues” below) but generally it works quite well.

Another issue I’ve come across while doing this is that when I want to use the components in a project I now have to add the font which is required by minimalcomps to it, and if I want to add other swf-based assets I would have to merge the minimalcomps-font into it. So it’s a bit of extra work which could be avoided if the resource management of flash9+ based targets could be fixed.

But as long as it’s a simple project with no other assets it’s really as simple as adding these two lines to the hxml:

-lib minimalcomps
-swf-lib font/pf_ronda_seven.swf

And then you can use it like this:

var vbox = new minimalcomps.VBox( this );
new minimalcomps.HUISlider( vbox , 0 , 0 , "Slide this!" );
new minimalcomps.HUISlider( vbox , 0 , 0 , "And that!" );

And you’ll get this!

Known Issues:

• VBox won’t position Knob and InputText properly
• ColorChooser doesn’t position it’s popup correctly
• Event targets isn’t the object but the _comp
• “-swf-lib font/pf_ronda_seven.swf” must be added when compiling

TODO

• Fix the known issues (duh!).
• Add the missing components (last I checked the FPSMeter was added since my port).
• Generate some docs would be nice.
• Add it to haxelib as soon as I figure out what my password was (if anyone who can reset it reads this, please do!)

The macports go snow leopard.

Now that I updated to Mac OS X 10.6 (Snow Leopard) I cleared out all my ports (to update them to 64-bit) and noticed that the neko port didn’t compile anymore (and consequently haxe as well).

So after plenty of debugging, recompiling and asking stupid questions on #macports I got it up and running again. And this time I fixed a bug in the compiled libneko.dylib library that I noticed while creating the ehx executable (which I’ll do a little writeup on soon, I actually have it working now) - it was pointing to the wrong library path. And I also rewrote the Portfile entirely for haxe so it now doesn’t do any Makefile hacking so using the official repositories should work fine now.

Now go update your ports as I need to know if I broke it for <10.6!

Instructions can be found in my previous ports-post

Trust your flash.

Have you ever wanted to just quickly try your flash app which communicates outside of itself, either through sockets or http, without resorting to using a webserver?

Here’s a nice little line of bash which does that for you from the terminal: Adding the current working directory as a trusted one. And then you just need to restart your flash player and you’re go!

http://gist.github.com/160685

Updated the haxe & neko macports

Finally got around to update the haxe and neko ports to the latest versions (neko 1.8.1 and haxe 2.0.4).

Actually I got some issues while doing it as I wanted to change the current structure of the neko library to match the proposed structure of the other ports (instead of keeping all files in /opt/local/bin I wanted the libneko.dylib to stay in /opt/local/lib like all the other little .dylibs and such) which took some research as I didn’t previously know how dynamic libraries are linked.

And I also skipped the whole git repository hack for haxe and instead just retrieved the latest versions and packaged them into a nice little tar instead.

Besides that I’m also using unmodified sources this time, as the previous Mac OS X issues has been patched now (thanks Nicolas!). This means that the step to using the CVS sources instead should be rather easy whenever this has been tested a bit.

So, if you already fetched my private little ports repository you should only have to do a git pull and you’re up-to-date and should just have to run sudo port update (I haven’t tested this though as I removed the old one while modifying my portfiles). But if you’re new to this, here’s some quick instructions (and here’s the real instructions):

Note: This example assumes that:

• You’ll keep your repository in your user directory, also known as “~”.
• You’re using the default macports prefix, “/opt/local”
• And, there’s no previous neko or haxe installations as they might cause some conflicts (simply remove them if there are)

1. Start a terminal session and navigate to your home dir:
   cd ~
2. Fetch a clone of the ports repository:
   git clone git://github.com/slaskis/ports.git
3. Edit the macports sources.conf:
   pico /opt/local/etc/macports/sources.conf
4. Add this line anywhere above the previous “rsync:…”-line (but substitute {username} with your actual user name):
   file:///Users/{username}/ports [nosync]
5. Install haxe and neko:
   sudo port install haxe
6. Follow the instructions after the installs. It’ll be instructions from both the neko install and haxe install, so don’t miss them or it’ll have problems finding the tools.
7. (optional) Install hxcpp and enjoy the fresh fruits of 2.0.4!
   haxelib install hxcpp

And don’t forget to read why you should actually install this in the first place:

• What’s new in 2.0.4? (by Nicolas Cannasse)
• Get started with iPhone and haxe. (by Hugh Sanderson)

What’s missing in the neko port right now is mod_neko and mod_tora apache support (besides other useful libraries, like postgresql perhaps?), I havn’t needed these myself yet, but feel free to fork my repository and help out!

format.jpg.Writer finished!

I’ve finally completed the JPEG Writer for the hxformat library. After the initial port from an “optimized” as3 JPG Encoder class it was a lot of time spent in comparing the output from the format.jpg.Writer to the as3 results.

The biggest challenge I guess was that, since the hxformat library is aiming to be cross target (i.e. should be usable in neko, php, FP10, FP8, javascript and cpp), I could not just port it straight up as I couldn’t rely on the flash specific bitmapData.getPixel methods etc. Instead I’ve kept the target specific code inside a format.jpg.Tools class, so to use the library in a SWF target it would look like this:

var o = new haxe.io.BytesOutput();
var w = new format.jpg.Writer( o );
w.write( format.jpg.Tools.fromBitmapData( bmp ) );
// Now we have a jpg stream in "o".

And similarly (assuming we’ve made a javascript friendly format.jpg.Tools already, which I haven’t yet) it would look like this in a JS target:

var o = new haxe.io.BytesOutput();
var w = new format.jpg.Writer( o );
w.write( format.jpg.Tools.fromCanvas( js.Lib.document.getElementById( "image" ) ) );
// Now we have a jpg stream in "o".

The idea is that the format.jpg.Tools.from* methods should create a format.jpg.Data typedef which then may be passed into the format.jpg.Writer#write method.

Creating that typedef could off course also be done manually, but I’m a fan of convenience methods :) And also, the methods should off course be optimized for the target, so in a FP8 target we’d use a loop with bmp.getPixel to extract the pixel stream, while in FP9+ we just use bmp.getPixels instead.

I also did a version using linked lists instead of Arrays (or Vectors if it’s FP10), but I didn’t see a bit improvement and it was a lot messier so I decided to keep the Array version.

I’m hoping someone could help me optimize it even further, maybe using the flash.Memory feature of FP10 or some other clever optimizations. I’m currently down to about 6 seconds on my brand new Macbook Pro on a 2880x2880 px image, the same one as used in the optimized version at ByteArray.org, which takes about 3.5 seconds(!). I really hope we can make the hxformat version comparable, if not even faster, in the end. I’ve given it my best so far, getting it down from a timeout (>15 seconds) to 6 seconds.

I was stuck for a while when the finished image did not look at all like the original, it was black almost entirely. The problem was, I realized after way to many attempts, that the source image was transparent (mostly) and transparent pixels was converted to black ones, DOH!

So, you can find the source code here, I haven’t added any tests for it in the library though, but the lines above should be enough to get started :) It’s the exact same syntax if you want to try out the PNG or BMP Writer/Reader, except another package.

If you want to help out you can either:

• Try it out with different images and see if it gives proper results, and if you can open it in your favorite application.
• Make it faster! Find anywhere that we can optimize?
• Write “tools” for javascript/canvas and other targets, although the neash project might make the current fromBitmapData work for most targets already?
• I’m pondering the possibility to use the previous format.tools.Huffman class to compute those huffman tables instead and wouldn’t mind some input on that.
• Get your hands real dirty and write the format.jpg.Reader class ;) Perhaps the tables used in the format.jpg.Writer should be extracted to be used in the Reader as well?
• Another thing I’m planning to add to the image formats (especially jpg as it’s so slow) is asynchronous writing. This would probably not be used in targets like neko or cpp, what do you think?

haxe & neko for macports

Yay! I finally got the haXe and neko ports to compile properly, it took a while as I had to learn how Makefiles and Portfiles work (besides how to compile C and neko).

First, I’ve set up my own forks of both haXe and neko at github.com as it’s easier for me to modify and share with others, they’re updated from the official repositories regularly. And then I got neko to actually compile on Mac by modifying some parts of the source code. Then after alot of time spent on reading the MacPorts guide book I finally got a working Portfile for downloading (from github), patching the Makefile, compiling and finally installing the neko binaries into the MacPorts directories. This wasn’t so easy as I had alot of troubles getting the binaries to find the libraries afterwards.

After getting this far it was a lot easier as I understood how it all came together, so modifying the Makefile for haXe was much less work, and the only thing I had problems with was getting it to play nicely with the environment variables set for neko so it could compile the haxelib and haxedoc tools that comes with it (but I got it to work thanks to some people at the MacPorts irc channel).

Actually, I did one nice hacky solution to get the downloading for the haXe port to work properly: I created an extra git repository which submoduled the other repositories needed to compile haXe (haxe, neko and ocaml). It works like a charm though.

So you’d like to try it out you just need to clone my ports repository. And to use a local repository you just point to the repository in the sources.conf (usually found in /opt/local/etc/macports/). And then you just run “sudo port install haxe” and both of them should be compiled and installed (as neko is a dependency). Just remember to first uninstall haXe and neko (by removing the haXe and neko related files in /usr/lib and /usr/bin) in case you have an old version or you’ll get funny errors. Oh, and don’t forget to follow the instructions after the installation or you’ll get some errors when it won’t find the libraries. Apparently it’s the recommended way of setting environment variables with macports; telling the user to do it themselves.

These will be fixed some more, to preferably use the official sources on CVS, and if Nicolas and the others approves I might actually submit it to the official MacPorts repository eventually.