Add HugoJS support

[erkyrath]

See https://github.com/juhana/hugojs . Use https://github.com/juhana/hugojs/wiki/Hosting-your-own-interpreter-instance as a starting point.

We will probably need to modify the interpreter a bit to start up from already-read data, and save/load to real files via electrofs.

[curiousdannii]

Emglken is another option now. Should I start working on it?

The license of Hugo is still non-free from what I can tell.

Edit: It seems that Kent has decided on a BSD-2-Clause license: http://develop.generalcoffee.com/hugo/trac/browser/trunk/License.txt If I take the code from there then we'll be set!

[erkyrath]

By all means give it a shot.

[curiousdannii]

hugo.zip

I've finished an initial basic port and it seems to work fine (with glkote-term). I haven't tested it in Lectrote yet. Included is a dispatch library.

Call it like usual. It needs Glk and GiDispa passed to it in the options. (When loading from HTML using window.GiDispa (or GiDispa) rather than new GiDispa() should work.)

[erkyrath]

I tried a quick integration, copying the way ZVM is loaded. It runs into errors when hugo.js is loaded:

Failed to load resource: net::ERR_FILE_NOT_FOUND — file:///Users/zarf/src/lectrote/hugo.js.mem
Uncaught could not load memory initializer hugo.js.mem — hugo.js:12 

Then it gets into an infinite loop somewhere after load_run is called. I haven't done any further investigation.

[erkyrath]

This is in the branch: https://github.com/erkyrath/lectrote/tree/hugo

You also need to modify quixe/src/quixe/gi_load.js -- I haven't checked in these changes. Add a case to load_run:

case 'hugoem':
    all_options.engine_name = 'HugoEm';
    all_options.game_format_name = 'Hugo';
    all_options.vm = window.Hugo;
    all_options.Glk = window.Glk;
    all_options.Dialog = window.Dialog;
    break;

[curiousdannii]

Oh, I should've realised this would be a problem. It defaults to looking in the base directory for the memory file. We could just move it to the same place as hugoplay.html, but that would be ugly. I'll look at what can be done.

Looking to the future, I'm keen to make more Emglken VMs. What if the folder was called emglken and they were all put together? Next time I'll also include a package.json in the zip.

[curiousdannii]

I've committed an update to https://github.com/curiousdannii/lectrote/tree/hugo

The gi_load.js code is now

    case 'hugoem':
        all_options.engine_name = 'Hugo';
        all_options.game_format_name = 'Hugo';
        all_options.memdir = 'hugoem';
        all_options.vm = window.engine = window.Hugo;
        all_options.Glk = window.Glk;
        all_options.GiDispa = window.GiDispa;
        break;

[erkyrath]

Thanks, will try this tonight.

(I'm going to rearrange the code to move the VM-specific sections to apphooks.js so that gi_load.js can be generic again. It's obviously getting clunky.)

I don't have a strong opinion whether to have a common folder or a bunch of separate folders. But it's nice to be able to have a separate version number for each VM, since they usually will be updated at different times.

[erkyrath]

Working, excellent.

[curiousdannii]

I should say that I'm really impressed with the Quixe API. It's clean and simple, but not restrictive or constraining.

[erkyrath]

I was about to to set up a release, but then I tried save/restore. They're not working.

When I try either, I get the exception and stack trace below. (This is with use_unminified_js:true in the options.) The exception happens as soon as the file dialog appears -- not after a file is selected. So it's somehow continuing on to the "resume" path before dialog.js calls its callback.

Uncaught glk_stream_open_file: invalid fileref

glk_stream_open_file @ glkapi.js:4636
_glem_stream_open_file @ hugo.js:1
vc @ hugo.js:5
Jd @ hugo.js:5
zb @ hugo.js:5
Ib @ hugo.js:5
Zb @ hugo.js:5
ic @ hugo.js:5
sb @ hugo.js:5
sb @ hugo.js:5
Wb @ hugo.js:5
zb @ hugo.js:5
Ib @ hugo.js:5
Zb @ hugo.js:5
xb @ hugo.js:5
sb @ hugo.js:5
sb @ hugo.js:5
sb @ hugo.js:5
resume @ hugo.js:1
EmterpreterAsync.handle.Module.glem_callback @ hugo.js:1
resume @ hugo.js:1
handle_line_input @ glkapi.js:391
accept_ui_event @ glkapi.js:168
send_response @ glkote.js:2142
submit_line_input @ glkote.js:2049
evhan_input_keypress @ glkote.js:2789
dispatch @ jquery-1.12.4.min.js:3
r.handle @ jquery-1.12.4.min.js:3

[curiousdannii]

Sorry, I didn't test it very thoroughly yet. (I mustn't have tested saving in Hugo at all, though I did for Git...) I'll look into it.

[erkyrath]

Looks good.

I once got a "unable to restore, different version" error. But I couldn't reproduce it after several more tries. (Also tried exchanging save files with Gargoyle.)

There may be something wrong in there, but I'll do the release and see how it crops up in the real world.

Thanks again.

[curiousdannii]

I haven't seen that error yet, but I'll be keeping a look out for it.

[curiousdannii]

On version numbers, rather than using package.json, I can provide you with a versions.json like this:

{
  "emglken": "0.1.4",
  "hugo": "3.3.0",
  "tads2": "1.7.7"
}

I think this would indicate the relevant versions with enough clarity. I'm not sure the best way to present it all in the about window though (especially once there are more Emglken terps.)

[erkyrath]

That would be great. I can set up the about window.

I can also set up the preferences window to offer a choice of interpreters for a given format, if necessary.

[curiousdannii]

Thinking more: the VM version numbers would be for the base branches not the Emglken ports, and the Emglken version number would be for library. The Hugo port wouldn't have its own version number, and, for example, adding graphics support may not require changes to the master branch of hugo. Would you be okay with having a major change like that described in the Lectrote release log but without a version number update? Or should I keep a separate version number for the ports? (Add a fourth digit perhaps?)

Actually I think I quite like the idea of a fourth digit for the port. It could be prefixed with a hyphen rather than a period, a la Debian package versions. "3.3.0-1"

[erkyrath]

I don't think we need to publicize two version numbers for each interpreter -- that would get crowded -- so "3.3.0-1" makes sense.