<hcarty>
natrium1970: I've had to use Mac OS on occasion. If you use brew and install opam that way then I think it pulls aspcud automatically.
<hcarty>
Drup: Just thought I'd ask. Matching works well enough.
<Drup>
hcarty: no idea in general
<hcarty>
Drup: It's something I run into now and then but haven't come up with a satisfactory option to replace pattern matching.
<hcarty>
Drup: How would you avoid explicit pattern matching, and keep relatively clean code, when you have: match a_err, b_err with | Ok _, Error _ -> ... | Ok _, Ok _ -> ... | Error _, Ok _ -> ... | etc.
<hcarty>
companion_cube: ∅Caml?
<hcarty>
And implicit modules. I'm hoping I get all of my wishes within the next year.
<hcarty>
If we're wishing, I want a way to cleanly mix rresult with lwt!
<hcarty>
Drup: 'R.ok v' vs 'Ok v'?
<hcarty>
ggole: Separate
<hcarty>
Or you can match on the length, but that doesn't offer much over a few if branches
2015-10-09
<hcarty>
apache2: (two libraries available via opam)
<hcarty>
apache2: re or pcre
2015-07-02
<hcarty>
I recently learned that rename can fail on NFS even if the operation was a success. So I need to work around that.
<hcarty>
flux: Probably not enough for preemptive threads to be an issue. It's NFS, so there's definitely chances for slowness.
<flux>
hcarty, do you have a use case that involves doing that a lot/for slow file systems?
<hcarty>
flux: Yes, it looks like Lwt_preemptive.detach (Sys.file_exists path) would work. Heavy as Drup said, but it would work.
<hcarty>
Drup: If I come up with something useful I'll submit a patch :-)
<hcarty>
Something that comes out of the box with Lwt that is. I don't see anything that seems to map to Sys.file_exists in Lwt_io, Lwt_sys or Lwt_unix.
<hcarty>
Is there an Lwt-friendly way to check if a file exists?
2015-07-01
<hcarty>
companion_cube: That's a much better approach than a random comment on IRC :-)
<companion_cube>
hcarty: you could open an issue, that's an idea
<hcarty>
companion_cube: Thanks, that's good to know. Maybe it's worth adding a constraint in the opam repository?
<hcarty>
rks`: Thank you
<rks`>
hcarty: yes that should work
<hcarty>
companion_cube: On 4.02.1, if I use ppx_deriving 2.1 I get the issue. It goes away if I roll back to 2.0.
<hcarty>
rks`: Would/should a pin to master work?
<hcarty>
I have "PKG ppx_deriving.std" in my .merlin
<hcarty>
I'm getting "Cannot locate deriver eq" when using ppx_deriving in merlin but the same code compiles fine and can be used from utop. Any suggestions for how to diagnose this?
<hcarty>
That's not very helpful, self..
<hcarty>
I'm getting "
2015-06-26
<Denommus>
hcarty: also, does it support HTTPS?
<Denommus>
hcarty: what about parsing JSON?
<hcarty>
Denommus: Cohttp and the curl bindings are both usable as a client
<hcarty>
:-)
<hcarty>
Though I suppose I could handle that by grouping them appropriately.
<hcarty>
Drup: That's what I have currently. The number of enabled/disabled threads could vary.
<hcarty>
That's what I want in this case. Effectively Lwt.pick [if flag then real_thread else sleep_forever; other_real_thread; ...]
<hcarty>
Looks like it: Lwt.cancel (fst (Lwt.wait ())) returns immediately in utop
<hcarty>
Drup: Ah, of course. Thank you!
<hcarty>
Does Lwt include something like a "val never : 'a Lwt.t" which sleeps forever?
2015-03-20
<hcarty>
It doesn't give literals but it does allow prettier access
<hcarty>
ggole: Something similar is hopefully coming in 4.03
2015-03-18
<hcarty>
whitequark: What is the proper sequence of steps to use ppx_import in foo.ml for a type defined in foo.mli? I've tried several variations on this: https://gist.github.com/hcarty/0464098413faec3c354e
2015-03-02
<flux>
hcarty, well, they sort of still depend on the code being structured in a way that has a nice way to put them at
<hcarty>
flux: Why not stick with open_resource + close_resource in that case?
<hcarty>
Some kind of (let%use out = open_output_file outfile in e) extension would be nice to have but I'm not sure how it could be made generic without being ugly.
<hcarty>
companion_cube: And hooray for discovered bugs!
<hcarty>
companion_cube: I can file something formally if you'd like. I've only briefly looked at the code thought so I wasn't sure if I was missing something.
<Drup>
hcarty: it's a bit hard to answer without all the code
<hcarty>
Drup: Never mind. That call does cause a memory leak...
<hcarty>
Drup: Thanks for the help
<hcarty>
Drup: That's what I had and thought it was causing a memory leak. Apparently not though, the issue is elsewhere.
<Drup>
hcarty: well, it's safe if that's what your function takes
<hcarty>
Drup: Is it safe to use "ptr string" for the argument in this case?
<Drup>
hcarty: use "allocate" on a string, gives the pointer to the C function and then you're good
<hcarty>
How do I do the equivalent of this with ctypes? "char *foo = NULL; f(&foo); /* foo now points to a string allocated by f */"
2015-01-14
<struk|work>
hcarty: libplplot12 5.10.0-0ubuntu5 . It built really easily for me on (k)ubuntu. also worked without fail in utop etc.
<hcarty>
struk|work: Suggestions and contributions are welcome. Which version of PLplot are you working with?
<hcarty>
I haven't done much to test the build process beyond confirming that it works on the systems I need/use it on. There is a bit of wrangling required I expect to make the build play nice with opam-repository's travis builds. Shouldn't be too bad though.
<struk|work>
hcarty: great! ok I will double down on plplot given this new information. thanks
<hcarty>
struk|work: opam is planned of course, both an 'opam' file in the repository for pinning and a properly submitted package. Knowing someone else is using it motivates that effort a bit :-)
<struk|work>
hcarty: excellent. I intend to keep using it then. What are you thoughts on also publishing it to opam?
<hcarty>
struk|work: I'm glad to hear it! I do intend to keep that repository up to date.
<struk|work>
hcarty: hey, do you have any particular plans for https://github.com/hcarty/ocaml-plplot ? I found it much easier to work with than the main plplot repo
2015-01-12
<struk|work>
hey does anyone know if github user hcarty lurks in #ocaml?
2014-12-18
<companion_cube>
anyway, hcarty: on Buffer.add_channel, Damien's proposal can solve your issue about "identifying the bytes making up the partial request": compare the length of the buffer before and after the read
2014-11-18
<hcarty>
kaustuv: Another work-around is to "ocamlfind install ulex08 META" where META depends on ulex.
<hcarty>
companion_cube: smondet's pvem is actually exactly what I'm looking for, or close to it. So no need perhaps for something directly in containers.
<companion_cube>
hcarty: there is CCError -- although it is less general
<hcarty>
companion_cube: Something with a similar ('good, 'bad) t type
<hcarty>
companion_cube: Is there a (planned) containers equivalent to BatResult/(whatever Core has for this purpose)?
<hcarty>
The symmetry would be nice to have though
<hcarty>
nojb: Indeed
<nojb>
hcarty: I see, but you can do that today with match foo with [{Complex.re; _}; {Complex.im; _}] -> re, im …
<hcarty>
nojb: 'Complex.[{re; _}; {im; _] -> re, im' as one contrived use
<nojb>
hcarty: you can already do some of that with match foo with {Complex.re} -> re as several people mentioned
<hcarty>
It could be nice to have, for example, match x with M.[{field1; field2}; _] -> field1, field2
<hcarty>
It's probably worth filing a Mantis bug about that mismatch
<hcarty>
Drup: Sorry, meant that for nojb
<hcarty>
nojb: Sorry ^^
<hcarty>
Drup: But not in pattern matches apparently
<Drup>
hcarty: js_of_ocaml + the fact that batteries is slightly stuck for now
<hcarty>
Drup: Why the move from Batteries to CC if I may ask?
<hcarty>
Recent enough version of OCaml that is
<hcarty>
Module.(match ...) works too. And if you have a recent enough version dropping the 'open' entirely should work, though you'll get warnings by default.
2014-10-22
<hcarty>
Drup: And that fixes it! Thank you very much.
<hcarty>
Drup: Thanks, I'll try with the external solver for now. I'm reluctant to spend my time chasing down the aspcud dependency list.
<hcarty>
Build aspcud that is
<hcarty>
Drup: No. This is a CentOS 6 system so it's not pre-packaged that I know of. I haven't attempted to build from source yet.
<Drup>
hcarty: do you have aspcud ?
<hcarty>
Not quite what I was hoping for
<hcarty>
In the opam 1.2 case: === 1 to install | 40 to reinstall | 1 to upgrade | 19 to downgrade | 4 to remove ===
<hcarty>
opam 1.2rc4 wants to remove lots of packages and downgrade lots of others to update Lwt from 2.4.5 to 2.4.6. opam 1.1.1 on the same installation didn't have an issue with the upgrade. Any pointers on how to track down why this is happening?
2014-10-20
<hcarty>
thomasga: Looks that way. Thanks, will do.
<thomasga>
hcarty: report on the bug tracker, looks like a regression ...
<hcarty>
"port" not "post"
<hcarty>
I have a local repository with a package defined with a git URL (ssh://host:post/repo/#v0.1.0). This works under opam 1.1.0. Under 1.2.0rc4 I get "fatal: Couldn't find remote ref v0.1.0"
<hcarty>
Has the handling of git tags changed in opam 1.2.0?
2014-09-23
<Drup>
hcarty: see the mail "opam local switch" in the mailing list
<Drup>
hcarty: sort of, but there is no need
<hcarty_>
Is it safe to "opam switch install ..." a new compiler while using the current default switch in another terminal?
2014-08-20
<hcarty>
Is that a 1.2-ism? I don't see it in the help text. I'm still on 1.1.1.
<hcarty>
Is there a proper opam-way to retrieve (or write) an application with a set of dependencies and then install those dependencies? A functioning version of 'opam get-me-what-i-need-to-hack-on /path/to/my/project/'
2014-06-20
<hcarty>
mrvn: It may support something with its code generation backend. I've only used the libffi-based interface so far.
<hcarty>
mrvn: I don't think so in 0.3.0. The included finalization support uses Gc.finalise.
<hcarty>
It makes ocaml/utop/ocaml-top into easy C API exploration tools.
<hcarty>
mrvn: Yep. And Ctypes makes it very easy to experiment on the fly which is wonderful.
<hcarty>
To be clear, I really like Ctypes
<hcarty>
Ctypes gives a wonderful feeling of type safety right up until the segfaults start. Though I suppose That really could apply to C in general.
<hcarty>
Armael: I went with string_opt as the array element type to avoid extra super type unsafety
<companion_cube>
hi hcarty
<hcarty>
companion_cube: Hello
<Armael>
hcarty: just check that coerce doesn't raise an exception at runtime
<hcarty>
I'd used it before but initially didn't think to use it here.
<hcarty>
mrvn: Yes, that's what fixed it for me
<mrvn>
hcarty: then that is what you should use
<hcarty>
mrvn: None maps to null, Some s maps to the string s
<hcarty>
Armael: Thank you for your suggestions
<hcarty>
And it fixes the segfault!
<hcarty>
That seems more promising
<hcarty>
Or... make the array a string_opt array
<hcarty>
Not sure if that's the right approach... but it may work.
<hcarty>
Armael: CArray.set requires a string argument for the value being set
<hcarty>
Armael: Indeed, but how?
<hcarty>
Drup: Given a list of N strings, I need an N+1 element array to pass to the C library
<hcarty>
Drup: I don't think so, unless Ctypes initializes the array elements to NULL
<hcarty>
I effectively need a way of saying the equivalent of: CArray.set carray (n - 1) null
<hcarty>
How would I do this with Ctypes? Do I need to drop the use of ptr string and use ptr void with manual casts?
<hcarty>
The C function being called expects the last value in the 'string array' to be NULL
<hcarty>
I'm using Ctypes and need to pass a char ** value. So something along the lines of (ptr string -> returning void).
2014-05-22
<whitequark>
hcarty: sounds ok
<hcarty>
whitequark: I may have something of a fix for the lwt-zmq build errors in opam's Travis. In short, my hope is that using a PPA to install zeromq rather than building it from source will fix the linking issues.
2014-04-16
<hcarty>
flux: I expect so. It's possible to do. Certainly more complex than a naive sequential approach.
<hcarty>
flux: s/canvas/surface/
<flux>
hcarty, I think I can almost guarantee it's going to be more complicated than it is now..
<hcarty>
flux: If you do a memory-backed canvas then you can marshal the underlying storage
<mrvn>
hcarty: Ok. No wonder I couldn't find any Thread implementation in LWT.
<hcarty>
mrvn: Yes
<mrvn>
hcarty: but that then uses the ocamls Thread module, right?
<hcarty>
mrvn: Lwt_preemptive is the module IIRC
<hcarty>
mrvn: It can.
<hcarty>
mrvn: For some definition of "not terribly expensive"
<hcarty>
mrvn: It could be. Not terribly expensive if both processes are running on the same machine.
<mrvn>
hcarty: sending the full image might be costly.
<hcarty>
flux: One somewhat simple approach - Use zeromq to send bits back and forth. Have the decoding run in a separate process. It receives the filename/encoded bytes and sends back the decoded bytes as the decoding completes.
2014-04-14
<Drup>
hcarty, gasche : since both of you are there
<companion_cube>
hcarty: I understand totally
<hcarty>
companion_cube: To be clear, I'm looking forward to seeing your work on Batteries released. My concern is that releasing two versions of Batteries in an official way will make both seem obsolete and/or unstable.
<hcarty>
Unless 'batteries' is redone so that it is based on 'batteries-light'
<hcarty>
That's what seems dangerous to me. They are both called 'batteries' but they ultimately compete with each other.
<hcarty>
What would the new package be called? How would a user know which kind of Batteries to package/code against?
<hcarty>
But if this is a case of wanting to experiment before release then I think adding it to the official repository is rather dangerous.
<Drup>
hcarty: I would like not to wait 6 month.
<hcarty>
If we're going to call it 'Batteries 3.0' then official opam it up
<companion_cube>
the mismatch seems to be that Drup wants it in production, and hcarty as an experimental package ;)
<hcarty>
Drup: I agree. But for an experimental release I think it's better to keep things cleanly and clearly separate
<hcarty>
companion_cube: A separate testing repository which could be added by interested users may be nice.
<hcarty>
companion_cube: I don't think having two Batteries packages in opam is a good idea. Not in the official repository at least.
2014-04-11
<hcarty>
gasche: Thank you for the explanation. That makes sense.
<gasche>
hcarty: constructor+field selection is always driven by the constructor/field type, not the argument type; this makes behavior more robust to change in the code
<hcarty>
Rota: So for the earlier example from mrvn, you can have - type a = Foo of int type b = Foo of float let make_int x : a = Foo x let make_float x : b = Foo x
<hcarty>
Rota: OCaml 4.01.0 and newer allow you to have the same constructor name (and record field name) defined in multiple types in a single module. You can let the compiler try to infer the type the constructor belongs to or tell the compiler explicitly with type annotations.
2014-04-09
<adrien>
hcarty: there are important differences between the two
<adrien>
hcarty: not sure
<hcarty>
It will likely be a heated discussion when it happens.
<hcarty>
The Core vs (Batteries/ocamlnet/Lwt/etc) debate is something that probably should happen. It has not happened so far, at least not out in the open.
<hcarty>
utop is worth installing and trying. It has some nice features such as context-sensitive tab completion which make exploring the language easier.
<hcarty>
ebzzry: To be clear - utop is less controversial than library choices.
<jpdeplaix>
hcarty: to be complete, I'm using BatteriesExceptionless + ocaml-monomorphic
<hcarty>
jpdeplaix: Thanks!
<hcarty>
I've been using the Exceptionless modules in Batteries as well, so you answered my follow up question (is it worth switching)
<hcarty>
jpdeplaix: Ok, thanks.
<jpdeplaix>
hcarty: not anymore :/
<hcarty>
jpdeplaix: Do you use your monad-exn library regularly? How happy have you been with it?
<hcarty>
elfring: Regarding your cmake question - I have done some work with OCaml and cmake. It worked but was painful. Using oasis or ocamlbuild directly is a much better option if you have a choice.
2014-04-08
<hcarty>
It would be nice if Batteries maintained its current adherence to semantic versioning
<hcarty>
I'm not sure how their release numbering works as they seem to introduce backwards-incompatible changes without major version number bumps.
<hcarty>
companion_cube: Greetings
<companion_cube>
o/ hcarty
<hcarty>
companion_cube: Of course it's easy for me to say that as a Batteries user who only contributes code infrequently.
<hcarty>
companion_cube: I replied to your email, but to repeat - yes, more frequent releases! Particularly patch-level bugfix and backwards-compatible minor releases.
2014-04-02
<hcarty>
mk270: No hard deadline, but a fix in oasis is hopefully coming in 0.4.6 (two releases from now)
2014-04-01
<hcarty>
mk270: It works for a simple example using ocamlbuild only. If oasis is updated to support this then so much the better.
<hcarty>
mk270: Sure thing - I hope it's useful for you :-)
<jpdeplaix>
hcarty: no it's not really a bug. It's something hard to do
<mk270>
hcarty: how are people getting anything done, then?
<mk270>
hcarty: :(
<hcarty>
mk270: I think it's safe to say that this is a bug in oasis
<Drup>
hcarty: I don't find it anymore
<hcarty>
Drup: Do you have a link to the bug report? I searched through the bugs reported on the forge but didn't find anything
<mk270>
hcarty: ah ok - my code is already split up into directories - i could deepen the split and make a separate _oasis for each
<hcarty>
mk270: Packing your libraries should hide internal modules. Unfortunately that doesn't seem to work within a single _oasis file.
<hcarty>
mk270: What Drup said :-)
<mk270>
hcarty: do you mean "it's how oasis currently works"? or how something else in the toolchain does, e.g., ocamlbuild?
<mk270>
hcarty: i want to be able to split code across files
<mk270>
hcarty: cheers
<hcarty>
mk270: I don't know if it's expected, but it is how the tool currently works. It's caused me trouble in a project with two libraries which share internal module names.
2014-03-23
<companion_cube>
hcarty, adrien_, Drup: I removed Exceptionless modules
2014-03-21
<hcarty>
Starting out with foo, foo_opt/foo_res as appropriate is a step in the right direction
<hcarty>
adrien_oww: Agreed.
<hcarty>
Thanks to merlin I can neglect my browser while coding
<hcarty>
companion_cube: Indeed!
<hcarty>
My vote goes for _opt suffixes. The maintenance load should be less.
<hcarty>
companion_cube: I often want Sys.getenv to return a string option value. I'll submit a pull request at some point but want to structure it appropriately.
<hcarty>
companion_cube: Do you want to move your split batteries implementation to have *_opt versions of functions rather than BatFoo.Exceptionless modules?
<hcarty>
It's thankfully possible to think that a language is badly designed without thinking the same about people using the language.
<hcarty>
It works in both directions and isn't meant to be disparaging (sp?) in either.
<hcarty>
companion_cube: Both? :-)
<companion_cube>
hcarty: you mean that for many people, programming = PHP? :s
<hcarty>
Keep in mind that for many people, PHP = programming. If Hack nudges them in a positive direction that they wouldn't have been aware of otherwise then that's a good thing.
<hcarty>
Also, named matches are nice to have. I don't think ocaml-re supports them.
<hcarty>
Yes, the maturity of (PCRE and the OCaml bindings) is a large part of why I haven't moved existing projects over
<hcarty>
According to the ocaml-re docs it usually as fast or faster than pcre
<hcarty>
flux: :-) Not in my experience. None of my current regex use in OCaml is particularly significant in the overall runtime cost.
<hcarty>
ocaml-re even provides a (very small) Pcre compatibility module to draw you in!
<hcarty>
flux: I've used and continue to use both in different projects. I generally use re in new projects since it eliminates a non-OCaml dependency.
<hcarty>
nicoo: Both are nice. I've found ocaml-re's Re_glob particularly convenient.
2014-03-18
<samae>
Drup, hcarty: yeah, ocaml cairo does the trick : )
2014-03-17
<hcarty>
adrien_oww: Proactive too. I like using his libraries.
<samae>
hcarty: and doesn't work : )
<hcarty>
samae: And for better or worse, the library you most likely want from opam is cairo2. The 'cairo' package is older and less complete.
<hcarty>
samae: There is an OCaml version of the Cairo tutorial somewhere. It gives a nice overview of the library.
<samae>
Ow, it is maintained : ), my bad hcarty
<samae>
hcarty: I started with Cairo, but I couldn't run a simple example here, do you have any pointers on how to use it?
<hcarty>
Cairo or Camlimages should do what you want. PLplot if you're willing to go through some extra work.
<hcarty>
Cairo is, but you can get PNG output
<samae>
hcarty: they are just renders of a simulation