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@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@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 |
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
erlang-in-lisp-devel@common-lisp.net
-
Faré