Reworking Crosscheck

0 views
Skip to first unread message

Charles Lowell

unread,
Jul 17, 2008, 3:23:05 PM7/17/08
to cross...@googlegroups.com
Hey Everybody,

I wrote about the reasons that I think crosscheck has been languishing
recently, and what things need to be done to revive it:

http://www.thefrontside.net/blog/crosscheck-update-cleaning-house

Not only do I think we need to rewrite crosscheck the program, but I
also think we need to rewrite crosscheck the community. In the same
way, that we want to call out to the community for help design and
build the runtime from the ground up, we want also to call out to the
community about how better to organize the project itself.

Since we're starting essentially from scratch in both places, this is
everybody's chance to get in on the ground floor and take an active
part in shaping the code and the community. If you're present and
following the growth of the program from the start, then from the very
first day you'll be a crosscheck guru.... and that's the ultimate goal
here, to have as many crosscheck experts as there can possibly be
besides just Jason and me.

Of course, it's not just about the code, we need to rework our site,
and our documentation, and that means suggestions about how it should
look, and how it should be put together. We're all ears on that front
to.

If you are interested in helping us out, please let me know. Just
know, that if you have a suggestion for a design, or for a site, or
for anything, be prepared to back it up with an implementation.

In this spirit, I've started a prototype for the next major version of
crosscheck. You can view/checkout the sourcecode here:

https://crosscheck.svn.sourceforge.net/svnroot/crosscheck/branches/back-to-javascript


Remember, this is a very rough draft that I banged out in only a few
days. However, in the spirit of openness, I wanted to release it to
everybody so that they can understand it, work with it, and perhaps
suggest modifications to it as soon as possible.

Specifically, it addresses several of the things that I laid out in my
blog

1) mostly javascript. the majority of the implementation is in
bootstrap.js

I'm pretty pleased with the way that this turned out. Being
javascript, it's really concise, and takes about 300% less LOC that
the equivalent java implementation. The most notable exception is the
code that wraps the testcase run and catches errors and failures.
Unfortunately that has to be in java in order to get to the stack.

Another thing that I'm liking about this is that the number of java
classes is less intimidating than it was before. Because there are so
many less, it's easier to see what the ones that are there mean.

2) all of the crosscheck javascript is pre-compiled inside the jar.

It took me a while to figure out how to do this since the rhino docs
are (and have really always been) atrocious. They tell you how to
compile, but not how to use the scripts that you've compiled. Anyway,
the core engine and the assertions are now compiled to an optimized
class file. We can do the same for any other scripts that come along.


What it does not do is the actual crosschecky stuff. While the concept
of the host has been baked into the APIs, it doesn't actually do
anything with it yet. That still needs to come... but I'll wait to do
it together with those interested in helping out.

There are several bugs I'm sure. I can't quite figure out how to get a
proper stack trace when there is an assertion failure, but hey! I
wanted to throw it out there rather than wait for it to achieve a
perfect state which will never happen.

Let me know what you think!


Charles Lowell
cow...@thefrontside.net
512.207.0229


Reply all
Reply to author
Forward
0 new messages