kirit.com

Created 26th April, 2005 13:12 (UTC), last edited 22nd December, 2016 03:24 (UTC)

Writing about C++, Programming, Fost 5, the web, Thailand and anything else that catches my attention—with some photos thrown in

Fost 5 release 5.19.06.45081 now out

Posted 23rd June, 2019 04:17 (UTC), last edited 24th June, 2019 04:22 (UTC)

The biggest change this time around is that a large number of APIs have been marked for deprecation. These will be removed after the next tagged release (September), so please take special care with the deprecation notices and update any code.

We are currently working on full UTF-16 and UTF-32 support in f5-cord. Once this lands then we will deprecate a slew more of old string APIs. Our target is still to replace fostlib::string with f5::u8string. It will of course take a while.

Good progress is being with iOS support now. There is a new unit test runner, test-ios, that passes all unit tests and is available to download and build.

We've removed a couple of the applications that were never being updated, beanbag and beanbag-seed.

We will also cut down the scope of the open source part of Odin to remove the application handling aspects. These just cause a complication and we believe that the only use cases are particular to us. Please get in touch if this is not the case.

Building on Linux & Mac

You should install Boost development packages using your package manager or brew to safe you from having to build them.

git clone --branch=5.18.09.45065 --recursive git@github.com:KayEss/fost-hello.git
cd fost-hello
mkdir build.tmp
cd build.tmp
cmake -G Ninja .. -DCMAKE_INSTALL_PREFIX=../dist
ninja install/strip
export LD_LIBRARY_PATH=../dist/lib
../dist/bin/hello-world-d

On the Mac you will need to set DYLD_LIBRARY_PATH before running hello-world-d

export DYLD_LIBRARY_PATH=../dist/lib
../dist/bin/hello-world-d

Download locations

Applications

  • fost-hello — Sample seed project — git@github.com:KayEss/fost-hello.git
  • mengmon — Stand alone web server — git@github.com:KayEss/mengmom.git
  • test-android — Android application that runs Fost unit tests — git@github.com:KayEss/test-android.git
  • test-ios — iOS application that runs Fost unit tests — git@github.com:KayEss/test-ios.git
  • wright — Experimental build system — git@github.com:KayEss/wright.git

Libraries

  • f5-cord — First version of a new string library with compile time string and Unicode support — git@github.com:KayEss/f5-cord.git
  • f5-json-schema — JSON Schema validation — git@github.com:KayEss/json-schema.git
  • f5-threading — Preview of the first Fost 5 library which includes help for threading — git@github.com:KayEss/f5-threading.git
  • fost-aws — Amazon AWS and OpenStack — git@github.com:KayEss/fost-aws.git
  • fost-android-ndk — The native code for Android. Includes required parts of Boost configured to use the standard Android build system.
  • fost-beanbag — Transactional JSON database — git@github.com:KayEss/fost-beanbag.git
  • fost-base — Build system and core libraries — git@github.com:KayEss/fost-base.git
  • fost-internet — Internet protocols, servers & clients — git@github.com:KayEss/fost-internet.git
  • fost-meta — All libraries in one wrapper — git@github.com:KayEss/fost-meta.git
  • fost-postgres — PostgreSQL — git@github.com:KayEss/fost-postgres.git
  • fost-web — Web server libraries — git@github.com:KayEss/fost-web.git
  • fost-wright — Experiment in a build system — git@github.com:KayEss/fost-wright.git

Detailed change log

f5-cord

  • Deprecated two argument substr as the second argument handling doesn't match std::string::substr.

f5-threading

  • Replace std::experimental::optional with std::optional

