<cemerick>
alas, same outcome w/ ocaml 4.12 (completely new switch), ocamllsp 1.7.0, vscode 1.8.4: No config found for file "main.ml" in ".". Try calling `dune build`.ocamllsp
<cemerick>
oh, and dune 2.9.0
<cemerick>
The only output for the language server is repeated "[Error - 8:31:34 PM] Locate failed. not in environment:..." messages
<rgrinberg>
can i see the project?
<cemerick>
rgrinberg: Just nailed it down. In the course of moving a bunch of stuff around, the dune-project file was left behind elsewhere. Once it was restored, lsp et al work as expected
<rgrinberg>
Yeah, that's a common issue. There's a mismatch between where the lsp expects the build directory to be and where it is actually located
<rgrinberg>
I'd like to come up with a better way to diagnose it
<cemerick>
none of my projects use dune-project for anything yet; everything continued to build just fine, so I assumed nothing was out of place
<d_bot>
<Anurag> companion_cube: neovim's built in lsp client + Ocamllsp has been an excellent combination in my experience. I'd definitely recommend trying it out!
<d_bot>
<darrenldl> didnt know neovim can do that huh
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<Anurag> The recently released 0.5 version has a built in lsp client
waleee has quit [Ping timeout: 240 seconds]
vicfred has joined #ocaml
rgrinberg has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
mmalter has quit [Remote host closed the connection]
<companion_cube>
Yeah I just moved to the built-in lsp because of deno
mbuf has joined #ocaml
<d_bot>
<salt rock lamp> Has anyone written a neovim rplugin with ocaml yet?
zebrag has quit [Quit: Konversation terminated!]
<cemerick>
prior to ppx_blob, how would one include the contents of a file in an OCaml executable?
<cemerick>
I assume the answer is cppo somehow, but the #include there seems to be only for .ml files
Skyfire has joined #ocaml
<rgrinberg>
We have an exmple of how to do it in dune. The gist of is to generate an .ml file with like foo = {unique_string| ... contents here .. |unique_string}
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
Haudegen has joined #ocaml
vicfred has quit [Quit: Leaving]
glassofethanol has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hendursa1 has joined #ocaml
olle has joined #ocaml
hendursaga has quit [Ping timeout: 276 seconds]
favonia has quit [Ping timeout: 240 seconds]
xd1le has quit [Quit: xd1le]
<Leonidas>
Anurag: Yeah, I've just "finished" setting it up. Unfortunately there's quite a lot of outdated mess information going around
kakadu has joined #ocaml
<companion_cube>
cemerick: a dune rule :)
<d_bot>
<undu> Grammar-based highlighting is also pretty nice (using tree-sitter)
<companion_cube>
Like rgrinberg said.
JSharp has quit []
JSharp has joined #ocaml
nojb has joined #ocaml
<cemerick>
zozozo: that looks super useful, thanks 😊
Haudegen has quit [Quit: Bin weg.]
nojb has quit [Remote host closed the connection]
<Leonidas>
undu: Does that work reliably?
<d_bot>
<undu> For ml files yes
<d_bot>
<undu> For mli files a tweak is needed in ocaml.vim
<d_bot>
<undu> It's not merge because it changes the vim filetypes, which can break users' configs
hackinghorn has joined #ocaml
bartholin has joined #ocaml
favonia has joined #ocaml
nojb has joined #ocaml
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #ocaml
nojb has quit [Remote host closed the connection]
nojb has joined #ocaml
nojb has quit [Remote host closed the connection]
nojb has joined #ocaml
nojb has quit [Remote host closed the connection]
nojb has joined #ocaml
nojb has quit [Remote host closed the connection]
nojb has joined #ocaml
nojb has quit [Remote host closed the connection]
nojb has joined #ocaml
nojb has quit [Remote host closed the connection]
waleee has joined #ocaml
Haudegen has joined #ocaml
hannes has quit [Ping timeout: 272 seconds]
hannes has joined #ocaml
Anarchos has joined #ocaml
waleee has quit [Ping timeout: 245 seconds]
waleee has joined #ocaml
waleee has quit [Quit: WeeChat 3.2]
waleee has joined #ocaml
Anarchos has quit [Quit: Vision[0.10.3]: i've been blurred!]
Tuplanolla has joined #ocaml
hackinghorn has quit [Quit: Leaving]
<companion_cube>
hum
<cemerick>
ironic that dune rules were mentioned yesterday;
<cemerick>
I have a simple rule that generates a .ml file, which then isn't being compiled, although the module it names is referred to by other sources
<cemerick>
what might cause that?
<mclovin>
let's say the file you generate is `m.ml`, did you add `m` to the `modules` list in your lib/executable stanza ?
<mclovin>
just using it in other .ml files isn't enough
rgrinberg has joined #ocaml
<companion_cube>
it should be enough
<companion_cube>
unless there's an ambiguity for ocamldeps
glassofethanol has quit [Quit: leaving]
<cemerick>
mclovin: thank you, I had an unnecessary `(modules Main)`; I removed it, and all's well
<cemerick>
companion_cube is right, no `modules` declaration is necessary, unless you declare a mix of libraries and executables in the same dune file
<cemerick>
it's interesting that such generated modules aren't visible to/included in `dune utop src`
<companion_cube>
really?
Haudegen has quit [Quit: Bin weg.]
<cemerick>
seems not, even if I do explicitly include the generated module name in a `modules` declaration for the library
<cemerick>
hardly a problem, but a little surprising
<companion_cube>
do you have a file with the same name as the library?
<companion_cube>
like `foo.ml`
<companion_cube>
for `(public_name foo)`
<cemerick>
you mean in the actual src dir? No
<d_bot>
<jco> Hi! Anyone got a working emacs lsp configuration to share?
<d_bot>
<jco> Last time I tried the lsp server was shown disconnected in the modeline.
def has left #ocaml [#ocaml]
<d_bot>
<RegularSpatula> I’ve been wondering about using the LSP in Emacs as well…is it nicer than the standard merlin/tuareg setup?
Boarders has quit []
Boarders has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bartholin has quit [Quit: Leaving]
mbuf has quit [Quit: Leaving]
Haudegen has joined #ocaml
<d_bot>
<monk> super random but is there a source that documents the history of the bactrian camel as the symbol/mascot
<d_bot>
<monk> the jump from O*Caml* to Camel is obvious, but i'm more interested in when/how that symbol was chosen
<d_bot>
<monk> surprisingly the best result i get is realworld ocaml's FAQ page that makes a random shout out to it with a comment differentiating ocaml from perl which is lost on me
<d_bot>
<jco> You mean why the choice of 'Caml'?
elf_fortrez has joined #ocaml
<d_bot>
<monk> no, why the use of the bactrian camel as OCaml's choice in logo/symbol!
<d_bot>
<monk> eg this server's discord icon
<d_bot>
<jco> kk
<d_bot>
<monk> to answer this question, though, i got it to work and it's fairly nice
<d_bot>
<monk> i don't use it normally yet, though, because merlin + tuareg is honestly very good
<d_bot>
<monk> though i wish merlin+tuareg had the same automatic linting/syntax checking, ie lsp ocaml will mark errors as you type them whereas merlin+tuareg needs you to compile the file first to catch some of them
<d_bot>
<monk> i only use ocaml lsp for the cs3110 material i am working through because they use that + ocamlformat
<d_bot>
<monk> here's the config i pulled from that somewhere, someplace
<d_bot>
<monk> ```e-lisp
<d_bot>
<monk> (use-package ocamlformat
<d_bot>
<monk> :load-path
<d_bot>
<monk> (lambda ()
<d_bot>
<monk> (concat
<d_bot>
<monk> ;; Never use "/" or "\" since this is not portable (opam-user-setup does this though)
<d_bot>
<monk> ;; Always use file-name-as-directory since this will append the correct separator if needed
<d_bot>
<monk> oh shoot, sorry for spamming code here i forgot that rule
<d_bot>
<RegularSpatula> You mean you’re getting some errors that don’t show up in the “jump to error”? But do when compiling?
<d_bot>
<monk> ... does discord not have emacs-lisp syntax highlighting? i tried e-lisp, emacs-lisp, and elisp and none worked
<d_bot>
<jco> Thanks @monk, I'll try that
<d_bot>
<monk> jco notice that i only have it enabled for a specific switch, just to be clear
<d_bot>
<jco> I come from vscode but I need emacs for other tools, so I thought I'd just totally switch to emacs
<d_bot>
<monk> so rename that to whatever you wish
<d_bot>
<RegularSpatula> jco: is there a reason you like the lsp better than merlin/Tuareg ? (Just curious)
wonko has joined #ocaml
wonko has quit [Changing host]
wonko has joined #ocaml
<d_bot>
<monk> so in the attempt to give an example of what i mean to regularspatula, i now realized that emacsclient doesn't pickup switch changes by default
<d_bot>
<monk> anyone know of a common solution to this
<d_bot>
<monk> to be clear, idk if this is limited to just emacsclient, i haven't tested with normal emacs
elf_fortrez has quit [Ping timeout: 256 seconds]
<d_bot>
<monk> ah ha! there's a function, `opam-update-env`
<d_bot>
<monk> hmm, unfortunate, it appears that didn't do what i expected
<d_bot>
<monk> wonder what i'm doing wrong lol
<d_bot>
<RegularSpatula> Normal Emacs I assume being not using the lsp? If so mine picks up the switch changes if I restart emacs after changing the switch. Can’t recall of the top of my head whether I had to tell it specifically to do that though ..
<d_bot>
<monk> so restarting is not ideal imo, but it looks like there is a way to change it
<d_bot>
<monk> i had to restart merlin and/or tuareg mode after also running `tuareg-opam-update-env` and/or `opam-update-env`.
<d_bot>
<monk> i don't know which did it
<d_bot>
<monk> but now it's doing what i expected
<d_bot>
<RegularSpatula> Oh nice, probably I’ll have to steal that trick and put it in a little elisp function at some point
<d_bot>
<monk> so as a trivial example, merlin-tuareg doesn't "automatically" catch syntax errors and patently incorrect code... until you save
<d_bot>
<monk> and picks up both errors, "expecting `in`..." and the fact fake_function is not declared somewhere
<d_bot>
<jco> I relied a lot on it to discover functions from a large codebasz
<d_bot>
<RegularSpatula> Ahh before saving. I thought you were having a problem of after the save, the error isn’t reported but it is when you compile it specifically
<d_bot>
<monk> yeah
<d_bot>
<monk> didn't describe it well
<d_bot>
<monk> yes, it should
<d_bot>
<jco> And can you jump to the définition of functions, modules,etc?
<d_bot>
<monk> the reason i don't use ocaml lsp regularly yet is that it's basically just a spiffier version of tuareg-merlin since tuareg-merlin is already fairly well tuned by a community that clearly uses emacs a lot
<d_bot>
<monk> i really like lsp mode but if given the chance for ~zero latency vs 1ms of latency where the former can do 90% of the latter, i take the former
<d_bot>
<monk> i don't do python anymore, but it's hard for me to imagine using lsp for it as another example
<d_bot>
<jco> So lsp is not worth the hassle?
<d_bot>
<monk> lsp with rust, on the other hand, is something very much different from any setup where you don't rely on lsp
<d_bot>
<monk> so even when i am hitting some really gross latency because a project has a lot of macro stuff happening, i deal with it
<d_bot>
<monk> i don't consider myself one of those latency obsessed people, either, btw. i just became more conscious of it after jumping from small little projects in rust using lsp to ocaml with tuareg-merlin
<d_bot>
<RegularSpatula> you can use `merlin-locate` for this
<d_bot>
<monk> jco i think the real thing is to not get caught up on editor ricing here
<d_bot>
<monk> both ocaml lsp and tuareg-merlin are good
<d_bot>
<monk> go with one and move on to the real issues
<d_bot>
<RegularSpatula> if you do go with tuareg-merlin, i recommend also using company mode to help with completions
<d_bot>
<monk> i haven't used ocaml lsp on a big code base (i don't touch any to begin with) so i don't know if it suddenly gets slow as compared to tuareg-merlin; to the degree i used it with small bits of code, it's fancier with no immediate drawbacks.
<d_bot>
<jco> I'm so used to the user friendliness of vscode ocamllabs extension: types above the définitions in a light grey color, types and documentation on hover, jump to definition with control+click
<d_bot>
<monk> you probably will get that with lsp, so if that's what you want, go with lsp
<d_bot>
<jco> That's what I need to switch to emacs
<d_bot>
<monk> lsp has all the small window drawing stuff where it'll show you a type sig or a function docstring
rgrinberg has joined #ocaml
<d_bot>
<monk> i think company-mode is mandatory no matter what, i think emacs `lsp` assumes its usage
<d_bot>
<monk> but yeah, you want to use company-mode
<d_bot>
<RegularSpatula> ah didn't realize...i don't use the lsp if you can tell lol
<d_bot>
<monk> if you use tuareg-merlin, there's actually a really nice opam package that does the work of setting it up for you
<d_bot>
<monk> as someone who doesn't consider themselves really familiar with elisp despite using emacs for years, i'm typically averse to using something that does a bunch of autoconfig for me, i want to at least know the code i'm sticking into my config and typically have issues otherwise
<d_bot>
<monk> but opam-user-setup seriously Just Works
<d_bot>
<monk> all i did was move the line it added into my `init.el` into my actual config file which uses org-mode
<d_bot>
<monk> if you're generally new to emacs, the change it makes to init.el is nothing to worry about
<d_bot>
<jco> Perfect! Many thanks monk
<d_bot>
<monk> np
wonko is now known as w7
w7 is now known as wonko
<d_bot>
<rgrinberg> the main difference is that it's considerably faster completion and reuses flymake/flycheck rather than its own error display mechanism
<d_bot>
<RegularSpatula> The LSP is faster?
<d_bot>
<rgrinberg> yeah
<d_bot>
<monk> really? dang
<d_bot>
<monk> exception to the rule maybe
<d_bot>
<rgrinberg> the lsp clients in emacs all use company mode's async completion
<d_bot>
<rgrinberg> so at least it feels a lot faster
<d_bot>
<monk> python lsp always felt slower
<d_bot>
<rgrinberg> are you using eglot?
<d_bot>
<monk> and rust lsp feels slower only because of the size of projects, code gen
<d_bot>
<monk> no, i use `lsp` proper
<d_bot>
<rgrinberg> eglot's a lot faster and less buggy in my experience
nojb has joined #ocaml
<d_bot>
<monk> i hear that, i just liked using a project that was more documented and used lol
<d_bot>
<monk> i haven't looked at eglot in like over a year tho so maybe that changed
<d_bot>
<rgrinberg> i couldn't stand lsp mode personally. it had really poor performance
<d_bot>
<monk> i consistently heard that back then, tho, that eglot was slimmer/faster
<d_bot>
<monk> hmm
<d_bot>
<monk> damn that would be such a big change to my config but i might have to revisit it
nojb has quit [Remote host closed the connection]
<d_bot>
<rgrinberg> i hear you. emacs is a constant waste of time
<d_bot>
<monk> hahahahaha
<d_bot>
<rgrinberg> if you only use emacs for ocaml then it's probably not worth the hassle. but if you program in other languages, it's worth it to use one consistent setup across languages
<d_bot>
<monk> this i do agree with
<d_bot>
<monk> which i guess is the dual to what i said earlier
wonko has quit [Remote host closed the connection]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
olle has quit [Ping timeout: 244 seconds]
kevinsjoberg has quit []
kevinsjoberg has joined #ocaml
olle has joined #ocaml
rgrinberg has quit [Ping timeout: 252 seconds]
mro has joined #ocaml
olle has quit [Ping timeout: 244 seconds]
gravicappa has quit [Ping timeout: 252 seconds]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
Serpent7776 has quit [Quit: leaving]
vb has joined #ocaml
mro has quit [Read error: Connection reset by peer]
mro has joined #ocaml
Everything has joined #ocaml
Guest71 has joined #ocaml
rgrinberg has joined #ocaml
mro has quit [Quit: Leaving...]
zebrag has joined #ocaml
Tuplanolla has quit [Quit: Leaving.]
Guest71 has quit [Ping timeout: 256 seconds]
<d_bot>
<leviroth> I tried to reinstall ctypes today and have been running into this error: `# ocamlfind: Conflict with another package: Library dllctypes_stubs.so is already installed`
<d_bot>
<leviroth> I'm not sure what all the relevant pieces are, for example I don't know if it matters that I'm installing via opam
<d_bot>
<leviroth> is there any obvious place I could check to see where ocamlfind thinks that this file is installed?
khoa has joined #ocaml
<d_bot>
<colin> `whereis` might work
<d_bot>
<colin> some Linux distros have a package for ocaml-cstubs, I wonder if that could cause conflicts
<d_bot>
<colin> not sure though, given that you can have a system level install of OCaml that becomes a virtual opam switch or whatever (?)
<d_bot>
<colin> really can't say if that'd be the reason for your issue
<d_bot>
<colin> whoops, meant ocaml-ctypes
<rgrinberg>
You can do opam list --owns-file=/path/to/dllctypes_stubs.so
Haudegen has quit [Ping timeout: 240 seconds]
<companion_cube>
Ocaml lsp worked for me rgrinberg
<d_bot>
<leviroth> I tried `whereis` but can't find it. I think `opam list` would work if I knew what the path was.
waleee has quit [Ping timeout: 252 seconds]
waleee has joined #ocaml
<d_bot>
<leviroth> I used plain old `find` in `~/.opam` and found a file at `$(opam var lib)/stublibs/dllctypes_stubs.so`. Deleted it and then the install worked.