by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 13:42
    GreyCat commented #229
  • 13:42
    GreyCat commented #229
  • 13:37
    GreyCat commented #750
  • 11:03
    GreyCat commented #291
  • 11:02

    GreyCat on master

    Support TXT, SRV and PTR records Merge pull request #291 from NN… (compare)

  • 11:02
    GreyCat closed #291
  • 10:35
    GreyCat commented #755
  • 00:18
    LmpOSX commented #734
  • May 28 09:12
    Mingun commented #90
  • May 28 07:40
    l0calh05t commented #90
  • May 28 07:35
    l0calh05t commented #90
  • May 28 07:33
    Mingun commented #90
  • May 28 07:21
    l0calh05t commented #90
  • May 28 07:20
    l0calh05t commented #90
  • May 28 07:15
    l0calh05t commented #90
  • May 27 22:32
    webbnh commented #90
  • May 27 21:53
    heinrich5991 commented #90
  • May 27 20:33
    l0calh05t commented #90
  • May 27 19:24

    generalmimon on master

    Remove REPL link as per https:… (compare)

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: