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.
21:46:41
nij-
AeroNotix: Yeah, in the end I just want content-addressability. This is how the functional package managers work.
21:47:16
nij-
AeroNotix: I want to first understand why this isn't what's wanted in the major build system (asdf).
21:47:17
AeroNotix
summing up the answers so far: ASDF doesn't have this functionality and it appears it does not intend to grow the functionality.
21:47:51
nij-
AeroNotix: Well, in asdf3 they introduced version-specifier.. maybe hash-specifier or other type of content addressing tools are to come.
21:48:20
AeroNotix
yeah again, not sure if you understood what I mentioned - the string format the version takes really isn't the important part
21:49:16
AeroNotix
things being content-addressable make it seem super duper megawow important, but ehh... ? Not really.
21:49:22
sveit
is there a way to get the "~G" format directive to not output trailing spaces? it seems in the spec that there is some "ee" parameter which gets used as "~ee@T" and "ee" is always set to at least 2.
21:50:39
AeroNotix
my main concern isn't around what the version string is, but rather, does the store that hold the code even still exist
21:50:53
etimmons
My personal opinion is that such a thing belongs outside the ASDF system definition
21:51:35
nij-
etimmons: Got it. I respect that. I'm just curious why they also don't think it's a nice idea to use hash-specifiers.
21:52:06
etimmons
A sufficient reason to not include it is how do you reconcile two systems that depend on the same system but at different versions/hashes
21:53:45
qhong
FYI: I just tried loading hunchentoot 1.2.0 (from ~10 years ago). Loads fine, I run (asdf:test-system "hunchentoot"), test fails
21:55:34
qhong
I'm afraid contemporary projects based on ASDF will not work after a dozen of years, totally unlike the projects 40 years ago
21:59:53
qhong
etimmons: it can be done, at least for systems that don’t do wacky stuff like introspecting symbol-package. `rename-package` hack
22:02:24
mgl
Is there a way to get the default values of &optional and &key arguments of a function on CCL?
22:05:59
_death
qhong: so why do you say "based on ASDF"?.. besides, saying they're "based" on asdf is a bit of a stretch.. sure, they have an .asd file and old projects may have had a different defsystem file, but that doesn't mean they're "based" on it.. the actual difference between hunchentoot and the older projects is the number of dependencies
22:07:14
_death
qhong: many old projects are self-contained.. some however depend on mcclim or genera code or whatever, so those are less likely to work without changes
22:08:17
qhong
I still think this should and can be fixed, say, if projects document the exact version of their dependencies, so that a working system in the past can always be reproduced in the future
22:17:15
random-nick
I agree it would be nice if CL library releases would include a file which lists versions of their dependencies at the time of release/testing
22:17:59
random-nick
however I don't think it should be respected by default because of the version conflict issue
22:18:56
phoe
...or they try to be fully backwards compatible, which limits the amount of damage that non-versioning can do
22:19:31
EdLangley[m]
I sort of think the best thing to happen to a CL package is for it to be basically done and then become unmaintained
22:24:22
_death
well, I'd say that even if the interface is not perfect, there are usually many improvements that can be made on the implementation side.. and exposing a new interface without breaking the old one is often possible too.. these things take more effort and imagination and require an anti-churn attitude that respects users.. and outside CL all kinds of pressures lead to the opposite attitude
22:25:10
EdLangley[m]
But, it seems to me like maintainers often get sort of bored with something that works and then start breaking it
22:25:40
AeroNotix
EdLangley[m]: it's just the reasons for the rot are irrelevant to CL because CL itself is unchanging
22:25:58
AeroNotix
and that's not necessarily a good thing, but it is a benefit of basing your project on CL
22:27:21
AeroNotix
I've said it previously when this channel was on freenode but imho CL is in need of a modernized standard
22:28:02
AeroNotix
on the face of it CL being so set in stone itself seems like a good thing but you end up with balkanization of useful features when they are implemented in poor libraries
22:28:20
moon-child
EdLangley[m]: it would be better if those portability libraries were standardised
22:28:31
EdLangley[m]
So, I've seen python people say things like "the standard library is where libraries go to die"
22:28:45
AeroNotix
Modern concurrent programming is, imho, a large feature which CL lacks. Libraries are all over the place and maintained by the few, pushed to the limits by no-one
22:28:47
phoe
if we had a standardization committee member every time this topic was mentioned then we would have multiple X3J13 by now :D
22:29:07
AeroNotix
and if they are reasonably halfway decent, they're supported by only a couple of implementations
22:29:30
AeroNotix
imho the fact CL is so stagnant is a big part of why its popularity stays so niche
22:30:04
EdLangley[m]
As far as threads goes, the implementations implement threads and the portability library standardizes the interface
22:30:07
_death
what may be good is more specifications (extensions to the standard) that are agreed upon and implemented by lisp implementation vendors.. but it requires $$$.. if only there were some rich Lisp people who were interested in pursuing this ;)
22:30:43
moon-child
EdLangley[m]: the interface is not standardised to the level of quality I would like
22:32:15
AeroNotix
my suggestion is that no standard in a platform and community such as CL's leads to terrible balkanization where no-one is the winner
22:32:33
EdLangley[m]
It's a bit strange to complain about the standard causing stagnation and then suggest standardizing more things would help
22:33:03
EdLangley[m]
So, if we come up with better interfaces and/or techniques, they can only be implemented as libraries on top of the standard
22:33:05
AeroNotix
EdLangley[m]: I think standardization is good, and CL in particular lends itself well to that model
22:33:28
EdLangley[m]
Which, to me, suggests we make the standard as minimal as possible to support a healthy library ecosystem
22:33:53
EdLangley[m]
And have libraries to sort out the vendor extensions into things that are portable between implementaitons
22:33:53
moon-child
sure. For many things that works. But, again, _threads cannot be implemented as a library_
22:33:54
AeroNotix
my opinion is that because the standard is coming up on quite literally 30 years old, it's missing out on a lot of progress
22:35:28
AeroNotix
EdLangley[m]: we have the situation you mention, 'standard as minimal as possible'
22:35:37
moon-child
sure. Where is my memory model? Can I be sure that abcl, ccl, and sbcl all implement the same semantics?
22:36:03
phoe
I think this problem is always answered best by "who's supposed to do this and who's supposed to pay them"
22:38:38
phoe
"it would be nice if CL had a revised specification" is a truism; the real meat of that issue is who are the people and whence comes the money, everything else has already been said probably hundreds of times before
22:39:11
phoe
and until this meat has an appropriately meaty answer we are bound to repeat history, except as farce
22:40:57
contrapunctus
Maybe it's time to start something akin to XEPs and SRFIs? Sounds like that way the existing standard remains untouched, but there's a library standardization process...
22:44:01
_death
EdLangley[m]: the updates could constitute clarifications etc. like WSCL.. but there's a lot of room for new specs, some of which don't actually require participation of lisp implementation vendors, but may require participation of lisp library writers in particular fields
22:44:43
AeroNotix
I personally wouldn't care which form it takes... the above sounds reasonable to me
22:45:46
AeroNotix
my point is more that people are off in the weeds implementing modern tooling on 30 year old software
22:46:10
AeroNotix
and we have pockets of brilliance which are tarnished by the fact there's no cohesion between any thing
22:46:22
contrapunctus
phoe: even append-only is fine, I guess, since newer ones can supercede older ones. cf. XEPs - each one gets a new number, it's just that the older ones are rarely changed and the current set of relevent XEPs changes; the older, deprecated XEPs don't go anywhere.
22:46:40
AeroNotix
libraries fester, are incomplete or lack the performance or usability required because implementations are well, 30 years old and are unchanging to their needs
22:46:44
_death
again, this requires time and will, and the fuel is $$$.. PG went back to roots with Arc and Bel.. maybe someone should point out that the next language starts with the letter "C" :).. there are potential patrons for such a process who were (or even are) part the Lisp world.. I dunno why, but I've not seen any of them talk about that, though they usually do show some interest in Lisp
22:48:20
fe[nl]ix
if you look at past documents, they were introduced and marked as "final" within a month
22:50:56
contrapunctus
fe[nl]ix: hm...did implementation maintainers not participate in the CDR process? And did nobody request or aid CDR implementation? 🤔️
22:50:59
EdLangley[m]
If we have the library and it's implementable on top of what existing implementations provide, it's mostly fine
22:59:29
_death
fe[nl]ix: what's interesting though is that something like PLN, which has no real specification, was implemented by several Lisp vendors..
23:00:39
fe[nl]ix
and yes, there was enough demand that mostly similar functionality was implemented
23:01:33
fe[nl]ix
if you take a look at https://github.com/phoe/trivial-package-local-nicknames/blob/master/trivial-package-local-nicknames.lisp
23:03:54
fe[nl]ix
EdLangley[m]: most of the things that are important require changes to the implementations
23:04:50
_death
right, so this could be a first target.. the variants are not too different, and it's recent enough, and could improve via pressure of standardization
23:04:58
fe[nl]ix
I'm working on making Bordeaux-threads APIv2 as good as possible, with lots of tests but there are limits
23:05:28
moon-child
(well. I guess technically you can also do completely portable reader, and your own PLN. SO maybe it does not signify much)
23:05:44
_death
(btw personally I don't use PLNs.. I just give it as an example of something not too complicated that's ready for standardization)