adrien changed the topic of #ocaml to: Discussions about the OCaml programming language | http://www.ocaml.org | OCaml 4.09 release notes: https://caml.inria.fr/pub/distrib/ocaml-4.09/notes/Changes | Try OCaml in your browser: http://try.ocamlpro.com | Public channel logs at http://irclog.whitequark.org/ocaml
unyu has quit [Quit: unyu~]
unyu has joined #ocaml
smazga has quit [Quit: leaving]
okuu has joined #ocaml
unyu has quit [Ping timeout: 276 seconds]
ygrek__ has joined #ocaml
ycjung1 has quit [Quit: WeeChat 2.6]
_whitelogger has joined #ocaml
iovec has quit [Quit: Connection closed for inactivity]
okuu has quit [Ping timeout: 246 seconds]
okuu has joined #ocaml
tormen has joined #ocaml
tormen_ has quit [Ping timeout: 268 seconds]
artart78 has quit [Ping timeout: 252 seconds]
brettgilio has joined #ocaml
mfp has quit [Ping timeout: 240 seconds]
mbuf has joined #ocaml
gravicappa has joined #ocaml
narimiran has joined #ocaml
_xvilka_ is now known as xvilka
xvilka has quit [Changing host]
xvilka has joined #ocaml
ycjung has joined #ocaml
ggole has joined #ocaml
rople has quit [Ping timeout: 245 seconds]
rople has joined #ocaml
dckc has quit [Ping timeout: 250 seconds]
dckc has joined #ocaml
dmiles has quit [Ping timeout: 276 seconds]
zmt01 has joined #ocaml
zmt00 has quit [Ping timeout: 245 seconds]
keep_learning has joined #ocaml
dmiles has joined #ocaml
dborisog has joined #ocaml
stux|RC-only has quit [Quit: Aloha!]
jave has quit [Ping timeout: 240 seconds]
porchetta has quit [Ping timeout: 240 seconds]
stux|RC-only has joined #ocaml
porchetta has joined #ocaml
jave has joined #ocaml
artart78 has joined #ocaml
Haudegen has joined #ocaml
Serpent7776 has joined #ocaml
barockobamo has joined #ocaml
<sarna> hi, what’s extlib? do people use it? or does everyone use jane street’s stuff now
bartholin has quit [Remote host closed the connection]
<Leonidas> sarna: extlib is what was absorbed into batteries and for a long time believed dead. Then it started to be maintained again for some reason.
<Leonidas> I don't think any new code uses it
<Leonidas> these days I would either use core/base or containers
<narimiran> is there a better way of doing `String.sub s 1 (String.length s - 1)`?
<narimiran> e.g. what in python would be `s[1:]`
<def`> narimiran: defining a slice function?
<narimiran> def`: ok, so nothing built-in?
<def`> no
<sarna> thanks Leonidas
<sarna> so, containers is like core but without the dependency on linux?
<Leonidas> sarna: no, containers is like stdlib
<Leonidas> base is like core but with reduced dependencies
<Leonidas> none of them depend on "linux"
<sarna> unix*, sorry
<sarna> I'm a bit confused about this stdlib situation, in every language I've used before there was a standardized stdlib
<Leonidas> Core I am not sure, Base I believe works on Windows. And in JS.
<Leonidas> sarna: you haven't used D then ;-)
<sarna> yeah, core_kernel works on windows too I believe
<sarna> yep, I haven't :)
<Leonidas> sarna: Just ignore the existence of extlib and batteries
<sarna> Leonidas: I believe Jane Street's stuff is more popular/standard?
<Leonidas> sarna: then your choices are whether you want the compiler standard library, which is missing a lot of handy functionality
<Leonidas> sarna: or if you prefer a conservative extension then containers
<sarna> Leonidas: I'm writing stuff for myself mostly, I don't have any constraints. I'd like to have good docs and ergonomics
<Leonidas> sarna: if you want a modern extension (which is then incompatible) then Base/Core.
<sarna> Leonidas: what do you mean by "incompatible"?
<Leonidas> I don't think core is very popular, but it does a lot of things right and rather pleasant to use
<Leonidas> sarna: like, all the signatures change. So if you see `List.map (fun x -> x) xs` in the wild, that won't work since core has a different signature
<sarna> but it would be awkward to use it with other libraries, that's what you mean?
<Leonidas> sarna: no, I wouldn't say that. Unlike batteries it doesn't introduce invasive data structures (BatEnum, looking at you)
<sarna> Leonidas: List.map in Core is `map : 'a t -> f:('a -> 'b) -> 'b t`, how is it different from the regular one?
<Leonidas> sarna: the ~f label
<Leonidas> sarna: in general, core uses labels way more and avoids exceptions
<sarna> Leonidas: oh, the function is a named argument?
<Leonidas> sarna: yes.
<Leonidas> it can be super useful when doing |> |> |> chains
<sarna> yeah, I can see how
<sarna> I don't know if I like the "avoids exceptions" part though
<sarna> does ocaml have a mechanism analogous to rust's question mark? (you put a question mark after calling a function that returns a Result, and if it's an Error it short-circuits and returns from current function)
<sarna> without it I find Results kind of awkward to work with
<prsafont[m]> I don't think I've seen that, but there are result combinators available: https://erratique.ch/software/rresult/doc/Rresult.html
* sarna squints
<sarna> is that the monadic "shove" operator
<prsafont[m]> you've got join, bind and map and their infix equivalents
ygrek__ has quit [Ping timeout: 240 seconds]
<sarna> looks good, thanks
<Leonidas> sarna: yes, well, sort-of
<Leonidas> sarna: we use Jane Streets ppx_let which unpack a result in the Ok case and return the Error directly in the Error case.
<def`> custom let operators from OCaml 4.08 lets you do that very easily
<def`> # let (let-?) r f = match r with Ok x -> f x | Error _ as err -> err;;
<Leonidas> let%bind alright = Bumblebee.remove "/usr" in …
<def`> which can be used with 'let-? fail = Error "Booh" in Ok fail;;'
<Leonidas> def`: Without the same for match I still think it is inferior to ppx_let :(
<sarna> both are very cool!
<Leonidas> but it can be used by people who avoid ppx and are ok with requiring 4.08 :)
<sarna> (why avoid ppx?)
nopf has quit [Ping timeout: 240 seconds]
nicoo has quit [Ping timeout: 260 seconds]
nopf has joined #ocaml
rople has quit [Ping timeout: 268 seconds]
<Leonidas> sarna: ppxes can be fragile when updating ocaml versions
<Leonidas> it is being worked on to improve the cross-version compatibility, but old ppx'es won't automatically profit
<reynir> I wrote a ppx for rust's if-let in OCaml a while ago https://github.com/reynir/let-if
<reynir> It's not as useful in OCaml, and you probably shouldn't use it anyway
<reynir> (I'm curious if it still works)
<sarna> Leonidas: oh, I see
<reynir> Oh, I published it on opam and it works with 4.08.0 :o
nicoo has joined #ocaml
<Leonidas> reynir: heh, at this point, who hasn't :D https://github.com/Leonidas-from-XIV/ppx_iflet
<Leonidas> (though I took it from Clojure)
<sarna> Leonidas: have you worked with clojure?
<Leonidas> sarna: yes, my previous full-time job before my OCaml job
<sarna> Leonidas: how does Clojure compare to OCaml? I'm having a hard time choosing between a lisp and OCaml right now, I would be grateful if you provided me with some insight :)
<reynir> Leonidas :D :D :D
<Leonidas> sarna: they are ~nothing~ alike except for the immutable bit
<Leonidas> sarna: so, what I liked about clojure was how convenient it was and the amount of useful macros
<Leonidas> sarna: what I did't like is that it runs on the JVM, the low discipline and the fact that everything was insanely fragile
zolk3ri has joined #ocaml
<sarna> Leonidas: was it fragile now that you look at it, or did it really break in catastrophic ways?
<Leonidas> I always had to run my code, which due to the terrible start up times of the JVM and the Clojure interpreter itself was incredibly frustrating
<Leonidas> sarna: I spend a lot of time figuring out why things were `nil` because Clojure loves to propagate `nil` through your code happily until you really get to the point where it can't assume `nil` is an empty collection
<sarna> yeah, but I won't believe that you only rely on the compiler for OCaml and not test your code :)
<Leonidas> but that is so far removed from the the place you wrote it that it becomes frustrating
<sarna> Leonidas: I'm having this problem with a Scheme dialect, yesterday a map failed and all I got was #f.. I couldn't figure out why
<Leonidas> sarna: I have days where I never run my program. Coworker was amazed that when he run it, it immediately worked correctly.
<Leonidas> Of course, there are limits, I'm not saying that this is 100% always true, especially if you can't type constrain your domain sensibly
<sarna> Leonidas: you were running the compiler and tests, or just the compiler?
<Leonidas> sarna: just the compiler. and dune enables all kinds of warnings which have been very useful
<sarna> Leonidas: I see
<Leonidas> I didn't think I would enjoy the "unused identifier" warning as much as I do, but it often points to something in my code that I have forgotten to do with it.
<sarna> how's OCaml's productivity in comparison with Clojure? is it much worse, or comparable given that you spend less time debugging
<Leonidas> ocaml productivity is often constrained by a death of thousand cuts by different tools
<sarna> ouch :(
<Leonidas> sarna: oh, ohne thing that frustrated me a lot in clojure is that I never know what goes into a function and what comes out (its all maps with ??? keys)
<sarna> yeah, it's really convenient until it suddenly bites your leg off
<Leonidas> sarna: like, you have a ppx that would be perfect, but doesn't work if you include another ppx because of some ppx-tooling incompatibility
<Leonidas> or the library you want to use only has Lwt bindings
<sarna> oh :(
<sarna> that's unfortunate
<Leonidas> or it is full of exceptions so you have to wrap every call into try_with, so you can have result-types
<Leonidas> I could imagine it is a bit of a C++ situation, where you have all this ecosystem, but you can't use anything because it does exceptions, or RAII or whatever differently from you.
<sarna> yeah, once we tried integrating result types into a C# codebase, it was so inconvenient we gave up entirely
<Leonidas> sarna: I am building systems (effectively) checked exceptions in OCaml, it's a great feature :D
<Leonidas> but if you just write ocaml and have all things available it is totally a zen experience with bits fitting together
<sarna> Leonidas: yeah, but how often does it happen
<Leonidas> I also much prefer the OCaml community for its somewhat more theoretical insight than the more industry Clojure approach (though it is nowhere near as "get it done by any means necessary" as Python)
<sarna> I want a language to write personal tools in, and an occasional big project when I’m feeling particularly bold
<Leonidas> sarna: I use ocaml for that.
<sarna> I can’t spend days trying to fit the bits together :( I wouldn’t finish anything
<Leonidas> depends on which bits these are
<sarna> “get it done by any means necessary” - hey, C# culture is the same
<Leonidas> if you need to do a lot of "integration work" like smash kafka into oracle or vice versa then OCaml is not the best choice
<sarna> no, not these kind of tools :D
barockobamo has quit [Quit: Leaving]
<sarna> mostly cli helpers
<Leonidas> sarna: yes, that's why I have become a sort of unemployable loonie :D
<Leonidas> refusing to get stuff done in fragile ways
<Leonidas> sarna: for cli helpers it should be fine. also it is amazing in larger codebases where pulling a change through an entire codebase can be trivial
<sarna> Leonidas: that’s why I didn’t go for haskell though - I prefer stuff that works over stuff that’s perfect but doesn’t
<sarna> theoretically perfect*, I mean
<Leonidas> I always think about using Rust but I never have the usecase for it :|
<Leonidas> maybe AoC
<zolk3ri> Leonidas: Haha, same here, you are definitely not alone with that. :) I don't work in IT, I do it for a hobby when I'm in full control. :D
<sarna> I thought about it, but I run into lifetimes with the simplest of problems sometimes.. that’s why I turned to Rust with GC, aka OCaml
<prsafont[m]> I though lifetimes would be much better now that they got rid of semantic ones
<prsafont[m]> last year's AoC was painful with them
<sarna> would OCaml be good for parsing and/or generating text files?
<zolk3ri> Have they fixed temporary lifetimes yet? The workaround is annoying. For example you could not do "let x = os::args().slice_from(1);", you had to do "let x = os::args();\nlet x = x.slive_from(1);".
<zolk3ri> sarna: Yeah, definitely.
<Leonidas> sarna: I don't mind lifetimes and I think it is an interesting concept. But I have no need for a GC-less language right now.
<Leonidas> sarna: yes, ocaml is pretty great at parsing
<sarna> zolk3ri: they have non-lexical lifetimes now, I don't know about your example though
<Leonidas> that's sort of 80% of the ocaml showcase :D
<sarna> oh! tempting
<zolk3ri> ↑ :D
ski has quit [Ping timeout: 240 seconds]
<zolk3ri> sarna: The example does not work anymore at all, but this is the RFC I am referring to: https://github.com/rust-lang/rfcs/blob/master/text/0066-better-temporary-lifetimes.md. Seems like the issue that has been opened in 2014 is still open.
ski has joined #ocaml
<sarna> zolk3ri: that's gonna be helpful, thank you!
<prsafont[m]> there also parser-combinators like https://github.com/inhabitedtype/angstrom
<sarna> nice :)
<sarna> is there something like typeclassopedia for ocaml?
<narimiran> AoC day3 spoilers ahead: from what i can tell, this part of my code causes lots of slowdowns: http://ix.io/23rj/ocaml — i call it two times, with two lists of 150k member each. is there something i could do to speed it up?
<zolk3ri> sarna: I'm not sure but I remember reading https://www.mseri.me/typeclass-ocaml/. This post mentions angstrom as well in the section "A practical example - monadic parsing library". :D
<sarna> zolk3ri: that's definitely gonna help :)
<sarna> I have the haskell book, but I'd have to read like a half of it to get through all of these
<sarna> and it's ~1000 pages
<prsafont[m]> Made a parser for dmidecode output with angstrom, tough to start, but once you get the hang of it it's very nice to work with
okuu is now known as unyu
mfp has joined #ocaml
okuu has joined #ocaml
unyu has quit [Killed (niven.freenode.net (Nickname regained by services))]
okuu is now known as unyu
<sarna> hmm, I can't get ocp-indent to work.. I get stuff indented 8 spaces in vim, when I run it on the command line it uses two
<sarna> which makes me think ocp-indent isn't what is running there
Haudegen has quit [Quit: Bin weg.]
<narimiran> sarna: did you define your tab width in vimrc?
<sarna> narimiran: yeah, it's 4..
<narimiran> this is what i have: `set tabstop=2 softtabstop=2 shiftwidth=2 expandtab smarttab`
<zolk3ri> sarna: When you install ocp-indent via opam it tells you to add a line to ~/.vimrc, did you do that?
<sarna> zolk3ri: yep
<sarna> the FileType one
<sarna> (it was wrong though, I had to change it)
<sarna> ((the path didn't exist))
<reynir> I use opam-usersetup for that
<reynir> opam user-setup
<sarna> okay, got merlin working, ocp-indent is still broken though
<narimiran> sarna: do you have both `opam install ocp-indent` and the vim plugin of the same name?
<sarna> narimiran: I have a working ocp-indent command installed with opam. I also followed their instructions wrt vim
<narimiran> then i'm out of ideas :)
<narimiran> oh, here's one more: did you restart vim after installing the plugin? :D
<zolk3ri> Yeah, have you tried turning it off and on?!
<sarna> yeah, I even rebooted :(
<sarna> the worst part of programming - when the tools don't work and you don't know why
<zolk3ri> Yeah I have no idea, I use emacs. :/
dhil has joined #ocaml
<reynir> sarna: I tend to do 'opam install user-setup; opam user-setup install' after I've installed merlin, ocp-indent and such
<sarna> found it.. it was that issue https://github.com/OCamlPro/ocp-indent/issues/268
<sarna> that means everything works now, ha
zolk3ri has quit [Ping timeout: 260 seconds]
<reynir> \o/
<narimiran> sarna: wait, i also use neovim. do i also need to add/remove something in my settings?
<narimiran> i've noticed that indentation levels are "wonky" when going to the new line. could this be connected?
<sarna> narimiran: you have to comment the first five lines in ocaml.vim
<Leonidas> ocamlformat ftw :p
Haudegen has joined #ocaml
<sarna> ...why nobody told me about this one when I couldn't get ocp-indent to work
<sarna> lol, got it to work in three minutes
<sarna> thanks Leonidas
<narimiran> Leonidas: from my limited experience, ocamlformat is waaaay too aggressive compared to ocp-indent
<prsafont[m]> it has lots of knobs and pulls to get better results with existing code
<Leonidas> narimiran: that's exactly what I want. I want a fixed way to encode the source code
<def`> sarna: have you tried https://github.com/let-def/ocp-indent-vim?
<def`> (While working inside vim, I find ocp-indent more comfortable)
mbuf has quit [Ping timeout: 265 seconds]
<sarna> def`: last touched 2 years ago, I think I'll stay with ocamlformat
<Leonidas> narimiran: we originally introduced it to avoid spending too much time bikeshedding about formatting in reviews and teaching new people how to format
<def`> sarna: lol
<Armael> sarna: that just means that it's perfect!
<narimiran> prsafont[m]: i couldn't get it to produce ocp-like results, even though it has a switch that says that
<Leonidas> narimiran: but the way I use it I just write the most sloppy stuff that barely compiles and ask ocamlformat to figure out that mess
<narimiran> and sometimes i really really don't want some space around operators, and such
<sarna> Armael: sure, like common lisp
kjak has quit [Ping timeout: 265 seconds]
<Leonidas> yeah, I *really* dislike arbitrary strange changes, I always wonder if it was deliberate or not
<Armael> *shrug*
<Armael> just be aware that ocp-indent and ocamlformat serve somewhat different purposes
<Leonidas> yes, that's very much true
<sarna> hm, what are they?
<sarna> I thought they were for the same thing
<Armael> ocp-indent only deals with indentation, ocamlformat reformats your whole code
<Leonidas> also interesting how dune 2 is planning to strong-arm ocamlformat into everyone's workflow :D
<narimiran> also: if i put 2 or 0 empty lines between two functions, i did it for a reason, i don't want 1 empty line
<prsafont[m]> narimiran: there are a few "space-around-" switches that I can see
<Leonidas> we have some people who really like to format their code in their own artisanal way, so there's a bit of a conflict
<Armael> also, ocp-indent is used by everyone at this point, which is not the case with ocamlformat
<Leonidas> narimiran: that reason is known to you just now, but noone else and in 5 years not even you, so why not just be consistent
<Leonidas> Armael: Everyone? I have never in my life used it.
<Armael> fine. almost everyone then :p
<Armael> what were you using before ocamlformat?
<sarna> oh, I see
<narimiran> btw, i'm using ocp-indent-vim, until def` recommended it to sarna i thought we were talking about it, but it seems there is also (official?) version without 'vim' in its name?
<Leonidas> Armael: nothing. Fighting with how Vim formats stuff by default, mostly.
<Armael> huh.
<Leonidas> it mostly does the right thing
<sarna> narimiran: I was using this one https://www.typerex.org/ocp-indent.html
<narimiran> sarna: ocp-indent-vim has this as its first line: `if exists("b:did_indent") || expand('%:e') == 'mly'` — don't know if that would have helped you
<narimiran> and, although it had no commits in 1.5 years, i find it quite good, if i don't count all those initially wrong indent levels for pipes or match cases
<narimiran> it goes something like "oh, a new line, let me put there 4 spaces, no, now is 0, oh wait, here's your 2"
<sarna> narimiran: if ocamlformat becomes annoying I'll use this one :^)
<sarna> lol
<narimiran> sarna: fwiw, for me ocamlformat was way more annoying than those indent-mishaps
sarna has quit [Remote host closed the connection]
mbuf has joined #ocaml
<narimiran> aaand, it seems that commenting out that part of ocaml.vim solves my indent-problems mentioned above!
<narimiran> maybe sarna didn't fix his problems, but he did mine :)
sarna has joined #ocaml
mbuf has quit [Read error: Connection reset by peer]
mbuf has joined #ocaml
<narimiran> now, with that out of my way: are ocaml's Map/Hashtbl of (int, int) tuples as keys way much slower than python's dict or am i doing something wrong?
<def`> narimiran: you are probably doing something wrong :)
<narimiran> def`: can you maybe spot my error in this snippet, i.e. how to improve this? http://ix.io/23rj/ocaml
<Leonidas> rgrinberg: is there any way to make packages using dune.configurator work with dune 1.x and 2.0? Adding a dependency on dune-configurator pulls up to 2.0, whereas leaving it out (allowing for dune 1.x) breaks building on 2.0.
<narimiran> def`: i've also tried to use OSeq instead of List as an input to `follow`, but nothing significantly changed. using Hashtbl gave me 2x speedup, but that's still much slower than expected
<Leonidas> rgrinberg: oh, nevermind, it seems like dune-configurator.1.0 works with dune < 2
<def`> narimiran: do you have a test case ?
<narimiran> def`: give me a sec to share the whole program, plus its input
<narimiran> i call this `follow` function two times, each time it is a list/seq with ~150k elements
<narimiran> def`: full program: http://ix.io/23rP ; input: http://ix.io/23rQ
<thizanne> d
<def`> narimiran: it takes around 250ms here. this is slower than python?
FreeBirdLjj has joined #ocaml
<narimiran> def`: yep
<def`> do you have the python code too :) ?
<narimiran> i have _some_ python code, not mine
<narimiran> but the thing is, based on previous AoC days and the usual python<->ocaml differences, i would expect that optimal ocaml solution should run in less than 10ms
<narimiran> now i'm thinking the slowness might come because of creation of lots of tuples, but i don't see an easy way around it
<Armael> you can use a big matrix
<Armael> I guess
<Armael> instead of a map
<narimiran> Armael: i'll have both positive and negative indices, plus i don't know the dimensions (yeah, i tweak it until it works, but that's cheating :))
<Armael> can't you compute the dimensions from the input?
<Armael> (I agree that it's a bit unpleasant)
<narimiran> Armael: ideally it should work for any input, but i can tweak it to work only for this one
<narimiran> even still, i would like to know where does this poor performance come from, and if there's a way around it using Map or at least Hashtbl
<def`> narimiran: parsing the input already takes ~80ms
<def`> so it it seems unlikely to finish in 10ms
<narimiran> Armael: to have some idea about dimensions (not my input): https://i.redd.it/r170jdax3d241.png
<Armael> okey, a matrix sounds like a bad idea then
<narimiran> def`: then i _also_ need to parse it differently :)
<narimiran> def`: parsing-only on my machine takes ~20ms :/
<thizanne> that's still more than 10ms though
<narimiran> thizanne: yeah, it is. but how do i optimize the remaining ~150ms?
<Armael> narimiran: is the input you linked above the largest input you have?
<narimiran> Armael: yep, and others should be approximately the same size
<Armael> explode_instr seems a bit brutal
<Armael> but if it works then no need to be very clever
tane has joined #ocaml
<narimiran> Armael: heh, from 300 elements, it becomes ~150k
<Armael> ye
<narimiran> Armael: but even if i keep it at 300, later on, i'll need to have all those ~150k in the Map
mbuf has quit [Quit: Leaving]
<narimiran> here's my OSeq version of the same thing: http://ix.io/23rV - no noticeable difference compared to the List version
<def`> are you sure other solutions transform the lines into points ?
<companion_cube> Leonidas: Core does use its own iterator type, doesn't it?
<def`> because I suspect this is where most of the overhead comes from, you change the asymptotic complexity of the problem
<def`> (and of the parser)
<Armael> ye I would believe so
<narimiran> def`: here's the top-voted python solution: https://old.reddit.com/r/adventofcode/comments/e5bz2w/2019_day_3_solutions/f9iz68s/
<def`> narimiran: how long does that takes ?
<narimiran> slightly less than my ocaml solution (165ms vs 185ms)
<thizanne> narimiran: your "oseq version" is some bash script
<Armael> thizanne: you removed the last V
<thizanne> ?? thanks I guess
<narimiran> thizanne: full link has V at the end: http://ix.io/23rV
<narimiran> at first i thought your comment was about how shitty my ocaml is :D
<companion_cube> narimiran: why use List.map if you go full OSeq ?
<thizanne> narimiran: I would expect maps to be slower than hash tables
<thizanne> (and python dicts are hash tables)
<narimiran> companion_cube: because of the `List.hd wires, List.hd (List.tl wires)` line because i don't know better than that? :)
<companion_cube> ah well
<companion_cube> there's OSeq.memoize but yeah
<narimiran> thizanne: i started working on my Hashtbl solution and it showed ~2x performance gain over Map
<companion_cube> use Hashtbl.Make(), it also makes a difference
<narimiran> companion_cube: oh, i've never used it before. i need to define how to hash my keys?
<companion_cube> yes, and equality too
<companion_cube> you can search for Hashtbl.Make on github I think
<narimiran> companion_cube: so, i need to add `hash` to this? http://ix.io/23rj/ocaml
<companion_cube> yeah, mostly
<companion_cube> and replace compare with equal
<companion_cube> (which is simpler to write)
<narimiran> argh, why would there be an example in the docs.... that would be too easy for newcomers....
<companion_cube> :/
<companion_cube> (please make a PR!)
<companion_cube> yeah
<companion_cube> I made a PR years ago for Map.Make
<companion_cube> but you could do the same for Hashtbl.Make!
<narimiran> companion_cube: that was you? a big thank you from me for that!! been using that example!
<companion_cube> I think it was me, yes :p
<Fardale> narimiran: there is a example here http://caml.inria.fr/pub/docs/manual-ocaml/libref/Hashtbl.html
<narimiran> Fardale: oh! thanks!!
<narimiran> yep, that gave ~15% boost, for my highly sophisticated hash function of (int, int) tuple: `let hash (x, y) = 1000 * x + y` :D
<companion_cube> take a look at CCHash ;)
<narimiran> companion_cube: what specifically should i look at? :)
<companion_cube> combinators
<companion_cube> CCHash.(combine2 (int x) (int y)) typically
<narimiran> that's slower than my hash :D :D :D
<companion_cube> but hopefully better
<Armael> what about "let hash = Hashtbl.hash"
<narimiran> Armael: aren't i then back to where i was without Hashtbl.Make?
<Armael> idk
<ggole> No, because the equality function will be the specialised one
<ggole> iirc there's a ppx_hash, that might be worth trying
zolk3ri has joined #ocaml
<narimiran> btw, is there a way to set up utop to always load some module at startup?
<Fardale> narimiran: I have this https://zero.crans.org/?5811678f10bf1642#5JsG34zGnSx31tzFABkSmepcnLRo5sCaZE2739WwFA44 in ~/.ocamlinit to use topfind and to load containers
<narimiran> Fardale: thanks! `#require "containers"` is exactly what i had in mind :)
<companion_cube> Armael: yeah, also works
<Armael> narimiran: btw here I think it makes little sense to fine tune a bruteforce algorithm; you'll be faster by probably an order of magnitude of you optimize the algorithm instead of the current implem :)
<Armael> if*
<narimiran> Armael: agreed
<narimiran> what bothers me is that brute-force python is faster :) but now i started to work on a completely different solution. let's see where that will take me....
kjak has joined #ocaml
dhil has quit [Ping timeout: 240 seconds]
smazga has joined #ocaml
alfonsox has joined #ocaml
zolk3ri has quit [Remote host closed the connection]
Serpent7776 has quit [Quit: Leaving]
<narimiran> companion_cube: can i combine OSeq and containers? e.g. for `.of_seq` stuff?
<companion_cube> :/
<companion_cube> don't open Containers and it'll work
<companion_cube> but there's an unfortunate name collision from when `Iter` was named `Sequence` (before the standard `Seq` even existed)
<narimiran> companion_cube: hmm, i've just tried in utop where i #require-d both of them...
<companion_cube> should work if you use List.of_seq
<narimiran> thanks, will play with it
FreeBirdLjj has quit [Remote host closed the connection]
ziyourenxiang has quit [Ping timeout: 265 seconds]
vicfred has quit [Quit: Leaving]
mbuf has joined #ocaml
FreeBirdLjj has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 276 seconds]
mbuf has quit [Quit: Leaving]
spew has joined #ocaml
unyu has quit [Quit: reboot]
unyu has joined #ocaml
dhil has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
<narimiran> boom!! from ~200ms down to ~50ms!
alfonsox has quit []
ggole has quit [Ping timeout: 250 seconds]
dborisog has quit [Ping timeout: 265 seconds]
jnavila has joined #ocaml
bitwinery has joined #ocaml
nicoo has quit [Ping timeout: 260 seconds]
jnavila has quit [Ping timeout: 252 seconds]
Haudegen has joined #ocaml
jnavila has joined #ocaml
jnavila has quit [Ping timeout: 246 seconds]
barockobamo has joined #ocaml
brettgilio has quit [Ping timeout: 250 seconds]
jnavila has joined #ocaml
nicoo has joined #ocaml
jmiven has quit [Quit: bye]
jmiven has joined #ocaml
bartholin has joined #ocaml
jao has joined #ocaml
jao is now known as Guest95385
unyu has quit [Quit: brb]
unyu has joined #ocaml
iovec has joined #ocaml
smazga has quit [Ping timeout: 276 seconds]
kakadu has joined #ocaml
smazga has joined #ocaml
gareppa has joined #ocaml
Guest95385 has quit [Ping timeout: 246 seconds]
narimiran has quit [Quit: leaving]
gravicappa has quit [Ping timeout: 265 seconds]
jao has joined #ocaml
vesper11 has quit [Ping timeout: 246 seconds]
vesper11 has joined #ocaml
tane has quit [Quit: Leaving]
gareppa has quit [Ping timeout: 265 seconds]
brettgilio has joined #ocaml
vicfred has joined #ocaml
jnavila has quit [Remote host closed the connection]
dogui has quit [Ping timeout: 276 seconds]
dogui has joined #ocaml
Hrundi_V_Bakshi has joined #ocaml
<companion_cube> ok I have an itch to reimplement linenoise in OCaml, the C codebase isn't really nice :/
<madroach> Hi companion_cube, I like your CCLwt_klist. I wanted a lazy version of its of_list function. This seems to be impossible because Lwt evaluates its bind callbacks eagerly.
<companion_cube> oh wow, where did you find that? is it in the old containers0-misc? :D
<companion_cube> -0
kakadu has quit [Quit: Konversation terminated!]
ziyourenxiang has joined #ocaml
johnelse has joined #ocaml
<madroach> has it proven useful?
<companion_cube> haven't touched that in years
<companion_cube> have you looked at lwt-pipe? I think Fardale is using it
<madroach> companion_cube: yes, I know lwt-pipe. I was looking for a datastructure representing a stream that could be functorised over different promise modules like Lwt, Async or Engines.
<madroach> But it has to be lazy.
<madroach> Seems like one would need to use something generator-like then. This would be lazy by nature.
<companion_cube> oh boy, that sounds painful
dhil has quit [Ping timeout: 240 seconds]
iovec has quit [Quit: Connection closed for inactivity]
Hrundi_V_Bakshi has quit [Ping timeout: 246 seconds]
brettgilio has quit [Ping timeout: 250 seconds]
Haudegen has quit [Ping timeout: 265 seconds]