freenode/lisp - IRC Chatlog
Search
14:29:01
Xach
jackdaniel: I want to make a file, /foo/bar/index.txt, that has a list of all *.asd files under /foo/bar/. And I want to make the pathnames relative to /foo/bar/, so in the case of symlinks, I want the non-resolved name.
14:29:37
Xach
but sometimes /foo/bar/ itself is actually /Barble/Narble/foo/bar/ and that can foul up computing relative pathnames
14:33:53
jackdaniel
Xach: ecl's directory will be rewritten to match more closely other implementations, so resolve-symlinks will get there too. But first I want to write a CDR for pathname unification to have something to refere to
14:35:28
drmeister
Can slime be used to connect to swank servers on remote machines? I'm guessing yes based on what I've heard.
14:35:52
drmeister
jackdaniel: I have the same issue with resolve-symlinks because clasp duplicates ECL's behavior
14:35:58
Xach
drmeister: Yes, but by default it listens only on localhost. there is no authentication in the protocol.
14:36:45
drmeister
I'm running swank within a docker container and there appears to be some initial communication and then:
14:37:37
jackdaniel
note, that M-. won't work unless you have sources at the exact same location as on target machine
14:38:30
jackdaniel
drmeister: 0.0.0.0 is "every network", but you have to connect to the particular ip
14:39:18
drmeister
0.0.0.0 is a docker thing - that's where they provide access to the docker services
14:49:49
drmeister
I'd like to deploy Cando (Clasp+chemistry code) as a Docker image that people run and connect to initially through emacs/slime
14:52:39
drmeister
I see the same immediate shutdown with sbcl/swank running in the docker container
14:52:51
jackdaniel
drmeister: see https://gitlab.common-lisp.net/ecl/ecl-android/blob/master/assets/lisp/etc/user.lisp#L69 start-swank function
14:54:09
eudoxia
and you set the loopback interface in swank to... i don't recall what the correct value would be
14:56:17
antoszka
I'd rather ask the potential users to set up ssh tunnels and leave swank listening on 127.0.0.1:<whatever port>
14:56:26
eudoxia
I guess you could set swank::*loopback-interface* to (uiop:hostname) and let UIOP take the wheel
15:00:05
eudoxia
also, try connecting to the Docker swank with https://github.com/eudoxia0/swank-protocol
15:41:55
slaterr
about my earlier question about turning CL into lisp-1. wouldn't it be relatively simple by walking through the code, and turning every function call into a check whether the symbol refered to a function or a variable, and then either call it directly or via funcall?
15:45:10
beach
So if you have (with-output-to-string (var ...)) you will treat var as a function call?
15:48:20
slaterr
is that a problem? I'm not sure what "enivonment of the implementation" standards for. do you mean code can't be written in CL and it has to be implementation specific?
15:48:39
ogamita
slaterr: yes, it's simple, such a macro has been posted on news:comp.lang.lisp ages ago.
15:50:37
beach
slaterr: For you example of ((f x)), would you turn (let ((x 234) (y 345)) ...) into (let (funcall (x 234) (y 345)) ...)?
15:51:06
ogamita
Theorically, a code walker has to be implementation specific, because the standard doesn't prevent the implementations to provide implementation specific special operators. But in practice IIRC, there's only one such occurence amongst all the common implementations.
15:51:45
ogamita
So in practice you can "easily" write a code walker. Now the "easily" is quoted because to make it easy it is preferable to provide your own implementation of all the CL macros.
15:53:25
ogamita
Yes, new special operators, but the worst is the _extension_ of standard special operators! AFAIK there is only one such occurence amongst the common implementation too. (clisp extends CL:FUNCTION with an additionnal parameter, sbcl has an additionnal special operator (that is not an implementation of a standard macro).
15:54:35
ogamita
https://github.com/informatimago/lisp/blob/master/common-lisp/lisp/stepper.lisp#L266
15:55:27
ogamita
ok, in cl-stepper I have it easy, because I use the underlying implementation for the expansion of the result of the code walker.
15:56:42
ogamita
beach: the trick is to assume a conforming program on a conforming implementation. Then you can substitute any operator of the implementation by equivalent conforming operators, notably for macros. (for functions it is more difficult if you have alternate data types).
16:01:17
drmeister
eudoxia: That swank-protocol thing... that runs within another Common Lisp implementation and talks to swank somewhere else - correct?
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)