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