freenode/#lisp - IRC Chatlog
Search
22:23:26
Gnuxie[m]
yeah that, i didn't know it was possible to uhh copyright your irc talkings though and stop people opening issues just because you said it
22:24:01
aeth
Gnuxie[m]: probably allowed under fair use, but there was quite a bit of text here so I was just being safe.
22:25:20
aeth
I'm not a lawyer, but afaik everything you write is automatically copyrighted by you without you having to claim it with e.g. © or (C).
22:26:19
aeth
That's why code without a license is treated as all rights reserved instead of public domain.
22:29:48
White_Flame
huh, I remember getting errors/warnings of this sort of thing a while ago already
22:30:46
White_Flame
as in a few years ago. It must have only been supported in a few places and is spreading now. IIRC, it was struct slots that bit me
22:33:32
aeth
< Xach> hmm, failures with latest (ish) sbcl from git - another increase in type derivation strictness i think? http://report.quicklisp.org/2020-08-29/failure-report/claw.html#claw is one example, many seem to be due to slots with a declared type but a NIL initform.
22:39:16
aeth
So then a patch to swank to hide ERROR verbosity and an update of all library code with invalid default NILs will happen before anyone really notices it.
22:40:31
aeth
I guess I'm going to have to compile the latest SBCL and see which parts of my code break (probably more than I expect)
23:04:37
rumbler31
reason why I'm procrastinating my python homework, I'm busy trying to import functools and read the docs on the reduce because I miss lisp and want to run a higher order function on an array
23:31:34
aeth
Wow, I was getting really excited by the changes in the latest SBCL, but, no, unfortunately it still does not check :type in default optimization levels in DEFCLASS, e.g. (defclass foo () ((%foobar :initarg :foobar :initform nil :accessor foobar :type fixnum)))
23:31:58
aeth
It will now warn that NIL isn't a fixnum, but it won't actually stop you from doing (make-instance 'foo :foobar "hello") thus keeping :type absolutely useless on the implementation that 90% of people use
23:32:53
no-defun-allowed
I think that the latest SBCL broke decentralise2 dispatch maybe (but it's fair because I mixed compilation/evaluation environments). That was fun.
23:33:34
aeth
well, it broke cl-autowrap, which was fun, because I had to override it with the git version so I could even test to see if anything new showed up in my game engine when I loaded with :verbose t (nothing did)
23:33:55
no-defun-allowed
No, I don't think SBCL changed anything for that to happen, but it did happen, and I can't complain really.
3:29:27
beach
phoe: By the way, I can prepare a presentation for a week from tomorrow (or later) in case you have no other candidates.
8:43:16
pve
but it's not clear to me why (shadow 'array) leads to that weird behaviour, because reading the hyperspec entry for shadow, I get the impression that it should work
8:47:03
pve
are all the references to the symbol "ARRAY" stored "in one place" in the fasl, so that when the fasl is loaded, LOAD sees 'array (i.e. CL:ARRAY, before shadowing) and then assumes all ARRAY symbols in the fasl are the same?
8:49:42
beach
The symbol ARRAY already exists in the cl-user package, so it is going to use the pre-existing symbol.
8:52:13
beach
The name is a designator for a string, so only the name of the symbol matters if you give it a symbol.
8:57:56
pve
but why then, does it print COMMON-LISP-USER::ARRAY if I load-compile from slime (C-c C-k)?
9:17:36
pve
beach: ok, so the discrepancy must have been caused by something I was loading into my slime session (need to investigate that), because if I compile and load my example from the shell without loading any init files or libraries it prints COMMON-LISP-USER::ARRAY in both cases
9:18:39
phoe
I mean, PACKAGE-NAME SYMBOL-PACKAGE should *not* return CL-USER in this case because ARRAY is imported from CL
9:21:11
no-defun-allowed
The two (or three?) means of compiling and/or loading that code appear to do different things though.
9:22:05
phoe
"For each such name, if a corresponding symbol is not present in package (directly, not by inheritance), then a corresponding symbol is created with that name, and inserted into package as an internal symbol."
9:27:06
White_Flame
hmm, nevermind, I think that the eval-when should guarantee the shadowing before the format expression is read
9:28:22
White_Flame
this is why it's important to have a separate package.lisp to set everything up in a separate file
9:29:22
phoe
the SHADOW call should be a part of DEFPACKAGE, that's my only real gripe with this code
9:31:08
pve
my original problem was probably caused by some package-fu I'm doing in the project I'm working on
10:09:02
beach
Am I reading the dictionary entry for DEFCONSTANT right in that the constant is not defined at compile time?
10:09:46
beach
It says that the compiler must recognize that the name names a constant variable, but not that the value is available at compile time.
10:11:14
phoe
"An implementation may choose to evaluate the value-form at compile time, load time, or both."
10:11:43
phoe
if the value is allowed to be available only at load time, then it may *not* be available at compile time
10:12:24
phoe
it is allowed not to be available at compile-time, BUT it also says that this behavior is implementation-dependent
10:12:46
phoe
so as an implementer you can do e.g. what SBCL does which is to EVAL-ALWAYS %DEFCONSTANT
10:13:15
phoe
but it seems that as a user you cannot really depend on the constant being available at compile time.
10:13:19
beach
Right, so a file containing (defconstant bla ...) (defun foo (..) bla) may or may not work.
10:14:21
phoe
"If a defconstant form appears as a top level form, the compiler must recognize that name names a constant variable."
10:16:39
phoe
but this way is trivial to implement and preserves language semantics, since constant redefinition is undefined