hamlink at comcast.net
Sun Aug 8 16:29:56 PDT 2004
On Aug 8, 2004, at 2:10 PM, alex crain wrote:
> On Aug 7, 2004, at 11:55 PM, Hamilton Link wrote:
>> On Aug 7, 2004, at 11:33 AM, alex crain wrote:
>>> Anyway - I think that we're on the same page.
>> Excellent. We are on the same page from a binary standpoint, so now
>> we should get on the same page goal-wise, I think we're in different
>> chapters still in that respect... I think a good way to proceed might
>> be to sketch out dummy front ends with the project builder's
>> Interface Builder tool or with lisp, and send screen shots (and the
>> Interface files, so they can be modified and exchanged) back and
>> forth to one another for a little while.
> Not to worry - my first step was to find a printable version of the
> manual and start marking up what works and what doesn't. It will be
> some time before I actually start mucking with the GUI.
> That being said, the idea for the tabbed window comes from the
> reasoning that the listener, backtrace and inspector windows are all
> different views of a lisp thread, with different functionality.
Fair enough, but code and a thread running through code are still
pretty different. I'm not saying there shouldn't be a way to map back
and forth, I'm just saying that it's way not one-to-one (like a
page-swapping window would force it to become).
With an interrupted thread, you want to look at the objects currently
in memory (inspectors), the call stack (backtrace), the lexical
environments (i.e. the code for each stack frame), and the amortized
view of how much time is beings spent at various places in the code
(profiler). You also may want to evaluate new expressions possibly
involving stuff from this or other call stacks (listener). Then you may
want to fix the code or even just look at it in many places, both
related and unrelated (editor).
And most importantly, you want to be able to look at a lot of this
stuff simultaneously within each thread and across multiple threads.
> In the listener window, I want to
> (a) be able to edit and send sexprs to lispland
> (b) browse the history to select a previous command
> (c) hot key off of any symbol to find value, documentation and source
> file information
And when you're looking at documentation you're saying you don't want
to be editing and sending sexps to a listener? That's your preference
maybe but it's certainly not mine.
> The backtrace buffer, in contrast, has no notion of history because
> it's essentially a view of
> a transient object.
Yes the backtrace window that shows the stacks may not have a notion of
history, _but_ the listener that's sitting there in a break loop
> I envision an outline interface that would let me scroll through the
> stack frames, expanding them as needed, similar to the inspector (but
> different, see below).
Oh, by the way, I like your vision on this AND a preliminary version of
this exists so you don't need to start from scratch! The list archive I
think has an email on how to invoke it when you're in the break loop,
maybe Gary could reiterate this.
> In a
> perfect world I would be able to select a stack frame and invoke a
> listener that would continue
> from that point so that I could, say, step through a code sequence
> repeatedly, starting from the same point each time without actually
> rerunning the entire program.
Well, you can kind of do that already, restart from a particular frame
that is... IF restarts have been declared. In general what it sounds
like you're suggesting is only possible in languages where you have
copyable continuations. And unless there's some scheme implementation
that does this, I don't think there are any such languages. Which would
be consistent with the world not being perfect.
> The inspector is a view of one or more persistent objects in the
> system which I would want to
> use to follow links and ultimately monitor the values of program
The good news is there's no need for them to be "persistent" in any way
that is different than any other object. If you open up an inspector to
something it will stick around by merit of having a window referring to
it. Now, if you declared it to be dynamic-extent, then you might be in
> All of these utilities are (in my mind) grouped to a single thread,
> and if I had multiple top level listeners then I would want them
> grouped with their own set of backtrace and inspector windows (and
> maybe help and editor windows as well).
I have done a lot of multithreaded programming. Editors aren't linked
to threads in my mind at all. Objects aren't either, since lisp threads
have a shared memory model. The in-your-mind part is dangerous when
you're designing a GUI specifically because you're taking your world
model and imposing it on others.
Break loops definitely do map to a single thread (ignoring for the
moment the strange overlay that the command-line openmcl is forced to
provide). You can have a stack of break loops for a thread so it's
really one-to-many, but with a constraint that probably makes it
reasonable to have a one-listener-per-thread model, unfolding a
backtrace outline viewer when you enter a break loop. If you have a lot
of threads, however, you will probably have most of them uninvolved in
a REP loop most of the time. It might still be good if they can all
print and read from their own pseudo-listener though and if they do hit
a break loop or return to a REP loop there will be a window just for
them, so that's good. Possibly a reasonable thing to do would be make a
dummy terminal-io that each thread can start with that doesn't have a
listener/breakloop/backtrace window and creates one the first time it
is written or read from. This will reduce clutter when
process-run-functioning a bunch of stuff.
> I was thinking of tabbed windows with tear offs because that would
> simplify the grouping: you could toggle between views without having
> to figure out which backtrace is tied to a specific listener.
Yeah, that's reasonable. I would prefer to look at both the backtrace
and the break loop at the same time, though, and there are other ways
of joining them (like a split window pairing a break loop and its
backtrace) to meet your very sensible easy-association requirement.
> Alternately we could go with window groups and some kind of group
> manager that would allow you to raise a group at a time.
That is also a good idea. I would personally like to have a set of
group-bubbles that I can move windows between and switch between them
by clicking a group bubble. And I wouldn't want any constraints on
which window was in which group. This would free me and everyone else
up to figure out what grouping is most useful, and saves you from
thinking of the ideal way, which is good because there is no ideal.
>> For the listener, don't even switch to a debugger pane, whatever that
>> means. Just leave it at the break prompt, that's where a lot of
>> debugging happens. If you want to resize the listener window and make
>> a split window showing the listener plus the backtrace right away,
>> THAT might be cool. When I get out of the break loop it should
> This works for me.
> If I get my wish about branching listeners from arbitrary frames then
> we could just bring up a new listener as some kind of child of the
> paused one (it would have to be a child so that it could go away when
> execution continues in the main window).
Hmm... I partially withdraw my previous statement about copyable
continuations. It is possible from the command line to, at a break
prompt, evaluate whatever you like, so maybe what you want is the break
loop REP itself. You can process-interrupt a process at any point (or
at least you could at one time, did native threads break this?) to
evaluate anything, even to the point of starting a break loop.
I don't know what the evaluation context in a break loop looks like
exactly. I don't think you can see into the stack without calling out
values explicitly. I don't think it would do what you are thinking
you'd like to do, but please describe what you have in mind in more
depth and maybe Gary will be able to say what is and isn't possible.
>> Gary says that your mail domains don't have valid DNS MX records, and
>> this makes the mailer daemon unhappy:
> Yes, I've heard this before but I can't explain it. widgetworks.com
> had an MX record and DNS works from most domains, but not all, at
> least not all the time. I'll try to track it down again on this end.
> In the mean time, I'll just forward stuff to the mailing list and read
> about it in the archives.
More information about the Openmcl-devel