kaitai_struct/Lobby

Petr Pučil

@generalmimon

though it probably can be done, as this link mentions on page 14:

Custom exception objects
error({code=121})
What's wrong with strings?

selective catch is fragile at best

Tables as errors

positive error identity

can attach arbitrary context

Classes as errors

can employ inheritance testing

Mikhail Yakshin

@GreyCat

I would probably better stick to the simplest solution - i.e. making sure that contents work for Luas in the same way that it worked before - by using that error(...) - and that's it

Whoever wants to have better support for exceptions in Lua can come afterwards and contribute it, if they'll be up to it

Petr Pučil

@generalmimon

@GreyCat :+1:

Tim Kurvers

@timkurvers

the JavaScript compiler seems to flatten directory structures when dealing with imports, is that intentional?

Mikhail Yakshin

@GreyCat

Yes, there's no concept of directory structure there

Tim Kurvers

@timkurvers

I see, it assumes based on meta.id that files will live right next to eachother?

(or rather, it uses meta.id in relative require calls)

Mikhail Yakshin

@GreyCat

ksc output matches practices required by target language

e.g. for Java, there is no way you can put files into arbitrary directories

they have to exactly match package names

Tim Kurvers

@timkurvers

I see, that makes sense given the amount of different output languages supported. barring any changes in the compiler to customize these import paths, I suppose the best bet here would be a good old string replace in the compiled files? :smile:

Mikhail Yakshin

@GreyCat

@timkurvers Can you tell us more about your use case? E.g. what language you're targeting, why do you want a certain structure with generated files, etc?

Is there a way to represent this structure somehow in ksy so we can end up generating these for you?

Tim Kurvers

@timkurvers

@GreyCat I believe I (or potentially a co-author) may have discussed this before, but the structure we're testing Kaitai for is https://github.com/wowserhq/blizzardry/tree/master/src/lib/dbc, which is essentially a database format where each file (under entities) has its own record type. but the general structure of those database files are the same.

the general structure currently and also preferably when using Kaitai looks something like this:

/t/kaitai-test/dbc ∴ tree --dirsfirst
.
├── entities
│   ├── a.ksy
│   └── b.ksy
├── dbc.ksy
├── localized_string_ref.ksy
└── string_ref.ksy

1 directory, 5 files

either you open the file in a general form (dbc.ksy) in this case you get zero information about the records in it, but you can read the file

or you use a definition in entities, which in this case knows about the format for a.dbc as well as b.dbc (there's a gazillion of these files, over 80+ I believe)

Mikhail Yakshin

@GreyCat

Ok, so how do you want it to be presented in your target language?

Tim Kurvers

@timkurvers

.
├── entities
│   ├── a.js
│   └── b.js
├── dbc.js
├── localized_string_ref.js
└── string_ref.js

1 directory, 5 files

Mikhail Yakshin

@GreyCat

Ok, so it's JavaScript

Tim Kurvers

@timkurvers

correct :+1:

Mikhail Yakshin

@GreyCat

... and you basically do all loading of .js files manually,

i.e. there is some kind of central file which does a bunch of require(...) calls or something like that?

Tim Kurvers

@timkurvers

that's kind of out of scope, but yes, a consumer would require the files it needs

it's not a huge crisis if this folder would get flattened, but it'd be hard for consumers to find string_ref.js (and optimally, they would use one of the entity definitions)

with the current JavaScript compiler (if I haven't completely misunderstood how it currently functions) importing string_ref.ksy into a.ksy would produce output for a.js which assumes string_ref.jsis right next to it (require('./StringRef.js I believe)

Tim Kurvers

@timkurvers

have now managed to maintain the directory structure and rewrite require calls the compiler produces to correctly reflect that directory structure

have a question related to imported types though: am I correct in assuming (from the Scala source code) that imported types are never given a root when used?

if so, what would be the Kaitai way of having these imported types reference / point to data contained elsewhere in a file? passing them in as params?

dgelessus

@dgelessus

@timkurvers Correct - KS treats imported types as independent (unlike nested types from the same file), so the root is intentionally not passed on when you use an imported type. If you need information from the struct that uses the type, you should pass that information as parameters.
(You can also just pass the entire struct, but unless you need to access a lot of fields, IMO it's better to only pass the values that you really need. This will make your life easier if you ever need to use your imported type from a different struct than you originally wrote it for.)

Tim Kurvers

@timkurvers

@dgelessus thanks, I see! :+1:

I've tried to pass a custom type to this imported type, but I'm a bit unsure whether I can use custom types for a param's type:

params:
  - id: string_block
    type: string_block

is that supposed to be type: struct instead?

Mikhail Yakshin

@GreyCat

@timkurvers Normally, you should be able to use specific user types

dgelessus

@dgelessus

struct is also supported - the difference is that it stands for "generic Kaitai Struct struct object" rather than a struct of a specific type. I don't remember right now what the use case is for that though, considering that KS is (mostly) statically typed

Tim Kurvers

@timkurvers

if I use type: string_block for that param, I get the following when using the JavaScript compiler:

$c_s_MatchError {
  's$1': null,
  'e$1': null,
  'stackTrace$1': null,
  'objString$4': null,
  'obj$4': 'string_block',
  'bitmap$0$4': false,
  stackdata: [Circular]
}

I'm on 0.8.0 though, haven't tried anything more recent

dgelessus

@dgelessus

Can you try it with https://ide.kaitai.io/devel/ to check if it's fixed in the development 0.9 version?

James Elliott

@brunchboy

Might it be because your id and type are the same string?

Tim Kurvers

@timkurvers

using type: struct it compiles, but it requires casting when actually attempting to do anything with that param (which matches your description @dgelessus )

no dice @brunchboy, but I may be doing something wrong. will give it a shot in the Web IDE @dgelessus :+1:

Tim Kurvers

@timkurvers

seems to compile properly in the Web IDE, will try latest locally

Tim Kurvers

@timkurvers

does Kaitai have type inheritance? I just realized that would make these formats a lot easier to work with

@dgelessus got it to work though opting not to pass the struct but rather only the needed data as you recommended, thanks! :+1:

Mikhail Yakshin

@GreyCat

@timkurvers Kaitai Struct does not have type inheritance.

If you have an idea on how to implement it — please go ahead and start an issue with a proposal — that will be most welcome :)

Tim Kurvers

@timkurvers

@GreyCat I see, thanks! doubt I would be able to help much with implementation :sweat_smile:

Where communities thrive

People

Repo info

Activity

Custom exception objects