From rvirding at gmail.com Fri Aug 8 00:56:22 2008 From: rvirding at gmail.com (Robert Virding) Date: Fri, 8 Aug 2008 02:56:22 +0200 Subject: [erlang-in-lisp-devel] Funs Message-ID: <3dbc6d1c0808071756g139b77c1qc91a03c2de8e2735@mail.gmail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fahree at gmail.com Wed Aug 13 04:01:16 2008 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Wed, 13 Aug 2008 00:01:16 -0400 Subject: [erlang-in-lisp-devel] latest erlang-in-lisp Message-ID: <653bea160808122101u3373ff75k126edb9b0b867ea9@mail.gmail.com> 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. From thatmattbone at gmail.com Thu Aug 14 20:29:51 2008 From: thatmattbone at gmail.com (Matt Bone) Date: Thu, 14 Aug 2008 16:29:51 -0400 Subject: [erlang-in-lisp-devel] latest erlang-in-lisp In-Reply-To: <653bea160808122101u3373ff75k126edb9b0b867ea9@mail.gmail.com> References: <653bea160808122101u3373ff75k126edb9b0b867ea9@mail.gmail.com> Message-ID: Sorry for the delay. I believe I fixed the issues we were discussing via IM (so now the process mailboxes are a bit cleaner using the norvig-style queue implementation as opposed to consing like crazy (there is one spot for improvement, but I'll fix that soon)). All the tests that should pass, do indeed pass (there's a stupid bug in two of the actual tests that I need to fix). As far as slime goes, I've been having strange problems for the past week or so (I'm not trying to pass the buck here, but I haven't experienced any troubles all summer). I would say last week mid week, I updated my copy of slime and it wouldn't start with complaints about the sbcl threads. Others had a similar problem (I wasn't getting complaints in the REPL, but on startup): http://thread.gmane.org/gmane.lisp.slime.devel/7529 This morning I had some troubles again (I forget what it was) and updated my copy...right this second I can't actually do a slime-load-system without sbcl going bonkers and chewing up 100% of the cpu time. It ties up emacs and I can't even get to *slime-events* to see what's going wrong. I should probably just back off my copy of slime. My code is not mixing threads/processes at the moment, so maybe that is a fiveam thing? I'm not sure, I'll check it out more... In other news, I'm almost done ditching the read/print message serialization in favor of cl-store. I think this will work well, but I do not know about performance. --matt On Wed, Aug 13, 2008 at 12:01 AM, Far? wrote: > 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. > _______________________________________________ > erlang-in-lisp-devel mailing list > erlang-in-lisp-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel > From fahree at gmail.com Fri Aug 15 04:12:47 2008 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Fri, 15 Aug 2008 00:12:47 -0400 Subject: [erlang-in-lisp-devel] git access Message-ID: <653bea160808142112w42a6b775k694126238d2404db@mail.gmail.com> 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 at 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. From fahree at gmail.com Fri Aug 15 04:30:14 2008 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Fri, 15 Aug 2008 00:30:14 -0400 Subject: [erlang-in-lisp-devel] watching processes Message-ID: <653bea160808142130y53050ba1m7dc658bda5f1e6a8@mail.gmail.com> 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 From fahree at gmail.com Fri Aug 15 04:40:43 2008 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Fri, 15 Aug 2008 00:40:43 -0400 Subject: [erlang-in-lisp-devel] latest erlang-in-lisp In-Reply-To: References: <653bea160808122101u3373ff75k126edb9b0b867ea9@mail.gmail.com> Message-ID: <653bea160808142140m582da1cdi397d67c4e9303868@mail.gmail.com> > This morning I had some troubles again (I forget what it was) and > updated my copy...right this second I can't actually do a > slime-load-system without sbcl going bonkers and chewing up 100% of > the cpu time. It ties up emacs and I can't even get to *slime-events* > to see what's going wrong. I should probably just back off my copy of > slime. Sounds like some SBCL problem, combined with some SLIME issue. Maybe downgrade to some known-working versions? > In other news, I'm almost done ditching the read/print message > serialization in favor of cl-store. I think this will work well, but > I do not know about performance. Can you make the serialization method parametrizable? Or even punt on it for now, considering we're in "pencils down" period. At this point, it will become more important to ensure there's enough docs of what's there and what remains to be done for other people to take over your code. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Opportunity is missed by most people because it comes dressed in overalls and looks like work. -- T. A. Edison From thatmattbone at gmail.com Fri Aug 15 14:35:21 2008 From: thatmattbone at gmail.com (Matt Bone) Date: Fri, 15 Aug 2008 10:35:21 -0400 Subject: [erlang-in-lisp-devel] Re: git access In-Reply-To: <653bea160808142112w42a6b775k694126238d2404db@mail.gmail.com> References: <653bea160808142112w42a6b775k694126238d2404db@mail.gmail.com> Message-ID: Ok, I set those permissions, and I'll change the instructions. --matt On Fri, Aug 15, 2008 at 12:12 AM, Far? wrote: > 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 at 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. >