janmidtgaard.bsky.social
Recovering academic. Occasionally hacks OCaml and property-based testing, manufacturing bad luck on an industrial scale.
Mastodon account: https://types.pl/@jmid
35 posts
63 followers
76 following
Regular Contributor
Active Commenter
comment in response to
post
Good stuff (of course there's property-based testing involved! 🤓) and a very nice collaboration with past @tarides.com summer interns and colleagues. The paper is even open access for your reading pleasure:
link.springer.com/chapter/10.1...
comment in response to
post
Just... have... to drop this... here.
comment in response to
post
github.com/ocaml/opam-r...
uses
github.com/ocaml/opam-r...
which uses
github.com/ocaml/opam-r...
which seem to be supported on Windows.
The status page is green for one of 4.14 or 5.3 on each.
Which OCaml version are you using - you didn't say?
comment in response to
post
Which libraries is your (minimal) example using?
Are you perhaps using caqti-driver-postgresql?
Also, which versions of the libraries are you using?
comment in response to
post
Also: Beware that not all packages may work out of the box on Windows, as they tends to require C code and libraries at some point, and setting that up may require fiddling with conf-* files on the opam repository.
Caqti should however run on Windows, it seems from
windows.check.ci.dev
comment in response to
post
From the error message, it sounds like an error while trying to use postgresql with Caqti. If that's the case, I would try to cut out 'dream' and see if a simple 5-10-line OCaml program can connect with such a database through Caqti.
comment in response to
post
OK. If I'm understanding the above page correctly, this means you got a MinGW installation of the compiler (it's the default).
It is handy to know, to understand the problem and when searching, e.g., Google or Discuss for someone else with a similar problem.
comment in response to
post
Yep 👍 How did you install OCaml under Windows?
ocaml.org/docs/ocaml-o... lists some of the variants I mentioned above.
comment in response to
post
For the latter I would probably use the `nm` tool on Linux.
comment in response to
post
3. You are getting a linking error. This means the compiler(s) translated each file, but failed in the last part stitching them together based on names. Here it fails to resolve a bunch of names listed in the error. Have you checked that the mentioned file(s) exist - and that they contain the names?
comment in response to
post
2. You are sharing an error message - but not much about the code that trigger it. Generally it helps to create and share a small reproducer. From such a thing, I sometimes end up figuring out the problem myself...
comment in response to
post
I don't have the answer for you, so here's some general advice:
1. Your post is too short on detail. For one, OCaml can run in at last 4 ways on Windows (MinGW, Cygwin, MSVC, WSL, ...). Which one are you using?
comment in response to
post
Using a tuple-comma with right-to-left evaluation seems a distraction. Is that intentionally or did it get mixed up with the single ; sequence operator? ocaml.org/docs/mutabil...
comment in response to
post
OK, but that does something with a worse complexity.
In your gist, List.mem is going to take O(n) time, and you are calling it for each row * col.
I'm suggesting something like dropping `|> PosSet.of_list`
and replacing `PosSet.iter` with `List.iter`, thus taking only 1 pass over the list 🙂
comment in response to
post
After a quick look at that code, you seem to only use PosSet in part2, where the set is represented as a list, then transformed into a set only to iterate over it. Unless this is a bottleneck, I would probably just keep the list as is and iterate over that directly... 🤔🤷
comment in response to
post
If your use case is something involving integers, you might consider Patricia trees, a functional and fast bit-walking trie-like data structure:
github.com/backtracking...
codex.top/api/patricia...
comment in response to
post
In OCaml's Stdlib sets are represented as balanced search trees: github.com/ocaml/ocaml/...
The answer is therefore "it depends". For many uses assuming no/few collisions hashtables are going to be fast. Worst case, however probing may end up spending O(n) time. Sets offer a worst case of O(log n).
comment in response to
post
Thanks for the kind words Sabine 🙏☺️
comment in response to
post
The future is still up in the air. I've been taking a break to hack on a couple of open source things and to go skiing with the family over the winter holidays. ⛷️
Feel free to shoot me a PM if you want to meet, catch up, and chat over a coffee ☕ 🙂
comment in response to
post
Yep 👍 It reminds me (again) of steps 1 and 2 of this nice, pedagogical paper that I was academically raised with: citeseerx.ist.psu.edu/document?rep... As a result, I tend to just read these as "named in either prefix or postfix notation"... 🤓
comment in response to
post
You are however introducing a data dependency, which I believe corresponds to an eta-expansion in a desugared version. These should align:
```
(* Prints hello after world *)
let _ = f "hello" () >>= fun u -> f "world" u
(* Prints world after hello *)
let _ = let* u = f "hello" () in f "world" u
```
comment in response to
post
This is just the good old right-to-left evaluation issue surprising for the N+1'th time, isn't it? 🤔
Recall that despite its syntax, >>= is just a 2-argument function call to bind underneath the hood, which are most likely evaluated right-to-left, but with evaluation order technically undefined.
comment in response to
post
I don't think so. My friend is more into 3d-printing that FP...
He happened to have a fair amount of excess orange ligaments after printing pumpkins for Halloween, and then thought of me 😄