Original date:2015-10-16 17:12:32 Edited by: ghaberek Subject: Re: Euphoria JSON parser

SDPringle said...

You can link the C code with the rest into the "library" section, and then you use a Euphoria wrapper that you first can debug as an external dll while the team resists.

In the case of Regex, we didn't do this. Because of the way as Open Euphoria has integrated PCRE. Extra glue code in C via be_regex.c had to handle whether we pass a number implemented as an encoded pointer to a struct d or as a C integer. The code had to be written with great care to ensure people were not passing sequences where integers were expected. Initially, it did not do this.

Now, if you use the c_func/c_proc interface and compile the files into the library, you don't get external dependencies. And it is in the be_callc.c that makes sure your integers are converted into c integers when they need to and whether to error out. The EUPHORIA wrapper code has to be written correctly but it is less work in the end.

Right, for wrapping Mini-XML, I was thinking I could put all of the function addresses into a table and just peek them all from memory, get the pointer to that table with one machine_func() call, and then wrap the functions with define_c_func()/proc() as if I were wrapping a shared library. That would save me from having to burn through ~70 machine_func() constants in the backend. But, if I can just use define_c_func()/proc() to access backend functions directly, then I can just skip the machine_func() nonsense entirely. (And if that's true, why do we still have machine_func()? Just for legacy purposes?)

SDPringle said...

This approach eliminates a need for a be_json.c which would be needed if you pass everything through machine_func/machine_proc.

True, but JSMN is only two functions. It was easier to just expose them via machine_func() and be done with it. Most of the magic happens directly within json.e.


Not Categorized, Please Help


Quick Links

User menu

Not signed in.

Misc Menu