libera/#commonlisp - IRC Chatlog
Search
21:33:32
lisp123
rotateq: Yes, I got that working. My brain hurted trying to install CMUCL so I gave up
21:37:10
lisp123
rotateq: Perhaps. Next up is LispWorks if I can save up enough money to try it out (outside of the Personal Edition), and perhaps AllegroCL too
21:38:24
lisp123
My goal is to have them all nicely installed, then switch between each in Emacs with (setq inferior-lisp-program ....)
21:40:21
rotateq
even wanting to be aware of the things *one* of the main implementations provide is immense
21:46:19
rotateq
you have luck if your customer is getting what you tell him why you choose the thing itself in contrast to most competitors, trusts you and says "OK". so you don't have to tell him even more "oh and because of this and that better this implementation"
21:48:18
rotateq
right, because they don't have an overview, so trust is of much worthness (you could tell them basically anything)
21:50:38
rotateq
yes the payment will include that you do it to your best believing (justified by clear facts and some metrics). and thinking in the long run
21:53:15
rotateq
that kind of freedom often goes hand in hand with confidence, and confidence is grown by experience and experience is grown by practice
4:27:43
lukego
SLIME really needs a way to give you a hint when the long computation you're waiting for has stopped because SBCL ran out of heap space and discretely printed a nasty warning in *inferior-lisp* before waiting with the socket open at the ldb> prompt
5:30:13
beach
lukego: SLIME is good, but it is not great, and some of the limitations are probably due to intrinsic problems with the technique being used.
6:17:38
lukego
beach: True. But that sounds a bit like a fortune-cooking comment that could apply to any project :)
6:19:29
lukego
and in this case I'm not sure that it would be advantageous to have the tooling running inside that Lisp image that has run out of heap space (or e.g. heap corrupted) and landed at the LDB prompt. The fact that it's partitioned into a separate subprocess is kind of handy because I'm restarting the Lisp process multiple times per day but never losing my editor state, since my Emacs is a lot more stable than my Common Lisp :)
6:20:47
lukego
is the long term vision for mcclim ecosystem to run all of the Lisp code together in the same image? Or to partition it into multiple images e.g. the way HEMLOCK had REMOTE stuff to manage an "inferior" lisp process way back when?
6:25:09
lukego
This is btw the main topic on my mind this morning: where should the inter-process/inter-language boundaries in my system be? which parts are best integrated, which best separated, and which doesn't it matter? Interesting in the context of e.g. SMT solvers, machine learning toolkits, data visualization, etc, where the benefits of integration need to outweigh a *lot* of extra work reinventing stuff that's available separately
6:26:33
beach
Right, our Common Lisp implementations are not stable enough, or safe enough, to handle an IDE in the same image.
6:27:08
beach
But it seems like the wrong approach to take for granted that our Common Lisp implementations are not great, and work around it, rather than fixing the implementations.
6:29:16
beach
I don't think that there is an agreed-upon vision for McCLIM. I know what I want, and I believe scymtym shares this vision. I also know that Shinmera (for example) does not share it. He once said something like "I will *never* use an editor that runs in the same image as my Common Lisp system".