Fix Compiler Sensitivity to Arguments

[peblair]

Currently, the compiler (the one freshly merged from new-horizons) is extremely sensitive to where and how you run it in a few ways:

This works:

pyret-lang$ node build/phaseA/pyret.jarr --builtin-js-dir src/js/trove \
                                         --builtin-arr-dir src/arr/trove \
                                         --require-config src/scripts/standalone-configA.json \
                                         --build-runnable ../junk/pyret/tbl.arr

But the following do not (due to file-locating errors):

pyret-lang$ node build/phaseA/pyret.jarr --builtin-js-dir src/js/trove \
                                         --builtin-arr-dir src/arr/trove \
                                         --require-config src/scripts/standalone-configA.json \
                                         --build-runnable /home/belph/junk/pyret/tbl.arr

~$ node pyret-lang/build/phaseA/pyret.jarr --compiled-dir pyret-lang/compiled \
                                           --builtin-js-dir pyret-lang/src/js/trove \
                                           --builtin-arr-dir pyret-lang/src/arr/trove \
                                           --require-config pyret-lang/src/scripts/standalone-configA.json \
                                           --build-runnable junk/pyret/tbl.arr

[jpolitz]

Can you paste the errors?

[peblair]

Error for the first example:

The run ended in error:
"Cannot find import dependency(\"file\", [list: \"/home/belph/junk/pyret/tbl.arr\"])"


Pyret stack:
  file:///home/belph/pyret-lang/src/arr/compiler/cli-module-loader.arr: line 251, column 10
  file:///home/belph/pyret-lang/src/arr/compiler/cli-module-loader.arr: line 242, column 4
  file:///home/belph/pyret-lang/src/arr/compiler/cli-module-loader.arr: line 324, column 9
  file:///home/belph/pyret-lang/src/arr/compiler/cli-module-loader.arr: line 371, column 12
  file:///home/belph/pyret-lang/src/arr/compiler/pyret.arr: line 99, column 10
  file:///home/belph/pyret-lang/src/arr/compiler/pyret.arr: line 69, column 4
  file:///home/belph/pyret-lang/src/arr/compiler/pyret.arr: line 162, column 4

Error for the second example:

The run ended in error:
Abstraction breaking: Uncaught JavaScript error:
 { Error: ENOENT: no such file or directory, open 'src/js/base/handalone.js'
    at Error (native)
    at Object.fs.openSync (fs.js:634:18)
    at Object.fs.readFileSync (fs.js:502:33)
    at PBase.makeStandalone [as app] (/home/belph/pyret-lang/build/phaseA/pyret.jarr:337834:26)
    at ActivationRecord.$temp_lam9369 [as fun] (/home/belph/pyret-lang/build/phaseA/pyret.jarr:686272:23)
    at Immediate.iter [as _onImmediate] (/home/belph/pyret-lang/build/phaseA/pyret.jarr:146009:26)
    at tryOnImmediate (timers.js:543:15)
    at processImmediate [as _immediateCallback] (timers.js:523:5)
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'src/js/base/handalone.js' }
Stack trace:
 Error: ENOENT: no such file or directory, open 'src/js/base/handalone.js'
    at Error (native)
    at Object.fs.openSync (fs.js:634:18)
    at Object.fs.readFileSync (fs.js:502:33)
    at PBase.makeStandalone [as app] (/home/belph/pyret-lang/build/phaseA/pyret.jarr:337834:26)
    at ActivationRecord.$temp_lam9369 [as fun] (/home/belph/pyret-lang/build/phaseA/pyret.jarr:686272:23)
    at Immediate.iter [as _onImmediate] (/home/belph/pyret-lang/build/phaseA/pyret.jarr:146009:26)
    at tryOnImmediate (timers.js:543:15)
    at processImmediate [as _immediateCallback] (timers.js:523:5)

[peblair]

I have a suspicion at least one of these stems from the contents of standalone-configA.json throwing off the compiler.

[jpolitz]

The second makes sense and is quite easily fixable; there's a template file that we copy into standalone JS files that is located relative to the working directory.

The first I'm a little confused by, because I think the file locator should have no trouble working with absolute paths. But I'll look into it. Thanks.

[schanzer]

@belph and @jpolitz , it's been four years and at least a few major revisions to the compiler. Is this still an issue?