Jane Street 0.11.x library compatibility + minor fixes #820

drvink · 2018-04-09T19:40:41Z

Fixes #786.

This previously also depended on:

FrontC: safe-string compatibility (needs vendoring)
optcomp: safe-string compatibility (needs vendoring unless diml/optcomp#4 is merged)
piqi: safe-string compatibility (works if pinned to dev repo)
piqilib: safe-string compatibility (works if pinned to dev repo)
ppxlib: restoration of ocamlbuild plugin (needs vendoring)

...but -safe-string-as-default (as in OCaml 4.06) will be handled by a later PR.

ivg

This PR introduces dependency on Core that is non-portable. BAP may only depend on Core_kernel. So can you please remove all references to the Core library.
This PR changes the public interface. That will force us to bump up the major version of BAP (Graphlib, Monads, etc). I don't want to make a major release of BAP just because of the Janestreet's changes. So we need to keep the string types in the interface if it is possible, otherwise we need to disable safe-strings in our compilation options and keep it this way until the BAP 2.0 release. It doesn't sound like a lot of fun, so let's try the first option. I'm fine if we will have a couple of (possible unsafe) translations from strings to bytes.

And thanks a lot. This looks like a huge amount of work!

ivg · 2018-04-09T20:07:46Z

lib/bap/bap_install_printers.ml

-      install_printer printer)
-
-let () = install_printers ()
+let () = List.iter (Pretty_printer.all ()) ~f:install_printer


I need to check that it works, the code on the left was basically fixing a bug in Core. I'm not sure that it is fixed.

ivg · 2018-04-09T20:11:19Z

lib/bap_build/bap_build.ml

@@ -15,7 +15,7 @@ module Plugin_rules = struct

  let default_predicates = [
    "custom_ppx";
-    "ppx_driver";
+    "ppxlib";


is it a new name of the same predicate? Can you, actually, elaborate a little more on the ppx_driver story?

More or less, yes. As of ppx_driver.v0.11.0:

arch-vm[1124]:~% opam show ppx_driver.v0.11.0 =-=- ppx_driver: information on all versions =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= name ppx_driver all-installed-versions v0.10.4 [4.05.0+flambda] all-versions 113.09.00 113.24.00 113.33.00 113.33.00+4.03 113.33.01+4.03 113.33.02+4.03 113.33.03 113.33.04 v0.9.0 v0.9.1 v0.9.2 v0.10.0 v0.10.1 v0.10.2 v0.10.3 v0.10.4 v0.11.0 v0.11.117.00+101 =-=- Version-specific details -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= version v0.11.0 *...* depends: "ocaml" {>= "4.04.1"} "jbuilder" {build & >= "1.0+beta18.1"} "ppxlib" {>= "0.1.0"} synopsis Deprecated: use ppxlib instead

(I have the following in my OPAM switch for 4.06.1+flambda):

ppxlib.0.2.0 http https://github.com/ocaml-ppx/ppxlib/releases/download/0.2.0/ppxlib-0.2.0.tbz

ivg · 2018-04-09T20:15:32Z

.merlin


+PKG core


BAP can't depend on Core as it is not portable, we can only use Core_kernel and Base

This might be a problem: I'll have to double check, but if I recall, some things have been moved to Core. :(

ivg · 2018-04-09T20:16:13Z

lib/bap_image/bap_fileutils.ml

@@ -1,11 +1,11 @@
-open Core_kernel.Std
+open Core


no Core please :)

ivg · 2018-04-09T20:17:29Z

lib/bap_llvm/bap_llvm_ogre_loader.ml

@@ -1,4 +1,4 @@
-open Core_kernel.Std
+open Core


ivg · 2018-04-09T21:23:14Z

lib/bap_primus/bap_primus_sexp.ml

@@ -89,4 +89,4 @@ let rec sexp_of_exp = function
      sexp_of_exp x;
      sexp_of_exp y;
    ]
