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

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 22nd December, 2018 04:20 (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:

Fost 5 release 5.18.06.45062 now out

Posted 24th June, 2018 03:08 (UTC), last edited 24th June, 2018 10:35 (UTC)

This is the last release that will use Boost build (bjam). We're joining the cmake bandwagon instead. This is more of a sideways step than a forwards one, but hopefully might make some things easier in the long run, although in the short term there are likely poor choices in how to structure the builds.

We are deleting the old boost build files (Jamroots and Jamfiles) from everywhere and tidying up a few other small things at the same time.

With cmake it should become simpler to compile using odd compilers (especially cross compiling) and its ability to generate Visual Studio and XCode project files should make it simpler to work on those platforms, not to mention all of the IDEs that use cmake natively.

Some early advantages are that project layouts are now much more flexible because the cmake link directives don't need paths to targets and also that openssl can be easily replaced by boringssl.

As part of this work we're now dropping fost-orm and fost-py. The only library from fost-orm carried forwards is fost-jsondb which is now part of fost-beanbag. There are no new Python bindings.

Also, due to changes in OpenSSL the oldest version of Boost that will be supported by the cmake based builds will be 1.62.0.

Building on Linux & Mac

git clone --branch=5.18.06.45062 --recursive git@github.com:KayEss/fost-hello.git
cd fost-hello
Boost/build
hello/compile
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-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 — Eclipse project for Android that allows Fost 4 and Beanbags to be used on mobile devices — git@github.com:KayEss/fost-android.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-orm — Object/Relational mapping — git@github.com:KayEss/fost-orm.git
  • fost-postgres — PostgreSQL — git@github.com:KayEss/fost-postgres.git
  • fost-py — Python (2.x) bindings — git@github.com:KayEss/fost-py.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 memory method to the u8view so that the underlying memory buffer can be accessed.

fostgres

  • Add support for password configuration on the connection strings.
  • Allow database connection string settings to come from the environment.

fost-base

  • Add coercions for jcursor index value types.
  • Add some basic base16 support.
  • Add various base32 encoding flavours (base32, base32hex and base32c)
  • Add a fork of Crypto++'s fork of tweetnacl to generate ed25519 signing key pairs.

fost-internet

  • Add fost-hod for handling packet oriented data over TCP.

fost-web

  • Add a pathname view and a file serving view.

Categories:

Fost 5 release 5.18.03.45059 now out

Posted 26th March, 2018 04:11 (UTC), last edited 26th March, 2018 08:53 (UTC)

The Mac builds are finally back! This means we now have Linux, Mac and Android. Regaining iOS support is still something for the future.

The Mac build does drop the Python 2 bindings and the Wright application. Wright isn't going to be a loss, and the Python 2 bindings need to be deprecated in favour of a newer set of Python 3 ones.

One upshot of this is that the oldest compiler we need to support is now likely to be the Mac one rather than the Android one, but it's hard to tell because Apple have a completely different versioning scheme than the llvm project uses.

There have been many changes to the string handling. This is still leading up to the large refactoring. The u8view has become much more useful and there is a shared version of this in the works. Eventually this will lead to the replacement and deprecation of the fostlib::string for a variant based constant string, and the use of std::string everywhere else.

There has also been more cleaning up and removing of Boost libraries. You may find you need to now include Boost threading headers or Boost function headers.

Building on Linux & Mac

git clone --branch=5.18.03.45059 --recursive git@github.com:KayEss/fost-hello.git
cd fost-hello
Boost/build
hello/compile
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-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 — Eclipse project for Android that allows Fost 4 and Beanbags to be used on mobile devices — git@github.com:KayEss/fost-android.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-orm — Object/Relational mapping — git@github.com:KayEss/fost-orm.git
  • fost-postgres — PostgreSQL — git@github.com:KayEss/fost-postgres.git
  • fost-py — Python (2.x) bindings — git@github.com:KayEss/fost-py.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 empty to the u8view and buffers.
  • Add ability to output u8view and move overloaded operator <<s to std namespace.
  • Allow appending of a u8view to a std::string.
  • u8views can be concatenated to form std::strings.
  • u8view supports operator <.
  • lstring now also has a string literal, _l.
  • Add empty() member to lstirng.
  • The const shared string buffers need to be immutable.
  • u8view can be explicitly converted to a std::string.
  • u8view is now comparable with const char *.

threading

  • Don't include any Fost headers.
  • Bypass the coroutine unwind exceptions for the reactor and sync.
  • Move the reactor_pool to reactor.hpp
  • The reactor_pool can be closed and its threads joined at any time.

fostgres

  • Fix the fg parser to allow whitespace and comments in more places.

fost-aws

  • Removed use of boost::function.

fost-base

  • Fix bug to handle requirements for autotest libraries properly.
  • Removed Boost lambda and bind
  • Remove previously deprecated fostlib::counter.
  • Allow the C++ version to be specified as std-version in the requirments.jam file.
  • crypto_compare works with Unicode strings.
  • More tagged strings can now be coerced to json and to f5::u8view.
  • Improve the converting nullable constructor so it uses explicit type conversions.
  • Make more string utilties compatible with f5::u8view, at the cost of wide character literals.
  • Make nullable<f5::u8view> coercions from JSON not throw errors if the value isn't a string.
  • Improve the jcursor APIs to better support u8view and move semantics.
  • Add f5::lstring as an option for storage inside fostlib::json.
  • Control characters need to be escaped when producing JSON strings.
  • Can now mint a JWT with an initial payload.
  • Remove uses of boost::function and make worker const sane.
  • Add missing namespaces to the log definition macros.
  • Small readability improvement to the default stdout logger.
  • Crypto hashes now take a f5::u8view which should remove some memory allocations.
  • Deprecate fostlib::utf::u8_view in favour of f5::u8view
  • Move utf::u8_view to f5-cord.
  • Remove array_view and replace with f5::array_view from f5-cord.
  • Deprecate use of the fostlib::string JSON coercion in favour of utf::u8_view.

fost-internet

  • Make the query_string API a bit less pathalogical by caching the stringified version.
  • JSON arrays used as header sub-values are now set as the JSON string.
  • Removed all uses of boost::function

fost-orm

  • Remove all instances of boost::function

fost-postgres

  • Put session variable names in double quotes.
  • Changed the upsert function to also take an array of strings for a RETURNING clause.

fost-py

  • Fix a problem with Boost 1.65

wright

  • Work is distributed between workers more evenly.

Categories: