freenode/#lisp - IRC Chatlog
Search
3:11:04
Bike
'(a . b) will evaluate to a cons, but it won't be freshly allocated at runtime, and as pierpa alluded to, a and b won't be evaluated as they would be in (cons a b)
3:12:45
iqubic
Now, this is going to sound stupid, but the THEN and ELSE arguments of the if macro can only ever be one s-exp, right?
3:13:44
iqubic
No. Emacs tells me that COND is only ever one s-exp, but ELSE can be as many as I want.
3:55:14
loke
beach: I created a bug report about the output recrod problem, as well as a simplified test case. I even created screenshots:
3:56:12
loke
beach: Thanks. I'd appreciate even the slightest hint as to where the problem could originate.
4:02:03
loke
beach: not this one, no. There are actually two separate issues relating to output records. I stumbles on both of them at the same time, but I discovered they are separate.
4:02:34
loke
The onw I posted just now is actually independent of the text. I'm still researching a good proposal for the other one.
4:03:38
loke
The text issue has to do with the fact that DRAW-TEXT is underspecified in that the output record can't draw transformed text. I have some ideas how to fix that one.
4:06:00
beach
The first thing I will do is to stick a call to Clouseau in there and examine the output-record hierarchy.
4:08:19
loke
The really weird part that I don't understand is why the second box gets revealed as I resize the window.
4:38:49
beach
Crap. Someone seems to have modified the inspector so that it now writes to standard-output, and it modifies the output history.
4:51:15
beach
loke: My tools are failing me, so this is going to take more than a few hours. I'll work on it during the day.
5:17:07
z3t0
this is odd, for some reason qTools works just fine using ccl on macos whereas sbcl fails horribly
5:23:39
mfiano
It's a known bug, and stassats recommends opting in to the mac beta (he said he won't fix it)
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..]