August 2008 - erlang-in-lisp-devel@lists.common-lisp.net

[erlang-in-lisp-devel] git access
by Faré 15 Aug '08

15 Aug '08

Dear Matt, I wanted to git push a trivial patch, and found that 1- your instructions are slightly wrong. You say git push shell.common-lisp.net/project/erlang-in-lisp/git but it's actually git push USER@shell.common-lisp.net:/project/erlang-in-lisp/git 2- the git directory (and all the rest) has no group write permission, so only you can modify things. Can you chmod -R g+wX /project/erlang-in-lisp ? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Due to circumstances beyond your control, you are master of your fate and captain of your soul.

2 1

[erlang-in-lisp-devel] latest erlang-in-lisp
by Faré 15 Aug '08

15 Aug '08

After I go in the erlang-in-lisp/src/ directory, M-x slime-load-system erlang-in-lisp and (it.bese.fiveam:run!) I experience strange bugs: * multiple processes are running connected to the same fd used by SLIME, and SLIME gets confused the hell out of it. * one of the processes ends up at the ldb prompt because a GC invariant is lost (!), and at least one process isn't, which also confuses SLIME. * pstree -p shows 1 parent sbcl, 1 child sbcl, and four children {sbcl} whatever that means (threads?) * In case that's what happens, note that it is a very very bad idea to fork a process after you've started spawning threads, least you (and all the libraries you use -- good luck) take special measures with pthread_atfork(). * The 5am run wasn't very verbose (but had messages pasted in the mix possibly by children not heeding the redirection), and I couldn't find the dribble log (if any) so I don't know which test fails. Matt, can you advise? You may find help from people on irc #lisp, and/or me, etc. Otherwise, considering it's "pencil down" period, you should probably focus on fixing bugs and writing documentation. Thanks a lot! [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Arbitrary limits to programs are evil, particularly when they go either enforced or unenforced.

2 2

[erlang-in-lisp-devel] watching processes
by Faré 15 Aug '08

15 Aug '08

Some ideas to add to a TODO file for e-i-l. Watching other processes is hard to do reliably in Unix. If the processes are linked by parent/child relationships, then the parent can easily watch if children die with SIGCHLD (and *must* do it to avoid zombies) - but this is not general enough mechanism for e-i-l. Another option is to share a pipe with the other process before you even fork, and add the watching of it in your epoll loop, so you can say the process is dead when you get an EPOLLHUP. This depends on all the considered processes following the proper convention of sending around the fd to the pipe, and so is not applicable to watching arbitrary other processes, but may work. It might be possible to open an fd on some file in /proc/$pid and receive an event when the process dies. Or not. These solutions require experimentation, but have the advantage that they are not subject to the same race conditions as having to register with a central server after you've forked. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] It is a miracle that curiosity survives formal education. -- Albert Einstein

1 0

[erlang-in-lisp-devel] Funs
by Robert Virding 08 Aug '08

08 Aug '08

Hi sorry I have been a bit lazy here. I have been reading through what Matt Bone has written in is his blog and would like to comment. As his entries are a bit old I thought this might be a better way to get info to him. Correct me I am wrong here. First about how funs are implemented in the BEAM today. The compiler, in the v3_kernel module, breaks out funs into separate "normal" functions with the free variables added as explicit variables. In the kernel erlang format all functions are flat with unique variables and have proper atom names. For the fun functions the name is built up from the function in which the fun occurs and an fun index, something like '-foo/3-anonymous-3-'. The fun itself is basically a tuple containing the module name, the fun function name, and the actual values of the free variables. There is also a unique tag to make sure that you can only call a fun in the same module as it was defined. This is needed as funs functions are called by name. Note that there is no code in the fun, calling a fun needs the right module to be loaded and it has to be exactly the same version of the module. This can be difficult running distributed erlang. It also mans that funs are not realy safe over code loading as you can have a fun which points to a too old version of a module which has been purged. Funs were not part of the original language/implementation and added after the basic code handling had been defined. In this respect they don't really fit in as well as they could. I hope this may help a little. I will get back soon on signals and messages and how they interact. One thought on using the front-end of the existing Erlang compiler. Core erlang, which is generated by the v3_core module, is very lisp like. Most of it will directly translate to basic lisp except for patterns, and the try and catch constructions. One hint there is to look at my LFE where I go the opposite way and compile to core elang. The basic LFE forms are actually very close to core erlang and LFE try is handled the same as ERlang try and generates the same core code. Another thought might be to use kernel erlang instead as it is simpler and the pattern matching has been compiled out. Robert

1 0