Closed Josverl closed 5 years ago
@BradenM ,
I have implemented the above change in the json format starting with version 1.2.0 i think that should improve the parsing as formally a json array is un-ordered so skipping the first 2 nodes was a bit of a hack.
Could you take a look at commit cb0779b and let me know if that works for you ?
/jos
Looks good to me. Definitely agree with getting rid of the array, and the firmware specs should be considerably more uniform and easier to parse now.
I am not and won't be home where I can test this out on some more devices/firmware for the rest of this week, but I will definitely give it a more detailed look when I get back.
NP, I’ll push it to main, and we can continue to adopt as needed.
enjoy the fireworks
/jos Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
From: Braden Mars notifications@github.com Sent: Tuesday, July 2, 2019 5:15:55 PM To: Josverl/micropython-stubber Cc: Jos Verlinde; Assign Subject: Re: [Josverl/micropython-stubber] module.json schema is too simplistic (#4)
Looks good to me. Definitely agree with getting rid of the array, and the firmware specs should be much easier to parse now.
I am not and won't be home where I can test this out on some more devices/firmware for the rest of this week, but I will definitely give it a more detailed look when I get back.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJosverl%2Fmicropython-stubber%2Fissues%2F4%3Femail_source%3Dnotifications%26email_token%3DAAHPVFXFRJFA42BICLF6QTLP5NWKXA5CNFSM4H4NM3I2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZBTUNQ%23issuecomment-507722294&data=02%7C01%7C%7C503e2350cb1e4e1b14cf08d6ff002e9a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636976773575766423&sdata=jFSQRmzAzzE9hlvOBdccQYdXccXqXqOt4rnwuNlWvkI%3D&reserved=0, or mute the threadhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAHPVFRNOZJWPYCSI57SBSDP5NWKXANCNFSM4H4NM3IQ&data=02%7C01%7C%7C503e2350cb1e4e1b14cf08d6ff002e9a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636976773575776422&sdata=FLDIBED7q2kKpHOTXz6h5M4zafmqpDgPAIqilCOAR%2Fw%3D&reserved=0.
@Josverl,
Was finally able to check this out properly. Definitely a lot more useful, but I am still struggling with the issue of being able to determine exactly what branch of micropython a device is using.
I am trying to avoid hard coding it, as according to awesome-micropython, there are over 2000 of 'em. So far I haven't been able to come up with anything better than cross-referencing the version number against the tags/ports from a list of micropython git repos (See this and its output). Not exactly a perfect approach.
For micropy-cli
, the benefit of knowing the exact firmware would make it pretty easy to determine which (firmware) frozen modules to retrieve and source in a project. I may just be over complicating this haha, but do you happen to have any ideas? Thanks.
@Josverl,
For now this schema works great, I have gone ahead and integrated it into micropy-cli
. I have pushed tackling firmware resolution to a later date, so when you have the time do you mind removing the stubber.modules
debug line and merging into master?
Thanks for your help!
I've merged the schema to main.
i agree that all the different firmware options make it hard to find the capabilities of the language , and of the included optional modules; especially as these modules also can/are sometimes changed for the specific firmware.
the module .json file uses a very simplistic format ( a single array of things) , making it hard to read and reason over it. A better format would be something such as :