Free software activity in August 2024

Free software activity in July 2024

Free software activity in June 2024

Free software activity in May 2024

Convert playing-with-rich to rST

Add m.code and pygments-default.css

CSS generated using:

  pygmentize -f html -S default -a .m-code >static/pygments-default.css

This will only work with posts that have been converted to
reStructuredText.

Merge commit '523506668a61646603ed299e1b60b7f77a8ebd77'

Playing with rich

Improve layout of Markdown-generated code blocks

Free software activity in April 2024

Add Liberapay link

Free software activity in March 2024

Tweak title to avoid invalid HTML formatting

"Install everything" in Ubuntu?

Avoid typogrify generating invalid markup

FLOSS activity in January/February 2024

latex2svg: restrict the libgs workaround to dvisvgm < 3.0.

On newer versions this isn't needed, and the hardcoded paths aren't
always enough. So better to just not try at all.

Task management

OpenUK New Year's Honours

Going freelance

Move a video from people.canonical.com/~cjwatson/

Move some images from people.canonical.com/~cjwatson/

Add images referenced by content/lp-python3.md

css: support .m-image and .m-figure for <video> as well.

latex2svg: look for libgs.so.10 in /usr/lib64 as well.

Update copyright year.

Six months in, I could have waited until 2024, heh.

Stop mentioning Pelican -- it's a general site theme independent of it.

doc: properly show that a class directive *is* needed for a table.

The output markup had it but the snippet not, causing confusion.

m.code: make it work with newer docutils.

Not sure when this got broken but omitting the option no longer works.

documentation/python: test external doc overload matching with * and /.

With the previous commit this now "just works", as the placeholders are
dropped from the final signature. The test thus works mainly for
documenting this feature.

documentation/python: recognize / and * in pybind11 signatures.

documentation/python: ignore a new useless builtin on 3.11.

documentation/python: don't use deprecated distutils.

Turns out the version info can be compared much more easily. Thanks
Python, this is nice.

latex2svg: work around dvisvgm < 3.0 not detecting ghostscript 10.

The latex stack and everything around it is ... interesting. A huge pile
of stuff that randomly breaks in very silent and non-obvious ways, and
it's all so huge and complicated that even distro package maintainers
have no way to know if the packages are mutually compatible.

Now that I figured this out, I still need to comment on that ArchLinux
bug.

latex2svg: more robust handling of libgs not being found.

Instead of just looking it up upfront and then hoping for the best,
verify also that dvisvgm actually detected and used it. Because it not
always does, in particular with versions < 3.0 and ghostscript 10.

m.code: minor.

css: reduce size of the jumbo header.

The previous size was unbearable with longer titles such as in
https://blog.magnum.graphics/backstage/cpu-feature-detection-dispatch/

doc: update command line for Pygments CSS generation.

m.code: support inverse video in the ANSI lexer.

I'm very glad for the extremely extensive code coverage here. Without
it, I'd break half of other stuff by accident.

m.code,doxygen: test inline ANSI code highlighting.

Because it got broken with Pygments newer than the ancient 2.6.1 fork I
have (it now unconditionally adds a wrapper <div>), and unfortunately I
can't see how to not do that in 2.14 without delegating into private
APIs.

So just to have that problematic part reproduced in tests, once I get to
that. Unfortunately latest Pelican doesn't work with older Pygments
anymore for some reason (or, well, disallows it), so I can't generate
the website until I have this fixed properly. Ugh.

package/ci: the eternal trash fire of random packages breaking!!

I have no patience for any of this.

documentation/python: test using :property: in a class docstring.

It works, I just wasn't sure if there wasn't something special regarding
docstrings so I had to check explicitly.

documentation/doxygen: support styling <dl> with CSS classes.

So I can make my own footnotes. Finally I got to know what kind of
markup is abused for the autogenerated TODO lists.

css: document that a <table> can be .m-fullwidth.

I kinda forgot all the particulars since I made this five years ago, so
better document everything for my old soul.

Link to reproducible-builds.org

Use pelican --listen instead of python -m pelican.server

Reproducible man-db databases

Fix deprecated %s usage in *_FEED_ATOM

package/ci: I HATE WEB DEVELOPMENT

All packages getting changed all the time with stupid differences. IT IS
NOT POSSIBLE TO JUST HAVE A PROJECT WORKING FOR SIX MONTHS WITHOUT A
CONSTANT NEED FOR ADAPTING TO CHANGES IN DEPENDECIES FFS!!!

I miss developing against Qt, where the APIs I used in 2007 were still
there in 2014. ARGH

Updated CREDITS.md.

fix typos in m-components.css

m.code: fix ANSI lexer compatibility with Pygments 2.12+.

I'm still pinned on an older version because of the significant
difference in output, but it shoulnd't crash at least.

m.dox: document a rather nasty abuse of lack of python variable scoping.

m.dox: restore compatibility with cppreference tag files.

These put the filename into a different tag, and don't use anchors.

m.dox: test & fix linking to files, defines and macros.

