You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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?
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?
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...
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.)
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?
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.
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?
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.
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.
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.
Activity
schungx commentedon Jun 21, 2020
Added an entry in #100
schungx commentedon Jun 21, 2020
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
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.
alvinhochun commentedon Jun 22, 2020
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
ASTcontent, 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?schungx commentedon Jun 23, 2020
I can open up
ASTincluding theExpr,StmtandTokentypes. 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
pubbehind a feature gate?schungx commentedon Jun 23, 2020
@alvinhochun if you'd pull from my fork instead: https://github.com/schungx/rhai
The latest version has a new feature
internalsthat exposes the internal data structures of theAST.alvinhochun commentedon Jun 23, 2020
schungx commentedon Jun 23, 2020
You mean a
rhai_coreand arhaithat only re-exports the common API?alvinhochun commentedon Jun 23, 2020
How about splitting the parser and AST stuff to a
rhai_astcrate?schungx commentedon Jun 23, 2020
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...
alvinhochun commentedon Jun 23, 2020
Maybe it'll just be simpler for me to maintain a fork for the playground.
schungx commentedon Jun 23, 2020
You don't have to. Just turn on
features = [ "internals" ]and you basically getrhai_astthere.I fully intend to merge this feature into master a bit later.
alvinhochun commentedon Jun 25, 2020
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
TokenIteratorinto 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.)49 remaining items
alvinhochun commentedon Jul 6, 2020
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/.
alvinhochun commentedon Jul 6, 2020
How about I just print "Initializing Web Worker..." to the output box for now?
schungx commentedon Jul 7, 2020
Suggestion:
Right now it says "Running" on the
Stopbutton'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.
alvinhochun commentedon Jul 7, 2020
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.rhaiwith print without making the browser slow down to a crawl). I also add a loading tooltip like you suggested.alvinhochun commentedon Jul 7, 2020
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...
schungx commentedon Jul 10, 2020
Ah, I see it.
https://www.reddit.com/r/rust/comments/hmtve2/rhai_playground_or_a_toy_project_of_using_rhai/
alvinhochun commentedon Jul 11, 2020
I implemented a modules proof-of-concept on the
modules-testbranch (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?
schungx commentedon Jul 12, 2020
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.
schungx commentedon Jul 12, 2020
But still, having modules working in WASM is way cool!
alvinhochun commentedon Jul 12, 2020
I had given script storage a bit of thought before. The "simple" way is to use
localStorageto store scripts, butlocalStoragesize 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.
schungx commentedon Jul 12, 2020
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.
schungx commentedon Aug 4, 2020
Pinging @alvinhochun ... The latest drop adds closures support. Would be really interested to see if running in the playground! :-D
alvinhochun commentedon Aug 6, 2020
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.)
schungx commentedon Feb 4, 2021
Since the Playground is now part of the org, closing this now.