| Click here to select a new forum. |
| JSON parser lib for Mac OS? |
Posted by: cluster_fsck on 2025-08-09 18:33:47 Has anyone come across a JSON library for Mac OS or ported one? I've looked at the following:
cJSON - pretty lightweight and has hooks for custom memory management, so started playing around with having it use Handles for relocatable memory
Jansson - nice API and powerful, but could be a beast to get working inside of a classic Mac OS app
jsmn - minimal JSON parser (it's just a header file!) but haven't yet tried playing with it
I need to look around at other projects for embedded systems, but the above seem like the most popular C-based parsers I could find.
Thanks for any help! |
Posted by: Realitystorm on 2025-08-10 08:21:36 It depends what you want to do. At it's most basic all you need to use is JavaScript's "eval" function to convert a JSON text string containing data structures back in to objects and arrays.
var jsonString = '{"firstName":"John","lastName":"Smith"}';
var obj = eval('(' + jsonString + ')'); // Wrap in parentheses for object literal
console.log(obj.firstName); // Outputs: John |
Posted by: Realitystorm on 2025-08-10 09:14:51 I guess I should also mention the obvious, before someone else does, using eval this way isn't secure so only use it if you can ensure that the JSON text will only be provided by a trusted source. |
Posted by: Snial on 2025-08-10 09:39:49 SAX JSON Parsers can be well-suited to low-memory/embedded systems.
A SAX like JSON parser for embedded with partial parsing. - X-Ryl669/JSON
github.com
Because they're event-driven they should map quite well to Classic Mac OS. |
Posted by: cluster_fsck on 2025-08-10 09:53:35
It depends what you want to do. At it's most basic all you need to use is JavaScript's "eval" function to convert a JSON text string containing data structures back in to objects and arrays.
var jsonString = '{"firstName":"John","lastName":"Smith"}';
var obj = eval('(' + jsonString + ')'); // Wrap in parentheses for object literal
console.log(obj.firstName); // Outputs: John My use case is retrieving a JSON stream and likely writing it to disk, then breaking it up based on the topmost enclosing objects, then running those through a parser to pull out what I need and display to a user. I’m doing this all in C and embedding a JavaScript engine feels like a lot of overhead.
I've been looking at the small open source parsers to adapt to classic Mac OS memory model (moving from malloc-allocated ptrs to blocks of relocatable Handles to avoid memory fragmentation) and potentially wrapping the primitive types in Core Foundation objects (I’ll be using Carbon) to get safer string handling. |
Posted by: cluster_fsck on 2025-08-10 09:54:42
SAX JSON Parsers can be well-suited to low-memory/embedded systems.
A SAX like JSON parser for embedded with partial parsing. - X-Ryl669/JSON
github.com
Because they're event-driven they should map quite well to Classic Mac OS.
Cool, thank you! I’m still in therapy after early-career exposure to C++ Windows programming 😆 but will clone the repo and check it out. |
Posted by: twelvetone12 on 2025-08-10 10:07:45 I use cJSON on a couple embedded systems and it works ok. You can override the various allocation/deallocation functions. The only drawback is that it parses everything in one go so if you very limited resources and huge json files it can be a problem. |
Posted by: cluster_fsck on 2025-08-10 10:34:59
I use cJSON on a couple embedded systems and it works ok. You can override the various allocation/deallocation functions. The only drawback is that it parses everything in one go so if you very limited resources and huge json files it can be a problem. Thanks! I’m going to use a very conservative paging approach to grabbing the JSON-formatted content and need to do a bunch of testing to see what’s reasonable for memory consumption and how much heap I need to give my app. I’m not targeting low end Macs as a PowerPC Mac will be necessary. |
Posted by: jmacz on 2025-08-10 16:32:26 Depends on what you mean by “classic Mac OS”. If you intend to support System 7 for example, any solution that does not adequately give up control (due to cooperative multitasking) will “freeze” the system until parsing is complete, as @Snial alluded to. Small snippets might be fine but anything taking more than a second will result in a poor user experience. |
Posted by: cluster_fsck on 2025-08-10 17:00:49
Depends on what you mean by “classic Mac OS”. If you intend to support System 7 for example, any solution that does not adequately give up control (due to cooperative multitasking) will “freeze” the system until parsing is complete, as @Snial alluded to. Small snippets might be fine but anything taking more than a second will result in a poor user experience.
Yeah, this is where the MP APIs will come in handy. At a minimum, my plan was to move the parsing off to a thread and I may target Mac OS 9+, which means that preemptive threads will be available for this type of operation. I did some work using them a loooooong time ago, so may dive back in. At a minimum, I'll use Thread Manager to spin off processing into a separate thread, but was also going to take an opportunity to learn Carbon's CFRunLoops to see if that would be appropriate (although those likely just back into existing OS primitives and are still coorperative). |
Posted by: cheesestraws on 2025-08-11 00:13:05 How big are these JSON files, or whatever? The idea of using the MP APIs for parsing smallish text files seems like quite serious overkill. |
Posted by: Snial on 2025-08-11 03:16:35
Depends on what you mean by “classic Mac OS”. If you intend to support System 7 for example, any solution that does not adequately give up control (due to cooperative multitasking) will “freeze” the system until parsing is complete, as @Snial alluded to. Small snippets might be fine but anything taking more than a second will result in a poor user experience. (and @cluster_fsck ), @cheesestraws . The beauty of SAX parsers is that as well as being extremely CPU & memory resource-light, they're well-suited to giving up control, because they function as event-driven systems. The application-side handler gets called for each token, so it'll get called frequently and if a timeout check is added to the handler; it can call and process GetNextEvent (or WaitEvent) as appropriate. Or, it could be embedded in a Time-manager task for background processing for the same reason. |
Posted by: cluster_fsck on 2025-08-11 05:27:00
How big are these JSON files, or whatever? The idea of using the MP APIs for parsing smallish text files seems like quite serious overkill. Oh yeah, that would be a last resort. At the moment, the JSON will be streaming in so a SAX-style parser would likely work well so I can just pick off the key/value pairs that I want without reductive pre-processing. |
| 1 |