The Grantlee community is pleased to announce the release of Grantlee version 0.3 (Mirror). Source and binary compatibility are maintained as with all previous releases. Django is an implementation of the Django template system in Qt.
This release builds with both Qt 5 and Qt 4. The Qt 5 build is only for transitional purposes so that a downstream can get their own code built and working with Qt 5 without being first blocked by Grantlee backward incompatible changes. The Qt 5 based version of Grantlee 0.5.0 should not be relied upon as a stable interface. It is only there to assist porting. There won’t be any more Qt 4 based releases, except to fix build issues if needed.
The next release of Grantlee will happen next week and will be exclusively Qt 5 based. It will have a small number of backward incompatible changes, such as adding missing const and dropping some deprecated stuff.
The minimum CMake required has also been increased to version 2.8.11. This release contains most of the API for usage requirements and so allows cleaning up a lot of older CMake code.
Also in this release is a small number of new bug fixes and memory leak plugs etc.
With many people using the SIP stack in both open source and commercial projects, the migration was carefully planned and tested over an extended period of time. Hopefully some of the experience from this migration can help other projects too.
Previous SVN committers were tracked down using my script for matching emails to Github accounts. This also allowed us to see their recent commits on other projects and see how they want their name and email address represented when their previous commits in SVN were mapped to Git commits.
For about a year, the sync2git script had been run hourly from cron to maintain an official mirror of the project in Github. This allowed people to test it and it also allowed us to start using some Github features like travis-CI.org before officially moving to Git.
At the cut-over, the SVN directories were made read-only, sync2git was run one last time and then people were advised they could commit in Git.
Canonical has announced that a couple of curl vulnerabilities have been found and fixed in its Ubuntu 14.04 LTS, Ubuntu 12.04 LTS, and Ubuntu 10.04 LTS operating systems.
The developers have released a new update for the curl package and it looks like a number of security issues have been corrected.
“Tim Ruehsen discovered that curl incorrectly handled partial literal IP addresses. This could lead to the disclosure of cookies to the wrong site, and malicious sites being able to set cookies for others,” reads the security notice.
Equally, I am not at all sold that “we have knowledge of [the server environment] and can author your program accordingly so it will execute as anticipated” when doing server development. Or, at least, that’s possible, but nobody does. If you doubt this, I invite you to go file a bug on any server-side app you like and say “this thing doesn’t work right for me” and then add at the bottom “oh, and I’m running FreeBSD, not Ubuntu”. The response will occasionally be “oh really? we had better get that fixed then!” but is much more likely to be “we don’t support that. Use Ubuntu and this git repository.” Now, that’s a valid approach — we only support this specific known configuration! — but importantly, on the web Aaron sees requiring a specific browser/OS combination as an impractical impossibility and the wrong thing to do, whereas doing this on the server is positively virtuous. I believe that this is no virtue. Dismissing claims of failure with “well, you should be using the environment I demand” is just as large a sin on the server or the desktop as it is in the browser. You, the web developer, can’t require that I use your choice of browser, but equally you, the server developer, shouldn’t require that I use your particular exact combination of server packages either. Why do client users deserve more respect than server users? If a developer using your server software should be compelled to go and get a different server, how’s that different from asking someone to install a different web browser? Sure, I’m not expecting someone who built a server app running on Linux to necessarily also make it run on Windows (although wise developers will do so), but then I’m not really expecting someone who’s built a 3d game with WebGL to make the experience meaningful for someone browsing with Lynx, either.
Perhaps though you differ there, gentle reader. That the web is the web, and one should have a meaningful experience (although importantly not necessarily the same meaningful experience) which ever class of browser and device and capability one uses to get at the web. That is a very good point, one with which I have a reasonable amount of sympathy, and it leads me on to the final part of the argument.
For the tl;dr: Docker FDW is a thing.
Star it, hack it, try it out. File bugs, be happy. If you want to see what it's
like to read, there's some example SQL down below.
The question is first, what the heck is a PostgreSQL Foreign Data Wrapper?
PostgreSQL Foreign Data Wrappers are plugins that allow C libraries
to provide an adaptor for PostgreSQL to talk to an external database.
Some folks have used this to wrap stuff like
MongoDB, which I always found
to be hilarous (and an epic hack).
During my time at PyGotham, I saw a talk from
Wes Chow about something called
Multicorn. He was showing off some really neat
plugins, such as the git revision history of CPython, and parsed logfiles
from some stuff over at Chartbeat. This basically blew my mind.
All throughout the talk I was coming up with all sorts of things that I wanted
to do -- this whole library is basically exactly what I've been dreaming
about for years. I've always wanted to provide a SQL-like interface
into querying API data, joining data cross-API using common crosswalks,
such as using Capitol Words to query for
Legislators, and use the
to JOIN against the congress api
to get their Twitter account names.
My first shot was to Multicorn the new
Open Civic Data API I was working on, chuckled
and put it aside as a really awesome hack.
It wasn't until tianon connected the dots for me
and suggested a Docker FDW did I get really excited.
Cue a few hours of hacking, and I'm proud to say -- here's
Currently it only implements reading from the API, but extending this to allow
for SQL DELETE operations isn't out of the question, and likely to be
implemented soon. This lets us ask all sorts of really interesting
questions out of the API, and might even help folks writing webapps
avoid adding too much Docker-aware logic.
Setting it up
I'm going to assume you have a working Multicorn, PostgreSQL and Docker setup
(including adding the postgres user to the docker group)
So, now let's pop open a psql session. Create a database (I called mine
dockerfdw, but it can be anything), and let's create some tables.
Before we create the tables, we need to let PostgreSQL know where our
objects are. This takes a name for the server, and the Python importable
path to our FDW.
Now that we have the server in place, we can tell PostgreSQL to create a table
backed by the FDW by creating a foreign table. I won't go too much into the
syntax here, but you might also note that we pass in some options - these are
passed to the constructor of the FDW, letting us set stuff like the Docker
And, now that we have tables in place, we can try to learn something about the
Docker containers. Let's start with something fun - a join from containers
to images, showing all image tag names, the container names and the ip of the
container (if it has one!).
Success! This is just a taste of what's to come, so please feel free to hack on
tweet me @paultag, file bugs / feature requests.
It's currently a bit of a hack, and it's something that I think has
long-term potential after some work goes into making sure that this is a rock
solid interface to the Docker API.