Open Beta for Sinan

So we have moved right along and we are very close to release. Before we do a general release we decided to do something of a small beta. We are trying to get together a group of solid people who know Erlang that are interested in using the system. They shouldn't mind going to a bit of extra trouble to provide us with useful information. They also need to be able to put up with potential issues that might arise from using the new build system. If you want to participate either post a comment to this blog letting me know or send an email to me or Martin Logan. You can find both of our email addresses in the erlang-questions archives. Once you do that we will provide you with some nice tarballs and pointers to the documentation.

Windows Support

So far support for Windows has been, at most, an after thought for me. I own only one rather old windows box that I use for the occasional gaming. For that reason, windows just isn't a big priority. However, after a discussion with Martin Logan we came to the conclusion that sinan will need to support windows from the initial release. Fortunately, I have used the filename and filelib modules through out the implementation. That should remove any path name issues between the two systems. Unfortunately, I use symlinks pretty heavily through out the build. I have also used two very unix specific os commands as part of development, uname and tar. At first I thought that replacing these commands would pose a big problem. That proves not to be the case as the stdlib and kernel applications provide for my needs, though that functionality is pretty well hidden.

To figure out what platform and architecture I am on I use uname. I need this to pull down the correct version of binary dependencies from the repository. I didn't see any real solution to replace this command. I finally ran across a reference to erlang:system_info(system_architecture). This should solve my needs pretty well. Unfortunately, it only works in R9 and above. So, as you would expect, its a trade off. If I use this I can make the system work in windows but not in pre R9 systems. I think the right choice is to make it work in windows. Hopefully a pre R9 solution will present itself.

I also thought tar would present more of a problem as tar isn't a windows command. There is an erl_tar module in stdlib but it claims to support only Sun's version of tar. However, on examination of the docs for both erl_tar and gnutar this seems not to be the case. The format followed by erl_tar is IEEE Std 1003.1. This is an extended version of tar called ustar and its a POSIX standard. It seems that modern versions of gnutar support IEEE Std 1003.1 as well, as you can see here (check the references at the bottom of the page). So the erlang docs seem either in accurate or out of date, fortunately for me.

Symlinks are a bit of a harder problem. The need for symlinks is greatly reduced now that I don't have to build up tar-able structures. However, I still use them to build up a deployable version of the OTP apps with sources in the _build directory. I think that the only solution to this problem is to copy the sources and related files into the binary structures instead of symlinking them in. It will add a bit of overhead but I think thats worth it.

I do have one final problem, this one just occurred to me. I have written a nice little shell script to kick off a build. This shell script uses a bit of magic (borrowed from firefox) to follow any symlinks back to its deployed area where it gathers the paths for sinan. It then kicks off erl with all the proper paths to the sinan code. Not being a windows person I have no idea how to handle this on windows boxes. Hopefully, some erlang oriented windows guy will step forward and help me out with this.

Sinan Documentation

The documentation for Sinan goes apace. I have finished all of the user level documentation and have started the developer documentation.

Why worry about developer documentation? Sinan is a very pluggable system. Most of the current functionality that ships with the system is composed of tasks that are plugged into the engine. Third party tasks will use the exact same mechanism and be first class parts of the system right along with them. I think this is pretty darn important and I want to support it right out of the box. Thats why I am spending a bit of extra time and getting the developer documentation out with the user docs.

Code Complete!

I finished up the last few tasks over the weekend. This means that all the coding is pretty complete at this point. I still need to document the internals a bit more, so third party tasks can be written. I also need to spend some time writing high level user documentation so getting up to speed on the system is strait forward. All this will all probably take me a week or so. Hopefully, I can then do a true release.

On a side note, one of the things that I ended up doing was adding code coverage metrics to the unit test running. The cover module made this possible. Unfortunately, it only provides the number of runs for each line of executable code without any information about global coverage percentages. When I get some time I am going to poke around in system and see if I can come up with a way to get the executable line count from a module. If I can get that information then providing high level project statistics wont be so bad.