SQL> create view v1 as
select object_type, count(1) as howmany from user_objects group by object_type;

The histogram automatically scales to the width of the current window.

Also, I have been reading Jordan Mechner’s book The Making Of Prince Of Persia†. It’s both fascinating and inspiring. Just before that, I read The Future Was Here, the story of the Commodore Amiga‡. The book is made even more poignant by my Mac inexplicably showing the beach ball as I scroll through a simple web page, or the mighty RHEL servers at work being unable to keep up with my typing. The future is still back in the 80s.

† The original code is also on Github.

‡ I have an A500+ on my desk right now, the best of them IMHO. I might write a post comparing it with the Atari STE, and the BBC with the C64, in the cold light of day as an experienced adult. I have a fine collection of classic machines now, often acquired broken with the intention of repairing them myself. Another time-sink from OCaml work…

• Some .cmi for toplevel internals that used to be installed in`ocamlc -where` are now to be found in `ocamlc -where`/compiler-libs. Add “-I +compiler-libs” where needed.
• Warning 28 is now enabled by default.

The impact of these was that the toplevel prompt wasn’t working in the shell, and one non-fatal warning when compiling, so nothing that would have broken any code, but it’s good to be up-to-date. The necessary changes have been checked in on Github.

Speaking of which, bearing in mind the LinkedIn débàcle, I have a password generator too…

#include <cstdlib>

int main(int argc, char** argv) {
  int* ptr = NULL;
  *ptr = 1;

  exit(EXIT_SUCCESS);
}

Referencing that NULL pointer obviously crashes straight away with a terse segmentation fault:

By simply linking it with libSegFault, which seems to be documented only very informally, but comes with glibc:

Of course you could get all this by starting the program with gdb but this looks like a great technique for diagnosing crashes “in the wild”. Not that my code segfaults all the time, mind! After writing this, I found some more details on Stack Overflow, including a good tip about c++filt. Another useful utility is addr2line.

Also I am starting to incorporate libtap++, an implementation of the Test Anything Protocol, into my projects. C++ has strong typing, at least stronger than plain C, which helps trap errors at compile time like in OCaml. But since I always write a test harness anyway, it makes sense to fall into line with the way everyone else does it, especially as I have ambitions for wider adoption of my bindings†. Presently there is no TAP producer for OCaml‡, so at some point I will work on that too (or just bind to the C libtap).

On the recommendation of a friend of mine who is a very experienced C++ programmer, I have been playing with Eclipse CDT, which is pretty nice for C/C++ but doesn’t deal well at all with mixed C++/OCaml projects, and EclipseFP seems to have dropped support for OCaml at some point. I think I’ll try using it for just the .so portion of my projects and stick with Emacs/make for final integration with OCaml bindings, at least until I see if it really is more productive to do C++ in a full-blown IDE versus good old Emacs. Also I’ve bought a copy of The Boost C++ Libraries, again on the recommendation of my friend, that whatever I want, it’s probably already in Boost.

† OPERATION FOOTHOLD
‡ See comments

Of course, I do actually know that is all irrelevant; no-one springs forth a fully-formed programmer, you pay your dues slogging through learning and reference materials, gradually working your way up from writing Hello, world! via proofs-of-concept to real programs. Rome wasn’t built in a day! What I need to do is stop reading so much and just start coding something – this isn’t as dangerous as it sounds as I do have the foundations already in place for decent OO, and I’ve kept up with ideas like RAII and copy-and-swap, and smart pointers and the other goodies in Boost etc.

And I have been here before, about one year ago I started this blog as I set out to learn and use OCaml! I have been successful in that in as much as I can use it for “real work”, particularly since writing OCI*ML†, which required dusting off my C. This C++ diversion too is mainly in support of OPERATION FOOTHOLD, for working with Coherence, Qt, Agg and others, all of which make use of advanced C++ features.

† And I haven’t forgotten there is more work needed on that as well, for example LOBs.

1. High priority messages
2. Info messages
3. Messages which mention XYZ in their body

A “real” application might have a much more detailed message structure than just priority, subject and body, however the code will be very easy to modify to add new fields, etc. The important thing to understand is that the filters run within the Coherence grid itself; a subscriber only sees messages in which it has registered an interest, the routing and filtering is entirely offloaded from the client. Filters can be combined, for example with AndFilter, tho’ they are not quite as powerful as the WHERE construct in SQL (e.g. no joins). Coherence-based systems are known to scale to thousands of messages/sec with thousands of connected subscribers, and OCaml is an ideal language for CEP applications such as trading.

