freenode/#lisp - IRC Chatlog
Search
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
16:31:38
pjb
Well, require with a single argument is implementation dependent; in that case, I don't see how getting different results when evaluating it at compilation-time or at run-time makes any difference. If you want conforming results, pass it the path to load!