[erlang-in-lisp-devel] Erlang in Lisp

[Faré]

Dear Matt, dear Robert,

 LIST
 I propose we continue these conversations on the public mailing-list
 erlang-in-lisp-devel at common-lisp.net:
 http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel

 REPO
 OK, I pulled a copy of the git repo, and see you've been active
 importing stuff. I think that a shell script to checkout and/or update
 the existing code would have been better, but let's say what's there
 is good where it is. You may want to try the other approach for
 pulling the erlang sources, or the sources of other CL libraries we'll
 need: iolib and its dependencies, etc.

 PLANNING
 as far as google is concerned, we're still in a planning phase, not
 the mad coding phase yet, but "learn about what exists, learn about
 each other, draw a plan".

 FORK
 Since the first step is forking, you can see in philip-jose what I was
 thinking of regarding the fork thing -- grep for fork there, except
 that the code isn't very developed.

 The idea would be that there should be a DSL to express all the
 parameters that you may want to preserve or tweak when you fork:
 shuffling fd's, closing some, changing directory, dropping privileges,
 changing process group, and all kind of weird things. Then, either you
 exec as part of the same C call (so as to not risk any lisp runtime
 confusion because of GC or other interruptions), or you immediately do
 a lot of adjustments before/after you get back to the lisp side in the
 child: frob the fd streams, reset the thread/lock structures and/or if
 any (hopefully none), etc. See also how the lisp-based fork tries to
 GC before to fork if tight in memory.

 But for the very first step, I think that a portable run-program
 implementation based on a simple C fork with a trivial DSL for
 shuffling fd's would be a good first goal. We should be using iolib
 and synchronous wait for the process management, not signal handlers.
 Luigi said he had such an implementation - we may ask him about it, or
 start from the run-program present in an existing CL implementation
 (not SBCL or CMUCL - it's broken with broken signal handling race
 conditions).

 YOUR TURN
 sorry for my long silence. I was busy at work. I'll try to be on track
 now. Matt: what about posting regular updates on your blog and/or on
 this list?


 [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
 The Constitution may not be perfect, but it's a lot better than what we've got!





 2008/4/26 Matt Bone <thatmattbone at gmail.com>:


> I have my cl.net account and I created a git repository (empty at the
 >  moment).  I'll write this up, but for now we can:
 >  git clone http://common-lisp.net/project/erlang-in-lisp/git
 >
 >  and to push a patch:
 >  git push /project/erlang-in-lisp/public_html/git master
 >
 >  --matt
 >
 >
 >
 >  On Fri, Apr 25, 2008 at 6:01 PM, Faré <fahree at gmail.com> wrote:
 >  > Robert Virding was making lots of interesting suggestions as to which
 >  >  level of Erlang implementation we want so as to leverage as much as
 >  >  possible of the Erlang front-end and support. It looks like Core
 >  >  Erlang or Kernel Erlang would be most fit.
 >  >
 >  >  Drew: can you give an ETA for creating those common-lisp.net accounts,
 >  >  GIT repository and mailing-list? I suppose Robert should get an
 >  >  account, too.
 >  >
 >  >  Matt: can you download all relevant software/documents and make a list
 >  >  of URLs/checkout commands so everyone else can do it, too?
 >  >
 >  >  [ François-René ÐVB Rideau | Reflection&Cybernethics |
http://fare.tunes.org ]
 >  >  Most people think they need a ruler. Perhaps we should give them a fake
 >  >  one that doesn't actually do anything, and then they won't think about
 >  >  it. It is sort of like giving an infant a pacifier. -- Perry Metzger