freenode/#sbcl - IRC Chatlog
Search
11:30:20
pfdietz
Bug space is mined out, at least those parts the current random testers can sample. Except for dynamic extent bugs, but no point in finding the same problem there over and over (and ir1-copy bugs).
14:07:11
makomo
hello. does anyone know why this doesn't signal an error? (defgeneric test (a b &rest c)) (defmethod test (a b &key c)) (test 1 2 :d 100)
14:08:35
makomo
case 4 talks about an implicit :allow-other-keys t keyword argument, but i don't think case 4 applies here, since my generic function doesn't have &key in its lambda list
14:09:05
makomo
for regular functions however, this would signal an error: (defun test (a b &key c)) (test :d 100)
14:10:04
makomo
the last sentence of case 4 would explain this behavior, but as i said, it shouldn't be applicable in this case. or is that last sentence a general fact maybe?
14:18:09
Xof
makomo: I won't argue very strongly here, but if I had to defend the current behaviour I would say that "the generic function itself checks the allowable keys" and "the generic function by having &rest in its arglist accepts all keys"
14:18:50
makomo
Xof: that's what i'm thinking too, but apart from the last sentence of case 4, i can't find anything else that would suggest that behavior
14:21:38
Xof
Since the (&rest c) would otherwise do nothing -- it's not like there are real bindings there -- I am somewhat for the existing behaviour
14:52:35
dougk_
stylewarning: if you're seriously going to make Alpha work, you'll have to go back to mid-october last year to get a known good build.
14:56:08
stassats
like regalloc, but i didn't really change its operation, just some of the data structures
16:20:17
stylewarning
dougk_: I'm not sure I'll have the energy to try to make it work, but I have the machine and I'd like to
19:15:40
stassats
i feel like there's a lot of room to make the compiler faster overall, nothing it does is inherently slow, just poor datastrctures, unnecessary work and slow fixed point detection
19:48:07
pkhuong
stassats: there's cool stuff to do to make the compiler faster, but in a lot of cases, I'm able to come up with pathological counter examples :\
20:19:54
aeth
Parallel compilation would be done at the level of something like ASDF and not SBCL, right?
20:21:44
aeth
Good question. I assumed files would be compiled in parallel, but one file could be compiled in parallel, too.
20:22:15
aeth
And the former would probably have to be done by ASDF and the latter would probably have to be done by SBCL
20:23:09
pkhuong
aeth: even parallelism at file granularity is hard in CL, apparently. I think that's what Fare is trying to achieve with uiop.
21:20:03
aeth
I wonder if it works with asdf's package-inferred-system or if that just infers things to be serial.
21:21:23
aeth
too bad most systems are defined to be serial so it wouldn't help with large dependencies
21:22:48
aeth
The longest compilation time I could think of for a realistic large application is probably 2 min (on my system, your experience might differ), which would be cut down to 15 seconds in a naive (/ 120 8) calculation. From noticable to not that noticable.
21:24:44
aeth
It wouldn't be really (/ 120 8) even at full utilization for various reasons, like hyperthreading (it's only really a quad core) and turbo boost (single-core is faster)
21:25:05
stassats
even 2 minute build times is not something that would bother me, since i rarely rebuild the whole thing
21:26:05
aeth
It depends on what you modify. If it has a foo/utils that almost everything depends on, then modifying utils would rebuild close to the whole thing afaik.
21:27:12
stassats
one of my projects takes around 2 minutes to bring up, but i do it once in a development session
21:29:16
aeth
#lispgames probably could get 20 minute build times if any of the engines actually became big and professional (like GNU?)
21:30:37
aeth
pfdietz2: Imo, one of the key ways to ensure correct code in SBCL is to use type declarations.
21:32:49
aeth
I haven't written it yet, but I think combining type declarations with (setf sb-ext:*derive-function-types* t) should essentially give static type checking, although obviously *derive-function-types* shouldn't be used when using CL interactively via SLIME.
21:41:39
pfdietz2
Program is built in reverse of control flow, so you don't generate assignments or bindings to dead things.
21:42:47
aeth
pfdietz2: That looks like it's designed for compilers, but I think something similar would be useful for frameworks.
21:43:46
stassats
pfdietz2: so, are you implying compiler instrumentation? cause i'm not really sure how to do that from "user space"
21:47:19
pfdietz2
Current random tester generated lots of dead code. Exercised dead code logic in the compiler a lot.