Re: Euphoria JSON parser
- Posted by jimcbrown (admin) Oct 16, 2015
- 2764 views
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
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.
Does this work on Windoze though? Using -1 in place of open_dll("") works fine on nix because they all use the same dlsym() - which supports use of RTLD_DEFAULT and RTLD_NEXT in place of an dlopen handle. (See http://www.scs.stanford.edu/histar/src/pkg/uclibc/include/dlfcn.h and http://linux.die.net/man/3/dlsym for details on how this works.)
I can't find any documentation suggesting that GetProcAddress() on the stupid platform supports anything similar. I even looked through WINE sources ( http://source.winehq.org/source/dlls/ntdll/loader.c and http://source.winehq.org/source/dlls/kernel32/module.c ) but afaict WINE doesn't implement such behavior either.
Another reason this works is because on nix, both shared objects and executables are ELF objects, and you can dlopen() an executable with no problems. However, I've seen evidence that the stupid platform can't do this (e.g. http://stackoverflow.com/questions/19110747/loadlibrary-an-exe )
while the team resists.
Huh?
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 main reason we did it this way was for DOS support. Since DOS was dropped I've advocated for loading PCRE via a shared library instead of having it built in, but no one has put in the effort to actually separate it back out again.
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.
That's a really clever idea!
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?)
Probably. A big part of this was that the define_c() stuff didn't work on DOS. (At least not this way. You could use define_c_func() to call a machine code routine, but it'd be a heck of a lot harder to call a backend routine in DOS this way. At the very least, you'd need a way to look up the memory address of the routine yourself, as there's no linker (ala dlopen/LoadLibrary) that can do it for you in the DOS version of Euphoria.)
