Very cool! If you added a Twostroke adapter to ExecJS (https://github.com/sstephenson/execjs), the ruby-coffee-script gem would work without modification.
I've been thinking of making a pure-ruby javascript interpreter in order to embed it into ExecJS as a fallback for when nothing else is present.
I believe this is only the case on Linux, but I've found that it gives my coworkers who are trying out rails for the first time quite a bit of confusion. (For that matter, it would help if execjs appended #readme in its error message instead of just to the github page, since the same coworkers were also unfamiliar with github, and didn't realize they had to look below the fold for the list of runtimes.)
Something like Twostroke could be useful if for some reason or other you can't embed V8 (eg. no platform support, no access to compilers, etc.) Twostroke is dog slow compared to a 'real' JavaScript engine, but it will do the job if there's no other options.
It's also a fun project that has taught me a lot about parsers, language implementations and JavaScript's object model.
That is, a parser which is essentially coded by hand, with all token checking, saving and restoring parser's state, functions corresponding to non-terminating symbols of grammar etc.
Are there no good parsing libraries in Ruby (similar to Python's pyparsing or Haskell's Parsec), and could this have forced the author to code his parser from scratch?
There's treetop, kpeg and a bunch of other stuff but I prefer writing my parsers by hand. Pretty much all that's missing from mine is semicolon insertion, but that's something I'm working to nut out.
Forced? I've written dozens of parsers, and personally I avoid parsing libraries like the plague - unless you're writing a really simple parser with few needs for error reporting and recovery, my experience is that parsing libraries usually end up being far more pain than they are worth.
Completely agreed. Once I got the hang of hand-writing parsers, I never looked back; they're higher-quality, generally faster, easier to write, and are easier to maintain than generated parsers.
I'm starting to wonder if the people behind these sorts of projects (eg. old console emulators written in JavaScript, this, etc.) are insane or if this is all some sort of epic trolling for lulz.
The front page for the project hasn't been updated in over 3 years, and a quick search for github activity shows stagnation too. What direction is this project heading and how fast is it getting there?
27 comments
[ 3.7 ms ] story [ 52.4 ms ] threadI believe this is only the case on Linux, but I've found that it gives my coworkers who are trying out rails for the first time quite a bit of confusion. (For that matter, it would help if execjs appended #readme in its error message instead of just to the github page, since the same coworkers were also unfamiliar with github, and didn't realize they had to look below the fold for the list of runtimes.)
It's also a fun project that has taught me a lot about parsers, language implementations and JavaScript's object model.
https://github.com/charliesome/twostroke/blob/master/lib/two...
That is, a parser which is essentially coded by hand, with all token checking, saving and restoring parser's state, functions corresponding to non-terminating symbols of grammar etc.
Are there no good parsing libraries in Ruby (similar to Python's pyparsing or Haskell's Parsec), and could this have forced the author to code his parser from scratch?
Should be pretty interesting to see Twostroke running on HotRuby running on Twostroke running on HotRuby running...