Comments (37)
I know order is not supposed to matter, but I would be in favor of this:
{
"layout-version" : "2",
"firmware": "3.61",
"modules" :
{
"SceAudioIn": {
"nid": "0x0000000A",
"libraries": {
"SceAudioIn": {
"nid": "0xF8DC61A3",
"kernel": false,
"variables": {},
"functions": {
"sceAudioInGetAdopt": "0x566AC433",
"sceAudioInGetStatus": "0x2F940377",
"sceAudioInInput": "0x638ADD2D",
"sceAudioInOpenPort": "0x39B50DC1",
"sceAudioInReleasePort": "0x3A61B8C4"
}
}
}
}
}
}
Changes:
- Moved nid, kernel, and variables.
- Enforced 0xXXXXXXXX for all NIDs.
- Renamed version to layout-version to emphasis that this is not the revision of the db itself, but the revision of the layout of the db.
from vita-headers.
Easy indeed, we simply need to define it schema, then use it to validate.
from vita-headers.
@yifanlu sure, well you could just add a "firmware"
field below version easily. I still think the YAML is a better idea--if we are going to be doing a fairly drastic change anyway, the YAML is a lot cleaner. It can be generated extremely easy without the use of a library (just one of the many benefits).
from vita-headers.
FORMAT ULTIMATUM :)
Latest discuted in matrix
{
"version" : "2",
"firmware": "3.61",
"modules" :
{
"SceAudioIn": {
"nid": "0xA",
"libraries": {
"SceAudioIn": {
"functions": {
"sceAudioInGetAdopt": "0x566AC433",
"sceAudioInGetStatus": "0x2F940377",
"sceAudioInInput": "0x638ADD2D",
"sceAudioInOpenPort": "0x39B50DC1",
"sceAudioInReleasePort": "0x3A61B8C4"
},
"kernel": false,
"nid": "0xF8DC61A3",
"variables": {}
}
}
}
}
}
You have 24 hours to review it :)
from vita-headers.
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
from vita-headers.
@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.
"layout-version"
can just be shortened to "version"
, there shouldn't be any ambiguity as firmware is there too.
from vita-headers.
We should also have some sort of indicator for the new version. Maybe a tag
// version: 2
at the start? But then it won't comply with JSON standard(s). It's kinda messy to add a new field/object though.
from vita-headers.
About 2):
- Advantages of hexadecimal:
- Consistent with the PSP NIDs.
- Some NID lists on the Internet are in hexadecimal, so Sony probably uses it too.
0xFFFFFFFF
is a more obvious maximum value than4294967295
.
- Advantages of decimal:
- Easier parsing and comparing, especially in Python
- Stay consistent with the previous version
from vita-headers.
We should also have some sort of indicator for the new version. Maybe a tag
// version: 2
at the start?
JSON doesn't support comments, so a tag version: 2
at the root of the JSON would work better. It would also allow to programmatically find the version.
from vita-headers.
@devnoname120 parse hex also easy in python, but json not support hexdeciaml.
from vita-headers.
I'm testing hex right now
I agree with version: 2
from vita-headers.
i mean json spec. they not support hex number. if can work, probably it's non standard lib extension.
from vita-headers.
https://gist.github.com/frangarcj/a1515d799b4db9216ae074458dd0e2a6
from vita-headers.
Confirmed working with hex values. should I change format?
from vita-headers.
We need to decide whether we want to switch to YAML or not.
An advantage of YAML is that it natively supports hex values. I'm not sure how well YAML libraries handle it though.
Here is how it would look: https://gist.github.com/devnoname120/ff2a08dbcfa0126d9099ce894f7fe783
It seems more readable to me.
from vita-headers.
I think json with hex values is the best solution:
- It's already developed
- You can easily export fron json to other formats if needed (eg. using nodejs)
If you like the idea I can make a pull request with latest db.json in new format
Changes in vita-import-load are already done
from vita-headers.
yeah.. i'm ok at this time.
but i want to change other format, too.
hex string method looks tricky.
from vita-headers.
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.
from vita-headers.
I agree with Davee.
The validator script should be very easy to do in Python.
from vita-headers.
i didn't like json schema
(it look too ugly format. IMO). probably, json schema
can check formatting using regex.
but in this case, also we can write plain python script using just json
module.
that module is already standard library, so not need extra dependencies for validation.
just need dict iterations..
(yeah it can make validation script to be little mess, it just pros & cons)
from vita-headers.
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.
{ "version" : "3.61",
"modules" : [
{
"name" : "SceDeci4p",
"nid" : "0x27",
"libraries" : [
{
"name" : "SceDeci4pUserp",
"nid" : "0x797E39C0",
"kernel" : false,
"functions" : [
{ "name" : "sceKernelDeci4pClose", "nid" : "0x63B0C50F" },
{ "name" : "sceKernelDeci4pDisableWatchpoint", "nid" : "0x5A4CDF97" },
{ "name" : "sceKernelDeci4pEnableWatchpoint", "nid" : "0x3BC66BD8" },
{ "name" : "sceKernelDeci4pIsProcessAttached", "nid" : "0xC4E1D86D" },
{ "name" : "sceKernelDeci4pOpen", "nid" : "0x28578FE8" },
{ "name" : "sceKernelDeci4pRead", "nid" : "0x971E1C66" },
{ "name" : "sceKernelDeci4pRegisterCallback", "nid" : "0x73371F35" },
{ "name" : "sceKernelDeci4pWrite", "nid" : "0xCDA3AAAC" },
],
"variables": []
}
]
},
]
}
I like the look of YAML though.
from vita-headers.
I like that json version better
El lun., 21 nov. 2016 a las 9:29, Josh de Kock ([email protected])
escribió:
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.{ "version" : "3.61",
"modules" : [
{
"name" : "SceDeci4p",
"nid" : "0x27",
"libraries" : [
{
"name" : "SceDeci4pUserp",
"nid" : "0x797E39C0",
"kernel" : false,
"functions" : [
{ "name" : "sceKernelDeci4pClose", "nid" : "0x63B0C50F" },
{ "name" : "sceKernelDeci4pDisableWatchpoint", "nid" : "0x5A4CDF97" },
{ "name" : "sceKernelDeci4pEnableWatchpoint", "nid" : "0x3BC66BD8" },
{ "name" : "sceKernelDeci4pIsProcessAttached", "nid" : "0xC4E1D86D" },
{ "name" : "sceKernelDeci4pOpen", "nid" : "0x28578FE8" },
{ "name" : "sceKernelDeci4pRead", "nid" : "0x971E1C66" },
{ "name" : "sceKernelDeci4pRegisterCallback", "nid" : "0x73371F35" },
{ "name" : "sceKernelDeci4pWrite", "nid" : "0xCDA3AAAC" },
],
"variables": []
}
]
},
]
}I like the look of YAML though.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#83 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYaFnPWEzi_7aL3Sf4jOvIuG5-WxCLhks5rAVZWgaJpZM4KwFST
.
from vita-headers.
@enoposix I think that @yifanlu wanted to use version
for the DB specification version. Should we also have a field for the firmware version?
from vita-headers.
@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.
from vita-headers.
@devnoname120 right, sure. I guess that makes sense.
Why not go all out and allow multiple firmwares in one DB then?
{
"version" : 2,
"firmwares" : [
{
"firmware": "3.61",
"modules" : [
{
"name" : "SceDeci4p",
"nid" : "0x27",
"libraries" : [
{
"name" : "SceDeci4pUserp",
"nid" : "0x797E39C0",
"kernel" : false,
"functions" : [
{ "name" : "sceKernelDeci4pClose", "nid" : "0x63B0C50F" },
{ "name" : "sceKernelDeci4pDisableWatchpoint", "nid" : "0x5A4CDF97" },
{ "name" : "sceKernelDeci4pEnableWatchpoint", "nid" : "0x3BC66BD8" },
{ "name" : "sceKernelDeci4pIsProcessAttached", "nid" : "0xC4E1D86D" },
{ "name" : "sceKernelDeci4pOpen", "nid" : "0x28578FE8" },
{ "name" : "sceKernelDeci4pRead", "nid" : "0x971E1C66" },
{ "name" : "sceKernelDeci4pRegisterCallback", "nid" : "0x73371F35" },
{ "name" : "sceKernelDeci4pWrite", "nid" : "0xCDA3AAAC" },
],
"variables": []
}
]
},
]
},
],
}
from vita-headers.
can we ignore empty variables
field?
from vita-headers.
These last two formats are ugly af. They're using data as keys.
from vita-headers.
@enoposix we have agreed to use that instead of arrays
@d3m3vilurr yes
from vita-headers.
@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.
from vita-headers.
I saw a opinion about object of array in the IRC, and remembered it only have little benefits.
- make more semantic format design
- can support unnamed exports
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.
but I agreed, this issue holded 2 weeks & should make something. it probably better then just holding & no decision.
03:33:49 D<davee[m]> most of the complaints are implementation
03:34:01 D<davee[m]> i find that a good set of work towards a decision talks more
03:34:19 F<frangarcj> I'll make the implementation
format version
(or layout-version
, and I like just using version
) can help this decision.
from vita-headers.
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.
Use hex strings (all caps preferred) instead of decimal numbers
This is dumb and hard to parse.
Easy indeed, we simply need to define it schema, then use it to validate.
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.
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.
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?
from vita-headers.
Parsing yaml in C is a shitfest
Depend on how strict you want your parser to be.
For example this yaml (converted from psplibdoc.xml long time ago):
https://github.com/yne/prxtool/blob/master/res/psplibdoc.yml
can be parsed using only ~40 line of pure C (who want a yaml dependency anyway):
https://github.com/yne/prxtool/blob/master/db_nids.c#L104
I don't see any point of doing any kind of validation
I'm just giving a solution, I'm not the one who proposed ;-)
from vita-headers.
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.)
Imports: https://gist.github.com/devnoname120/7f32f510949561a962f0e6b10e88aefd
Exports: https://gist.github.com/devnoname120/da986fa40f9f1c9b0d131c6280684b8b
from vita-headers.
I'm currently converting vita imports to yaml
from vita-headers.
from vita-headers.
Changed to yaml. Please check actual yml file
from vita-headers.
@frangarcj It seems good to me. There is only the ForDriver
--> ForKernel
renaming left to do, and maybe the ForKernel
--> ksce
.
from vita-headers.
Related Issues (20)
- Need to separate headers for each library HOT 7
- SceAppMgr HOT 6
- Some function arguments are wrong
- _vshSblAimgrGetConsoleId doesn't appear in the search HOT 11
- Functions with the same nid exist HOT 7
- socket sceNetSend looks not working properly HOT 4
- Libraries of the module SceDriverUser are in wrong modules HOT 2
- definition_check couldn't check c++ mangled methods
- split the db.yml to muliple files
- Merge vdsuite NID database to the vitasdk HOT 9
- Possible error in sceAppMgrLaunchAppByUri HOT 6
- PS Vita Dev Wiki link on homepage dead HOT 3
- Add a function to open quick menu without triggering the button HOT 5
- build.py makes bunch of empty folders without db.yml
- [Question] Setting up an arbitrary virtual address space HOT 7
- [Question] Calling function from loaded module HOT 9
- No `sceGxtGetDataAddress` nids?
- Compatibility with projects that have their own prototype definitions such as taihen or something
- sceAvPlayerInit return negative value (0x81300020) HOT 9
- Stubname field added to YML databases without any documentation HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vita-headers.