THIS BLOG HAS BEEN MOVED TO ncannasse.fr, please update your bookmarks !

ScreenWeaver HX

posted on 2006-06-11

Yesterday was released the first Beta version of ScreenWeaver HX. SWHX is a simple and powerful way to create Flash Desktop Applications.

For several months, I could see growing interest for Rich Desktop Applications using Flash as the UI. There were several popular projects already, like Zinc and the original ScreenWeaver, but most of them were just giving access to a fixed number of system features, and it was either not possible or not easy to add DLLs to get more features.

When working on haXe Remoting, I could experiment with the new Flash8 ExternalInterface API that enables communications between Flash and Javascript in the Browser. There are some major problems with ExternalInterface and I agree with the author : ExternalInterface is broken for an out-of-the-box usage. That’s why an additional serialization layer is needed to bypass the EI quirks. In both haXe Remoting and SWHX, we’re using some haXe serialization to only pass strings between the two sides of the EI, which is greatly simplify everything.

In particular, it means that we didn’t have to implement all the XPCOM stuff in SWHX. This resulted in less code, optimized for a particular usage. It of course somehow “force” the user to use haXe Remoting to communicate between the System and Flash layers, but that’s actually better since a lot more stable than “plain old” External Interface.

By the end of April I contacted Edwin van Rijkom which I have been meeting already at Spark Europe. He is the author of Screenweaver so already knew very well about the technology needed for previously called haxeDesktop project. He was very enthousiast from the beginning and started writing most of the code by himself, with crossplatformability in mind. I was very busy at this moment so not really helpful. During theses important first weeks, Edwin really did great work.

Once most was done, it was time to start interacting with the System/Neko Layer. Edwin started working on it but it was more my speciality so I took over the task. Two big changes occured at this time. The first was to change from an EXE-centric model were SWHX itself was loading the Neko code to an SWHX DLL that was used just like any other Neko library. This is important since it means that you can use SWHX like any other Neko library from any Neko supported language. Also, it gave back the control of the whole API to the haXe/Neko layer which was better. The other change was to turn all the C++ code into plain C code, which was better to interact with the Neko C FFI which is more C-oriented.

Once the new architecture ready, I started integrating the code Edwin wrote which was fairly simple since most of the testing was already done. One of the nice ideas was to let handle the getURL calls by the Neko Layer. This way, while there is a default behavior which is to either load a local file or fetch an URL content, the SWHX user can override this behavior and handle its own file loading, access permissions and hard drive caching mecanisms.

One last issue was the Flash Player integration. SWHX requires the Firefox Flash Plugin to be available. That’s problematic since the Player is not redistributable. There is a form to ask for permission but in practice only a few companies have been granted this usage and Adobe (formely Macromedia) has always been pretty evasive regarding this issue. Our way to deal with that is pretty simple : if the DLL is not found, download the Player archive from Adobe website, unzip it to extract the DLL and save it into the current directory. This behavior is optional and customizable by the SWHX user but for the Application end-user it’s completely transparent and will only notice a small lag when starting the Application for the first time.

SHWX is currently working on Windows and Edwin will finalize the Mac port as soon as he come back from his merited hollidays. As for Linux, there are two important things to deal with :

  1. port the “system.c” which is just an interface for creating a window and handling some OS-specific stuff. It’s only a few Ko of sources so it should be quick. Once done it means you can display the player.
  2. the biggest problem is that since there is no FP8 for Linux it means no ExternalInterface and then no synchronous communications between the System and Flash layer. A first solution can be to have at least async communications by using FSCommand, then later maybe find a “hack” to enable synchronized communications on FP7 (we have some ideas but nothing done).

In only one-month-and-half since the project started, we could provide a great tool for all Flash and haXe users. I would like especially to thanks Edwin since nothing would have been possible without him.

haXe 1.0 Release Canditate

posted on 2006-05-02

