freenode/#lisp - IRC Chatlog
Search
13:50:14
dlowe
if the client allows, you could also pin the cert so that the one site is guaranteed to use that one certificate, which will also thwart mitm attacks
13:58:46
warweasle
Well, I tried ##C++ but most of them never heard of Unification. Any idea if there is a unification library in C/C++?
14:22:52
gendl
Hi, why would my remote slime connection get "broken by remote peer" instead of going into the debugger, when I hit an error.
14:23:35
gendl
warweasle: nope. Server is still there, I can do M-x slime-connect and connect to it again
14:24:34
gendl
nope, it's the same instance -- although that's a good question, let me double check that
14:24:46
gendl
indeed the server is running in an infinite recovery loop so you may be on to something
14:28:28
gendl
seems the server process had been constantly crashing on initialization and getting re-spawned. the startup banner and messages are repeated in the log file a gazillion times.
14:29:02
gendl
it wasn't slime/swank crashing the lisp -- the lisp was repeatedly crashing on its own.
14:29:52
warweasle
Yeah... Whenever something is wrong I always assume I did it. Generally, every library I download is much better than anything I could write myself.
14:30:00
gendl
anyway sorry for the noise, problem identified and nothing to do with slime/swank -- my init is broken...
15:15:32
daphnis
tests whether a predicate applies to the variable, rather than whether it is equal to a value
15:17:30
beach
"variable"? If it is anything like ordinary CASE, it computes the value of an arbitrary form before checking the cases.
16:04:37
remexre
anyone know of bindings to signal (the chat program)? libsignal-protocol-c is gross enough that I'd rather not write the cffi glue myself if I don't have to :)
16:07:31
jackdaniel
easye: you may be interested in the issue resolved here: https://gitlab.com/embeddable-common-lisp/ecl/-/merge_requests/194 (lambda list congruency)
16:28:14
Xach
The latest sbcl is more strict about slots with :initform and :type. It has led to a lot of projects that no longer compile.
16:31:58
Xach
there is some redundancy - if project A fails, and is used by B, C, and D, all four will show the same failure error.
16:38:08
Xach
i think they are almost all of that form, with a small number of package locks/conflicts.
17:15:44
jasom
I would do :initform nil if I wanted to require it be specified when constructed, for example.
17:16:37
Xach
I have not closely followed the discussion around the change, only that it seems to be here to stay.
17:16:40
mfiano
It doesn't. If you declare a type, it is now a warning if the initial value's type is not of the declared type. You can always use a compelx type specifier to include null
17:17:30
jackdaniel
what you want is (fo :initarg :foo :type integer)) :default-initargs :foo (alexandria:required-arg 'foo))
17:18:43
jackdaniel
with structures you are even deeper in trouble, because type is used for inlined access and accessor-functions may be used for type inferenc3e
17:19:21
jackdaniel
so you could end up with inlined assembler instruction which adds fixnum to a string ,)
17:19:53
jasom
switching to alexandria:required-arg from nil is easy enough; thanks for pointing that out jackdaniel
17:24:55
mfiano
Xach: Yeah, I always wanted that from the failure reports. Would be nice to display it as a tree structure with root nodes sorted by "most bang for the buck". For example glkit is not located in proximity to sdl2kit or sketch, but it is the cause of their failures.
17:27:31
Xach
claw is second with 23. then cl-csv with 12, cl-messagepack with 10, cl-cffi-gtk with 10, db-cp with 6, and diminishing from there.
17:28:01
mfiano
claw can be easily fixed. I already pinged borodust. He has to backport a PR that was recently merged into cl-autowrap, what claw is derived from.
17:34:54
jasom
ebrasca: fast-io works for this too, though it's original purpose was for writing to byte-vectors it supports streams as well
17:35:08
minion
ebrasca: look at pcl: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
17:35:27
mfiano
fast-io is more for reading and writing octets. Binary parsing is at a different level.
17:35:59
jasom
mfiano: it is not for reading/writing octets, it can read binary values from 8-64 bits with specified endian
17:37:22
jasom
ebrasca: do you just want serialization/deserialization, or do you want to read externally specified binary formats?
17:37:23
mfiano
Point being, it is a tool for binary parsing, and requires no knowledge of compiler theory to function, unlike binary parsing.
17:42:37
mfiano
A friend wrote that specifically for that use case for me, because there were not any robust solutions available at the time.
17:42:39
Xach
It is also not particularly hard to write it yourself, and is quite educational. the tools cl provides are quite adequate building blocks to build up abstractions.
17:45:04
mfiano
You can check out flac-metadata, for an example of using fast-io and bitio in a mixed endian format. FLAC is BE for most fields, but does include Ogg Vorbis data which is LE.
17:47:41
Xach
i really enjoy files that mix endianness in them, it shows that real things are messy sometimes for reasons.
17:48:14
ebrasca
Here link of superblock structure https://www.kernel.org/doc/html/latest/filesystems/ext4/globals.html
17:52:28
mfiano
Mixed [byte] endianess is incredibly easy to handle. Things can get complicated without good abstractions when trying to handle bit endianness
17:53:05
ebrasca
s_blocks_count_lo is at offset #x4 and s_blocks_count_hi is at offset #x150 , both have 32 bits size and little endian
17:53:58
Xach
ebrasca: so: (if 64-bit-supported-p (+ (ash s-blocks-count-hi 32) s-blocks-count-lo) s-blocks-count-lo)
18:06:02
ebrasca
Xach: I am searching some solution because https://github.com/ebrasca/Mezzano/blob/master/file/ext4.lisp#L220 is very easy to make mistakes and it have some duplication with defstructure and writer.
18:44:44
aeth
The only problematic thing witht he new SBCL change is that SBCL went from completely ignoring :type in DEFCLASS at default optimization levels to not ignoring :type in a niche case that other implementations probably don't check (while still otherwise ignoring :type in DEFCLASS at default optimization levels)
18:46:20
aeth
The only problem with not using (error foo) as a default value to keyword (including the ones generated by :initform) or optional arguments is SLIME's minibuffer behavior, which creates a lot of noise when the default value is (error 'foo "bar baz quux") when the only relevant thing to the user of the API is that the default value is (error)
18:49:17
aeth
Unless this is more extensive than the 2.0.8 changes that got rolled back just before release, this is only for DEFCLASS's :iniform and perhaps DEFSTRUCT default slots (I didn't test the latter) and there are even more invalid APIs in the general case of a function with &optional or &keyword arguments with DECLAREd types that contradict the provided default values.
18:50:45
aeth
mseddon: In 2.0.8 and before, SBCL ignores :type entirely in DEFCLASS when (safety 3) isn't true, or when speed > safety, or something like that. Essentially, by default, :type is a meaningless thing in SBCL, so probably the majority of Common Lispers have never really faced a :type that actually, really checks.
18:51:16
aeth
In 2.0.9, SBCL does a tiny bit of type checking, to make sure that the :initform is a valid form of the slot's :type in DEFCLASS.
18:51:19
mseddon
I mean I happen to declaim that during development, but I would expect this for much lower values of safety.
18:51:36
aeth
(SBCL's official stance has always been to use DEFSTRUCT if you care about types because those are optimizable.)
18:53:15
aeth
mseddon: You wouldn't segfault if the type is invalid (except perhaps at (safety 0) when all bets are off), but you would probably get a runtime error. Except with DEFCLASS, which will only give you that runtime error if (debug 3) and otherwise act like everything's fine if you (setf (foo your-instance) 42) when that slot is, idk, of type conses or something.
18:53:41
aeth
(DEFSTRUCT will give you errors on setting or constructing things with slots of invalid types)
18:54:51
mseddon
aeth: if you find the time to put up an example, I would be happy to rock up alongside you and wave my pitchfork.
18:56:13
aeth
mseddon: (setf (foo your-instance) 42) if foo is the accessor for a DEFCLASS slot with :type single-float is an error, it's just that SBCL won't check for it at default optimization levels. It will be an error in e.g. CCL.
18:56:18
aeth
Take this class: (defclass foobar () ((%foo :initform 0f0 :initarg :foo :accessor foo :type single-float)))
19:00:26
aeth
That might error, that might not. In CCL, that does error. In SBCL, even though SBCL is otherwise the best implementation at checking types, that doesn't error unless the DEFCLASS is defined in a (debug 3) environment (iirc... it certainly doesn't at default).
19:02:13
aeth
Now, replace ":initform 0f0" with ":initform nil". In CCL, that's a runtime type error when calling (make-instance 'foobar) unless a valid value for foo is provided. The appropriate way to do this, though, is to make the initform a call to ERROR.
19:03:14
aeth
In many implementations, it's just ignored entirely and the invalid NIL default value is permitted, including SBCL 2.0.8 at default optimization levels.
19:04:54
aeth
Now according to NEWS at http://www.sbcl.org/news.html SBCL 2.0.9 does this: "the compiler signals a warning at compile-time when an initform of T, NIL or 0 does not match a STANDARD-CLASS slot's declared type."
19:05:42
aeth
SBCL (an implementation people generally use for the static checking) now does a tiny, tiny bit of static checking in a case where it previously did no checking at all, but only when the :initform is T, NIL, or 0
19:06:09
mseddon
aeth: no, this is the thing, I expect SBCL to fall at the first hurdle, and use it because it does.
19:06:10
aeth
(SBCL generally does static checking as compile time warnings that compile into runtime errors)
19:06:40
aeth
mseddon: Right, people are complaining because it does a bit of checking, whereas I got my hopes up that this edge case in SBCL type checking was finally fixed, when it's only fixed in a tiny, tiny, tiny special case.
19:07:35
aeth
Bike: I'm also curious as to why this doesn't (at least didn't in the right-before-2.0.8 release I tested before it got rolled back for 2.0.8) do a similar check for DEFUNs with DECLAREd types incompatible with the default optional/keyword argument values. This one might even catch a few bugs in my code.
19:07:56
mseddon
aeth: I had an amazing boss once who told me the story of managing a project for a simple vector CAD program for a tutorial for a university lesson. It blew up if they added >5 shapes on the screen, he raised it, they got back something that blew up with >6 shapes on the screen...
19:08:58
aeth
Bike: Depending on your perspective. You the user can see intforms as keyword argument defaults of a MAKE-INSTANCE. That's certainly how SLIME exposes them.
19:09:15
Bike
okay, but that's not how sbcl does it, and in fact it's kind of impossible with how mop works
19:09:44
aeth
Bike: Yes, it would have to be checked in a different place, it is just, from the user's perspective, an extremely similar issue.
19:10:26
mseddon
drl: unless you changed your shell, it's usually .bashrc that configures your default shell (bash)
19:10:45
mseddon
drl: so if you add EXPORT SBCL_HOME=/path/to/your/sbcl/home at the bottom of that .bashrc
19:11:03
aeth
Bike: Sorry, I'm communicating it improperly. It's the same class of bug (a default value that cannot possibly be of the valid type, which when properly done should be a call to ERROR instead). It would just have to be checked differently.
19:11:55
mseddon
drl: for least confusion, check it works in a shell after you add that, and then log out and in again, in case some old programs didn't realise that SBCL_HOME changed.
20:05:33
mseddon
drl: np, make sure your shell environment is configured correctly, lisp requires this.
20:46:13
aeth
I personally just create a 3-line shell script (including #!/bin/bash in those 3 lines) in ~/bin to export SBCL_HOME and then call the SBCL executable from there.
20:48:08
aeth
drl: what I did to get it to work is this command: INSTALL_ROOT=/home/yourusernamegoeshere/.local sh ./install.sh
20:48:45
aeth
drl: and then in the script: export SBCL_HOME=/home/yourusernamegoeshere/.local/lib/sbcl
20:49:36
aeth
Installing to /usr/local is something I don't mess with unless I have no other option, e.g. stumpwm (since I need to launch it like any other WM)
20:50:09
aeth
Installing to ~/.local and putting the binary (or a trivial shell script, like I do with SBCL) in ~/bin tends to have fewer issues ime
20:51:34
aeth
The only catch is it might create files you want to exclude from your backups, like anything in ~/.local/lib and ~/.local/bin in this case
20:53:11
aeth
this might work in general to laucnh a custom, home-installed SBCL: export SBCL_HOME=~/.local/lib/sbcl && ~/.local/bin/sbcl
20:53:37
aeth
You might need to put the second part on its own line, though, idk edge cases in shell parsing
20:55:02
aeth
drl: afaik, stumpwm creates its own standalone executable when you install it, so even if you use the ~/.local/bin/sbcl executable, it will use that newer version to build the /usr/local/bin/stumpwm binary
20:59:24
drl
aeth, If i set SBCL_HOME to anything but asdf/quicklisp I get and error message when I start slime.
21:10:18
Nilby
drl: When I'm having such problems I usually make a new user, or use a "clean" with no files, and if it works there, then carefully and reversibly remove stuff from my environment until it works. Then I can maybe fix the problematic piece of setup.
21:13:18
drl
aeth, I followed you directions, and it installed. But now I get this error message: core was built for runtime "lat-l-2020-09-28-06-53-18" but this is "lat-l-2020-09-14-16-03-37"
21:30:28
aeth
drl: I guess remove and reinstall? My guess is the ~/.local/lib/sbcl and ~/.local/bin/sbcl are using different SBCLs for whatever reason... or, alternatively, the correct SBCL_HOME isn't being used