search

nuprl / Stopify

A JS-to-JS compiler that makes it easier to build Web IDEs and compile to JS.
https://zenodo.org/records/10408254
BSD 3-Clause "New" or "Revised" License
173 stars 12 forks source link

Propagate runtime config options about stack size #513

Closed jpolitz closed 3 months ago

jpolitz commented 3 months ago

Deep stacks, at least on the lazy impl, seem to be working as long as the runtime correctly gets the options about stack size.

This PR makes the (deep, lazy) test pass just by getting the config to the right places.

Eager is still failing with call stack size exceeded with these changes.

The runtimeOpts given to stopifyLocally were not used to configure any starting stack sizes (they go to the Runner https://github.com/nuprl/Stopify/blob/275d950193a9fc04175ed810834f9e1778108229/stopify/src/entrypoints/compiler.ts#L49, which hands them off via super to AbstractRunner, which puts them in a private field that's not consulted for stack configuration https://github.com/nuprl/Stopify/blob/275d950193a9fc04175ed810834f9e1778108229/stopify/src/runtime/abstractRunner.ts#L47.

This commit does that configuration on the init() method. I'm not sure that's the right place, but it's where the estimator and some other config happen based on the opts field, so it seems reasonable.

Separately, this also adds (optional) params to newRTS to configure stack size (since those are the parameters the constructors of the various runtimes take). With just this change (e.g. without the new configuration in init() that sets fields on rts), you can get deep/lazy working by using e.g.

stopify.newRTS('lazy', 1000, 10)

before calling .run(). But since stopifyLocally takes the runtimeOpts, it seems right to use them somewhere (https://github.com/nuprl/Stopify/blob/275d950193a9fc04175ed810834f9e1778108229/stopify/src/entrypoints/compiler.ts#L135).

NB: I'm also only able to make this test run by removing TextDecoder and TextEncoder from knowns in cannotCapture.ts (https://github.com/nuprl/Stopify/blob/master/stopify-continuations-compiler/src/common/cannotCapture.ts#L35). Would be useful to hear if others/the CI has the same issue; I don't want to add that change in case it breaks other things (someone added it deliberately at some point so there's got to be a reason they are there; https://github.com/nuprl/Stopify/commit/a4deef9d94875c8f531fb7af31a6d42bd6a803ce).

I'm not sure what's going on there (I'm on Node 22, TextDecoder seems to be defined when I eval it in the REPL), I get this error:

 FAIL  dist/test/semantics.test.js
  ● Test suite failed to run

    ReferenceError: TextDecoder is not defined

      at eval (eval at <anonymous> (../stopify-continuations-compiler/src/common/cannotCapture.ts:48:13), <anonymous>:1:1)
      at ../stopify-continuations-compiler/src/common/cannotCapture.ts:48:13
          at Array.map (<anonymous>)
      at Object.<anonymous> (../stopify-continuations-compiler/src/common/cannotCapture.ts:48:4)
      at Object.<anonymous> (../stopify-continuations-compiler/src/common/desugarNew.ts:14:1)
      at Object.<anonymous> (../stopify-continuations-compiler/src/callcc/callcc.ts:11:1)
      at Object.<anonymous> (../stopify-continuations-compiler/src/index.ts:5:1)
      at Object.<anonymous> (src/stopify/stopifyCallCC.ts:3:1)
      at Object.<anonymous> (src/compiler/compiler.ts:3:1)
      at Object.<anonymous> (src/entrypoints/compiler.ts:10:1)
      at Object.<anonymous> (test/semantics.test.ts:2:1)
      at processTicksAndRejections (node:internal/process/task_queues:95:5)
jpolitz commented 3 months ago

CC @blerner