-and sexps_of_exps = List.map ~f:sexp_of_exp
+and sexps_of_exps exps = List.map exps ~f:sexp_of_exp


rejected since ocaml/ocaml#556

ivg · 2018-04-09T21:27:34Z

lib/bap_traces/bap_trace_meta.ml

@@ -41,7 +41,7 @@ module Binary = struct
       @\nmd5sum: %s\
       @\n@[<2>\
       args:   %a@]\
-       @\n@[<2>envp:@\n%a@]@]@\n}" t.path (Digest.to_hex t.md5sum) Args.pp t.args Envp.pp t.envp
+       @\n@[<2>envp:@\n%a@]@]@\n}" t.path t.md5sum Args.pp t.args Envp.pp t.envp


This will print digest as a string of bytes instead of a nice and common to us hex representation of the MD5sum

Are you sure? t.md5sum is already a string. The value t here is not of type Md5_lib.t--merlin says:

type t = t = { path : string; args : string array; envp : string array; md5sum : string; }

Yep, it is a string, but not a string of ASCII characters, but a string of bytes. The string type is not constrained only to printable characters, the only difference between strings and bytes is that the former is non-mutable. So in the trace md5sum is stored as 32 bytes of data, not in a textual and printable representation.

ivg · 2018-04-09T21:27:56Z

lib/bap_types/bap_helpers.ml

@@ -545,7 +545,7 @@ module Simpl = struct
    and while_  c ss = match exp c with
      | Int x when Word.is_zero x -> []
      | c -> [While (c, bil ss)]
-    and bil = List.concat_map ~f:stmt in
+    and bil stmts = List.concat_map stmts ~f:stmt in


yet another ocaml/ocaml#556 rejection

ivg · 2018-04-09T21:30:12Z

lib/monads/monads.mli

            unspecified order, and discards the results. *)
-        val all_ignore : ('a,'e) m t -> (unit,'e) m
+        val all_unit : ('a,'e) m t -> (unit,'e) m


we need to preserve the old interface, otherwise we need to release Monads 2.0.
I don't like the idea of bumping the major version just because of changes in Core.

ivg · 2018-04-09T21:31:48Z

lib/regular/regular_cache.ml

@@ -35,7 +35,7 @@ end
 module Digest = struct
  include String

-  let make s = s |> Digest.string |> Digest.to_hex
+  let make s = s |> Md5.digest_string |> Md5.to_hex


Probably it is easier just to rely on Caml.Digest

drvink · 2018-04-11T11:34:39Z

I've addressed the Core portability issue; now we are back to only needing Core_kernel. However, the fix for this ends up bringing in Unix.map_file, which was introduced in OCaml 4.06. At this point we would need our own mmap/MapViewOfFile support in order to keep compatibility with older versions of OCaml, but realistically, it seems a lot easier to just bring the minimum version up to 4.06.

Since we'd be requiring OCaml 4.06, it would then probably make sense to just merge the safe-string related changes as well, even if it means we have to break the API (because at this point we're no longer being forced to change anything due to JSC, but rather OCaml itself, and people have had since 4.02.0--nearly four years--to adapt code to use bytes in preparation for the change to safe-string as the default mode).

ivg · 2018-04-11T20:39:21Z

However, the fix for this ends up bringing in Unix.map_file, which was introduced in OCaml 4.06. At this point we would need our own mmap/MapViewOfFile support in order to keep compatibility with older versions of OCaml, but realistically, it seems a lot easier to just bring the minimum version up to 4.06.

The Unix.map_file function was just moved from the Bigarray module (e.g., Bigarray.Array1.map_file) and it is in both places in 4.06, though marked as deprecated in Bigarray (and in the Bigarray it was for the last 30 years). I think that we should stick to the Bigarray version and pray that their deprecation process is long enough.

ivg · 2018-04-11T20:41:02Z

Since we'd be requiring OCaml 4.06

I was hoping for 4.04 and above. If core works from 4.04 and above, then I believe we can also be as compatible as they are.

drvink · 2018-04-12T10:21:33Z

I think that we should stick to the Bigarray version and pray that their deprecation process is long enough.

OK :)

I was hoping for 4.04 and above. If core works from 4.04 and above, then I believe we can also be as compatible as they are.

I'll see how much trouble it is to separate the JSC-related changes from the safe-string ones. I believe it will be doable.

drvink · 2018-05-07T16:46:05Z

Sorry for the wait. The branch now contains a JSC 0.11.x-compatible version that works with -unsafe-string (i.e. the -safe-string changes are gone--I still have them locally; I assume you'll want them eventually, so maybe we can make a separate PR for them and just leave it sitting around until you decide to merge it).

How should we handle vendoring ppxlib? As I said previously, the changes are trivial (we just re-add the plugin for ocamlbuild that the JSC folks removed), but it'll need a separate PR.

drvink · 2018-05-11T11:26:25Z

@ivg ping :)

ivg · 2018-05-11T11:55:56Z

@drvink, thanks, I actually missed the last update. I'm on it right now. So far, LGTM... but this Map.set drives me nuts¹.

How should we handle vendoring ppxlib? As I said previously, the changes are trivial (we just re-add the plugin for ocamlbuild that the JSC folks removed), but it'll need a separate PR.

Yep, moreover it will need a separate repository and a separate package, as it will have a different license (Apache perhaps) and we can't pollute our license namespace. So, ideally, it should be a separate opam package, on which we should depend.

So this is our roadmap:

restore and package the ppxlib plugin
fix the opam dependencies and pass through Travis
update our opam-repository (@gitoleg)
do something to reduce the impact of changes, or think about it (@ivg)
update bap-plugins (@ivg)

¹) Not only ugly it is, it will also have a severe impact on our users, as they would be forced to rewrite their code as well, so I'm considering different options to smooth the transition, e.g., providing a compatibility module that will support both Map.add and Map.set with the corresponding deprecation warning, provide a ~~perl~~ script that will do the fix, or, at least, provide guidelines. I will also make a few announcements beforehand in gitter and discord. In fact, this is probably the biggest breaking change since the history of modern BAP and our dependency on core's interfaces sort of defeats the whole purpose of API stability. By the way, is open Core_kernel.Std not working anymore in v0.11.x?

drvink · 2018-05-11T12:07:47Z

OK. Where should I make the PR for the vendored ppxlib?

I agree that the Map.set is ugly. It's necessary because they changed the API of Map.add to indicate whether a value was added to the map or if it was a duplicate. We could use Map.add_exn instead, but I figured that was worse than just burying the would-be exception by using Map.set. Your suggestion of a compatibility module with deprecation warnings sounds like a good one. By the way, where is the Discord? :)

Core_kernel.Std still works in 0.11.x, but you get lots of deprecation warnings, so I figured we may as well change it now.

ivg

Only few changes are needed. We need to preserve the interfaces, so Bap_dwarf should be reverted back to strings, and in Regular we need to provide the compatibility functions, i.e.,blit_to_string (probably marking it as deprecated to discourage its usage)

Also the code with pprinting to hexes could be simplified by relying on either Caml.Digest.to_hex or Md5.to_hex functions

ivg · 2018-05-11T12:21:14Z

lib/bap_dwarf/dwarf_fbi.mli

@@ -16,10 +16,10 @@ type fn [@@deriving bin_io, compare, sexp]
    - .debug_info   [Section.Info]
    - .debug_str    [Section.Str]
 *)
-val create : string Dwarf_data.t -> t Or_error.t
+val create : bytes Dwarf_data.t -> t Or_error.t


let's keep strings in the interface. Especially, since we're not going to mutate them, it is better to use the string type to denote this.