The nature of PubSub is that the publishers and subscribers are fully de-coupled; a publisher does not know if any subscriber is listening, nor does a subscriber know who has sent the message. If reliable delivery or a stronger relationship or is required, then a message bus such as Oracle AQ should be used (the tradeoff being lower throughput/higher latency). An analogy is UDP vs TCP. In all cases, so long as the data can be interchanged via a common format (database column types for AQ, POF for Coherence, Apache Thrift, etc), it does not matter what language any of the individual participants is written in. This is the fundamental principle of OPERATION FOOTHOLD.

The code for the subscriber is as follows.

open Cohml
open Callback
open Printf
open Log_message
open Unix

(* the message record struct *)
type message = {msg_id : int;  msg_priority : int; msg_subject : string; msg_body : string}

(* the query predicate for the message records we are interested in receiving 
   events for. Fields are 0-3 (see definition of message above), conditions are
   0: less than, 1: equal to, 2: greater than, 3: like, types are 0 for int, 1
   for string. Search term is a string and we'll atoi() it in C if we need to.
   Existing is if we want anything already in the cache before we begin.
*)
type field = | ID | PRIORITY | SUBJECT | BODY
type field_type = | INT | STRING
type condition = | LESS_THAN | EQUAL_TO | GREATER_THAN | LIKE 
type query = {field : field; field_type: field_type; condition : condition; search_term : string; existing: bool}

(* function to register message listener callbacks - insert, update, delete*)
external coh_msg_listen: coh_ptr -> query -> string -> string -> string -> unit = "caml_coh_addmessagelistener"

let string_of_message m = sprintf "id=%d, priority=%d, subject='%s', body='%s'" m.msg_id m.msg_priority m.msg_subject m.msg_body

(* callback functions *)
let _ = register "cbf_msg_insert" (fun k m -> 
  log_message (sprintf "New message: %s" (string_of_message m)))
let _ = register "cbf_msg_update" (fun k om nm ->
  log_message (sprintf "Message changed %s/%s" (string_of_message om) (string_of_message nm)))
let _ = register "cbf_msg_delete" (fun k ->
  log_message (sprintf "Message %d deleted" k))
  
let () =
  let st = (match Array.length Sys.argv with
    |1 -> 1 (* default to subscriber type 1 *)
    |_ -> int_of_string Sys.argv.(1) ) in
  let q = (match st with
    |1 -> { field=PRIORITY; field_type=INT; condition=LESS_THAN; search_term="2"; existing=false }
    |2 -> { field=SUBJECT; field_type=STRING; condition=EQUAL_TO; search_term="INFO"; existing=false }
    |_ -> { field=BODY; field_type=STRING; condition=LIKE; search_term="%XYZ%"; existing=false }) in
  log_message (sprintf "Subscriber starting as type %d" st);
  let c = coh_getcache "message_cache" in
  coh_msg_listen c q "cbf_msg_insert" "cbf_msg_update" "cbf_msg_delete";
  sleep 1000

It builds on the previous example, the new feature being the query struct which describes the type of message the subscriber is interested (all three of the example subscribers are in the same source file, selectable on the command line). This is clearly highly specific to the message record type and it’s C++ representation the Message class, however at least the subscription can be defined from OCaml code. To test it, I have written a simple load generator that composes random messages:

open Cohml
open Log_message

type message = {msg_id : int;  msg_priority : int; msg_subject : string; msg_body : string}
external coh_put_message: coh_ptr -> message -> unit = "caml_put_message"
let print_message m = log_message (Printf.sprintf "id=%d, priority=%d, subject='%s', body='%s'" m.msg_id m.msg_priority m.msg_subject m.msg_body) 

let p () = (Random.int 5) + 1 
let subjects = [|"INFO"; "WARN"; "FAIL"; "RECOVER"|] 
let s () = Random.int (Array.length subjects)
let bodies = [|"ABC"; "DEF"; "GHI"; "JKL"; "SOS"; "XYZ"|]
let b () = Random.int (Array.length bodies)
let pad = String.make 40 'Z' (* for Tibco-style 50-byte messages *) 

