<d_bot>
<Manas (prometheansacrifice)> The duniverse fork fails because `cudf` submodule doesn't resolve. But the upstream package fails too (even the distribution tarball)
<d_bot>
<copy> @Manas (prometheansacrifice) That's probably due to the recent ocamlgraph update. Try `opam install ocamlgraph=1.8.8`
<d_bot>
<Manas (prometheansacrifice)> Build didn't pass, but sounds relevant to my problem. What;s the recent update at ocamlgraph?
dckc has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
amiloradovsky has quit [Ping timeout: 240 seconds]
<d_bot>
<copy> I don't know the details, but it has been upgraded to 2.0, which may have some breaking changes
<d_bot>
<rgrinberg> @Manas (prometheansacrifice) how does esy use opam's solver again?
<d_bot>
<Manas (prometheansacrifice)> @rgrinberg I'm not sure I understand your question - could you be a little more specific?
<d_bot>
<Manas (prometheansacrifice)> Are you asking if there are any patches we make to dose3?
<d_bot>
<Manas (prometheansacrifice)> We dont
<d_bot>
<Manas (prometheansacrifice)> For the past few days dose3 fails to build in our builds
jgjl has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<d_bot>
<rgrinberg> Nvm, for a minute I thought that dose3 was a kind of solver.
<d_bot>
<rgrinberg> > For the past few days dose3 fails to build in our builds
<d_bot>
<rgrinberg> @Manas (prometheansacrifice) I'll try to help out though. As far as I know, opam is only tested against the versions of libraries defined in `Makefile.sources`. Are you sure you're using these versions of dose/ocamlgraph, etc?
narimiran has joined #ocaml
<d_bot>
<Manas (prometheansacrifice)> Yes, dose3 is being resolved as opam-repository informs
<d_bot>
<Manas (prometheansacrifice)> @rgrinberg What is Makefile.sources?
<d_bot>
<rgrinberg> just some hacky thing used in opam to bootstrap the dependencies
<d_bot>
<Manas (prometheansacrifice)> I see
<d_bot>
<Manas (prometheansacrifice)> A way to build opam without any package manager - got it
<d_bot>
<rgrinberg> Using duniverse repo's forks on top of the versions here should work.
<d_bot>
<rgrinberg> A bit of a shame all of this cudf machinery is even necessary. As far as I understand, it's to explain the the solver's solutions to the user.
<d_bot>
<Manas (prometheansacrifice)> @rgrinberg the duniverse fork got rid of the submodules altogether since the submodule is unreachable and it still wouldn't work - opam logs would say `git submodule` failed
<d_bot>
<Manas (prometheansacrifice)> I would prefer using the duniverse fork actually
<d_bot>
<rgrinberg> Lol. Well that's a shame.
<d_bot>
<Manas (prometheansacrifice)> cc @EduardoRFS since you need this too
<d_bot>
<Manas (prometheansacrifice)> Eduardo, were you using duniverse-5.0.1 branch of dose3 from the fork too?
<d_bot>
<EduardoRFS> I think so
<d_bot>
<EduardoRFS> but I was also using the cudf from dune
Serpent7776 has joined #ocaml
<d_bot>
<EduardoRFS> just added the resolutions pointing to the right package
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
yomimono has joined #ocaml
bartholin has joined #ocaml
jbrown has joined #ocaml
musogre has joined #ocaml
musogre has quit [Remote host closed the connection]
bartholin has quit [Quit: Leaving]
reynir has quit [Ping timeout: 260 seconds]
reynir has joined #ocaml
sm2n has quit [Quit: Leaving]
narimiran has quit [Quit: leaving]
sm2n has joined #ocaml
dhil has joined #ocaml
narimiran has joined #ocaml
yomimono has quit [Ping timeout: 264 seconds]
<d_bot>
<gar> Question about linking deps. From inspection of verbose output of dune builds, it looks like dune always(?) adds the directories of deps using `-I`, and sometimes it adds the dep file (*.cmx, *.cmxa) as well. My question is: to build a compile command using `ocamlfind`, not dune, is it sufficient to add just the file and omit the `-I`? From experimenting that seems to be the case, at least sometimes. But then the question becomes
<d_bot>
<ostera> afaict it'll look for all the relevant files in any of the -I dirs, including the dir the target file is on
<d_bot>
<ostera> if you're building the entire world at once, then you should be able to omit `-I`
<d_bot>
<ostera> but that means you are feeding the compiler _all of the sources you need_
Haudegen has quit [Quit: Bin weg.]
<d_bot>
<gar> Right, if I list all the dep files explicitly, then it does not need the search path. In principle that would be a little faster, no?
djellemah has joined #ocaml
<d_bot>
<ostera> i think the search path implies you already compiled what's in there
<d_bot>
<ostera> so it'd save you the time of compiling that again
<d_bot>
<octachron> All transitive cmi dependencies needs to be in the include paths when compiling
<d_bot>
<gar> What about mli files? The manual says the compiler looks for mli files to decide whether to look for cmi files. Does that include dependencies?
<d_bot>
<octachron> No, mli are only looked upon when compiling a %.ml file to see if there is a matching %.mli file. Mli file are not used once the corresponding compilation unit have been compiled.
Haudegen has joined #ocaml
Anarchos has joined #ocaml
Anarchos has quit [Quit: Vision[0.10.3]: i've been blurred!]
<d_bot>
<gar> File "bazel-out/darwin-fastbuild/bin/src/lib/ppx_register_event/Ppx_register_event__Register_event.ml", line 8, characters 13-43:
<d_bot>
<gar> Error: Unbound module Logproc_lib
<d_bot>
<gar> ```
<companion_cube>
ugh, @bluddy we really need to enforce some limit on the size of pastes here :(
<d_bot>
<octachron> Why surprisingly? The cmi file is needed.
<d_bot>
<gar> But if I add the `-I bazel-out/darwin-fastbuild/bin/src/lib/logproc_lib` and omit the cmx files it works
<d_bot>
<octachron> The cmx is needed for linking and intermodule optimization with flambda
<d_bot>
<gar> Oh right, that pesky cmi file. Surprising to an OCaml newbie, I should add.
<d_bot>
<octachron> If you are a newbie, it is highly advised to use dune.
<d_bot>
<gar> I'm writing Bazel rules. Learning from Dune, though.
<d_bot>
<gar> The cmi deps are effectively hidden deps. Nothing in the manual suggests (to me at least) that they are the key element to linking.
<d_bot>
<gar> Thanks for clarifying.
<d_bot>
<octachron> They are the key elements to compiling not linking.
<d_bot>
<gar> RIght, good point esp. for newcomers.
narimiran has quit [Ping timeout: 256 seconds]
osa1 has quit [Remote host closed the connection]
wingsorc has joined #ocaml
jnavila has joined #ocaml
ksft has quit [Read error: Connection reset by peer]
jnavila_ has joined #ocaml
jnavila has quit [Ping timeout: 256 seconds]
larou has joined #ocaml
dhil has quit [Ping timeout: 240 seconds]
berberman_ has joined #ocaml
berberman has quit [Ping timeout: 272 seconds]
<d_bot>
<Bluddy> companion_cube: I posted an issue on matterbridge. Long messages are truncated but the newlines in code blocks cause each line to seem like a new message. Irccloud knows how to handle it and turn it into a code block, but most IRC clients don't. In any case, they've labeled it as an enhancement but I don't know when they'll work on it.
dhil has joined #ocaml
<companion_cube>
do they really receive the message as a series of line? not just a string with ``` and \n in it?