fost-base

  • Implement string conversion (ISO Zulu time) for std::chrono::system_clock
  • Add new nonce functions that return base64url formatted random data in ordered and un-ordered variants.
  • Force conversion of the underlying string type from a tagged string to std::string be explicitly invoked.
  • Deprecate length members of tagged_string and string.
  • Add some APIs to tagged_string that are currently on string.
  • Add bin/minit back into project.
  • Deprecate string::length and tagged_string<>::length
  • Add a setting, fostlib::test::c_files_folder, describing the root folder tests should use if they need access to the file system.
  • Use of define FSL_FORCE_STD_FILESYSTEM switches from boost::filesystem to std::filesystem with names in fostlib::fs.
  • Start to process the string deprecations that we want to have:
    • Deprecate fostlib::tagged_string<T, I>::underlying().
    • Deprecate fostlib::string::c_str().
    • Add API for turning a fostlib::string into an f5::u8string (u8string_transition).

fost-internet

  • Add methods for fetching out string version and JSON version of mime bodies.

fost-postgres

  • Add RETURNING support to connection's update method.

fost-web

  • Add JSON directory listing view and ability to choose directory listing view for the static file server.
  • The web server takes a -C option which changes its current directory
  • Text files (text/ Content-Type) are served as UTF8.

fostgres

  • Object APIs can now process JSON arrays into a separate table.
  • Add a new view to retry Postgres serialisation errors.
  • Add a request logging middleware that stores the per-request log to the database.

odin

  • Support multiple facebook apps
  • Fix view odin.password.me
  • Add executable for timing password hashing rounds and configuration item for round count.


Categories:

Fost 5 release 5.19.03.45077 now out

Posted 31st March, 2019 03:51 (UTC), last edited 24th June, 2019 04:21 (UTC)

We've now finally started the process of porting the fostlib::string implementation to use f5::u8string. A short write up about the design can be found in the repository. There are going to be a lot of new deprecations in the next release and we'll then start to remove the deprecated code after that.

Building on Linux & Mac

You should install Boost development packages using your package manager or brew to safe you from having to build them.

git clone --branch=5.18.09.45065 --recursive git@github.com:KayEss/fost-hello.git
cd fost-hello
mkdir build.tmp
cd build.tmp
cmake -G Ninja .. -DCMAKE_INSTALL_PREFIX=../dist
ninja install/strip
export LD_LIBRARY_PATH=../dist/lib
../dist/bin/hello-world-d

On the Mac you will need to set DYLD_LIBRARY_PATH before running hello-world-d

export DYLD_LIBRARY_PATH=../dist/lib
../dist/bin/hello-world-d

Download locations

Applications

  • beanbag — Stand alone transactional JSON database server — git@github.com:KayEss/beanbag.git
  • beanbag-seed — Seed project for giving you a starting point to develop web applications using Beanbag — git@github.com:KayEss/beanbag-seed.git
  • fost-hello — Sample seed project — git@github.com:KayEss/fost-hello.git
  • mengmon — Stand alone web server — git@github.com:KayEss/mengmom.git
  • test-android — Android application that runs Fost unit tests — git@github.com:KayEss/test-android.git
  • wright — Experimental build system — git@github.com:KayEss/wright.git

Libraries

  • f5-cord — First version of a new string library with compile time string and Unicode support — git@github.com:KayEss/f5-cord.git
  • f5-json-schema — JSON Schema validation — git@github.com:KayEss/json-schema.git
  • f5-threading — Preview of the first Fost 5 library which includes help for threading — git@github.com:KayEss/f5-threading.git
  • fost-aws — Amazon AWS and OpenStack — git@github.com:KayEss/fost-aws.git
  • fost-android-ndk — The native code for Android. Includes required parts of Boost configured to use the standard Android build system.
  • fost-beanbag — Transactional JSON database — git@github.com:KayEss/fost-beanbag.git
  • fost-base — Build system and core libraries — git@github.com:KayEss/fost-base.git
  • fost-internet — Internet protocols, servers & clients — git@github.com:KayEss/fost-internet.git
  • fost-meta — All libraries in one wrapper — git@github.com:KayEss/fost-meta.git
  • fost-postgres — PostgreSQL — git@github.com:KayEss/fost-postgres.git
  • fost-web — Web server libraries — git@github.com:KayEss/fost-web.git
  • fost-wright — Experiment in a build system — git@github.com:KayEss/fost-wright.git

Detailed change log

cord

  • Add ends_with on the u8view and u8string.

