2016-05-23

<hcarty> s/aquiring/acquiring/
<hcarty> Will aquiring the runtime lock work with a cstubs-based funptr?
<hcarty> But the fact that you don't know when looking a stream if it's consumer- or producer-driven is a problem
<hcarty> seliopou companion_cube: I like that consumer-driven is an option in Lwt_stream - that's handy when you want to be fully bound by the consumer's usage rate
<companion_cube> we discussed it with hcarty
<hcarty> frefity: You need to bind the result, something like "let%lwt ic, oc = Lwt_io.open_connection ... in ..."
<hcarty> dsheets: Ah, cool - I didn't realize it was safe to call caml_*_runtime_system inside a bare C function. But I suppose it makes sense that it would be safe as long as that function is only called from a properly wrapped stub.
<hcarty> dsheets: Thanks, I'll take a look
<dsheets> hcarty: take a look at my ocaml-unix-fcntl or ocaml-unix-dirent packages, i have util c files which release the lock. yallop has some related work for lwt job wrapped bindings in the pipeline which may also solve this deficiency
<hcarty> That's fun
<mrvn> h<tab> completes to hcarty, johnelse leaves, h<tab> completes to hannes, butts_butts leaves, h<tab> completes to hcarty again. *grrr*
<hcarty> The calls will take seconds to minutes, so pretty long running :-)
<hcarty> mrvn: If I can include arbitrary C statements in stub generation I'll use that - not sure it's possible yet though
<hcarty> mrvn: They use the CPU fairly heavily and, in order to be useful in the context I need the bindings for, I need them to run concurrently with the rest of the program
<mrvn> hcarty: do they take long? do they block? Otherwise just add (* FIXME: release runtime *)
<hcarty> Not without significant extra effort at least
<hcarty> mrvn: I'm hoping for a workaround until formal support is available. I have libffi-based bindings working fine, but I'd like to bind some local C convenience functions too without having to mix FFI methods. Not sure that's going to work though
<mrvn> hcarty: I think they are working on that
<hcarty> What is the proper work-around for this?
<hcarty> I have some bindings using ctypes that currently use Foreign's release_runtime_lock. I'd like to move to stub generation because it will make binding some local C code easier. However stub generation doesn't give the option of releasing the OCaml runtime lock.

2016-05-19

<hcarty> mfp: react has > 42k :-)
<hcarty> mfp: s/react/reason/

2016-05-17

