<rgrinberg>
i think the problem is that camlp4 isn't compatible with ppx
<vbmithr>
Ah btw rgrinberg
<vbmithr>
I've rewritten your onanomsg
<rgrinberg>
cool :)
<vbmithr>
have a look at vbmithr/onanomsg (and see also the branch subtypes for one try with phantom types)
<vbmithr>
I plan on using that on a real world project :)
<rgrinberg>
did you get rid of ocp-build?
<vbmithr>
yeah
<vbmithr>
of course
<rgrinberg>
:D
<rgrinberg>
+1
<rgrinberg>
now call the rest of the whitequar shill^H^H^Hfan club
<rgrinberg>
to +1 that
<vbmithr>
:)
<vbmithr>
For onanomsg the important feature I added is zero-copy (using blitting directly into nanomsg provided buffers), and non-blocking operation through Lwt.
<vbmithr>
The rest was refactoring / interface redesigning
<rgrinberg>
makes sense
<rgrinberg>
i wanted to deal with all of that afterwards
<rgrinberg>
did you update ctypes?
<vbmithr>
nanomsg might have evolved since you made the bindings.
<vbmithr>
I mostly did not touch this
<vbmithr>
Should I ?
<rgrinberg>
perhaps
<rgrinberg>
hmm you didn't use cstruct?
<vbmithr>
no
<rgrinberg>
just bigarray directly?
<vbmithr>
what for ?
<vbmithr>
Lwt_bytes.
<vbmithr>
Since I was relying on Lwt anyway for NB
<rgrinberg>
dont know what's that
<vbmithr>
Bigstring-like.
<rgrinberg>
ok that is bigarray pretty much
<rgrinberg>
yeah
<rgrinberg>
surprising i thought nano was dead
<rgrinberg>
but people give a shit about it
<rgrinberg>
next up - pure ocaml implementation :D
<vbmithr>
haha
<vbmithr>
good choice of licence BTW
<vbmithr>
license
<rgrinberg>
haha avsm would disagree
<rgrinberg>
i should slap MIT on it
rgrinberg1 has joined #mirage
rgrinberg has quit [Read error: Connection reset by peer]
thomasga1 has joined #mirage
<rgrinberg1>
vbmithr: is there a way to depopt the lwt bits?
<rgrinberg1>
i suppose you don't care much about that :D
thomasga1 has quit [Client Quit]
thomasga has quit [Ping timeout: 264 seconds]
<vbmithr>
Yes
<vbmithr>
The lwt code is in the NB module
<vbmithr>
Other than that I just use Lwt_bytes
<vbmithr>
So it's almost trivial to depopt lwt yes
<rgrinberg1>
ok cool
<vbmithr>
It would be nice to a have a minimal bigstring library
<vbmithr>
Well, there is cstruct…
<vbmithr>
But it's not exactly a bigstring library
<vbmithr>
The problem space your code is trying to solve is simple enough that you can write a small core that is independent of any particular concurrency library.
<vbmithr>
I thought this in the beginning
<vbmithr>
But now I evolve on this as well
<vbmithr>
An implementation using Lwt of something that does not need it is just wrong
<vbmithr>
codecs do not need Lwt nor Async, never
<vbmithr>
I need to rewrite websocket btw :)
<rgrinberg1>
yeah that's true
<rgrinberg1>
if you're dealing with a protocol
<rgrinberg1>
you should be encode its messages and transitions as purely as possible
<rgrinberg1>
not everything is a protocol though
<vbmithr>
in the case of onanomsg, a small portion of it needs monad at all
<vbmithr>
so it's not a big deal at all to support both async/lwt
<vbmithr>
no, no :)
<vbmithr>
v interesting article you wrote
<rgrinberg1>
but yeah im in the lwt camp now
<rgrinberg1>
still use core_kernel
<rgrinberg1>
because unlike async, it doesn't really have a good community alternative
<vbmithr>
I think janestreet stuff is very good when you have the same usecase as them
<vbmithr>
write the same kind of programs
<vbmithr>
but in the other situation
<vbmithr>
I like having a community around
<vbmithr>
Anyway, when you write libraries you don't want to impose a choice on your users
<vbmithr>
when you write programs you don't care
<vbmithr>
but ultimately you are right there is no way to end fragmentation
<rgrinberg1>
yeah
<vbmithr>
a webserver for example :)
<rgrinberg1>
and of course its 2x worse when the choice is mutually incompatible
<rgrinberg1>
in the case of stdlibs the worst that can happen is fast executables
<rgrinberg1>
and funny name conflicts
<vbmithr>
I planned to use core to do bitcoin related things
<vbmithr>
a bit the same thing as janestreet is doing
<vbmithr>
for that, core/async is the perfect choice :)
rgrinberg1 has quit [Quit: Leaving.]
<vbmithr>
But I'm going to depopt lwt from onanomsg
<vbmithr>
I don't want to force lwt on users, as said previously :)
rgrinberg has joined #mirage
<rgrinberg>
awesome :)
<rgrinberg>
its good that youre getting familiar with core/async
<rgrinberg>
imo avsm is right we should port over the good ideas from there into lwt
<rgrinberg>
what are you doing with bitcoin may i ask
<vbmithr>
I don't think so. I'm just designing a sort of interface between a financial protocol and bitcoin exchanges
<vbmithr>
that use REST or websocket
<vbmithr>
So I need to do a TCP server, basically…
<vbmithr>
There is tons of code for that in Core/Async
<vbmithr>
I guess they do similar things
<vbmithr>
And since it was a project where I did not want to innovate (like using mirage for example), I was fine with async.
<vbmithr>
For doing TCP servers for example async is much nicer
<vbmithr>
there is much more advanced features in it, and so on
<rgrinberg>
indeed
<rgrinberg>
that's not going to be open source right?
<vbmithr>
github.com/vbmithr/ocaml-dtc
<vbmithr>
actually I'm working with struktured a bit
<vbmithr>
he wants to do machine learning things
<vbmithr>
I also did github.com/vbmithr/ocaml-scid
<vbmithr>
a dbuenzli inspired coded for financial data
<vbmithr>
those tools will be opensource of course
<rgrinberg>
nice :D
<rgrinberg>
in bunzli style: "scidm"
<vbmithr>
yeah, he is obsessed in short names
<vbmithr>
I leave him this
<vbmithr>
He tends to use super short variables names too
<vbmithr>
But in my opinion, programs are not math
<vbmithr>
You're not supposed to try to guess all the time what this one or two letter variable means