rgrinberg has quit [Read error: Connection reset by peer]
rgrinberg has joined #ocaml
Tuplanolla has quit [Quit: Leaving.]
rgrinberg has quit [Ping timeout: 240 seconds]
rgrinberg has joined #ocaml
rgrinberg has quit [Read error: Connection reset by peer]
rgrinberg has joined #ocaml
rgrinberg has quit [Ping timeout: 250 seconds]
rgrinberg has joined #ocaml
rgrinberg has quit [Ping timeout: 250 seconds]
rgrinberg has joined #ocaml
adanwan_ has joined #ocaml
adanwan has quit [Remote host closed the connection]
motherfsck has joined #ocaml
Haudegen has quit [Ping timeout: 256 seconds]
<d_bot>
<Jektrix> VPhantom, are you doing gRPC with OCaml? Or just using protobuf standalone. I've seen it mostly used with gRPC until now in other domains
rgrinberg has quit [Ping timeout: 256 seconds]
rgrinberg has joined #ocaml
rgrinberg has quit [Ping timeout: 240 seconds]
rgrinberg has joined #ocaml
rgrinberg has quit [Ping timeout: 256 seconds]
rgrinberg has joined #ocaml
<d_bot>
<VPhantom> Just Protobuf. I will use it for RPC but for various reasons it's not gRPC, not even service definitions.
<d_bot>
<VPhantom> Our internal "bus" will be based on Redis, not HTTP.
<companion_cube>
like, redis streams? blocking stuff on lists?
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<Jektrix> I've been finding gRPC (in Typescript, not OCaml) kind of frustrating at times to deal with
<d_bot>
<Jektrix> It's good but I'm wondering if there's something simpler out there to use.
<sleepydog>
so it's just protobuf or json over http/1.1 ?
<companion_cube>
pretty much
<companion_cube>
which probably makes a lot more sense than gRPC for most people?
<sleepydog>
i agree
rgrinberg has joined #ocaml
<d_bot>
<Jektrix> my main difficulties with grpc come from the reconnection/retry/repair of RPCs (especially bidirectional) and having to write a lot of application code on top to make bidirectional streams resilient
<d_bot>
<Jektrix> i'll take a look at this
<d_bot>
<Jektrix> I've also seen `ocaml-rpc` but haven't played with it yet
<companion_cube>
I don't think this is supposed to have streaming :D
<companion_cube>
it's more of a classic http request/response but with protobuf
<companion_cube>
(and there's no OCaml implementation of the service part, only protobuf)
<companion_cube>
(afaik)
<d_bot>
<Jektrix> still. thanks for the link. always good to see what's out there and get a lay of the land
<companion_cube>
but in both cases these are Go-originated alternatives to gRPC
<companion_cube>
by people who found gRPC too big and complicated
<sleepydog>
i would prefer whatever is easiest to troubleshoot when it breaks. i have to diagnose problems in gRPC services in my day job and it's difficult
<companion_cube>
and that's where http1.1 ought to be nicer
<sleepydog>
indeed. i'm not a fan of HTTP/2's "feature" to multiplex streams over a single TCP stream.
<d_bot>
<Anurag> `zmq` can be another decent option. It has decent abstractions where it takes care of socket connections etc, and lets the application deal with a higher level message oriented communication workflow
<Corbin>
..."I haven't used" is misleading, sorry. I haven't used the C++ or OCaml versions.
<companion_cube>
ZMQ is kind of nice.
<companion_cube>
capnproto, imho, looks super cool and interesting… but also so complicated that you only have a handful of implementations in the wild
rgrinberg has quit [Ping timeout: 240 seconds]
<companion_cube>
it might be technically better than flatbuffers or protobuf, but if it's a niche technology there's also many drawbacks
<companion_cube>
(we're on #ocaml, I don't need to detail i guess)
<sleepydog>
heh
<Corbin>
I've written a Capn encoder, decoder, and RPC stubs. It's medium difficulty. You have to be comfortable with some things being dynamically typed. Capability handling is hard even in cap-safe environments.
<companion_cube>
from the schema file? or from capnproto official compiler?
<Corbin>
Using the official compiler. The official way of doing it involves a kind of circular bootstrap, and it wasn't fun. Parsing the schema file sounds really easy, but you're not guaranteed to have the same struct layouts across languages if you do that.
<companion_cube>
well, that's my point. very complicated :p
<companion_cube>
if there's effectively only one compiler, it's less robust than having a lot of independent compilers
<companion_cube>
(and to be clear, protobuf isn't perfect on that either, but at least things like ocaml-protoc are 100% from scratch)
<Corbin>
Sure. IMHO if you don't need the speed, then don't do it. And this also applies to schemata in general; decoding a protobuf requires looking at tagged values, and that's a common feature with these nice backwards-compatible protocols.
<companion_cube>
protobuf wire format is considerably simpler
<companion_cube>
not sure if that's what you're saying ? :)
<Corbin>
I developed about half a Capn stack for Monte before realizing that JSON would work just as well. The current RPC framework just uses JSON over https://amp-protocol.net/
<Corbin>
Capn is meant to be faster protobufs. If protobufs aren't on the menu, then Capn shouldn't be either.
<companion_cube>
yeah
<companion_cube>
it's faster, but a lot more complicated
<companion_cube>
and there's the speed vs size tradeoff.
<companion_cube>
it'd be awesome if people ditched gRPC and adopted capnproto's RPC system en masse
<companion_cube>
but I think it'll never happen
<Corbin>
Yes. And TBF implementing their "level 3" or "level 4" RPC is non-trivial in *any* language. Gotta implement a little capability-handling framework. Something like the "Gordian surgeon" is required to slice objects into minimal network-safe units.
<sleepydog>
thanks for this link, i haven't read it before
<companion_cube>
yeah exactly, Corbin. the RPC thing is really advanced.
<companion_cube>
this might just be ahead of its time
<Corbin>
companion_cube: Yeah. I've been trying to make this stuff more accessible for years, and I'm not sure what else I can do besides (a) build little toys like Monte and (b) interoperate with standards like Capn when they arise. And (c) write cryptic obscurantist ramblings on public boards~
<Corbin>
Really, we just need JSON but with holes that can hold references to capabilities. When you want to send an object reference to somebody, either encode it as a JSON literal or just send the reference as a hole.
<companion_cube>
write a RFC? :p
<companion_cube>
tbh I think json is just overly wasteful
<companion_cube>
it's nice and readable, ish, but really, what a waste
<Corbin>
What do you think of AMP, at amp-protocol.net? Full disclosure: I pay to host this domain, but I don't control the docs. It happens to be low-latency, easy to implement, and extensible to hold a rich AST or JSON or whatever.
<companion_cube>
it's an unfortunate name
<companion_cube>
hmm it says "statically, strongly typed" but I don't see any schema anywhere :/
<Corbin>
Yeah. And just like with those other cases, our usage predates the rude usage by those other folks. I've used multiprocessing on AMP in Python for a Minecraft server, and in Monte for a raytracer.
<Corbin>
And indeed, JSON-RPC is a serious contender. The main reason I prefer AMP is because I don't like the overhead of HTTP; it's harder to write a secure HTTP client/server and asymmetric.
<companion_cube>
you don't have to do http for jsonrpc, in theory
<companion_cube>
it's transport agnostic
<companion_cube>
(see: LSP)
zebrag has quit [Quit: Konversation terminated!]
rgrinberg has quit [Read error: Connection reset by peer]
rgrinberg has joined #ocaml
rgrinberg has quit [Read error: Connection reset by peer]
rgrinberg has joined #ocaml
rgrinberg has quit [Read error: Connection reset by peer]
rgrinberg has joined #ocaml
rgrinberg has quit [Ping timeout: 240 seconds]
rgrinberg has joined #ocaml
<d_bot>
<darrenldl> the want to write a .ics generator intensifies as semester closes in hmmm
Dimonax has joined #ocaml
mbuf has joined #ocaml
rgrinberg has quit [Ping timeout: 256 seconds]
spip has quit [Quit: Konversation terminated!]
Serpent7776 has joined #ocaml
Tuplanolla has joined #ocaml
mbuf has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
bartholin has joined #ocaml
mbuf has joined #ocaml
random-jellyfish has joined #ocaml
<random-jellyfish>
Hi, I'm using the visual studio plugin for OCaml and if try to "open Graphics;;" it says "Unbound module Graphics"
<random-jellyfish>
I have installed the graphics package
<random-jellyfish>
is there some extra setup I have to do in vscode?
<d_bot>
<Jektrix> is your vscode plugin set to use the same opam switch as the one you installed `ocaml-lsp-server` into?
<d_bot>
<Jektrix> Well, to back things up, have you installed `ocaml-lsp-server` ?
<random-jellyfish>
yes I have
<d_bot>
<Jektrix> Check that vscode is using the correct opam switch first of all, I've made that mistake a few times
<random-jellyfish>
it's giving me the option to select a sandbox: a global or a custom one
<random-jellyfish>
global one seems to be default but with that it doesn't work
<d_bot>
<Jektrix> Hmm, global should work. If you do ctrl+shift+p and restart language server what happens?
<random-jellyfish>
same
<d_bot>
<Jektrix> are you using dune?
<random-jellyfish>
no, don't think so, what is dune?
<random-jellyfish>
I just want to run a small example
<random-jellyfish>
I'm still learning ocaml
<octachron>
A build system for OCaml.
<random-jellyfish>
I have a project with one file
<d_bot>
<Jektrix> Probably have to wait for someone more experienced than me to chime in but I always have to dune build first
<random-jellyfish>
and in that file I want to use the Graphics module
<random-jellyfish>
and vscode says "Unbound module"
<d_bot>
<Jektrix> so you may need to compile your code with `open Graphics` in it **once** first for the vscode lsp plugin to recognise it. I believe this is because it needs Merlin to spit out information first.
<octachron>
Then it is probably better to learn how to dune a simple dune file in order to add the graphics library to your project
<random-jellyfish>
if I open up the ocaml repl and do "#require "graphics";; open Graphics;;" it doesn't show any errors
<octachron>
require "graphics" is used to load the graphics library
<d_bot>
<Jektrix> I generally find after I create a new module or install a new package, i need to compile my code once first before the LSP recognises that it exists for some reason. again, I think it's related to merlin but not 100% sure.
<random-jellyfish>
can you tell me how to compile a single file from the command line?
<octachron>
You can use ocamlfind directly to compile directly your file with the graphics library, but that is not really scalable
<random-jellyfish>
I can probably search for it
<d_bot>
<Butanium (@me on answer)> It's recommanded to use dun
<octachron>
and the small dune file that I speak of is "(executable (name main) (libraries graphics))" (where main is the name of your main module)
<d_bot>
<Jektrix> I can't even remember the commands since I pretty much always use dune.
<d_bot>
<Jektrix> it should be `ocamlopt -o program.exe file1.ml` I think
<d_bot>
<Butanium (@me on answer)> Also don't you need `eval $(opam env) ` ?
<octachron>
@Jektrix, your are missing the graphics library, which is kind of the whole point?
<d_bot>
<Jektrix> Oh right whoops, yeah I haven't done it on the command line in so long without dune I forgot... you need to add ocamlfind in front to find and include the package.
<d_bot>
<Jektrix> just do the dune file octachron posted random-jellyfish
<random-jellyfish>
what should the dune file be named?
<d_bot>
<Jektrix> `dune`
<random-jellyfish>
okay
<d_bot>
<Jektrix> you will need to opam install dune as well if you haven't already. after that you will have your `main.ml` and `dune`, then you can run `dune exec main.exe` to compile and run the program.
<random-jellyfish>
wait a minute
<random-jellyfish>
my example file was named "graphics.ml"
<random-jellyfish>
I changed it and now the error is gone
<random-jellyfish>
could that have been the problem?
<random-jellyfish>
that the file has the same name as some installed module?
<octachron>
Yes, module names need to be unique
<d_bot>
<Jektrix> lol
<random-jellyfish>
right
<d_bot>
<Jektrix> I ... didn't think of that. Sorry random-jellyfish
<random-jellyfish>
perfect
<octachron>
(and if you are using an old version of OCaml, graphics might not be a library yet)
<random-jellyfish>
I've installed it on ubuntu with "sudo apt install ..."
<random-jellyfish>
opam found and installed graphics
<random-jellyfish>
in the dune file, the name parameter should be the same as the file I want to compile?
<octachron>
It should be the name of your main module, and if you have only one file, then it is also your "main" module.
<octachron>
The advantage of dune is then that you will not need to change anything when you add more (auxiliary) modules to your project.
Dimonax has quit [Quit: Leaving]
mro has joined #ocaml
<random-jellyfish>
so I renamed my file to main.ml
<random-jellyfish>
"dune build" runs without error
<random-jellyfish>
but now how do I run it?
<random-jellyfish>
nevermind, found the executable
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<d_bot>
<Butanium (@me on answer)> you can do `dune exec ./main.exe`
Haudegen has joined #ocaml
mro has quit [Remote host closed the connection]
<random-jellyfish>
thanks
bartholin has quit [Ping timeout: 256 seconds]
bartholin has joined #ocaml
<d_bot>
<gabriel_> hello guys, can someone explain to me how to terminate a program please
<d_bot>
<gabriel_> here is my program :
<d_bot>
<gabriel_> let rec pgcd a b = match (a,b) with
<d_bot>
<gabriel_> |(a,b) when a=b->a
<d_bot>
<gabriel_> |(a,b) when a>b -> pgcd(a-b) b
<d_bot>
<gabriel_> |_->pgcd a (b-a);;
<qwr>
that is a function, probably terminating by itself
hyphen has quit [Ping timeout: 256 seconds]
hyphen has joined #ocaml
Nahra has joined #ocaml
<random-jellyfish>
isn't it like writing in an imperative language while(a!=b) { if(a>b) a = a-b else b = b-a; } ?
<d_bot>
<gabriel_> ok
<random-jellyfish>
if you run it with a==b then it will run forever
<random-jellyfish>
because if will be set to 0 in the first iteration and then a>b forever
random-jellyfish has quit [Ping timeout: 256 seconds]
bartholin has quit [Ping timeout: 272 seconds]
<d_bot>
<VPhantom> Re: RPC with Protobuf, first we never have ambiguity about which message we're dealing with anywhere, because we have a single wrapper message that can contain anything we might want at a root level. One of these things is an RPC "message" which may contain authentication stuff (for public API users) and any number of requests and responses (both sides can issue both). Requests include a magic number so responses can be matched,
<d_bot>
<VPhantom> (Thank you moderators, for whatever that was! 😉)
jlrnick has joined #ocaml
bartholin has quit [Ping timeout: 256 seconds]
hyphen has quit [Ping timeout: 272 seconds]
hyphen has joined #ocaml
bartholin has joined #ocaml
jlrnick has quit [Ping timeout: 260 seconds]
spip has joined #ocaml
mro has joined #ocaml
mro has quit [Ping timeout: 240 seconds]
bartholin has quit [Ping timeout: 256 seconds]
mbuf has quit [Quit: Leaving]
bartholin has joined #ocaml
bartholin has quit [Ping timeout: 240 seconds]
hyphen has quit [Ping timeout: 256 seconds]
hyphen has joined #ocaml
bartholin has joined #ocaml
bartholin has quit [Ping timeout: 272 seconds]
mro has joined #ocaml
bartholin has joined #ocaml
bartholin has quit [Ping timeout: 272 seconds]
rgrinberg has joined #ocaml
bartholin has joined #ocaml
rgrinberg has quit [Ping timeout: 256 seconds]
rgrinberg has joined #ocaml
waleee has joined #ocaml
perrierjouet has quit [Quit: WeeChat 3.4]
Anarchos has joined #ocaml
mro has quit [Remote host closed the connection]
bartholin has quit [Ping timeout: 256 seconds]
ouestbillie has joined #ocaml
bartholin has joined #ocaml
rgrinberg has quit [Read error: Connection reset by peer]
rgrinberg has joined #ocaml
rgrinberg has quit [Ping timeout: 256 seconds]
jlrnick has joined #ocaml
hyphen has quit [Ping timeout: 256 seconds]
hyphen has joined #ocaml
ouestbillie has quit [Quit: leaving]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
perrierjouet has joined #ocaml
sda has joined #ocaml
sda has quit [Client Quit]
vicfred has joined #ocaml
vicfred has quit [Remote host closed the connection]
vicfred has joined #ocaml
<d_bot>
<orbitz> If I have merlin setup emacs, is there a compelling reason to move to ocaml-lsp in emacs?
vicfred has quit [Quit: Leaving]
bartholin has quit [Ping timeout: 256 seconds]
bartholin has joined #ocaml
adanwan_ has quit [Ping timeout: 276 seconds]
adanwan has joined #ocaml
bartholin has quit [Ping timeout: 272 seconds]
bartholin has joined #ocaml
bartholin has quit [Ping timeout: 256 seconds]
<d_bot>
<Pim> Better support ? I haven't setup anything on my emacs, but in general, languages servers are really effective supports. Don't know the case for merlin though
gravicappa has quit [Ping timeout: 256 seconds]
bartholin has joined #ocaml
romildo has joined #ocaml
romildo has quit [Client Quit]
adanwan has quit [Ping timeout: 276 seconds]
adanwan has joined #ocaml
<d_bot>
<concatime> When using `dune`, can I tell it to NOT compile the `.so` library?
random-jellyfish has joined #ocaml
wingsorc has joined #ocaml
jlrnick has quit [Ping timeout: 240 seconds]
bartholin has quit [Quit: Leaving]
<williewillus>
orbitz: not really a good reason IMO. In some ways, language specific plugins can be better as they aren't bound by the least common denominator that's the lsp protocol. Though in this case the lsp just uses merlin under the hood anyways, so it doesn't really matter.
<williewillus>
I prefer to use merlin directly
<williewillus>
less layers in the way
rgrinberg has joined #ocaml
<companion_cube>
otoh editors will probably have better LSP support than merlin support
zebrag has joined #ocaml
Tuplanolla has quit [Quit: Leaving.]
<d_bot>
<orbitz> My only complaint is Merlin is slow which actually will stall emacs as i type sometimes. Not sure if the LSP is asynchronous and would help with that. But other than that Merlin has been good to me
<d_bot>
<froyo> interesting, for the longest time i thought merlin was the flagship and ocamllsp was just a protocol layer over it
<d_bot>
<froyo> i can see the lsp server being the future tho because it's more integrated w/ the existing tooling, and i think we also have a tree sitter module :>
<d_bot>
<orbitz> I'd imagine LSP is future too
<companion_cube>
I don't know if merlin is really the flagship now
<companion_cube>
it was for a while, but now the active project is called "ocamllsp"
<d_bot>
<orbitz> I'll have to poke around for tutorial on emacs setup
<companion_cube>
and of course, the VSCode custom extensions :/
random-jellyfish has quit [Ping timeout: 256 seconds]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
Haudegen has quit [Ping timeout: 256 seconds]
JosEduardo[m] has quit [Ping timeout: 250 seconds]