[webkit-dev] new shell for JavaScriptCore?

[Gavin Barraclough]

On Jan 10, 2012, at 7:33 AM, Andy Wingo wrote:
> Hello JSC hackers,
> 
> I've been thinking for some time now that there is room for another
> command-line shell for JSC.

Hi Andy,

Yes!

Some more things to add to the wish list:
	* tab completion (e.g. "Math.si" -tab-> Math.sin)
	* persistant command history over invocations
	* binding results of prior commands to variables in global scope.
(I believe that the readline library has some useful hooks we're not currently using to help with the first two of these).

> Specific things that one might want to support in the new shell would be
> meta-commands:
> 
>> ,profile f(1)
>> ,disassemble f
> 
> Meta-commands are commands for the shell, not expressions to be
> evaluated.  As expressions can't begin with a comma, we would abuse the
> comma to introduce those meta-commands.

I'd suggest that it might be better to expose new commands through JavaScript where possible, rather than using a new syntax.  One key advantage is that if these commands are exposed through JavaScript then you can easily script use of the shell commands in JS, e.g. to disassemble all the functions on object foo's prototype:

	for (var func in foo.prototype) disassemble(foo.prototype[func]);

> There would also be a meta-command to inspect and modify the current
> heuristics, to turn the JIT on and off, etc.  These options could also
> be turned on and off from the command line.

It would be a really great if any new shell were not just be limited to being useful to WebKit developers, but was also suitable for use by programmers wanting to script in JavaScript.  Some of the tools you have listed should be extremely useful to us in developing JSC, but would probably be inappropriate to ship to customers, so we might want the option to be able to compile these out in some builds.  But I don't think that this should be a constraint in any way – we might just want to wrap some of the tools in #ifdefs, or maybe guard them on an environment variable being set.

> So, I wanted to solicit some thoughts on this idea before going to
> implement it.  I really think that the right place for a project like
> this is in WebKit proper, rather than in some external tree, as that way
> it will always be in sync with JSC.

Yes! - we'd definitely love to have a better shell in the project.

One other random thought, it might be desirable if the shell were written to the JSC API, rather than being written directly against JSC's internal headers.  If the current API is insufficient we can expose some additional functionality through private headers.  This is certainly not a requirement, but it would be a cleaner way to do things, and would serve as a really great test for the utility & design of our API (and may be helpful in informing future improvements).

cheers,
G.