What about privacy? Maybe not everyone wants to share his information with every far relative that you might never have met or twenty years ago when your grandmother died and you already have become a grandparent as well.
I find this a bit disappointing. Why not publish it with the preprint. Now we have no way to establish the quality of the two solutions or whether it is even possible to improve one of the solutions. I wonder why the C variant could not implement a JSON parser without malloc and free, while the RUST variant could.
Really strange the the C JSON parser has to use malloc where the RUST version does not. As if it is not possible to write a JSON parser in C that does use malloc. I presume that the syntax of the commands that the device will accept is known, and than there is no reason why you have to build a DOM of the JSON before you can process it. Apparently, the RUST version can do it. I really begin to question the abilities of two teams if the one team failed to implement a JSON parser solution without using memory allocations.
Part of the C protocol implementation is generated, and that generator chose the JSON parser. As it worked and there was plenty of memory left on the MCU, it was kept.
We're mentioning this in the paper: "The heap is entirely attributable to Parson's dynamic
allocation of JSON tree nodes; as memory usage
minimization was not a key goal, we kept Parson (the JSON
parser used by the PNPL code generator by default), noting
that there are less memory heavy options that do not require
a heap at all."
Wasn't memory one of the key indicators looked at?
> The analysis and measurements on hardware indicate no strong reason to prefer C over Rust for microcontroller firmware on the basis of memory footprint or execution speed.
I admit I have not carefully read the paper, and am collating info from comments here, so I may be fully mistaken. The word "strong" also allows for much interpretation, that I'm not a priori critical of, but am skeptical of.
Yeah, you can comfortably work with JSON in C directly on top of the string buffer containing it. Your representation for any JSON entity will just be const char pointer. It's possible to implement JSON path on top of this, and all kinds of niceties, and it's not slow.
Yes you can pin it to core 1 whilst pinning all other tasks to core 0. Then will never be interrupted or preempted (except by interrupts created on core 1)
I developed a similar language as an intermediate language for a C-compiler that I wrote. It uses reverse Polish notation instead of Polish notation [1], because it is easier to compile reverse Polish notation to machine code. I call the language Stack-C. See [2]. There are 32 bit and 64 bit compilers for x86 assembly and there is a memory safe interpreter for the language with a (rather limited) built-in debugger.
How to correct errors? I found some museum with the name that matches a city (but not exactly) to be placed in that city while it is in a city at the other side of the country. I guess some AI has been used.
Also some markers refer to areas and they are just placed at the center of that area. The marker for a country just placed in some random field.
I guess it's based on Wikidata's "coordinate location" property. You can find the Wikidata item corresponding to a Wikipedia article using the "Tools" dropdown in the desktop view. (Or just search on Wikidata directly.)
The data comes from Wikidata's P625 coordinate location property. It has to be corrected on Wikidata itself. Could you share some examples for where you think the data is incorrect?
reply