search for: ocamlcore

HLVM is a garbage collected virtual machine built upon LLVM: http://forge.ocamlcore.org/projects/hlvm/ The development of HLVM was described in a series of three OCaml Journal articles that turned out to be among our most popular. Consequently, we have decided to run another series of related articles that build upon this foundation in order to develop complete compilers. The...

On Mon, May 11, 2015 at 07:22:58PM +0200, Pino Toscano wrote: > On Monday 11 May 2015 11:11:50 Richard W.M. Jones wrote: > > OUnit2 has an OUnit (v1) compatibility module. Unfortunately it > > is rather gravely broken: > > https://forge.ocamlcore.org/tracker/?func=detail&aid=1392&group_id=162&atid=730 > > > > Since there is no new release fixing this, it's easier to switch to > > using OUnit2 for unit tests. > > A pity, for the bug and the fact that there's no oUnit v2 for > Fedora 21... >...

...lgorithms difficult or > impossible. True. Perhaps that is a good argument for providing both kinds. However, nulls are certainly more common than concurrent data structures. :-) The entire source code for HLVM is available for free under a commerce-friendly BSD license, BTW: http://forge.ocamlcore.org/projects/hlvm/ -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

...> > True. Perhaps that is a good argument for providing both kinds. However, > nulls > are certainly more common than concurrent data structures. :-) > > The entire source code for HLVM is available for free under a > commerce-friendly BSD license, BTW: > > http://forge.ocamlcore.org/projects/hlvm/ > > -- > Dr Jon Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/?e > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mail...

OUnit2 has an OUnit (v1) compatibility module. Unfortunately it is rather gravely broken: https://forge.ocamlcore.org/tracker/?func=detail&aid=1392&group_id=162&atid=730 Since there is no new release fixing this, it's easier to switch to using OUnit2 for unit tests. --- .gitignore | 2 +- README | 2 +- mllib/JSON_tests.ml | 56 +++++++++++++++++...

I have been working on a high-level virtual machine built upon LLVM since Christmas 2008 and just released the first working version: http://forge.ocamlcore.org/projects/hlvm/ This alpha release of HLVM provides: . Unit, bool, int and float primitive types. . Tuples (as first-class structs). . Homogeneous array type. . Boxed value type. . Function pointers. . Generic printing. . Full tail calls. . Precise garbage collection. . Foreign function interf...

On Thu, Jun 18, 2009 at 3:14 AM, Granville Barnett<granvillebarnett at googlemail.com> wrote: > >> Firstly, rather than using a single 1 word pointer to represent a >> reference I >> chose to use 3 words including a pointer to the type and a pointer to the >> value (as well as metadata). This allows typed nulls and that addresses an >> important deficiency

I have committed the changes to HLVM that bring it up to date with respect to the new LLVM 2.6 release: http://hlvm.forge.ocamlcore.org/ This required handling of llcontexts and the injection of a call to the new Llvm_executionengine.initialize_native_target function (that is undocumented) *before* the JIT EE is created, otherwise LLVM resorts to the LLVM interpreter which breaks at run-time because it does not fully implem...

Resent, to the list this time instead of David (sorry for the duplicate)... On Thu, Nov 12, 2009 at 9:57 PM, David Terei <davidterei at gmail.com> wrote: > I've run into some issues with tail calls in the past, make sure you > are doing the following: > > 1. Call should be marked with tail (obviously) > 2. Next statement after tail call should be 'return void'

On Monday 11 May 2015 11:11:50 Richard W.M. Jones wrote: > OUnit2 has an OUnit (v1) compatibility module. Unfortunately it > is rather gravely broken: > https://forge.ocamlcore.org/tracker/?func=detail&aid=1392&group_id=162&atid=730 > > Since there is no new release fixing this, it's easier to switch to > using OUnit2 for unit tests. A pity, for the bug and the fact that there's no oUnit v2 for Fedora 21... It is not a problem for me anyway,...

...and first class modules allow more "sophisticated" used of modules, although I tend to think that these will just make the code more confusing so I would push back on people trying to use if they were being too clever. (OCaml >= 3.12 and especially >= 4.00 https://forge.ocamlcore.org/docman/view.php/77/112/leroy-cug2010.pdf https://ocaml.org/meetings/ocaml/2012/slides/oud2012-leroy-slides.pdf) Also it would be nice to reduce the number of warnings, especially about the new "noalloc" syntax: File "common_utils.ml", line 26, characters 0-85: Warni...

See: https://forge.ocamlcore.org/docman/view.php/77/112/leroy-cug2010.pdf --- v2v/cmdline.ml | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/v2v/cmdline.ml b/v2v/cmdline.ml index 6aba4afb5..fdd0f2614 100644 --- a/v2v/cmdline.ml +++ b/v2v/cmdline.ml @@ -627,11 +627,9 @@ read the man page virt-v2v...

Jon Harrop wrote: > The simplest way is surely to reuse HLVM because it provides everything you > need and is even written in the right language! ;-) Is there a web page with HLVM docs? There's a README.txt in the subversion repository: https://llvm.org/svn/llvm-project/hlvm/trunk/README.txt which says: HLVM comes with documentation in HTML format. These are provided in

This adds --print-target. In addition, v2 provides a machine-readable version (in JSON format). All of the record -> JSON boilerplate in this patch could be eliminated if we moved the baseline to OCaml 4.02. Rich.

Methods 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

tail calls are only implemented for fastcall calling convention if i remeber right from my inquiries. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091112/e8f1dd2a/attachment.html>

> Firstly, rather than using a single 1 word pointer to represent a reference > I > chose to use 3 words including a pointer to the type and a pointer to the > value (as well as metadata). This allows typed nulls and that addresses an > important deficiency found in most other VMs including the CLR. Is Scarcity > able to handle such references or does its implementation of stack

Good afternoon! I'm trying to write an LLVM codegen for a Standard ML compiler (MLton). So far things seem to match up quite nicely, but I have hit two sticking points. I'm hoping LLVM experts might know how to handle these two cases better. 1: In ML we have some types that are actually one of several possible types. Expressed in C this might be thought of as a union. The codegen only

> Aaah. Wasn't quite sure what you were doing here. I'm not positive > what llvm can emit via the writers (there's support for all parts of > the file format), but it could be extended to write one out. I'm just > not quite sure why :) > > -eric Well, ultimately I'm curious about what it would take to port a JVM based language (http://openquark.org) to

...eld }?). This style is widely used inside the OCaml compiler sources, and is briefer than the long form, so it makes sense to use it. Furthermore there was one place in virt-dib where we are already using this new style, so the old code did not compile on OCaml < 3.12. See also: https://forge.ocamlcore.org/docman/view.php/77/112/leroy-cug2010.pdf --- builder/builder.ml | 22 ++++++++++------------ builder/index.ml | 19 ++++--------------- builder/index_parser.ml | 3 +-- builder/list_entries.ml | 27 +++++++-------------------- builder/simplestreams_...