[Openmcl-devel] hemlock

[Hamilton Link]

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 
certainly does.

> 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 
> variables.

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 
trouble...

> 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 
>> resize.
>
> This works for me.

Cool.

> 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.

h

>> 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.
>
> :alex
>