haXe RC1 is now available from http://haxe.org. After several Beta, I could at last put everything I wanted for 1.0 and this is a prerelease that should satisfy most of users wishes. The new things includes :

  • regular expressions (not yet supported in Flash, since there is no native support a haXe RE engine need to be written)
  • server-side Socket API, to create multiuser server in pure haXe code.
  • serialization : using a pure haXe serializer that can send classes instances and enums as well
  • remoting : kind of RPC between different haXe platforms, enable transparent communications between Flash/JavaScript and the Server.
  • a template system for server-side generated pages
  • the SPOD system for binding objects to database tables
  • and a lot of other things…

[EDIT : haXe 1.0 has been released]

AS3 & Our Future

posted on 2006-04-24

This is the reply I made to a post on the OSFlash list, talking about ActionScript3, MTASC, and haXe.
You can watch the original thread here.

——

> Hi, Flash 9 (better known as Flash 8.5) was announced. I’m wondering on
> how we could compile AS3 with and open source/free environment like MTASC.
>
> Nicolas Canesse has announced to not continue the development of MTASC,
> so it won’t have AS3 support.
>
> Now, i think it’s time to find a way to do that…

IMHO, there is no hurry.

AS3/Flash 8.5 has been in Beta for a while now. I don’t know when Flex2 will ship and the 8.5 player will be officialy released, but at this time I will work seriously on adding 8.5 Player support to haXe if it’s not done yet.

Before that, while I think it’s great to experiment with AS3 and new 8.5 Features, I don’t think it’s proper for full-scale development yet. At least in my company case, we need the player to be available on our clients computer, and that’s not the case for 8.5 Player.

We actually started using Flash 8 a few months ago. It’s pretty easy to go from Flash 7 to Flash 8 since there is only additional features that will simply not work when used with Flash 7 player. In the first time, it was then possible to add some eye-candy F8 effects to our games by keeping the game F7 compatible. Only recently we are asking our users to upgrade their player to Flash 8.

This kind of smooth transition can’t work with Flash 8.5. It’s a new language, a new API, and a new virtual machine. You need then to rewrite everything from scratch, by porting your code, which can be painful in some cases.

Also, remember that what drives Player adoption the most are the websites asking the users to upgrade their Player. We could see a great adoption curve for Flash 8. That’s IMHO thanks to the fact that the new features could be used and enjoyed by all kind of Flash users : designers and programmers.

That might not be the case for Flash 8.5 . I guess it will first be released with Flex 2 for building Rich Internet Applications and then only later Flash 9 - which will still keep Flash <= 8 compatibility. The current AS3 enthousiasts are mostly coders that can see the value of additional VM speed and features. Since they will not be 8.5-capable IDE before Flash 9, I expect the 8.5 player usage - and then adoption - to be a lot slower.

My conclusion is that while AS3 is hot and you can start playing with it right now, companies should carefuly plan their AS3 usage and try to walk the smooth transition line, when that makes sense of course.

That’s where haXe strategy makes sense. First, it provides a programming language a lot better than AS3 (or else I wouldn’t have done it), that can you can use right now in production as an AS2 replacement since it can target Flash Player 6-7-8.

And when haXe Flash Player 8.5 support will be added (don’t worry about it, it’s not that difficult to do), you can slowly migrate your classes, and keep most of your codebase unchanged since haXe is crossplatform. For the places where you are using some Flash API that will have changed between 8 and 8.5 you can use haXe conditional compilation for example :


#if flash9
...
#else flash8
...
#else flash7
...
#end

I guess there will be also some kind of API-wrappers in haXe to be able to ease this kind of changes.

Additionally, you can use haXe to write your Javascript/AJAX code and/or your Server-side code (replacing PHP and the likes).

If you want to know where I see "our future", I can see it right now there : http://haxe.org :)

Nicolas

haXe Beta 4

posted on 2006-04-02

