Ok, to replicate the bug, just go to
https://github.com/KennethAdamMiller/ocaml-makefile where I'm updating the fork of ocamlmakefile in order to allow a target to compile for ocamljava. Once I update (I've committed, but haven't pushed yet, will within a matter of hours hours), you can clone or pull, and cd to the threads subdirectory, which is an example project that consumes the ocamlmakefile. Then just do
make jbc #or make java-byte-code
ex1 and ex2 crashe with uncaught under/overflow exception and some other overflow errors (not reliable); I think it's because the synchronization that is expressed in the ocaml code isn't very well followed at java's level; there seems to be some very great imbalance in thread scheduling (possibly slow signal handling). In java, there's a long pause where the output doesn't make it to the screen until the uncaught exception hits, when it does, the numbers being passed have a huge difference. In contrast, ocamlopt or ocamlc compiled code executes rather evenly, with each event receiving scheduler attention pretty much equally. That's my jest.
Agreed! I'd much much rather construct some method of automatic (or even just expedient manual intervention!) that offers ocaml -> C sublibrary : java -> C sublibrary support! I've already started down the path of ocamljava, and right now, even ocaml-RPC with protocol buffers looks like a long haul as well! ocamljava is just a much better solution.
Precisely! ocaml-ctypes is exactly what's being used by the library that I'm porting to call into C sub libraries. It would be really sweet if the ocamljava compiler could detect the ocaml-ctypes and generate these mappings automatically. This would eliminate a lot of error prone code, since C code tends to interpret data raw at some point... How might I got about writing this to boot? I'm moderately new to ocaml, lacking deep expertise in it, but I'm an aggressive learner. Please explain the best path forward, I want to create a robust and reusable solution.