freenode/lisp - IRC Chatlog
Search
16:48:56
jasom
eudoxia: last time I wrote a swank client, the swank service changed to often for it to be useful; is that still the case?
16:49:36
eudoxia
swank-protocol is a very low level client, basically just handles the wire-protocol (length-prefixing and all that crap)
16:50:29
jasom
I looked at the slime history and it's really a case of a single monolithic program that just happens to make some function calls across the wire.
16:51:50
jasom
I don't know if I could convince the slime maintainers to do this, but a nice thing might be to factor out all the various implementation-specific things that slime can do into its own library (generate a backtrace, break, eval compile &c.) then one wouldn't be tied to the swank wire protocol
16:52:29
jasom
b/c the only real reason to use swank is the huge amount of implicit knowledge in the code about how to control and debug various lisp implementations
16:52:38
eudoxia
consider sending `(read)` over to swank and having the lisp process wait for user input
16:53:19
jasom
eudoxia: well that's just accomplished by binding streams, right? It's orthogonal to the debugger specific things
16:54:05
eudoxia
but ideally yeah: there should be an IDE engine core, an IDE engine wire protocol server, and a CL IDE engine client
16:54:24
jasom
I can implement bespoke gray streams fairly easy, and using trivial-gray-streams it's implementation independent. It's all the other stuff that is a PITA to do and needs to be done 6 times.
17:22:01
drmeister
If I have a Dockerfile that clones clasp from github and then builds it - if I change the github repo - is there a way to build a docker image from that point? I guess I start from an image that immediately precedes the git clone and build?
17:22:55
drmeister
Off-topic - I know - sorry. But there are several docker users here interested in Common Lisp.
20:29:09
burtons
Seems to be a low level problem with promises, with everything installed out of the lastest quicklisp.
21:17:58
k-stz
http://stackoverflow.com/questions/42426046/stopped-process-but-heap-is-still-changing if someone whats to guess with me. But it's only Lisp related to the extend that I'm building a Lisp program around it
21:25:46
TruePika
k-stz: ptrace(2) acts on threads, not entire processes; the second argument is the thread ID
21:28:08
k-stz
TruePika: ah thank you, that was me using pseudo code, I got the order right in the binding
21:36:42
k-stz
multiple threads sharing the same heap.. stopping one thread would still allow other threads to change it
21:39:50
k-stz
I'm checking if the heaps overlap and then I'm gonna stop them all.. this makes sense
21:46:23
k-stz
TruePika: well first of all thanks! SIGTSTP works, but now i have some more reading to do :)
22:16:45
lagagain
Why I have different result between with sbcl and with ecl? https://www.irccloud.com/pastebin/W4BJfqRc/Common%20Lisp%20-%20Hello%20World
22:18:09
lagagain
I think "Please Input your name" is show before input name, but sbcl, abcl is after input; clisp, ecl just I think.
22:19:56
scymtym
lagagain: the implementation is free to not write anything to your terminal before the READ-LINE call. add (finish-output) to force the output
22:25:08
TruePika
but that (DECLARE (IGNORABLE C D D E F)) should theoretically suppress the STYLE-WARNING issued
22:26:19
TruePika
yup, not unique to NST: (let* ((a 1) (b 2) (b 3)) (declare (ignorable a b b)) a) results in a STYLE-WARNING about defined and unused B
22:29:38
TruePika
I can't be sure if this is an SBCL bug, I don't see anything covering this in the hyperspec
22:34:45
TMA
TruePika: if LET* is expanded in the straightforward manner to a series of nested LETs, the declare remains in the innermost LET form
22:36:57
TMA
TruePika: therefore the ignorable is the second one, not the first one, which gets shadowed before being declared ignorable
22:39:32
TMA
TruePika: not without splitting the let* into (let* ((a 1) (b 2)) (declare (ignorable b)) (let* ((b 3)) (declare (ignorable a b b)) a))
1:53:49
krwq
hey, is there any way to make cffi-grovel fix include files? im seeing it is passing wrong paths to the compiler (they are missing c: on windows)