json-schema

  • Add debug logging for the HTTP schema loader.

fost-base

  • Split the CMake configuration into smaller parts.
  • Changes to string handling to support wider adoption of f5::u8string
  • Further changes needed for new f5-cord string implementation.

fost-web

  • Add test.throw view to help with testing and control.exception.catch for running alternative views when exceptions are thrown.
  • Fix fost.proxy.transparent. Pass the correct path.
  • Add fost.control.status-condition view

fost-wright

  • Made implementation compatible with future changes to string APIs.

fostgres

  • fostgres.sql supporting precondition
  • Fixed a bug in the HTTP tests not doing name look ups correctly.
  • Add debug logging of the database JSON schema loader.
  • Add fostgres.control.pg-error view
  • Add fostgres-tests
  • POST support configuration as an array

odin

  • Implement app logins for Facebook and Google.
  • Abandon unregister user when merge failed
  • Fix merge_record failed when user has app installation record
  • Trigger merge account when user token and login mismatch
  • Add merge identities
  • Remove usage of app token
  • Fix AuthN login schema
  • Add odin.middleware.reference view

Categories:

Build me a LISP

Created 9th February, 2019 07:42 (UTC), last edited 9th February, 2019 10:53 (UTC)

Normally programming language blog posts get started with grammars and syntax and parsing and all sorts of stuff like that. I can't be bothered with all of that, so instead, let's start with the (maybe more interesting aspect) of the actual evaluation of the code. Here we'll build an evaluation engine for LISP like languages in less than 50 lines of C++ — and literate C++ at that!

Lisp uses something called a "cons cell" to store each part of both the program and the data. Let's just say we have something called a cell for now, and we'll come back to defining what it is later on.

1
struct cell;

S-Expressions

A Lisp program is actually just something called an s-expression. It's a fancy term for a list of cells, but there is a special way to interpret these s-expressions. We'll come back to that later on.

For now, we just need to know that s-expressions describe our LISP program, and to run a LISP program we simply evaluate the s-expression.

2
3
#include <vector>
using sexpr = std::vector<cell>;

Cells

Now we can talk about what a cell is. Our simple LISP will only have a single data type, strings, so our cells will either contain a string or an s-expression.

4
5
6
7
#include <string>
#include <variant>
struct cell {
    std::variant<std::string, sexpr> content;

We do need to be able to make cells, and they can be made from either strings or s-expressions.

8
9
10
    cell(std::string s) : content{std::move(s)} {}
    cell(sexpr s) : content{std::move(s)} {}
};

Evaluation

There are three different sorts of data structure that we have so far:

  1. Strings
  2. S-expressions
  3. Cells

Because running our programs is going to be a matter of evaluating these structures, we'll need to consider what "evaluation" means for each of these.

First of all, strings are just themselves.

11
std::string eval(std::string s) { return s; }

The s-expressions are a bit more interesting, but for now we just have to promise to implement them so that we can start with the simpler cells (and because we have to implement the evaluation of the s-expressions in terms of evaluating cells)…

12
std::string eval(sexpr const &);

Evaluating a cell is pretty simple. It's either going to be a string or a s-expression, so depending on what we find in the cell content we can just forward to evaluating whichever one we find.

13
14
15
std::string eval(cell const &c) {
    return std::visit([](auto const &c) { return eval(c); }, c.content);
}

The standard library

Although an s-expression is just a vector of cells, the first item in it is special. To evaluate an s-expression we take the first item in it to be the name of a function that is to be executed, and the remaining s-expression cells are then taken as that function's arguments (some of which may be s-expressions that require evaluation themselves).

So if you're used to writing your programs like this:

foo(bar, baz)

The s-expression form would look more like:

(foo bar baz)

We're going to implement our library in C++, and we're going to look functions up by name. Because the s-expression can have any number of arguments, it makes sense to evaluate them based on a couple of iterators (markers), one to the first argument and one to the end of the s-expression.

16
using marker = sexpr::const_iterator;

Our built in library functions take the two iterators representing their arguments and return a string which is the result of running them.

17
18
#include <functional>
using builtin = std::function<auto(marker, marker)->std::string>;

We now need a simple data structure that will hold these for us and allow look-ups by name.

19
20
#include <map>
std::map<std::string, builtin> library;

Evaluating S-Expressions

The first item in an s-expression is a function name that we're going to call. This means that an empty s-expression is an error.

21
22
23
24
#include <stdexcept>
std::string eval(sexpr const &s) {
    if (s.begin() == s.end()) {
        throw std::domain_error("Empty sexpr");

An alternative design would be to say that an empty s-expression evaluates to an empty string, but this is good for us.

Now, assuming our s-expression contains a first item, we need to fetch the function name. Remember that our s-expression is comprised of cells (which can contain strings or s-expressions) so we need to turn our cell into a string. Luckily we already have a function that does that: eval.

25
26
    } else {
        auto const fname = eval(*s.begin());

Using eval here (rather than just fetching the string out of the cell directly) has some important consequences to what this language can do.

Although we've said so far that the first item in an s-expression has to be the function name, by evaluating the cell to fetch that string we can actually have an s-expression as the first cell! And evaluating that s-expression gives the function name that we will run. Don't worry about this for now, there will be an example at the end.

Now that we have a function name we only need to look it up and call it, and of course take into account the possibility that it might not be found.

27
28
29
30
31
32
33
        if (auto const fp = library.find(fname); fp != library.end()) {
            return fp->second(++s.begin(), s.end());
        } else {
            throw std::invalid_argument{fname + " not in the library"};
        }
    }
}

And that's actually it for the whole evaluation engine. Luckily we have some lines left over to try it out with.

Running a program

34
35
36
#include <iostream>
int main() {
    try {

As with all programming languages we have to make sure to say hello to the whole world.

(cat "Hello" "world!")

Because we didn't bother with a parser we have to write the data structure for the program directly into the C++ source code. Thankfully it's not too hard.

37
38
        using namespace std::string_literals;
        auto const prog = sexpr{"cat"s, "Hello "s, "world!"s};

Of course we didn't put anything into our library yet, so let's make sure that we do at least have an implementation of cat we can call.

39
40
41
42
43
        library["cat"] = [](marker pos, marker end) {
            std::string ret;
            while (pos != end) ret += eval(*pos++);
            return ret;
        };

Now we can run our program and show the result.

44
        std::cout << eval(prog) << std::endl;

If you grab this C++ file you can compile and run it using something like (the file is available as a Gist on Github):

clang++ lisp.cpp -std=c++17 -o lisp
./lisp

And you'll see some output:

Hello world!

Errors…

The very last thing we should do is to print out some sort of error message if a run-time error came up.

45
46
47
48
49
    } catch (std::exception &e) {
        std::cerr << "Error: " << e.what() << std::endl;
        return 1;
    }
}

More fun

Remember there was the bit about the evaluation of the lead term in the s-expression? Because the first term can itself be an s-expression you can write a program to generate the function name you want to call.

If you do try this on your machine, try to change the program to the following and see what happens.

auto const prog = sexpr{
    sexpr{"cat"s, "c"s, "a"s, "t"s},
        "Hello "s, "world!"s};

When you run this it will still print "Hello world!" because the s-expression as the first term gets evaluated and produces the name cat which then gets called to produce the output.

Order fun

Remember the type we had for builtin took markers to the s-expressions of the arguments? This means that the argument values are evaluated inside of the library function definition. Look again at the loop in our cat function:

while (pos != end) ret += eval(*pos++);

It would also be a reasonable choice to move that evaluation outside of the library function and instead have our builtin type look like this (a function that takes a vector of strings and produces a string):

using builtin = std::function<auto(std::vector<std::string>)->std::string>;

This difference in where the expressions are evaluated is called Evaluation Strategy and the choice we made above is called normal-order. This is of course the opposite of what you're used to from pretty much every other programming language, which normally use applicative-order.

More commonly, normal-order is referred to as lazy evaluation and applicative-order as eager evaluation.

