-
Notifications
You must be signed in to change notification settings - Fork 2
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
Question: source maps #11
Comments
Yes, each type of AST Node contains a Go: https://github.com/apexlang/apex-go/blob/main/ast/nodes.go#L30 This is used in the VSCode extension to highlight issues/errors in the Apex file.
By "continuous compiler setup" I assume you mean that whenever you update the Apex, that the code generates and if possible, the project is compiled. Right now, the VSCode extension at least runs In a sense, you can treat Apex as code and completely ignore the generated files. Apex could also be configured to run a compiler after codegen. However, I'm wondering if the continuous compilation function should be handled externally, by the IDE or custom setup. If you have thoughts on how this would work, please share them 😄 |
Let me look at the code and play with it first before i comment. I built a similar thing in the past and there are many ways to do this depending on the objectives. Are you trying to feed VSCODE or a web IDE etc ? I presume vscode since you have an extension like https://github.com/apexlang/vscode-extension |
Does this allow to look back at the IDL from the runtime ?
So if you compile a idl , when you’re using it at runtime you can see the line of code from back in the IDL
debugging is then easier.
Maybe source providence is a bette name for this :)
then with a continuous compiler setup you can see the wrong code, edit it, and get a new wasm module load up. Compiler as a service with quasi “edit and continue” debugging .
Thanks . Apex is amazing
The text was updated successfully, but these errors were encountered: