2014-03-14

<hcarty> Drup: :-)
<hcarty> In this case I'd prefer to pack as the module names I'm using are fairly generic.
<hcarty> Drup: Do you have an example you're willing to share?
<hcarty> Drup: Build
<Drup> hcarty: do you get error on build or on install ?
<hcarty> Ah, thanks. I'll expand my search then
<hcarty> s/result/results/
<hcarty> So the packed result will have Foo.Lib.(...) and Moo.Lib.(.-.), for example
<hcarty> smondet: Same name, different directory
<hcarty> I get cmi mismatch errors
<smondet> hcarty: same modules? or same name in different directory?
<hcarty> Library foo ... Modules Bar Baz.... Library mooo ... Modules Bar Baz ...
<hcarty> Is it possible to build two libraries defined in a single _oasis when both libraries and packed and each library shares sub-module names?

2014-03-07

<troydm> hcarty: no, i think that's probably not it
<troydm> hcarty: is that monadic bind? like in haskell >>=
<hcarty> troydm: That's what it's doing. Think of it as | in a shell.
<troydm> hcarty: http://cranialburnout.blogspot.ca/2013/09/database-radiation-hazard.html <- that doesn't looks to me that way
<hcarty> troydm: It applies the function on the right to the value on the left (ex. x |> f = f x)
<hcarty> flux: I played around with lablgtk + React a bit in a simpler form - https://github.com/hcarty/gtk-light/blob/master/gtk_light.ml#L103

2014-03-06

<hcarty> Get merlin working as soon as you're able. And spread printf calls everywhere.
<hcarty> Everyone starts out as a novice :-)
<hcarty> You would need a semicolon at the end of the line
<hcarty> I doubt it does, but it seems like a fairly large and complex piece of software
<hcarty> If the application plays with stdout
<hcarty> appleby: Though I have no idea how that will interfere with the rest of the application
<hcarty> appleby: If all you want is the raw value, you can use: printf "posn_lat: %f\n" wgs84.posn_lat
<appleby> hcarty, would you say I can print out posn_lat by using something like printf " {%d, %d, %.0f}, /* 1e7deg, 1e7deg, cm (hmsl=%.2fm) */ \\\n" (convert_angle wgs84.posn_lat) (convert_angle wgs84.posn_long) (100. *. float_of_string alt) (Egm96.of_wgs84 wgs84)
<hcarty> s/actuall/actually/
<hcarty> I don't remember what I actuall edited though. ~/.emacs.d/something maybe.
<hcarty> The last time I used emacs I remember having to edit a different configuration file than the one the documentation I looked at specified...
<hcarty> s/doesn't work/can't be made to work/
<hcarty> I'm not a Mac or emacs user (Linux + vim) but I'd be surprised if that combination doesn't work.
<hcarty> Sure
<hcarty> appleby: posn_lat looks like it's a float
<hcarty> appleby: No?
<hcarty> AltGr: Thanks. Good to know.
<hcarty> AltGr: Does the opam-version field specify the minimum supported opam version for a package?
<hcarty> Exactly! No one knows it isn't persistent.
<hcarty> AltGr: Indeed
<hcarty> flux: When the results are as impressive as merlin and ocp-indent, I'm ok with as many useful ones as people want to make :-)

2014-03-04

<hcarty> Ah, I didn't realize that. That's nice.
<hcarty> Once the IO bits are split that is.
<hcarty> companion_cube: Very cool. That should (hopefully) come somewhat naturally once Batteries is split up more, correct?
<hcarty> companion_cube: Hello!
<companion_cube> o/ hcarty
<hcarty> avsm: Is there a plan yet on the platform side regarding standard libraries?
<hcarty> .away

2014-02-27

<hcarty> flux: All viable options
<flux> hcarty, I suppose I can write a C oneliner that spits out the value for the enumeration. or I could just implement the whole function in C, without using ctypes :)
<hcarty> flux: The matching integer values should be used from the OCaml side. You can use a ctypes view to partially automate mapping between an OCaml variant and a C enum/int value.
<hcarty> flux: No, I think those need to be mapped by hand or generated with a program in C.
<flux> hcarty, ..I suppose enumeration symbols won't work with ctypes?
<hcarty> (says one of the many people who hasn't written out these steps...)
<hcarty> avsm: Having those steps in writing would help identify the broken/extraneous bits
<hcarty> flux: It's easy to play with, even from the toplevel.
<flux> hcarty, ok.. I've been thinking of taking a look at it..
<hcarty> flux: If you are still looking at bringing in/binding a single C function, ctypes is a wonderful way to go.

2014-02-25

<hcarty> ocamlscript is quite nice. I find myself using it less and less as ocamlbuild improves.
<hcarty> adrien_oww: Indeed!
<adrien_oww> hcarty: definitely but at first it might be difficult :P
<hcarty> kaustuv: The syntax extension works for me in utop
<kaustuv> hcarty: I get that "error" as well
<hcarty> Tricky at times perhaps, but very effective
<hcarty> adrien_oww: Using something which requires knowledge of the OCaml runtime is a wonderful way to learn OCaml :-)
<hcarty> kaustuv: I can't test it here because #require "cow";; gives an interface error - http://vpaste.net/Aynbt
<hcarty> EmilPer: I don't think it's actively maintained. It may still work.
<hcarty> kaustuv: Maybe there is an issue with using the toplevel in a non-interactive way? Does the same code work if you copy and paste into a running toplevel?
<hcarty> kaustuv: Swap lines 4 and 5
<hcarty> kaustuv: I think you need #camlp4o before the .syntax line

2014-02-24

<hcarty> nlucaroni: Thank you!
<hcarty> oasis 0.4.2 breaks oasis2opam <= 0.3.6. oasis2opam already depends on oasis >= 0.3.0; I'd like to add a '<= 0.4.1' constraint to the opam definition as well.
<hcarty> What is the syntax to specify a range of version restrictions under opam?
<def-lkb> hcarty: yep, thx
<hcarty> def-lkb: ^^
<hcarty> rwmjones: ocaml-re has a glob-based regex module

2014-02-19

<hcarty> adrien_oww: It's a cylon duck?

2014-02-18

<hcarty> companion_cube: Splitting out the modules one at a time also allows users to take advantage of the work as its done rather than requiring a grand 3.0.0 release before anyone can try things out and comment.
<hcarty> companion_cube: Yes. In particular starting with IO since it is one of the major trouble spots when trying to split Batteries effectively.
<hcarty> companion_cube: I've tried to do the same in my free time. It's too much for a free time project I think :-) Starting with a core module should be easier though as it requires tracking fewer moving parts.
<companion_cube> hcarty: well the point is, you shouldn't link against all batteries
<hcarty> If you're trying to pull in a subset then being more explicit is probably a good thing
<hcarty> companion_cube: If you're already pulling in all of Batteries, what does that matter?
<companion_cube> hcarty: maybe. Pervasives is also a tough topic, because it depends on many things.
<hcarty> companion_cube: "open Batteries" seems like a good way to spell "open BatteriesAll"
<hcarty> flux: But if you don't want all of Batteries you'll be able to more efficiently grab smaller pieces
<hcarty> flux: I think the intent is to still provide the ability to "open Batteries"
<companion_cube> hcarty: hmmm, interesting
<hcarty> companion_cube: That gives something to test against, both from an interface and a performance perspective
<hcarty> companion_cube: A nice first step toward splitting Batteries may be creating stand-alone versions of the problematic modules (IO and Enum or whatever replaces it)
<companion_cube> hcarty: sounds harder, you have to abstract over a monad
<hcarty> companion_cube: Exactly. If it can be made to work easily with Lwt then I'm completely for it :-)
<hcarty> flux: I read something along those lines but I don't have a reference.
<companion_cube> hcarty: indeed. and having compatibility with ocamlnet wouldn't be bad ;)
<hcarty> companion_cube: Any other reasonable option seems like it would require a BatIOTypes module which seems excessive and unfriendly to iteroperability with modules outside of Batteries.
<hcarty> companion_cube: It seems like the best option
<hcarty> companion_cube: That seems like a reasonable approach. Are there any significant performance concerns?
<hcarty> companion_cube: Something along the lines of the object wrappers in BatIO?
<companion_cube> hcarty: any opinion of making IO.output/input object types, so that they don't depend on BatIO anymore?
<hcarty> njcomsec: I don't think so.
<hcarty> I haven't played with Gen yet so I may be missing something obvious
<hcarty> Gen.Restart rather
<hcarty> companion_cube: What does Gen offer over Seq?
<hcarty> 'In general' in my case doesn't involve IO or other side effects though. Enum has been fine for that use.
<hcarty> I've found Seq to be closer to what I want in general than Enum or Gen. Gen.Restart looks like it acts similar to Seq.
<Drup> hcarty: I'm also quite convinced that on "one shot" iterators, Gen would take the lead. But I didn't benchmarked that very properly
<Drup> hcarty: imho, Gen and BatSeq shouldn't really be compared directly. On the other hand, BatSeq and Sequence are really very close
<companion_cube> hcarty: also, Sequence is faster but intrinsically less powerful
<hcarty> Drup: Probably so :-) The implementation difference is somewhat subtle.
<hcarty> Thank you
<hcarty> Drup: So Sequence is faster than Seq which is faster than Gen according to this benchmark - correct?
<hcarty> Drup: Thanks - I am on the list. I must have missed that thread.
<Drup> hcarty: do you need a copy of the email or are you on the mailing list already ?
<Drup> hcarty: actually ... I did, it's in my email on the batteries-devel ml
<Drup> hcarty: no, but I can make one easily
<hcarty> Drup: Do you have a Gen vs BatSeq performance comparison?
<flux> ok, so this is something new? I thought my 'module aliases' hcarty meant the something like module Baz = Batteries_foo
<hcarty> flux: That's a good question that I don't know the answer to :-)
<hcarty> flux: module aliases in their place IIRC
<hcarty> companion_cube: I've been lurking on that conversation. I haven't had any time to spend on it so I haven't wanted to chime in yet.
<hcarty> And a monolithic wrapper is still possible if the IO piece can be figured out.
<companion_cube> hcarty: I'm still planning to split batteries into smaller, friendlier pieces
<hcarty> I'm very happy to see smaller, more focused libraries/modules popping up on opam. While I like Batteries, being able to pick and choose smaller pieces seems more friendly.
<hcarty> companion_cube: Hello!
<companion_cube> \o hcarty btw
<hcarty> companion_cube: Have you done a performance test on Gen vs BatSeq?

2014-01-31

<hcarty> gasche: Do you have any interest in looking at the GADT-using code I mentioned a week or few ago?

2014-01-27

<adrien> hcarty: debian has a few patches which show nasty issues
<adrien> hcarty: ocaml-sdl might be something good to put in newhope :P
<hcarty> I haven't measured the performance loss to see how significant it is
<hcarty> companion_cube: Yes, although those may be mitigated/avoided if you use the upcoming stub generation functionality.
<hcarty> companion_cube: Ctypes is almost amazing. I expect that I will find it to be completely amazing once I am no longer ignorant of how to properly apply it.
<hcarty> companion_cube and adrien_oww: \o/
<companion_cube> o/ hcarty
<hcarty> The pahDriverList pointer is updated if it is not NULL. My attempt uses (string @-> int @-> ptr (ptr void) @-> returning t) where type t is a unit ptr.
<hcarty> Using Ctypes, what is the proper way to send a pointer-to-a-pointer (ex. void **) to a function which will allocate a pointed-to value if the given point is not null? The specific function I'm looking at wrapping is: http://www.gdal.org/ogr/ogr__api_8h.html#a2da3630231780d519543d1679c83e62f

2014-01-23

<hcarty> gasche: If you have time to look, the GADT-using code I mentioned earlier in the week - https://github.com/hcarty/indexmap/blob/master/indexMap.mli and https://github.com/hcarty/indexmap/blob/master/indexMap.ml
<hcarty> gasche: ping

2014-01-22

<hcarty> nicoo: Agreed too.
<hcarty> bernardofpc: Agreed
<nicoo> hcarty: Regarding basing it on RWO, we would have to choose between OCaml/Core and OCaml. (And RWO is frustrating w.r.t. not specifying what is syntax extensions and what is vanilla OCaml)
<hcarty> Something based on OCaml From The Very Beginning or RWO, depending on the audience you want to target.
<Kakadu> hcarty: I think that too
<hcarty> Kakadu: A well designed OCaml course would be nice to have on Coursera. I think it could help in promoting the language.
<hcarty> ?
<hcarty> Does ctypes provide a way to create custom blocks, along the lines of http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual033.html#toc150 (section 19.9 in the manual)

2014-01-20

