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é fahree@gmail.com 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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel