So, I made libpal and moved the liblfds and test porting layers into it. The liblfds porting layer consists of header files only, so libpal does not need to be compiled for liblfds – but it does need to *be there* and that was *odd*.
It meant liblfds now dependend upon some header files elsewhere, so you had to make sure to copy not just the library other but this dependency.
This is not going to be expected.
I think in fact the problem was that I added libcommmon and libbenchmark. I like having them, they make it easier to code, but then I need to document well there’s test, and then there’s libcommon, and you need to build this and this for that and so on…
So what I’m going to do is make liblfds, test and benchmark independent (well, test and benchmark both require liblfds of course 🙂
They will have their own fully independent porting layers, and I’ve got rid of libcommon/libbenchmark. It will mean duplicating some abstraction and utility code between test and benchmark, but it’s worth it for the simplification of documentation.
I’ve been looking at the porting documentation.
Right now it’s wrong, because it talks about porting *test*, but you don’t port test – test has no porting stuff in it. You need to port libcommon; it’s that which has the abstraction layer for test.
It’s called libcommon because although it’s not in this release, there’s also a benchmark programme, and there’s also a libbenchmark, which has another, fatter abstraction layer needed by the benchmark programme.
So it’s a complex mess.
What I’m thinking now is to remove the abstraction layer from liblfds, get rid of libcommon and libbenchmark and have libporting (porting abstraction layer). This will contain all of the abstraction layers – you implement as much as you need to get what you want working, i.e. there’s a minimal layer for liblfds, a bit more on top of that for test, then quite a bit more for benchmark.
libcommon and libbenchmark also contain quite a bit of utility code used by test and benchmark, but I can move that code into the programmes themselves – just to get it out of the way from the user.
Thing is, I really do NOT want to go off into major surgury land at this point. I want to get a release out.
So far today;
1. hash docs first pass
2. first pass for both usage guides
3. introduction second pass
1. btree docs
2. building guides
1. list bifuricated (library and test)
2. first pass list docs written (for both lists)
3. first pass liblfds porting guide written
4. added liblfds to the API docs
1. binary tree docs
2. hash docs
3. liblfds docs
4. ringbuffer docs
5. porting guide for test
6. complete the building guides
7. complete the user guides
8. bring all the build configurations up to date and run test on all platforms
I’ve split the list into two, one is ordered, the other is unordered.
I’ve just been documenting the list.
I’m finding I’m having to explain a lot about ordered vs unordered usage – I think I’m going to split the list into two, an ordered version and an unordered version.
Docs take foooooooooooooooooooooooooorever.
I know this of course.
I’m just sayin’ 🙂
The code is basically complete – I need to update build files for all the platforms, and then run test on them all.
It’s all doc work now.
Turned out to be a test bug.
Been writing docs. Getting the filled-in template pages up for each prototype. Done about half.
Release 7.0.0 features exponential backoff for atomic operations.
There was a bug in this code which meant the backoff loop instead of running up to 0/1/2/4/8/16/32/etc times, was running a very large number of times (billions).
This caused the ringbuffer read test to fault 🙂
I’ve added now a random delay in all the tests, which is present only in debug builds (i.e. slow builds) and I’m running it through now.
Raspberry Pi is up and running and currently executing the test programme.
It’s been flawless. Wrote an image of the Pi port of Debian on an SD card, this has gcc, make, nano, etc, on board. Booted perfectly, logged in, transferred the liblfds source code, compiled it all, first time I’ve build on Linux for a bit so fixed one of two bugs (and as ever always surprised that the MS compiler I’m using doesn’t complain when I used undefined enum types – yes, you read that right!)
Fabulous. Got my own tiny form factor 32-bit quad-core ARM platform, for 70 bucks all told. Couldn’t ask for more.