<hcarty> gasche: Ok, thank you
<hcarty> (int, float) IndexMap.ro vs (int, float Lwt.t) IndexMap.ro
<gasche> hcarty: no time to look before the middle of the week, I'd recommend that you ping me again with that; but it does sound interesting
<hcarty> ex. int vs int Lwt.t
<hcarty> 'e would change in the Lwt case
<hcarty> I wasn't sure if that would make it more or less readable
<hcarty> companion_cube: Both 'u and 'w, yes
<hcarty> Just be warned that you may end up with types that look like this: https://github.com/hcarty/indexmap/blob/master/indexMap.mli
<hcarty> It should be possible. Maybe tricky at first, but possible.
<hcarty> val set : ('i, 'e, 'u, 'r * write) t -> 'i -> 'e -> 'u
<hcarty> 'update_result_type would be fixed as unit for anything which is monad-ish
<hcarty> ('index_type, 'element_type, 'update_result_type, 'permission) t is not the shortest type around, but I'm not sure how to make it shorter and still allow easy use with Lwt and Batteries, for example.
<hcarty> companion_cube: GADTs are quite cool. The added type safety is nice, although all of the additional type annotations can be difficult to track.
<hcarty> I'm not sure if it shoudl go into Batteries directly or exist separately with a package to wraps some Batteries types (see batIndexMap.ml in the same repo)
<hcarty> companion_cube: OR batteries! :-)
<hcarty> companion_cube: It's not easy compared to some things, but I think it is easier than the phantom type version
<hcarty> And I think it's much nicer in this state. I'll get it into opam at some point.
<hcarty> companion_cube: Yes
<hcarty> If you have time to look, do you have any recommendations for improvement? This was my first attempt at using GADTs for something other than a throw away example.
<hcarty> gasche: Regarding GADTs in place of phantom types - I tried that for a simple module and think the resulting implementation is nicer than the phantom type version: https://github.com/hcarty/indexmap/blob/master/indexMap.ml
<hcarty> companion_cube: Agreed
<hcarty> The issue wasn't immediately obvious. Which seems to be a common theme in the lazy realm.
<hcarty> Those are fine too :-)
<hcarty> Or go with adrien_oww's suggestion and use ( land ) and ( lor ) :-)
<hcarty> I'm ok with ( + ) - it is a reasonable choice
<hcarty> companion_cube: ( <-- ) is the one I've had the most reasonable uses for. The others are less important in my experience.
<hcarty> adrien_oww: Much better :-)
<hcarty> So not very xorish in context
<hcarty> companion_cube: ( ^ ) is used for string concatenation in OCaml
<hcarty> ( + ) reads as "add"
<hcarty> "
<companion_cube> hcarty: yes, I see
<hcarty> gasche: Agreed. IRC is useful but not particularly permanent
<hcarty> companion_cube: Which I can add to the bug report too, but wanted to point out here while on the subject of Batteries
<hcarty> companion_cube: https://gist.github.com/anonymous/8523906 -- A possibly overly developed list of infix options for BatSet and BatSet.Make
<hcarty> And that defeats the purpose of using Seq
<hcarty> Updated with your prettier example :-)
<hcarty> The fix really involves changing the behavior and signature of BatSeq.Exceptionless.combine, so again this may be something that has to wait until 3.0 for a full fix.
<hcarty> I added that snippet to the bug report.
<hcarty> Sorry, rather BatSeq.Exceptionless.combine still gives a sequence which raises an exception when you try to consume it.
<hcarty> companion_cube: BatSeq.combine still raises an exception for this example -- Seq.Exceptionless.combine (Seq.of_list [1;2]) (Seq.of_list [1]) |> Option.get |> Seq.iter (fun _ -> print_endline "hello")
<hcarty> companion_cube: Regarding Batteries bug 418 - why does the refernced bug fix help? (https://github.com/ocaml-batteries-team/batteries-included/issues/418)
<gasche> hcarty: I don't remember, but I think it is incubating (or at least should be)
<hcarty> avsm: Thanks, I'll do that.
<companion_cube> hcarty: I don't know this. thelema or gasche may know
<avsm> hcarty: would recommend creating an issue for ctypes. the forthcoming stub generation will indeed support this via 'views'
<hcarty> companion_cube: Is BatteriesExceptionless considered to be under the incubator umbrella or is it official and unbreakable until 3.0.0?
<hcarty> companion_cube: `true | `false so you can extend at will :-)
<hcarty> adrien_oww: That's what I'm thinking too.
<hcarty> I'm curious to know if there is a clean way to do the same with ctypes. I expect that the answer is along the lines of "yes but not that clean"
<hcarty> The zeromq bindings (which are what I'm looking at now) handle this with some compile-time C stub #defines
<hcarty> flux: Indeed :-)
<hcarty> flux: I'm not using Windows for anything OCamly at the moment but I'd rather avoid explicitly breaking things there
<hcarty> flux: I do - but unfortunately the representation is different on Windows.
<hcarty> Is there an official/proper way to send/get a file descriptor to/from a C function using ctypes?