let () = 
  Random.self_init ();
  let x = (match Array.length Sys.argv with |1 -> 10000|_ -> int_of_string Sys.argv.(1)) in
  let c = coh_getcache "message_cache" in
  let t1 = Unix.gettimeofday () in
  for i = 1 to x do
    let m = {msg_id = i; msg_priority = p (); msg_subject = subjects.(s ()); msg_body = pad ^ (bodies.(b ()))} in
    coh_put_message c m;
    print_message m;
    Unix.sleep 1
  done;
  log_message (Printf.sprintf "Sent %d messages in %.3fs" x (Unix.gettimeofday () -. t1))

The sleep function allows the log messages from all the different programs to be correlated. Running it:

Publisher

Subscriber 1 - high priority messages

Subscriber 2 - INFO messages

Subscriber 3 - Messages mentioning XYZ

I think this is probably as far as I am going to take COH*ML for now; I need to get a lot more familiar with its native C++ interface, and re-acquainted C++ in general, before going much further. Nevertheless, this is more than sufficient as a proof-of-concept and will serve as a general framework for further development. I have a much better understanding than when I began of what is and is not feasible with this approach, and the trade-offs involved – it is ideally suited for relatively simple messages on which relatively complex algorithms written in OCaml can be run (then perhaps call back into C/C++ for, say, trade execution).

† when not updating the screen

open Cohml
open Printf
open Log_message

type message = {msg_id : int;  msg_priority : int; msg_subject : string; msg_body : string}

external coh_put_message: coh_ptr -> message -> unit = "caml_put_message"
external coh_get_message: coh_ptr -> int -> message = "caml_get_message"
external coh_pri_message: coh_ptr -> int -> message list = "caml_query_message_pri"

let print_message m = log_message (sprintf "id=%d, priority=%d, subject='%s', body='%s'\n" m.msg_id m.msg_priority m.msg_subject m.msg_body)

let () = 
  let test_msgs = [{msg_id = 1; msg_priority=3; msg_subject="test"; msg_body="hello, world!"};
		   {msg_id = 2; msg_priority=1; msg_subject="urgent!"; msg_body="High priority message"}] in
  let c = coh_getcache "message_cache" in
  List.iter (coh_put_message c) test_msgs;
  print_message (List.hd (coh_pri_message c 2));

The new C++ method, in cohml.c:

vector<Message*>* Cohml::query_message_pri(int k) {
  vector<Message*>* msgv = new vector<Message*>; 
  // field 1 is the priority of type int
  PofExtractor::Handle hExtractor = PofExtractor::create(typeid(int32_t), 1);
  Filter::View vFilter = LessEqualsFilter::create(hExtractor, Integer32::create(k));

  for (Iterator::Handle hIter = hCache->entrySet(vFilter)->iterator(); hIter->hasNext() ;) {
    Map::Entry::Handle hEntry = cast<Map::Entry::Handle>(hIter->next());
    Integer32::View vKey = cast<Integer32::View>(hEntry->getKey());
    Managed<Message>::View vMessage = cast<Managed<Message>::View>(hCache->get(vKey));
#ifdef DEBUG
    msg << __func__ << ": retrieved message: " << vMessage;
    debug(msg.str().c_str());
#endif
    Message* m = new Message(vMessage->getId(), vMessage->getPriority(), vMessage->getSubject(), vMessage->getBody());
    msgv->push_back(m);
  }

  return msgv;
}

Replacing:

ValueExtractor::Handle hExtractor = ReflectionExtractor::create("getPriority");

On the way I encountered a bug that causes a segmentation fault in List.iter:

Program received signal SIGSEGV, Segmentation fault.
0x08085570 in caml_interprete ()
(gdb) bt
#0  0x08085570 in caml_interprete ()
#1  0x08074992 in caml_main ()
#2  0x080846a8 in main ()
(gdb) 

Thanks to the time-reversing capabilities of Ocamldebug I can peer into the interpreter:

Lost connection with process 27541 (active process)
between time 1970 and time 1971
Tue Aug 16 17:13:02 2011: id=2, priority=1, subject='urgent!', body='High priority message'

Time : 1970 - pc : 14392 - module List
69   | a::l -> f a<|a|>; iter f l
(ocd)

