libera/commonlisp - IRC Chatlog
Search
14:56:41
phoe
Which part of the specification mentions that (MULTIPLE-VALUE-CALL (LAMBDA (ONE TWO) (LIST ONE TWO)) (VALUES 1 2 3)) should be an error?
15:12:23
ns12
Is it valid to add a particular keyword to *features* more than once? e.g. (push :foo *features*) (push :foo *features*)
15:17:04
ns12
Is it conventional to prefix custom feature symbols with the name of the library that adds the feature symbol to *features*?
15:47:41
_73
The symbol that denotes the condition type is internal, so I get an undefined symbol error.
15:48:49
beach
Symbols can not be undefined. If the symbol is internal, you need to use a double package marker to refer to it. That's not great with respect to modularity, but that's what you need to do.
15:49:14
pjb
You don't even have to use the right symbol in the handling form, if you know a superclass of those conditions that is named in another package!
15:50:03
pjb
(define-condition foo::condi () ()) (define-condition bar::error (foo::condi) ()) (handler-case (will-signal-bar-error) (foo::condi (err) (handle-bar-error-here err)))
15:50:12
_death
you can also consider whether the name should actually be external and if so export it and possibly submit a patch
15:53:29
phoe
maybe the condition itself is something like si::simple-reader-error and you are actually supposed to handle cl:reader-error instead
15:53:56
phoe
or maybe somebody forgot to export the condition name/accessors if it's some publicly available library, which would warrant a bugticket
15:55:23
phoe
in particular, package LEXER should export lex-error along with lex-error-{reason,line,source}
15:57:02
phoe
for whatever reason people tend to forget that conditions and their accessors are also a part of a library's API
17:05:15
huckleberry
Are bit-vectors and bit-xxx ops worth using over their logxxx counterparts if I'm planning to convert the result into an integer? I've got an algorithm I can make far simpler with a vector but it's invoked so often I have efficiency concerns
17:11:32
phoe
unless your bit fields are going to be longer than a machine word, at which point it might be useful to have these rather than bignums
18:27:07
gamaliel
Hi, common lisp newbie here. Is it possible to do (ql:uninstall) on a system plus its dependencies? I'm kind of confused by the information I've been looking online.
18:28:07
gamaliel
@Xach: I was testing out a system that turned out not to be the one I needed. So I want to purge the system from it, plus any systems it may have installed.
18:30:10
Xach
gamaliel: there isn't a short way to do it, sorry. possibly the easiest thing is to delete the "installed", "software", and "archives" directories in ~/quicklisp/dists/quicklisp/ - this will clear out everything.
18:31:10
White_Flame
I presume QL doesn't track which systems have been explicitly vs dependently downloaded
18:32:08
_death
a cheap way that still offloads some management to the user could be to have a quicklisp.log that contains "installed foo" entries
18:33:11
gamaliel
I think I found something that could help: ql-dist:dependency-tree. I checked on it and it seems to provide *all* dependencies. I guess it's a matter of choosing the ones to uninstall.
18:34:15
White_Flame
and if you uninstall too much, your normal QL dependencies should reload what's needed anyway
18:34:48
White_Flame
should download the exact same version as you had before, unless you upgraded the dist
21:05:29
nij-
Does ASDF support customizable fetcher? Something like (:depends-on (nyxt :host github :repo "atlas-engineer/nyxt" :hash "0a9sd0a9sd"))
21:06:59
nij-
That CL is frozen in time provides the community a chance to make use of code written 30 years ago. However the liquidity of dependencies may break this.. thus the question.
21:15:24
nij-
I really hope any code in CL could still easily work in the far future (assuming the code and all its dependencies still exist).
21:16:56
semz
https://asdf.common-lisp.dev/ suggests that it's considered out of scope (which makes sense to me)
21:22:26
qhong
I do see a problem here. Seems that asdf specifies dependencies only with name, but with no version information? (at least I don’t see people writing such in asd) Then in the far future, systems might break because of accumulation of tiny incompatible changes in their dependencies
21:25:41
nij-
qhong: As suggested by semz, it seems that asdf dev team doesn't think it's an issue (at least for asdf to solve).
21:26:12
nij-
But indeed, that does break the dream of having codes that work *forever* (assuming existence, again).
21:28:09
qhong
I hardly see it in use though, and seems that it only ensure newer version (so not exactly solving the bit rotting problem)
21:31:52
nij-
qhong: Hmm...... I only see version-specifier - https://asdf.common-lisp.dev/asdf.html
21:32:27
EdLangley[m]
Which results in things like pip and npm where people just go around breaking things
21:34:28
EdLangley[m]
External symbols that name functions should only change behavior in strictly additive ways
21:35:40
EdLangley[m]
Yeah, and my point is, as a community, if we expect libraries never to push breaking changes, then we set up incentives to keep it that way.
21:36:05
qhong
EdLangley[m]: There’s no such thing as strictly additive. E.g. I might rely on a specific function to produce an error, and a later version that does not produce error breaks my code
21:39:06
EdLangley[m]
Well, my view is that if you’re depending on unspecified behavior, breakage is your fault
21:40:07
qhong
EdLangley[m]: I also run 40 years code from say CMU AI repo just fine, but that’s because there were no ASDF, and they are self containing tarballs using `load`
21:40:37
nij-
Yeah, things like this is very secure, and will ensure the code to keep working 50 years later. How sexy is that?
21:41:54
nij-
EdLangley[m]: You cannot expect every major libraries to behave as you wish in your ideal for 50 years, can you?
21:42:23
qhong
moon-child: ha, like “wiki-based development” which got brought up over and over again on LtU?
21:43:32
nij-
But currently there are lots of libraries written that only acquired little popularity.
21:43:54
nij-
If you want those to grow incrementally, the better way is to come up with a way that encourages people to use and extend it.
21:44:10
phoe
if by "usable libraries" you mean "not broken by the developers" then I think it's actually the reverse
21:44:16
nij-
If the main building system in CL doesn't encourage that, those will be harder to be used.