freenode/#lisp - IRC Chatlog
Search
5:14:20
Xach_
i wrote my own sha stuff for quicklisp's pgp verification. have not done hmac. tempted to spin it into its own library.
5:16:36
drmeister
Clasp struggles mightily to compile ironclad because of terrible scaling in llvm and slowness in the Clasp runtime and Cleavir (working on it).
5:17:00
drmeister
I got so desperate I added C++ header libraries for hashing and hmac and exposed those functions.
5:17:38
Xach_
drmeister: not a bad approach in a pinch. better than having a terribly slow runtime for those too.
5:22:39
loke
drmeister: What is it about clasp that makes is particularly slow for Ironclad? I mean, Irconclad is always slow to compile, since, as I understand it, it generates a lot of code through macros.
5:23:55
drmeister
I haven't drilled into it carefully to figure it out and so I have to be careful where I attribute blame. It takes something like 7 hours to compile full ironclad.
5:24:12
beach
loke: My personal guess is that the Cleavir-based compiler does not yet implement most of the planned optimizations, so the entire native code base is just not good enough.
5:24:31
drmeister
Some of the time is in llvm - we know that it has terrible scaling for large functions.
5:26:08
beach
loke: The theory that the Cleavir-based compiler has some bottlenecks because it is using a lot of generic functions might be somewhat true, but I think it would be counterproductive to look for such bottlenecks before the optimizations are implemented.
5:27:36
beach
loke: But yeah, there is also the LLVM possibility. Many compiler optimization techniques require quadratic time in the size of the code, so if code is generated using macros, then that could very well be a big problem.
5:28:37
loke
I thought that ironclad generated massive functions, but I have to admit that I have never actually confirmed the sizes myself. So some of it could be just assumptions.
5:30:19
loke
drmeister&beach: How fast is ironclad running in Clasp after this 7 hour compile? Is the generated code any good?
5:30:55
drmeister
Yeah - that's fine. I haven't benchmarked it - but I haven't noticed any problems.
5:31:05
beach
loke: Like I said, the code generator of the Cleavir-based compiler is not good enought.
5:32:02
beach
loke: So that affects both the execution time of code that is compiled with it, and, of course, the time to execute the compiler itself, because that code is itself compiled with the compiler.
5:32:07
drmeister
I dunno beach - this looks like some n^m power scaling with the size of the function.
5:33:56
drmeister
I've been using it a lot interactively - the performance is good enough for what I've been doing.
5:44:37
drmeister
Is it typical for compilers to decide NOT to inline code if the resulting function becomes too large?
5:45:59
beach
Usually, inlining is done against some kind of "budget", and size is one consideration. In fact, the cost function typically reflects the cost of further optimizations, so it might take the size squared.
8:05:25
jasom
drmeister: one amazing optimization if you have whole-program information is to inline all functions that are called exactly once. It makes the code smaller and run faster.
8:07:43
jasom
drmeister: llvm normalizes code to SSA form. This can have a quadratic effect on code size.
8:08:30
jasom
code size for the intermediate representation that is; it gets reduced to something sane after optimizations, but the optimizations themselves run on the quadratically larger IR stream.
8:43:00
ym
I got "Invalid SB-MOP:SLOT-DEFINITION initialization: the initialization argument :NAME was constant: :OK." condition.
8:57:01
beach
Slot names are implementation details that should be private to the module in question. By making them keyword symbols, they are automatically exported to the entire world, so that you have no protection against (setf (slot-value obj :OK) ...)
8:59:28
beach
The :name argument is a slot name. An error is signaled if this argument is not a symbol which can be used as a variable name.
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)