The tagfile has an absolute path for some reason, but not going to
bother with that right now. The code was also appending one extra .html
extension, which is fixed.

m.dox: allow linking to variables as well.

I have *many* tags now, and need to be able to refer to them.

m.dox: properly test also links to typedefs, enums and enum values.

Instea of updating the Corrade tagfile, which would be several megabytes
of useless data, I'm now cherry-picking just what's changed.

Will make updates slightly harder but not impossible (can't just replace
the whole file but have to cherry-pick again). OTOH I can now use the
same approach for STL-tagfile-specific workarounds instead of bundling
another 2 MB of XML data.

Use two-space indentation for Doxygen tagfiles.

Updated CREDITS.rst.

documentation/doxygen: explanatory comments for parts without CI coverage.

Also restoring the note about the cpp_function_attributes regression
test.

doxygen: fix keywords leaking into return type

- fixes #225
- fixes #226

Also drive-by added support for C++20's `consteval` keyword.

Fix documentation typos

Updated CREDITS.rst.

documentation: Use https links instead of git links.

GitHub no longer supports git:// links. Trying to
following the clone instructions leads to an error:
>  The unauthenticated git protocol on port 9418 is no longer supported.
> Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.

documentation/doxygen: don't omit functions w/o brief from file docs.

Before, functions that contained for example /** \overload */ were
omitted from file docs, leading to user confusion.

And document the behavior more thoroughly -- took me a while to realize
this condition was really responsible for this.

documentation: it's Doxyfile.xml I shall ignore, not Doxyfile.html.

Made an error in 45911a18 and apparently it was fine because it silently
returned in some later check.

Launchpad now supports SSH Ed25519 keys and RSA SHA-2 signatures

Jabber? What's that?

Updated CREDITS.rst.

Fix various typos

Found via `codespell -q 3 -L nd,te`

Co-authored-by: Vladimír Vondruš <mosra@centrum.cz>

documentation/doxygen: don't trip up on WEIRD macros parsed as functions.

documentation/doxygen: the xrefim order change was just "temporary".

Followup to 4ec09a2c97f60c2c673de337d7dabdc198592f4a. A temporary
regression from 1.8.18 to 1.8.20, 1.9.0 is back to what 1.8.17 had. Heh.
Heh.

documentation/doxygen: silly block-separating workaround for Doxygen 1.9.

Now the new test_contents.Blockquote test passes fully.

documentation/doxygen: drop STUPID &zwj; in <blockquote>.

What the hell, such a pile of unnecessary work. FFS.

documentation/doxygen: fix Doxygen 1.9 code-after-blockquote bugs.

Before it was wrapped in a dedicated paragraph, now it's not anymore.
Thus, if a <programlisting> is right after a <blockquote> and there's
nothing else after it until the end of <para>, it should be treated as a
code block again.

documentation/doxygen: dedicated test for Doxygen 1.9 blockquote bugs.

And removing the problematic interaction from the general typography
test -- it's now here instead.

documentation/doxygen: adapt to different \dotfile handling in 1.9.3.

documentation/doxygen: don't add a space between <p> and <code>.

Seems obvious in retrospect, but for some reason I never realized.

documentation/doxygen: fix another void \return docs warning with 1.9.

Followup to 568edda0b4c2f4ff53652a28aa27a89cb54c2aac.

Updated CREDITS.md.

latex2svgextra: adapt to minor changes in dvisvgm 2.12 preamble.

And add an actually useful assert message.

Co-authored-by: Vladimír Vondruš <mosra@centrum.cz>

documentation/doxygen: add a clarifying note to the test Doxyfile.

documentation/doxygen: repro case & fix for a blockquote in brief.

Amazing. Such a *tiny* piece of functionality with a clear goal,
providing a single-line brief with no block elements. And yet this is
like the 50th bug I came across, so far.

Revert "documentation/doxygen: drop handling for a Doxygen 1.8.15 bug."

Turns out it's not really A Thing Of The Past yet -- the assertion is
firing for different cases and the message of it is utterly confusing.
Repro case for the others in the following commit.

This reverts commit 6bea7027cb2674e4c5f78a527ddab506d9785675.

documentation/doxygen: fix a friend class being parsed as a function.

Doxygen 1.9 no longer contains a "friend" prefix in the <type>, causing
some conditions to trip up and some asserts to trip up even worse after
that.

Co-authored-by: Vladimír Vondruš <mosra@centrum.cz>

documentation/doxygen: silence a warning.

Hopefully this wasn't omitted there for some testing purpose.

documentation/doxygen: ah so that's why the warning is uncovered.

Because 1.8.16+ just directly drops the whole <dotfile> tag if the
source doesn't exist. What a marvellous idea!!!

documentation/doxygen: fix Doxygen warning.

Funnily enough this doesn't make the multiline brief bug go away. So
what's even the point of checking those, Doxygen?!

documentation/doxygen: explicitly check for warning logs.

The output was quite a mess already, and that's just because I didn't
know about assertLogs() until now.

