libera/#commonlisp - IRC Chatlog
Search
6:43:28
gigo
Why should we use with-standard-io-syntax when not using it also works fine. Code I wrote to test it out: https://plaster.tymoon.eu/view/2506
6:46:51
kakuhen
phoe: i am trying to bootstrap 1.12.1 and I kept running into a bunch of mysterious compiler errors; so far i have managed to produce the 1.12.1 kernel and some bootstrapping binary from my existing ccl installation
6:47:28
kakuhen
somehow (ccl:compile-ccl) immediately gave me some error about x8664arg something, but (ccl:compile-ccl t) went smoothly
6:49:05
kakuhen
what i've done so far is merge my /usr/local/lib/ccl with the ccl-1.12.1 folders, but obviously not overwrite any overlapping files
6:50:26
phoe
the general procedure of bootstrapping CCL is, you use the existing CCL to build a new minimal heap image, and you compile the C kernel
6:51:50
kakuhen
Anyway, I ran the 1.12.1 kernel with the 1.12 heap image, and then I ran (ccl:xload-level-0), which compiled all the newer lisp files without error and produced a bootstrapping image
6:52:03
gigo
mfiano: phoe: So if I don't change the default IO settings, then not using (with-standard-io-syntax ...) would be okay?
6:52:12
kakuhen
phoe: im assuming i should be using this bootstrapping image when I invoke (ccl:compile-ccl) and not my 1.12 heap image
6:52:42
phoe
I think the bootstrapping image only contains enough facilities to be able to load FASLs
6:52:44
gigo
phoe: makes sense. thanks. so I should keep the (with-standard-io-syntax ...) as a best practice.
6:54:39
kakuhen
running (ccl:compile-ccl) gives me "Error: Unbound variable: $NUMX8664ARGREGS signaled during assembly-time evaluation of form (* $NUMX8664ARGREGS X8664::NODE-SIZE)" when its trying to compile x86-clos.lisp
6:54:46
mfiano
gigo: if your code has (float x 1.0) and isn't wrapped in with-standard-io-syntax, the user could change that by dynamically binding the float read format around a call to your function
6:54:52
kakuhen
But what I find confusing is that running (ccl:compile-ccl t) gives zero errors whatsoever.
6:58:16
kakuhen
phoe: OK turns out my cursed method of merging folders worked and produced me a 1.12.1 binary
6:58:26
kakuhen
you were right about the bootloader only being able to load fasls and do basic functions
6:59:12
kakuhen
The manual makes me believe that calling "(ccl:compile-ccl)" should recompile updated lisp sources and generate fasls for them
6:59:25
kakuhen
yet it has this strange error for x86-clos.lisp, unless you force compile EVERYTHING
7:01:01
gigo
mfiano: Can you give an example of *read-default-float-format* that can make the writing and reading incompatible (provided I don't use with-standard-io-syntax)?
7:03:24
phoe
gigo: I think (setf *print-length* 3) is a simpler example - you simply cannot read back lists that have been truncated like this, no need to play around with float formats
7:04:34
gigo
phoe: Yes, I tried (setf *print-length* 3) and it indeed breaks the reading. This helped. Want to try out an example with *read-default-float-format* too.
7:12:52
gigo
I will make something out of that example to convince example. Thanks for the example. I am first writing some examples to understand the difference between single-float and double-float.
7:19:41
phoe
gigo: double floats have more precision but cannot be immediate values on 64-bit platforms
7:24:04
kakuhen
Here is a full log of everything I did to bootstrap v1.12.1 from v1.12 https://bsd.to/wXwJ
7:24:15
kakuhen
Before running this, I uninstalled ccl and then reinstalled ccl (1.12) from freebsd ports
9:36:17
gigo
mfiano: phoe: In our discussion a little while back I learnt that if I don't use (with-standard-io-syntax ...) while writing to a file, reading it may become impossible. Is there an example where if I don't use (with-standard-io-syntax ...) while reading, it may cause problem?
9:42:53
susam
phoe: so not something straightforward a beginner like me can reproduce easily? that's fine. I will keep it in mind and try it out later when I have learnt more CL.
9:43:25
susam
phoe: this discussion has been most interesting. Unfortunately I have not learnt reader macros yet.
9:44:49
susam
In fact, it never occurred to me earlier that with-standard-io-syntax was important while reading and writing files. I guess because I mostly write them out in a custom format that I have to parse. But yes, after the few examples cited earlier today in this channel I see why it is important.
9:48:44
gigo
phoe: https://plaster.tymoon.eu/view/2507#2507 - this works fine. what kind of mismatch should I make?
9:50:26
phoe
(let* ((string (prin1-to-string 1.0f0)) (*read-default-float-format* 'double-float)) (read-from-string string))
10:37:13
gigo
phoe: learning CL and I had a nagging feeling since yesterday that I don't fully understand the need for with-standard-io-syntax. but now I do after reading the examples you gave. thanks!
10:40:25
kakuhen
How many people actually read documentation slots in CLOS, let alone know how to access them?
10:43:57
susam
gigo: Okay. I have been writing my personal tools in Common Lisp for the past few years but I am still learning something new from your questions.
10:45:42
susam
gigo: We had a PCL reading group sometime back where I used to take notes from the book and archive it for our group. I remember reading about with-standard-io-syntax but did not investigate it like you did, i.e., making test cases where not having it would lead to failure. I am planning to include these test cases given by phoe to our notes.
10:46:36
beach
kakuhen: Documentation for a slot is somewhat of an aberration, since slots are implementation details and do not merit any external client documentation, which is what documentation strings are for.
10:53:51
beach
tfb: I was answering the question of who reads and writes such documentation, not whether it belongs in the language or not.
10:56:34
tfb
beach: I think the statement that 'documentation strings are for external client documentation' is simply wrong: documentation strings are for whatever they are used for
11:02:30
edgar-rft
tfb: there's (documentation (x structure-class) (doc-type (eql 'type))) -> http://www.lispworks.com/documentation/HyperSpec/Body/f_docume.htm
12:11:26
Guest63
can we re-use their names for multiple classes (e.g. two classes can have the same accessor name)?
13:05:01
phoe
oh wait, https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/ is still a better resource
13:09:23
coat
practical common lisp is freely available online so I will start with that one. will buy gentle intro to symbolic computation after I have worked thru practical common lisp
13:12:45
Guest63
coat: it's a bit easier to read IMO (but others like PCL, so this is just an opinion), PCL may be useful as a second book
13:14:02
Guest63
the author of ansi cl btw is the founder of ycombinator, and now a multi billionaire - never knew writing books was so lucrative!
13:17:14
Guest63
also a gentle introduction to symbolic computing is available for free online (i note you said "buy"):
13:18:22
Guest63
imo its a good read but too long winded. I find it good to read another book first to get some basics in your head - THEN read AGITC - THEN go back to your original book and everything will click better
13:19:09
Guest63
but as a first read, it might be too slow and detract readers (its gentle pace is really helpful in explaining concepts, but IMO you don't realise why those concepts are important and need explaining until you get a bit of experience and then start asking the questions yourself)
13:39:52
tyson2
I find the practical examples in PCL are more interesting to read, then I go back and check out the topics I don't understand (have been using scheme and elisp for a while)
13:57:32
jcowan
On internal DEFPARAMETER, you can get very strange-looking things to happen: considere (progn (let ((gong 42)) (defparameter gong 50) gong) gong), where gong apparently escapes from the let-binding.
14:10:30
edgar-rft
the more interesting thing is that when I evaluate (let ((gong 42)) (defparameter gong 50) gong) for the first time, when no special var gong exists, it returns 42, while from the second time on it returns 50
14:13:27
edgar-rft
but shouldn't gong be declared special already after (defparameter gong 50) in the first evaluation, I mean the return value, not in the let binding
14:14:00
phoe
edgar-rft: the proclamation happens after the compiler infers that GONG refers to a lexical variable
14:14:25
phoe
the second time this code is compiled, the compiler knows that GONG is globally special
14:14:45
phoe
the confusion happens because there are actually two variables in play here: a lexical one named GONG and a dynamic one named GONG
14:16:15
edgar-rft
but in (let ((gong 42)) (declare (special gong)) (defparameter gong 50) gong) the declaration also happens *after* the let binding and it returns 50 at the first try
14:19:39
edgar-rft
so (declare ...) is considered at an earlier time than (defparameter ...) in the compiler?
14:20:21
edgar-rft
phoe: I'm talking about (let ((gong 42)) (declare (special gong)) (defparameter gong 50) gong)
14:21:22
_death
edgar-rft: the defparameter form is not a top-level form, so the compiler may not recognize it
14:22:36
edgar-rft
but I have to read the spec to make sure I understand what I am talking about :-)
14:24:05
Guest63
"Constructs that use lexical scope effectively generate a new name for each established entity on each execution. Therefore dynamic shadowing cannot occur (though lexical shadowing may). This is of particular importance when dynamic extent is involved."
14:24:29
_death
there was discussion about top-level bindings yesterday.. recently I looked at the chinual (for a reddit comment) and also noticed there was a LET-GLOBALLY operator
14:25:27
_death
which may be similar to what people nowadays call LETF.. but maybe had some difference with regards to this specific case
14:32:42
scymtym
we worked a little bit on the process for creating WSCL (which beach mentioned above). in case anyone wants propose a clarification regarding non-toplevel DEF{VAR,PARAMETER}, a pull-request that fleshes out https://github.com/s-expressionists/wscl/blob/main/wscl-issues/proposed/DEFPARAMETER-NON-TOPLEVEL-SEMANTICS would be welcome
14:38:19
scymtym
_death: yes that's wrong. the file is meant as a starting point which illustrates the format. to be honest, i didn't follow the discussion closely since i'm focusing on the infrastructure. it's just that having such as discussion without writing down any insights seems like a waste
14:52:42
_death
scymtym: well, I'd expect the first form to return (3 1) .. don't see how it could return (2 2) since there's no lexical binding there
14:57:46
scymtym
i think i wanted to write (2 3) but i rushed it a lot to have an example ready. the point is, why not write down different possible behaviors and the respective pros and cons as well as the behavior of existing implementations
15:42:17
_death
I don't think I ever used non-toplevel defparameter/defvar.. are there any known uses in the wild
15:46:09
jackdaniel
_death: LETF (at least in mcclim codebase) is a "let for places" - that of course breaks for multi-processing code, but it is ~ (let ,remember-old-vals (unwind-protect (progn (setf ,@store-new-vals) ,@body) ,@restore-old-vals)
15:51:34
_death
jackdaniel: right.. unlike letf, it was unaware of places.. but it did set variables.. re-reading its description, I guess it had more to do with stack groups
15:53:13
jackdaniel
funny break scenario for climi::letf is trying to bind the unbound slot (something that could be worked around if really necessary)
15:58:57
_death
there are other funny facts with LML.. e.g., it had defvar but its defparameter-like was called defconst.. the case-like operator used to be called selectq (the q meant the keys were not evaluated) and there was an evaluating case called select (and also selector, which let the programmer specify the comparison function).. sometimes it looks like CL has simplified operators that were gnarly in LML
16:01:33
_death
well, an alias, but it existed for "maclisp compatibility", though it was different from maclisp's :)
16:19:38
Bike
i'd just write it yourself and if it turns out to be in a utility library all the better
16:41:49
jackdaniel
otoh doing it that way may invoke unnecessary protocols (because it always modifies the place) - the same problem would apply to reverse-orf I think