9:27:27clintmIf I have two structs both with a slot of the same name, and I call the slot accessor function from one on an instance of the other, that's supposed to be a type error, right? If so, does allegro really just return nil?
9:28:47clintmI tested it in a bare alisp repl, but I'd like cofirmation before I plant a proverbial flag in the sand and say "this is bad and we shouldn't do it" at work.
9:29:56flip214clintm: for classes there's the generic function and methods framework. for structures the structure name is prepended for accessor names to avoid such conflicts.
9:32:57clintmbeach: because it's two different types, at least that's what I assumed. (defstruct a id) (defstruct b id) (a-id (make-b)) -> nil. Should that really be nil? On LW it's a type error.
9:33:02beachOh, type error because you are giving it a struct of a different type. Got it.
9:33:10clintmI mean, I assumed it would be a type error.
9:34:01beachStructs are designed to be fast. It wouldn't surprise me if the accessor does nothing other than access an element with a particular index.
9:37:57flip214clintm: on SBCL I get The value #S(B :ID NIL) is not of type COMMON-LISP-USER::A
9:38:11lievenan implementation is certainly allowed to carp but I don't think it's required
9:38:22clintmflip214: That's what I got with LW as well.
9:39:08clintmHrm, maybe if I scour the allegro docs I can find a way to turn it on even if just during testing and development. Thanks for the info, everyone!
10:00:30Haragis there a "prefered" "portable" pretty printing library out there that deals with writing the likes of clos objects and hashtables as readable, even if it is just readable by itself
10:01:39phoeI have phoe-toolbox:print-hash-table-readably for hash tables
10:02:26phoeand also possibly phoe-toolbox:print-instance-readably that tries to be DWIMmy in what it does
10:02:37phoeand therefore can miserably fail if one doesn't know what they're doing
14:31:17flip214yeah, but the arithmetic on them might be broken
14:37:49phoehuh, 18th Jan should still fit within Y2K38
14:38:30Xachflip214: oh, i would just stick with gzip, since i already have the code for it in the client.
14:42:50flip214Xach: https://paste.debian.net/hidden/6b51c5a0/, both with best settings (gzip -k9, brotli -kZ)
14:42:57flip214don't know how expensive bandwidth is for you
14:43:41flip214about 20% smaller, but of course I understand the convenience of having the unpacker already available
14:43:55Xachflip214: that looks promising, do you have brotli decompression code in CL?
14:50:13flip214Xach: use zopfli then. https://paste.debian.net/hidden/72cd504f/, decompression compatible with gzip - in fact, it creates .gz files by default.