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
Change NID db format #83
Comments
We should also have some sort of indicator for the new version. Maybe a tag
at the start? But then it won't comply with JSON standard(s). It's kinda messy to add a new field/object though. |
About 2):
|
JSON doesn't support comments, so a tag |
@devnoname120 parse hex also easy in python, but json not support hexdeciaml. |
I'm testing hex right now |
i mean json spec. they not support hex number. if can work, probably it's non standard lib extension. |
Confirmed working with hex values. should I change format? |
We need to decide whether we want to switch to YAML or not. Here is how it would look: https://gist.github.com/devnoname120/ff2a08dbcfa0126d9099ce894f7fe783 |
I think json with hex values is the best solution:
If you like the idea I can make a pull request with latest db.json in new format |
yeah.. i'm ok at this time. but i want to change other format, too. |
I'm happy to go with hex strings if we enforce that strings must be 10 characters long, beginning with "0x", followed by eight hexadecimal characters where all alphabet characters are capitalised. Additionally, we should have a simple validator script to automatically verify this repo's json db. |
I agree with Davee. The validator script should be very easy to do in Python. |
i didn't like |
If we're changing the JSON format, can we use something which is easily parseable in all languages, i.e. something which doesn't require the JSON parser to use objects as arrays and have a custom object for each item in the array.
I like the look of YAML though. |
I like that json version better El lun., 21 nov. 2016 a las 9:29, Josh de Kock (notifications@github.com)
|
@enoposix I think that @yifanlu wanted to use |
@yifanlu sure, well you could just add a |
@enoposix The format has already been discussed. Most of us prefer YAML for its cleanness, but it's harder to parse because it has complicated features that we don't need (e.g. references, data-type casting, etc.). Since this file is more meant to be read by a program, JSON seemed fine. |
@devnoname120 right, sure. I guess that makes sense. Why not go all out and allow multiple firmwares in one DB then?
|
FORMAT ULTIMATUM :) Latest discuted in matrix
You have 24 hours to review it :) |
I know order is not supposed to matter, but I would be in favor of this:
Changes:
|
can we ignore empty |
These last two formats are ugly af. They're using data as keys. |
@enoposix we have agreed to use that instead of arrays @d3m3vilurr yes |
@frangarcj why? there's literally no reason not to use a more parseable format, a user isn't going to be using this. And 'we' have not agreed. |
It is a long irc log but the use of eg. libraries['SceAudioIn'] was proposed for easy searchs. You have a key - value map vs array. @enoposix What's your opinion or problems? Sorry for the 'we' thing |
@frangarcj I didn't see the benefit of using objects over arrays, but the idea of using it as an object map makes sense, I see where you're coming from now. Acked.
|
I saw a opinion about object of array in the IRC, and remembered it only have little benefits.
but currently we not support unnamed functions in this project and channel subject changed dynamic loader instead NIDs. so actually we didn't decided about this.
format |
Ok I was away for a week so didn't get the chance to submit my opinion but here it is: Go with yaml, remove json support and json library from vita-toolchain.
This is dumb and hard to parse.
I don't see any point of doing any kind of validation. We don't have that many changes to json and if something is broken we'll see it on the build bot anyway.
We aren't writing our own parser so what's the problem? We aren't even using these advanced features. And we already have a yaml parser for exports written so using it for db.json makes sense. Parsing yaml in C is a shitfest but most people will use some scripting language, like Python, and there it's just one function call: http://pyyaml.org/wiki/PyYAMLDocumentation It seems that right now the only person who wants to go with json db w/ hex encoded strings is @devnoname120 and everybody else wants yaml or just does not care, so maybe you can explain his position in more detail? |
Depend on how strict you want your parser to be.
I'm just giving a solution, I'm not the one who proposed ;-) |
There was some discussion on IRC and @xyzz said that YAML is cleaner and we have a working parser for the export.yml files, so we should settle for it. Here is a proposal for the layout of the imports and exports files. (The DB is an imports file.) |
I'm currently converting vita imports to yaml |
Changed to yaml. Please check actual yml file |
@frangarcj It seems good to me. There is only the |
ForDriver
toForKernel
The text was updated successfully, but these errors were encountered: