2016-06-30

<hcarty> Ah, and the fix was merged
<hcarty> flux: For at least a little while
<hcarty> Drup: The issue I'm having with cohttp, though, is current and ppx related
<hcarty> gasche: That's good to know
<hcarty> Drup: No, but there were troubles building from master IIRC because it is/was using dynamic setup
<hcarty> Drup: Indeed. Lwt was ready to go, at least from git master, relatively quickly. Quite quickly once oasis was updated.
<Drup> hcarty: cohttp (and all the mirage stuff) has another issue
<hcarty> Well, cohttp + ppx_deriving, which is really ppx_type_conv + ppx_deriving + 4.03.0
<hcarty> gasche: Two conflated issues in my comment - the ppx stuff is cohttp related
<hcarty> While I don't quite have dbuenzli's distaste for ppx yet, preprocessors have been feeling like dangerous creatures recently

2016-06-29

<hcarty> gasche: brat?
<clement`> hcarty, gasche: Thanks; this discussion was very helpful!
<hcarty> with builds
<hcarty> Which can cause strange issues
<hcarty> clement`: If you pin a directory I think it uses the directory as-is by default
<clement`> hcarty: I'm modifying Dep, not Main
<hcarty> Without needing to create a local clone
<hcarty> clement`: If there is an existing version of Dep that you want to point to (ex. git master on github for Dep) then you can pin directly to that remote source
<hcarty> clement`: If you're modifying Dep and Main, then yes
<clement`> gasche, hcarty: I see. So essentially I clone Main and build it locally, and I clone Dep separately; then I use opam pin to use the clone of Dep as the install source for Dep. Finally every time I want to test Main with Dep I opam update Dep and I build Main manually. Is that right?
<hcarty> Or a particular branch or tag in that repository
<hcarty> clement`: And yes, you can pin to a local directory, or a local git repository
<clement`> hcarty: Thanks! With that solution I'll have to do a full uninstall/reinstall of Main every time I modify Dep, though, right? Also, can I point pin to a folder on my machine?
<hcarty> clement`: "opam pin" allows you to point opam to a specific version or instance of a package
<hcarty> clement`: "opam pin add dep --dev-repo" or "opam pin add dep <path/url to dep's repository or code>"
<hcarty> flambda will have to wait til another day
<hcarty> Realistically I'd love to fix it but don't have the hour to kill...
<hcarty> Will Jane St accept external contributions? I haven't followed their external interactions on something like this before
<hcarty> Well that sucks
<hcarty> Ah, thanks
<rgrinberg> hcarty: that's b/c it's a ppx_type_conv issue
<hcarty> But the issue does seem to be a conflict between one of the Jane St packages and ppx_deriving
<hcarty> Something in the dependency chain is forcing an older version of ppx_deriving which is not compatible with 4.03.0
<rgrinberg> hcarty: hmm, so there's a conflict? I've checked cohttp alone on 4.03 btw and it worked
<hcarty> rgrinberg: cohttp and ppx_deriving(_yojson) do not seem to be co-installable under 4.03.0
<hcarty> Drup: Regarding yesterday - sorry if I wasn't clear, but that was part of my point. Less experience is something of a virtue for a position like that because they'll more easily see things from a newcomer's perspective.
<hcarty> Algebr`: ocamlfind can be used to build - it's effectively a wrapper around ocamlc/ocamlopt/etc

2016-06-28

<Drup> hcarty: on the contrary, I would tend to think it's better if it's not done by a complete expert
<hcarty> This doesn't need to be someone who has 10+ years of experience with the langauge and community
<hcarty> gasche: Anil and Yaron have jobs already
<gasche> hcarty: sure, I'm just saying it's not necessarily easy to find someone interested
<hcarty> gasche: That's part of the challenge of growing a programming language community, and part of why a position like that can be so effective
<hcarty> gasche: I suspect someone would if there were a paycheck attached
<hcarty> Algebr`: A member of the Rust community (and team maybe?)
<gasche> hcarty: the OCaml maintainers are responsible for the compiler distribution, not opam
<hcarty> gasche: Maybe funding for such a project should go through something like OCaml Labs? If it's not going to be handled/implemented by the core OCaml team
<hcarty> Really no rush on my side. I'm just happy the bindings are there, helps spread the OCaml use around here
<hcarty> s/pieces/things/
<hcarty> No rush though as I have a simple internal library that does the few pieces I need
<hcarty> seliopou: Nudge for S3 support in ocaml-aws :-)
<gasche> hcarty: of course: https://github.com/ocaml/opam/issues/2594
<hcarty> Which did the setup, test and cleanup automatically
<hcarty> It would be nice to have a one-step way to tell opam "try to install my new package(s) from this repo"
<hcarty> gasche: Submit a PR! Or a bug report
<seliopou> hcarty: glad to help!
<hcarty> seliopou: I'm hoping to be able to make a release in the next few weeks - depends on work time availability mainly
<hcarty> seliopou: Thanks for taking a look and for the suggestions! I'll make those changes before release.
<hcarty> There's an outer layer that maps the precise msgpack representation type to a more usable user-focused type
<hcarty> I need to add benchmarks and proper tests, do a writeup and then it'll be ready to release
<hcarty> seliopou: You're welcome - thanks for the suggestion. I should have done that in the first place
<seliopou> hcarty thanks for sending that pr

2016-06-27

<sh0t> ok hcarty thanks. Drup i am updating if it doesn't work i ll post that thanks!
<hcarty> sh0t: Worst case, you can remove ~/.opam and start over :-)
<hcarty> sh0t: opam switch install 4.03.0
<hannes> hcarty: thx
<hcarty> hannes: http://caml.inria.fr/mantis/view.php?id=7280 if you're interested
<hcarty> Int32.(compare_unsigned, unsigned_to_int, unsigned_of_string, unsigned_to_string) and Int64.(compare_unsigned, unsigned_to_int, of_unsigned_int32, to_unsigned_int32, unsigned_of_string, unsigned_to_string)
<hcarty> hannes: I'm submitting a Mantis ticket at least
<hannes> hcarty: yes, to/of_* are the missing bits
<hcarty> aantron: I spoke too soon... I run into issues, at least in utop, if I create and free large pools over and over again
<hcarty> Those could all go into the Int32 and Int64 modules
<aantron> hcarty: sorry was away. good to hear though
<hcarty> gasche hannes: The worst missing offenders are, I think, compare and (to|of)_*
<hcarty> Or, potentially, add something like Int32.compare_unsigned
<hcarty> gasche: In those modules would make sense
<hcarty> gasche: I think there's a good argument for it as they're a huge pain to do properly otherwise
<hcarty> bruce_r: Starting with oasis is good for getting your code building and sets you up nicely for packaging the result, whether for your own use other the use of others
<hcarty> But Gerd also added omake output to oasis
<hcarty> bruce_r: oasis-generating-X is probably the most common, where X is usually ocamlbuild configuration
<hcarty> aantron: And now pools should be GCd properly... not sure that a thread pool is something that should be left to the GC to clean up, but it should ideally be cleaned up for the user if they forget
<hcarty> more effort = more effort than I've put into the code so far
<hcarty> aantron: https://github.com/hcarty/mwt/blob/master/src/mwt.mli#L3 - proper cleanup of a thread pool is more effort, but this Mwt.run function does the job if the cost of thread creation + teardown isn't too much to pay

2016-06-24

<hcarty> sveit: There is a native code toplevel (ocamlnat) but as far as I know it is not installed by default and it is not well supported yet
<aantron> hcarty: :D
<hcarty> Food time...
<hcarty> And the resource leaks :-)
<hcarty> aantron: Not necessarily something to release, but the mli is there
<hcarty> Not really related to the mli, just what I'm hacking on rather than writing the mli
<hcarty> Since threads are not GCd
<hcarty> aantron: Indeed! I need to figure out how to handle cleanup
<aantron> hcarty: lol, Mwt
<hcarty> Other than "I'd really like it to do a few more things"
<hcarty> companion_cube: Neither did I :-)
<hcarty> I suspect that more is required to avoid leaking threads, but this is all quite new to me
<hcarty> You'd use Mwt.make to create a pool and Mwt.detach to run something in a specific pool
<hcarty> aantron companion_cube: Hacked on here and there throughout the day and currently completely untested - https://gist.github.com/hcarty/5f613dcd87052fc429e47180fafcea2c
<hcarty> gasche: Said hilarity is definitely not limited to a classroom :-)
<hcarty> companion_cube: Perhaps... I'm hoping I can reuse 90% of what's there
<hcarty> This could be an external library, a new module in Lwt alongside Lwt_preemptive or a replacement for it
<hcarty> aantron: That should greatly simplify the init/at_exit code
<hcarty> aantron: I'm going to take a stab at making a version of Lwt_preemtive with multiple thread pools

2016-06-23

<hcarty> If I get a chance to test it I'll report back with how it does or does not work
<hcarty> struk|desk: Yep, sticking to foreign/libffi for now!
<hcarty> mrvn: Thanks. It looks like cstubs doesn't, but maybe there's some special magic with the lwt-jobs support? I kind of doubt it though.
<struk|desk> hcarty: I asked that same question last week and mrvn gave me the same answer :) frustrating isn't it?
<hcarty> Or is it only intended for binding blocking-but-not-CPU-costly code?
<hcarty> Does the new ctypes support for Lwt jobs provide an (at least partial) work-around for the lack of support for releasing the runtime lock when using cstubs?
<rgrinberg> hcarty: it works but it's not as good as it can be. To make it work real well you'll have to create a merlin deoplete source (written in python)
<hcarty> rgrinberg: neovim + deoplete <- Does this work with merlin? Looks quite nice
<hcarty> rgrinberg: Ready as in it compiles and functions. Still doesn't support inline records arguments in variants
<rgrinberg> hcarty: is ppx_deriving_yojson 4.03 ready yet?
<rgrinberg> hcarty: yup, you actually paste code between vim buffers and utop properly
<hcarty> rgrinberg: That's pretty slick
<hcarty> rgrinberg: oooooooooo
<rgrinberg> hcarty: try :term utop ;)
<struk|desk> hcarty: I couldn't get merlin + syntastic to work 100% with it yet, but when I do I'm fully switching over from vim
<malc_> hcarty: one slash too many
<hcarty> s/vn=im/vim/
<hcarty> I was happy to see that, again in limited testing, my existing vn=im configuration just worked
<hcarty> struk|desk: My limited experience with neovim so far has been that "it feels like vim". But I haven't tried anything special with it.
<struk|desk> hcarty: agreed that would be cool
<hcarty> It would be nice if vim+syntastic showed the warnings while editing
<hcarty> I want to be able to see the messages via merlin... not sure how to do that
<hcarty> I haven't looked in much detail yet and I only tested two relatively small codebases. But it looks like a useful start!
<hcarty> infinity0: It seems easy to use, at least in its default configuration
<hcarty> Because ocamllint complains if they don't... which seems a little odd given that (almost) every time I've seen a module type name it's been capitalized
<hcarty> And I just learned that module types can start with a lowercase letter
<hcarty> Ah, it works if I pin to --dev-repo
<hcarty> Same with another pure-OCaml library
<hcarty> It didn't work on my first attempt with a library using ctypes - it's causing ocamldep errors
<hcarty> infinity0: I haven't, but I think I will give it a try now :-)
<hcarty> edgimar: The tls stuff may be for retrieving remote data - the README indicates that some external resources are pulled down as part of the build process
<hcarty> edgimar Kakadu: s/nettls/gnutls/ maybe, in that last comment?
<hcarty> toolslive: If you can, though, it may be simpler to write a C stub and wrap that stub with ctypes, if possible
<hcarty> Gives you a nativeint that you can pass into a manually bound 'external' function
<hcarty> toolslive: raw_address_of_ptr
<hcarty> toolslive: I had to do this recently... there's a way to get the raw address of the pointer

2016-06-22