2014-01-17

<companion_cube> hcarty: are you here? :)

2014-01-06

<hcarty> Drup: That's the best I've been able to come up with too.
<Drup> hcarty: I would say multiple conf-* packages
<hcarty> For example, on Debian you might need '--enable-jasper --enable-jpeg --enable-png' while a custom build of the underlying C library may require '--enable-openjpeg --enable-jasper --enable-png'
<hcarty> How should something like this be handled in an opam-friendly way? There are already configuration flags in the library's _oasis file - I want to make sure I expose those in a flexible and useful way in the opam metadata.
<hcarty> Debian/Ubuntu configure their package with one JPEG library, Fedora/EPEL use another, and building by hand provides a third option
<hcarty> I'm working on getting several packages ready for opam. One of them is a binding to a C library which can be linked against a number of supporting libraries (different JPEG 2000 implementations).
<hcarty> avsm: I doubt I'll be able to contribute beyond testing whatever implementation(s) are available, but if that changes I'll be sure to send a pull request
<avsm> hcarty: yeah, although patches before are welcome. see the HTTP_CLIENT ticket for thoughts on how it should work
<hcarty> flux: And it probably does make sense to have that function and write_file in BatFile.
<hcarty> flux: There is a BatPervasives.input_file function which slurps in an entire file at once.
<hcarty> avsm: Is Lwt HTTPS server support planned for Cohttp?
<hcarty> companion_cube: I don't think so - just here
<companion_cube> hcarty, gasche: is there a batteries irc chan?

2013-11-13

<adrien> I know hcarty has worked on it but more recently, I don't know who's maintaining it

2013-10-15

<hcarty> gasche: non-compiler-developers that is.
<hcarty> gasche: Are non-developer comments/questions welcome on Mantis for things other than bugs, such as the inline record discussion?

2013-09-05

<hcarty> gasche: Your 'if I understand correctly' is correct
<hcarty> gasche: Thank you for the clarification on ocamlbuild. It looks like something may have slipped through into 4.01.0, maybe a partial commit somewhere.
<gasche> rks` , hcarty : -use-ocamlfind is not default for 4.01 as far as I know
<hcarty> rks`: Thanks
<hcarty> wmeyer: ping
<rks`> hcarty: ping wmeyer
<hcarty> gasche: Are these differences covered by the existing ocamlbuild bug reports or should I file something new?
<hcarty> without -use-ocamlfind
<hcarty> Similarly, adding "true: package(batteries)" to _tags fails
<hcarty> That's a strange difference
<hcarty> rks`: It apparently isn't. That fails trying to find Batteries.
<rks`> hcarty: what about "ocamlbuild -tag package(batteries) test.native" ?
<hcarty> But it's a known bug - http://caml.inria.fr/mantis/view.php?id=5406
<hcarty> rks`: With "open Batteries" in test.ml, "ocamlbuild test.native" fails as expected. "ocamlbuild -package batteries test.native" works but gives a warning saying 'Warning: tag "package" does not expect a parameter, but is used with parameter "batteries"'
<hcarty> rks`: On 4.01.0 a simple test makes it look like there is some kind of default support but it may be a little broken

2013-09-04

<kerneis> hcarty: oh this is good news
<hcarty> avsm: Regarding my cohttp question - if I use 'time curl -i -X POST -d "a" http://127.0.0.1:8080/' then the POST time is effectively the same as GET
<hcarty> warn_A-44 seems to do what I want, sorry for the noise.
<hcarty> ocamlbuild -documentation makes it look like there isn't but I thought I saw it in a project at one point
<hcarty> Is there a way to disable a warning by number in _tags?
<hcarty> It's (hopefully) too late for new syntax to make it into 4.01.0
<hcarty> def-lkb: I asked about M.() on the original bug report (http://caml.inria.fr/mantis/view.php?id=5980). I'll see what comes from that first.
<def-lkb> hcarty: it may be worth opening a bug report
<hcarty> I expect a ppx could fix that nicely
<hcarty> I like the warning but without some kind of M.!( ) or similar support it's too noisy to use in my code.
<def-lkb> hcarty: yes, … it's just a compromise
<hcarty> def-lkb: In order to limit the scope of the open that is
<hcarty> def-lkb: You can, but the whole thing would need to be wrapped in '( ... )' or 'begin ... end' which kills the concision
<def-lkb> hcarty: no
<hcarty> Is there an equivalent to open! in OCaml 4.01 when using the Module.( ... ) syntax?
<hcarty> sgnb: It sounds like those benchmarks are against GET requests though. That paste's GET handling seems nice and quick. The slow POST is what currently concerns me with cohttp.
<hcarty> sgnb: Thanks for the link. I should look at ocsigen too. I am/was looking at cohttp first since it's relatively light but ocsigen does have a lot of useful extras.
<hcarty> companion_cube: It does have a client library, not sure about CGI.
<hcarty> companion_cube: That's my initial impression but I just started playing with it
<hcarty> avsm: Using 4.01.0rc1 and cohttp 0.9.10 from opam
<hcarty> avsm: I'm testing with 'time curl -i -F "hi=" http://127.0.0.1:8080/' and 'time curl -i http://127.0.0.1:8080/'
<hcarty> avsm: http://vpaste.net/adQL8 -- This minimal cohttp+lwt server is slow (~1 second) to respond to POST requests. Is that normal/expected? HEAD and GET requests are quick (time says 0.008 seconds).

2013-08-29

<thomasga> hcarty: the hard (and boring) part is lifting functions I guess
<hcarty> Copied and pasted from a utop session so it's not the prettiest formatting
<hcarty> thomasga: I have something for one source module but I haven't puzzled through/looked up the syntax for multiple source modules
<hcarty> Is it heavy enough to impact the performance of your program?
<hcarty> It's all in BatText
<hcarty> The UTF8 support in Batteries isn't using Camomile anymore which may be why the functionality has changed.
<hcarty> pippijn: I haven't used BatUTF8, but I expect you could work around the issue by using BatText.of_string and BatText.fold.

2013-08-28

<hcarty> pippijn: The old Batteries list comprehension extension is available from opam as pa_comprehension IIRC
<hcarty> *packaged
<hcarty> pippijn: The syntax extensions are pacakged separately now
<hcarty> pippijn: It was removed with the Batteries 2.0 release
<hcarty> Yeah, that is an opam annoyance. If there isn't a bug already for it it's probably worth opening one.
<hcarty> pippijn: You need to install conf-libev (or something similar) to enable libev support
<hcarty> Does anyone here have a suggestion for where to stay (or not stay) in Boston for ICFP/OUD?

2013-08-07

<hcarty> technomancy: You're welcome. I've been using that bit of syntax a lot recently.
<technomancy> hcarty: cool; I tried it but was missing the parens
<hcarty> technomancy: You can use as in function argument. For example, let f ({ x; y } as point) = ...
<hcarty> smondet: Thanks for the Unix.setsid tip for killing a tree of child processes. It works well for what I need.
<hcarty> avsm: That's what I expected. Thanks.
<hcarty> avsm: There is a paragraph I have a few questions about - would you prefere one topic per comment or grouping multiple in a single comment?
<hcarty> avsm: How granular should RWO comments be?

2013-07-31

<hcarty> One level of child processes that is. I haven't tested processed nested more deeply than that.
<hcarty> For anyone interested, that set of steps does seem to work at least one level deep.
<hcarty> It looks like Unix.setsid ... (set sigX handler) ... Unix.kill 0 Sys.sigX ... (reset sigX handler) ... (continue on) ... may work
<hcarty> adrien: Yep, too recent unfortunately. Needs to be able to run on RHEL 6/CentOS 6.
<adrien> hcarty: maybe through CHILD_SUBREAPER
<hcarty> adrien: Wishful reading on my part
<hcarty> I have at least a few cases where that's not a (simple) option. On to testing process groups!
<hcarty> I misread the documentatio... it looks like prctl needs to be called from the child process rather than the parent to have this work.
<hcarty> smondet: Thanks, I'll take a look at that
<smondet> hcarty: (not sure) but Unix.setsid should create a process group, then
<hcarty> rks`: Thanks for the tip about where to look in Core. I'm not using it but I may be able to pinch the relevant bit of code if it's already there.
<hcarty> mrvn: If I write something I'll pass it along
<hcarty> there
<hcarty> adrien: Yep, didn't see it tehre
<hcarty> It was one of the results I found when looking for something in OCaml
<hcarty> I think that there is a Python binding
<hcarty> adrien: Assuming that works as described :-)