<icicled> hcarty: gotcha thanks
<hcarty> icicled: You need to pin ppx_deriving and ppx_deriving_yojson to their dev repos under 4.03.0 for now
<hcarty> companion_cube: Thanks for the link
<aantron> Drup: hcarty: companion_cube: thanks!
<hcarty> Drup: Oh right, those functions don't return threads
<Drup> hcarty: no, it's really Result.ok
<hcarty> companion_cube: aantron: I back companion_cube's PR, I'm not making a separate one. And I look forward to dropping my internal version of this :-)
<hcarty> Drup: I guess it would be Lwt.return_ok ok/Lwt.return_error exn
<hcarty> I ask because I've never used either
<hcarty> How were make_value and make_error used previously? What would their replacement if they're deprecated?
<hcarty> companion_cube: So fast!
<hcarty> companion_cube: If you want to add return_ok/return_error with (possibly?) less typing - http://vpaste.net/9lP7W
<hcarty> As companion_cube said, there isn't much difference and 247 is more complete than what I would have proposed
<hcarty> s/I think//
<hcarty> I think I'm ok with keeping the discussion in companion_cube's PR
<aantron> hcarty: two PRs are welcome for review, but you can put something like "discussion in 247" in the description to link to the first
<hcarty> I was following pvem's naming IIRC
<hcarty> companion_cube: :-)
<hcarty> Along with Lwt.return_ok and Lwt.return_error
<hcarty> companion_cube: Different names mainly...
<hcarty> aantron: WOuld you prefer two PRs or discussion in one?
<hcarty> My interface is slightly different
<hcarty> companion_cube: Beat me to it!
<companion_cube> (ah, hcarty too)
<hcarty> Drup: aantron: Thanks
<aantron> hcarty: i prefer 'ok/'error at least in the declaration. long function signatures with multiple mentions of the type variables should probably use 'a/'e
<Drup> hcarty: doesn't matter, do as you feel
<hcarty> And if ('ok, 'error) what name would you use for a transformed 'ok or 'error?
<hcarty> aantron, Drup: Do you have a preference on ('a, 'b) result vs ('ok, 'error) result when naming labeling type parameters?
<hcarty> aantron: I can submit something now/soon
<aantron> hcarty: companion_cube: channel: you are invited to submit proposed Lwt_result modules (or other approaches to Lwt and result) to resolve https://github.com/ocsigen/lwt/issues/226. i will eventually focus on this. i still have things in the queue first, but it would be nice to give interested people some more time to discuss. thanks in advance for any PRs :)
<hcarty> Algebr``: Ouch
<hcarty> Avoid the frustration of a stale setup.data
<hcarty> Drup: That would be quite nice
<Drup> hcarty: probably going to be there in next opam
<hcarty> On the todo list
<hcarty> Drup: Thanks - I've recent started having to switch between several switches regularly. Now I want a bash function to automatically do this when I change into a directory...
<hcarty> Algebr``: That's what I was going to suggest :-) And if you end up needing duplicates of one or more the values in the table could be Lwt_pool.t
<hcarty> Is it ok to "eval $(opam config env --switch=MY_SWITCH)" to use MY_SWITCH just in the current terminal session?
<hcarty> aantron: Thanks
<aantron> hcarty: ignore the appveyor failure, thats still a work in progress
<hcarty> Drup: I've seen it with Lwt_preemptive and when I've had to work with code using Core
<hcarty> It seems to be a common thing - anything that requires threads seems to also require the user to pass the appropriate threads tag/package/etc
<hcarty> Drup: Is that all it is? A forgotten META dependency?
<hcarty> Drup: Why is that necessary? Is it because it's possible to pick between threading implementations?
<aantron> hcarty: thanks!
<hcarty> aantron: https://github.com/ocsigen/lwt/issues/245 - reminder added :-)
<hcarty> aantron: ocamlfind may be able to, but I always see "threads" listed explicitly, when, say, code uses "core" which requires threads. I suspect it has to do with the vmthreads/system threads split, but I don't know if that's actually the case.
<Algebr``> hcarty: found it
<hcarty> aantron: agreed re: docs
<hcarty> Algebr``: tag(threads) -- or maybe tag(thread), I can't ever remember which
<hcarty> Algebr``: I've been lucky so far - "just" using Lwt_io or zeromq has been fast enough
<Algebr``> hcarty: so how to fix?
<hcarty> Algebr``: That's a common annoyance... and I don't know why ocamlfind doesn't/can't do the -thread stuff on its own
<Algebr``> hcarty: also a blog post I've been meaning to write
<hcarty> aantron: "How to do IO with Lwt" would be a very nice article to have
<hcarty> aantron: I'm happy to help where I can. Thanks for your recent Lwt curation :-)
<aantron> hcarty: np, i would appreciate it if you amend the existing commit in the current PR, though. and let me know when you are done making edits to it, then i will merge :)
<hcarty> aantron: Agreed. I'll make edits as I have time and submit PRs
<aantron> hcarty: "Creating pools" is also a bit useless in the module brief. perhaps "resource pools" ?
<hcarty> I'll submit a PR
<hcarty> Algebr``: Would it be better if the doc comment for 'a Lwt_pool.t read more like: "Type of a pool containing values of 'a"

2016-05-11

<hcarty> mfp: Thanks!
<hcarty> hannes: A PR would likely be well-received too
<hcarty> rgrinberg: Please let me know how it goes
<rgrinberg> hcarty: that's awesome, thanks. I have a co-worker that also uses atom. He might be happy that he can use merlin now.
<hcarty> I haven't used atom before but some of the people I work with do and really like it
<hcarty> rgrinberg: It appears so - https://atom.io/packages/search?q=ocaml
<rgrinberg> hcarty: there's an atom setup? I wasn't aware there's a merlin atom plugin?
<hcarty> *handful
<hcarty> mfp: Right now I have result, rresult, astring, cmdliner, uint and zmq
<hcarty> mfp: I have a few and don't want to duplicate too much of your work if you already have a suite of packages ready to go
<hcarty> mfp: Are you still planning to push a hanful of packages out to opam-cross-windows?
<hcarty> I'm happy with vim + merlin + ocp-indent + lots of plugins... and can completely understand why someone wouldn't want to have to deal with all of that
<hcarty> I've been wanting to get time to try the suggested atom setup to know if it's worth suggesting to others

2016-05-10

<hcarty> dogdogdog: I'm glad it works, have fun with utop :-)
<dogdogdog> hcarty: it was indeed just a matter of setting that var
<hcarty> dogdogdog: Good luck
<hcarty> companion_cube: That too!
<dogdogdog> hcarty: thank you for your help
<hcarty> If pkg-config can't find ncurses maybe there's some other configuration that needs to be performed. I haven't used void linux before - you may be able to get things working by tweaking $PKG_CONFIG_PATH or some other pkg-config environment variable(s)
<dogdogdog> hcarty: void linux. yes
<hcarty> dogdogdog: What OS are you running? Do you have the development packages for ncurses installed?
<hcarty> companion_cube: \o
<dogdogdog> hcarty: unfortunately those are both empty
<companion_cube> o/ hcarty
<hcarty> dogdogdog: opam should point you to files with the stdout and stderr output of the failed installation which may help

2016-05-09

<hcarty> kobee: If someone can help they/we will

2016-05-06

<hcarty> edwin: The {build} tag should help with that

2016-05-05

<hcarty> So I don't have to do this manually for the stdlib libraries and others
<hcarty> Drup: Now I want opam to start installing the ocamldoc -dump blobs for each library :-)
<hcarty> Or something else, similar, which can produce cross-library links in documentation
<hcarty> Is opam-doc currently usable?
<lwzukw> hcarty: So I should report the problem to atdgen.
<octachron> hcarty, for precision's sake, 4.03 included
<hcarty> lwzukw: Last I looked atdgen still used some Obj trickery internally to make things faster. That may be breaking stricter rules in 4.03.0
<hcarty> lwzukw: I saw something about atdgen generating segfaulting code on 4.03.0 but I think that was with flambda
<hcarty> octachron: Thanks
<octachron> hcarty, except if you are not using ocamldoc but some other tools that reads directly the doc attributes, it still matters up to 4.03.
<hcarty> Ignoring backwards compatibility with pre-4.02.3 OCaml, does using (** *) comments for documentation vs attributes matter?
<epilys> hcarty, whoah you seem to be correct, no split there
<hcarty> epilys: You can try '#show String;;' in utop
<hcarty> epilys: Maybe it's an old version of core without that function? I'm down to almost blind guessing at this point
<hcarty> Does 'ocamlfind list | grep core' show you anything?
<hcarty> epilys: Are you sure core is installed?
<epilys> hcarty, I might have long ago, so I don't really remember
<hcarty> epilys: If you haven't been explicitly changing switches then that's most likely not your problem
<epilys> hcarty, how do I find core's switch?
<hcarty> epilys: If you're using opam is it possible you're in a different switch than the one which has core installed?
<epilys> hcarty, Gives me the same error
<hcarty> 'open Core.Std;;' works from utop
<hcarty> epilys: For me, '#require "core";;' then
<epilys> hcarty, I have tried "core.std" and "core" along with "core.top" and "core.syntax" which were there ever since I installed ocaml
<hcarty> epilys: I don't usually use Core so I'm not sure - "core.top" may not be the correct package name, but that's a guess
<epilys> hcarty, that gives me an "Error: Unbound module Core" error
<hcarty> epilys: I suspect you need "open Core.Std" in your code
<hcarty> gasche: And both are important steps!
<hcarty> Drup: Being clever for no reason can be a fun way to learn why/when to avoid more compex language features

2016-05-03

<whitequark> hcarty: one word: seaiq
<hcarty> whitequark: I didn't think that there was an intersection between OCaml users and the remote sensing/geography-focused folks beyond myself

2016-05-02

<hcarty> Algebr: Yes to mantis. And there is (was?) a "better errors" project which helped with errors like this. I don't know what happened to it though
<whitequark> hcarty: thank the person who paid me to do it, I guess
<hcarty> I have a few packages that I need to submit PRs for
<hcarty> whitequark: Thank you for opam-cross-windows by the way - it's worked very well for me so far, in combination with MXE
<hcarty> whitequark: I see the opam-repository PR. Yeah, it broke some CI stuff here, unfortunate timing on the build I think
<whitequark> hcarty: I killed it, yes
<hcarty> Oh... never mind, 1.0 doesn't exist any longer?
<hcarty> https://opam.ocaml.org/archives/ppx_import.1.0+opam.tar.gz - does not exist. Does opam.ocaml.org only mirror the latest version of a package?
<Drup> oh, right, what hcarty said
<hcarty> reynir: Other way around - it silences a warning if something is shadowed
<maker> hcarty: you can do also local opening annyways right?
<hcarty> maker: And you can do that locally if you're only using the module in a small scope: let module Pem_csr = X509.Long_module_name in (expression using Pem_csr)

2016-04-29

<hcarty> And the Jane St camlp4 syntaxes are all, as far as I know, locked to pre-4.03.0 versions of OCaml
<hcarty> companion_cube: \o
<hcarty> Apparently conduit still needs camlp4 stuff, or opam thinks that's the case
<hcarty> That's really strange then
<hcarty> Algebr: Or opam is confused... is it using the internal solver?
<hcarty> Algebr: Looks like something still depends on old pre-ppx Jane St libraries
<hcarty> Algebr: oasis from opam
<Algebr> hcarty: oasis from opam or pinned?
<hcarty> Algebr: I tried 0.4.6 today and it worked
<hcarty> Algebr: It should now
<Leonidas> hcarty: nice, installing.
<hcarty> Hooray - oasis 0.4.6 installs under OCaml 4.03.0
<hcarty> zozozo: Interesting, I didn't know that
<hcarty> please_help: Installed outside of opam?

2016-04-28

<cojy> hcarty: it's usually called arrow
<hcarty> 'type separating arrow thing' doesn't read well
<hcarty> zozozo: Specifically the arrow... I haven't been able to find a good name for it
<zozozo> hcarty: lambda abstraction ? function type ?
<hcarty> What is the proper name for '->' in OCaml type definitions and signatures?
<hcarty> Enabling or disabling flambda is currently a choice that has to be made when the OCaml compiler is compiled. Compilation with flambda enabled is slower than without, so that's at least part of the reason it is not the default option.

2016-04-27

<hcarty> Algebr: The implementation is pretty bare-bones. At the time I wanted bigarray mmap-like data access from Lwt
<hcarty> Algebr: No, it's something I wrote and packaged separately a while ago
<flux> hcarty, so the performance benefits were great, but sadly my data is (int, int8_unsigned_elt, c_layout) not (char, int8_unsigned_elt, c_layout) :-)
<Algebr> hcarty: is Lwt_binio in lwt itself?
<flux> hcarty, cool, seems like it fits the bill exactly!
<hcarty> flux: ocplib-endian uses some efficient externals
<hcarty> flux: ocplib-endian has some functions which may help. I wrote Lwt_binio on top of it
<hcarty> rgrinberg: Thanks. I've pinned to master so I think I'm caught up with changes locally
<rgrinberg> hcarty: will be released today. There might be some minor breakage wrt some things being renamed after the switch to hmap
<hcarty> rgrinberg: Thanks - the upstream library changes from camlp4 to ppx unfortunately caused an opium-using project to break just as I was convincing a group of colleagues to try it out
<rgrinberg> hcarty: Let me just release 0.15 into opam
<rgrinberg> hcarty: I expect cohttp/conduit pre ppx. Nothing exact though.
<hcarty> rgrinberg: Do you know which version constraints are required to make opium 0.14.0 build from opam?
<_berke_> hcarty: thanks, I'll just wait. besides I have to convert my whole codebase to use ppx_sexpconv it seems.
<hcarty> _berke_: Not yet, at least not without pinning some packages. I'm not sure which ones.
<hcarty> kaustuv: Leading to invisible breakage when moving from stdlib to extlib, for example
<hcarty> kaustuv: I agree that match .. with exception ... is nice. But I don't see how that's significantly different than returning a result type, aside from the result type being explicit in the type signature
<kaustuv> hcarty: yes.
<hcarty> kaustuv: What do you mean by using match-with-exception rather than monadic style? Raising rather than returning option or result types?
<hcarty> kaustuv: There is preparation work being done for a 3.0 release

2016-04-26

