[size=85](I also intend to later work further on Famizork, which is the Z-machine implementation for Famicom.)[/size]
I don’t know; I have not even heard of such thing (I also don’t know if it will allow it to work with Synchronet and/or Windows Script Host). However, it might be slow and waste memory if compiled into a code which doesn’t use ArrayBuffer or stuff like it. But once the full codes are released, you are welcome to try it and report your results.
I am also writing a very simple HTML front-end, mainly for testing it; this front-end does not support split-screen, transcripts, or save games; JSZM does itself support these features though, and you may implement your own front-end which does, or modify the existing one.
Well, it is just how I program; I tend to use short names for local variables (although the variables in the “run” method do have longer names). I can add comments in case it is unclear (but it seems clear enough to me), although sometimes I also reuse local variables for multiple purposes (parseVocab uses “n” for two different purposes).
I am actually using DataViews; “this.view” is a DataView (and “this.mem” is a Uint8Array that views the same ArrayBuffer; both initialized in the “run” method). Note that there is a lot of code not shown in this small excerpt. (Also, “this.memInit” is not the same as “this.mem”; this is why the DataView methods are not used in the constructor function.) (The “get”, “getu”, “put”, and “putu” methods then wrap the DataView methods.)
If you have any further questions, comments, complaints, or whatever, then please mention them here.
I, too, occasionally use one-character variable names, especially on one-line callbacks. But I also never write code where a function-level variable is declared more than five lines above where it gets used, and I think the entire codebase for Improv has like two let statements in it and all the rest is const, so I feel like in my case it’s a justified Haskellism rather than obscurantist…
Well if you want anyone else to use the code then you should make it as straight forward as possible. And I’m not saying that short names must never be used (I’m sure we’ve all used i for a loop index), but it’s not others friendly when 90% of the variables are one character long.
And just make sure you’re not reusing variables with different types, as that makes it very inefficient.
The new version of does now have comments in getText explaining what each local variable means, and I think I am not reusing variables with different types, as far as I can tell. However, changes can be made later if needed. Also, the file does include documentation at the top about how to use it. I expect to post full codes soon (maybe in one or two days), and then further complaints can be made more precisely and I can know which to fix.
It seems to mostly work now, but there are still some problems. I am using ZORKMID (my interpreter in C) to help with debugging; I am finding it to be very useful for this purpose. (It was actually intended for debugging story files, although I am finding it much more useful for debugging interpreters. Why?)
Currently it works like this: The “run” method is a generator function that yields stuff directly, while functions defined by front-end are not generator functions.
Possibly the better way would be: The “run” method is a generator function that does not yield anything directly, but instead calls the front-end functions by “yield*” and then the front-end functions may yield stuff.
I suppose it is another way, although I believe generators are easier to work with. (If the front-end wishes to implement split-screen, font changing (fix pitch and variable pitch), and/or transcripting, then this also becomes more difficult. There is also save/restore prompts.)
I did write a (not yet published) Node.js package which includes functions for dealing with curried-callbacks functions, including to convert the built-in Node.js stuff into curried-callbacks format, to convert promises into curried-callbacks format (and also the other way around), and to run a generator that yields functions that take a callback as their only argument. (This last way makes it possible to still use callbacks.)
I expect I will keep version 1 as is (although perhaps fix bugs in version 1.0.1 or whatever, if any), but will make version 2 in the new way I suggested. I could even add convenience function to do it in the ways you have suggested too, if you would suggest how to deal with the problems I have listed.
(Also, eventually I will write XJSZM, which is ZIP/EZIP/XZIP/YZIP and therefore has a more sophisticated API, but is still with generators.)
If you have any other comments and/or complaints, then please write those on here too.
Example of a simple front-end with Node.js: example.js
It now is using all generators, there are also a few bug fixed too. In addition, if “module.exports” exists it will export it so that it can be used with Node.js. If you have other suggestions for convenience functions and whatever else, then you could do so.
It won’t work with any .z5 try with a .z3. Later I can make XJSZM which will support other Z-machine version too. Also, the API has changed since display.html was made (which didn’t work anyways), so try using the example front-end for Node.js which works better. You can also try to write your own HTML-based front-end; hopefully you know how to do it better than I do (I couldn’t get scrolling to work properly).
Version 2.0.2 of JSZM is now released, which fixes a minor bug with PRINTC and which now has documentation. (When XJSZM is released, it will be announced possibly on a different thread.)