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
Currently when opaque types/processes are used the script fails because it does not have definitions for opaque items. It would be nice if .js files could be loaded into the Web IDE and used to "fill in" opaque types and processes during KSY development. The Web IDE could scan the JS Code (debug) for opaque items by looking for "require('./SOME_FILE.js')" to extract the file name then identify if this external item has a KSY file. If it does then do nothing. If it does not then scan for a corresponding .js file and if found then copy js file contents to bottom of JS Code (Debug). The re-parsing would then work and allow users to test opaque items.
The text was updated successfully, but these errors were encountered:
@SpenserStyles Please also take a look at kaitai-io/kaitai_struct#143 as well. It discusses probable decoupling of "visualizing" and "parser engine" parts, which would allow to use language-specific class implementations (for example, by running "engine" written in C# and using C# parsers + C#-specific opaque types + webIDE written in JS).
Currently when opaque types/processes are used the script fails because it does not have definitions for opaque items. It would be nice if .js files could be loaded into the Web IDE and used to "fill in" opaque types and processes during KSY development. The Web IDE could scan the JS Code (debug) for opaque items by looking for "require('./SOME_FILE.js')" to extract the file name then identify if this external item has a KSY file. If it does then do nothing. If it does not then scan for a corresponding .js file and if found then copy js file contents to bottom of JS Code (Debug). The re-parsing would then work and allow users to test opaque items.
The text was updated successfully, but these errors were encountered: