freenode/#lisp - IRC Chatlog
Search
12:42:26
dim
how do you typically add (local) projects to ASDF/QL? I'm used to playing with asdf configuration files, but I'm now wondering if there's an easier way to do it?
12:46:40
pjb
dim: nowadays, the easiest way is to put them (or a symlink) in ~/quicklisp/local-projects/
12:47:40
pjb
Otherwise, as one-shot: (pushnew #P"/path/to/your/project/dir/where/the/asd/file/is/" asdf:*central-registry* :test 'equal) (ql:quickload :your-project)
12:49:21
dim
I mean it loads #P"/Users/dim/quicklisp/dists/quicklisp/software/pgloader-v3.4.1/" rather than ~/quicklisp/local-projects/pgloader
13:45:03
phoe
Let's suppose that I have a protocol, which includes a protocol class. Each class participating in the protocol must subclass this protocol class.
13:47:22
phoe
I have created such a participating class, and I decided to write some tests for it. And, at this point, I had a doubt. Since I will be testing the class's participation in the protocol, this means that my tests will be limited to the operations listed in the protocol, and therefore will not really be specific to this concrete class. They will be testing the protocol itself.
13:48:40
phoe
And this means that these tests should be valid for any class that participates in the protocol. At which point, I wondered - can I just grab all (in)direct subclasses of this protocol class, and run tests on these concrete classes?
13:49:46
phoe
I can use CLOS and MOP to grab all (in)direct subclasses of a protocol class, and I can run these protocol tests on each of these classes. My question is - does this approach look sane? Or do I have some error in my thinking somewhere I can't see yet?
13:54:12
beach
phoe: The test will be specific, because there will be methods on the operations in the protocol that are specialized to the concrete subclasses.
13:54:46
Xach_
dim: because there is normally no way that a quicklisp directory system would take precedence over a local-projects system
13:55:08
beach
phoe: Obviously, if your subclasses participate in other protocols as well, you need to write separate tests for the operations in those other protocols.
13:57:15
phoe
beach: I'm still digesting the "there will be methods on the operations in the protocol that are specialized to the concrete subclasses" part.
13:57:55
dim
I think it's easy to reproduce. git clone https://github.com/dimitri/pgloader ~/dev/pgloader (or somewhere else), then ln -s ~/dev/pgloader ~/quicklisp/local-projects, then (ql:where-is-system "pgloader")
13:58:40
phoe
I have a protocol class FOO, with a method BAR invoked like (BAR FOO). I know that method BAR will always return a string; the contents of that string may vary from concrete class to concrete class, but the protocol says that it will always be a string.
13:58:44
dim
(maybe the ln has to be tweaked to work, I did it differently and just wrote the steps from memory, trying to adjust them to another env, etc)
13:59:53
beach
phoe: So if you have a concrete subclass of FOO, like BAZ, clearly, you will have a method on BAR that specialized on BAZ, or else you wouldn't need the concrete sublass.
14:00:31
beach
phoe: And this method will be run, i.e. tested, when you execute BAR with a BAZ as its argument.
14:01:06
beach
And that's all that is required when it comes to the participation of BAZ in your protocol, so you are done.
14:01:15
phoe
If I have another subclass, QUUX, then (BAR QUUX) should also be tested with this test that I wrote. This is my thinking right now.
14:01:57
phoe
Like, if QUUX is a subclass of FOO, then it means that (BAR QUUX) should return a string, therefore the test I wrote before works also for QUUX.
14:02:00
beach
Sure, you need to run the tests for all possible subclasses, but that's not something to put in the protocol. The protocol can't possibly "know" how to create instances of those classes.
14:03:57
phoe
So client code can prepare the instances of those classes in any way it wants, and then it can invoke tests that are bundled as a part of the protocol, and pass those instances to the tests as a parameter. Is this correct?
14:06:18
beach
That would certainly be possible, yes. The protocol library can then contain tests that make sure that those classes respect some of the invariants that it defines.
14:06:55
phoe
The concrete classes can contain their own tests for whatever specific functionality the concrete classes provide.
15:01:19
dim
ccl and sbcl alike? (that might be the difference here, otherwise if you're interested I will nuke my asdf setup and reproduce)
17:52:37
jmarciano
for some reason I cannot connect to #emacs, so maybe here somebody knows how to (read from file in Emacs?
17:53:32
jmarciano
I am doing (with-temp-file *my-activity-file* (insert (prin1-to-string data))) while data is hash
18:45:04
pfdietz
If you just want to serialize and deserialize lisp objects to/from a file or stream, but not in readable format, then something like cl-store would be what you want. https://common-lisp.net/project/cl-store/
20:18:15
makomo
hi everyone, i'm using SLIME and have an ASDF system that has been loaded (created with quickproject). if i add to DEFPACKAGE a list of nicknames, what's the right thing to do for this change to take effect?
20:18:56
makomo
am i supposed to just re-eval the DEFPACKAGE form (not sure if that's legal)? or should i somehow reload the ASDF system?
20:23:24
makomo
rpg: from what i can see in CLHS "If the new definition is at variance with the current state of that package, the consequences are undefined; an implementation might choose to modify the existing package to reflect the new definition."
20:25:58
jackdaniel
makomo: since you are in development phase, you may see what implementation does and decide, if this is good enough for you
20:27:13
rpg
makomo: I've only ever done this with SBCL and ACL, which both seem to Do The Right Thing. Note that some changes like *removing* an export might not be reflected properly. But adding a nickname should not be a "demanding" change for the implementation.
20:29:40
rpg
Personally, I tend to do a lot of incremental compilation, and avoid full ASDF rebuilds for long periods of time. Old habits from developing systems that have complicated internal state that I don't like to destroy and rebuild
20:50:26
Fare
the bug I reported this week (based on a a sly issue) is pretty damning and must be fixed in next release
20:51:01
Fare
I'll try to do an interactive session where I reproduce the bug, add a test case, and hopefully fix the bug before I send an MR.
21:29:51
phoe
So i no longer have a ~/quicklisp directory lying around after a default installation.
21:30:53
phoe
removing an export causes warnings on SBCL, "package FOO also exports the following symbols: BAR, BAZ, QUUX, ...", and the compilation fails.
21:56:11
PuercoPope
phoe in sl{y,ime} you can do C-c x with a negative argument to unexport it automatically (and remove it from the defpackage