anil.recoil.org
+23
dra/blog_platform_2025_07_18_through-a-glass-darkly.json
+23
dra/blog_platform_2025_07_18_through-a-glass-darkly.json
···
···+"summary": "Earlier this year, I returned to the Computer Laboratory at the University of Cambridge, as part of the Energy and Environment Group, combining with my work at Tarides. It\u2019s been something of a whirlwind, which doesn\u2019t look like it\u2019ll be abating just yet, but there\u2019s still been the odd chance to consider where things are and where we might be headed. I\u2019m minded of a scene from an opera I performed a few years ago in Hannover. In the second act of Henrico Leone (\ud83e\udd81, rather than \ud83d\udc2b, but hey), Henrico\u2019s wife, Metilda, in a vision sees her husband defeated in battle:",+"content": "<p>Earlier this year, I returned to the <a href=\"https://www.cst.cam.ac.uk\">Computer Laboratory</a>\nat the <a href=\"https://www.cam.ac.uk\">University of Cambridge</a>, as part of the\n<a href=\"https://www.cst.cam.ac.uk/research/eeg\">Energy and Environment Group</a>,\ncombining with my work at <a href=\"https://www.tarides.com\">Tarides</a>. It\u2019s been\nsomething of a whirlwind, which doesn\u2019t look like it\u2019ll be abating just yet, but\nthere\u2019s still been the odd chance to consider where things are and where we\nmight be headed. I\u2019m minded of a scene from an opera I performed a few years ago\nin Hannover. In the second act of <em>Henrico Leone</em> (\ud83e\udd81, rather than \ud83d\udc2b, but hey),\nHenrico\u2019s wife, Metilda, in a vision sees her husband defeated in battle:</p>\n\n<div>\n\n \n Your browser does not support the audio tag.\n\n</div>\n\n<p><em>Morir\u00f2 fra strazi e scempi e dirassi, ingiusti dei, che salvando i vostri\ntempli io per voi tutto perdei.</em></p>\n\n<p>Dying, Henrico manages one last scream (almost literally in the opera; the role\nis portrayed by an alto castrato), declaring, \u201cI will die amidst torment and\ndestruction and it will be said, unjust gods, that in saving your temples I lost\neverything for you.\u201d. Agentic coding and the end of the programmer?\n<a href=\"https://oxcaml.org\">OxCaml</a> and the end of OCaml? <a href=\"https://github.com/dra27\">@dra27</a>\nswitching from Windows to macOS? Fortunately, the vision is, as visions often\nare, a Mirage. Henrico, luckily for a three act opera, has not been killed in\nAct II (he survived a shipwreck at the beginning of the opera, so he \u2013 along\nwith the metaphor \u2013 is doing quite well!). My feeling, set down in 2025 ready\nfor me to laugh at, um, later in 2025 (or hopefully a few years down the line),\nis that we\u2019ll still be here for some time to come; programming in OCaml.</p>\n\n<p>For me, the challenges and requirements on the ecosystem presented by our new AI\ntooling seem very little different from the challenges and requirements we had\nbefore. I\u2019ve often (and not entirely originally) remarked that Windows doesn\u2019t\nusually throw up portability problems, it\u2019s more that it shines a light and\nexaggerates unfortunate parts of a system\u2019s design (expecting to keep databases\nin gazillions of flat files, assuming there\u2019s only one directory separator\ncharacter, assuming there\u2019s one root file system, etc., etc.). So too the needs\nof LLMs shine a light on our stateful packaging systems (which we already knew\nwere too stateful), on the pain of package-to-library-to-module namespacing, on\nthe need for aggressive caching of previous build results to be able to explore\na search space. Looking at stats from <a href=\"https://octoverse.github.com/2022/top-programming-languages\">2022</a>\n(the <a href=\"https://github.blog/news-insights/octoverse/octoverse-2024/\">2024</a> report\ndoesn\u2019t appear to contain an updated statistic), one can glean that most of\nGitHub\u2019s 420+ million repositories are written in around 500 different\nprogramming languages. My entirely ill-educated guess is that there\u2019s not going\nto be the breadth of either existing material (for training) or even need to\ngive your favourite agent the ability to synthesise the programming language as\nwell as the program any time soon!</p>\n\n<p>I\u2019m excited to see what\u2019s happening and going to be happening with OxCaml. There\nare several great features which have already made it from Jane Street over to\nOCaml, and I fully expect the next few releases of OCaml to be reminiscent of\nOCaml 4.10+, as Multicore OCaml features started to migrate over to mainline\nOCaml. Also reminiscent of Multicore OCaml are things like missing Windows\nsupport! Plus \u00e7a change, plus c\u2019est la m\u00eame chose, I guess, but then <a href=\"https://github.com/ocaml/ocaml/pull/9927\">keeping</a>\n<a href=\"https://github.com/ocaml-multicore/ocaml-multicore/pull/351\">these</a>\n<a href=\"https://github.com/ocaml/ocaml/pull/11642\">things</a> <a href=\"https://github.com/ocaml/ocaml/pull/12954\">going</a>\n<a href=\"https://github.com/ocaml/ocaml/pulls?q=is%3Apr+author%3Adra27+fix+in%3Atitle+is%3Aclosed\">is</a>\n<a href=\"https://github.com/ocaml/opam/pulls?q=is%3Apr+is%3Aclosed+author%3Adra27+in%3Atitle+fix\">very</a>\n<a href=\"https://github.com/ocaml/flexdll/pulls?q=is%3Apr+is%3Aclosed+author%3Adra27+in%3Atitle+fix\">much</a>\n<a href=\"https://github.com/ocaml/ocaml/pull/14014\">what</a> <a href=\"https://github.com/dra27/ocaml/pulls?q=is%3Apr+is%3Aopen+label%3Arelocatable\">drives</a>\n<a href=\"https://github.com/dra27\">me</a>. For better or worse, I don\u2019t really seem to change\n(although I do occasionally use macOS \ud83d\ude01)</p>\n\n<p>I have always regarded my working life as divided between my work as a singer in\nthe performing arts and my work as an engineer/scientist in technology. More\nrecently, perhaps with a middle-aged tendency to muse, I see the common thread\n<em>in me</em> between the two and conclude that, despite my best efforts as a geeky\nchild, I act more artistically than scientifically. Performing is deeply\npersonal. It is also a service for an audience and one\u2019s skill, one\u2019s expertise,\none\u2019s talent is poured into the perfecting of that performance in the service of\nits audience. For me, everything leading up to it (learning, practice,\nrehearsal, etc.) is profoundly irrelevant next to the artefact of the\nperformance itself and the sole purpose of that preparatory work (however\nsatisfying and enjoyable!) is the perfecting of that artefact for that service\nof performance. My personal realisation is that this idea of service has always\nunderpinned my drive in technology as well. From my very earliest days dabbling\nwith setting up school computer networks, from the first software systems I\nprogrammed, the work was fascinating and the challenges stimulating, but it was\nand is driven by the pursuit of the perfect, or right, system in the service of\nits users.</p>\n\n<p>But what of the art itself? Standing in my office now, with computers both in\nfront and behind me, beside me are shelves of scores and piles of other music. I\ncan\u2019t easily count the number of times I have performed the major works of Bach\nand Handel over the last two decades, but at each repeat performance, I strive\nto achieve a closer perfection of that art from the one which preceded it -\nserving both the audience <em>and</em> the art. And here I find the service of the\nart-<em>e-fact</em> - the maintenance of that which one has written or which one has\ndone. I don\u2019t abandon that which I haven\u2019t yet perfected and which still has an\naudience.</p>\n\n<p>Perhaps it is this service of the art in the service of others which has driven\nand continues to drive my desire to improve our small corner of the world of\ntechnology, rather than necessarily to produce other things with it. Although it\nreally is nice to get to do that occasionally, too. Which in a meandering sort\nof a way is where the last year, and in particular this last 3-4 months, have\nbeen. Relocatable OCaml was an idea formulated over a few hours of thinking and\nwriting in 2019, and in fact originally conceived during a rehearsal. Showing\nthat it was a technically viable idea was done over a few weeks of hacking\nin 2021. Getting it to a stable state such that it could be demonstrated across\nthe three major platforms on all current releases of OCaml was done over a few\nmonths of feverish work in 2022. You can possibly see where this is going:\ngetting it to an upstreamable state where it can be maintained for the future\nhas taken the next order of magnitude in time, it would appear!</p>\n\n<p>I\u2019ve already written in some detail <a href=\"https://github.com/dra27/RFCs/blob/relocatable/rfcs/relocatable.md\">what it\u2019s supposed to do</a>.\nWhy it matters seems to touch so many areas for so many users. With Relocatable\nOCaml, opam switches can be created to your heart\u2019s content, wasting neither CPU\ntime and energy to build the same compiler again, nor disk space to store it,\nand without having to wait until we can morph the entire ecosystem to another\ndifferent way of doing things instead. Likewise, in Dune, the compiler can\nfinally be treated as any other package and cached between projects. Engineers\nworking on the compiler itself can now drop in a replacement development\ncompiler into an opam switch without having to curse and rebuild it with the\ncorrect prefix for that switch. For users, it Just Works\u2122, and hopefully in a\nfew years\u2019 time newcomers will wonder how it could ever not always have been\nthat way.</p>\n\n<p>When the curtain comes down on this performance, hopefully all its users will\napplaud through some measure of decreased grumpiness and increased productivity.\nHopefully the coffee market will not be too impacted by the lack of\n<code>opam switch create</code>-induced breaks. Hopefully the distance to perfection will\nbe a little smaller.</p>\n\n<p>And I\u2019ll look to the next performance. We aren\u2019t done yet.</p>",
+2
-2
ibrahim/alhasacademy.github.io_.json
+2
-2
ibrahim/alhasacademy.github.io_.json
···-"summary": "<p><strong>Research Software Engineering at Cambridge Zoology</strong></p>\n \n <div>\n <h4>TL;DR</h4>\n <p>Started new role as Research Software Engineer at Cambridge Zoology Department. Successfully transitioned from LCFI and began integrating with the interdisciplinary team at Conservation Evidence.</p>\n </div>\n \n <p>This week marked the beginning of my role as Research Software Engineer (the first and only one!) at the University of Cambridge's Department of Zoology. The transition from LCFI has been smooth, and I'm excited to work on new research projects that combine my software engineering expertise with real-world research problems.</p>\n \n <h3>The Team and the Project</h3>\n <p>The Conservation Evidence team, based in the University of Cambridge's Department of Zoology, maintains a free, open-access platform that trawls global scientific and grey literature to collate and summarise the results of conservation interventions. It distils these findings into plain-language \"synopses\" for specific species groups or habitats, then convenes expert panels to score each action's effectiveness in the definitive What Works in Conservation handbook. Alongside this synthesis work, the team publishes the peer-reviewed Conservation Evidence Journal so practitioners can share new case studies, and it collaborates with NGOs, businesses and policymakers to embed evidence-based decision-support tools in real-world planning. Their overarching goal is to give conservationists rapid, unbiased access to the best available evidence so scarce resources are channelled into actions that demonstrably benefit biodiversity.</p>",-"content": "<p><strong>Research Software Engineering at Cambridge Zoology</strong></p>\n \n <div>\n <h4>TL;DR</h4>\n <p>Started new role as Research Software Engineer at Cambridge Zoology Department. Successfully transitioned from LCFI and began integrating with the interdisciplinary team at Conservation Evidence.</p>\n </div>\n \n <p>This week marked the beginning of my role as Research Software Engineer (the first and only one!) at the University of Cambridge's Department of Zoology. The transition from LCFI has been smooth, and I'm excited to work on new research projects that combine my software engineering expertise with real-world research problems.</p>\n \n <h3>The Team and the Project</h3>\n <p>The Conservation Evidence team, based in the University of Cambridge's Department of Zoology, maintains a free, open-access platform that trawls global scientific and grey literature to collate and summarise the results of conservation interventions. It distils these findings into plain-language \"synopses\" for specific species groups or habitats, then convenes expert panels to score each action's effectiveness in the definitive What Works in Conservation handbook. Alongside this synthesis work, the team publishes the peer-reviewed Conservation Evidence Journal so practitioners can share new case studies, and it collaborates with NGOs, businesses and policymakers to embed evidence-based decision-support tools in real-world planning. Their overarching goal is to give conservationists rapid, unbiased access to the best available evidence so scarce resources are channelled into actions that demonstrably benefit biodiversity.</p>",
···+"summary": "<div>\n \n\n <span>Research Software Engineering at Cambridge Zoology</span>\n \n\n </div>\n \n <p>This week marked the beginning of my role as Research Software Engineer (the first and only one!) at the University of Cambridge's Department of Zoology. The transition from LCFI has been smooth, and I'm excited to work on new research projects that combine my software engineering expertise with real-world research problems.</p>\n \n <h3>The Team and the Project</h3>\n <p>The Conservation Evidence team, based in the University of Cambridge's Department of Zoology, maintains a free, open-access platform that trawls global scientific and grey literature to collate and summarise the results of conservation interventions. It distils these findings into plain-language \"synopses\" for specific species groups or habitats, then convenes expert panels to score each action's effectiveness in the definitive What Works in Conservation handbook. Alongside this synthesis work, the team publishes the peer-reviewed Conservation Evidence Journal so practitioners can share new case studies, and it collaborates with NGOs, businesses and policymakers to embed evidence-based decision-support tools in real-world planning. Their overarching goal is to give conservationists rapid, unbiased access to the best available evidence so scarce resources are channelled into actions that demonstrably benefit biodiversity.</p>",+"content": "<div>\n \n\n <span>Research Software Engineering at Cambridge Zoology</span>\n \n\n </div>\n \n <p>This week marked the beginning of my role as Research Software Engineer (the first and only one!) at the University of Cambridge's Department of Zoology. The transition from LCFI has been smooth, and I'm excited to work on new research projects that combine my software engineering expertise with real-world research problems.</p>\n \n <h3>The Team and the Project</h3>\n <p>The Conservation Evidence team, based in the University of Cambridge's Department of Zoology, maintains a free, open-access platform that trawls global scientific and grey literature to collate and summarise the results of conservation interventions. It distils these findings into plain-language \"synopses\" for specific species groups or habitats, then convenes expert panels to score each action's effectiveness in the definitive What Works in Conservation handbook. Alongside this synthesis work, the team publishes the peer-reviewed Conservation Evidence Journal so practitioners can share new case studies, and it collaborates with NGOs, businesses and policymakers to embed evidence-based decision-support tools in real-world planning. Their overarching goal is to give conservationists rapid, unbiased access to the best available evidence so scarce resources are channelled into actions that demonstrably benefit biodiversity.</p>",
+8
-8
index.json
+8
-8
index.json
············
············
+17
jon/blog_2025_07_odoc-3-live-on-ocaml-org.html.json
+17
jon/blog_2025_07_odoc-3-live-on-ocaml-org.html.json
···
···+"content": "<h1><a href=\"#odoc-3-is-live-on-ocaml.org!\"></a>Odoc 3 is live on OCaml.org!</h1><ul><li><span>published</span> <p>2025-07-14</p></li></ul><p>As of today, Odoc 3 is now live on OCaml.org! This is a major update to odoc, and has brought a whole host of new features and improvements to the documentation pages.</p><p>Some of the highlights include:</p><ul><li>Source code rendering</li><li>Hierarchical manual pages</li><li>Image, video and audio support</li><li>Separation of API docs by library</li></ul><p>A huge amount of work went into the <a href=\"https://discuss.ocaml.org/t/ann-odoc-3-0-released/16339\">Odoc 3.0 release</a>, and I'd like to thank my colleagues at Tarides, in particular <a href=\"https://github.com/panglesd\">Paul-Elliot</a> and <a href=\"https://github.com/julow/\">Jules</a> for the work they put into this.</p><p>But the odoc release happened months ago, so why is it only going live now? So, the doc tool itself is only one small part of getting the docs onto ocaml.org. Odoc works on the <a href=\"https://discuss.ocaml.org/t/cmt-cmti-question/5308\">cmt and cmti</a> files that are produced during the build process, and so part of the process of building docs is to build the packages, so we have to, at minimum, attempt to build all 17,000 or so distinct versions of the packages in opam-repository. The <a href=\"https://github.com/ocurrent\">ocurrent</a> tool <a href=\"https://github.com/ocurrent/ocaml-docs-ci\">ocaml-docs-ci</a>, which I've previously <a href=\"../05/docs-progress.html\" title=\"docs-progress\">written</a> <a href=\"../04/ocaml-docs-ci-and-odoc-3.html\" title=\"ocaml-docs-ci-and-odoc-3\">about</a>, is responsible for these builds and in this new release has demonstrated a new approach to this task, where we attempt to do the build in as efficient a way as possible by effectively building binary packages once for each required package in a specific 'universe' of dependencies. For example, many packages require e.g. <a href=\"https://erratique.ch/software/cmdliner\">cmdliner.1.3.0</a> to build, and some require a specific version of OCaml too. So we'll build cmdliner.1.3.0 once against each version of OCaml required -- but <i>only once</i>, which is in contrast to how some of the other tools in the ocurrent suite work, e.g. <a href=\"https://github.com/ocurrent/opam-repo-ci\">opam-repo-ci</a>. Once the packages are built, we then run the new tool <a href=\"https://ocaml.github.io/odoc/odoc-driver/index.html\">odoc_driver</a> to actually build the HTML docs. In addition to this, a new feature of Odoc 3 is to be able to link to packages that are your direct dependencies - so for example, the docs of odoc contain links to the docs of odoc_driver, even though odoc_driver depends upon odoc. This, whilst sounding easy enough, required some radical changes in the docs ci, which I promise I will write about later!</p><p>The builds and the generation of the docs is all done on a single blade server, called <a href=\"https://sage.caelum.ci.dev\">sage</a> with 40 threads, 2 8TiB spinning drives and a 1.8TiB SSD cache, and it produces about 1 TiB of data over the course of a couple of days. The changes required to this part of the process since odoc 2.x were primarily myself and <a href=\"https://tunbury.org\">Mark Elvers</a></p><p>Once the docs are built, how do they get onto ocaml.org? Odoc itself knows nothing about the layout and styling of ocaml.org, so the HTML it produces isn't suitable to be just rendered when a user requests particular docs. What happens is that odoc produces, as well as a self-contained HTML file, a json file with the body of the page, the sidebars, the breadcrumbs and so on as structured data, one per HTML page, which are then served from sage over HTTP. When a user requests a particular docs page, the ocaml.org server will request that json file from sage, then render this with the ocaml.org styling, then send it back to the user.</p><p>As odoc 3 moved a fair bit of logic from ocaml.org into odoc itself, there were quite a few changes that needed to be made to the ocaml.org server to integrate this into the site. This work was mostly done by <a href=\"https://github.com/panglesd\">Paul-Elliot</a> and myself, with a lot of help from the <a href=\"https://github.com/ocaml/ocaml.org?tab=readme-ov-file#maintainers\">ocaml.org team</a>, in particular <a href=\"\">Sabine Schmaltz</a> and <a href=\"https://github.com/cuihtlauac\">Cuihtlauac Alvarado</a>.</p><p>So, quite a lot of integration and infrastructure work was required to get the new docs site up and running, and I'm very happy to see this particular task concluded!</p><p>Continue reading <a href=\"https://jon.recoil.org/blog/2025/07/odoc-3-live-on-ocaml-org.html\">here</a></p>",
+17
jon/blog_2025_07_retrospective.html.json
+17
jon/blog_2025_07_retrospective.html.json
···
···+"content": "<h1><a href=\"#4-months-in,-a-retrospective\"></a>4 months in, a retrospective</h1><ul><li><span>published</span> <p>2025-07-18</p></li></ul><p>Astonishingly, it's already been <i>four whole months</i> since starting back at the university, which I find incredibly hard to believe. I'm utterly convinced that it was only a couple of weeks ago that I walked back into the Computer Laboratory as an SRA for the first time since 2021, but here we are, at the end of term already. Time to do a bit of a retrospective and forward-looking plan for the next 3-4 months!</p><p>Continue reading <a href=\"https://jon.recoil.org/blog/2025/07/retrospective.html\">here</a></p>",
+6
-6
links.json
+6
-6
links.json
·········
·········
+19
mte/2025_07_18_docker-oxcaml.json
+19
mte/2025_07_18_docker-oxcaml.json
···
···+"summary": "Jon asked me to make a Docker image that contains OxCaml ready to run without the need to build it from scratch.",+"content": "<p>Jon asked me to make a Docker image that contains <a href=\"https://oxcaml.org\">OxCaml</a> ready to run without the need to build it from scratch.</p>\n\n<p>I have written a simple OCurrent pipeline to periodically poll <a href=\"https://github.com/oxcaml/opam-repository\">oxcaml/opam-repository</a>. If the SHA has changed, it builds a Docker image and pushes it to current/opam-staging:oxcaml.</p>\n\n<p>The resulting image can be run like this:</p>\n\n<div><div><pre><code><span>$ </span>docker run <span>--rm</span> <span>-it</span> ocurrent/opam-staging:oxcaml\nubuntu@146eab4efc18:/<span>$ </span>ocaml\nOCaml version 5.2.0+ox\nEnter\n<span>#help;; for help.</span>\n\n<span>#</span>\n</code></pre></div></div>\n\n<p>The exact content of the image may change depending upon requirements, and we should also pick a better place to put it rather than ocurrent/opam-staging!</p>\n\n<p>The pipeline code is available here <a href=\"https://github.com/mtelvers/docker-oxcaml\">mtelvers/docker-oxcaml</a> and the service is deployed at <a href=\"https://oxcaml.image.ci.dev\">oxcaml.image.ci.dev</a>.</p>",