Open rottened23 opened 4 years ago
Hi Jonathan. I like the changes to shmipc.c, allowing whatever library you are building to provide the parser, encoder and appender, plus some equivalent to K (e.g. Python has PyObject
, Java JNI has jobject
). It first seemed odd for OCaml bindings to use the mock_k.c
shims, but it makes sense. I wrote those just so that I could build some command line tools for demonstration and debug without needing the Kdb runtimes. Ideally unless building bindings for KDB your code would not need to use a K object. Let me properly review this and run your sample code myself and I'll try to get this merged.
Hi Chris thanks for taking the time to review the PR! The main reason for using the mock_k objects was as it seemed to help me leverage a lot of what was already there. On the OCaml end the API that is exposed is just "plain old c objects" (i.e. char*, int, etc.) so there isn't any real requirement for needing the KDB objects there. Let me know if you run into any issues with the PR!
Hi @rottened23 Do you have an example of the ocaml side of things, ie. a script and compiler args? I was looking for a simple reader/writer I could run to exercise this, then port over to the current interface.
Wanted to leverage this wonderful library to build an interface to help with bindings for OCaml. Right now this justs supports opening a CQ file and polling it and passing each message back to OCaml through a callback. In terms of the support for OCaml all that was really done was to expose the functionality through a plain c-style format rather having it wrapped in the Kdb C objects.
I don't use C that much and especially Makefiles... so a bit of trial and error here. Regarding the makefile definitely broke the *.so building and likely some other things. I wanted the makefile to produce a single libocamlshmipc.so which has all the linking done for a stand alone package to develop against for ocaml.
Sample polling OCaml usage once the libocamlshmipc.so is on the LD_LIBRARY_PATH.