freenode/#lisp - IRC Chatlog
Search
2:36:46
fengshaun
and https://sourceforge.net/p/sbcl/sbcl/ci/master/tree/ is hard to navigate for someone unfamiliar
3:02:12
beach
fengshaun: APPLY would not be a Common Lisp function, so SLIME probably can't find it.
3:10:05
White_Flame
however, there are compile-time shenanigans happening too, so each of the hits that M-. brings up is some different path it might take
3:10:33
White_Flame
since DEFUN APPLY calls APPLY itself, that inner APPLY is actually something different
3:11:28
beach
I don't see how that could be done in Common Lisp, because it would involve direct access to machine registers and such.
3:12:30
White_Flame
inside DEFUN APPLY, there are type checks on the parameters. The nested APPLY then is in scope of when types are known, and compiler shenanigans do the low-level replacements there
3:14:01
White_Flame
and of course, if the types are known in user code (basically if the last parameter is a list), then the shenanigans can happen there directly
3:40:48
pjb
beach: I don't know about sbcl, but in ccl, slime usually can find the source of CL operators.
3:46:21
ck_
pjb: this looks to be more of a 'implementation platform" problem. More to do with windows than sbcl.
3:51:18
beach
pjb: What I meant was that fengshaun should not expect the code that spreads the argument to be written as a standard Common Lisp function.
3:54:18
pjb
Yes, but at least you should get some sources. It's true that it won't necessarily be clear, unless you know the internals of the implementation.
4:39:22
fengshaun
beach, no, it found the definition and I looked it up, it's a 'normal' cl function
4:39:45
fengshaun
pretty much cons'es the list together so the end result is it removes one layer of nesting
4:53:06
beach
fengshaun: Oh? So how does it pass the arguments to the function being called? I would be surprised if it conses anything at all.
4:55:35
beach
I can see that, in some implementations, every function would receive a list of arguments, but that would be a not-very-efficient implementation.
4:56:45
beach
fengshaun: An efficient native-code Common Lisp implementation would pass arguments in registers and on the stack, and neither the registers nor the stack are available to a standard Common Lisp function.
4:58:04
ck_
beach: I'd guess this is the source code they're looking at: https://github.com/sbcl/sbcl/blob/master/src/code/eval.lisp#L328
5:03:02
beach
But yeah, it seems to be consing. The comment suggests that this is not the way it is typically handled though.
5:22:36
beach
fengshaun: The SBCL compiler treats a lot of stuff specially. For example, here is the definition of the function CAR: https://github.com/sbcl/sbcl/blob/master/src/code/list.lisp#L30
5:38:48
no-defun-allowed
The representation of stuff isn't specificied in the CLHS, so it's probably useless if you want to read about the implementation of CAR.
5:39:39
beach
CAR was just an example of how the SBCL treats things specially. Nobody expressed interest in the implementation of CAR.
9:21:50
heisig
ralt: I have two replies for you, that are almost universally applicable to all 'issues' in Common Lisp:
9:22:09
heisig
1. The standardization committee was full of brilliant people, they probably had their reasons.
9:24:00
heisig
Heck, you can even make your own ralt-cl package that shadows unwind-protect with something of your choice :)
9:26:24
heisig
You could just ignore syntactic issues altogether. That is what I do nowadays, after realizing how much brainpower I have already wasted on this topic.
9:51:48
no-defun-allowed
Has anyone made a Common Lisp ugly printer? Not an obsfucator, the read in form should be the same as the form printed, but one that tries its best to write the least aesthetically pleasing output as possible.
9:53:08
no-defun-allowed
Maybe it would leave dangling parens, produce odd indentation, that kind of thing.
9:56:41
heisig
no-defun-allowed: Given that it is possible to have reader macros in the printed forms, such a tool could produce VERY ugly results.
9:57:50
no-defun-allowed
True. I'll keep my ugliness to things that make #lisp sad when reading code. then.
10:29:30
ralt
(DON'T RUN THIS AT HOME, IT'LL BRICK YOUR OS) if you run `chmod -x /lib64/ld-linux-x86-64.so.2`, how can you fix it? the constraints being that you ran this in bash, and you can't reboot into another OS.
10:31:12
no-defun-allowed
alternately, wait for Schmidt to refurbish another lispm and buy that instead
10:35:43
no-defun-allowed
(but seriously, maybe hope you have statically linked Busybox and a root shell lying around?)
12:32:47
eigenhombre
Hi, is there some magic required to load libraries requiring FFI in SBCL? When I "(ql:quickload :cl-charms)" I get "Error while trying to load definition for system cl-charms frompathname/Users/eigenhombre/quicklisp/dists/quicklisp/software/cl-charms-20181210-git/cl-charms.asd: COMPILE-FILE-ERROR while compiling #<CL-SOURCE-FILE "cffi" "src"
12:32:47
eigenhombre
"cffi-sbcl"> [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR]"
12:33:42
eigenhombre
(Sorry, IRC and Common Lisp newbie). This happens on OS X whether I install SBCL with Homebrew or from source. Other quicklisp library installs work fine.
12:55:30
ck_
I am on osx as well, can load cl-charms without problems through quicklisp. It compiles some c sources with clang.
12:56:02
ck_
is it possible that that part didn't work for you? Also, try (ql:quickload :cl-charms :verbose T) to see more information