Ian Bicking: the old part of his blog

Re: Introducing HTConsole

How come you wrote your own serializeJSON, when MochiKit already has one?

The keyboard handling code would be a lot cleaner and more correct if you used the MochiKit.Signal API. Check the latest interpreter example sources.

It's also kind of weird that you're using the exported functions for base and async stuff, but fully qualified DOM functions. I'd pick one or the other style and stick to it.

Could definitely use a status indicator and a way to interrupt.. I guess via some kind of trace func of a C extension to send exceptions across threads.

Comment on Introducing HTConsole
by Bob Ippolito

Comments:

How come you wrote your own serializeJSON, when MochiKit already has one?

Because I could not find it. I have a really hard time finding things in MochiKit sometimes.

Could definitely use a status indicator and a way to interrupt.. I guess via some kind of trace func of a C extension to send exceptions across threads.

I haven't particularly noticed that, but then there's lots of conditions I haven't tried. Was there a particular thing you were doing that caused a problem (something I might be able to reproduce)?

# Ian Bicking

How can the MochiKit docs change such that you'd have an easier time finding things? I mean shit, if you had looked for a function named serializeJSON you'd have found it... you picked the same name I did.

I did "while True: pass" to see how it would be handled.

# Bob Ippolito

Huh, yeah it's right in Base. I guess I have a problem figuring out what module things are in -- specifically Base, Format, and Async, though Base and Iter are also hard to tell apart at times. Now that I look at it, I realize I could just expand all the function lists on the front page of the documentation; instead I kept looking on individual pages. Maybe an "expand list of all available functions" link on the front page would help?

For the while True thing... damn, stopping a runaway thread is hard. Certainly on the client side some indication of command-sent-waiting-for-response can be added easily enough, but unfortunately I don't know how to actually handle the problem of infinite loops.

# Ian Bicking

There are two ways to handle an infinite loop.. you can set a trace func that checks some variable to see if it should raise an exception or not, or you can hack into some semi-private C API which lets you send an exception to another thread. The former is probably better for this.

I'll see about adding that expand all button, should be easy enough.

# Bob Ippolito

Keep in mind that Turing proved (before computers existed in fact) that it is impossible to accurately detect infinte loops -- it's called the 'Halting problem' FYI.

# Silas Snider

A single page with the entire documentation would also help (easier to search). On the topic of docs, links to the implementations from the documentation would also be really nice; the docs can be a little terse at times, but usually the implementation is clear enough.

# Ian Bicking

I'd rather fix the doc bugs than try and link to the source from the docs (non-trivial). Please file tickets when you find documentation that is insufficient.

# Bob Ippolito