00:07 <d_bot> <rgrinberg> If you're only interested errors, you can also do $ dune build check

02:23 <Boarders> what does this sort of error mean

09:34 <d_bot> <ostera> Boarders: these would be syntax errors and type-errors

09:34 <d_bot> <ostera> (possibly also dune-related errors)

11:53 <oznt> hi guys, I am trying to build csexp-1.3.2 on a gentoo system, but I am seeing an error: https://pastebin.com/cAv4sU9R

11:53 <oznt> can someone give me a hand please?

11:58 <octachron> this sounds like a packaging issue from gentoo's result package. Did you try to upgrade the result package to 1.5 as suggested in gentoo's bug tracker?

12:12 <oznt> octachron, no. Thank you

12:15 <oznt> that was it

12:18 <octachron> great!

13:18 <d_bot> <gar> I need to compile an mli file with a ppx deriving dependency. But if I pass either a cmxa or a cmx I get "don't know what to do with {{file}}". What's the secret formula for this?

13:26 <d_bot> <octachron> ppxs are executables, what cmx(a) are you trying to feed this poor ocamlfind with?

13:32 <d_bot> <gar> Right, sorry, the problem is a deriver is not getting engaged so when I try to compile the transformed file I get "Cannot locate deriver". That means the ppx is not fully transforming the input, correct? Not that a ppxlib needs to be passed to the compiler...

13:32 <d_bot> <gar> This is a locally-defined ppx lib.

13:35 <d_bot> <octachron> It sounds more like ppx_deriving had trouble linking the right deriver.

13:48 <d_bot> <gar> yeah, but everything looks in order to (naive) me. The source contains a rewriter (which does get engaged) in one module and a deriver (`Ppxlib.Driver.add deriver...`) in another module. Both modules are passed to the ppx executable compile command, after ppxlib and associated OPAM libs. The rewrite injects `[@@deriving (bin_io, version, sexp)]` . The compiler then complains "Error: Cannot locate deriver version". That's the deri

13:49 <d_bot> <gar> Or should the ppx executable have transformed the `[@@driving` bit?

13:52 <d_bot> <gar> IOW, there are clearly two passes involved; one injects `[@@deriving`, the other does the derivation. Are they both supposed to happen when I run the ppx executable? BTW, I am running it separately, not passing it to the compiler.

13:54 <d_bot> <gar> My understanding is that In The Beginning multiple jobs were used, but that now `ppxlib` acts as a driver so all passes are handled in one job.

13:59 <d_bot> <octachron> If you are invoking directly the ppx, there is no compiler involved.

13:59 <d_bot> <octachron> Passing "ppxlib" as a dependency does not make sense?

13:59 <d_bot> <octachron> The error is due to ppx_deriving trying to locate the version deriver and failing.

14:03 <d_bot> <gar> Since the code contains `Ppxlib.Driver.add ...`, it must be that I'm building the ppx executable incorrectly? I.e. that code is not being called at load time.

14:09 <d_bot> <gar> @octachron I was passing ppxlib to the compile under a delusion.

14:11 <d_bot> <octachron> By default, derivers are dynamically linked, if you don't give the location of the plugins at when running the ppx_deriving ppx, it can only fail.

14:11 <d_bot> <gar> So when I build my ppx lib, emitting a cmxs is a requirement?

14:12 <d_bot> <gar> I do put all the locations on the search path using `-I`.

14:13 <d_bot> <octachron> Or as stated in the ppx_deriving documentation, you need to build ppx in static mode.

14:18 <d_bot> <octachron> Also are you sure that `-I` is the right flag for ppx_deriving?

14:20 <d_bot> <gar> Ok, there must be a problem in my compile command for the executable. I pass all the cmx files, I put everything in the search path, and I use `-linkall`, and the last thing I pass is a module containing only `let () = Ppxlib.Driver.standalone ()`. Anything else I need to do?

14:21 <d_bot> <gar> I also pass `-predicates ppx_driver`, and I use `-linkpkg` and `-package` for OPAM deps.

14:38 <d_bot> <octachron> That doesn't seem obviously wrong.

14:51 <d_bot> <gar> The error message `Cannot locate deriver` - is that emitted by the compiler or by something from `ppxlib`? I would think the compiler, but how does it know about `deriver`?

15:10 <d_bot> <gar> Ok, I see what the problem is. For some OPAM deps, `ocamlfind` injects `-ppx` options into the command line. That works for the OPAM stuff since it follows `findlib` conventions. My locally-defined ppxlib does not. Don't know that the solution is yet, but that's where the problem lies. Thanks for your feedback @octachron

15:35 <d_bot> <octachron> The cannot locate deriver error message is raised by ppx_deriving (borrowing the error printing API from the compiler), the compiler is not involved at all.

16:31 <d_bot> <vinz> is there a way to ask ocamlopt to keep the `/tmp/foo.o` file it generates on calls like `as -o 'src/.foo_objs/native/foo.o' '/tmp/camlasmabef9b.s'`

16:58 <def> -S ?

17:00 <d_bot> <vinz> will try !

18:01 <d_bot> <gar> @octachron Turns out there is an error in my code for handling transitive deps. It resulted in a ppx being passed as a dep for the compile, which in turn caused ocamlfind to inject a `-ppx` option that introduced ppx_deriving, which in turn received control from the compiler when the deriving attribute needed handling, so of course it could not find the deriver. I guess deriving attrs do not need to be expanded in mli files?

18:02 <d_bot> <octachron> No they need to be expanded in mli files to expose the derived functions

18:26 <d_bot> <Skilly> i have a question about menhir and shift/reduce conflicts - inlined it with the code snippets here because i'm not sure how the irc bot would like this https://hashb.in/#JYAgFghgbgpiAOAnA9gIwqgNgTxBEAzsJjiAI4CuMBALsMgHZ6rIU0gCyMDYwiCEREQYBzPAwAmhXgDMaAekQwJFAMZxVjGZmCqaBADQhUbcDCUhg7EcmoAuAFAPNDGjAAeNOyAcADfzTYjiAgAD4gACoAkgByESEgAN6RUa4gAL4OIeERAEIA8vkAMiHJecjImBlZYSCIALyIgfBJkQBKMDJ1GSD+vk4AtrhIaJgwA94OwF1RIB7wOqpWMKSQsClx8nmFJT

18:26 <d_bot> <Skilly> oops, didn't realise how long that link is, sorry

18:30 <d_bot> <Skilly> thinking about this some more - i think it has to do with the fact that while it could resolve it if it had more lookahead tokens, it can't right now because it needs to make the decision about "do i use `ty` or do I use TINT/TBOOL" - is that remotely correct?

18:33 <d_bot> <Skilly> (and therefore, replacing the explicit TINT/TBOOL's with `ty` makes it so the parser doesn't have to worry about this decision yet, and only make this decision once it reaches RBRACKET vs `exp`, an unambiguous choice)

18:45 <d_bot> <octachron> Indeed, you also inline ty to avoid the issue.

18:48 <d_bot> <Skilly> @octachron as in `%inline ty` is another option? or what does that mean?

18:50 <d_bot> <octachron> %inline ty is another option. There is a nice explanation in menhir manual but basically, the option inlines in place the "inline" rule, which provides more context to make shift and reduce decisions.

19:16 <d_bot> <Skilly> thank you!

20:54 <mrvn> Skilly: Most parsers only use one token lookahead. So the next token must be sufficient to pick up which rule to follow. Most parsers loosen that though, e.g. keep going till they have the longest match.

20:55 <mrvn> Makes things like "if <expr> then <statement>" and "if <expr> then <statement> else <statement>" possible.