Skip to content

Rhai playground (using WebAssembly) #169

Closed

Description

@alvinhochun

The idea is to make a playground for Rhai scripts that runs in a web browser which can showcase the features of the Rhai scripting language. It might also be possible for others to repurpose it as a Rhai script editor.

I've started an attempt on https://github.com/alvinhochun/rhai-playground, but I am not making any promises.
The master branch gets automatically built and deployed to: https://alvinhochun.github.io/rhai-playground-unstable/
I might irregularly upload specific builds to: https://alvinhochun.github.io/rhai-demo/

Wish list (not a roadmap or to-do list):

  • Ability to run Rhai scripts
  • Proper syntax handling for Rhai scripts
  • Real-time AST compilation with error reporting (already works though pretty limited)
  • Integration with the book (embedding is now possible)
  • REPL
  • Autocomplete list for built-in packages
  • Provide more fancy IDE-like features
  • Engine settings
  • Custom modules
  • Heuristically guess variable types?
  • Debugging

Activity

  1. schungx commented on Jun 21, 2020

    @schungx
    Collaborator

    Added an entry in #100

  2. schungx commented on Jun 21, 2020

    @schungx
    Collaborator

    Real-time AST compilation with error reporting

    This may be quite possible because the parser is fast enough. If you trottle the parsing during 500ms pauses or so it'll probably work fine...

    However, the parser currently bugs out at the first error, which may not be perfect. To have a good experience, we really need reasonable error recovery, as per #119

    Autocomplete list for built-in packages

    This may not be easy as Rhai is dynamic, so there is no type information. It is difficult to know how to filter the list.

  3. alvinhochun commented on Jun 22, 2020

    @alvinhochun
    ContributorAuthor

    Autocomplete list for built-in packages

    This may not be easy as Rhai is dynamic, so there is no type information. It is difficult to know how to filter the list.

    It will just be unfiltered (i.e. only filtered based on whatever the user already typed in) to start with. If it ever gets advanced enough to be able to heuristically guess the data types (which seems very unlikely) then perhaps it can be developed further. Another idea could be type annotation comments but I don't aim to discuss this...


    I realized that it might be easier to code the playground if it can have direct access to the AST content, but it looks like a lot of it is currently inaccessible from the outside. I might also end up wanting to use some other innards or Rhai to implement other functions. That means I might have to maintain a fork for playground-specific use and the playground repo will stay as a separate repository. Do you have a better idea?

  4. schungx commented on Jun 23, 2020

    @schungx
    Collaborator

    I can open up AST including the Expr, Stmt and Token types. Never did realize that users will want to know the inside details, so I kept them private before in order not to break code when I change the implementation.

    Or do you think hiding a pub behind a feature gate?

  5. schungx commented on Jun 23, 2020

    @schungx
    Collaborator

    @alvinhochun if you'd pull from my fork instead: https://github.com/schungx/rhai

    The latest version has a new feature internals that exposes the internal data structures of the AST.

  6. alvinhochun commented on Jun 23, 2020

    @alvinhochun
    ContributorAuthor
  7. schungx commented on Jun 23, 2020

    @schungx
    Collaborator

    You mean a rhai_core and a rhai that only re-exports the common API?

  8. alvinhochun commented on Jun 23, 2020

    @alvinhochun
    ContributorAuthor

    How about splitting the parser and AST stuff to a rhai_ast crate?

  9. schungx commented on Jun 23, 2020

    @schungx
    Collaborator

    How about splitting the parser and AST stuff to a rhai_ast crate?

    Hhhmmm... that probably should work, but I'd hesitate to split a simple proj like Rhai into two yet even simpler crates. Unless there is an overwhelming reason...

  10. alvinhochun commented on Jun 23, 2020

    @alvinhochun
    ContributorAuthor

    Maybe it'll just be simpler for me to maintain a fork for the playground.

  11. schungx commented on Jun 23, 2020

    @schungx
    Collaborator

    Maybe it'll just be simpler for me to maintain a fork for the playground.

    You don't have to. Just turn on features = [ "internals" ] and you basically get rhai_ast there.

    I fully intend to merge this feature into master a bit later.

  12. alvinhochun commented on Jun 25, 2020

    @alvinhochun
    ContributorAuthor

    I experimented on whether I can reuse the existing Rhai tokenizer code for syntax highlighting, turns out it takes quite some modifications.

    This is the modified code that "works" (if you diff it against the original code snippets you might be able to tell how it was changed):
    https://github.com/alvinhochun/rhai-playground/blob/184d88e6fb86e18fc525cd24233b77d1898bfa6c/src/cm_rhai_mode/token.rs

    I also uploaded a build with this new syntax highlighting. (Compare with the previous Rust highlighting)

    The main difference is that, CodeMirror (the editor I'm using) only gives one line to the tokenizer at a time. It also caches the tokenizer state per line so that it can restart the tokenization from any line. This means I had to change how block comments are handled. (I am also surprised to see that Rhai doesn't support multi-line strings...)

    How do you think about refactoring the tokenizer in Rhai to allow the code to be reused? I'm thinking of splitting the "streaming" part in TokenIterator into a separate trait so I can make an adapter for the CodeMirror stream, and also somehow make it handle per-line tokenization. (Though I am also wondering if I can use the actual AST for syntax highlighting.)

  13. 49 remaining items

  14. alvinhochun commented on Jul 6, 2020

    @alvinhochun
    ContributorAuthor

    I'm thinking perhaps I should make a Reddit post about the playground, how do you feel about this?

    This is a great idea. However, you really need a semi-permanent URL for this, because you don't want it to change later on.

    Have you decided on the final URL for the playground?

    Right now it is a couple of links to different versions.

    Maybe have a landing URL that is the current stable version, then a link to "vnext" or "experimental" on the landing page?

    I suppose I will be keeping https://alvinhochun.github.io/rhai-playground-unstable/. If you think it is necessary to have one to be called "stable" I would just copy the current build to https://alvinhochun.github.io/rhai-playground/.

  15. alvinhochun commented on Jul 6, 2020

    @alvinhochun
    ContributorAuthor

    Also, right now, there is a noticeable pause when the user presses Run the first time. That is to wait for the WASM package to load. This is bad for user experience, especially the very first button click.

    I'd suggest either pre-loading that WASM package or put up a spinning loading gif...

    How about I just print "Initializing Web Worker..." to the output box for now?

  16. schungx commented on Jul 7, 2020

    @schungx
    Collaborator

    Suggestion:

    Right now it says "Running" on the Stop button's tooltip - if it is actually running, it'd start counting.

    Therefore, you can change that text to "Initializing, please wait...", plus also put a message to the output box.

    That should do it.

  17. alvinhochun commented on Jul 7, 2020

    @alvinhochun
    ContributorAuthor

    Ok, I've dealt with some of the issues. Most notably, there is now only one .wasm file which saves about 150KiB of download (gzipped) loading the worker. Frequent output printing no longer take as much resources (you can run primes.rhai with print without making the browser slow down to a crawl). I also add a loading tooltip like you suggested.

  18. alvinhochun commented on Jul 7, 2020

    @alvinhochun
    ContributorAuthor

    I made https://alvinhochun.github.io/rhai-demo/ a redirect. You can change all references to the new URL https://alvinhochun.github.io/rhai-playground-unstable/.

    I'll probably make a Reddit post later today...

  19. alvinhochun commented on Jul 11, 2020

    @alvinhochun
    ContributorAuthor

    I implemented a modules proof-of-concept on the modules-test branch (not deployed). (Honestly, I find my code quite amusing...)

    So, I want to allow scripts to be added as modules with user-specified names, which can be used when running the main script. Of course, the Playground has to provide a way to manage the modules, perhaps even the ability for them to be exported and re-imported. Makes sense?

    Or would you suggest me work on something else before that?

  20. schungx commented on Jul 12, 2020

    @schungx
    Collaborator

    So, I want to allow scripts to be added as modules with user-specified names, which can be used when running the main script. Of course, the Playground has to provide a way to manage the modules, perhaps even the ability for them to be exported and re-imported. Makes sense?

    That would make it more than a simple Playground, though. You're going to be keeping a local store of scripts on behalf of users.

    You may actually have a "standard" list of modules and hook up a module resolver so users can load different pre-built modules. But to allow users to register their own modules and use it in their scripts, that's going to add a whole new dimension of functionalities.

    You might as well also have script storage.

  21. schungx commented on Jul 12, 2020

    @schungx
    Collaborator

    But still, having modules working in WASM is way cool!

  22. alvinhochun commented on Jul 12, 2020

    @alvinhochun
    ContributorAuthor

    That would make it more than a simple Playground, though. You're going to be keeping a local store of scripts on behalf of users.

    You may actually have a "standard" list of modules and hook up a module resolver so users can load different pre-built modules. But to allow users to register their own modules and use it in their scripts, that's going to add a whole new dimension of functionalities.

    You might as well also have script storage.

    I had given script storage a bit of thought before. The "simple" way is to use localStorage to store scripts, but localStorage size is rather limited. I have no experience with IndexedDB and it seems a bit complicated on first glance. Therefore I want to leave this for later.

    For now, I wanted to just make a per-session (i.e. until page refresh) script storage to start with. I can perhaps implement something like drag-drop to add files as scripts to make it easier to load user modules. If you want to suggest any "standard modules", I can include them too.

    There is also the case of embedding - if a page embeds the playground, I would like the page to be able to provide predefined modules, and also not have it affect the local storage.

  23. schungx commented on Jul 12, 2020

    @schungx
    Collaborator

    For now, I wanted to just make a per-session (i.e. until page refresh) script storage to start with. I can perhaps implement something like drag-drop to add files as scripts to make it easier to load user modules. If you want to suggest any "standard modules", I can include them too.

    Well, if you do that, people are gonna hate you... nobody wants to redo a whole bunch of modules the next time round.

    I think indexDB is probably the best.

    Actually localStorage shouldn't be too bad. The typical scripts are very short. They should fit comfortably inside localStorage.

  24. schungx commented on Aug 4, 2020

    @schungx
    Collaborator

    Pinging @alvinhochun ... The latest drop adds closures support. Would be really interested to see if running in the playground! :-D

  25. alvinhochun commented on Aug 6, 2020

    @alvinhochun
    ContributorAuthor

    Done, I've bumped it to Rhai 0.18.1 and it's deployed.

    (As you can see, there had not been any changes recently because I shifted my focus to another project, but I will get back to it soon.)

  26. schungx commented on Feb 4, 2021

    @schungx
    Collaborator

    Since the Playground is now part of the org, closing this now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions