<Nikkel>
I think I'm doing everything correctly, but apparently not
<ggole>
That certainly looks OK
<ggole>
Unless Set.Make doesn't produce a module matching Set.S in 4.08, which would be more than a bit surprising
tizoc has quit [Quit: Coyote finally caught me]
tizoc has joined #ocaml
<Nikkel>
ggole: If I leave out the type declaration, then everything is okay
<Nikkel>
that is, if I just have it defined in types.ml
<ggole>
Is there anything which could shadow Set in the signature but not the implementation?
silver has joined #ocaml
<Nikkel>
ggole: I don't think so. I just tried with Product_Match_Set: Stdlib.Set.S to qualify it
<Nikkel>
I could also try with BatSet, but this really should be working
<ggole>
It's almost as if you have the latest version of Set.S, but an old version of Set.Make
<ggole>
But that shouldn't be possible.
<ggole>
What happens if you compile a single file containing just those definitions? eg, module Product_Match = struct type t let compare (_ : t) _ : int = assert false end module Types : sig module Product_Match_Set : Set.S with type elt = Product_Match.t end = struct module Product_Match_Set = Set.Make (struct type t = Product_Match.t let compare = Product_Match.compare end) end
<Nikkel>
let my try and see
<Nikkel>
After this opam update and upgrade
<ggole>
(btw, that can just be Set.Make (Product_Match). But ignore that until you've figured out your problem.)
<octachron>
Nikkel, it looks like Set.Make is shadowed by something
jgkamat has quit [Ping timeout: 276 seconds]
<Nikkel>
Oh
<Nikkel>
octachron: So I should try doing Stdlib.Set.Make instead?
<octachron>
Yeah, you could also check if you are using a library that may shadow Set
gareppa has joined #ocaml
jco has joined #ocaml
jco has quit [Client Quit]
jco has joined #ocaml
nullifidian_ has joined #ocaml
nullifidian has quit [Ping timeout: 276 seconds]
Haudegen has quit [Quit: Bin weg.]
jco has quit [Quit: WeeChat 2.6]
gareppa has quit [Quit: Leaving]
jgkamat has joined #ocaml
<Nikkel>
octachron: Thanks, that did the trick. I overlooked that I had Batteries and not just BatPervasives in types.ml
Haudegen has joined #ocaml
jco has joined #ocaml
jao has joined #ocaml
jco_ has joined #ocaml
jco has quit [Ping timeout: 252 seconds]
jaar has joined #ocaml
spew has joined #ocaml
jao has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
jao has joined #ocaml
tane_ has quit [Quit: Leaving]
<Nikkel>
Are there any nice libraries for formatting currency strings? So for example f 24415313.510 = "24,415,313.51"
<flux>
not sure, but please don't use floating point numbers for currency if you can help it :)
<Nikkel>
I know
<Nikkel>
But thank you :) luckily it's not vital at all here
<flux>
formatting in that way doesn't seem very hard for a given an integer
<flux>
first you take `mod 100` of the number and use `Printf.sprintf ".%02d" (x mod 100)` to format it
<flux>
and the rest you handle with a recursing loop that uses the divisor 1000 each loop
<flux>
(I'm assuming the integer is scaled to mean 1 = 1 cent)
<Nikkel>
Thank you very much :) I'll do how you say
narimiran has quit [Read error: Connection reset by peer]
narimiran has joined #ocaml
<companion_cube>
qcheck released 🎉
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
<narimiran>
currently i'm doing this: `Intset.of_list (CCList.range' 0 100)`, but it *seems* inefficient. is there a better way?
<oni-on-ion>
MS will merge github and vscode
<narimiran>
also, is there a(n easy) way to create a sequence of some range? would seq be a better choice than a list?
<companion_cube>
for the standard `seq` there's my `oseq` library with tons of combinators
h116 has joined #ocaml
<narimiran>
i'll give it a try
<narimiran>
companion_cube: first impressions: OSeq misses an equivalent of the nice CCList.range_by :)
amiloradovsky has joined #ocaml
<companion_cube>
erf :D
<companion_cube>
PR welcome though, shouldn't be too hard
<narimiran>
btw, how do you profile your code and find bottlenecks?
mbuf has quit [Quit: Leaving]
<companion_cube>
I tend to use perf
<narimiran>
i'm starting to think that converting int lists to int sets, just to do some set diffs and intersections, creates too much overhead for my use case....
<ggole>
let int_set_of_range low high = let set = ref Intset.empty in for i = low to high do set := Intset.add i !set done; !set
<ggole>
Remember: the uglier, the faster. Them's the rules.
<narimiran>
ggole: heh, i also sometimes get that feeling, but for now i'm trying to keep things "acceptable amount of ugly" :)
<ggole>
If you have a Range module lying around with a fold operation, that would probably fit.
<narimiran>
no Range in stdlib nor in Containers. (and i'm trying to avoid Core & co. for now)
<companion_cube>
OSeq.(1 -- 10 |> to_list);; btw
<narimiran>
companion_cube: yeah, i'm already using either `CCList.range` or `CCList.(--)` and their upper-bound-excluded variants
<companion_cube>
the difference is that this is a sequence, not a list :)
<companion_cube>
that being said, if you take intersections of int ranges, it can be done with int pairs :D
<narimiran>
wait wait, doesn't `to_list` convert it back to list?
<companion_cube>
yeah it's just for demo purpose
<narimiran>
btw, "conversion to int sets is slow, i know better". now everything is 100x slower. bravo, maestro! :D
<narimiran>
please expand more about "it can be done with int pairs"
<Armael>
if you are only dealing with intervals then you can represent them as the pair of their lower and upper bound
<Armael>
(works well if you are only intersecting intervals, but not really if you are also taking their union, since the union of two intervals may not be an interval)
<narimiran>
i have two sets, e.g. one is {0 .. 100}, the other one is {5, 15, 23, 47, 55, 91}
jnavila has joined #ocaml
<Armael>
then you should probably stay with sets I guess :)
<companion_cube>
yes indeed!
<narimiran>
eh, i've changed every instance of List with OSeq where possible, and there's no impact on performance....
<companion_cube>
:D
<companion_cube>
as a side note, union and intersection of sorted lists isn't too bad either
<narimiran>
but hey, i had on my todo list to start using seq's, so i did at least that :)
<narimiran>
ok, lets see if List.sort_unique will be less than 100x slower :D
<companion_cube>
I mean, if you preserve the ivnariant that they're sorted !
<companion_cube>
not if you re-sort them all the time
<narimiran>
one of them is sorted, the other one is all over the place :)
brettgilio has quit [Ping timeout: 250 seconds]
sagax has quit [Read error: Connection reset by peer]
Haudegen has joined #ocaml
bitwinery has joined #ocaml
bitwinery has quit [Remote host closed the connection]
bitwinery has joined #ocaml
sagax has joined #ocaml
jnavila has quit [Ping timeout: 246 seconds]
unyu has quit [Quit: reboot]
unyu has joined #ocaml
gravicappa has quit [Ping timeout: 268 seconds]
cobreadmonster has quit [Quit: Connection closed for inactivity]
<companion_cube>
is it just me, or is opam-ci really overloaded? :D
ggole has quit [Quit: Leaving]
gareppa has joined #ocaml
kakadu has joined #ocaml
jnavila has joined #ocaml
<spew>
if you build it they will come
<spew>
and then you'll wish they hadn't
<companion_cube>
seems like some PRs rebuild Coq :°
exprosic has joined #ocaml
gareppa has quit [Quit: Leaving]
brettgilio has joined #ocaml
narimiran has quit [Ping timeout: 268 seconds]
nullifidian__ has joined #ocaml
nullifidian_ has quit [Ping timeout: 265 seconds]
jco_ has quit [Quit: WeeChat 2.6]
ravenousmoose has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jnavila has quit [Remote host closed the connection]
tane has quit [Quit: Leaving]
amiloradovsky has quit [Ping timeout: 240 seconds]
ygrek_ has joined #ocaml
profan has joined #ocaml
profan has quit [Client Quit]
kakadu has quit [Remote host closed the connection]