freenode/lisp - IRC Chatlog
Search
3:13:51
pookleblinky
heh. Mezzano, what hopes to become a full OS, is smaller than neovim *and* sbcl.
3:17:49
beach
Don't worry, it will get bigger as new features and new compiler optimizations are added.
3:46:38
beach
He wants to know whether I would "adopt" his version. I need to know what that means. I certainly had not planned on any extensive maintenance work on mine.
3:50:29
Lord_Nightmare
maybe replace yours with his, but host yours as another branch on that same project?
3:54:07
beach
It is a bit sad that Jean-Philippe does not hang out here, or they could have coordinated this work.
4:17:58
newdan
In SLDB/Slime, I can put my cursor over a stack frame and hit the v key to show the code that the frame corresponds to. I can hit t to show locals, and I can hit e to evaluate an expression in the frame's context in the CL-USER package
4:18:25
newdan
Is there any way I can evaluate code in the frame's context but in a different package? Particularly, in the package that the frame's code is defined in?
4:19:49
newdan
Bike: Is that the most convenient way to do it? Is that a normal part of your own workflow when debugging with Slime?
4:22:51
newdan
Even though I use defpackage/in-package which seems like a pretty standard way of doing it
4:22:51
Bike
as in, swank has a frame-package implementation interface, and sbcl just returns nil (meaning "lol i dunno")
4:27:55
newdan
I have (declaim (optimize (speed 0) (debug 3) (safety 3))) at the top of one of the files although that feels like a pretty crappy way of doing it
4:29:16
beach
I have that as a default, because I figure I will put explicit declarations where I need more speed. And there are very few such places.
4:29:26
newdan
Because I want it to apply to basically everywhere, and I can't tell when that declaim happens or if it will have a good impact
4:30:18
newdan
lol yes I was getting that impression, will try that now and see if it helps, thanks for the tip
4:31:04
newdan
I also have (sb-ext:restrict-compiler-policy 'debug 3), I don't know if that's needed or what that even does
4:31:45
newdan
But as a newbie I agree beach , it would be nice to have debugging turned on unless it's turned off on purpose
4:32:17
newdan
For a while I was really confused that a bunch of my vars seemed to be missing, I've since learned that I guess the compiler tries to reduce the number of variables when possible
4:34:00
beach
newdan: For example, it is common for the compiler to eliminate a variable that is no longer "live" in that it can't be referenced anymore, even though the variable is still in scope.
4:35:46
beach
newdan: So, for instance, if your stack frame corresponds to a control point inside a LET, but the last reference to some of the lexical variables precedes the control point, then you won't see it in the stack frame.
4:36:23
newdan
I see, that's pretty cool. Unfortunately the e key on a frame still wants to execute in CL-USER after putting the declaim stuff in sbclrc, but I'm still pretty happy to at least have moved that stuff to sbclrc
4:36:44
beach
I don't know the details of SBCL, but if I were working on it, I would keep variables live artificially until they get out of scope when DEBUG is 3.
4:37:34
newdan
Oh, I don't know. I restarted SBCL but I didn't try to look for/delete FASL files or anything
4:39:21
fiddlerwoaroof
beach: on a slightly off-topic note, shouldn't it be possible to use method specializers as type declarations?
4:40:41
beach
Is it not possible? Method specializers are either class names or EQL specializers. Both are allowed in declarations. No?
4:41:22
newdan
Still not fixing the eval in frame. I am using quicklisp to load my system, I dunno if (ql:quickload :foo :force t) does the same thing you want (although it did look like it forced something to recompile)
4:41:30
fiddlerwoaroof
I should be more specific, I was surprised that sbcl didn't seem to make use of such type information.
4:42:10
fiddlerwoaroof
I used DEFMETHOD to decalare one argument an integer and another a string and then I passed the string to format as ~D
4:42:28
fiddlerwoaroof
usually, if sbcl knows the type, it'll warn you, but I didn't get any warning
4:42:29
beach
fiddlerwoaroof: For standard objects, it is tricky because some other thread may do a change-class.
4:43:28
fiddlerwoaroof
I was trying to figure out why the type didn't propagate like I half-expected it to
7:03:48
fiddlerwoaroof
Am I missing anything important in this? I'm trying to write a macro for running a single method of a generic function in isolation.
7:06:58
fiddlerwoaroof
Everything seems to work, I'm just wondering if I'm missing any subtle edge-cases
7:09:00
beach
Looks OK to me. Notice, though, as I pointed out the other day, that some classes of generic functions may use a different signature for its methods.
7:11:09
fiddlerwoaroof
I didn't think of that, I'll have to keep that in mind if I start using this more generally
7:12:38
beach
For example, if it can be determined that no method calls CALL-NEXT-METHOD, then the NEXT-METHODS argument may be omitted.
7:13:33
beach
Another example: I can imagine some systems which would not cons up a list of arguments to pass to methods if, say, there are only required parameters.
7:17:23
pjb
fiddlerwoaroof: also, it will fail since you don't define next-method-p and call-next-method!
7:18:50
pjb
Argh, it would have, since they're lexical functions, therefore there's absolutely no home of methodcall to ever work correctly.
7:20:14
pjb
fiddlerwoaroof: it would be better to defun the body of your method and call those functions from your methods.
7:20:19
fiddlerwoaroof
The reason for the next-method related stuff is to provide something to "catch" functions that try to call-next-method
7:20:59
fiddlerwoaroof
I could also do it the way you suggest, but I wanted to experiment with this way.
7:21:07
beach
pjb: I think next-method-p and call-next-method turn into accesses on the list of next methods so it works in the default case.
7:22:13
beach
pjb: The problem is that an implementation is allowed to optimize for standard MOP-defined classes, in particular for standard-generic-function, so it could very well not work on certain implementations in that case.
7:36:07
pjb
fiddlerwoaroof: what you can test is the generic function with different classes of arguments. But it doesn't make sense to try to test single methods, in lisp, because of method combinations. In Objective-C, you could get a pointer to a method function and call it, and it would work, because it could still call super and that's all you have there as method combination.
7:37:12
pjb
This is why I don't think you can expect next-method-p and call-next-method to be statically determined (or "optimized") in general.
7:37:35
fiddlerwoaroof
But, there are a couple situations where I just want to test that my code works and I don't care what the other code being run does
7:39:05
fiddlerwoaroof
For example, if I'm using a library by extending a generic function, I might want to make sure that, given certain expected inputs, the body of the method produces the expected output, but I might not want to test the library code.
7:39:13
pjb
I don't know what you're trying to isolate. If you can implement your hack, then you can just call the generic function directly, it won't make a difference.
7:39:58
pjb
Again, if you have such simple and orthogonal methods, it may be preferable to put their bodies in separate functions, and test them.
7:40:17
fiddlerwoaroof
It might, if, for example, the :around method connects to a database and writes the result of the primary method to the database, it might be useful to run the primary method by itself to make sure the right data gets written
7:40:39
fiddlerwoaroof
And, this is mostly just an experiment, I'm not really claiming (yet) that this is actually a good idea.
7:41:14
pjb
Definitely, if you have such independent stuff, keep it in separate functions: you probably will want to reuse it elsewhere.
11:58:59
Baggers
easye: It is allowed to succeed if the object is already of the requested type though
12:04:09
edgar-rft
in some years when all folks involved in the ANSI spec are dead, we're finally allowed to implement whatever we want