documentation/doxygen: Doxygen 1.9.3 warns about \return for void.

And quite intensely. Don't do that, then.

documentation/doxygen: since 1.9.2, HAVE_DOT has to be explicitly set.

Kinda silly to require that even for the XML output, where Graphviz
doesn't actually need to be used at all -- the content/files are pasted
verbatim.

documentation/doxygen: robustly skip unexpected XML files.

This skips the Doxyfile.xml from 1.8.19 (without a warning, to avoid
polluting the output for everyone running newer Doxygen), and
additionally also all other files that don't have the expected root or
immediately following tags (with a warning, because that's likely
something to act on).

These checks used to be inconsistent between extract_metadata() and
parse_xml() (resulting extract_metadata() to continuing further and
dying on some other exception, sigh) and also was an assert instead of a
graceful handling.

A new test case is added to verify that all expected messages are
printed, all unexpected files are skipped but also the expected files
are not skipped. The warnings/errors are also printed just once, not
once during metadata extraction and once during actual page generation.

Co-authored-by: crf8472 <crf8472@web.de>
Co-authored-by: SRGDamia1 <sdamiano@stroudcenter.org>

documentation/doxygen: adapt test output for silly 1.8.18 differences.

Is this a random order? FFS.

documentation/doxygen: all strikethroughs are supported only in 1.8.17.

documentation/doxygen: don't set a config value twice in the test.

documentation/doxygen: 1.8.16 doesn't support subpages of index.

These just aren't marked as such. So skip the direct test and rewrite
the other to not accidentally use this functionality.

package/ci: test against Doxygen 1.8.16 and 1.8.18 as well.

Preparing for the final boss which is 1.9, but!

 * 1.8.13 downloads and runs fine, but there's way too many test
   failures and I'm not ready for these. Probably will just drop the
   support eventually.
 * 1.8.14 to 1.8.15 links to libclang.so.6, which is not a thing on
   Ubuntu 18.14. I suppose this is because SOMEBODY built the damn
   release binary on their own PC, instead of in an old enough sandboxed
   environment, HA?!
 * 1.8.16 and 1.8.17 work, just a bunch of fixes needed to make test
   pass on .16.
 * 1.8.18 works, except it relies on some silly libtinfo.so.5 that I had
   to install.

Update copyright year.

Pro Tip: if you update only once every two years, you save 50% of the
work! 50%!!!!

documentation: expose search data packing options.

There are new SEARCH_RESULT_ID_BYTES, SEARCH_FILE_OFFSET_BYTES and
SEARCH_NAME_SIZE_BYTES options exposed in both Doxygen and Python doc
generator. Because they affect some internals that the regular user
shouldn't need to care about and don't reflect anything tangible like
project symbol count, they're not really documented.

On the other hand, they can't really be estimated beforehand The
estimator would either overestimate, leading to files larger than they
could be, or it underestimates, leading to random corner cases that
would be impossible to track down. Thus the project just starts with the
small sizes and if they're not enough, an exception with a (hopefully
helpful-enough) message is raised, suggesting users to adjust their
config.

documentation: parametrize the search binary data type sizes.

Needed in order to support more than 65k symbols or files larger than 16
MB. What I thought was "more than enough" during the initial design was
quickly stepped over by various projects, including my own Magnum Python
bindings.

To avoid having to either maintain two separate formats and two separate
en/decoders or needlessly inflate the format for everyone, certain data
types are parametrized based on how large the data is:

 * RESULT_ID_BYTES describes how many bytes is needed to store result
   IDs. By default it's 2 (so 65536 results) but can be also 3 (16M
   results) or 4.
 * FILE_OFFSET_BYTES describes how many bytes is needed to store file
   offsets. By default it's 3 (so 16 MB), but can be also 4.
 * NAME_SIZE_BYTES describes how many bytes is needed to store various
   name lengths (prefix, suffix lengths etc). By default it's 1 (so 256
   bytes at most), but can be also 2.

At first I tried to preserve 32-bit alignment as much as possible, but
eventually realized this is completely unimportant in the browser
environment -- there's other much worse performance pitfalls than
reading an unaligned value. This is also why there are 24-bit integer
types, even though they're quite annoying to pack from Python.

Furthermore, the original hack to reserve 11 bits for result count at
the cost of having only 4 bits for child count was changed to instead
expand the result count to a 15-bit value if there's > 127 results. Some
endianness tricks involved, but much cleaner than before. I briefly
considered having a global RESULT_COUNT_BYTES parameter as well, but
considering >90% of result counts fit into 8 bits and this is only for
weird outliers like Python __init__(), it would be a giant waste of
precious bytes.

The minor differences in the test file sizes are due to:

 * The header expanding symbol count from 16 to 32 bits (+2B)
 * The header containing type description and associated padding (+4B)
 * The result map no longer packing flags and offsets together, thus
   saving one byte from flags (-1B)

To ensure there's no hardcoded type size assumptions anymore, the tests
now go through all type size combinations.