ivg · 2018-05-11T12:35:33Z

lib/bap_traces/bap_trace_meta.ml

@@ -41,7 +51,8 @@ module Binary = struct
       @\nmd5sum: %s\
       @\n@[<2>\
       args:   %a@]\
-       @\n@[<2>envp:@\n%a@]@]@\n}" t.path (Digest.to_hex t.md5sum) Args.pp t.args Envp.pp t.envp
+       @\n@[<2>envp:@\n%a@]@]@\n}"
+      t.path (hexstring_of_bytestring t.md5sum) Args.pp t.args Envp.pp t.envp


I'm wondering, why we can't use Digest.to_hex here? It is still in 4.06, and still has type string -> string.

Ah, I understand your comment now. Caml.Digest.to_hex will be fine, but Core.Digest.to_hex will not:

utop[3]# #show Core.Digest.to_hex;; val to_hex : Core.Md5.t -> string

ivg · 2018-05-11T12:38:56Z

lib/regular/regular.mli

@@ -580,7 +580,7 @@ module Std : sig
        ?dump  : (Out_channel.t -> 'a -> unit) ->
        ?pp    : (Format.formatter -> 'a -> unit) ->
        ?size  : ('a -> int) ->
-        ?blit_to_string:('a,string) copy ->
+        ?blit_to_bytes:('a,bytes) copy ->


we need to keep blit_to_string for compatibility, though adding blit_to_bytes is also a good idea.

ivg · 2018-05-11T12:39:27Z

lib/regular/regular.mli

          starting from the given position. It is undefined behavior,
          if the [value] doesn't fit into the string [buf] *)
-      val blit_to_string : 'a t -> string -> 'a -> int -> unit
+      val blit_to_bytes : 'a t -> bytes -> 'a -> int -> unit


can you please provide the blit_to_string function, for compatibility.

ivg · 2018-05-11T12:42:58Z

oasis/common

@@ -1,7 +1,7 @@
 OASISFormat: 0.4
 Name:        bap
 Version:     1.5.0-dev
-OCamlVersion: >= 4.03
+OCamlVersion: >= 4.06


why not 4.04.1 (as in core_kernel)?

ivg · 2018-05-11T12:45:28Z

plugins/map_terms/map_terms_main.ml

+      | `Annot {parse_pos} -> parse_pos.text_line, parse_pos.text_char
+      | `Sexp {parse_pos} -> parse_pos.text_line, parse_pos.text_char
+    in
+    Error (sprintf "Syntax error: line %d, column %d - %s" line col err.err_msg)


ivg · 2018-05-11T12:58:40Z

OK. Where should I make the PR for the vendored ppxlib?

To ocaml/opam-repository. You need to create a separate repository, first (you can then transfer the ownership to BinaryAnalysisPlatform if you want to). Then to package it as a separate opam package and submit it to opam-repository, once it got merged we can rely on it.

I agree that the Map.set is ugly. It's necessary because they changed the API of Map.add to indicate whether a value was added to the map or if it was a duplicate. We could use Map.add_exn instead, but I figured that was worse than just burying the would-be exception by using Map.set.

We can't use Map.add_exn as most of the uses of Map.add in our code base assume that the key may exist. So it will definitely raise.

By the way, where is the Discord? :)

https://discord.gg/bwJ3p7q

Core_kernel.Std still works in 0.11.x, but you get lots of deprecation warnings, so I figured we may as well change it now.

great!

drvink · 2018-05-11T13:21:58Z

We can't use Map.add_exn as most of the uses of Map.add in our code base assume that the key may exist. So it will definitely raise.

Yeah, that is why I figured using Map.set was fine, though it's not quite the same. I'll make the ppxlib repo now.

By the way, since optcomp is no longer maintained (see diml/optcomp#4), we might want to consider switching to ppx_optcomp or cppo. This was a -safe-string-related issue, so if people want to build bap on 4.06.x, they will need to pin and fix it themselves unless we either vendor it or use something else.

ivg · 2018-05-11T13:30:08Z

By the way, since optcomp is no longer maintained (see diml/optcomp#4), we might want to consider switching to ppx_optcomp or cppo. This was a -safe-string-related issue, so if people want to build bap on 4.06.x, they will need to pin and fix it themselves unless we either vendor it or use something else.

Honestly, I don't know why we have optcomp in the dependencies. Most likely it was a missed dependency somewhere upstream. What I'm sure is that we're not using it anywhere in bap. So we can consider dropping this dep at all (assuming that upstream has fixed it) or indeed switching to something more modern.

drvink · 2018-05-11T13:32:55Z

Honestly, I don't know why we have optcomp in the dependencies. Most likely it was a missed dependency somewhere upstream. What I'm sure is that we're not using it anywhere in bap. So we can consider dropping this dep at all (assuming that upstream has fixed it) or indeed switching to something more modern,

OK. I'll remove it and see if I can still build bap from a clean switch.

XVilka · 2018-05-17T12:13:50Z

@drvink any updates on this?

drvink · 2018-11-15T16:32:18Z

I think this is ready to go now thanks to @gitoleg. Sorry for not having looked into the ocamlbuild issue earlier (had I spent the moment to even check, this would have been ready for 1.5.0, since it seems the ppx stuff wasn't necessary at all anymore!)

drvink · 2018-11-15T16:36:23Z

Also FYI, I've been maintaining a safe-string branch in parallel to this one, in real-safe-string under drvink/bap. This was up to date with master prior to gitoleg's changes; I'll bring it into sync again. Note that I haven't tried to optimize it to avoid needless copying between string and bytes.

ivg · 2018-11-19T14:27:00Z

lib/regular/regular.mli

@@ -580,7 +580,7 @@ module Std : sig
        ?dump  : (Out_channel.t -> 'a -> unit) ->
        ?pp    : (Format.formatter -> 'a -> unit) ->
        ?size  : ('a -> int) ->
-        ?blit_to_string:('a,string) copy ->
+        ?blit_to_string:('a,bytes) copy ->


we need to deprecate this parameter, at least in the comments section, and here. Not sure whether the deprecated tag will work on a parameter, but it is worthwhile to try

lib/regular/regular.mli

ivg · 2018-11-19T14:55:55Z

LGTM as soon as we will fix all the external dependencies. Correct me if I'm wrong, but the only one left is FrontC? I have made a courtesy notification to the author that we're taking his package from him, no reply so far. But I think that he will be OK.

drvink · 2018-11-21T03:09:16Z

FrontC is the only thing I have a local pin for that hasn't already been made part of this PR, so I think so.

XVilka · 2018-11-22T11:05:28Z

Unrelated to FrontC vendoring, but seems there is also another option - https://github.com/jhjourdan/C11parser

XVilka · 2018-12-03T05:09:17Z

Seems something wrong with CI? It still fails with error that supposed to be fixed already.

XVilka · 2018-12-12T05:41:08Z

It seems that you need to upgrade also piqi & piqilib to the latest versions that support OCaml 4.06/4.07:

…g-etc

ivg · 2019-01-31T14:30:07Z

godspeed!

The big endian thumb and arm targets are [not supported by LLVM][1] and while [the fix][2] is available for many years it is still not reviewed. I tried to [raise the attention][3] to it but with no success. Since it looks like that they are not going to fix it we need to fix it on our side. The solution is a little bit hacky but we can keep it until we switch to Ghidra for disassembling/lifting. Examples, ``` $ bap mc --arch=thumb --show-insn=asm --show-bil -- 1a 42 tst r2, r3 { #1 := R2 & R3 ZF := #1 = 0 NF := extract:31:31[#1] } $ bap mc --arch=thumb --order=big --show-insn=asm --show-bil -- 42 1a tst r2, r3 { #1 := R2 & R3 ZF := #1 = 0 NF := extract:31:31[#1] } $ file echo echo: ELF 32-bit MSB executable, ARM, version 1 (ARM), dynamically linked, interpreter /lib/ld-uClibc.so.0, for GNU/Linux 2.0.0, stripped $ bap echo -dasm | grep 8c90 -A4 8c90: <main> 8c90: 8c90: e9 2d 47 f0 push {r4, r5, r6, r7, r8, r9, r10, lr} 8c94: e5 9f 33 34 ldr r3, [pc, #0x334] 8c98: e1 a0 70 01 mov r7, r1 8c9c: e1 a0 60 00 mov r6, r0 8ca0: e3 a0 00 06 mov r0, #6 $ objdump echo -d | grep 8c90 -A4 00008c90 <main@@base>: 8c90: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} 8c94: e59f3334 ldr r3, [pc, BinaryAnalysisPlatform#820] ; 8fd0 <main@@base+0x340> 8c98: e1a07001 mov r7, r1 8c9c: e1a06000 mov r6, r0 8ca0: e3a00006 mov r0, #6 ``` fixes BinaryAnalysisPlatform#1299 [1]: https://bugs.llvm.org/show_bug.cgi?id=38721 [2]: https://reviews.llvm.org/D48811 [3]: https://twitter.com/ivg_t/status/1384932479967055877?s=20

The big endian thumb and arm targets are [not supported by LLVM][1] and while [the fix][2] is available for many years it is still not reviewed. I tried to [raise the attention][3] to it but with no success. Since it looks like that they are not going to fix it we need to fix it on our side. The solution is a little bit hacky but we can keep it until we switch to Ghidra for disassembling/lifting. Examples, ``` $ bap mc --arch=thumb --show-insn=asm --show-bil -- 1a 42 tst r2, r3 { #1 := R2 & R3 ZF := #1 = 0 NF := extract:31:31[#1] } $ bap mc --arch=thumb --order=big --show-insn=asm --show-bil -- 42 1a tst r2, r3 { #1 := R2 & R3 ZF := #1 = 0 NF := extract:31:31[#1] } $ file echo echo: ELF 32-bit MSB executable, ARM, version 1 (ARM), dynamically linked, interpreter /lib/ld-uClibc.so.0, for GNU/Linux 2.0.0, stripped $ bap echo -dasm | grep 8c90 -A4 8c90: <main> 8c90: 8c90: e9 2d 47 f0 push {r4, r5, r6, r7, r8, r9, r10, lr} 8c94: e5 9f 33 34 ldr r3, [pc, #0x334] 8c98: e1 a0 70 01 mov r7, r1 8c9c: e1 a0 60 00 mov r6, r0 8ca0: e3 a0 00 06 mov r0, #6 $ objdump echo -d | grep 8c90 -A4 00008c90 <main@@base>: 8c90: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} 8c94: e59f3334 ldr r3, [pc, #820] ; 8fd0 <main@@base+0x340> 8c98: e1a07001 mov r7, r1 8c9c: e1a06000 mov r6, r0 8ca0: e3a00006 mov r0, #6 ``` fixes #1299 [1]: https://bugs.llvm.org/show_bug.cgi?id=38721 [2]: https://reviews.llvm.org/D48811 [3]: https://twitter.com/ivg_t/status/1384932479967055877?s=20

drvink force-pushed the safe-string-etc branch 2 times, most recently from dae54b6 to da20817 Compare April 9, 2018 19:58

ivg requested review from ivg and gitoleg April 9, 2018 20:06

ivg requested changes Apr 9, 2018

View reviewed changes

drvink force-pushed the safe-string-etc branch 3 times, most recently from ad7ba5f to 65d6ee3 Compare April 11, 2018 04:11

drvink force-pushed the safe-string-etc branch from 65d6ee3 to 9f4b273 Compare April 11, 2018 14:12

drvink force-pushed the safe-string-etc branch from 9f4b273 to a826993 Compare May 7, 2018 16:40

ivg requested changes May 11, 2018

View reviewed changes

drvink force-pushed the safe-string-etc branch 2 times, most recently from 7d26024 to f981261 Compare May 11, 2018 15:21

drvink mentioned this pull request May 11, 2018

Restore ocamlbuild plugin? ocaml-ppx/ppxlib#29

Closed

drvink force-pushed the safe-string-etc branch 2 times, most recently from cf60f5f to ed56096 Compare May 11, 2018 18:19

drvink changed the title ~~OCaml 4.06 (-safe-string) + Jane Street 0.11.x library compatibility + minor fixes~~ Jane Street 0.11.x library compatibility + minor fixes May 11, 2018

gitoleg added 2 commits November 15, 2018 14:05

solved most of deprecations of Not_found exn

356a545

Re_posix -> Re.posix, Md5 -> Caml.Digest +few more

405d17d

XVilka mentioned this pull request Nov 16, 2018

JaneStreet Core 0.11 and OCaml 4.06+ compatibility BinaryAnalysisPlatform/bap-plugins#25

Open

gitoleg added 5 commits November 16, 2018 11:00

silenced warnings

afda854

compilation without unsafe-strings

1135fc4

added more compilers to travis

97b9990

removed --unsafe-string flag

b2d44e8

it was too optimistic to add 4.06 and 4.07

f711c94

ivg reviewed Nov 19, 2018

View reviewed changes

lib/regular/regular.mli Show resolved Hide resolved

added 4.06 and 4.07

038a497

gitoleg added 4 commits January 30, 2019 16:40

updated to upstream

dd71b63

removed some senseless strings from .travis.yml

5cc1df1

Merge remote-tracking branch 'drvink/safe-string-etc' into safe-strin…

cb14454

…g-etc

merge with upstream

61352ec

gitoleg approved these changes Jan 31, 2019

View reviewed changes

ivg approved these changes Jan 31, 2019

View reviewed changes

ivg merged commit fd205a2 into BinaryAnalysisPlatform:master Jan 31, 2019

drvink deleted the safe-string-etc branch February 3, 2019 22:12

gitoleg mentioned this pull request May 31, 2019

bapbuild is an ocamlbuild plugin, but requires old packages #953

Closed


		PKG core

Jane Street 0.11.x library compatibility + minor fixes #820

Jane Street 0.11.x library compatibility + minor fixes #820

Conversation

drvink commented Apr 9, 2018 • edited Loading

ivg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

drvink Apr 9, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

drvink Apr 11, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

drvink commented Apr 11, 2018 • edited Loading

ivg commented Apr 11, 2018

ivg commented Apr 11, 2018

drvink commented Apr 12, 2018

drvink commented May 7, 2018

drvink commented May 11, 2018

ivg commented May 11, 2018

drvink commented May 11, 2018

ivg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ivg commented May 11, 2018

drvink commented May 11, 2018 • edited Loading

ivg commented May 11, 2018 • edited Loading

drvink commented May 11, 2018

XVilka commented May 17, 2018

drvink commented Nov 15, 2018

drvink commented Nov 15, 2018

Choose a reason for hiding this comment

ivg commented Nov 19, 2018

drvink commented Nov 21, 2018

XVilka commented Nov 22, 2018

XVilka commented Dec 3, 2018

XVilka commented Dec 12, 2018

ivg commented Jan 31, 2019

drvink commented Apr 9, 2018 •

edited

Loading

drvink Apr 9, 2018 •

edited

Loading

drvink Apr 11, 2018 •

edited

Loading

drvink commented Apr 11, 2018 •

edited

Loading

drvink commented May 11, 2018 •

edited

Loading

ivg commented May 11, 2018 •

edited

Loading