dj3500 / hightail Goto Github PK

Readme is now done, but we could still use:

1. comments in source code
2. some documentation on architecture (it's not too complicated so this should be short)

When user runs Hightail for the first time, they are presented with a stupid-sounding message about having to configure it first. It should be better, and also they should be taken to the config dialog immediately. The config dialog should have more comments.

Say I enter a correct URL and click Parse, and then when it's done, I cancel by clicking on the cross in upper-right corner. The problem tabs still get created :) "Cancel" button and Escape keys work fine.

I'm not convinced we shouldn't just close the dialog and create the tabs when the user clicks "Parse" and it comes back successful (like it was 1-2 versions ago).

If the program outputs a megabyte into stdout, we don't have to show it (we could show the beginning though), but we definitely need to be resilient against it (Hightail shouldn't attempt to process it too much and become slow and unresponsive). We should handle this gracefully.

When the result is WA, nice colorful diffs that tell the user which is the first wrong line etc.

Make Hightail support languages where the executable is run like "java executable" rather than "executable".

Their appearance under Windows is the intended one. Not sure about Linux.

This could be a kickass feature; when the input contains a graph in a standard format (number of vertices, number of edges, list of edges given as pairs of vertices, possibly with weights), then we could show the user a picture of the graph generated using some library.

It should work like this: leave alone all the tests that are already finished, and kill the others. Set the verdict of the others to ABORTED.

We should have an icon instead of the default Java one (maybe a capital H?).

Now, making a build of Hightail looks like so:

• run Build All
• zip up Hightail.jar and the lib directory
• distribute the zip
• user unzips the zip and runs the jar
  This should be faciliated by Java Web Start or something so that less clicking is necessary for the user (and preferably everything is in a single jar file).

When there are two non-equal floating-point values, the differ should compute min(their absolute difference, their relative difference) and give that to the user so that the user can decide whether it's a WA or OK.

This is far-fetched and might not be possible to do / to do right. But I'm thinking about something along the lines of:

• the user has a macro like
  #define DBG(x) cout << "DBG: " << #x << " = " << x << endl;
• we ignore (in diffing) lines beginning with DBG, but in diff view, we truncate the "DBG: " and display the lines in green, or something.
• or, we could display everything that came from stderr in green (however, can we sync it with what came from stdout and display both things in the same textarea?)
  Don't know if this would be usable.

Parser for CodeChef tasks doesn't currently work on all tasks (for example, http://www.codechef.com/JUNE13/problems/LAPIN). It should be made to. This might not be easy, because formatting inputs/outputs on CodeChef is not strict, problem authors have freedom in formatting.

This wouldn't be OS-agnostic, which is a downside, but it might be useful.
We would need a configuration option for this.

Tests should be run sequentially after all and not in parallel. If we run 10 instances of a program that takes 200MB, we can swap out the computer. There is not much gain to be had (at least timewise) from running them in parallel.

Some people (i.e. beginners) might want to write different problems in different languages, but as it is now, the language setting (i.e. the command which prepends the executable file, like "java") is system-wide.

Two examples:

• under Windows, we select not an .exe file but some other non-executable file (which exists). We then get "running..." indefinitely. Not sure if this is also broken under Linux (we have some sort of checking whether the file is executable, not sure if it works there).
• if the prepending command (like "java") is mistyped, or is not in the system path, the same happens.

What should happen: a useful error message.

I think we have that (at least for non-zero exit codes), but does it work? Test.

This is debatable, but when a user hits "compile" in their IDE (which they probably do using a shortcut), they should also have the option to hit another combination of keys and have Hightail test their code.

Aggregate result for problem: the user shouldn't have to check whether everything is OK: we should output (upon finish of testing) whether all testcases were OK or there were WAs/TLEs/etc.

This is a general issue. We should make sure the UI is bulletproof and does exactly what a poweruser would intend it to do in contest prime-time.

We have a placeholder now (a green circle).

It should probably redirect to some kind of project wiki/documentation. That needs to be written.

TLEs/killing long-running processes/etc.

Feature which would allow the user to set the start time of a contest in the "parse contest" dialog, and leave it. Hightail would then wait until a few seconds after that time and then start to parse the contest by itself. The idea is that the user should be able to do as much setup as possible before the contest, rather than having to even click the "parse" button when the contest is already on.

Or, in our case, possibly integration tests with predefined problems/solutions/testcases that give all possible verdicts etc.
Get coverage up from 0% ;)

When you open a testcase just to inspect it, there is a mechanism in place to only mark the testcase as edited if there were some changes to it. That mechanism doesn't work. This also results in erasing the program's output after exiting the Inspect/Edit dialog.

As in: if it errors out, is it possible to Abort? Don't we leave the buttons in an inconsistent state (e.g. neither "Run tests" or "Abort tests" are active)? Test error handling in the parser (what does the program do if the format of the CF problem page changes?). Etc.

Not sure if this can be done OS-agnostically in Java. And we need to know where the source file is.

For example, a feature to autorun the tests whenever executable file changes/is created. Is it always desirable? If we do this, we had better already implemented TLEs/REs etc. and be very stable about running stuff, so that running absolute crap/unstable programs/programs that pump out gigabytes of output to stdout etc. doesn't mess up the state of Hightail. And then we need a way to inform the user about the results (tooltip from taskbar or something unobtrusive).

... so that we warn the user that they're testing old code / they forgot to compile.
Downside: if they forgot to compile, they might have also forgotten to save the source file and there's nothing we can do about that.
Downside: we would need to know where the .cpp file is (another configuration option to take care of).
Also, the user should be able to turn off this feature.

This seems to be missing currently.

I find that this use case appears sometimes (we need to duplicate example testcase and modify it a little, or run it ourselves in the console for some reason).
Not sure if this can be done OS-agnostically in Java.

When it is looking somewhat mature, make a website of the project, promote it on CF/CodeChef/etc.

If parsing kind of seemed to work, but returned no results (no tasks or no testcases), the result should be negative.

There should be icons for the various possible verdicts, and the "result" column in problem view should be formatted using some sort of a custom formatter which shows the icon, runtime, exit code if non-zero etc.

Button to browse for the executable file, right of the filename textfield. The textfield should still be editable "by finger".

If tested program reads no input (but the testcase has input), it can termiante before we write the input to the stdin and it will cause IOStreamException Broken Pipe or Stream Closed. Then the result will be "aborted" while it should process the testcase normally comparing output with expected output.

...rather than in the upper left corner of user's screen. Also, the "parse contest" / "parse problem" dialogs should have a title.

...instead of entering a "tab" character.

Now that Krig has made most shortcuts editable, the same should be possible for "New contest" and "New problem" (particularly if someone wants to change, for example, "add test" to Ctrl+N).

It takes some noticeable time to show up (at least the first time it's opened). If we confirm that it's only during the first time, is it possible to somehow preload it when the program starts?