Hello folks.
I'm very interested in improving LLVM's OCaml bindings. I have
several nontrivial patches sitting on llvm-commits for several
weeks, and so far there's been little interest in them.
Could someone with a good understanding of OCaml please take
a look at these?
1) http://llvm-reviews.chandlerc.com/D1925
Every other function in OCaml bindings accepts context
explicitly, would it be a legitimate change to make existing
functions accept it as well? This would break the API.
2) http://llvm-reviews.chandlerc.com/D1926
I'd like to add garbage collection support to the API
wherever safe, that's at least DataLayout.t and llmemorybuffer.
This removes the need for .dispose. I could remove it and break
the API or print a warning at runtime.
3) http://llvm-reviews.chandlerc.com/D1927
In order to allow code generation from OCaml, I need to build
a stub library per configured target. I'm not sure how to
integrate it with LLVM's build system; my current solution seems
very ad-hoc.
I will update the patch to use Dynlink interface (this is the
textbook use case for Dynlink), but conceptually this doesn't
change the problem of interfacing with build system.
--
WBR, Peter Zotov.
On Sat, Nov 2, 2013 at 9:04 PM, Peter Zotov <whitequark at whitequark.org>wrote:> Hello folks. > > I'm very interested in improving LLVM's OCaml bindings. I have > several nontrivial patches sitting on llvm-commits for several > weeks, and so far there's been little interest in them. > > Could someone with a good understanding of OCaml please take > a look at these? > > 1) http://llvm-reviews.chandlerc.com/D1925 > > Every other function in OCaml bindings accepts context > explicitly, would it be a legitimate change to make existing > functions accept it as well? This would break the API. >I don't really have a good idea of who uses these OCaml bindings API's. A good first step is probably to map out the landscape of the users of the API. Maybe browse research papers? I wouldn't expect to see many OCaml programs "in production" that depend on this API. Also, I'm not sure if we have a stated backwards compatibility policy for this API. Ultimately you probably just want to talk with all the API users you can scrape together. -- Sean Silva> > 2) http://llvm-reviews.chandlerc.com/D1926 > > I'd like to add garbage collection support to the API > wherever safe, that's at least DataLayout.t and llmemorybuffer. > This removes the need for .dispose. I could remove it and break > the API or print a warning at runtime. > > 3) http://llvm-reviews.chandlerc.com/D1927 > > In order to allow code generation from OCaml, I need to build > a stub library per configured target. I'm not sure how to > integrate it with LLVM's build system; my current solution seems > very ad-hoc. > > I will update the patch to use Dynlink interface (this is the > textbook use case for Dynlink), but conceptually this doesn't > change the problem of interfacing with build system. > > -- > WBR, Peter Zotov. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131103/cf4320c6/attachment.html>
(readding llvmdev) On Sun, Nov 3, 2013 at 1:40 AM, Peter Zotov <whitequark at whitequark.org>wrote:> Sean Silva писал 03.11.2013 09:22: > >> On Sat, Nov 2, 2013 at 9:04 PM, Peter Zotov <whitequark at whitequark.org> >> wrote: >> >> Hello folks. >>> >>> I'm very interested in improving LLVM's OCaml bindings. I have >>> several nontrivial patches sitting on llvm-commits for several >>> weeks, and so far there's been little interest in them. >>> >>> Could someone with a good understanding of OCaml please take >>> a look at these? >>> >>> 1) http://llvm-reviews.chandlerc.com/D1925 [1] >>> >>> >>> Every other function in OCaml bindings accepts context >>> explicitly, would it be a legitimate change to make existing >>> functions accept it as well? This would break the API. >>> >> >> I don't really have a good idea of who uses these OCaml bindings >> API's. A good first step is probably to map out the landscape of the >> users of the API. Maybe browse research papers? I wouldn't expect to >> see many OCaml programs "in production" that depend on this API. Also, >> I'm not sure if we have a stated backwards compatibility policy for >> this API. Ultimately you probably just want to talk with all the API >> users you can scrape together. >> > > I've looked through all Google hits by "ocaml llvm". Sadly, there are no > alive (updated within last 12 months) projects using the OCaml bindings. > Further, I only found research projects. I guess this means that there > won't be much impact from breaking the API. I have tried to contact > some of the authors, though, and I'll write to the OCaml ML. > > This leaves another question open: are there any LLVM developers who > can review OCaml patches? >I honestly don't know. -- Sean Silva> > >> -- Sean Silva >> >> >> 2) http://llvm-reviews.chandlerc.com/D1926 [2] >>> >>> >>> I'd like to add garbage collection support to the API >>> wherever safe, that's at least DataLayout.t and llmemorybuffer. >>> This removes the need for .dispose. I could remove it and break >>> the API or print a warning at runtime. >>> >>> 3) http://llvm-reviews.chandlerc.com/D1927 [3] >>> >>> >>> In order to allow code generation from OCaml, I need to build >>> a stub library per configured target. I'm not sure how to >>> integrate it with LLVM's build system; my current solution seems >>> very ad-hoc. >>> >>> I will update the patch to use Dynlink interface (this is the >>> textbook use case for Dynlink), but conceptually this doesn't >>> change the problem of interfacing with build system. >>> >>> -- >>> WBR, Peter Zotov. >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu [4] >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev [5] >>> >> >> >> >> Links: >> ------ >> [1] http://llvm-reviews.chandlerc.com/D1925 >> [2] http://llvm-reviews.chandlerc.com/D1926 >> [3] http://llvm-reviews.chandlerc.com/D1927 >> [4] http://llvm.cs.uiuc.edu >> [5] http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > -- > WBR, Peter Zotov. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131103/d3c841ec/attachment.html>
Sean Silva wrote:> I've looked through all Google hits by "ocaml llvm". Sadly, there are no > alive (updated within last 12 months) projects using the OCaml bindings. > Further, I only found research projects. I guess this means that there > won't be much impact from breaking the API.I wrote HLVM in 2008 and have been tinkering with OCaml+LLVM again recently, trying to get a good dev environment up and running. HLVM wasn't officially research. Also, it doesn't work with the current LLVM for reasons unknown. I consider the current OCaml bindings to be quite stable so I'd be happy to see minor tweaks go in (like adding explicit contexts) but if anyone wants to make major changes or completely rewrite them then I'd ask that it be a completely separate project so they don't break what we already have that works fine. Cheers, Jon.