From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id BC4F37EE25 for ; Tue, 5 Nov 2013 22:30:21 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of jp.deplaix@gmail.com) identity=pra; client-ip=74.125.82.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jp.deplaix@gmail.com"; x-sender="jp.deplaix@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of jp.deplaix@gmail.com designates 74.125.82.41 as permitted sender) identity=mailfrom; client-ip=74.125.82.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jp.deplaix@gmail.com"; x-sender="jp.deplaix@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wg0-f41.google.com) identity=helo; client-ip=74.125.82.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jp.deplaix@gmail.com"; x-sender="postmaster@mail-wg0-f41.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEDAOxieVJKfVIplGdsb2JhbABZgz+DW7tuS4EsFg4BAQEBBwsLCRIqgiUBAQUjDwENARscAgMMBgMCCw0CAgUWCwICCQMCAQIBEREBBQEcEwgBAReHUwEDDwQBCJBWj1qMBFODCYQmChknDWSJAQEBBAyBHYtYgl8WglWBRAOYCoY9iWBBhFI X-IPAS-Result: AlEDAOxieVJKfVIplGdsb2JhbABZgz+DW7tuS4EsFg4BAQEBBwsLCRIqgiUBAQUjDwENARscAgMMBgMCCw0CAgUWCwICCQMCAQIBEREBBQEcEwgBAReHUwEDDwQBCJBWj1qMBFODCYQmChknDWSJAQEBBAyBHYtYgl8WglWBRAOYCoY9iWBBhFI X-IronPort-AV: E=Sophos;i="4.93,641,1378850400"; d="scan'208";a="33893319" Received: from mail-wg0-f41.google.com ([74.125.82.41]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 05 Nov 2013 22:30:21 +0100 Received: by mail-wg0-f41.google.com with SMTP id b13so3548077wgh.0 for ; Tue, 05 Nov 2013 13:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=k2SIMFWxjB6qP3ehlks4yXB1QJYg2+JJshpqVqgmZ4Q=; b=D82jw4HRCxImwykcu8GstsW7dIaPVRsiJxo9XJrlEOK4dh967yRkl7OtgLRNTfTgYz REl4NtABNaB6SUfGIF07BvFCIuIuqJxi4EEDnCwvAUt7f2BrMUlwsNqiQ9KLHGNfucjO TKFsu5OiPuSwwTt8M8YJ4VYlGz9LYAm5uCl73S2zuGmtz0ArcUkhfc0G4w1TxXkliy+I z1z9qrGkDbonO9jxvtWvdtziBPoBERmATtbML6X2K/JGx2ewrPeXGol4YtKOYLW1pK4M XOkKqqwVUqiqjNr4fACUSSzM8VBZ7VznuI0T4jlv+pJZ56oU/qdGR6x90J8k4TgEDm2J tvGw== X-Received: by 10.194.174.36 with SMTP id bp4mr19003020wjc.7.1383687020426; Tue, 05 Nov 2013 13:30:20 -0800 (PST) Received: from [192.168.1.23] (AMontsouris-652-1-188-204.w90-24.abo.wanadoo.fr. [90.24.211.204]) by mx.google.com with ESMTPSA id qc10sm17963637wic.9.2013.11.05.13.30.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 13:30:19 -0800 (PST) Message-ID: <52796387.8070602@gmail.com> Date: Tue, 05 Nov 2013 22:30:47 +0100 From: Jacques-Pascal Deplaix User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <5278D1D1.4060009@gmail.com> <523e06f6b965a40b16bc8fe69a88e339@whitequark.org> In-Reply-To: <523e06f6b965a40b16bc8fe69a88e339@whitequark.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] LLVM OCaml bindings Why LLVM chose to do Asserts instead of raise an exception ? Anyways, thanks for your impressive work. I will consider re-switch to the official binding if it's finally usable. On 11/05/2013 12:32 PM, Peter Zotov wrote: > Jacques-Pascal Deplaix писал 05.11.2013 15:09: >> Hi, >> >> So now I have again my own binding that produces LLVM-IR but this time >> with the same interface than the official binding, and it works pretty >> well [4]. > > The problem is that just generating LLVM IR is often not enough. > All of the below cannot be achieved without a proper binding: > > 1) JIT, > 2) Querying the backend for sizes of structures, legal integral types, > 3) Native code generation without shelling out. > > Generally, you can do very much with LLVM by shelling out to its > plenthora > of command-line tools, but I find the in-process solution cleaner. > > You can get sensible error messages instead of segfaults by using > a Debug+Asserts or Release+Asserts build of LLVM. The builds packaged > in Debian, opam, etc are usually built without asserts. > > I'll probably release LLVM 3.4 bindings on opam and they will feature > asserts on by default. > >> [2]: I have done several issues on the LLVM bug tracker, but apart from >> segfaults and bugs when trying to use LLVM_bitwriter, the missed feature >> is, IMHO, the possibility to get a string that contains the LLVM-IR >> code, and not just print it. > > This will be included in upcoming 3.4 release. I will be happy to hear > (and likely implement) what else do you miss. > >> [3]: https://github.com/jpdeplaix/cervoise/blob/jeSuisFou/src/LLVM.mli >> [4]: https://github.com/jpdeplaix/cervoise/blob/master/src/LLVM.ml >> >> On 11/05/2013 05:23 AM, Peter Zotov wrote: >>> Hello folks, >>> >>> I'm currently working on improving LLVM's OCaml bindings. >>> There's been quite some progress so far[1]; the only major >>> areas pending are AOT code generation and MCJIT support. >>> >>> I would be very interested to hear how are you using these >>> bindings, or suggestions for future development. In particular, >>> I'd like to understand the impact of breaking the API. >>> >>> [1]: >>> https://github.com/llvm-mirror/llvm/commits/master/bindings/ocaml >>> >