Last week, on a whim, I gave Claude Code (CC) a task that turned out to be both possible and highly useful, because it removed a common annoyance for some colleagues and myself.

See, there is this C-library called CPL that ESO uses for processing of astronomical data. There also is a Python-wrapper for it, pycpl, that allows to use the library from Python, which is great because it's the language that astronomers and data scientists mostly use nowadays.

However, pycpl does not come with CPL, but instead requires it to be installed beforehand, which often implies compiling it oneself because not all operating systems package the right version, if at all. This is not a big hurdle for developers, but if one wants to share a half-finished pipeline with some prospective users, it easily becomes one. Containers and such can help with this but are always a crutch that I would rather avoid.

Claude to the rescue. The off-handed remark in a telecon, that we should just make a pycpl package that comes with CPL (and its dependency libs) included, took hold with me long enough to ask CC to just do it!

I started by downloading the latest CPL source code, and the three libs it needs. Then I asked CC to initialize the git repository and sort out which files to add and which to ignore.

After pushing to Github, I could switch to the online version of CC where I had free credits to burn, so no harm done if this endeavour would turn into failure. Then I just quickly told it what to do like this, typos and all:

pycpl is a python wrapper for C-lib CPL. But it is packaged without the C-lib, so the overall goal is to upgrade the pycpl package to include the build of CPL and its depencencies (which are also present here). start by looking at the build system of pycpl and how to include the other lobraries to it. then move the libs to appropriate places inside pycpl and try the build.

This session log and this follow-up basically show how CC figured it all out. I only skimmed through it at the time and could not tell you what exactly it did. At some point I realized it needed some of the files that were omitted earlier, so I added those back. In the end, I had a package that installed locally -- a success already.

But what would make this really useful would be a Python "wheel", i.e. a package bundle that is pre-compiled for different platforms and Python version. This way, users would be able to install instantly, without any compiling happening at all. So I naturally asked CC about it, and how to set it up such that GitHub Actions do the compiling. This was the most tedious bit. CC needed many iterations to get this right and compiling on GitHub is not fast. So I let it work in the background over an evening, only checking in occasionally. Claude figured it out in the end! The package installs and works nicely for myself and several colleagues.

Initially, the plan was to also upload to PyPI, because ESO does not actually do that. But I was not able to put claim to the name "pycpl" there, and without that it would not work. Plus I did not want to step on people's toes too much by publishing work that is not my own. Even though, in principle, it should be fine with GPL-licensed code.

Thus, for now, one has to provide an "extra index URL" to install this pycpl package. Use uv, for example like this:

    (uv) pip install pycpl --extra-index-url https://ivh.github.io/pycpl/simple/

Or try if it works without having anything prepared:

    uv run --with pycpl --extra-index-url https://ivh.github.io/pycpl/simple/ python -c "import cpl;"

Or add it to the header of a script file like this:

    uv add --script main.py --index https://ivh.github.io/pycpl/simple/  pycpl

One can also add the index URL to one's pyproject.toml, together with ESO index URL that provides tools like pyesorex and edps, which seem to play nicely with my pycpl instead of ESO's own. For how to do that, see the README in the GitHub repo.

I've been using Claude Code (CC) quite extensively in recent weeks, and apart from a few fails it's been a blast. I want to write about a few of the things I got it to do successfully, but in order to do that I need to be able to share the session logs.

Unfortunately, there is no straight-forward way to do this. The logs are saved as .jsonl files in $HOME/.claude/projects/-path-to-your-work-directory/ and when using the online version of CC, all one to do is use the Open in CLI button and continue locally, then the .jsonl with the whole session will show up in the project folder.

These file are a bit unweildy. For example, they contain the whole content of files that CC reads and a buch of distracting metadata. I tried Simon Willison's claude_to_markdown.py but that was not quite what I wanted, which is a static HTML file with embedded JavaScript (JS) to hide the long reads and outputs by default, but make them expandable if needed.

What better way to achieve this than just let CC do it? Very meta, I know. So I donwloaded the JS from https://claude.ai/code/ (after all, they have solved the same task there already) and put it into a fresh repo with an example session log. This is the outline I wrote and added to the repo:

# main goal
a script, python or other, that takes session logs from Claude Code (CC)
and converts them into HTML.

## example data
- a06171f9-5f33-4258-84e1-4dc70e84c6dd.jsonl an example session log. all
  input files will have this format.
- Screenshot, two example screenshots of how it looks on CC web.
- CCweb_example.html and CCweb_example_files/ , the saved web page of CC
  that should contain useful routines to render the session. Ignore the 
  left half of the page and session management, only the session part 
  itself is needed.

## requirements
- the output should be a single html-file, named like the input but ending
  .jsonl exchanged to .html
- all javascript should be inlined.
- the script does not need to be self-contained, can e.g. read js files or
  templates to make the output.
- the html should look similar to the screenshots, i.e. compact with 
  unnecessary information skipped, file reads hiden, and long diffs
  shortened but expandable.

Then all that was let do do was to point CC to the repository and tell it to get crackin'.

This is how it went.

I wasn't a perfect one-shot success, as you can see. But with just a little prodding CC figured it out. I then continued in a new short session to have it sum up the elapsed working time and put that on top of the HTML. Not bad at all, I would say. Feel free to check it out on gitHub.

Quoting Patrick Boyle:

For AI users, this frenzy is a gift. Competition has meant that the models improve rapidly and their prices stay low. There is no reason not to use these products while they are free or almost free.

I fully agree and get lots of value from my 20$ Claude subscription, mostly via ClaudeCode. More on that later, but I am happy to take investors' money by buying a product that is sold under break-even price. May it last as long as possible. But to continue the quote:

For AI investors, the economics are unforgiving. Better chips make models faster—and make yesterday’s chips worthless. Every leap forward accelerates depreciation on the collateral lenders are asked to finance. That is why banks refuse to lend, they prefer assets that last longer than a news cycle.

A quick follow-up on the previous post, here are a few links to satisfy your thirst for more input about AI and related topics.

MIRI's blog seems to do a good job at collecting updates.

This recent conference has put up PDFs of several presentations.

Eliezer Yudkowsky is on Facebook and Twitter, so is Demis Hassabis from DeepMind.

I also got Kurzweil's famous book The Singularity Is Near and will read it soon. Other's have convinced me that his thinking probably is way too optimistic, in the sense that while his predictions may be possible, they are not the default outcome. But it is certainly a worthwhile read anyway.

The Second Machine Age by Erik Brynjolfsson and Andrew McAfee made it onto my reading list as well.

The Foom debate is often referred to. I however cannot understand how some claim that Hanson "won" with his arguments against a fast take-off.

Nick Bostrom's latest paper is here (PDF) and his recent talk Safety Issues in Advanced AI is basically an updated version of his "classic" talk at Google.

Also very much worth to watch is Demis Hassabis - The Future of Artificial Intelligence.

Oh, and if you don't know Yudkowsky's short Three Worlds Collide yet, go and read it - it's deep and funny!

What strikes me in of all this is how young the whole field is. Even five or ten years ago, the main concepts and jargon that seem to make quite a bit of sense once you get them explained to you, were not in place at all.

I've recently been reading Nick Bostrom's book Superintelligence and must admit it stuck with me. It may well seem a tad abstract to us who are new to thinking about such matters, but highly stimulating and thought-provoking.

The main point is driven home thoroughly: We should be talking more about artificial intelligence! Because its arrival might be just around the corner and it has the potential to mark a crossroads for our future, the choices being really really bad or really really fantastically good.

If you havn't read them yet, these two blog posts by Wait But Why are probably the best introdution: Part 1, Part 2.

I am currently half-way through Olle Häggström's Here Be Dragons which covers related but broader toptics of near-future technologies.