Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change request: Replace the GLSL parser #677

Open
AndrewRayCode opened this issue Nov 20, 2022 · 1 comment
Open

Change request: Replace the GLSL parser #677

AndrewRayCode opened this issue Nov 20, 2022 · 1 comment

Comments

@AndrewRayCode
Copy link

Describe the bug
AstExplorer.net currently uses the stackgl glsl-parser as the GLSL parser. At the time, this was really the only Javascript parser available, and the best choice.

Today, we know this parser is buggy, incomplete, and doesn't process valid GLSL input. It's also likely abandonware at this point as bug reports aren't responded to.

The StackGL GLSL parser can only handle (a limited subset of) the older version of the GLSL language, "GLSL ES 1.00", which came with WebGL 1. The parser cannot handle the current version of GLSL, "GLSL ES 3.00", supported by WebGL 2. Any new library created today that needs a GLSL parser needs ES 3.00 support.

I have written a new GLSL parser/compiler, @shaderfrog/glsl-parser, that handles all of the above. It's relatively new, but due to its full support of both versions of the language, it's already in use by 28 other projects (that I'm aware of).

I propose replacing the StackGL parser with the Shaderfrog GLSL parser. Other than being the author, my other disclosure is my own personal interest in this is having a nice UI to debug my ASTs 😃

@fkling
Copy link
Owner

fkling commented Nov 25, 2022

Other than being the author, my other disclosure is my own personal interest in this is having a nice UI to debug my ASTs

Thanks for the disclosure 😆 That's still an unsolved problem to me: What should the criteria be for adding a parser to astexplorer? Popularity? Language? There are no official guidelines at the moment.
On one hand I don't want to add everybody's toy parser, on the other hand small projects an still be very useful to others.

In the long run it would be cool if it were possible to also dynamically load parsers from npm to provide some kind of "ad-hoc" playground (just like actual code playgrounds work I suppose). But a couple of other things need to happen first to make that work.

But coming back to your question, I don't see a problem to simple add your parser. We don't have to remove the other one yet, though of course we eventually should (or at least hide it) if it doesn't receive any updates anymore.

I suggest you have a look at existing parser integrations for how to add your parser!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants