[Openmcl-devel] hemlock

Hamilton Link hamlink at comcast.net
Sat Aug 7 20:55:30 PDT 2004 

On Aug 7, 2004, at 11:33 AM, alex crain wrote:

>
> Ok, I did the whole thing again and it worked without CLX, so I must 
> have done something wrong the first time.
>
> If you do:
> (require "CLX")
> (require "defsystem")
> (make::oos "hemlock" :load)
>
> You get a kind-of sort-of working hemlock using X11 windows. It worked 
> enough to confuse me.
>
> 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.

> I've already done some COCOA programming - Decoding your inspector 
> code enabled me to write a file browser using nsOutlineView and I was 
> working on a debugger using the outline model when I tripped over the 
> hemlock discussion.

Debugger, debugger... you've used that term twice in this email, what 
do you mean? Break loop? Backtrace? both and the Inspector? debugging 
for me is a process, one involving looking at code, looking at data, 
backtraces, looking at the contents of the error, etc., it's not a 
window.

FYI I wouldn't mind someone making the inspector outline-based, 
actually, instead of NSBrowser-plus-NSTable based. I think it would be 
more compact and would show more of the objects in question.

> After looking at this, I'm thinking that a top level window should be 
> tabbed with
> 	a listener pane
> 	a debugger pane
> 	an inspector pane
> 	a documentation pane
> 	an editor pane

Don't do the top-level-window thing. Why? Tabbed views are modal by 
default. Modal views are bad GUI design for most things, and 
programming is one of those things IMHO. You could do it for editors 
(tabbed view, tearable tabs), but leave the listeners, inspectors, 
backtrace, etc. as separate windows. I really can't emphasize this 
enough.

The programming environments I like best make separate windows for 
everything. You can see more, and you can have the things that you 
_want_ to see at the same time, _visible_ all at the same time.

Emacs gets away with modality for two reasons: (1) it's a legacy mode 
for terminals and is often used in that way, (2) emacs has split panel 
and independent window modes that are easy to invoke, and it's totally 
easy to switch between buffers without reaching for the mouse. Oh, and 
(3) we want something that is _better_ than the emacs+slime package.

> If we used the main menus to manipulate the top level windows and make 
> the panes
> tearable, that should be enough flexibility to make most people happy. 
> Then we just cross link the whole mess so that you can pop between 
> panes with a hotkey:

