freenode/#sicl - IRC Chatlog
Search
6:01:38
beach
I guess I should make a list of shortcomings of the SLIME debugger in order to justify Clordane, just as I made a list of problems with Unix in order to justify CLOSOS.
6:07:25
beach
shka_: Clordane is for any implementation with maintainers willing to add support for it.
6:10:33
beach
There roughly 0 probability that any SBCL maintainer would be willing to add support for Clordane.
6:12:56
beach
People are mostly happy with SLIME. I just saw that AndrewYoung called it a "nice debugger".
6:13:29
jackdaniel
I'm understanding correctly that adding support for clodrane will be no smaller feat than, say, adding package local nicknames support to an implementation?
6:45:07
beach
Seriously, I have to work out with scymtym what a communication protocol for Clordane would look like.
6:50:23
beach
I suspect the most likely way in which things will evolve is that Clordane is going to be for SICL only for quite some time. Then if (and only if) people can use it, do use it, and like it, perhaps there will be interest in adding support for other implementations.
6:51:19
beach
Another possibility is that people will use SICL+Clordane for development and debugging, and continue to use their existing implementation for deployment.
6:51:49
jackdaniel
in principle that was an idea behind ecl's bytecode compiler according to papers I've read
7:06:53
jackdaniel
(and some parts of this idea are still present in ecl, i.e tracing bytecompiled function may be revoked by means of untrace, but if you compile function which is being traced to C, then you can't untrace it unless you recompile the function itself)
7:08:22
jackdaniel
of course you may call trace (and then untrace) on a function compiled to C and this will work
7:09:54
jackdaniel
ie by replacing function definition with a wrapper which calls the actual function
7:10:54
jackdaniel
but that gives me an idea how ecl could be improved to work nicely with tracing even in this bogus situation
7:12:15
beach
For what it's worth, I don't intend to implement tracing in SICL by wrapping a function.
7:13:02
beach
Because that doesn't really trace the function. It replaces the relation between the name and the function by a different function.
7:14:56
beach
I.e., SICL will tell Clordane that it has reached the entry point of the function. Clordane has information that it should not stop there, but just show some information. So it does, and then tells SICL to continue.
7:19:43
beach
Though this mechanism would require the user to use Clordane, which is obviously not conforming behavior. So I guess I need to implement some simple conforming mechanism as well.
7:41:05
beach
scymtym: I think that (by chance) I arrived at the solution for Clordane that you suggested some time ago, namely that there be some kind of communication protocol, allowing the application to determine what operations it will admit, rather than allowing Clordane arbitrary access to variable values, values of the program counter, etc.
7:44:31
beach
From consulting with loke, I arrived at the basic structure that you now see. I.e., an action on the part of the application calls a Clordane function, either one function for each kind of action, or we can define a class hierarchy of "messages".
7:44:39
beach
The applications then "waits" for an action from Clordane by executing another Clordane function that essentially waits for a queue to be non-empty and the dequeues the first message.
7:45:27
beach
The function that the application calls, in turn calls EXECUTE-FRAME-COMMAND to synchronize with the Clordane command loop.
7:47:33
beach
So if you want to give some thought to such a specification, that would be great, since you asked about "the next step" the other day.
7:47:54
scymtym
intuitively, i would represent messages as classes, but i haven't given it any thought
13:54:52
beach
Am I reading the SLIME debugger chapter right? I don't see a way of setting a breakpoint at some point in a function, neither before a program is started for execution, nor when it has failed and the user is staring at a backtrace.
13:56:01
beach
All I see is the set of three stepping functions available only when things have failed and we have a backtrace.
13:57:06
beach
What is the "next form in the current function" and what does it mean to step "to" it?
13:58:12
beach
sldb-step seems clear, but it mentions only CMUCL. But it doesn't say what happens when one of those breakpoints is reached.
14:01:24
beach
In case it is not clear what I am doing, I am compiling a list of shortcomings with our current development environment, and in particular with the "nice debugger" that we have.
14:02:10
beach
I also want to make it clear that I am convinced that the people who wrote the SLIME debugger are not to blame here. I am sure they did a fine job with what they had to work with and with the resources available.
14:02:28
Bike
my impression is that stepping pretty much doesn't work at all in sbcl, and given how common sbcl is, you know
14:02:35
beach
Well, it depends on the implementation, and I am guessing most implementations have very limited support.
14:03:32
beach
Now, let's turn to examining stack frames. And this aspect is likely implementation-specific as well.
14:04:23
beach
Some of them may have names such as VAR-1 where I actually used a variable named VAR.
14:06:15
scymtym
(defun (x) (let ((x …)) …)) results in multiple variables named X which get disambiguated as X, X#1, etc. to show the "shadowed" values
14:07:40
beach
That was my guess, yes. I think it would be better to show them as source positions of definition (in the sense of DEF-USE etc).