It might be useful to have a mode where after finishing a run, the delta search automatically runs again on the minimized input to see if another pass yields further minimization, up until a fixed point.

CI seems to be broken on node.js v4 and has been for some time. See this job:

https://travis-ci.org/wala/jsdelta/jobs/636746183

Probably caused by some dependency bump. Probably we should just drop support for node.js v4.

@esbena thoughts?

In quick mode (on the modernise branch), we still seem to try to delete individual arguments to function calls, since we're minimizing all arrays. Ideally, this wouldn't happen. It's not a huge deal, except for cases where each run of the JS-processing program takes a long time, and you really want quick mode to not dig in beyond the statement level.

If installed with -g, we should create a jsdelta script that will be in the user's path.

Spinoff of #48. From that issue:

Then, I ran into an issue with delta_multi.js trying to delete entire directories, as it would also delete parent directories of main.js, leading to a failure to stat the file. This I think we can fix.

In someone's copious spare time... :-)

We could do it as described here: http://blog.regehr.org/archives/749

I'm wondering if we should make the new fixpoint mode on by default. Or maybe it should just even be on always, and not be an option. @xiemaisi any thoughts?

The current implementation of delta_multi.js finds a fix-point for the shasum of the reduced target directory. That process does not terminate if the target program dynamically generates new files in the target directory, since the new files will change the shasum!

Solution: let all reduction steps return true/false based on their success. The fixpoint is reached if they all return false during one fixpoint iteration. (this should also be faster since the shasum computation is avoided)

To reproduce:

echo '{"foo": 3}' > test.json
jsdelta --cmd false test.json

Result:

Testing candidate /tmp/tmp1/delta_js_0.json (11 bytes)
    aborted with error
Starting iteration #0
Target: /tmp/tmp1/delta_js_1.json (1 bytes)
Testing candidate /tmp/tmp1/delta_js_1.json (1 bytes)
    aborted with error
Starting iteration #1

/usr/lib/node_modules/jsdelta/src/file_util.js:43
        throw e;
        ^
Error: Line 2: Unexpected end of input
    at constructError (/usr/lib/node_modules/jsdelta/node_modules/esprima/esprima.js:2406:21)
    at createError (/usr/lib/node_modules/jsdelta/node_modules/esprima/esprima.js:2425:17)
    at unexpectedTokenError (/usr/lib/node_modules/jsdelta/node_modules/esprima/esprima.js:2499:13)
    at throwUnexpectedToken (/usr/lib/node_modules/jsdelta/node_modules/esprima/esprima.js:2504:15)
    at expect (/usr/lib/node_modules/jsdelta/node_modules/esprima/esprima.js:2522:13)
    at parseGroupExpression (/usr/lib/node_modules/jsdelta/node_modules/esprima/esprima.js:3138:17)
    at inheritCoverGrammar (/usr/lib/node_modules/jsdelta/node_modules/esprima/esprima.js:2680:18)
    at parsePrimaryExpression (/usr/lib/node_modules/jsdelta/node_modules/esprima/esprima.js:3238:20)
    at inheritCoverGrammar (/usr/lib/node_modules/jsdelta/node_modules/esprima/esprima.js:2680:18)
    at parseLeftHandSideExpressionAllowCall (/usr/lib/node_modules/jsdelta/node_modules/esprima/esprima.js:3413:20)

delta_js_1.json consists of a single newline; I assume what's going on here is that the JSON is being reduced down to what would be a syntactically valid JavaScript program (which does nothing at all) and then interpreted as JSON (which doesn't like an empty string).

This would be a simple generalization of the substring matching we do now

I've been trying to use jsdelta in a multi-file scenario but not having much success. Here's the command I am using:

node delta.js --cmd predicate.sh --msg some_msg --dir program_dir relative/path/to/main.js

The first thing that tripped me up is that I think the path to the "main" source file must be relative to program_dir, not an absolute path. If this is correct, we should document it.

Then, I ran into an issue with delta_multi.js trying to delete entire directories, as it would also delete parent directories of main.js, leading to a failure to stat the file. This I think we can fix.

My main problem is the following. Really, my analysis is running over all scripts in program_dir; there is no "main" source file to be distinguished from the others. When jsdelta is minimizing other files, I still see printed in the output:

Testing candidate main.js (XXXX bytes)
              aborted with other error
          Original file doesn't satisfy predicate.

Is this expected? Or is the search getting messed up somehow because the "Original file doesn't satisfy predicate"?

I think in the multi-file mode, there should be no need to specify a "main" file, and things should just work. Maybe my mental model for how the tool is working is wrong, though.

@esbena any thoughts / memories around this? 🙂

We should print out the stdout and stderr output.

I don’t use JSDelta very often, so when I do have need for it I generally have to puzzle out how to get it do do what I want again. I'm therefore opening this issue to serve as a collection of recipes for using JSDelta in different situations.

Right now the file to be minimized needs to be passed as the final argument (I think). We should use a standard library so that the argument order isn't so sensitive.

JSDelta is currently only able to do reductions for a single source
file at a time. We will soon be developing support for exploring
reductions of multiple files in a single run of JSDelta, and we will
make a pull request when the feature is done.

The feature is JavaScript independent, and any delta-debugger could
make use of it, but I am not aware of any available solutions. Are
you?

If not, then we will implement it from scratch according to the
following plan, input is welcome.

Plan

Conceptually, two new AST-nodes will be added: directories and files.

This means that:

• directories will be treated as statements currently are
  (i.e. "binary-search" and recursive deletions of files/directories)
• files will be treated as expressions currently are (i.e. individual
  mutations, but through an application of the current JSDelta)

Practically, each iteration will be a done on a full copy of the
latest successful reduction (we might need to delete the unsuccessful
copies for space reasons). File- and directory-names probably needs to
be kept unchanged.

Implementation-wise, JSDelta will need to remember (these two are
currently the same thing):

• where the "main-file" is relative to the root directory
• which file/directory that is being reduced

When jsdelta is passed a JSON file, it outputs candidate files (delta_js_1.json and so on) with the JSON wrapped in parentheses, like so:

({"foo": "bar"});

This means that the file is not valid JSON, so trying to delta JSON files doesn't work properly.

I don't know enough about esprima to be able to immediately identify why it's doing this and how to stop it. For my test script I have worked around this by stripping the characters out with the following ugly hack:

if grep '^({' $1 > /dev/null ; then
        cat $1 | head -c-2 | tail -c+2 > $TMPDIR/npm-shrinkwrap.json
else
        cp $1 $TMPDIR/npm-shrinkwrap.json
fi