[erlang-in-lisp-devel] latest erlang-in-lisp

[Matt Bone]

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 at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel
>