blog

2023-02-03

Back to Life

So, wow, gosh, goodness, what the hell - signs of life!

Signs of life indeed.

So, first, the simple stuff - I have brought the forum, mailing lists and this blog up to the current versions of their respective code bases. So things look a little different now on the site.

But the real sign of life is that I’ve picked up the liblfds code I’m doing something with it again.

I’ve actually been working on another major project for the last few years, but that kicked in after I had got liblfds into a state where it was completely unfit for release - huge amounts of new work done, but needing huge amounts more to be viable.

That’s still the case, but I want at least to be in a position where the work is organized, there’s a defined path forward, and I can make consistent, if gradual, progress.

What has to be done now;

  1. liblfds needs work - hazard pointers have been implemented, but they’re not working correctly, and I’m sure they should be; I need to solve this
  2. the documentation needs to be moved from Mediawiki to markdown
  3. a new test suite has to be written
  4. a new benchmark suite has to be written

Right now, I’m getting on with #2.

However, I have adopted a major change in how liblfds is arranged.

Historically, every release had its version number in the names of all objects (structs, functions, etc), so all releases could be used concurrently. It was a lot of work, and I suspect it was confusing for users and hardly used, and so I ended up spending a lot of time, which could have gone into development, managing and maintaining the work needed to maintain these separately named releases.

What I’m doing now is moving over to a single current version, with a comprehensive test suite. If the code as it is now passes the test suite, then it’s fully fit for release and it is the current version. There will be no releases as such - always and only the current version, which passes the test suite.

I will of course maintain a document which lists all API changes, so when you come to upgrade, you can follow down that list and make each change in turn, and so bring yourself up to date.

Next, I have a RISC-V dev board (had it for years) and I came to add RISC-V support; I think I’m going to need to write double-word LL/SC code, in RISC-V assembly! and I can’t do this right now, because I have a new laptop, which currently lacks ethernet, and I need ethernet to connect to the dev board! but it will happen soon, once I order the ethernet adaptor for the lappy (a “frame.work”, and it’s the best laptop ever - it’s bloody great).

I’m also thinking seriously about dropping support for Windows.

I’ve had a number of bad experiences with Microsoft, both personally and that which I’ve seen happen to others, and I’m currently using Windows 7 and both that, and the tooling on it, is now very old - but the later versions of Windows are spyware, and to my knowledge MS still do not properly support anything after C89 - which is crazy.

Okay. That’s all for now.

2023-02-05

Documentation

Wowsers! so, I thought getting the docs brought over from mediawiki to markdown would be a lot of work.

In fact, it’s been possible to automate a huge amount of that work.

You can export from a mediawiki to a single XML. I’ve done that (been doing for it ages, backups), and then in Python extracted each page from the XML, parsed it, then taken the mediawiki markup and converted it to markdown markup. Fantastic!

There are generic mediawiki to markdown converters out there, but the one I saw uses Pandoc for this, and although what it does is not incorrect, it’s not correct, either - for example, in mediawiki, you indicate preformatted text by having one or more leading spaces. This gets converted to each line being in single backticks - when it should be the whole block of preformatted is inside a single pair of triple backticks.

Links are a problem, too. Mediawiki links by page name, but now I have docs which in their native form are markdown, but are converted via Pandoc to HTML - but Pandoc doesn’t know to convert link targets ending in “.md” to link targets ending in “.html” - and the link targets I have from the Mediawiki lack suffixes anyway (and I’ve wanted to rename a number of files from their mediawiki names to easier to use filenames).

So all in all, conversion is a custom job, and I’ve hacked together a Python script which does what I want.

So, this gives me the 7.1.1 docs, in markdown, with roughly but fairly closely the directory structure I want, too, and with working links.

There will be some manual re-organization now, where all markdown pages are linear, but there are some non-linear mediawiki pages are not (the main index page is three main boxes, each with links, and the index pages for each liblfds version are much the same), which brings the 7.1.1 docs properly over to markdown.

Then I need to update the docs to what’s in 7.2.0 now, and there’s a lot that’s been added.

For now, back to the other project I’m currently working on, need to complete a test suite, will take some days.



Home Blog Forum Mailing Lists Documentation GitHub Contact

admin at liblfds dot org