freenode/#lisp - IRC Chatlog
Search
6:00:31
jasom
https://www.reddit.com/r/lisp/comments/8de7ol/notice_for_lisp_game_jammers_sbcl_macos_bug/
8:54:50
xificurC
in sbcl, the implications/limitations of `eval` are the same as of `compile` right? The manual states that `eval` is mostly just (funcall (compile nil (lambda () ...)))
8:56:38
xificurC
is there a good, down-to-earth explanation of lexical and dynamic environments? I understand the concepts from other languages but am failing to extrapolate the knowledge here. E.g. to understand why `eval` cannot see the lexical scope and how is the lexical and dynamic scope actually implemented
8:58:53
xificurC
next: the sbcl manual states that fasls are binary compatible only with the version they were compiled with. Can I write a load-compile function that will always load a fasl compiled version of the given file by recompiling the source code file when necessary?
8:59:26
xificurC
I'll hope for someone smart to chime in :) Oh and the topic needs updating sbcl version :)
8:59:58
phoe
xificurC: if you use ASDF to load your systems, it will automatically recompile the files when necessary.
9:00:39
xificurC
phoe: we are using sbcl as a scripting environment right now, loading asdf for each invocation is too costly
9:02:17
xificurC
phoe: I can make an image with all the libraries pre-loaded, can't I. I'm saying we are using a clean image as the distribution provides and loading things as needed
9:03:12
xificurC
the moment we start creating our own image is the moment we have moved from distributing scripts to distributing compiled units
9:03:54
phoe
xificurC: in layman's terms, dynamic environment consists of everything on the stack; lexical environment consits of everything inside a given pair of parentheses.
9:04:45
phoe
this is why when function A invokes function B, the lexical environment of A does not move over to B, because B is defined in a different pair of parens, but the dynamic environment from A moves over to B, because A and B are both on the stack now.
9:05:44
phoe
an implementation can keep some symbol references for debugging purposes, but other than that, the lexenv disappears after compiling code.
9:06:26
xificurC
phoe: this leaves the implementation the option of e.g. keeping the lexical env in registers?
9:07:19
aeth
Lexical variables can be optimized, and they're known. Usually even the type is known. SBCL is only really "fooled" by numbers and sequences.
9:07:58
phoe
An implementation *can* keep it for debugging, etc., but other than that, it's a by-product.
9:08:22
aeth
It's implementation-specific, but they're probably kept at (debug 3) and not at (debug 1) (speed 3)
9:09:21
xificurC
phoe: ok i see what you mean I think, you're saying the compiler can optimize the usage so that the resulting assembly will have no trace of it
9:15:03
xificurC
rust is *huge* and compiled only, with no normal REPL (last time I checked). CL is not just compiled, fully interactive, garbage collected... Hard to compare the 2 isn't it?
9:17:01
blep-on-external
i'm not selling it to a compsci student or a mathematician: this is a person neckhigh in modern bollocks
9:17:27
xificurC
capisce: CL is huge in a different way. If you learn parentheses and a couple more things you know the language and can start reading about what's in the standard.
9:17:51
aeth
blep-on-external: Show them something that normally is written in C++, but is written in CL instead. (Which of course implies that the GC doesn't matter that much in the end.)
9:17:54
xificurC
tell me how long will it take for a newcomer to learn all of rust's syntax and semantics
9:19:48
xificurC
I'll circle back to my question about load-compile - I can imagine the logic being: if no fasl or incorrect version or older than .lisp recompile, then use fasl. How can I check for the incorrect version?
9:21:24
jackdaniel
some implementations will warn you and reject such fasl with error when you try to load it
9:23:36
xificurC
blep-on-external: I think rust macros were at least partially based on racket's syntax-parse
9:25:18
xificurC
jackdaniel: the first time I asked, which was when I joined. Not sure if you were around at that point
9:27:31
xificurC
jackdaniel: I found that in the manual in 30s too, but it's a mixture of sbcl's internals and various asdf operations. I couldn't find docs for invalid-fasl
10:54:03
Petit_Dejeuner
Xach: Thank you for mirroring so much of the lisp usenet posts. Google groups has been very annoying lately.
11:13:02
Petit_Dejeuner
"lexical environment no longer exists after compilation." probably worth saying that lexical environment means the same as static environment
11:13:38
Petit_Dejeuner
or at least that lexical/static are user interchangably, (static is the opposite of dynamic)
11:23:57
White__Flame
more practically, the mappings from symbolic names to lexical variable locations no longer exists after compilation
11:26:37
DemolitionMan
please is there a way to allow/prevent the reader to read code depending on *features* contents? I need to read source code depending on :x86 or :x86_64 keyword. Thanks
11:27:35
phoe
if the reader conditional does not exist, the reader will read over the next form and treat it as non-existent
11:35:53
xificurC
Petit_Dejeuner: so when e.g. a defun is being compiled (let's talk sbcl) it checks it's lexical env scope and compiles everything necessary in? Where does such a lexical env exist after compiled? stack? heap? register?
12:07:38
drmeister
Does anyone know how to write debugging output from slime that doesn't interfere with its regular communication?
12:13:14
jackdaniel
xificurC: if you know the term, then you should read about closure allocation strategies.
12:18:36
jackdaniel
I'm aware that I may sound not nice, but I suggest it because looking up things indivudually is a useful skill
12:19:08
xificurC
jackdaniel: is it really such a sin to ask for a tldr in an IRC channel? If I wanted to attain deep knowledge of the topic and couldn't find good resources I would ask for resources. If I'm looking for a short answer for a short question "go google [xyz]" is really not that helpful
12:20:07
xificurC
jackdaniel: it's hard to read someone's mood or character from text but it started to seem to me you like what you're doing to me :)
12:22:01
xificurC
jackdaniel: re looking up things - my usual process is: 1) look it up; 2) if couldn't find look it up another way; 3) if couldn't find look it up another way; 4) ask for help. For a thought on that I'm coding something for a week and this is the first time I came for advice
12:24:03
jackdaniel
yet your question create an impression, that you didn't bother to look things up. either way, I've already stated my opinion on the matter
12:26:11
xificurC
jackdaniel: I agree that my language or usage of terms might give that impression. Thanks for the link, I'll give it a look
13:02:17
dlowe
Given the current size of the userbase, I think I'd rather have more people contributing to the quicklisp infrastructure than more infrastructures.
13:50:28
dlowe
Sure. Being able to subscribe to, depend on, and maintain multiple repos would be key here
14:07:57
Petit_Dejeuner
Er, what I mean is I used to be able to use them in slime without any configuration, but now they aren't bound.
14:13:13
pyc
Is buildapp necessary? Isn't sb-ext:save-lisp-and-die enough to build a distributable executable binary?
14:14:13
jackdaniel
pyc: buildapp is meant to be portable and make things easier. it works on sbcl and ccl
14:15:02
jackdaniel
I'm presonally using net.didierverna.clon which works on more implementations, provides good abstraction for command line options and on top of that is well documented
14:25:41
Xach
pfdietz: I am putting together a docker image that contains all the necessary foreign libraries for building everything shipped in quicklisp.
14:35:27
Xach
pyc: i made buildapp because i wrote the same type of lisp file to load stuff and call save-lisp-and-die all the time
14:35:50
Xach
it is a program that automates writing that kind of lisp file and loading it. i also could not figure out how cl-launch worked.
14:36:04
Xach
now there is cl-launch, net.didierverna.clon, asdf built-ins, and probably more besides.
14:57:36
Fare
I noticed, too late, that there was a difference in calling convention between cl-launch and buildapp -- cl-launch calls a main function with argv[1..] while buildapp calls it with argv[0..]
16:05:44
beach
It just occurred to me, the Intel "bug" where speculatively executed instructions do not check for permission, wouldn't that bug also affect Common Lisp systems that rely on the hardware to for GC write barriers?
16:48:50
Xof
beach: the real problem in that bug was read permission of sensitive data that the user process shouldn't have been able to read