Continuing the successful tradition of the last couple of weeks, what is everyone hacking on this week?
I’m trying to write C++ so as to add a theory to Z3. It hurts.
1 Like
One of the reasons I’m using OCaml is I couldn’t bear working with LLVM in C++.
Yeah, I wish I could write this in rust or OCaml, but I doubt the maintainers are open to making Z3 depend on multiple languages (bindings notwithstanding)… Anyway, the lack of sum types is really awful!
You can fake them. It’s just not fun.
I’m trying to write an experimental ppx_deriving plugin for crowbar. I’ve made a few stabs at doing this before but bounced off because of a few issues with the package and lots of issues with my own lack of knowledge, but I seem to have finally eaten enough documentation to be able to make some progress. I have something very slowly taking shape now, which is super encouraging!
I’ve also been hyping our bug cleaning day for MirageOS, which will be this Friday the 17th, and I’ll take this opportunity to hype it some more 
4 Likes
Having hacked together a (somewhat) working unified interface for reading keyboard input in mirage-framebuffer last week (general and Qubes), which I’m not super satisfied with, but that at least seems to do the job, I’m now stepping through qubes-guid with gdb to figure out where my implementation disagrees with the canonical implementation (qubes-gui-agent-linux) on the exciting topic of resizing windows.
I also read up on libSDL and realized I was using tsdl in a completely horrific manner, so I’m hoping I’ll find time this week to clean that up.
This week I’m also trying to learn more about GADTs to make ocaml-openpgp prettier/faster/safer/better. It’s still a little confusing, but @dinosaure has been so kind as to provide me with excellent explanations and examples, so I feel like I’m making progress.
2 Likes
What C++ version does Z3 use? C++17 has variants (of course, I’m not implying that they are ergonomic…).
It seems to be a subset of C++11 that all major OSes and compilers support. Typically, auto and std::pair are fine, but lambdas are not used in the codebase. Z3 has been developed for more than 10 years, afair, so it’s not that surprising.
I’ve been enjoying putting obi.ocamllabs.io together over the weekend 
The sheer number of build failures due to safe-string was pretty eye-opening…
3 Likes
That’s a very nice tool. Unfortunate how bad the problem it shows is.
I wonder if there is some metric that can be used to prioritize the packages (perhaps ranking by number of dependent packages or by download stats?) There are so many of them that knowing which is the most critical to fix first could be useful.
There is this: http://opam.ocaml.org/packages/index-popularity.html that might help with picking which packages to fix.
1 Like
(and @avsm): could also be relevant to see dependencies on these libraries to get an idea how much (otherwise good) software it breaks.
super nice project. are you looking to incorporate reproducible builds?
EDIT: I fixed rawlink which made charrua-unix (@haesbaert’s DHCP implementation) not compile. See: https://github.com/haesbaert/rawlink/pull/5
… can some explain why write takes a mutable bytes (shouldn’t the source be a string, like in write_substring?)
val Unix.write file_descr -> bytes -> int -> int -> int
val Unix.write_substring file_descr -> string -> int -> int -> int
Depending on the situation you might want use a single, fixed, bytes buffer to perform your writes. But if you already have a string at hand you should use write_substring.
That makes sense, but I think you could argue the same for a Unix.write_subbytes - for instance a fixed 4096 byte buffer that only gets filled with Unix.read : file_descr -> bytes -> int -> int -> int bytes (in which case I would now have to copy those bytes to a string to pass the read bytes on to another file descriptor using Unix.write_substring).
Edit: I missed that the int -> int were ofs len, meaning that Unix.write is equivalent to Unix.write_substring (like Bytes.blit vs Bytes.blit_string, the latter blitting a substring [and not the whole string]). Anyway, I still find the naming convention used for these inconsistent.
This week I have finished the desugaring of my difference-aware printer for type errror messages:
7 Likes
I’ll be live-streaming myself building the game 2048 from scratch using some libraries we built. The livestream is tonight (Wednesday) at 7:30pm PST.
We made a library to make it simple to draw 2D shapes on screen and make them interactive, called Reprocessing. It’s a very simple library that basically makes you write a function that gets called at 60fps, and allows you to make imperative draw calls in it. We handle all the GL under the hood and try to be efficient.
Reprocessing is now at a point where we can play with it and make actual games, so that’s what we’re doing.
We made flappy bird last week and it went pretty well, only took us 3h lol.
It is exciting though because now I’m pretty confident in saying that one can write a simple game in OCaml.
Here’s the channel where the flappy bird livestream is: https://m.youtube.com/channel/UCt9qBLTPcmN_x6YWys3bWVQ
If you watch the livestream you’ll see that we have a special hook in reprocessing that allows the user to get hotreloading, meaning the user saves the file and in a couple hundred ms the game runs their new code. The way we achieved that is stupidly simple, and will make you all cringe I’m sure, so I’ll forgo the details unless someone’s interested 
5 Likes
This is very cool! Would be nice to make it usable from OCaml too, for example, adding it to OPAM.
Thanks! Putting all of this on opam is actually on the roadmap. The biggest blocker right now is putting the build system we’re using called bsb-native. It’s just a matter of time allocation at this point
Shouldn’t be hard to add a quick jbuilder building option to Reprocessing. Probably will be much easier than adding bsb-native, since if I recall correctly, that’s a fork of the OCaml compiler.
1 Like