<d_bot>
<sgrove> @hcarty I managed to figure it out, thank you!
2021-01-08
<companion_cube>
@hcarty: I still disagree with that
<companion_cube>
hcarty: please don't
2020-10-03
<d_bot>
<Skilly> okay, just tried it out with 4.11 but Go-to-definition across files still doesn't work sadly @hcarty :/ thanks for trying though!
2020-10-02
<d_bot>
<Skilly> @hcarty thanks for letting me know, sadly uni requires 4.04 and ocamllisp needs >= 4.06
<d_bot>
<shawn> @hcarty do those plugins play nice with `esy`?
2020-09-22
<cemerick>
hcarty: mirror/cache, yes, but it is subject to retroactive changes in opam-repository
2020-09-17
<SoF>
hcarty: I wasn't able to set up the cygwin stuff (some old install still lying around messing things up), but with arctumn's help I got it working well on WSL :)
<Leonidas>
hcarty: I found a way to disable it, but it involved editing the shell scripts in .opam which is not great since it can create issues with multiple opam processes.
<discord3>
<hcarty> Leonidas: If there isn't a way to disable it for single packages, that seems like a good feature request for opam
2018-06-08
<discord3>
<hcarty> Sure thing! This should be in a FAQ somewhere, where it can get appropriately argued and bikeshed'd
<discord3>
<hcarty> Indeed
<discord3>
<hcarty> No problem re: typos 😃
<discord3>
<hcarty> sin x reads more clearly than x |> sin, but read myinput |> process_input |> archive_result reads more clearly (to me at least!) than archive_result (process_input (read myinput))
<discord3>
<hcarty> ZirconiumX: All in my experience - |> is most useful when there would be a lot of ( ... ) nesting and the steps read well sequentially. I find @@ to be less generally useful.
<discord2>
<hcarty> Or the update details. Spiros can probably offer some guidance if you ask though
<discord2>
<hcarty> As Perry suggested. PRs are likely to be welcome. I think most of what's there is generated but I'm not at all familiar with the repo
<discord2>
<hcarty> The developer is working at Jane Street now
<discord2>
<hcarty> gtrak: I don't think it's abandoned but I'm pretty sure it's not actively developed
2018-05-07
<discord2>
<Perry> @hcarty I think the most important thing (which I often suck at) is being really nice to everyone else in such a discussion. It makes it easier. But I won't claim to being a paragon on this, I often get frustrated and post too quickly.
<discord2>
<hcarty> takanuva: Good luck - it sounds like a very useful addition!
<discord2>
<hcarty> @Perry Agreed that they sap a lot of energy. It's a (difficult) question of spending the energy now vs later.
<takanuva>
hcarty: I'll open an issue then; thank you
<discord2>
<Perry> @hcarty That's why I'm interested in making sure the default font is relatively large. I have vision problems so I sympathize with people with that constraint. But the wider topic is, steenuil is right, such discussions sap people's energy, even if they're necessary.
<discord2>
<hcarty> Font sizes matter a lot of users with usability constraints/concerns. These kinds of core topics are worth spending time on up-front
2018-05-01
<remix2000[m]>
Thank you, hcarty ! The cohttp looks interesting. And, by the way, what's the best way to parse a JSON response?
<sh0t>
ok thanks companion_cube thanks hcarty[m]
<sh0t>
hi hcarty[m] thanks for the hint. How do I add a flag to the compilation if I am using oasis?
<hcarty[m]>
sh0t: I'm not sure of the exact flag spelling, but I think you need to add `-thread` or maybe `-threads` to that command
<hcarty[m]>
ocurl is pretty low-level so a GET request takes more steps than one might expect. Along with that, though, it provides an impressive/overwhelming level of flexibility
<hcarty[m]>
@remix2000:matrix.org: ocurl (pretty close binding to the C libcurl API) and cohttp. I think ocamlnet has something as well
2018-04-24
<Leonidas>
hcarty[m]: but that will fail when it comes to release tarballs
2018-04-23
<hcarty[m]>
Leonidas: It's possible. One (relatively) simple approach is to use SSH keys for access to the private repositories.
<hcarty[m]>
@leo
2018-03-06
<rgr[m]>
Leonidas: I'll update the README more thoroughly after hcarty submits his lwt bindings.
<Leonidas>
rgr[m]: Well, I am working at the company, so sort-of. But I'll add you and hcarty anyway :-)
2017-12-17
<rgrinberg>
That vim mode is hcarty's work!
2017-08-04
<hcarty>
This code raises an assertion with Faraday 0.3.0 (from opam) - any thoughts on what I'm doing incorrectly here? http://vpaste.net/RhXNs
2017-04-21
<orbifx>
hcarty: it will be in opam anyway, as a library
<hcarty>
orbifx: Even if that isn't your primary mode of distribution
<hcarty>
orbifx: It makes sense to have it in opam too, in part because it would then be included in future compiler compatibility and regression testing
<hcarty>
flux: There have been a few "opam bundle"-like efforts. It would be pretty nice to have something like that available.
<hcarty>
FWIW it looks like opam 2 will do what I was looking/hoping for (opam install . --deps-only)
<hcarty>
Does opam have a way to say "install the dependencies list in this opam file/these opam files" without creating a pin?
2017-03-17
<orbifx-m>
is hcarty here?
2017-01-27
<hcarty>
companion_cube: containers 1.0 is looking quite promising! :-)
<hcarty>
companion_cube: \o
<hcarty>
seliopou: Hello
2017-01-26
<KV>
hcarty, yes you're right. I just found out by hacking my way into the channel-stuff that it is to abstract to handle from C. File descriptors seems way more sane. Thanks
<hcarty>
KV: Maybe by going through the Unix module
2017-01-25
<hcarty>
dmbaturin: Fair point
<dmbaturin>
hcarty: Well, if I want to get it into fedora repos, I'm not sure if writing the spec file to their guidelines is easier than adapting an existing SRPM, but we'll see.
<hcarty>
The source RPMs may provide a good starting point
<hcarty>
There are/were RPMs available somewhere I thought... maybe for CentOS/RHEL
<hcarty>
dmbaturin: I've definitely done that or its equivalent before... a missing aspcud is bordering on dangerous for opam
<dmbaturin>
hcarty: I guess it's not nearly as embarassing as that time when for some odd reason (which has to do with aspcud not installed on my desktop) "opam install lwt" installed ridiculously old Lwt and I was wondering where's my ppx extension. ;)
<dmbaturin>
hcarty: Oh, good to know.
<hcarty>
Lwt is playing nicely from a fresh switch
<hcarty>
dmbaturin and Drup: FWIW, the issue was on my end - I had a broken opam switch and the host wasn't properly identified as win32. So invalid signals were checked in Lwt.
<hcarty>
Maybe from C's assert
<hcarty>
dmbaturin: Possibly, or some edge-case from cross-compilation
<dmbaturin>
hcarty: Well, it may also be Lwt being insufficiently cross-platform there.
<hcarty>
cheater: assert can be used the same way and is probably the more appropriate tool in this example
<hcarty>
dmbaturin: Yeah, I think this has something to do with static linking + cross compilation (using MXE + opam-cross-windows)... but I'm not certain
<hcarty>
Drup: Mine is, for better or worse, growing by bits and pieces
<cheater>
hcarty: that's probably what i was looking for
<hcarty>
Drup: Any chance you know what could cause "Lwt_unix.on_signal: unavailable signal" with Lwt on Windows? Happens immediately when starting a program.
<hcarty>
works
<hcarty>
1 + failwith "Ooops I need to put a number here"
<hcarty>
cheater: If you want something that works more or less the same way but maybe simpler conceptually you can use failwith
2017-01-24
<hcarty>
2
2017-01-23
<hcarty>
So maybe it's not doing much cleanup
<hcarty>
emacs-fb: Looks like caml_sys_exit(foo) doesn't do much beyond calling exit(foo)
<hcarty>
In that case it may require a manual call to flush the buffered output
<emacs-fb>
hcarty: Called that -- didn't print the string :-/
<hcarty>
Algebr``: The pointer itself or the thing it's pointing to? Warning: I'm not 100% sure in either case :-)
2017-01-10
<hcarty>
s/I'm //
<hcarty>
octachron: I'm sounds like a play on ctors
<hcarty>
companion_cube: I was going to add that one, but I was worried it would add controvesy to the PR :-)
<hcarty>
companion_cube: I'm impressed by (and thankful/hopeful for) your PR patience
<hcarty>
\o
<hcarty>
But the whole discussion around the unboxed PR makes it seem like that wasn't true
<hcarty>
I honestly had thought it was this way already - I thought there were discussions about single-constructor variants being optimized away without any special code
<hcarty>
Annotation of the type definition
<hcarty>
Algebr``: It requires annotation IIRC
<hcarty>
Drup: Hooray for Lwt-powered Format
2017-01-09
<hcarty>
justin_smith: I did a lot of weather and GIS data wrangling in school and at a previous job using OCaml. It's nice for that kind of thing - not nearly the library support that Python has, but sooo much better to maintain over time
<justin_smith>
hcarty: kind of makes sense, I'd assume it's neccessary for the big money applications, but that won't be open source for obvious reasons
<hcarty>
justin_smith: Number crunching definitely happens in OCaml. I think most of it is behind closed doors though.
<hcarty>
Sounds good
<aantron>
hcarty: yeah, but i released initially as deprecated due to reconsideration since 2.6.0, and never linked it from the manual index. should probably add a link to the PR at least. this deprecation message is before the 2.7.0 style
<hcarty>
companion_cube: \o
<hcarty>
aantron: The module is marked as deprecated but not mentioned in the 3.0.0 tracking issue
<companion_cube>
o/ hcarty
<hcarty>
aantron: Is the deprecation of Lwt_result based on the discussion around the Lwt_opt(ion) PR?
2016-12-29
<hcarty>
Drup: Thank you! I knew there was some syntax difference I was missing
<hcarty>
Drup: Aaaaaah
<Drup>
hcarty: with type .. and type ...
<hcarty>
A direct conversion gives an error
<hcarty>
Is it possible to use a first-class module with multiple type substitutions? The local module equivalent to: module M : S with type a = t1 with type b = t2
2016-09-01
<hcarty>
...
<hcarty>
If only someone would propose such an addition in OCaml. And respond to comments, updating as the discussion moves along.
<hcarty>
companion_cube: :-)
<hcarty>
But I agree, efficient is the desire
<hcarty>
companion_cube: Borrowing is differently difficult in its accessibility, at least in Rust as it exists now
<hcarty>
Rust is pretty amazing. If/when usability is improved to the point where borrowing becomes accessible for beginners it will be pretty fantastic
<hcarty>
No laughter here re:swift. My initial impression of the language when it was first shown was that they've done a lot right with it.
<hcarty>
Hopefully OCaml will progress similarly over those five years
<hcarty>
rgrinberg: Rust is wonderful, and my hope is in five years it will be as usable as OCaml is now for quickly writing code
<hcarty>
rgrinberg: There are tasks on the oasis forge by Sylvain to move completely over to github from the forge
<hcarty>
companion_cube: Thanks for the effort toward a camlp4-less oasis!
<rgrinberg>
hcarty: AFAIK, they have --short-paths understand this convention now. And possibly support in ocamldep
<hcarty>
rgrinberg: There's some basic support there in 4.03 or 4.04 isn't there? Or maybe just for short-name selection
<hcarty>
I'm quite sure it's not that simple as far as the actual compilation process goes
<hcarty>
[@@@ocaml.module Foo] in the file myfile.ml
<hcarty>
Unless we do something with attributes maybe
<hcarty>
s/Fooo/Foo/
<hcarty>
The compiler says that foo.ml -> module Fooo
<hcarty>
companion_cube: Good point, thanks
<companion_cube>
hcarty: well \n does not belong in the line
<hcarty>
And you only need packs/aliases if you want the definition of Foo.Baz and Foo.Bar to live in different files
<hcarty>
With packs you always link everything in the pack
<hcarty>
-no-alias-deps goes with aliases
<hcarty>
Bluddy[m]: You use packs OR aliases
<hcarty>
companion_cube: I'm not sure why \n would come after the eol position, but perhaps there's a definition which states that \n is after the end of the line
<Bluddy[m]>
hcarty, companion_cube: so if I'm making a library and I want Foo.Baz and Foo.Bar to both be available, I have to use packs? And then, when I'm a user using the library and I want to use Foo.Baz, I compile with -no-alias-deps to reduce my footprint? Or is something missing here (because I know Jane Street had to change their code to make this work).
<hcarty>
Doesn't look like it
<hcarty>
companion_cube: Will do. Re.split Re.(compile @@ char '\n') "a\nb" = ["a"; "b"], which is what I would expect
<hcarty>
Unrelated to the compilation discussion: (Re.split Re.(compile eol) "a\nb") = ["a"; "\nb"] --- this is not what I would have expected
<hcarty>
Bluddy[m]: -no-alias-deps is a way to have something similar to packs but without requiring linking of unused aliased modules
<Bluddy[m]>
hcarty: So when you create a module that contains aliases to other modules, and compile with -no-dep-aliases, what gets created?
<hcarty>
*both
<hcarty>
bothing?
<hcarty>
Bluddy[m]: packs and module aliases are two ways we can have Foo.Bar and Baz.Bar not have linking conflicts due to bothing having a 'Bar' module
<hcarty>
chsn: objects or polymorphic variants
<hcarty>
chsn: It's not named tuples - it's an object
<chsn>
hcarty: how does that give me 'named tuples' ?
<hcarty>
chsn: let f x = object method x = x end
<chsn>
Bluddy[m]: hcarty : 1) are tuples 'named', i.e. do they have fields x, y, or is it just Float * Float; hcarty: can you point me to an example?
<hcarty>
chsn: Or objects
<hcarty>
chsn: Not with record types
<Bluddy[m]>
hcarty: yes, I was referring to this vaguely above. It needs to be the default. In every build system.
<hcarty>
I'm not sure if this is coming in 2.0, but allowing local switches to share a compiler would save a lot of potential pain with local switches
<hcarty>
When I run into opam hell it's usually due to (a) pins that I created and forgot about or (b) missing version constraints after a dependency's new API-breaking version
<hcarty>
Agreed
<hcarty>
companion_cube: Yeah, the reasoning makes sense. Format has been Super Popular more recently
<hcarty>
companion_cube: Small complaint, not a real issue with the library
<hcarty>
companion_cube: print vs pp ....
<Bluddy[m]>
hcarty: But then you use a simple flip function: let flip f x y = f y x. You can even curry it if you need to with `let flipmap = flip List.map`. No need to add a tax to every invocation of map.
<rgrinberg>
you mean hcarty ?
<hcarty>
Bluddy[m]: Everyone knows it, but it is nice to be able to put the list first as companion_cube said
<Bluddy[m]>
hcarty: everyone knows where the function is in List.map. If I need to swap arguments, I'll use a simple argument swapping combinator.
<hcarty>
Bluddy[m]: Agreed that List.map ~f is nice. As for why not Containers - mostly naming differences w/other (dbuenzli) libraries
<hcarty>
Using dep/deps in myocamlbuild.ml doesn't work because it doesn't know how to build/handle a "foo.txt" file
<hcarty>
How can I tell ocamlbuild that some code depends on a static file? I'm using ppx_blob and want to tell ocamlbuild that it needs to copy/'ln -s' the included file
2016-07-20
<seliopou>
hcarty: thanks! and thank you for your contributions
<hcarty>
I still haven't had time to test the Z submodule
<hcarty>
seliopou: Congratulations on a first angstrom release!
2016-07-15
<hcarty>
hongbo`: That should give you show_u, show_v, pp_u, pp_v
<hongbo`>
hcarty: thanks
<hcarty>
hongbo`: Yes, you only need it once, as you wrote the example
<hcarty>
hongbo`: From a quick test in utop it looks like you do not
2016-07-13
<hcarty>
companion_cube: And, hopefully, if scale beyond that is required ... opam
<seliopou>
hcarty definitely doesn't. there was actually a controversial patch to opam a while back that hard-coded the URI of a chaching server, and (hopefully) it was rejected
<hcarty>
seliopou: I thought opam.ocaml.org did some kind of automatic mirroring of upstream packages... I may be remembering that incorrectly though
<rgrinberg>
that's hcarty actually :P
2016-07-12
<hcarty>
Bluddy[m]: ocamllint could probably be extended to support that if it doesn't already
<hcarty>
Bluddy[m]: Yeah, I've put up a gist or two which shouldn't be terribly out of date. That's just the inner workings though - there's a (hopefully) more user-friendly layer available as well
<hcarty>
I would like to do some testing against other language implementations of msgpack to see how speed compares. Haven't had time yet though.
<Bluddy[m]>
hcarty (IRC): I've already found some version of it using the power of google. Looks good so far.
<hcarty>
Bluddy[m]: No repo yet - need to get a bit more polish in place, put it through an internal review and write the whole thing up. The current plan is an early August release.
<seliopou>
Bluddy[m]: before hcarty's pr (which was great), it did not deal with ints at all, now it relies on ocp-endian for dealing with such things
<Bluddy[m]>
hcarty: how so? Do you have the repo up?
<hcarty>
Bluddy[m]: The msgpack-angstrom implementation is already reasonably performant... depends on the data you're processing
<hcarty>
I'd never used a parser combinator library before
<hcarty>
companion_cube: Not sure - I started this as an experiment because (a) ocaml-msgpack is very slow for large messages and (b) learn a bit of angstrom
<hcarty>
*extracted
<hcarty>
Bluddy[m]: It's extacted from Coq code and, unfortunately, comes with each byte parsed as an 8-element bool tuple
<companion_cube>
I wonder, how much slower than a handwritten parser do you get, hcarty?
<hcarty>
Bluddy[m]: angstrom
<Bluddy[m]>
hcarty: you're parsing msgpack using what library?
<hcarty>
companion_cube: Parsing msgpack
<hcarty>
seliopou: I haven't tried the Z submodule yet but I'll try today
<seliopou>
hcarty: you gotta use the Z submodule and then lift stuff with z to parse
<hcarty>
Admittedly much easier to read when broken up with sane newlines
<hcarty>
let f x = begin if x then begin 1 end else begin 0 end end --- clear as mud! :-)
<hcarty>
Kind of like ocamllint
<hcarty>
That may be something which could be enforced with a ppx
<hcarty>
For the low, low cost of "begin"
<hcarty>
companion_cube: If you're willing to pay the matching "begin" price then you can have it all, right now
<hcarty>
companion_cube: You can't nest let now without adding "in"
<hcarty>
companion_cube: I sometimes wonder if an 'end' after toplevel 'let's would help, particularly when starting out with the language
<hcarty>
Is there a .tar.gz download available anywhere for the 1.11 cryptokit release?
<hcarty>
companion_cube: Ah, implicits... one day
2016-07-08
<hcarty>
ocamlscript is (almost) very nice as well, aside from the camlp4 dependency. It makes simple projects very easy to create with little to no external configuration.
<hcarty>
lostman: With more recent versions maybe?
<hcarty>
Tooling is definitely too complicated. Need opam + oasis + merlin + ocp-indent + editor configuration is a lot to ask from someone maybe interested in the language.
<hcarty>
companion_cube: And VS Code, which has quite nice OCaml support at this point
<hcarty>
And that!
<hcarty>
pseudony1ous: gasche's answer of "parameterized type" is the term to search for/understand
<hcarty>
pseudony1ous: If you want to constrain that type to only have a router socket then your fix is the right one
<jgw25>
hcarty: Thanks. Do you know where it's documented? I couldn't find it in the OCaml manual
<hcarty>
jgw25: So if you link a.ml first and b.ml second, then everything in A is run in order, followed by everything in B
<hcarty>
jgw25: Link order, then order inside of the module definitions
2016-07-07
<hcarty>
open but silence warnings about shadowing
2016-07-06
<hcarty>
It doesn't cover all of the latest language features but the parts it does cover are described well
<hcarty>
upbeatfx: I really like the caltech/Jason Hickey book as an introductory text
<upbeatfx>
hcarty, Drup -- ah, forgot this works differently in irc
<upbeatfx>
@hcarty Thanks, I'll look into that book, @Drup & @hcarty Is there a recommended book for someone coming from procedural/imperative languages? I may start with RWO, it's longer but it covers far more than ThinkOCaml
<hcarty>
upbeatfx: RWO has good information on functors. So does the manual and courses.cms.caltech.edu/cs134/cs134b/book.pdf
2016-07-05
<hcarty>
Nash_: Lots of other editors provide at least basic syntax highlighting support
<hcarty>
Nash_: The best/most complete IDE-ish support is currently available in vim, emacs, atom and VS Code
<hcarty>
apache2: There were a few projects adding support. They're all fairly out of date I think
<hcarty>
rgrinberg: Based on very simple, stupid tests it's faster too (which makes sense, it eliminates recursion)
<rgrinberg>
hcarty: \o/
<hcarty>
Not sure what will come of it yet
<hcarty>
rgrinberg: Still very much a WIP
<hcarty>
rgrinberg: I've hacked in some streaming support too
<hcarty>
seliopou: Only 322 encodings/second with 10 megabyte blobs on the same system, though :-)
<hcarty>
gasche: It's also eliminating lots of `compose` calls
<hcarty>
As I said last week, I'm quite happy with angstrom
<hcarty>
gasche: A big match over the first tag byte
<gasche>
hcarty: what does the change look like?
<hcarty>
s/lots/lots of/
<hcarty>
seliopou: ~23k encodings per second -> ~122k encodings/second
<hcarty>
seliopou: For a somewhat pathological case (lots embedded tiny maps/arrays), your optimization suggestion of sticking all of the msgpack tag bits into a big match/function case was tremendously successful
2016-07-01
<hcarty>
gasche: Self-employment seems to always be an ugly thing to manage
<gasche>
hcarty: so Patreon knows a bit about US taxation and otherwise it directs you to VAT-style forms that are supposed to tax some form of consumption
<hcarty>
gasche: There are platforms like patreon which have, presumably, made some effort to figure out the legality of an arrangement like that
<hcarty>
gasche: Agreed, that's totally fair
<gasche>
hcarty: I don't think your msgpack parser particularly readable, in the sense that it seems less readable that a declarative description of the format
<hcarty>
Writing ELF and PE parsers for angstrom seems like a fun project
<hcarty>
"nice" in this case meaning easy to use and efficient
<hcarty>
cnu-: angstrom is very nice for that kind of parsing
2016-06-30
<hcarty>
I'm off, have a good night!
<hcarty>
Please ping me in the PR when you bring the changes in and I'll test msgpack again
<hcarty>
Ha, excellent :-)
<seliopou>
hcarty so i sortof rewrote angstrom today and got an even bigger performance gain
<hcarty>
Drup: No, it's mainly something like ppx_deriving which needs to touch lots of internal structure
<Drup>
hcarty: we have a compatibility layer in place now, and we can expand it for the next releases
<Drup>
hcarty: for the small things in ppx, it should not be an issue
<hcarty>
But if something that is strongly tied to a specific OCaml version is anywhere in the chain of dependencies then OCaml vNext will be out of reach until those packages are updated
<hcarty>
gasche: In cases where that is an option, though, it seems like a good idea
<hcarty>
gasche: ppx makes that rather difficult when the internals shift and values/constructors get renamed between versions
<hcarty>
rgrinberg: And thank you for looking at it if you have time
<hcarty>
Drup: Thanks
<Drup>
hcarty: "opam pin add -e foo 2.3.0"
<hcarty>
Is it possible to change the version constraints for a single package locally?
<hcarty>
rgrinberg: I'd like to use 4.03.0, but outside of that I'd like to (continue to) move my code away from a mix of `Ok and Ok
<rgrinberg>
hcarty: i'll have a look at this today. out of curiousity, why do you need ppx_driving 4.0?
<hcarty>
They compile in the same switch
<hcarty>
rgrinberg: Not sure - I haven't tried to use a Jane St deriver + a ppx_deriving deriver together
<rgrinberg>
hcarty: seemed like that was the case. Did you compile the ppx_deriving exporter?