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

Enable support for opaque types? #15

Closed
ams-tschoening opened this issue Mar 24, 2017 · 5 comments
Closed

Enable support for opaque types? #15

ams-tschoening opened this issue Mar 24, 2017 · 5 comments
Assignees
Labels

Comments

@ams-tschoening
Copy link
Contributor

I'm currently working to get my KSYs usable using an opaque type in the Ruby visualizer and by default it doesn't seem to work. I need to activate support for opaque types in the compiler:

args = ['--debug', '-t', 'ruby', fn, '-d', code_dir]
to
args = ['--debug', '-t', 'ruby', '--opaque-types=true', fn, '-d', code_dir]

I don't see any way providing this on the shell or such. So, do you want to provide some way or simply enable this feature like you hard code e.g. debug as well?

@GreyCat GreyCat self-assigned this Mar 25, 2017
@GreyCat GreyCat added the bug label Mar 25, 2017
@GreyCat
Copy link
Member

GreyCat commented Mar 25, 2017

My bad, I totally forgot about that. I'll add some CLI options to ksv, would it be ok?

@ams-tschoening
Copy link
Contributor Author

Sure, but hard coding wouldn't be a problem for me either. Less to document and code and such... Else, some generic mechanism to simply forward all compiler switches would be great I guess. Maybe forward everything after the last specified KSY?

puts "Usage: #{File.basename($PROGRAM_NAME)} <file_to_parse.bin> <format.ksy>..."

@GreyCat
Copy link
Member

GreyCat commented Apr 2, 2017

Ok, I'm slow again, but this is what I've came up with:

Usage: ksv [options] <file_to_parse.bin> <format.ksy>...

    -I, --import-path [DIRECTORIES]  .ksy library search path(s) for imports (see also KSPATH env variable)
        --opaque-types [BOOLEAN]     opaque types allowed, default: false
        --version                    show versions of ksv and ksc

So, ksv --opaque-types=true foo.bin foo.ksy should work now, these two options would be passed to ksc verbatim. Probably I'll add something like -r or --require to allow loading of arbitrary Ruby source files into program space, so one can actually use some custom Ruby code for these opaque types.

Also, take a look at kaitai-io/kaitai_struct#143 — this could potentially enable to use Ruby visualizer + Java engine (to allow execution of Java opaque types code).

@ams-tschoening
Copy link
Contributor Author

Ok, I'm slow again[...]

Don't worry, I appreciate everything you do and had a workaround, so wasn't stuck. Everything's fine. :-) I tried your changes and they work, so am closing this.

Probably I'll add something like -r or --require to allow loading of arbitrary Ruby source files into program space, so one can actually use some custom Ruby code for these opaque types.

Is it really necessary to implement that in ksv, while it's already available in the Ruby binary itself? I have the following command line for example, which uses -r to load an opaque implementation. Wouldn't it be enough to document that?

/C start "${env_var:ComSpec}" /K """${env_var:ProgramFiles(x86)}\Ruby23\bin\ruby.exe" "-I${env_var:ProgramFiles(x86)}\kaitai_struct\runtime\ruby\lib" "-r../parser/record/fmt_oms_rec_pre_proc.rb" "${env_var:ProgramFiles(x86)}\kaitai_struct\visualizer\bin\ksv" "--opaque-types=true" "${workspace_loc}/../../Svn/Bin/Giftschrank/Smart-Metering/data.bin" "record/fmt_clt_recs.ksy"""

@GreyCat
Copy link
Member

GreyCat commented Apr 3, 2017

Wouldn't it be enough to document that?

In *nix systems, ksv is usually invoked simply with ksv, without ruby, manual addition of -I, etc. Some people might have no clue that it's written in Ruby (although for this specific option, I guess they know what they do ;)), so I guess it's better to add it anyway.

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

No branches or pull requests

2 participants