This is the first release for C++14. It includes a preview of a first version of the Fost 5 threading library, but fost-windows has been removed due to continued in-accessibility to a compiler and test platform. Old versions of Boost should probably be rebuilt so that they will be built with C++14.
All of the changes for this switch are going to take a bit of time to settle down. So far we are using C++14 for Android and Linux projects based on this release, but the packaging of it is probably still a bit off in some of the -dev projects.
We've also restricted the Boost versions that we're supporting to 1.55 through 1.58. And Android library is currently using 1.56.
git clone --branch=4.15.06.44953 --recursive firstname.lastname@example.org:KayEss/fost-hello.git cd fost-hello Boost/build 58 0 Boost/install 58 0 hello/compile dist/bin/hello-world-d
std::rethrow_exceptionto move an exception between threads.
FOST_HAS_MOVEdefine because with C++14 we don't need it.
.tests.cppas well as
jcursor::insertfails due to existing data at the requested key.
datamember to the local JSON transaction so all of the data can be fetched.
The biggest change in 1.7 was the alteration of Django's transaction handling. This was a change that I never thought that the Django project would make. I don't yet have enough experience with these later versions of Django to say whether or not the handling really makes sense, but from reading the documentation I'm hopeful — however it seems to me that the defaults for new projects are still broken and unsafe, but it's still too early for me to have any specific recommendations in this regard.
This unsafe-by-default behaviour is compounded by the difficulty of testing transactions in Django. Django's test runner tries to be clever with transactions in order to speed up test execution, something that works against getting transactions correct in the code. Then there's the removal of the transaction middleware. It used to be quite simple to ensure that requests had safe enough defaults within the context of a request by simply using this middleware. Now each view must be correctly marked up in order to get safe behaviour — something nearly impossible to test for, and difficult to know and remember. Are you sure that every single view in your latest Django project correctly uses atomic?
I think only people who have a deep understanding of database transactions and why they're needed have any hope of getting Django to do the right thing now. My advice used to be to include the transaction middleware in your application and then the behaviour you get would be what you'd probably expect — when a request errors then no changes are made to the database. This is very simple to reason about for expert and beginner alike.
So, although Django Async's tests all pass with both 1.7 and 1.8 I have little faith that the underlying behaviour is actually safe in the context of a request, although I believe that the queue itself is still safe.
With Slumber it's slightly more complex. There have been extensive changes in the meta layer (that describes applications and models) and although I think I have most of that worked through in a more or less acceptable manner there are test failures that defy explanation — tests not being able to see the data that they've just written to the database. There is probably some stupid error on my part here, but with Django nose still broken for Django 1.8 it's also very hard to get any insight through the logs as to what is happening. A large number of incompatibilities have been fixed though.
I've also added the use of Django's
atomic decorator to the views (where this is available, at least where it can be imported). I believe that this ought to make all Slumber operations safe under 1.7 and 1.8. This change is already in the develop branch, and will be published as 0.8.1 once I get a chance (certainly in the next day or two).
I have many very large disks spread across several machines at my home office — currently 14TB on my desktop and 13TB on my main file server. I have also have a few others knocking about for backups which I put into an external hot-drive slot on my desktop case. The environment that I'm in is extremely hostile to disks — I churn through a lot of data running compilations, tests, VMs and doing animations. Not to mention other data processing tasks associated with logs across large numbers of servers. Added to the heat in Thailand disks don't last very long. Recently I've been getting better at replacing disks before they totally fail.
Back in the days when I was using only Windows I used to stripe up smaller disks into single large logical volumes. This make using the disks far easier (and in many cases increases performance), but it comes at a great cost — if any disk fails then the entire logical volume dies with it. I've also tried out RAID using
mdadm. This works well until anything at all goes wrong. I don't think I've ever come across any tool that was quite so user hostile as
mdadm. Every time I've needed to use it it's taken me half a day to re-learn how to do even the simplest of tasks. LVM also has some RAID abilities, but I've never tried them.
I first started to use LVM because it has great tools for resizing disk partitions, but these days I don't use any of those. The main reason I use it now is that it is the only way I know of to correctly handle very large disks.
There are three layers that need to be initialised:
The configuration I'm always after is rather simple: a single volume group per disk and then a single logical volume that takes up the whole disk as well.
First create the physical volume directly onto the disk. The standard disk partitioning programs don't seem to work properly with disks larger than a couple of TB (and you may not notice until you're writing data above the 2TB mark).
sudo pvcreate /dev/sdf
We want a volume group for a single disk. It's tempting to do other things here and to try to be clever — pretty much always a bad idea (see above).
sudo vgcreate miro2 /dev/sdf
Create the logical volume:
sudo lvcreate --name files6 --extents 100%VG miro2
Finally make a file system:
sudo mkfs.ext4 /dev/mapper/miro2-files6
I use a naming convention for the volume groups that includes the machine name. This makes it easier to move a disk between machines without suffering a name clash. I also just use an increasing number for the logical volume names for simplicity's sake. These disks get mounted through
fstab into a folder each under
/dev/mapper/miro1-files5 /mnt/files5 ext4 noatime,errors=remount-ro 0 1 /dev/mapper/miro2-files6 /mnt/files6 ext4 noatime,errors=remount-ro 0 1
I always use
noatime simply because I think it does save some writes and I never have reason to care about access times. I use bind mounts to put individual folders on the disks where I want them:
/mnt/files4/projects /home/kirit/Projects none bind 0 0
My next task is to try to work out how to use
smartctl better and add that to my internal monitoring in the hopes of getting more advanced notice that disks are failing.
This is going to be the last Fost 4 release. At some point soon the fost 5 branches will be removed and new long term 4.15.03 branches will be set up for long term maintenance of the C++03 compatible versions of the libraries.
|Linux & Mac|
git clone --branch=22.214.171.124938 --recursive email@example.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
git clone --branch=126.96.36.199938 --recursive firstname.lastname@example.org:KayEss/fost-hello.git cd fost-hello Boost\build hello\compile dist\bin\hello-world-gd
The new version of Fost is going to have a large number of breaking changes that will affect pretty much every aspect of the libraries' use. The reason for this is quite simple, C++11 is really a new language when compared to C++03. Many of these changes will be brought about due to simple changes brought about by the promotion of many Boost libraries into the standard library.
The plan is to support C++14 with whatever compilers we can use to do this. The current latest version of Ubuntu at least has the features we need to make a start here. I hope that Microsoft Visual C++ 2013 also has enough support to at least get started. We still aren't in a position to support Mac OS X as I don't have access to the platform in a manner suitable for testing — it isn't clear to me that this is even possible without a huge investment due to inherent limitations of OS X virtualisation.
There's likely to be a problem with compilers on the older Ubuntu platforms that's likely to necessitate building both a compiler and Boost. Hopefully Docker can help make this somewhat simpler.
Initially we'll be wanting to support Ubuntu Precise (12.04) and later, and Windows with Microsoft Visual C++ 2013. We'll also support Android with NDK 10c and later.
For Python we intend to move to Python 3 and drop support for 2.
The change from Fost.3 to 4 was done by a complete rebuild of all of the files from the ground up. That isn't what will happen this time. Instead we'll start to build Fost 5 with the newer compile flags and then start to make the breaking changes that we want. These breaking changes will continue for the first releases of Fost 5 — this appears to be unavoidable given the resources we have to do this work with.
There's a number of changes that are obviously needed even before starting work on anything: Firstly, there's a number of Boost libraries that we can now replace with standard libraries:
It's clear that Fost 5 will continue to require a large part of Boost.
There's also a list of changes we want to make to the libraries as well:
Boost build is a pain, and hard for other people to work with. There's a lot of things I'd like to be able to get out of the build process, but customising Boost build is always a constant frustration. It isn't at all clear that any other build system would be a significant improvement. The only way to really know whether something else is going to be better is to try it out.
SCons looks good in that it's building Python, already a dependency in the build process. But for large projects it's slow, and we use this to build large projects (sometimes hundreds of thousands of build targets). CMake also looks interesting, but extending it will be a nightmare and it's hard to know if it has the features that Fost needs or not, let alone features for things we'd like to do.
It may also be time to look again at testing. C++11's lambda syntax gives a lot of extra flexibility there. It ought to be possible to produce something much closer to a Jasmine style of tests now rather than the current macro based system.
A bigger question hangs over Boost ASIO. Fost 4 doesn't take advantage of the asynchronous features, preferring instead to use threads as building blocks rather than callbacks. This means a certain amount of fighting the API so as to get time outs and blocking working well. What's worse though is the use of OpenSSL — but it isn't at clear what a better alternative would look like. Maybe LibreSSL will become usable across our target platforms in time.