xenu has quit [Read error: Connection reset by peer]
xenu has joined #ocaml
Haudegen has quit [Ping timeout: 256 seconds]
<d_bot>
<EduardoRFS> I'm working on an IR for JS that works with tail call optimization in general so it should work with CPS, the hope is to be able to add the trampoline only when the depth of the stack is not small and bounded
waleee has quit [Ping timeout: 250 seconds]
waleee has joined #ocaml
Tuplanolla has quit [Quit: Leaving.]
waleee has quit [Ping timeout: 256 seconds]
waleee has joined #ocaml
zebrag has quit [Quit: Konversation terminated!]
xd1le has joined #ocaml
x88x88x has joined #ocaml
rgrinberg has joined #ocaml
gravicappa has joined #ocaml
Haudegen has joined #ocaml
shawnw has quit [Ping timeout: 240 seconds]
jlrnick has joined #ocaml
shawnw has joined #ocaml
mbuf has joined #ocaml
gravicappa has quit [Ping timeout: 240 seconds]
jlrnick has quit [Remote host closed the connection]
perrierjouet has quit [Ping timeout: 268 seconds]
sagax has quit [Ping timeout: 260 seconds]
jlrnick has joined #ocaml
jlrnick has quit [Remote host closed the connection]
jlrnick has joined #ocaml
perrierjouet has joined #ocaml
chrisz has quit [Remote host closed the connection]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chrisz has joined #ocaml
Tuplanolla has joined #ocaml
mro has joined #ocaml
<d_bot>
<orbitz> Has anyone thought about a way to unify all the `with_*` patterns in various libraries and make them composable? And would anyone adopt it?
<d_bot>
<orbitz> One way to do it would be an applicative interface: `With.((fun io -> output_string io "hi") <$> with_in "somefile")`
bartholin has joined #ocaml
<d_bot>
<orbitz> But maybe the closure overhead is unpleasant?
<d_bot>
<Continuation Calculus> hi
<d_bot>
<Continuation Calculus> does anyone have any example of usage of ephemerons?
<d_bot>
<Continuation Calculus> just trying to add some metadata to fragments of AST without changing its type
<d_bot>
<Continuation Calculus> does this assume that there is already a way to index data? I thought ephemerons would be built on top of pointers
<d_bot>
<hhugo> I don't understand your question
<d_bot>
<Continuation Calculus> I have a type t, I want to create a table of `t -> metadata`. I want this table to be indexed with OCaml pointers, rather than through a `compare : t -> t -> int` or a `hash : t -> int`
mro has quit [Remote host closed the connection]
<d_bot>
<hhugo> Do you really need Ephemerons ? Isn't weak enough for your usecase ? Anyway, Weak.Make / Ephemeron.K1.Make should do what you want
<d_bot>
<Continuation Calculus> ooh, I only saw `Ephemeron.K!` and I was like "but a single value -> data isn't that useful", hahaha
<d_bot>
<Continuation Calculus> I'll try it thx
<d_bot>
<Continuation Calculus> Given that things get removed whenever the matched key is GC'd, there is no downside to making a `Ephemeron.K1.Make(...).t` a global reference, right?
sagax has joined #ocaml
xiongxin has joined #ocaml
chrisz has quit [Ping timeout: 260 seconds]
chrisz has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
cedric has joined #ocaml
xiongxin has quit [Remote host closed the connection]
xiongxin1 has joined #ocaml
xiongxin1 is now known as xiongxin
<d_bot>
<VPhantom> Here's an odd one: anyone know why type `Bigarray.kind` is a GADT instead of a regular variant? Since it's just used as a kind selection flag I don't see the benefit.
<d_bot>
<VPhantom> (IRC users: I deleted my previous message. It's to restrict the combinations to a valid subset.)
cedric has quit [Quit: Konversation terminated!]
Anarchos has joined #ocaml
<Anarchos>
i am looking for examples of color in logs (within framework Logs of dbünzli), but in the text message, not in the header.
mro has joined #ocaml
gravicappa has quit [Ping timeout: 256 seconds]
spip has joined #ocaml
spip is now known as Guest6754
shawnw has quit [Remote host closed the connection]
mro has quit [Remote host closed the connection]
Guest6754 has quit [Quit: Konversation terminated!]
<companion_cube>
@orbitz I'm not convinced it'd be a progress
spip has joined #ocaml
spip is now known as Guest7910
xiongxin has quit [Quit: xiongxin]
Haudegen has joined #ocaml
<d_bot>
<orbitz> @companion_cube Why so?
<d_bot>
<orbitz> I find implementing `with_*` functions annoying and I find mixing and matching them, especially with monad code, the pits
<d_bot>
<orbitz> The pits, I say!
<companion_cube>
heh
<companion_cube>
don't use monads ;) ;)
<d_bot>
<orbitz> Ha or I could just get my monad `withs` for free
<companion_cube>
more seriously, sounds like the problem is mixing monads and other effects
<companion_cube>
lwt has some `with` functions
<companion_cube>
they work well
<d_bot>
<orbitz> I don't think the problem is actually moandic, for example I may want to do : `CCWith.(fun inp outp -> let x = readline inp in output_string outp x) <$> open_in somethign <*> open_out somethign)`
<companion_cube>
ah, so a `_ t` that is basically resource tracking?
<d_bot>
<orbitz> yes
<companion_cube>
('a -> unit) * (unit->unit) I guess
<d_bot>
<orbitz> that is what all the ad-hoc with stuff is?
<companion_cube>
the ad-hoc stuff is not reifying anything, it's just very concrete functions
<d_bot>
<orbitz> I'm not sure what you mean in terms of what I'm saying by that. I'm just presenting a structure for doing with that isn't ad-hoc
* qwr
thinks that the algebralic effects should remove some need for monads by providing another way for managing the control flow
<companion_cube>
I don't know if I want a non ad-hoc thing, I don't think it brings much to the table
<d_bot>
<orbitz> I think the functions would have a type `('a * ('a -> unit))` and the runner (in this case applicative) would call the cleanup function when unwinding
<d_bot>
<orbitz> The upside is implementors don't have to care about all the ways things can fail and what to do, they just need to know how to make the thing and clean the thing up
<d_bot>
<orbitz> And you could functorize it over a monadic interface as well
<companion_cube>
not sure how, the cleanup would have to be tied to a given monad anyway (or no monad)
x88x88x has quit [Ping timeout: 240 seconds]
<d_bot>
<orbitz> Are you saying you don't see how a this could be useful or just whether it could be functorized over a particular monadic interface?
<companion_cube>
I don't see how it can be functorized over monads
<companion_cube>
and without that, I still don't see it being really better than ad-hoc functions :)
x88x88x has joined #ocaml
<d_bot>
<orbitz> To be clear, I'm not saying the same piece of code could be, but that the `CCWith` interface could be, so you could easily make versiosn of it for different monadic interfaces
<d_bot>
<orbitz> So you'd have like `CCWith_lwt`
mro has joined #ocaml
<d_bot>
<Continuation Calculus> About `Ephemeron.K1.Make`, I have to pass in both a `hash : t -> int` and an `equal : t -> t -> bool`. Which one is finer than the others? As in, does `hash a = hash b -> equal a b`, `equal a b -> hash a = hash b`, or `equal a b <-> hash a b`?
<d_bot>
<orbitz> What value do you believe the ad-hoc functions have? I find this view surprising as what i'm proposing is pretty common in a number of languages (`with` in Python, `using` in C#, RIAA in C++, Java has something similar). It seems to me that most `with_*` functions are doing the exact same thing in terms of policy, it's just different based on resource, but perhaps I'm incorrect.
<d_bot>
<VPhantom> Those are the relevant bits of a slightly fancier file which has generic, Unix and Lwt implementations.
<d_bot>
<orbitz> ohhh fancy
<companion_cube>
well, all of these languages have custom features for that, @orbitz
<companion_cube>
we don't
<companion_cube>
the ad-hoc functions are the simplest approximation we have
<companion_cube>
(I'd love to have a `using` version of let, like F#, but well)
<d_bot>
<orbitz> @companion_cube We don't need custom language features for that
<d_bot>
<VPhantom> I'm pretty happy with how my little `let&` turned out. The toughest part was getting the Lwt version behaving as intended. I know those automatic "finally" are frowned upon in some circles but they greatly simplify my day to day needs.
<companion_cube>
I think we do need a language feature to make it clean
<d_bot>
<orbitz> @companion_cube So is your push back because you believe unifying resource management doesn't add value or because you believe the only way it could add value is by modifying the Ocaml?
<companion_cube>
I think it'd be good if OCaml had a feature to support it (a special kind of `let`) but even that is not clearly defined
<Corbin>
It sounds like regardless of the value added, it requires redesigning part of the language.
<companion_cube>
we don't have "disposable" or anything like that
<companion_cube>
and I don't believe it can be unified much without language support
<Corbin>
Resource-management syntax only makes sense in the presence of resources. The languages you mentioned (Python, C♯, C++, Java) all primarily use it for memory and atomic/exclusive access; OCaml abstracts memory, removing the biggest motivation.
<d_bot>
<orbitz> What is missing in @VPhantom 's implementation?
<companion_cube>
nothing particular, it's tied to a specified monad is all
<Corbin>
(Also, what would be cleaned up? e.g. Python only cleans up exception-handling state. In e.g. Haskell, the same cleanup is done with ordinary functions, and it isn't a problem.)
<companion_cube>
I can do the same with `let@` and regular ('a -> 'b) -> 'b with_ functions
<d_bot>
<orbitz> That is not true in my experience, generally i use `with` in Python for managing anything that needs to be cleaned up ,liek files, temporary dirs, all the same stuff I see `with_*` used in Ocaml for
<companion_cube>
it's just not much better than `with_foo @@ fun foo ->\n…`
<companion_cube>
python has objects with a cleanup method
<companion_cube>
OCaml resources often are not objects
<d_bot>
<orbitz> They do not need to be
<companion_cube>
(and ofc python has a special construct)
<companion_cube>
there's nothing on a `in_channel` that tells you how to clean it up
<d_bot>
<orbitz> Nor does there need to be
<d_bot>
<orbitz> I proposed the create function would return the object + cleanup
<Corbin>
It sounds strange, but from a language-design point, Python `with` is about memory. Like, `with open(...):` is mostly about reducing GC and FD pressure; the file object will eventually get cleaned up either way, and the cleanup is not because of `with` but because of GC finalizers on file objects.
<d_bot>
<orbitz> `('a * ('a -> unit))`
<companion_cube>
Corbin: with is about… resources?
<d_bot>
<orbitz> No, `with` gurantees your file is closed by the end of the block
<companion_cube>
FDs are not memory
<companion_cube>
and the cleanup is definitely because of with
<Corbin>
The FD might not actually get closed. All that's guaranteed is that Python will forget about the FD and release any associated memory. But I see your point.
<d_bot>
<VPhantom> The main point in my case was indeed to guarantee that a resource will be freed.
<d_bot>
<orbitz> No, `with` guarantees it is closed
<companion_cube>
Corbin: wrong
<d_bot>
<orbitz> Just as in `with tempfile.TemporaryDirectory() as dname: ..` it gurantees the tempdir is cleaned up at the end
<d_bot>
<orbitz> @VPhantom Thanks for sharing your implementatino
<d_bot>
<VPhantom> Yeah `with` and the `contextmanager` to create our own contexts was the main positive remember from my stint with Python a couple years ago. Very clean.
<d_bot>
<VPhantom> Thanks @mmatalka. I'd share the whole thing but it hasn't been tested much yet. Let me know if you need the Lwt equivalent though, it was a bit of a pain to get right.
<companion_cube>
Corbin: seriously?
<d_bot>
<octachron> @Continuation Calculus : the `hash` part is used to reduce the number of calls to `equal` (to avoid an O(n) lookup). Thus `equal` should be finer than `hash` `(equal x y ⇒ hash x = hash y)` (and `let hash _ = 0` is always valid and inefficient).
<Corbin>
I grok and agree with y'all about the *intent* of `with` and similar tools in various languages. What I'm trying to emphasize is how the actual implementation details are worked out; "resource" ends up being a very limited thing.
<companion_cube>
that's the most braindead thing I've seen in a while
<companion_cube>
why not close the FD
<d_bot>
<VPhantom> huh
<companion_cube>
Corbin: TIL cpython is even worse than I thought
<Corbin>
If you read the following procedures (and it's hard to do, so don't force yourself!) then you'll see how the GC provokes the IO object to finish cleaning itself up, "closing" and then closing for real.
<companion_cube>
yeah it's super ugly
<companion_cube>
but I don't understand why they do that?
<d_bot>
<Continuation Calculus> so ppx_hash would defeat the purpose right?
<d_bot>
<octachron> O(n) in the number of elements in the table at the time of the lookup. `ppx_hash` will allow you to derive hopefully good hashing function rather than the terrible `hash _ = 0` one.
<Corbin>
No worries. I'm not saying that Python is wrong. I'm saying that the conception of what resource-management syntax does is too wide, given what actually ends up being implemented.
<d_bot>
<orbitz> But I agree with you @companion_cube , even if Python is doign th wrong thing for fd's, the semantics of its `with` feature are clear about when it executes the resource cleanup for a context manager
<companion_cube>
Corbin: I'm saying python is wrong
<d_bot>
<orbitz> Although I believe Python does the correct thing for files, as can be seen in the lnes I linked to
gravicappa has joined #ocaml
<d_bot>
<octachron> (with an ideal hashing function distributing all keys uniformly across any integer range)
<companion_cube>
ahhh
<companion_cube>
it's overloaded?
xd1le has quit [Quit: xd1le]
<d_bot>
<orbitz> Yes
<companion_cube>
@octachron which ppx_hash are we talking about?
<Corbin>
companion_cube: Python just implements `with` in terms of existing syntax. I'm not sure if this is always possible, but it provokes examining an assumption: could we just implement resource management with ordinary library code?
<companion_cube>
err, no
<companion_cube>
`with` is a special form of python
<Corbin>
Anytime you `with r() as h: f(h)` you can `h = r(); h.__enter__(); try: f(h);; except e: h.__exit__(e);; else: h.__exit__()`
<d_bot>
<Continuation Calculus> yup, this is the one i had in mind
<Corbin>
Or something like that. This sort of thing was crucial to getting `with` into RPython, where it's gotta be statically typeable.
<Corbin>
My point, if I have one, is: resource management can be implemented as a library with no language changes iff this sort of desugaring is possible. The proof in both directions is in the pudding; just write the library.
<companion_cube>
ah you mean `with` rewrites to another form internally?
<companion_cube>
that doesn't matter, it's still special syntax
<d_bot>
<VPhantom> Yeah mine is based around `try` and `Fun.protect`.
<companion_cube>
we can arleady do that, it's the with_ functions mentioned above; it's just not ergonomic
<Corbin>
Sure. And in languages that don't allow users to add new syntax, or that don't allow making new barewords that act like keywords, this could be a problem.
<d_bot>
<VPhantom> Wait, OCaml allows creating new barewords that act like keywords?
<Corbin>
Functions starting with "with_" in their names don't have anything in common, other than the name, right? You'd have to give them some common feature if you wanted to isolate them.
<d_bot>
<Continuation Calculus> unrelated question: in iso-recursivity, `unfold (x : mu v . body) : body[v := mu v . body]` simply requires a substitution/unfolding. but how do you implement `fold` ?? In `fold (mu v . body) (x : t[v := mu v . body]) : mu v . t`, to inverse the substitution, you have to like pattern match the whole type `t` to find instances of `mu v . body`, is that correct?
<d_bot>
<orbitz> "with_" functions almost always create and destroy a resource
<Corbin>
VPhantom: OCaml is one of many languages where a bare identifier surrounded by whitespace can act as an operator. Ruby's another, but through a totally different mechanism.
<d_bot>
<VPhantom> I didn't know other strings besides "mod" had that potential.
<Corbin>
Maybe "can act as" is ambiguous. I'm not talking about magic syntax; I'm just saying that `f x` is one bareword somehow applied to another with whitespace, so you could pick creative names like `with resource`.
<d_bot>
<VPhantom> Oh. Or possibly `with @@ resource ...` in a more realistic context. It's already a little bit less ergonomic.
<companion_cube>
`with_resource @@ fun resource -> …` is my go-to
<companion_cube>
we don't have particularly lightweight function syntax
<companion_cube>
unlike ruby or kotlin, say
<d_bot>
<VPhantom> I considered doing that, but then the let syntax is so nice...
<d_bot>
<VPhantom> The wrapper just melts away.
<companion_cube>
with @@ it does, too
<companion_cube>
it doesn't indent more
<companion_cube>
sometimes I have 3 or 4 `foobar @@ fun () ->\n` in a row :D
<d_bot>
<VPhantom> Sure, but I find `let& fd = with_file ... in` more ergonomic than the `@@` equivalent. It conveys the intention more obviously to me.
<d_bot>
<VPhantom> I do use my little exception trap `catch @@ fun () ->` though in a few places.
<companion_cube>
fun stuff: `let (let@) f x = f x;;`
<companion_cube>
`let@ fd = CCIO.with_in "file" in CCIO.read_all fd`
<d_bot>
<VPhantom> (I use `Result.t` all over, including its binding and thus I trap exceptions into results.)
<companion_cube>
that works :D
<companion_cube>
I've tried, and now I do the opposite (in my own side project, note): exceptions everywhere
<d_bot>
<VPhantom> Yeah but that "with" doesn't have the associated resource freeing.
<companion_cube>
but with an exception type that emulates traces a bit
<companion_cube>
CCIO.with_in does the freeing :)
<companion_cube>
it's just sugar for `CCIO.with_in "file" (fun fd -> CCIO.read_all fd)`
<d_bot>
<VPhantom> I kinda took Jane Street's lead re: exceptions. Meshes better with Lwt for me anyway.
<d_bot>
<VPhantom> Nice.
<companion_cube>
lwt kind of meshes well with exceptions actually
<companion_cube>
`try%lwt` and all that
<d_bot>
<VPhantom> I hadn't thought of using a let binding for partial application like that. Very creative.
<companion_cube>
it's stolen from an old discuss post of gasche
<companion_cube>
but it does make a lot of sense
<d_bot>
<VPhantom> Yeah I avoid "try" so far. Since my "business logic" stuff returns results, I just want a surprise exception to make my function return early with an error result. With Multicore I might do a 180° and end up with exceptions everywhere, but so far that's what I do.
<companion_cube>
I use exceptions but barely any `try`, I guess
<companion_cube>
in a context where most exceptions trickly down to the root and are logged/displayed/accumulated, I mean.
<companion_cube>
well for a start, it seems that now it wants 3 files, not one
<companion_cube>
(in this case I provide twice the same… err)
<companion_cube>
like dllfoo_stubs.so, libfoo_stubs.a, and libfoo.a
<companion_cube>
sth like that
<rgrinberg>
I haven't used that plugin, so I'm really not sure what's the problem. Perhaps you didn't run vscode in your opam environment?
<rgrinberg>
companion_cube which one of those targets do you have a problem which building?
<d_bot>
<minimario> is there a better plugin lol
<rgrinberg>
s/which/with/
<d_bot>
<Et7f3> Ocaml platform
<rgrinberg>
better is in the eye of the beholder, but there's a better maintained one for sure
<companion_cube>
well I only get stubs.a and stubs.o
<companion_cube>
there is no libfoo.a
<d_bot>
<minimario> dunno, as long as it works and type checks i'll be happy
<d_bot>
<minimario> but it's not working 😨
<rgrinberg>
give the other plugin a try then
rgrinberg has quit [Read error: Connection reset by peer]
<d_bot>
<minimario> hmm doesn't seem to work either
rgrinberg has joined #ocaml
<rgrinberg>
companion_cube how do I get target/release?
<d_bot>
<minimario> ocamllsp is still saying async is unbound 🤔
<rgrinberg>
did you build your project?
<companion_cube>
make build-rust-stubs
<rgrinberg>
did you select the correct sandbox?
<companion_cube>
(also called by opam)
<companion_cube>
iirc I tried to have dune build it, and it was just too hard
<d_bot>
<minimario> sandbox?
<companion_cube>
have to call cargo --frozen or whatever, from a different directory, etc. a whole mess.
<rgrinberg>
Yes, you must select a sandbox. Otherwise the editor doesn't know where your libraries are installed. You can do so with the "OCaml: Select a Sandbox for This Workspace" command.
<rgrinberg>
companion_cube i'm getting a lot of errors trying to build with cargo
<rgrinberg>
lots of missing symbols errors
<rgrinberg>
in particular missing symbols that should be provided by OCaml's runtime.
<d_bot>
<minimario> choosing a sandbox did not fix the problem 😦
<d_bot>
<minimario> i can "open Core" perfectly but can't "open Async"
<rgrinberg>
I suppose this is the culprit: ld: warning: directory not found for option '-L/Users/rgrinberg/.opam/4.13/lib/ocaml\x1f-lcamlrun
<rgrinberg>
minimario, for editor support to work, the following conditions must be satisfied:
<companion_cube>
rgrinberg: ugh
<rgrinberg>
1) you must run ocamllsp in the correct sandbox
<rgrinberg>
2) you must successfully build the project with dune
<companion_cube>
what's your OS?
<rgrinberg>
macos
<companion_cube>
hmm, Matt did a PR for that… that's unfortunate
<companion_cube>
the whole build_rust.sh should try to find OCaml properly, and CI does it :/
<d_bot>
<Et7f3> was is thatâ€: (encoding issue)
<d_bot>
<Et7f3> What is*
<d_bot>
<Et7f3> A smiley ?
<d_bot>
<minimario> 2) is certainly done, i'm not sure how to check for 1)?
<rgrinberg>
select the correct sandbox in your editor and then restart the lsp server
<d_bot>
<minimario> ocaml: restart language server?
<rgrinberg>
There are separate commands for both of those actions
<rgrinberg>
That's right
<d_bot>
<minimario> hmm i tried this and it still did not work
<rgrinberg>
which version of ocamllsp and dune are you using?
<d_bot>
<minimario> ocamllsp 1.4.1 and dune 2.9.1
<rgrinberg>
you should upgrade to a recent version of ocamllsp
<d_bot>
<minimario> what's the command for that?
<rgrinberg>
how did you install ocamllsp in the first place?
<d_bot>
<minimario> opam install ocaml-lsp-server i think
<rgrinberg>
Okay, then you need opam update && opam upgrade ocaml-lsp-server
<rgrinberg>
companion_cube hard to help without building the project, but what archive files does the cargo build produce?
<companion_cube>
gives me just libbatsat_stubs.a and libbatsat_stubs.so
<companion_cube>
(both pretty big)
<companion_cube>
it uses ocaml-rs to do the stubs…
<companion_cube>
but really it seems to not work well on macOS, each person has a different build error :/ :/
<rgrinberg>
Okay, then shouldn't you just copy those .a and .so files to your library's dir?
<companion_cube>
yeah that's what I do
<companion_cube>
but I'm annoyed that dune asks me for a third file that doesn't exist
<companion_cube>
and it's not documented how foreign_archives works :/
<rgrinberg>
companion_cube well you're copying an .a file when dune expects an .so, no?
<companion_cube>
it works this way
<rgrinberg>
In particular, how is this supposed to work? (run cp %{lib} dllbatsat_stubs%{ext_lib})
<companion_cube>
I tried with %{ext_dll} but that's also buggy on macOS (wrong extension)
<companion_cube>
it probably won't work with dynamic linking, idk.
<companion_cube>
and I don't care too much, cf `(no_dynlink)`
<rgrinberg>
yes, that's an upstream bug :) they refuse to change to dylib for mac shared libs
<companion_cube>
ah, seems like it still compiles if I remove the dll stuff
<companion_cube>
otoh I have to do this `liblibbatsat.a` when the stubs already contain all I need
<rgrinberg>
use an empty archive then?
<companion_cube>
I tried
<companion_cube>
but couldn't find a way to make that work on macOS
<companion_cube>
look at the commit history
<companion_cube>
`ar rcs foo.a` fails on macOS (not on linux) because it wants at least one file
<companion_cube>
that's kind of exhausting
<rgrinberg>
so what's wrong with having a dummy source?
<rgrinberg>
like you did earlier
<companion_cube>
linking fails :/
<companion_cube>
I honestly don't understand how all that works
<companion_cube>
on master it worked nicely :/
<companion_cube>
(with dune 1.6?)
<rgrinberg>
how does the linking fail?
<companion_cube>
lots of undefiend reference
<companion_cube>
anyway, works for me again, but if it doesn't on your macOS, the problem is not solved :(
<rgrinberg>
well i can't even get far enough to see the error since I can't build the crate
<companion_cube>
the stubs, you mean, right?
<rgrinberg>
yes, ./build_rust.sh doesn't work for me
<companion_cube>
that's really a problem
<companion_cube>
I wonder if it's a macOS version
<d_bot>
<Et7f3> `SEP="`echo -e '\x1f'`";` or `SEP=$'\x1f'` if you don't care of sh
<companion_cube>
might end up scripting it with OCaml…
<rgrinberg>
yes, it seems to be this pesky separator
<rgrinberg>
it's no being interpreted correctly
mro has joined #ocaml
<companion_cube>
what rust version do you have?
<d_bot>
<Et7f3> Shouldn't be related to cargo but just shell isue
<companion_cube>
unless cargo doesn't interpret the variable properly
<d_bot>
<Et7f3> And wtf if you wan't sh just use #!/bin/sh
<d_bot>
<Et7f3> Why does darwin need those special flag ?
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<companion_cube>
@Et7f3 I'm not sure…
<d_bot>
<minimario> after upgrading i am now getting ```/home/minimario/.opam/4.13.1/lib/textwrap/wrapper.cmi seems to be compiled with a version of OCaml that is not supported by Merlin.ocamllsp```
<d_bot>
<NULL> Watch out when you're entering messages with multiple lines, it spams IRC users (or that's what happens when IRC users do so)
<d_bot>
<minimario> oh oops
<d_bot>
<NULL> that's what happens here*
<d_bot>
<NULL> A `dune clean && dune build` should solve this
<d_bot>
<NULL> If you're using a single switch, choosing the sandbox is useless BTW
<d_bot>
<NULL> Wait, I only read the message: why does it point out a file in the switch ?
<d_bot>
<minimario> dune clean && dune build did not solve this
<d_bot>
<minimario> sad
<d_bot>
<NULL> Yeah no, seeing where the error comes from this wouldn't change anything. That's just very weird to me
<d_bot>
<NULL> What's your version of ocaml and ocaml-lsp-server ?
<d_bot>
<minimario> 4.13.1 and 1.9.1
<d_bot>
<NULL> `opam reinstall textwrap` maybe ?
<d_bot>
<minimario> oh i restarted my computer and it worked lmao
<d_bot>
<minimario> 🤔
<d_bot>
<Ulugbek> After upgrading what specifically? The message seems to say that you compiled the project with a compiler version different than the merlin is compiled with. (I’ll try documenting this in ocamllsp docs)
<d_bot>
<minimario> i ran "opam update && opam upgrade ocaml-lsp-server"
<d_bot>
<minimario> and then restarted vscode
<d_bot>
<NULL> Did it upgrade OCaml and not recompile that package ?
<d_bot>
<minimario> no idea what it did
<d_bot>
<minimario> hmm
<d_bot>
<minimario> i don't think it upgraded ocaml actually
<d_bot>
<minimario> only ocaml-lsp-server
<d_bot>
<minimario> from 4.1 to 4.9
<d_bot>
<NULL> You mean from `1.4.1` to `1.9.1` ?
<d_bot>
<minimario> yes haha my bad
<d_bot>
<Ulugbek> 1.4.1 is compatible with ocaml 4.12, while 1.9.1 is compatible with ocaml 4.13.x, so the compiler version must have changed
<d_bot>
<Ulugbek> Hence the problem
<d_bot>
<minimario> ah ok
<d_bot>
<minimario> that makes sense
<d_bot>
<NULL> The problem is why that package wasn't recompiled then
<d_bot>
<minimario> are lwt and async essentially different libraries providing similar functionality
mro has quit [Quit: Leaving...]
<d_bot>
<NULL> I can sorta reproduce the problem : with switches `a` (OCaml 4.13.1, ocaml-lsp-server 1.9.1) and `b` (OCaml 4.11.1, ocaml-lsp-server 1.4.1), sandbox set to switch a but global switch b, the LSP complains that switch b's Stdlib was compiled with 4.11 (and expects 4.13)
<d_bot>
<NULL> That's because the project is built with OCaml 4.11 where LSP expects 4.13; the problem is only that it's the Stdlib being wrongfully flagged as the wrong version
<d_bot>
<rgrinberg> Now I don’t remember if the lsp server is restated when the sandbox is switched.
<d_bot>
<rgrinberg> If it’s not, it probably should be
<d_bot>
<NULL> I don't know either but that's not the problem
<d_bot>
<NULL> It would be if switch a and b were swapped