rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bcksl has quit [Quit: \]
end has quit [Quit: end]
jabuxas has joined #ocaml
bcksl has joined #ocaml
end has joined #ocaml
pi3ce has joined #ocaml
jabuxas has quit [Ping timeout: 272 seconds]
waleee has quit [Ping timeout: 252 seconds]
tri has joined #ocaml
mbuf has joined #ocaml
z0e has joined #ocaml
sroso has joined #ocaml
average has joined #ocaml
zanetti has joined #ocaml
zanetti has quit [Quit: zanetti]
myrkraverk_ has quit [Read error: Connection reset by peer]
myrkraverk_ has joined #ocaml
tri has quit [Remote host closed the connection]
z0e has quit [Quit: Client closed]
Serpent7776 has joined #ocaml
mima has joined #ocaml
average has quit [Quit: Connection closed for inactivity]
mbuf has quit [Ping timeout: 255 seconds]
mbuf has joined #ocaml
dnh has joined #ocaml
mima has quit [Ping timeout: 252 seconds]
dnh has quit [Ping timeout: 260 seconds]
nickblack has joined #ocaml
nickblack has quit [Remote host closed the connection]
dnh has joined #ocaml
dnh has quit [Ping timeout: 256 seconds]
<discocaml>
<JM> Gooby: On that list ahrefs and besport are both commercial web products, so from a high level the answer has to be "yes, OCaml is ready".
<discocaml>
<JM> But when it comes to specifics, eg. stripe integration, the sample size is too small to guarantee any of these 2 will be using the tools/integrations you need. So you'll have to check your specific use cases.
<discocaml>
<gooby_clown> That seems fair enough, I've been reading the Ahref blog yesterday and it seems they are making a lot of use of the existing OCaml toolset which is nice, as for the integrations hopefully one day that will be sorted out as well 😄
bartholin has joined #ocaml
sroso has quit [Read error: Connection reset by peer]
sroso has joined #ocaml
dnh has joined #ocaml
mima has joined #ocaml
sroso has quit [Quit: Leaving :)]
<companion_cube>
If anything, the biggest user is still Janestreet
jabuxas has joined #ocaml
<discocaml>
<limp.biskit> ocaml is ready, but mass adoption is different
<discocaml>
<limp.biskit> lots of languages have been ready for years, most online shops will still use php
<discocaml>
<lukstafi> Oh my, `ppx_jane` pulls in _a lot_ of dependencies. I'm starting to question my ways.
<companion_cube>
ha!
<discocaml>
<lukstafi> The part I'm extremely happy with is sexplib and `deriving sexp`.
<discocaml>
<lukstafi> Witness-based containers from `base` are nice, I got used to them, but can imagine living without.
<discocaml>
<lukstafi> The part about removing structural comparison entirely and relying on `deriving equal,compare,hash` is probably the right way to go.
<companion_cube>
agreed on that one
<discocaml>
<limp.biskit> the only thing that makes me feel better about base is that so much stuff depends on it i usually have it preinstalled in a dev environment
<discocaml>
<limp.biskit> but nowadays i also have containers installed most the time because i land up pulling it in anyway for the much better string library
<discocaml>
<limp.biskit> fieldslib is a nice idea, but i found it very confusing and not worth the complexity
<companion_cube>
I stick with only a few ppx typically, the old school ones (ppx_deriving.std, a specific one for serialization…)
<discocaml>
<limp.biskit> some riot people are making a version of serde for ocaml
<companion_cube>
yeah… and it pulls in one of their dep
<discocaml>
<limp.biskit> wow, you're saying you don't want another incompatible stream implementation
<Armael>
tfw there's both a rio and riot opam package
<discocaml>
<limp.biskit> i don't know if it supports tagging individual fields like go's serialisation does, if it doesn't seems a bit useless
<discocaml>
<limp.biskit> i already have relatively few ocaml datastructures that can map 1-1 to their intended json form on deriving functions
<discocaml>
<regularspatula> @lukstafi Base itself is pretty light though
<companion_cube>
I don't even really know what rio is
<companion_cube>
another buffer library? like, why
<discocaml>
<limp.biskit> ocaml is allergic to standardisation 🤷♀️
<companion_cube>
if there was just a bit more in the stdlib (a few more types, that is) it'd certainly help
<companion_cube>
otherwise, the curse is that OCaml makes it so easy to rewrite your stuff that everybody does
<olle>
companion_cube: well compare with forth hahaha
<olle>
ocaml is very fine comparatively
<companion_cube>
ah no, with forth you have to do your own forth
<companion_cube>
totally different! 😂
<olle>
you don't "have to", but people do
<olle>
for some darn reason
<olle>
But compared to PHP, OCaml has more duplication in its eco-system, I find.
<discocaml>
<limp.biskit> hopefully picos lessens the situation for schedulers
<discocaml>
<limp.biskit> don't know about standard stream libraries though since eio, riot and lwt all have their own
<companion_cube>
a concurrent stream is very tied to the concurrency model…
<companion_cube>
tbh the only hope we have is that picos gets adoption and defines one
<discocaml>
<limp.biskit> my thoughts, don't know if it might be considered "out of scope"
<companion_cube>
I mean a stream type might be built on top
<companion_cube>
and thus work for everyone 🤞
<discocaml>
<limp.biskit> that and a high level promise implementation would probably make most simple things portable
<olle>
promise?
<companion_cube>
picos has it!!
<discocaml>
<limp.biskit> nice!
<discocaml>
<limp.biskit> didn't realise
<companion_cube>
it has slightly more sophisticated concepts but yeah
z0e has joined #ocaml
waleee has joined #ocaml
waleee has quit [Client Quit]
tri has joined #ocaml
average has joined #ocaml
tri has quit [Ping timeout: 245 seconds]
jabuxas has quit [Ping timeout: 260 seconds]
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
emilknievel has joined #ocaml
bartholin has quit [Ping timeout: 256 seconds]
z0e has quit [Quit: Client closed]
<discocaml>
<dinosaure> yes, for instance miou does not use the same promise model than picos, I think we need to agree on how to have an unique identifier for promise and how to get the current one. picos uses `==` and I decided to use a simple number
tri has joined #ocaml
<companion_cube>
for the most part I think you should use TLS/an effect to get the current fiber?
<companion_cube>
if we also had standard TLS it'd help, of course, but well
tri has quit [Ping timeout: 255 seconds]
<discocaml>
<dinosaure> picos defines a effect to know which is the current promise (useful to implement mutex & condition)
<discocaml>
<dinosaure> but I will prefer to return an unique identifier - it will give an opportunity for any scheduler to define their own promises
bartholin has joined #ocaml
<discocaml>
<gabyfle> Hi ! I'm currently writing a quite huge program and I just found out that my code have a bug because of something I did not thought of. I'm using a lot of immutable data structures and I do have two "parallel" data structures built on the `Map` module.
<discocaml>
<gabyfle>
<discocaml>
<gabyfle> Of what I understood, my problem is related to physical equality between values when using `Map.add`. In fact, my data structure is composed of a Map `int -> t` and a "reverse map" `t->int`, where `t` is an immutable data structue. Sometimes, I can see having multiple times the same value inside the inverse map because I use `add` as if it'll not check the "physical" equality.
<discocaml>
<gabyfle>
<discocaml>
<gabyfle> Does anyone know how to make a turnaround that is not too dirty ? I would love to have a `add` function that just checks values, not physical equalities. Thanks a lot in advance !
<discocaml>
<gabyfle> Hi ! I'm currently writing a program and I just found out that my code have a bug because of something I did not thought of. I'm using a lot of immutable data structures and I do have two "parallel" data structures built on the `Map` module.
<discocaml>
<gabyfle>
<discocaml>
<gabyfle> Of what I understood, my problem is related to physical equality between values when using `Map.add`. In fact, my data structure is composed of a Map `int -> t` and a "reverse map" `t->int`, where `t` is an immutable data structue. Sometimes, I can see having multiple times the same value inside the inverse map because I use `add` as if it'll not check the "physical" equality.
<discocaml>
<gabyfle>
<discocaml>
<gabyfle> Does anyone know how to make a turnaround that is not too dirty ? I would love to have a `add` function that just checks values, not physical equalities. Thanks a lot in advance !
<companion_cube>
@dinosaure you just wrap a `Computation.t` and that's it right?
<companion_cube>
as long as you do that, other libraries can await your promises and all is good
<discocaml>
<dinosaure> yes, my promise has few more information but it's basically a Computation.t 🙂
<companion_cube>
then all is good
<companion_cube>
I need to get to that too…
<discocaml>
<._null._> What's your issue exactly? It souns like you need a revmap `t -> int` which can hold many values for every t, why not make it a `t -> int list` map ?
<discocaml>
<._null._> What's your issue exactly? It sounds like you need a revmap `t -> int` which can hold many values for every t, why not make it a `t -> int list` map ?
<discocaml>
<gabyfle> Nah, in fact I don't need to hold many values for one `t`, actually that's my problem, it's that even tho I have two `t` that have the same value, they are sometimes added two times to the map:
<discocaml>
<gabyfle> Here `Variable(test)` aren't created at the same place but when I do make a `Map.add` with them, it looks like for OCaml their'e not the same values
<discocaml>
<gabyfle> Nah, in fact I don't need to hold many values for one `t`, actually that's my problem: each unique value of `t` should points towards a unique `int`, it's that even tho I have two `t` that have the same value, they are sometimes added two times to the map:
<discocaml>
<gabyfle> Here `Variable(test)` aren't created at the same place but when I do make a `Map.add` with them, it looks like for OCaml their'e not the same values
<discocaml>
<hockletock> the module you supply to `Map.Make` defines equality of keys, you need to use some definition other than physical equality
<discocaml>
<deepspacejohn> if you need to distinguish two immutable values, then the most reliable way of doing so is to add some kind of identifier to each one.
<discocaml>
<._null._> (It defines comparison in fact, but the point still stands)
<discocaml>
<deepspacejohn> e.g. `let new_id = let count = ref 0 in fun () -> incr count; !count`
<discocaml>
<hockletock> it defines both, actually
<discocaml>
<gabyfle> yeah, actually the type t implements a comparison on it, that's how I did the Inverse map
<discocaml>
<hockletock> oh, my mistake
<discocaml>
<deepspacejohn> and then you can have `Variable(1, test)` and `Variable(2, test)` and they won't be the same.
<discocaml>
<._null._> Are tou sure that this comparison function doesn't differentiate between values supposed to be equal ?
<discocaml>
<gabyfle> Yeah, I first thought this was the issue but I checked by doing stuff like `compare Variable("test") Variable("test")` and it was returning 0 as expected
<discocaml>
<gabyfle> I'll try with something like this, thanks !
<discocaml>
<deepspacejohn> IIRC, physical equality is never guaranteed one way or the other for immutable values, because the compiler may sometimes decide to reuse a value during optimization. adding a unique (int) ID is the best way to distinguish them.
<discocaml>
<._null._> Physical equality is also never used in maps
<discocaml>
<deepspacejohn> unless you had a weird comparison function that checked it for some reason, I guess.
<discocaml>
<gabyfle> Maybe I didn't explained well my thought bt in fact I don't need physical equality, even tho they say in the wiki that it's always ensured
<discocaml>
<gabyfle> Maybe I didn't explained well my thought bt in fact I don't need (and want) physical equality, even tho they say in the wiki that it's always ensured
<discocaml>
<._null._> This is not your problem. If you add two equal values for two equal keys, even if they are not physically equal, you will have a single binding in your map
<discocaml>
<._null._> This is not the problem you're facing. If you add two equal values for two equal keys, even if they are not physically equal, you will have a single binding in your map
<discocaml>
<gabyfle> Mhum ok, I'll have to debug a bit more then, thannks a lot for the help, I appreciate it a lot 🙏
<discocaml>
<._null._> `let a = "a" and a' = "a";; a == a';; (* false *) IntMap.empty |> IntMap.add 0 a |> IntMap.add 0 a' |> IntMap.to_list;; (* [0, "a"] *)`
average has quit [Quit: Connection closed for inactivity]
tri has joined #ocaml
jabuxas has joined #ocaml
tri has quit [Ping timeout: 260 seconds]
mima has quit [Ping timeout: 264 seconds]
rgrinberg has joined #ocaml
Serpent7776 has quit [Ping timeout: 252 seconds]
dnh has joined #ocaml
Tuplanolla has joined #ocaml
<discocaml>
<gabyfle> Ran the same test with my map, works the same, so I just don't understand how come I can end up with two bindings for the same key, wtf
<discocaml>
<hockletock> is your compare function complicated? If it isn't transitive then there can be multiple places to put a key where it is "between" its in order neighbors
waleee has joined #ocaml
<discocaml>
<hockletock> see how consecutive elements compare to each other if you turn the map into a list
<discocaml>
<hockletock> (after the bug occurs)
<discocaml>
<hockletock> consecutive keys*
<discocaml>
<gabyfle> actually, the compare function is super simple:
<discocaml>
<gabyfle>
<discocaml>
<gabyfle> ```ocaml
<discocaml>
<gabyfle> module Symbol = struct
<discocaml>
<gabyfle> type t_symbol =
<discocaml>
<gabyfle> | Number of Lnumber.t
<discocaml>
<gabyfle> | String of Lstring.t
<discocaml>
<gabyfle> | Function of Lfunction.t
<discocaml>
<gabyfle>
<discocaml>
<gabyfle> type t = Const of t_symbol | Variable of string | None
<discocaml>
<gabyfle>
<discocaml>
<gabyfle> let compare_vals (a : t_symbol) (b : t_symbol) =
<discocaml>
<gabyfle> match (a, b) with
<discocaml>
<gabyfle> | Number a, Number b ->
<discocaml>
<gabyfle> Lnumber.compare a b
<discocaml>
<gabyfle> | String a, String b ->
<discocaml>
<gabyfle> Lstring.compare a b
<discocaml>
<gabyfle> | Function a, Function b ->
<discocaml>
<gabyfle> Lfunction.compare a b
<discocaml>
<gabyfle> | _ ->
<discocaml>
<gabyfle> -1
<discocaml>
<gabyfle>
<discocaml>
<gabyfle> let compare (a : t) (b : t) =
<discocaml>
<gabyfle> match (a, b) with
<discocaml>
<gabyfle> | Const a, Const b ->
<discocaml>
<gabyfle> compare_vals a b
<discocaml>
<gabyfle> | Variable a, Variable b ->
<discocaml>
<gabyfle> String.compare a b
<discocaml>
<gabyfle> | None, None ->
<discocaml>
<gabyfle> 0
<discocaml>
<gabyfle> | _ ->
<discocaml>
<gabyfle> thanks, will try to !
<discocaml>
<gabyfle> actually, after sending the code, it may come from the default case ?
<discocaml>
<._null._> That's not correct, because `String "" < Number 0` and `Number 0 < String ""`
<discocaml>
<gabyfle> niiiice
<discocaml>
<gabyfle> hahaha thanks a lot
<discocaml>
<gabyfle> Thanks a lot for your patience and your help guys, that was clearly a very stupid bug of mine, thanks for finding it haha !
mbuf has quit [Quit: Leaving]
mima has joined #ocaml
tri has joined #ocaml
tri has quit [Ping timeout: 255 seconds]
waleee has quit [Ping timeout: 256 seconds]
jabuxas has quit [Ping timeout: 268 seconds]
<discocaml>
<Kali> avoid sending code blocks in #general since they send as one message per line on the irc bridge
waleee has joined #ocaml
tri has joined #ocaml
tri has quit [Ping timeout: 252 seconds]
bartholin has quit [Quit: Leaving]
oriba has joined #ocaml
chiselfu1e has joined #ocaml
chiselfuse has quit [Remote host closed the connection]
jabuxas has joined #ocaml
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sroso has joined #ocaml
sroso has quit [Max SendQ exceeded]
sroso has joined #ocaml
chiselfu1e has quit [Remote host closed the connection]