Not good enough. I want to see a mix of all this stuff at once. Keeping 
all my editing windows neat and tidy (as long as they're tearable) is 
the most I want the GUI to constrain me.

> break in listener ... switch to debugger pane
> backtrace to symbol ... highlight and check documentation switch to 
> inspector
> browse in inspector .. find error. Select problem ... switch to source 
> file
> recompile, back to listener continue or restart

Absolutely, positively, one hundred percent, no. You're over-thinking 
the GUI, and popping back and forth like that you're guaranteed to piss 
off the user. Those are subtle, process-smoothing features to add when 
the functional parts are nice and solid, anyway, and if it's throwing 
errors _and_ popping all over the place, no one will use it long enough 
for you to figure out what the right process support level is.

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.

> Since it doesn't look like anyone is actively working on the code at 
> the moment, I'll pick up the ball and run for awhile. Feel free to 
> offer unsolicited advice.

I will reiterate some of my unsolicited advice from before: concentrate 
on the following first:
  - get what's there, working more solidly
  - get what's there, interacting more smoothly
  - get what's there, looking less funky
THEN you'll be in a much better place to make more substantive changes, 
and you might start accumulating a user base to test things for you and 
give you feedback.

> :alex
>
> BTW: could you send something to gary and ask him to put me on the 
> mailing list? I seem to be falling into a black hole somewhere.

Gary says that your mail domains don't have valid DNS MX records, and 
this makes the mailer daemon unhappy:

>> If you can somehow communicate with Alex Crain via email, could you 
>> please
>> tell him that neither the domain
>>
>> widgetworks.com
>>
>> nor the domain
>>
>> mail2.widgetworks.com
>>
>> have valid DNS MX records:
>>
>> [~] gb at clozure> host -t MX clozure.com
>> clozure.com mail is handled (pri=10) by clozure.com
>> [~] gb at clozure> host -t MX apple.com
>> apple.com mail is handled (pri=10) by eg-mail-in1.apple.com
>> apple.com mail is handled (pri=30) by mail-in.euro.apple.com
>> apple.com mail is handled (pri=10) by mail-in3.apple.com
>> apple.com mail is handled (pri=10) by mail-in4.apple.com
>> apple.com mail is handled (pri=10) by mail-in5.apple.com
>> [~] gb at clozure> host -t MX sandia.gov
>> sandia.gov mail is handled (pri=10) by mm01snlnto.sandia.gov
>> sandia.gov mail is handled (pri=10) by mm02snlnto.sandia.gov
>> [~] gb at clozure> host -t MX widgetworks.com
>> Host not found, try again.
>> [~] gb at clozure> host -t MX mail2.widgetworks.com
>> Host not found, try again.
>> [~] gb at clozure> host -t MX unm.edu
>> unm.edu mail is handled (pri=10) by canis.unm.edu
>> unm.edu mail is handled (pri=10) by bootes.unm.edu
>>
>>
>> Sendmail on clozure.com (and most other RFC-compliant mailers) will
>> have difficulty sending him email.



> :alex
>
> On Aug 6, 2004, at 9:03 PM, Hamilton Link wrote:
>
>>
>> On Aug 6, 2004, at 12:56 PM, alex crain wrote:
>>
>>> Ok, I managed to make it work. I was missing the part about 
>>> ccl:compile-hemlock and trying to use make::oop, which sort of works 
>>> and sort of doesn't.
>>>
>>> Anyway, I'm getting the cocoa listener and I can open files with a 
>>> mode line and scroll bars. I also see that paren matching works and 
>>> I can do all the cocoa things like cut and paste.
>>>
>>> Sooo...
>>>
>>> What else works and what doesn't? I notice that I still had to 
>>> require CLX to get hemlock to compile, help is broken and I get 
>>> "Error in event loop: NIL is not a line!" on a regular basis.
>>> Is there anything definitive on what the state of the project is? 
>>> I'm not complaining, I'm just wondering where is a good place to 
>>> start.
>>
>> Um... if you said (require "COMPILE-HEMLOCK") and then 
>> (ccl::compile-hemlock), it should have built hemlock. Requiring CLX 
>> directly shouldn't have been necessary. You lost me entirely when you 
>> said the thing about make::oop, is that an asdf thing?
>>
>> So probably the first thing to do would be to make sure you and I are 
>> on the same page with the build process, since otherwise we can't be 
>> sure we're testing against the same product. While we're at it we 
>> could upgrade the docs (before everything becomes second nature to 
>> you and you forget what the confusing parts were). Given that it's 
>> not complicated to build (IMHO, having done it many times), I'm not 
>> particularly crazy about converting it to asdf just yet.
>>
>> Then personally I would be inclined to see development proceed 
>> approximately like this:
>>  - address hemlock's undefined function warnings (by defining things 
>> or removing references), which probably represent a mix of unrealized 
>> functionality, potential error generators, and inappropriate features
>>  - fix as many of the panic-attack-inducing situations in the editor 
>> and listener as we can reliably reproduce that are still around after 
>> we stop hitting undefined functions
>>  - fix help and make a comtab viewer/configurator so people can 
>> figure out how to use the editor
>>  - take care of genuine integration issues, like making a hotkey or 
>> :b at listener at a break prompt pop up backtrace, double-clicking on 
>> an object in a GUI popping up the inspector, drag and drop, 
>> contextual menus for forms and GUI-displayed things that will eval 
>> forms, open class browsers, bind "@" to the selected object, and so 
>> on
>>  - emulate slime+emacs in keybindings as a default comtab 
>> configuration
>>  - tweak some of the cosmetic and performance issues, specifically 
>> the stuff I listed in my original email to you (which I apparently 
>> didn't copy to the list) plus the stuff we find while getting the 
>> editor working smoothly
>>  - overhaul crufty things, like revamping the inspector to be smaller 
>> while showing more
>>
>> I do a little bit of cocoa programming (like i made the crufty 
>> inspector) and will probably end up doing more as time goes by, so I 
>> should be able to help write code now and then besides the thorough 
>> testing and whining that I will be doing. I'm just really busy doing 
>> other programming projects most of the time.
>>
>> And for future reference, probably on this topic emailing me at 
>> hamlink at cs.unm.edu would be best, since that's where I get mail on 
>> the computer that I do the most hemlock testing.
>>
>> h
>>
>>> On Aug 5, 2004, at 10:55 PM, Hamilton Link wrote:
>>>
>>>> Oh and by the way JUST in case it was a build problem, your query 
>>>> made me go back and look at the docs again, and they were pretty 
>>>> bad. Now they've been rearranged and will hopefully be rewritten in 
>>>> the not-too-distant future by a few of us to be clearer. The build 
>>>> process is now Chapter 2: http://openmcl.clozure.com/Doc/ch02.html
>>>>
>>>> Oh, and this is my other email, if you want to correspond about 
>>>> Hemlock over the weekend. Monday I'll be at hamlink at cs.unm.edu so 
>>>> catch me if you can! :)
>>>>
>>>> h
>>>>
>>>> On Aug 3, 2004, at 7:15 PM, alex crain wrote:
>>>>
>>>>> I'm interested in working on the hemlock integration. Can you give 
>>>>> me a 100 word description of where things are?
>>>>>
>>>>> Also, could you see if I'm on the openmcl-devel mailing list? I 
>>>>> was once, but I changed my address from alex at widgetworks.com to 
>>>>> alexcrain at widgetworks.com and while I tried to subscribe a couple 
>>>>> of times, I'm not getting any mail.
>>>>>
>>>>> :alex
>>>>>
>>>>> _______________________________________________
>>>>> Openmcl-devel mailing list
>>>>> Openmcl-devel at clozure.com
>>>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>>>
>>>
>

More information about the Openmcl-devel mailing list