After reading some discussions on edu-sig, and with a little inspiration from Try Ruby, I've been playing around more with a web-based console, HTConsole. (Like several people now, I am lazily using the Cheese Shop page as the homepage.) (I should note also, I'm not really trying to recreate the publically-available interpreter aspect of Try Ruby, it's more that I'm trying to further explore the HTML-based interpreter that the later parts of the Try Ruby tutorial introduces)
This isn't intended to be Yet Another Python Console; I'm really thinking more about this as a learning tool. And since I haven't really thought about the security implications, you'll have to install it yourself to try it. Maybe some of this later.
But really, the idea isn't to duplicate (or even improve ala ipython) the console experience (ignoring the name), except to use that as a starting point.
So far I've mostly just achieved that starting point, but if you poke around there's a couple places where I'm expanding on that. If you add something to the local scope (e.g., through an import or assignment), it shows up in a table at the bottom of the screen. (Though I'm going to have to figure out how to keep the screen from getting too long.) Objects can also be displayed in an interactive manner. A function, for instance, has an edit button; if you hit it, you can edit the function in place. I want to add self-editing features to more objects. Well, at least to classes and functions. And dicts. And lists too I guess. And property. So, okay, a bunch of things.
On edu-sig there's also been talk of doctesting, and that's another thing I want to add, just to select a doctest and run it against the environment.
Anyway, it's kind of fun I think, and thoroughly non-enterprise; not even suitable for serious programming. That lends a sense of freedom. You install it like:
easy_install htconsole ... lots of junk passes by ... htconsole ... web browser pops up with console ...
At least, I think this is all it should take to install. Note: I'm pretty sure you'll need the latest version of setuptools to get it to install nicely (with support for dependency_links) -- grab ez_setup.py and run it to get the latest version.
Now to figure out some of the tricky Python magic to edit more objects in place...
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.
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.
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.
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.