<hcarty> rgrinberg: Understood, thanks :-)
<rgrinberg> hcarty: obviously it's not a must and the library should still be plenty usable without it but it's an important feature I think
<hcarty> rgrinberg: Ok, I'll see if I can get time to work that in before the initial release
<rgrinberg> hcarty: it would be sufficient for me if I could fold over the array/map as it's being read
<hcarty> rgrinberg: For a streaming msgpack implementation, would it be sufficient to get an array or map as a complete entity? Or would you want to be able to stream each element/mapping piece by piece?
<hcarty> gasche: Hello
<hcarty> t4nk421: Maybe a problem in the META file for FOO?
<hcarty> toolslive: I ran into the same thing recently :-)
<hcarty> toolslive: A report/request about this - https://github.com/ocamllabs/ocaml-ctypes/issues/167
<aantron> hcarty: Algebr`: so in OASIS, you just do BuildDepends: thread? that doesn't seem right, its not a package

2016-06-21

<aantron> hcarty: right :)
<hcarty> aantron: Thanks! That's what I expected, but more from a "that seems like it would make sense" perspective rather than "I know the intended semantics"
<aantron> hcarty: yeah, to a first approximation, lwt.async and lwt_main are orthogonal. if the thread you ran async on does some kind of real I/O, lwt_engine will become involved... but thats orthogonal to whether you wrapped it in async or not.
<hcarty> cheater: Can you gist/pastebin/... the code you're #use-ing?
<hcarty> aantron: Not really regression test material! :-) But it illustrates what I was hoping for functionality-wise
<hcarty> A simple test for my use-case, prints out multiple Hello lines as expected
<aantron> hcarty: ok, thanks
<hcarty> aantron: It works
<hcarty> aantron: Thanks. I'll try it and see what happens :-)
<aantron> hcarty: without confirming, yes
<hcarty> Is it ok to call Lwt.async before any calls to Lwt_main.run? With the async'd thread run once Lwt_main.run is called?
<hcarty> zozozo: The last answer I saw to that question was, effectively, "Don't ask"
<aantron> gah, the travis builds havent even started. im going to wait for at least 1 row in each of {4.01, 4.02, 4.03} to complete, just in case, then its merged :) thanks companion_cube, hcarty! :)
<hcarty> Indeed
<hcarty> companion_cube: And Lwt_option and Lwt_option_result and Lwt_result_option and Result_lwt and Option_lwt... I don't think I've needed Result_option_lwt yet though
<hcarty> As far as names go, I'm biased toward Rresult as I've been happily using that for a while. I'm glad this is making it in to Lwt
<hcarty> aantron: Lovely! I'm fine with moving the conversation on naming specifics to a different PR
<aantron> companion_cube: hcarty: im going to merge Lwt_result https://github.com/ocsigen/lwt/pull/247 (in a bit). hcarty: i agree about things like the name of fail. i suggest we make follow-on PRs for those to discuss them independently. if that sounds reasonable to you guys, i'll post something to that effect on GH and proceed
<hcarty> flux: Arrays are used there to match column numbers
<hcarty> dave24: You put ';' in the middle of the line
<cheater> hcarty: :))
<hcarty> cheater: Welcome to the wonderful world of OCaml :-)
<hcarty> And what chelfi said
<hcarty> cheater: Not really. These derived functions are built by looking at the language AST and building appropriate code based on that
<cheater> hcarty: thanks. so this is generics? is that what this mechanism is called?
<hcarty> The [@...] syntax specifies attributes. If you use an appropriate pre-processor those attributes can specify things like "generate serialization and comparison functions for this type"
<hcarty> cheater: This 'with' syntax is from older syntax extensions. The more current/modern way to do this is something along the lines of "type t = { ... } [@@deriving sexp, bin_io, compare]"
<hcarty> cheater: I haven't used async_rpc before, but that may help
<hcarty> cheater: Latest async and core docs: https://ocaml.janestreet.com/ocaml-core/latest/doc/
<hcarty> cheater: Yes, I think so
<cheater> hcarty: gotcha. is it the same arg order as >|=?
<hcarty> A few other libraries use that spelling too
<hcarty> cheater: >>| is Async's spelling of >|=
<hcarty> cheater: Yeah... Core, Async and friends take quite a while to compile
<hcarty> to get the whole set
<hcarty> cheater: opam install utop merlin ocp-indent ocp-index
<hcarty> ocp-browser lets you browse through all your installed libraries, including (most of) their documentation
<hcarty> utop is a fancy interactive OCaml session
<hcarty> merlin can be but it's really setup to be run with an editor
<hcarty> I'd recommend utop and ocp-browser for cli use
<hcarty> merlin + ocp-indent are highly recommended in general
<hcarty> vim/emacs/sublime text/atom/vs code
<hcarty> IDE-like goodies for your editor
<hcarty> merlin isn't a search engine but it's a very nice editor support tool
<hcarty> cheater: http://ocamloscope.herokuapp.com/ has a very limited set of libraries that you can search. Otherwise merlin and maybe ocp-browser (part of ocp-index)
<hcarty> cheater: I haven't used webmachine yet, but from a cohttp perspective I'm not sure anything special is required
<dave24> hcarty: yeah thanks, i found it
<hcarty> dave24: In the case of cohttp it's most likely (always?) the bind operator for the concurrency library being used
<hcarty> One day codoc (or whatever it's latest incarnation is) will save us all
<hcarty> companion_cube: According to the README it's tied rather closely to 4.01.0 which may also make adding more libraries difficult
<hcarty> dave24: merlin can be helpful with this, at least for identifying the type of an entity
<hcarty> companion_cube: So quick! :-)
<hcarty> dave24: There is http://ocamloscope.herokuapp.com/ - but the answer will depend on context

2016-06-20

<aantron> octachron: hcarty: yep. and no mention of -as-map anywhere
<aantron> hcarty: let me grep through ocamlbuild source
<hcarty> aantron: Installed a 4.03.0 switch with oasis, same error sadly
<hcarty> I've been feeling the call of Logs recently, in part because of the dbuenzli effect
<hcarty> companion_cube: It's mostly an overlay. There are a few custom pieces of code, but the whole thing is ~100 lines of code
<hcarty> companion_cube: Yeah, backwards compatibility is a harsh burden!
<companion_cube> hcarty: wouldn't it be almost like an overlay?
<hcarty> companion_cube: The whole thing was put together quickly for the benefit of a few folks new to OCaml and is still a major WIP
<hcarty> companion_cube: CC* are on the list to consider. The main (and honestly weak) reason for not using CC* already is naming consistency with an existing codebase. print vs pp and a few similar names.
<hcarty> companion_cube: Gen is in the bundle too :-)
<hcarty> companion_cube: The In_channel and Out_channel code are mainly for with_file-like functions and similar convenience functions
<aantron> hcarty: you might also be able to use namespaces (though use the master version)
<hcarty> I think I'm going to give up on this for now, unfortunately. I can use the raw module names for now inside of the library (A__b rather than B).
<hcarty> I suspect that's a fixable problem but I haven't had time to spend on it yet
<hcarty> aantron: I'd love to move to 4.03.0 but cohttp didn't build on there last time I tried
<hcarty> aantron: I think that's correct, based on how the manual describes it
<hcarty> companion_cube: Astring, Rresult, Fmt, Yojson, ppx_deriving.std, ppx_deriving_yojson and the In_channel and Out_channel modules from Core
<hcarty> aantron: Yes
<hcarty> aantron: for a.ml: src/a.ml: A__b A__c; for a__b.ml: src/a__b.ml: A
<hcarty> aantron: 4.02.3
<aantron> hcarty: is the switch 4.03, or 4.02?
<companion_cube> hcarty: I mean what specific do you add to your mini stdlib?
<aantron> hcarty: whats the build error?
<hcarty> companion_cube: Internal work projects
<aantron> hcarty: im torn in namespaces between writing a whole-project ocamldep, which is the right way to solve this, and adding some hacks to be able to use 4.03 ocamldep, which i can do probably in a few days, but it won't be very flexible. i guess i should go with the latter and do the former later..
<hcarty> companion_cube: Yep! :-)
<hcarty> http://vpaste.net/kWVDm -- _build/_log output
<hcarty> aantron: This is an internal mini-stdlib at the moment. But I'd like to use module aliases more intelligently in general. Improvements to Namespaces would be wonderful to see :-)
<aantron> hcarty: do you have the _build/_log?
<hcarty> octachron: It looks like it is - trying to track that down now. I'm not sure how to tell oasis to show ocamlbuild's verbose/class output
<aantron> hcarty: what are you working on? every time someone mentions aliases i feel a fire lit under me to work on namespaces again :p
<hcarty> companion_cube: \o
<companion_cube> o/ aantron and hcarty
<hcarty> aantron: Thanks ... I'm making lots of foolish typos along the way
<hcarty> AAAAA
<hcarty> s/sure/hope/ perhaps...
<hcarty> I'm sure I'm missing something simple
<hcarty> aantron: Thanks
<aantron> hcarty: want me to take a look? maybe make a gist?
<hcarty> Gah... same issue even on a simple project
<hcarty> parentlib.ml has actual code used by parentlib_a.ml as opposed to just module aliases
<hcarty> Aaaaah, I see... I haven't split all the code I need into indenpendent modules
<hcarty> aantron: Adding "true: no_alias_deps" and appropriate open(Parentlib) entries to _tags fails with circular build errors
<aantron> hcarty: what do you mean by straightforward?
<hcarty> Is there a straightforward way to use module aliases with oasis?

2016-06-17

<hcarty> seliopou: Sounds good, thanks!
<seliopou> hcarty: sorry haven't had time to comment on PR but looks good!
<hcarty> That will (hopefully) come eventually in the form of modular implicits, but that isn't in the language yet
<hcarty> There is no automatic resolution of a matching module like you get with type classes
<hcarty> I don't know the current state of xavierbot but it's not running at the moment and hasn't been for a while
<hcarty> zRecursive: OCaml doesn't support type classes or other mechanisms for symbol/function overloading. A mechanism to support this is being worked on though.
<zRecursive> hcarty: xavierbot isnot working now ?
<hcarty> There was xavierbot or similar for a while

2016-06-16

<hcarty> seliopou: Then let's do this parsing thing
<seliopou> hcarty i'd be down for some endian parsing!
<hcarty> rgrinberg: Oh yes... it would be very nice if there were a version of setup-dynamic which did away with the setup.data file entirely
<rgrinberg> hcarty: which is also extremely unhelpful :/
<hcarty> setup.data caches the information found when ./configure is run
<hcarty> There's a bit of bash magic I saw once to complain if setup.data doesn't match the current switch. Not sure if I have the link though.
<hcarty> seangrove: You're welcome, glad it worked
<seangrove> Thanks hcarty
<hcarty> seangrove: setup.data may have been pointing to a different switch
<seangrove> hcarty: Wow, looks like that did it
<hcarty> seangrove: You could try a "make distclean && make" but it's a bit of a reach. Any chance there's a switch mismatch?
<hcarty> reynir: https://gist.github.com/hcarty/52b8933a012611a26d7526d69bcf6dc4 -- this is a slightly modified version of the actual module I mentioned
<hcarty> reynir: Of an exposed Cmdliner.t? I can find something
<reynir> hcarty: do you have an example of this?
* hcarty adds notes to to-be-released libraries so that this isn't forgotten
<hcarty> rgrinberg: Agreed!
<rgrinberg> hcarty: Yeah, I wish more libs did this.
<rgrinberg> hcarty: Ill make an issue to track this btw. Perhaps it's worth separating the options that modify run settings and options that have different actions (like printing the routes)
<hcarty> rgrinberg: Exposing the cmdliner terms/args would be useful

2016-06-15

<hcarty> seliopou: Are you interested in LE/BE number parsing in Angstrom? (8,16,32,64)bit integers

2016-06-13

<hcarty> Bah, wrong window...
<hcarty> ls
<hcarty> Is there an equivalent to `opam-admin make -r` for compiler definitions?

2016-05-27

<hcarty> Ah, I just saw the PR to do so and discussion around it
<hcarty> seliopou: Do you think you'll be moving Angstrom away from cstruct?

2016-05-25

<hcarty> LE/BE numbers that is
<hcarty> seliopou: For Angstrom, is it worth adding raw LE/BE to the library?
<adrien> hcarty: most recent thing I knew was that they had either given up or weren't really supporting it
<Drup> hcarty: I haven't, but you can ask everything to seliopou
<hcarty> ?
<hcarty> Drup: You've mentioned Angstrom a few times - have you used it at all/
<hcarty> adrien: MXE can do dynamic linking FWIW

2016-05-24

<hcarty> mrvn: If they segfault please submit a bug!
<hcarty> I haven't tried async parallel. I use zeromq more or less daily and am quite happy with it overall
<hcarty> flux: Or a feature request
<hcarty> flux: That would be useful... submit a PR to lwt-zmq with the appropriate scaffolding :-)
<hcarty> flux: And listening for multiple senders
<hcarty> flux: Not channels, just bytes
<flux> hcarty, 0mq for ocaml allows passing channels easily from process to process?
<hcarty> flux: zeromq maybe?

2016-05-23

<aantron> companion_cube: seliopou: Drup: hcarty: proposals to change Lwt_stream and/or include something else in Lwt (or factor streams out) are welcome. id rather not keep something people dont want to use, even if it takes a long time to fully phase out. as for me as a user, i have no strong opinion on Lwt_stream, but the interface does frighten me slightly