<hcarty> cojy: A mixture of C and a snapshot of the bytecode-compiled compiler
<hcarty> Algebr: Makes sense. For my immediate use, calculating the stringified checksum of a blob of bytes, the amount of code for both seems about the same.
<hcarty> There seems to be a lot of use of nocrypto rather than cryptokit. (a) Is that actually true? (b) If so, why?
<hcarty> companion_cube: pv?
<companion_cube> hcarty: p
<hcarty> companion_cube: \o
<companion_cube> o/ hcarty
<hcarty> gasche: I'd like to have .merlin auto-generate from the package(...) entries in _tags
<hcarty> gasche: Does ocamlbuild, either from a myocamlbuild.ml or its findlib-accessible modules, provide a way to inspect the content of a _tags file?
<hcarty> ocaml117: You can extend the module but you may not be able to do what you want with values of type t. That depends on what functionality is already exposed.
<hcarty> adrien: Is there documentation available? I've been using whitequark's opam repository for my limited Windows-targeting needs so far.
<hcarty> adrien: That cross-compilation news is good to hear
<hcarty> adrien: The toplevel didn't get backtrace support until some 4.x version. A recent one IIRC

2016-04-25

<hcarty> Algebr: It's a valid question. Honestly I think it's usually momentum and a lack of a big, "must-have" project to draw people in
<hcarty> It depends on what a person is coming to the site to see
<hcarty> Drup: Put the ocsigen shared drawing application on the front page :-)
<hcarty> rgrinberg: I completely agree, just to be clear. I avoid HN most of the time for that reason. And try to tread lightly when looking through proggit
<rgrinberg> hcarty: it's a legitimate concern. when it's brought up like this - in the context of a real use case.
<hcarty> Algebr: Fair - perception matters when trying to grow a community
<hcarty> rgrinberg: MXE + whitequarks opam-cross-windows repo made the whole process much nicer since I could avoid Windows for the most part
<hcarty> rgrinberg: I had to write some code for Windows and wanted to write it in OCaml. So it's by choice, but I am/was a suffering OCaml programmer targeting Windows
<hcarty> companion_cube: Why compete? We JS.
<Drup> hcarty: yes!
<hcarty> Drup: compiler-as-package?
<hcarty> Drup: Thanks :-) Just read about it
<Drup> hcarty: it's useful for profiling with perf (it will give call stacks)
<hcarty> Never mind... RWO has a section on the +fp compiler switches
<hcarty> What does the "with frame pointers enabled" switch add/change?
<hcarty> Thanks
<hcarty> Drup: Potential subtle version conflicts?
<Drup> hcarty: side note: it's not an abolutely great idea in general, at least not if you keep both repositories
<hcarty> :-)
<flux> hcarty, ok, got it, while ! opam update && opam switch .. ; do :; done
<hcarty> flux: If you want to avoid the delay you can add opam-repository directly as a remote
<hcarty> flux: "opam update" and there may be some delay between the commit hitting github and it being mirrored into the main/official off-github package list
<hcarty> Drup: Thanks
<hcarty> Is it safe to 'opam switch install 4.03.0 --no-switch' and continue using the current switch while the new switch is building?
<hcarty> Drup: Does Lwt 2.5.2 work on 4.03.0?
<hcarty> flux: Only if you use ppx... or oasis... or something that uses one of those!
<hcarty> companion_cube: No, what exists is enough to solve an immediate problem I was having. I'm hoping to have time later this week to look at it more
<companion_cube> hcarty: are you in a hurry for lwt-pipe?
<hcarty> \o/ - (Hooray-even-more!)
<hcarty> Drup: \o/ - (Hooray!)
<companion_cube> hcarty: no, create should deal with the idempotence of `close` by itself
<hcarty> The ability to close a Lwt_pipe.t at any time by anyone makes for some tough corner cases
<hcarty> companion_cube: This is what I currently have for of_stream: http://vpaste.net/pqVyA It seems like overkill but I'm not sure how to make it simpler with missing cases. And I'm still not sure I've caught everything that should be caught.
<hcarty> I'm not sure if the Invalid_argument exception is caused by the same thing or something else
<hcarty> I was running into this with of_stream and from and was assuming it came from those implementations but it doesn't. I think it's because the keep call in of_list closes the pipe.
<hcarty> companion_cube: But if you "Lwt_pipe.read p" more times after that you get the expected "None" returned
<hcarty> companion_cube: And if you try to "Lwt_pipe.read p" after that you get 'Exception: Invalid_argument "Lwt.wakeup_result"'
<hcarty> companion_cube: Something seems to be not right: let p = Lwt_pipe.of_list [1; 2; 3] in Lwt_pipe.close p (* raises Lwt_pipe.Closed *)
<hcarty> Lwt_pipe.from could be made to act like connect with an ownership argument allowing users to supply a "close" function if they want to
<hcarty> I think they should be there. It might be useful to have un-closable pipes. That increases the overall complexity more though.
<hcarty> s/abuse with/absuse without/
<hcarty> Agreed
<hcarty> companion_cube: The simple case for each is simple and useful... and easy to abuse with rust-like ownership rules
<hcarty> companion_cube: Hello! Regarding the Lwt_pipe kind-of-ownership thing I'm not sure. That, to/of_stream and a Lwt_stream-like "from" all come with rather ugly possiblities

2016-04-24

<hcarty> companion_cube: ^
<hcarty> I need to go and I'm not sure how to handle the early-close condition safely. I'll come back to it later in the week
<hcarty> I'm also planning to add a val from : 'a option -> ('a, _) t function, like Lwt_stream.from
<hcarty> I'll update to handle that case
<hcarty> companion_cube: Good point - I think the async exception handler would be called
<hcarty> companion_cube: PR with pipe <-> stream conversion. Does that approach seem sane?
<rntz> hcarty: thanks
<hcarty> So fast, thanks companion_cube :-)
<hcarty> I'm not sure if Lwt_io is available on mirage or js_of_ocaml or not
<hcarty> Just getting thoughts out
<hcarty> companion_cube: No rush!
<hcarty> companion_cube: And now that the result type is pulled out of the generic pipe type it may be worth replacing 'a step with 'a option
<hcarty> companion_cube: I'll have more time to spend on this later in the week, but a few lwt-pipe thoughts. It may be worth splitting out the IO piece into a separate, optional module to make lwt-pipe usable from js/mirage/other exotic places
<hcarty> rntz: Yes
<hcarty> rntz: (1) The language manual is well written (2) and includes documentation for the standard library. I've heard the .mli files are the best documentation for Core but I don't know if that is still true

2016-04-23

<twobitsp1ite> So, I asked earlier about Bigarrays with structs/records, and hcarty replied after I had gone AFK that I could use multiple separate arrays, one for each value I would use in a struct... That's actually something I was thinking about doing..

2016-04-22

<hcarty> I need to leave for now, but thank you! What's there already works after dropping it into my existing code. Take care and have a good night
<hcarty> The `r, `w permissions?
<hcarty> If it's read_exn then there's a hidden failure state
<hcarty> And in that case a user can explicitly write 'a Result.result to the pipe
<hcarty> Imagine: read a line -> if the line is valid then push (f line) to the pipe else repeat
<hcarty> s/this/my current/
<hcarty> But in this case if the producer fails it just moves onto the next item on its list of things to handle - downstream doesn't care about those failures so they never get written to the pipe
<hcarty> For Lwt_pipe.IO that's true
<hcarty> consumers that is
<hcarty> In my current use case the producer only pushes onto the pipe if there is a valid value to push and the consumer relies on that
<hcarty> I don't think there should be an assumption that failure is possible
<hcarty> My immediate use is a program which grabs files, does a bit of processing, then shoves the successful results into a stream/pipe
<hcarty> I would prefer that it not be in the base type, so for example a consumer of Lwt_pipe.read isn't forced to handle a potentially unused error case
<hcarty> companion_cube: Why is the error type built into the basic pipe?
<hcarty> companion_cube: Thanks - and I'm not sure for the .cm* files, I don't recall
<hcarty> It should. I have a few foo-bar libraries installed
<hcarty> My preference goes to lwt-pipe in both, but as long as they're consistent I'm ok with the naming
<hcarty> companion_cube: https://github.com/c-cube/lwt_pipe/blob/master/Makefile#L12 - lwt-pipe vs lwt_pipe (opam vs ocamlfind)
<hcarty> companion_cube: Thanks! I'll try it as-is, testing and noting any issues as I go
<hcarty> pinning now
<hcarty> Agreed
<hcarty> Sure, thanks
<hcarty> For Lwt_pipe?
<hcarty> companion_cube: And yes, a separate library would be good. I've needed this some kind of thing a handful of times. If I come up with something useful I'll contribute it back, either to Lwt_pipe or a new library if that makes more sense
<hcarty> Lwt_stream.from leaves the generation rate up to the consumer rather than the producer
<hcarty> The pull configuration of Lwt_stream is nice as I want the consumers to dictate the rate of stream progress
<companion_cube> hcarty: if you want, we can make a separate library for this
<hcarty> I'll give it a try
<hcarty> companion_cube: Thanks!
<hcarty> Ah, I see - containers-lwt
<hcarty> Ah, maybe that's what I was thinking of. Is that in Containers or outside of it?