Lectrote 1.2.4 now supports Hugo


Dannii has (if I understand correctly) compiled the C Hugo source with emscripten and linked it to glkote. The result is a working Javascript interpreter. (Though not based on the HugoJS that Juhana did last year.)

I’ve only done a couple of moves worth of testing, using Clockwork Boy 1 and 2. Give it a shot.

Great news!

I’ve run into a couple issues in my testing. First off, the interpreter hangs if a game ever tries to draw a status window more than 1 row tall.

A game also hangs if it tries to read or write from an external file (I call them configuration files; I don’t remember what Hugo calls them). Currently, Roodylib uses that feature to detect interpreter capabilities. I could turn it off for glk games, but it’s worked to varying success in previous glk implementations (both read/write work in the Windows glk client, while just reading works in Gargoyle).

Sample games? I note that clockworkboy.hex has a two-line status window, but I don’t see a hang.

If you see a hang, it may be useful to use the “Toggle developer tools” menu option and look for errors in the JS console.

Here is a screenshot of the console window after the error: https://snag.gy/s5HX1l.jpg

And here is a compiled example where you can see it for yourself: https://drive.google.com/file/d/0B_4ZXs4Z_yoWanEzTHlOdVcwbG8/view?usp=sharing

Ah, yep I see what the bug is. A dumb mistake on my part.

These files will fix the window height bug: dropbox.com/s/8565ksh1os3qou5/hugo.zip?dl=0
Put hugo.js and hugo.js.mem in the Lectrote/resources/app/hugoem folder

Can you please share the code for the file command?

The code is:

routine DoFile { local opcodeterp_check readfile "HrCheck" { opcodeterp_check = readval } writefile "HrCheck" { writeval opcodeterp_check } "File stuff tested." }

So, it’s choking because it’s not finding a file called “HrCheck”, but in those cases, the interpreter is really supposed to shrug and go on.

I’ve fixed the file bug and updated the Dropbox zip.

It was the same bug as Gargoyle has (because my Hugo repo is based on Garglk’s hugo code) so Gargoyle will be able to be fixed too.

Very cool. Thanks for looking into it!

I’ve put up Lectrote 1.2.5 with those Hugo fixes. Thanks.

Thanks for this, I updated Thunderword Experimental to the 3.3.0 Hugo tree.

Info for Mac users & non-native English speakers:
You can look up a word from system-installed dictionaries via a 3-finger tap on a word in Lectrote. (The standard OSX context menu, also supported by standard Chrome, i.e. right-click then “Look Up”, seems not yet supported by the Electron shell.)

I gather this means I can add Lectrote to the Hugo column on the IFwiki interpreter page for Windows, Linux, and Mac OS X. Is that correct? Does this also apply to Mac OS 10.12?

Yes and yes.


I’ve posted a new Lectrote release (1.2.8, see github.com/erkyrath/lectrote/releases ).

Dannii has been updating the Hugo and glk/emscripten modules, and asks:

I don’t know what Hugo games stress-test that, but try some and let us know.

Cryptozookeeper should do it.

I notice that this is in js, packaged with Chromium. Is there a way I can run this as a js application locally in Chrome?

Not as far as I know. It relies on Node.js, which is packaged in there too.

Cryptozookeeper is what I was testing with, and I increased the undo buffer to 4096 so that it would have multiple undos. But I was only testing the beginning of the game, and it’s very conceivable that mid or late game would have different requirements on the undo buffer.

What do you mean by a “js application locally”? The Hugo interpreter could run as a normal web page, just like Quixe, but some extra code would be needed to support that. It won’t be able to run off file: without quite a lot more work because Chrome would block the resource files it requires. As an extension or saved application, yes in theory, but I don’t know what would be needed to set that up.

After an earlier conversation, I noticed that chrome has some extensions that work well with Twine and some online parser games. There are so many interesting extensions out there that manipulate text or allow you to access it in different ways, such as voice or text capture.

It would be nice to access more interpreters through chrome to allow the use of such extensions.