if isn't (an eager) function

In LISP terms our builtins are all special forms. This is important in order to be able to correctly implement forms like if.

Let's say we want to implement if so that it can be used something like this:

(if (condition) (true-case) (false-case)) -> string

We will always need to evaluate the condition expression, and, depending on what happens, we are for sure going to return either the true-case or the false-case. But more importantly we only want to evaluate one of them.

If we have to implement if in a language that only has eager evaluation then we will evaluate both the true-case and the false-case even if we only return the result of one of them.

But with lazy evaluation we can save ourselves some processing, and this control of the evaluation that we give to the library functions is critical if you want to take this toy language and turn it into something real.

C++ itself is an eager language and this is why we cannot short-circuit in user-defined implementations of && and ||, something that can cause us some pain. But there is hope.

Posted: 9th February, 2019 08:52 (UTC)
First announced

Fost 5 release 5.18.12.45070 now out

Posted 22nd December, 2018 03:42 (UTC), last edited 24th June, 2019 04:23 (UTC)

There are some large changes in process at the moment. We're revamping the string handling in f5-cord to used shared ownership and persistent data. The new string has many improvements and fostlib::string will continue to bridge the gap between the old and new designs, although we will start on a track of deprecation of much of the old API.

We are also tidying up the JSON implementation to work with the new string type. This will split it apart from the rest of fost-base and make it much easier to use in other projects.

The Android unit test runner is now fully working and stable. It runs all of the “check” tests from all of the relevant libraries. For details check it out on Github. The Apple Mac builds are now also fully stable (at least for Mojave) and we are working on a Mac iOS test runner to complement the Android one. This should be working by the next release.

Lots of changes have been made to the cmake builds to make them more flexible. The f5-json-schema library is now usable for validating request bodies for web APIs.

Building on Linux & Mac

You should install Boost development packages using your package manager or brew to safe you from having to build them.

git clone --branch=5.18.09.45065 --recursive git@github.com:KayEss/fost-hello.git
cd fost-hello
mkdir build.tmp
cd build.tmp
cmake -G Ninja .. -DCMAKE_INSTALL_PREFIX=../dist
ninja install/strip
export LD_LIBRARY_PATH=../dist/lib
../dist/bin/hello-world-d

On the Mac you will need to set DYLD_LIBRARY_PATH before running hello-world-d

export DYLD_LIBRARY_PATH=../dist/lib
../dist/bin/hello-world-d

Download locations

Applications

  • beanbag — Stand alone transactional JSON database server — git@github.com:KayEss/beanbag.git
  • beanbag-seed — Seed project for giving you a starting point to develop web applications using Beanbag — git@github.com:KayEss/beanbag-seed.git
  • fost-hello — Sample seed project — git@github.com:KayEss/fost-hello.git
  • mengmon — Stand alone web server — git@github.com:KayEss/mengmom.git
  • test-android — Android application that runs Fost unit tests — git@github.com:KayEss/test-android.git
  • wright — Experimental build system — git@github.com:KayEss/wright.git

Libraries

  • f5-cord — First version of a new string library with compile time string and Unicode support — git@github.com:KayEss/f5-cord.git
  • f5-json-schema — JSON Schema validation — git@github.com:KayEss/json-schema.git
  • f5-threading — Preview of the first Fost 5 library which includes help for threading — git@github.com:KayEss/f5-threading.git
  • fost-aws — Amazon AWS and OpenStack — git@github.com:KayEss/fost-aws.git
  • fost-android-ndk — The native code for Android. Includes required parts of Boost configured to use the standard Android build system.
  • fost-beanbag — Transactional JSON database — git@github.com:KayEss/fost-beanbag.git
  • fost-base — Build system and core libraries — git@github.com:KayEss/fost-base.git
  • fost-internet — Internet protocols, servers & clients — git@github.com:KayEss/fost-internet.git
  • fost-meta — All libraries in one wrapper — git@github.com:KayEss/fost-meta.git
  • fost-postgres — PostgreSQL — git@github.com:KayEss/fost-postgres.git
  • fost-web — Web server libraries — git@github.com:KayEss/fost-web.git
  • fost-wright — Experiment in a build system — git@github.com:KayEss/fost-wright.git

