[erlang-questions] Stand Alone Erlang Still Updated?

Peter K Chan peter@REDACTED
Tue Jul 31 23:48:47 CEST 2007

I understand how a fully packaged executable could be difficult to do
hot code replacement and updates.

It may be an issue of deployment scenario. If I am deploying on the
server, I value hot code replacement, but if I am deploying on client
side, I value compactness.

I personally think that for a client side deployment with no need to do
hot code replacement or package updates, something like the
RubyScript2Exe would be perfect (for me, anyway).


(Note: originally message was mistakenly sent only to Chris. I included
the list in this message).

-----Original Message-----
From: Chris Curtis [mailto:Chris.Curtis@REDACTED] 
Sent: Tuesday, July 31, 2007 8:22 AM
To: Peter K Chan; erlang-questions@REDACTED
Subject: RE: [erlang-questions] Stand Alone Erlang Still Updated?

Peter Chan wrote:
> I would put my vote in a native executable too. CEAN is very nice for
> managing all the dependencies, but when deployed to the target system,
> it is still a big pile of directories.

> I took the earlier suggestion and looked at Wings3D, and I really like
> how minimal and straightforward the Wings3D distribution is. CEAN is
> great for package management, but the myriad files are still confusing
> me, who is a novice.

> Looking at it, SAE would seems to be the ideal deployment form. It
> be nice to see SAE updated for current Erlang, or somehow be able to
> compile a CEAN to a SAE (with only a .exe, a few .dll, and a .zip). 

Yep, that's pretty much what I'm hoping for. A comparable model (sort
of) comes from the Ruby world... Ruby Gems are kind of like CEAN, and
there's a tool RubyScript2Exe that can generate the executable and
associated support files. [I haven't personally used this, just know it

Another, slightly-different model is from the Lisp world, where (for
example) SBCL has (sb-ext:save-lisp-and-die ... :executable t ...) that
saves things as they are.

OTOH, dealing with updates and hot code replacement may be a much larger
problem without a "pile of directories and BEAM files".

I also need to go back and look at the Wings3D code... it's been a while
since I poked at it.

The end goal, as I see it, is the ability to produce a complete
installable application that can be dealt with by a normal consumer-type


More information about the erlang-questions mailing list