Starting Erlang

Joe Armstrong joe@REDACTED
Wed Apr 24 14:50:01 CEST 2002


    I am working on a new stand-alone Erlang - this time I want to
do it properly....

    So far I have manged to build windows .exe files in a pure Erlang
environment (which means you can build your windows .exe files on
linux and then run them on windows).

    I am now turning my attention to the Erlang start sequence itself.


	Does *anybody* understand (I mean *really* understand the
Erlang start-boot sequence). Is all this junk in the .script files
really necessary.

	Do you think there would be any objections if I reworked it all?

	Does anybody write their own .script files and make their own
home rolled .boot files? - If so please mail me privatly.

	I currently imagine distributing applications something like this:

	1) You install "Erlang" (one dll or so) (I hope)
	   and erlRun (an executable to lauch Erlang)

	2) An application is (usually) three files.

	   foo.bat  (windows launcher)   (unix launcher)
	   foo.ear  (Erlang archive)

  and would be one liners
           containing just

	   erlRun foo.ear -s Mod Func Arg1 Arg2 ... ArgN

	   foo.ear is assumed to be a Mod x Code archive -
	   The code in this is loaded (lazily)

	   Evaluating the command line: ExtraArg1, ExtraArg2, ...

	   Would just do

	   apply(Mod, Func, [Arg1, .. ArgN], [ExtraArg1, .., ExtraArgN])

	   that's it.

           For those of you who want the "old style" behaviour all the
	   things that are done inside the .script files and in init.erl
	   and kernel.erl can be safely hidden away inside one of the start
	   up modules.

        3) the new erlRun command would (probably)
	   have many extra args, so you could say

	   > erlRun F1.ear F2.ear URL , .....

	   To allow multiple archives and loading off URI's etc.

	4) The program epack would make a single file executable
	   from a .bat or .sh file

	   > epack Foo.bat

	   would create Foo.exe for windows (with *everything* packed
           into one file)

	   > epack
	   would do the same for unixes

	I also feel it is high time to revamp code loading. code.erl
is a total mess - IMHO we sould only retain the few calls that people
actually make and add support so we can code load off URLs and .ear

        Will this worry anybody?

More information about the erlang-questions mailing list