haXe Beta 4 has just been released on haXe.org. It is pretty stable right now but still missing some standard libraries such as Regular Expressions, haXe Remoting, etc… I’m also not so much satisfied with current JavaScript standard lib. While it provides some typed access to HTML DOM, it doesn’t handle seamlessly browser differences. Some work would be needed to try to rebuild a browser-abtract JS API by using the appropriate implementation and ensuring consistency.

I guess there is some JS frameworks that already do that. I should have a look at try to make one of them available from haXe.

haXe Polymorphism and Variance

posted on 2006-03-27

I hacked a pretty interesting software on Friday, using haXe. The things I wanted to do were not so easy, and involved both ML-style-polymorphism and variance, two features that haXe don’t have right now but that can somehow be emulated using current type system.

Polymorphism : in ML, polymorphism enables you to write some code that will work for different kind of types. For example the following haXe function is building an array-pair from two values :

function pair(a,b) {
    return [a,b];
}

In ML, that would give a polymorphic type “'a -> 'a -> 'a array” that would bind the types of the two values to the type of the array. Then for each usage of pair, the first argument will be enough to guess the type of the second argument and the return array type.

In haXe, there is no per-function polymorphism. So-called type parameters can only be in classes, that’s per-class polymorphism. If then you want to emulate polymorphism in haXe, you can use static functions with type annotations :

class Pair<T> {
    public function make(a : T, b : T) : Array<T> {
         return [a,b];
    }
}

Please note that in that case specifying the return type Array<T> is not mandatory since it will be inferred from a and b types. OTOH, the parameters types are mandatory because if there is no type specified the Pair.make type will be monomorphic (it will use haXe type Unknown) and then its first usage will set its type definitly, while we want each usage to be valid for a given type.

This now works, you can write Pair.make("hello","world!") and Pair.make(0,1) and they both get accepted by the typechecker. Pair.make("hello",0) get rejected, saying that the Int 0 is not a String. Since everytime we’re accessing the Pair class the type T becomes a monomorph, everything is working accordingly.

As a side note, this creates a type-hole when you have a contraint on the type T (like T extends String) since the constraint is lost when monomorphizing T. In that case the typechecker should enforce that the user is giving the full type before accessing to any method/field. There is also another type-hole when type parameters are used in static variables. I need to fix that also, but that’s of course weird usages already.

Variance : when dealing with type parameters, you will soon hit in the Variance problem. It can simply be stated as the following : if B extends A, given a class C<T>, does C<B> extends C<A> (covariance) ? the contrary (contravariance) ? or not at all ? (invariance)

In haXe there is right now no variance, all type parameters are considered invariant. It’s actually a bit difficult to implement, I gave it two tries on Friday but wasn’t satisfied with the way code was heading so I dropped the changes. Some people might thing that all types are always covariant, since it seems pretty much logical at first sight, let’s give some examples and counter-examples :

The following class type-parameter is covariant :

class C<T> {
    var x : T;
}

This is the case for most of the classes that are only “storing” some values.

OTOH, the following class type-parameter is contravariant :

class C<T> {
    public function f( x : T )  : Void {
    }
}

Why ? Because a Function that needs a B as argument can’t take a A, while the other-way is true (assuming that B extends A). We have then C<A> "extends" C<B>, the subtyping relationship is reversed.

Here’s then an invariant class, easily obtained by mixing one contravariant and one covariant case :

class C<T> {
   public function f( x : T )  : T {
      // ....
   }
}

In that case B -> B is not a subtype of A -> A, and the other way is not true either.

Modelizing Covariance in haXe is a bit tricky, and needs to use type-parameters and creates classes instances only for the sake of type-correctness, but it works pretty well. It’s an interesting exercice if you like this kind of things, but I won’t put an answer there since it’s not so much beautiful and might not be 100% correct since some type-holes still exists (see the previous note).

The best would be to allow variance notation on type parameters (like OCaml +/-) but that’s a bit tricky, I need to think more about which data structure model would be the best fitted for integration inside the haXe compiler.