{"action":"created","issue":{"url":"https://api.github.com/repos/kaitai-io/kaitai_struct_compiler/issues/31","repository_url":"https://api.github.com/repos/kaitai-io/kaitai_struct_compiler","labels_url":"https://api.github.com/repos/kaitai-io/kaitai_struct_compiler/issues/31/labels{/name}","comments_url":"https://api.github.com/repos/kaitai-io/kaitai_struct_compiler/issues/31/comments","events_url":"https://api.github.com/repos/kaitai-io/kaitai_struct_compiler/issues/31/events","html_url":"https://github.com/kaitai-io/kaitai_struct_compiler/issues/31","id":191043303,"number":31,"title":"Exception in thread \"main\" java.lang.RuntimeException: Unable to access config_field in List(fmts_header) context","user":{"login":"tschoening","id":6223655,"avatar_url":"https://avatars.githubusercontent.com/u/6223655?v=3","gravatar_id":"","url":"https://api.github.com/users/tschoening","html_url":"https://github.com/tschoening","followers_url":"https://api.github.com/users/tschoening/followers","following_url":"https://api.github.com/users/tschoening/following{/other_user}","gists_url":"https://api.github.com/users/tschoening/gists{/gist_id}","starred_url":"https://api.github.com/users/tschoening/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tschoening/subscriptions","organizations_url":"https://api.github.com/users/tschoening/orgs","repos_url":"https://api.github.com/users/tschoening/repos","events_url":"https://api.github.com/users/tschoening/events{/privacy}","received_events_url":"https://api.github.com/users/tschoening/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-11-22T15:47:21Z","updated_at":"2016-11-22T18:19:20Z","closed_at":null,"body":"I have three KSY files each containing some types and representing some kind of container data: Datagram is all the data and contains a header, which contains a config_field. Each of those has one KSY file. The datagram of course is not only a header, but has a payload as well, the length of the payload depends on the config_field in the header. So what I ultimately trying to achieve is accessing the header.config_field in the datagram to know how many bytes I need to read for the payload.\r\n\r\nFor test purposes I simply hard coded the length of the payload, the generation of Java classes work this way and I can see that the class structure and their visibility should be able to provide what I need. There is a public getter for the header, which has a public getter for the config_field etc.\r\n\r\nSo, is my approach wrong and can't work for some reason or is this  bug?\r\n\r\nDatagram:\r\n\r\n    meta:\r\n      id:      fmts_datagram\r\n      endian:  le\r\n    \r\n    seq:\r\n      - id:   header\r\n        type: fmts_header\r\n      - id:   enc_payload\r\n        size: header.config_field.aes_byte_cnt # TODO recognize missing MEH C-Field\r\n        #if:   header.config_field.aes_byte_cnt > 0\r\n    #  - id:    dec_payload\r\n    #    size:  header.length - 14 # TODO recognize missing MEH C-Field\r\n    #    if:    header.config_field.aes_byte_cnt == 0\r\n\r\nHeader:\r\n\r\n    meta:\r\n      id:      fmts_header\r\n      endian:  le\r\n    \r\n    seq:\r\n      - id:   length\r\n        type: u1\r\n        doc:  Length of datagram without CRC bytes.\r\n    [...]\r\n      - id:   config_field\r\n        type: fmts_config_field\r\n    \r\n    instances:\r\n    [...]\r\n\r\n\r\nConfigField:\r\n\r\n    meta:\r\n      id:      fmts_config_field\r\n      endian:  le\r\n    \r\n    seq:\r\n      - id:   lsb\r\n        type: u1\r\n      - id:   msb\r\n        type: u1\r\n    \r\n    instances:\r\n      enc_mode:\r\n        value: msb & 0x0F\r\n      aes_blk_cnt:\r\n        value: lsb >> 4\r\n      aes_byte_cnt:\r\n        value: aes_blk_cnt * 16\r\n"},"comment":{"url":"https://api.github.com/repos/kaitai-io/kaitai_struct_compiler/issues/comments/262321482","html_url":"https://github.com/kaitai-io/kaitai_struct_compiler/issues/31#issuecomment-262321482","issue_url":"https://api.github.com/repos/kaitai-io/kaitai_struct_compiler/issues/31","id":262321482,"user":{"login":"GreyCat","id":157154,"avatar_url":"https://avatars.githubusercontent.com/u/157154?v=3","gravatar_id":"","url":"https://api.github.com/users/GreyCat","html_url":"https://github.com/GreyCat","followers_url":"https://api.github.com/users/GreyCat/followers","following_url":"https://api.github.com/users/GreyCat/following{/other_user}","gists_url":"https://api.github.com/users/GreyCat/gists{/gist_id}","starred_url":"https://api.github.com/users/GreyCat/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GreyCat/subscriptions","organizations_url":"https://api.github.com/users/GreyCat/orgs","repos_url":"https://api.github.com/users/GreyCat/repos","events_url":"https://api.github.com/users/GreyCat/events{/privacy}","received_events_url":"https://api.github.com/users/GreyCat/received_events","type":"User","site_admin":false},"created_at":"2016-11-22T18:19:20Z","updated_at":"2016-11-22T18:19:20Z","body":"Yeah, as I said, right now all files are compiled effectively separately. That means that you can, for example, ask to compile \"Datagram\" without having all the other .ksys on the command line or in the same directory, or whatever - and the result will be exactly the same as compiling it together with\r\n\r\n```\r\nksc -t java fmts_datagram.ksy fmts_header.ksy fmts_config_field.ksy\r\n```\r\n\r\nThat means that accessing `header.config_field` is impossible: for a compiler, `header` is just some unknown, opaque type. During compilation of `fmts_datagram.ksy`, compiler doesn't have any information about internals of `header`, which fields it contains, which types are they, etc, etc. - and it needs that information to evaluation of the expression in `size` properly.\r\n\r\nSo, to summarize: it is impossible right now. Referencing types in other files works in simple, \"opaque\" cases - i.e. when you just ask for them to be instanced, or reference them whole. You can't access object's internals - i.e. `seq` attributes, `instances` attributes, `enums`, etc.\r\n\r\nI can offer several solutions:\r\n\r\n1. Simplest one - obviously, put everything in one file manually. To some extent, that is per design - i.e. stacking network protocols works that way exactly because there should be no inter\r\n2. Simple one - add an extra step to your build system that will concatenate all your protocol ksy files into one automatically during the build. Here's a short Ruby script that does that, for example:\r\n\r\n```ruby\r\nrequire 'yaml'\r\ndoc = YAML.load(File.read(ARGV.shift))\r\nARGV.each { |fn|\r\n  doc2 = YAML.load(File.read(fn))\r\n  doc['types'][doc2['meta']['id']] = doc2\r\n  doc2['meta'].delete('id')\r\n}\r\nputs doc.to_yaml\r\n```\r\n\r\n3. Long one - discuss implementation of more-than-one file compilation with us and wait for it to be implemented."}}
{"actor":{"display_login":"GreyCat"}}