search for: lablgtk

...vely verbose debug logs. I'd much rather > the bindings reraised errors as exceptions on the OCaml side. Unfortunately most errors are assertions, which we can't hook into. Perhaps though we can recover some type safety. Hypothetically, I can imagine using polymorphic variants just like lablgtk, and type llvalue = [`Value] type lluser = [value | `User] type llconstant = [user | `Constant] type llfunction = [llconstant | `Function] val value_name : [> llvalue] -> string val is_tail_call : [>llfunction] -> bool Would something like this be worthwhile? If we do it right, I thi...

The 'may' function is a higher-order function (HOF) that replaces: match x with | None -> () | Some x -> f x with: may f x The idea comes from lablgtk (OCaml Gtk bindings) where it is widely used. If this change is clearer than previous code, then this could be used in many more places. However I previously steered clear from using HOFs like this because they can be quite confusing for newcomers to functional programming. Rich.

...than just naming the variant sum types > Llvm.ll_____. I considered some other options, but decided I'm not fond of > them in practice. I think we'd need only one definition of "type 'a whatever". The phantom type would be enough to distinguish everything. For instance, lablgtk has a "type 'a obj" that they use as the base type for all of their variants, which I might copy. We can even hide this type by naming the variants something like "llfunction_variants" and then "type llfunction = llfunction_variants obj" to have roughly the same in...

Erick, After some experimentation, I'd prefer the closed system. LLVM has some type peculiarities like the commonality between CallInst and InvokeInst. I find that the closed type system lets me express such constraints more naturally. Expressing these constraints explicitly in the open system involves annotating the C++ class hierarchy with extra variants which are unnecessary in

On Tue, Nov 10, 2015 at 08:25:54PM +0000, Richard W.M. Jones wrote: > The 'may' function is a higher-order function (HOF) that replaces: > > match x with > | None -> () > | Some x -> f x > > with: > > may f x Another possibility is to break from lablgtk and call the function 'maybe', as in: g#set_trace trace; g#set_verbose verbose; maybe g#set_identifier identifier; ? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-...

On Tuesday 16 February 2010 03:51:00 Jianzhou Zhao wrote: > Does anyone know if there is any realistic project using LLVM-OCaml > Bindings? I've written a VM in OCaml built upon LLVM using LLVM's OCaml bindings: http://www.ffconsultancy.com/ocaml/hlvm/ There are at least two other significant users of LLVM's OCaml bindings, AFAIK. > How is the performance? Performance

Attached are updated LLVM-OCaml Bindings Tutorial from Chris Wailes. (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-April/021804.html) We changed them to work with the latest APIs(LLVM2.6 and the latest LLVM from SVN). Does anyone know if there is any realistic project using LLVM-OCaml Bindings? How is the performance? Jianzhou -------------- next part -------------- A non-text attachment was

...ds in OCaml which don't take any parameters don't require the dummy unit arg, ie writing: method foo = ... is fine. The reason you might need the unit arg is if you need to create a closure from the method without calling it, for example if you need to use the method in a callback. In lablgtk2 the convention is to use unitless methods if either: the method shouldn't be used as a callback; or: (conceptually) the method doesn't change the object's internal state. Let's do that here. --- v2v/convert_linux.ml | 2 +- v2v/linux_bootloaders.ml | 14 ++++++-------- v2v...