<jackdaniel>
my biggest contribution to slime was adding stolen phrase to the welcome message: "Are we consing yet?" :-)
<luis>
jackdaniel: good job!
<jackdaniel>
I know, I wouldn't brag about it otherwise ;p
<jackdaniel>
(and that's folks how you get an op on freenode channel ,)
<jackdaniel>
but more seriously: I have issue with navigating to source code
<jackdaniel>
not sure if ecl fault or slime, I see "error in process filter: slime-dcase failed: nil"
<jackdaniel>
hum, otoh I have outdated slime, I'll try with a new one
<luis>
fiddlerwoaroof: I think I have a simpler fix. Replied to the PR.
<luis>
jackdaniel: did updating SLIME fix it?
<jackdaniel>
no, but it is ecl to blame
<jackdaniel>
(possibly in swank's ecl backend, not sure yet)
<luis>
jackdaniel: I'm adding a testing suite for swank, and I'm precisely starting with source location tests, so you might find that useful.
<luis>
I got side-tracked with picking/writing the test framework. Classical mistake. I've avoided this mistake in the past, not sure what happened this time around. :-)
<jackdaniel>
thank you. maybe you'll find this test useful: ECL can't tell the source location of methods (but it works just fine with generic functions per se and "normal" functions)
<luis>
ACK
<jackdaniel>
I'm not sure if it is a bug to return NIL or maybe should ECL signal an error
<jackdaniel>
(or ecl's swank backend)
<luis>
jackdaniel: swank/backend:converting-errors-to-error-location suggests you should always return some sort of location object
<luis>
Hmm, actually MAKE-ERROR-LOCATION returns an s-exp, not a location object
<luis>
jackdaniel: anyway, use one of those (or both). Seems to be what the SBCL and ACL backends do.
<jackdaniel>
so I should return something in `(:error "Not implemented yet") spirit? (+/- how it should be implemented)