Martin Kersten a écrit :
Providing debian packages of libraries with debugging symbols would be great.
For that we provide the super-source tarball which contains all the sourcecode needed to undertake the actions you are embarking upon.
OK. I'll patch the Debian packages to do that. I already did something similar for Debian packages of R.
Should I assume that the mtime.mal + lib_mtime.so is the first one to be loaded? Just to know if some dynamic linking successfully happened before or not.
no. it is not the first one. For that you have to breakpoint on loadLibrary.
Thanks. Will do.
I think you really should involve an OCaml programmer with C experience to embark upon this track. And follow the suggested implementation steps, i.e. first linking in the mapilibrary. That is ultimately the interaction between OCaml and the server. Any entanglement at a lower level, e.g. the column store, calls for really strong C programming expertise. The estimate time for the former is a few weaks, the latter may easily take a year to do it properly.
Hmmm.. no. Reasons are: I want to do it myself. OCaml programmer with C experience willing to work on MonetDB are quite scarce. And I'm not necessarily the worst when it comes to OCaml/C/C++ interaction. For now, I have one priority: embedding MonetDB in OCaml bytecode. This is the bottleneck for what I want to do. I willing to postpone lower level stuff, but not the embedding.
Will do that. However, I believe it is not a problem of location, as this works out fine when the OCaml binding is compiled to native code.
Programming is like mathematics not based on belief, but finding proofs using the proper tools and analysis steps.
Yes. That's the learning curve I'm on, and I'm happy to do so. (But the act of doing mathematics is quite based on beliefs and intuitions, nonetheless...)
I have seen no proof that the MonetDB modules are properly loaded yet,
Indeed, there is yet no proof. Knowing the good tool to use to check that MonetDB modules are properly loaded, in the OCaml native code context, would be useful.
nor if you have set the environment paths correctly.
See the bottom of this email: http://markmail.org/message/rpv6ovrmsp3hsqi7
And then I ignore possible low level interferences (e.g.malloc) that might occur when linking two systems this way.
From the point of view of OCaml, there's no issue. There's an OCaml heap, on which OCaml does its own memory management and garbage collection. You can use malloc, allocating a pointer in the C heap, without interfering with the OCaml heap. When wrapping a pointer, you just have to make sure that you include a finaliser so that OCaml's garbage collector frees the mallocated space when the wrapping OCaml value goes out of scope. Nothing magic. Concerning threads, it's a bit more painful. But as long as you do not use the OCaml Thread library, you can do anything you want, including callbacks containing OCaml code. When you use the Thread library, you have to take care of OCaml's master lock when doing OCaml callbacks from C code. Nothing magic here either. Overall, OCaml is quite friendly to C code.
The action described sofar are really basic steps towards C programming and testing.
Yes. I reckon that C is not exactly my cup of tea. But if I've been able to embed the R interpreter into OCaml, with my load of segfaults and conflicting signal handling between OCaml and R, for instance, I believe I should be able to get something decent working at some point with this MonetDB binding. All the best, -- Guillaume Yziquel http://yziquel.homelinux.org/