This is why I am using List.hd there on line 18 instead of:

  List.iter print_message (coh_pri_message c 2);

UPDATE 17^th August: This was a bug in my C++ code, I was constructing an Array but treating it as a List in OCaml. D’oh! Fixed now and pushed to GitHub.

Anyway, the moral of the story is, don’t trust the documentation! Which was even for a later version than this feature was introduced in.

Also, writing C++ really makes you appreciate type inference. Most of the code above is type annotation and coercion. But like I say, it should be possible to just generate much of it.

To use a more complex data structure than a primitive type such as a string with the Coherence grid, there are three options:

1. A native Coherence class. This would be the option if developing from scratch an application that would only ever run on Coherence (e.g. using Coherence’s own String type rather than std::string from the C++ standard library).
2. Retrofitting an existing class to work with the Managed template. This is probably the easiest method.
3. Writing a new (de)serializer to work with an existing class. This is the lowest level but highest performance method.

While I am actually developing from scratch here, “systems integration” is my middle name†, so for the purposes of this example I am going to go with option 2 as I consider it to be a more representative scenario of “real work”. The complete code for this example is on GitHub.

The interesting thing about the C++ object definition is that it contains no Coherence-specific code, but it must have:

• A public or protected zero-parameter constructor
• A copy constructor
• A == operator, for equality comparison
• A << operator (e.g. for use with cout)
• A hash function, to return a unique identifier

Some of these a class is likely to have anyway. In addition there are two functions, to (de)serialize the objects. These are Coherence-specific, but are “free” so can be implemented independently of the class. I have done some research as to whether it is possible to generate these on-the-fly at runtime as I do with object-types for Oracle AQ and have concluded that it is not; therefore each class corresponding to an OCaml record (or other type) must be coded in C++ at compile time, and this is in addition to the code required to marshal the object to and from OCaml. The reason is of course so that objects in Coherence can be created and transparently accessed by clients in C++, Java and .NET. The good news is that the structure is quite regular and both should be quite amenable to code generation, perhaps from parsing the source code to the original existing class, if available. For this trivial example, storing and retrieving a record of type message in the grid, the C++:OCaml SLOC ratio is ~10:1, but the C++ is very simple‡.

open Cohml
open Printf
open Log_message

type message = {msg_id : int;  msg_priority : int; msg_subject : string; msg_body : string}

external coh_put_message: coh_ptr -> message -> unit = "caml_put_message"
external coh_get_message: coh_ptr -> int -> message = "caml_get_message"

let print_message m = log_message (sprintf "id=%d, priority=%d, subject='%s', body='%s'\n" m.msg_id m.msg_priority m.msg_subject m.msg_body)

let () = 
  let test_msgs = [{msg_id = 1; msg_priority=3; msg_subject="test"; msg_body="hello, world!"}] in
  let c = coh_getcache "message_cache" in
  List.iter (coh_put_message c) test_msgs;
  print_message (coh_get_message c 1);

Click to enlarge

After completing any of the above approaches, a data object is ready to be stored within the Coherence cluster. You can perform get and put based operations with your objects. However, to make use of more advanced features of Coherence: such as queries or entry processors; or if you use a key that is not a simple type; or when you use a cache loader and cache store, you must write some Java code.

Emphasis mine. I have all the C++ written, I just need to do that bit, which should be straightforward enough (and again like the C++ can probably be code-generated for the most part). Still, it adds complexity to the solution, which will make the OCaml a harder sell unless what we are actually doing with the cached objects is much better implemented in OCaml than C++, e.g. the sorts of algorithms that functional programming languages are well-suited for, or the kind of prototyping that a very high level language is well suited for, on already-defined objects (so perhaps the Java code backing the C++ code is already done for us!).

Unfortunately however I must conclude that a pure-OCaml interface to Coherence is impossible. However I am confident that my hybrid approach is going to be useful for “real work”, and better than SWIG in this particular case.

UPDATE: Perhaps I can get “close enough” with a PofExtractor.

† Actually it’s Aurelius
‡ Too much to post – see GitHub

open Cohml
open Callback
open Unix

let _ = register "cbf_coh_insert" (fun k v -> print_endline ("Inserted key=" ^ k ^ " value=" ^ v))
let _ = register "cbf_coh_update" 
  (fun k ov nv -> print_endline ("Updated key=" ^ k ^ " old value=" ^ ov ^ " new value=" ^ nv))
