|Anonymous | Login | Signup for a new account||2019-01-20 04:30 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000470||Tunix||Build System||public||2011-12-07 14:06||2011-12-08 16:10|
|Target Version||Future||Fixed in Version|
|Summary||0000470: Consider some changes to the datamap.in format|
|Description||Currently each datamap section has a  square bracket delimited label and then a bunch of keys. The way it currently works is to read the key called keys (which must be first?) then read the keys listed in keys up to the next square bracketed delimiter. This has some problems from a maintenance perspective:|
If you add a key you have to add it to the keys list
If you remove a key you have to remove it from the keys list
Any change must be made in two places doubling the chance for human error in changing these and doubling the dev effort required to change these.
The code does extra work to parse the list of keys and then check each against that list as it reads?
It would be much better if instead of a list of keys, there were just the keys. A quick grep shows that this would reduce the size of the MTX config base by nearly 8000 lines. The change to remove the keys lines from the config could be easily automated once the code change to remove the requirement and dependency on that line was removed. If it was removed in a way where its presence didn't interfere with the operation of the app, they could be left in place and removed as come across in future.
Additionally, there are other similar format/processing issues in other places, such as:
Realtime datamap requiring a count of entries and specific naming instead of logical naming and use however many there are.
New XML colour text statuses specify everything in every case, better to have defaults for most and specify only what varies from the default.
Possibly other things.
I'll say here also that MTX is generally pretty good modularity wise and flexibility wise, which is why these stand out as obvious exceptions. Good work Dave!
|Tags||No tags attached.|
This would require probing for EVERY posible key name which is:
1. S L O W
2. Requires maint of a key list
The current design lets mtx get a key list and then knows what keys to query. You have no idea of the possible key combinations and and dependencies. Your way would introduce a lot of new bugs for the only gain of slightly smaller files...
Why can't it be parsed in the format of a list and just read out as written in? Why pull it into a map and then reference it by key? The point is that they key list could be generated by whatever parses it "get all keys" then just use them.
2. Less ugly
Just think about it... no need to do back flips. Maybe it'll sink in and you'll come up with an even better solution later...
|For the record, this is about maintenance and human error and bugs, not cleanliness. The reason that the lambda table went all crazy this morning was a lack of keys in the keys list compared to what i specified of actual key value pairs. It's non-obvious and somewhat fragile, that's all. Hence this is a consider and scheduled for "future" :-p Just think about it, AKA, consider it.|
This is a STRUCTURED FILE, parsed with a very specific set of routines, its not something that is just read and sequentially parsed, like a datalog. The sections are referred to in arbritrary order during GLADE file processing, basically the whole point of the datamap files is to BIND additional data to controls/widgets that glade doesn't allow you to do. By removing ONE line from each section (keys=<keyname>,<keyname> ) it would force the ENTIRE LIST of possible keytypes to be requested for each and every section (massively inefficient), and also break many things due to the fact that some keys IMPLY other key's presence indirect (complex_expr, for instance)
There is ZERO VALUE WHATSOEVER to break the longstanding file format. If you had ASKED about how to modify/write a datamap.in it would have been a 2 minute interaction that saved you time, but you didn't take the initiative to do so and suffered because of it.
The fact that they exist in certain files implies certain keys will be present too... that's a non-argument. If you find an entry that has children, and you reach the end of the section without having found them, spit out an error/warning and carryon/fail, whatever is appropriate. Likewise for a section that needs certain keys because of what it is.
I understand that it won't necessarily be straight forward. I understand that it will take time. But you should understand that it's currently ugly. In each section, the list of keys that are in the section is present in two forms, horizontal and vertical. You can read that same list in either way, one has maintenance issues, the other is more clean.
I have known that you need to add keys having been tripped up by it before, but it's easy to forget as it's so unnatural to be forced to dual specify. It would make more sense to have a key list on one line and then value per line associated with the keys, however that would be fragile due to ordering.
PS, I've studied lexical and grammar parsing at university, no need to educate me on what it takes to interpret a file into a data structure. You could spend your time/energy instead describing how it works in detail such that we could move forward with improvements, or instead just ignore the issue quietly and save me significant time. Either is fine.
|Assigned to me, reported by me, none of your business anymore, leave it alone.|
|Copyright © 2000 - 2011 MantisBT Group|