Question: is there a way to load the .ne files in the browser?

[swooboo]

I'm considering adding a nearley-based parser to one of the projects I work on (HERITAGE). As it stands now, I can't keep it client-side only, and have to compile the .ne files server-side, with node.js. Is there a way to do this on the client?

[alyssarosenzweig]

Look at the internals of nearleyc for how the tool is implemented. I don't know if this is supported, but I imagine you should be able to replicate that with browserify or the likes.

[alyssarosenzweig]

On the other hand, from reading the linked issue it seems this is an X/Y problem. Why not compile the .ne files on your development machine and package the resulting .ne.js with the project, statically? This is supported behavior and is used by several of nearley's dependants -- including my own project, uPresent :-)

[kach]

You don't need to compile the files on the client — you compile them ahead of time and use the compiled files on the client. It's kind of like using LESS CSS or CoffeeScript: it works great on the client!

[kach]

(Also: HERITAGE looks so cool! I'm a big IF nerd and I love seeing IF generation projects.)

[swooboo]

Thank you @bobbybee and @Hardmath123 for your extensive answers. I insist on client-side compilation, because, in my mind, HERITAGE should not be dependent on any server-side activity. So that, I can edit the code on any machine, and develop the game regardless of whether I have node.js or any other dependency for this matter. I liked the uPresent, and I wish I had this 3 months ago when I was writing my project documentation... I wish... Anyway, if I do rely on server-side logic, I won't have the standalone-ity of HERITAGE any more. That's why I'm asking. That's also one of the reasons I don't use LESS or SASS. I use ECMA5 Script, but I use Babel that compiles it on the client. (I know this is not the right way, but I don't care, because ECMA5 will soon (hopefully) be supported by major browsers.) So, do you think there is a way? If not, this means that I'll have a .ne file in my repo, which, if changed, will have to be compiled on some machine that can do it. I will consider just compiling it once, and then extending it in the code itself though, without nearleyc'ing it every time...

BTW, what's IF?

[kach]

IF is short for Interactive Fiction, or text-based adventure games. :-)

To clarify, anyone using HERITAGE won't need node, because you can just give them compiled .ne.js files. Assuming the grammar is fixed, you can even develop HERITAGE without node.

If you insist on being able to develop HERITAGE without node, though, you still have a few options:

1. As you suggested, compile it once and then modify the generated JS file manually — it's not that difficult once you get used to it.
2. I could write a simple web-based frontend to the compiler, in the style of http://pegjs.org/online, so that you can compile without installing node and then copy the generated JS code to your project.
3. I guess I could add an option in nearley to read a grammar directly from a string and compile it on-the-fly. But I think (1) or (2) are better ideas.

What do you think?

[swooboo]

2 or 3 are preferable for me, and 3 is better. That's how I use Babel today. I know it's sub-optimal, but ATM I don't care. Or, if 2 is exposed enough, I could write a Makefile that will 'compile' the code using a wget query with the grammar as a parameter. Editing JS manually is, indeed, possible, but I would really like to preserve the .ne files usability so grammars can be changed more easily.

Thanks for the great support @Hardmath123 :)

[alyssarosenzweig]

@swooboo I guess I still don't understand why you are so dependent on the browser. As you said, your usage of Babel is not 'correct' in the sense that it has major performance (and stylistic) implications. Nearley doesn't have this feature setup because there is not a real reason to use it -- it would admittedly be neat for nearley's own documentation, but other than that, grammars are pretty much fixed from the program's launch -- I don't see how this is any different..

By the way, what text editor do you use?

[swooboo]

@bobbybee

1. For starters, having something like this PEG.js online compiler, would be good for demonstrative purposes of nearley.
2. While my usage of Babel is sub-optimal, it currently is substantial, and is not a subject of change until such need rises.
3. The fact that "grammars are pretty much fixed" usually, doesn't mean they always are / should be. That's why I want to be able to adapt the grammar parser with velocity and not compiling on different machines.
4. I use Sublime Text 3, with this syntax highlighting.

[alyssarosenzweig]

1. Agreed. That doesn't answer why you personally want it :-)

2. I think you would change your mind if you realized how little your workflow would be changed, but that's not my business.

3. And you can! I was worried for a moment you were using something like a ChromiumOS where installing was literally not possible. But it seems like you are more concerned about the productivity implications of having to type nearleyc (or babel for that matter) every time. While I don't personally use Sublime, I am positive if you research "hooks" or something like that, you'll find there is a way to run a certain command automatically whenever a file is saved, etc. Ideally, once you setup the integration on a given machine, you never think about it again, and you get clean code out.

---

Another idea to consider is the time you take to refresh your browser is worth something, too. Even if you don't choose to use a save-hook or anything like that, you should be able to run a script to run nearleyc / babel / linters / minifiers and then open your browser in a blink of an eye. Maybe even less work! In vim, :make with a suitable Makefile would do the trick :-)

[kach]

Hey @swooboo — here's a quick online thing I hacked together for you this morning. http://nearley.js.org/www/quick-compiler.html

Let me know how it goes.

[swooboo]

Hi.

Sorry for taking my time, I don't work on HERITAGE full time.

@Hardmath123 - this is very very nice indeed, I'll use it.

1. Do you think I can automate it, and generate the grammar on the fly? (non-interactively via API)
2. Minor issue - for some reason AdBlock catches it as popup, maybe you're doing some async stuff and lose the human origin of the event.

@bobbybee - I like your points, you provide truly valid constructive criticism.

2. Which changes would be done to the workflow? Will I need to have a machine with node.js installed on it + Babel / nearley compilers? That's my main issue - now I can use a text editor and that's it. Once I start compiling, I need to install many different tools.
3. I still think, that if there are no performance issues, no compiling is needed. Am I wrong? What is the added value of compiling besides performance?

Thank you both for the help and constructive criticism!

--swooboo

[kach]

1. If you look at the source code for quick-compiler.html, you'll understand how to compile grammars client-side. Then you can just do that directly in the JS for your project.

window.addEventListener("load", function() {
    var grammarInput = document.getElementById("grammar-input");
    var compileInput = document.getElementById("compile-grammar");
    compileInput.addEventListener("click", function() {
        var grm = grammarInput.value;
        var parser = new nearley.Parser(grammar.ParserRules, grammar.ParserStart);
        parser.feed(grammarInput.value);
        var result = parser.results[0];
        var compiled = Compile(result, {});
        var js = generate(compiled);
        window.open("data:text/javascript;charset=utf-8,"+encodeURIComponent(js));
    }, false);

}, false);

2. Your adblocker catches it as a popup because it tries to open a pop-up with the JS file you're supposed to download. Just make your adblocker ignore that website via a whitelist or something and you'll be fine.

[swooboo]

Thanks, I also figured I'd have to do that. I'll give it a go, looks good, thanks a lot for the support.

[kach]

Sounds good. Closing for now — but if you have further questions, feel free to ask.