let _ = register "cbf_coh_delete" (fun k -> print_endline ("Deleted key=" ^ k))

let () = 
  print_endline "Listening...";
  let c = coh_getcache "test_cache" in
  coh_listen c "cbf_coh_insert" "cbf_coh_update" "cbf_coh_delete";
  sleep 1000

I am not entirely comfortable with this as a problem in the names can’t be detected at compile time – tho’ at runtime there is a check that the callback functions do exist, it does not check their type signatures. I wish it was possible to pass a closure/let binding straight into C†. It would be possible to accidentally have the arguments out of order:

  coh_listen c "cbf_coh_update" "cbf_coh_insert" "cbf_coh_delete";

And it will compile cleanly and crash as soon as it runs! We use advanced languages like OCaml precisely to avoid that possibility. But it does mean the ability to connect to more than one cache with MapListeners.

Next up: objects. Or maybe queries. The Coherence book (p.335), referring to data object serialization, states

Unlike the Java and .NET versions, in C++ this mapping is performed at compilation time.

So non-trivial applications will have to include C++ to use custom objects. I’d hoped to present the users of my bindings with a pure OCaml API, but this should still be straightforward enough.

† Update: Apparently you can. Well, sort of. Hmm.

open Cohml
open Callback
open Unix

let cbf_coh_insert k v = print_endline ("Inserted key=" ^ k ^ " value=" ^ v)
let _ = register "cbf_coh_insert" cbf_coh_insert

let cbf_coh_update k ov nv = print_endline ("Updated key=" ^ k ^ " old value=" ^ ov ^ " new value=" ^ nv)
let _ = register "cbf_coh_update" cbf_coh_update

let cbf_coh_delete k = print_endline ("Deleted key=" ^ k)
let _ = register "cbf_coh_delete" cbf_coh_delete

let () = 
  print_endline "Listening...";
  let c = coh_getcache "test_cache" in
  coh_listen c ;
  sleep 1000

The new library function is coh_listen on line 17. It sleeps after registering for callbacks, but could do some additional processing if thread-safe. The registered names correspond to those in the lower-level C++, an excerpt from cohml.c:

void CohmlMapListener::entryInserted(MapEvent::View vEvent) {
  // TODO: stash these function pointers
  caml_callback2(*caml_named_value("cbf_coh_insert"), 
		 caml_copy_string(cast<String::View>(vEvent->getKey())->getCString()), 
		 caml_copy_string(cast<String::View>(vEvent->getNewValue())->getCString()));
}

// call the OCaml function cbf_coh_update with the key, the previous value and the new value
void CohmlMapListener::entryUpdated(MapEvent::View vEvent) {
  caml_callback3(*caml_named_value("cbf_coh_update"), 
		 caml_copy_string(cast<String::View>(vEvent->getKey())->getCString()),  
		 caml_copy_string(cast<String::View>(vEvent->getOldValue())->getCString()), 
		 caml_copy_string(cast<String::View>(vEvent->getNewValue())->getCString()));
}

// call the OCaml function cb_coh_delete with the key just removed from the cache
void CohmlMapListener::entryDeleted(MapEvent::View vEvent) {
  caml_callback(*caml_named_value("cbf_coh_delete"), 
		caml_copy_string(cast<String::View>(vEvent->getKey())->getCString()));
}

Now if we run up the listener process and manipulate the cache from cohmlsh in another window:

Click to enlarge

Click to enlarge

Towards that end I have have bought a copy of Bruce Eckel’s Thinking in C++. Reading it is giving me a strange sense of déjà vu…

† This is possibly because we are still only using strings!
‡Get something off the grid, process it in OCaml and store it in the database, for example, or vice-versa

Click to enlarge

1. Use a class (or classes) written in pure C++ to interact with Coherence
2. Use extern "C" functions first to instantiate an object from (1) and return an object pointer to OCaml, then to invoke methods via that pointer.
3. From OCaml, call the function to create the object, then pass the pointer from (2) into the other C functions using the normal OCaml/C interface
4. Pre- and post- grid operations implemented in OCaml

The next challenge will be to use MapListener/Continuous Query to execute code in OCaml in response to events within the grid – if possible, configuring it from the OCaml side. And then to do it with more complex data structures than simple strings.