SAE doesn't work

Joe Armstrong <>
Fri Jun 25 21:46:56 CEST 2004

  I tried  (and failed) to ressurect  my old Stand  alone Erlang (SAE)
with R9C-2 ...

  Oh sad day (and rainy to boot - this is probably the worse summer
I can remember - it just rains all the time :<()

I ran into a weird  problem my system couldn't find erlang:open_port/2
- now there *used*  to be a module erl_open_port.erl  and some yuck in
erlang.erl that did the deed.  What has happened to all of this?  Also
I note the appearence  of erlang:blocking_read_file/1 is this now here
to stay?  ((don't even think about calling this unless you are writing
a low-level boot loader for Erlang itself ...))

  <<waving arms around mode on>>

  IMHO the Erlang start-up procedure is getting more and more
complex. A simpler method goes something like this.

			    - O -
   ((thinking out loud))

   Make a tuple {Mod, Func, Args, [{Mod,Code}}]
   [{Mod,Code}] is a list of {Module, CompiledObjectCode} tuples
   store this in a file. "boot.img"

   To start the system. Run the (precompiled) code in ring0.erl
   (this might define run() as ...)

   run() ->
      Bin = erlang:blocking_read_file("boot.img"),
      T = binary_to_term(Bin),

   cold_start({Mod, Func, Args, Mods}) ->
      (catch apply(Mod, Func, Args)),

   load_mods([{Mod,Code}|T]) ->
      case erlang:load_module(Mod, Code) of
        {module,Mod} ->
        Other ->
            %% erlang:display({bad_module,Mod}),
   load_mods([]) ->

  IMHO the start-up  procedure can be greatly simplified  if we assume
the following:

   There are certain BIFs (like blocking_read_file/1, get_env/1 ...
   that are *only* to be used when booting the system and *before*
   normal user-level processes are run.

   These bifs should allow the user to write erlang code to set up all
emulator flags etc. ((all the "funny" flags to Erlang))

   When the system is "up and running" all I/O etc will be
non-blocking but getting there can use blocking calls etc.



More information about the erlang-questions mailing list