Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactoring to support basic polling and OCaml bindings through Ctypes #7

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

rottened23
Copy link

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.

open Ctypes
open Foreign

let cb_t = uint64_t @-> string @-> uint64_t @-> returning void

let open_and_poll' = foreign "OCAMLshmipc_open_and_poll" (string @-> funptr cb_t @-> returning void)

let open_and_poll st cb = 
    let cb' addr str len = cb 
        (Unsigned.UInt64.to_int addr)
        str
        (Unsigned.UInt64.to_int len)
    in
    open_and_poll' st cb'

let () = 
    let dir = Array.get (Sys.get_argv ()) 1 in
    let cb index str len = 
        print_endline (Printf.sprintf "IN OCAML: index:%d len:%d data:%s " index len str
    in
    open_and_poll dir cb

@shuckc
Copy link
Contributor

shuckc commented Feb 23, 2020

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.

@rottened23
Copy link
Author

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!

@shuckc
Copy link
Contributor

shuckc commented Oct 24, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants