Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow eval before run #2618

Open
technomancy opened this issue Jun 19, 2024 · 1 comment
Open

Allow eval before run #2618

technomancy opened this issue Jun 19, 2024 · 1 comment
Labels
discussion Issues with no clear action or preferred solution enhancement Improvement of existing feature or adding something new

Comments

@technomancy
Copy link
Contributor

Currently in order to use the eval command, you have to first run and then hit esc to close the game.

For normal development this is fine. However, if this restriction were lifted, it would make it possible to automate tests; for example, you could run something like this:

$ tic80 --cli --cmd "new fennel" \
    --cmd "eval (fn _G.btnp [] (< 0.5 (math.random))) (set _G.btn _G.btnp)" \
    --cmd "eval (for [_ 1 1024] (_G.TIC)) (trace \"Success\")"

This would set the keypad to return random values and run 1024 tics of the game. If I could do this with all the Fennel-based TIC-80 games I've found, it would help a lot with testing new versions of Fennel to identify crashes, but I'd imagine that it would also be helpful for testing other changes to TIC-80. In the future perhaps even a --randomize-input flag could be added to further facilitate testing.

However when I tried a few different attempts of implementing this myself, I ran into dead ends. First I tried making changes in evalFennel so that it would call initFennel if the Lua VM was not yet initialized. This worked for basic code, but as soon as I went to call trace it would segfault abruptly. Then I thought maybe I was solving the problem in the wrong place; it would be better if it could work with any language, so maybe handling it in onEvalCommand was a better idea. I noticed that a lot of the initialization work was done in tic_core_tick instead of tic_init_vm, so that had to be moved. But it doesn't seem possible to call tic_init_vm from onEvalCommand anyway.

So, two questions:

  • is this a good idea in the first place?
  • if so, could I get some tips of where to start with the implementation?
@aliceisjustplaying aliceisjustplaying added enhancement Improvement of existing feature or adding something new discussion Issues with no clear action or preferred solution labels Jul 6, 2024
@bryce-carson
Copy link

* is this a good idea in the first place?

Absolutely; I have run into this while implementing the R language integration and I considered it a bug in TIC-80. It is currently a no-op; nothing happens, if I recall, if you try to eval before run.

* if so, could I get some tips of where to start with the implementation?

You can look at the following answer to your other question.

it doesn't seem possible to call tic_init_vm from onEvalCommand anyway.

This might work; it would depend on the state of the machine when this function is called.

static void onEvalCommand(Console* console)
{
  printLine(console);

  const tic_script* script_config = tic_get_script(console->tic);

  tic_init_vm((tic_core *)console->studio->mem,
              console->studio->code,
              script_config)

    if (script_config->eval)
    {
      if(console->desc->count)
        script_config->eval(console->tic,
                            console->desc->src+strlen(console->desc->command));
      else printError(console, "nothing to eval");
    }
    else
    {
      printError(console, "'eval' not implemented for the script");
    }

  commandDone(console);
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Issues with no clear action or preferred solution enhancement Improvement of existing feature or adding something new
Projects
None yet
Development

No branches or pull requests

3 participants