Detailed change log

cord

  • Add const iteration of shared_buffer.
  • Support (explicit) conversions of the string types to std::string_view
  • Add a new f5::cord::string type, immutable shared string.
  • Add a starts_with member to u8view.
  • Add a missing comparison operator.

threading

  • Remove the old deprecated eventfd based code.
  • Add clear member to tsmap and improve the return type for unique_ptr.
  • Fix a bug in tsmap::insert_or_assign which caused it to return the wrong value.
  • Small improvement to API for moving things into a tsmap.
  • Fix a horribly broken search API in tsmap.

json-schema

  • Complete the implementation of fetching schemas over HTTP(S).
  • The implementation now fully conforms to the V7 test suite.
  • Added an API that can be used to register schema loaders.
  • Refactor the assertion functions so that they will be easier to extend in future.

fost-base

  • Split the CMake configuraion into smaller parts.
  • Changes to string handling to support wider adoption of f5::u8string
  • Support EdDSA JWTs.
  • JWT secrets can now be looked up via a function passed to the load function.
  • Add iterator traits to JSON iterator.
  • Tidy up some headers.
  • Do less work when stringifying JSON.
  • Refactor the integral to integral coercions to remove a lot of complex template meta-programming.
  • Add a way to get a JSON pointer URL fragment string for a jcursor.

fost-internet

  • Allow setting a URL fragment from a jcursor.
  • Implement a better URL join that covers many more of the required cases.
  • Remove usernames and passwords from URLs.
  • Rename url::anchor to url::fragment as that is the proper term.

fost-web

  • Add fost.schema.validate view

fostgres

  • Extend schema validation to fields and CSJ.

odin

  • Add odin.password.hash view
  • Remove deprecated warnings
  • Added odin.app.installation view
  • Support app OPEN access policy
  • odin.app.secure doesn't need app_id as a prefix anymore.
  • Fix table app_user PK order
  • Add table app_role_ledger
  • Add table app_user_role_ledger
  • Added app user roles
  • Tighten up some APIs in the example configuration.
  • Added module opts/installation-id
  • Added odin.app.handover view
  • Added odin.app.verify view
  • Added odin.app.secure view
  • Added Expire user module

Categories:

Fost 5 release 5.18.09.45065 now out

Posted 25th September, 2018 03:04 (UTC), last edited 25th September, 2018 10:37 (UTC)

The switch to CMake has been generally pretty good. There are a few rough edges, and some weird things that it just doesn't seem to want to do. As a consequence, things like examples don't work very well yet, but it is very good that the build process now follows a more “standard” approach.

The Mac support has also had it's ups and downs. The switch to C++17 caused problem due to the age of the compiler available, but that was fixed with the new command line tools that landed week. The final piece is some changes to the system libraries that are supposed to land with Mojave. Hopefully this will be smooth when it's used.

A new JSON schema validation library has been added and schema validation features are now available in Fostgres. It would make sense to also add them to the Beanbags, but that work hasn't been planned yet, let alone started.

Building on Linux & Mac

You should install Boost development packages using your package manager or brew to safe you from having to build them.

git clone --branch=5.18.09.45065 --recursive git@github.com:KayEss/fost-hello.git
cd fost-hello
mkdir build.tmp
cd build.tmp
cmake -G Ninja .. -DCMAKE_INSTALL_PREFIX=../dist
ninja install/strip
export LD_LIBRARY_PATH=../dist/lib
../dist/bin/hello-world-d

On the Mac you will need to set DYLD_LIBRARY_PATH before running hello-world-d

export DYLD_LIBRARY_PATH=../dist/lib
../dist/bin/hello-world-d

Download locations

Applications

  • beanbag — Stand alone transactional JSON database server — git@github.com:KayEss/beanbag.git
  • beanbag-seed — Seed project for giving you a starting point to develop web applications using Beanbag — git@github.com:KayEss/beanbag-seed.git
  • fost-hello — Sample seed project — git@github.com:KayEss/fost-hello.git
  • mengmon — Stand alone web server — git@github.com:KayEss/mengmom.git
  • wright — Experimental build system — git@github.com:KayEss/wright.git

Libraries

  • f5-cord — First version of a new string library with compile time string and Unicode support — git@github.com:KayEss/f5-cord.git
  • f5-json-schema — JSON Schema validation — git@github.com:KayEss/json-schema.git
  • f5-threading — Preview of the first Fost 5 library which includes help for threading — git@github.com:KayEss/f5-threading.git
  • fost-aws — Amazon AWS and OpenStack — git@github.com:KayEss/fost-aws.git
  • fost-android-ndk — The native code for Android. Includes required parts of Boost configured to use the standard Android build system.
  • fost-beanbag — Transactional JSON database — git@github.com:KayEss/fost-beanbag.git
  • fost-base — Build system and core libraries — git@github.com:KayEss/fost-base.git
  • fost-internet — Internet protocols, servers & clients — git@github.com:KayEss/fost-internet.git
  • fost-meta — All libraries in one wrapper — git@github.com:KayEss/fost-meta.git
  • fost-postgres — PostgreSQL — git@github.com:KayEss/fost-postgres.git
  • fost-web — Web server libraries — git@github.com:KayEss/fost-web.git
  • fost-wright — Experiment in a build system — git@github.com:KayEss/fost-wright.git

Detailed change log

cord

  • Add a member to fetch the number of code points from u8view.
  • Fix a bug in the printing of u8view to streams.
  • Add more equality comparison for u8view.
  • Add better members for initialising the shared_buffer.

threading

  • Replace the use of eventfd with a pipe.
  • Remove the deprecated `f5/threading/boost-asio.hpp` header.

fost-base

  • Add a parser for JSON pointers.
  • fostlib::json::apply_visitor can now take any number of lambda like expressions.
  • An empty jcursor needs to be represented as an empty array in JSON.
  • Add an object and array member to json to make access and iteration simpler.
  • Add direct comparison between JSON and u8view.
  • Add iteration over the command line arguments passed to fostlib::arguments.
  • Remove info member from exception and change throw to noexcept.
  • Remove fostlib::variant as it's not used.
  • Switch fostlib::json to use std::variant.
  • Remove memoize, as it's never been used.
  • fostlib::nullable, fostlib::null_t and fostlib::null are now aliases to the std::optional types and values.
  • Add a logger that outputs single lines of JSON to the console.
  • Use guids to generate temporary file names.
  • Fix a potential problem with the pathname join function one of the paths is empty.
  • Fix up the library searches for dynlink
  • Add some missing append operation for string
  • Fixed password hashing to use u8view instead of utf8_string
  • Fixed include for fostlib::insert
  • Use a more efficient implementation for crypto_bytes — Reverted for now as the required system call header is not always available.
  • Added RIPEMD-256 cryptographic hash function.

fost-internet

  • Improve handling of weird ways TCP connections can be dropped and add more logging.
  • The HTTP response body doesn't really need to be const.
  • No longer make use of Boost regex library.

fost-wright

  • Fix a bug where a child death after all jobs had been handed out would result in the parent process being killed.
  • Add support for distribution of work over a network connection.

fostgres

  • Add JSON schema validation for object PUT and PATCH.
  • Fix the order of the expected & actual results for object request.
  • Fix a bug in the HTTP request checking where expressions would be resolved twice.
  • Add fg quote function

odin

  • Returned Unprocessable Entity when user's email already exists in the system.
  • Added Login with Odin page
  • Added App module
  • Added odin.api.login view
  • Added link Facebook module
  • Added login with Google module
  • Added login with Facebook module
  • Added reset forgotten password API view
  • Added forgotten-password module
  • Added self registration API with full-name
  • Added self registration API with e-mail address
  • Change the way that Odin migrations are run.
  • Deprecate setting a password when a user is created. It should be done separately

Categories: