libera/#sicl - IRC Chatlog
Search
14:51:48
mfiano
CLPM can save you the trouble of announcing that, and contributors forgetting to do that, for all versioned dependencies.
14:52:47
yitzi
beach: Seems like not all of the gray stream protocol is implemented in Code/Stream. I am right in this? Asking because I would like to make this printer depend on gray streams so I can test elsewhere first.
14:54:39
beach
yitzi: Feel free to assume everything is implemented and use some more complete implementation for testing in the host.
14:54:42
mfiano
Yes. It's kind of unfortunate the Quicklisp model has made us more lazy developers. Having Xach handle releases with such a large period just puts more burden on developers, especially when something as important as compatible dependencies can only be handled by the developer.
14:57:39
beach
mfiano: I don't know enough about the problem that CLPM solves, so I am not sure what this means.
14:58:26
mfiano
The Common Lisp foundation has been recently talking about backing the project after the recent article was published that explains just that.
15:01:44
beach
I do think it is a good idea to plan for the end of what Xach is doing. He may very well decide to do something else some day, or something might happen to him. We would need a backup plan then.
15:07:49
mfiano
This post is mostly about the CLPI metadata format, rather than CLPM itself, but still gives an idea of the kinds of problems it solves.
15:08:12
mfiano
Noteably, giving developers the power of when to release, and their users the power to automatically aggregate the correct dependencies/versions
15:10:07
mfiano
Very few projects make proper releases, with changelogs, etc. They just push to git, and wait for Xach to distribute their work at some random time in the future.
15:18:02
mfiano
THe developer writes a s-expression-based manifest file listing the dependencies, where they can be fetched (local, github, gitlab, quicklisp, etc), and their versions (quicklisp dist version, git commit hash, git tag, etc), and then upon "installing" this manifest, these direct dependencies are fetched, and their asd files are grovelled to pull in indirect dependencies.
15:19:06
mfiano
It configures asdf in such a way that you can switch to different contexts. So you could switch to another project, or another manifest of the same project.
15:20:27
mfiano
When the developer "installs" the manifest, it creates a lockfile with the exact recipe to install the exact versions the developer has. This lockfile should be checked in to git, as it is all a user needs to reproduce the build with the correct versions the developer tested with
15:22:44
mfiano
It's not for everyone yet. It is a bit of extra work on the developer, but it's work that in my opinion should already be in a developer's workflow. This is the social problem I was talking about.
15:25:18
mfiano
For example: If a developer needs to issue an important hotfix, their only choice is to push a commit and instruct their users to manually clone it, and place it in Quicklisp's local-projects directory to override the dist version.
15:25:30
beach
My main problem is that I am not working on projects for general consumption, and the one I am working on (SICL) should not be used by anyone except the developers at this point. So I have not taken the time to organize things so that there will be any smooth installation.
15:26:17
mfiano
Now, all those users have to pay attention to their local-projects directory. When they update Quicklisp a next time, that old version will be the one used unless they clean up later. This is something that should be automated and under a developer's control...not a user's.
15:26:25
Bike
you could still use it yourself. e.g. if i got to using clpm for ctype or whatnot you could somewhat protect yourself against my doing destructive api changes
15:27:55
beach
I would rather just apply my expertise to my current project, but I guess the fact that I depend on other libraries is already making it necessary to do something else.
15:28:51
mfiano
Yes even if _you_ are the only consumer, having a dead-simple way to depend on ctype git commit f00 is a nice thing to have.
15:31:12
Bike
as of now, ctype has no external dependencies, so maybe a clpm whatever file could be easy to write. on the other hand, it does implementation-specific hooie
15:31:20
beach
This stuff is precisely the kind that I could use help with, and it is always precisely the stuff that I have to do myself. So it's a curse. The one person who knows the most about the internals of SICL must work on something else.
15:31:33
mfiano
Well this model is not for everyone, and not for most CL users. It isn't like most languages, in that most CL code is for personal use, and doesn't have many consumers, if any besides the main developers. This is why I believe the "lazy Quicklisp" way works and people don't mind that the control given by most other languages' workflows is taken away from them.
15:32:31
shka
for instance, i ended up writing docker file that populates the local-projects manually
15:32:36
mfiano
For this to be successful there needs to be education on why it is good for the developer to have these knobs rather than some centralized automated thing
15:36:21
beach
Well, no, I can't say I do. What I really want is for someone else to do the SICL project management, but, again, that doesn't seem to be a choice here.
15:38:20
mfiano
Maybe it would be worthwhile to set up a donations page or something, and funds could go towards someone helping you with the menial tasks.
15:39:22
beach
I have considered that, but even when I offer money, it is nearly impossible to find people, so I think setting up such a page would be even more crap work with no result.
15:41:19
mfiano
I am guilty there. I didn't intend for this new medication to make it so difficult to computer for very long, not to mention program.
18:00:32
Duuqnd
I've been thinking about how to implement the random-state type. My first thought was to just make it a class, but then I read that random-state must be able to be printed and read back in. SBCL does this by simply having random-state be a struct, but I'm not sure what to do here. I could make it a struct, but I'd like to hear more opinions.
18:03:58
Bike
i don't think readability should be a factor there. even without a custom random state reader syntax you could just use #., and in fact now that i'm looking at it sbcl uses #. within the struct anyway
18:06:17
Duuqnd
Yeah, I thought about using #. but I'm not sure what exactly would come after that. A (make-instance 'random-state) or similar?
18:11:18
Duuqnd
It could be something like #.(sicl-random:make-random-state ...) except the name "make-random-state" is already taken by CL so it would have to be called something else.
18:15:19
Duuqnd
I initially didn't want to do that because it would be ugly, but really, nobody prints a random-state to admire it, all that really matters there is that it can be printed and read.
18:16:02
Bike
yeah, since the standard just says it has to be readable without actually explaining any details, a program that does anything with it but READ isn't portable anyway