In the most recent versions of the Qt SDK it appears as if default support for all databases except SQLite has been removed.
The Qt documentation provides a short write-up on how to re-enable this driver, but it leaves out some important details.
To enable support for the QODBC driver follow these steps:
1. From the Qt Creator Application Launch Start Updater:
Continued after the jump…
I recently installed Internet Explorer 9, and while the browsers interface seems nice, the JavaScript performance in terms of running FormBoss leaves something to be desired: In short, it’s completely unusable.
This was not at all the case in IE 8, and when you consider IE 9 was supposed to be the release that finally fixed JavaScript this is quite disheartening.
As any serious JavaScript programmer can attest to, the irony of IE has always been that in many ways its been more ‘correct’ in terms of standards than the other browsers. That is, what passes in Firefox in terms of JavaScript code fails in IE not because IE is wrong, but because Firefox is so forgiving (and by extension, wrong). This is doubly true when we add a JavaScript library like Prototype JS into the mix, in that the libraries attempts to smooth over browser differences may expose us to subtitle differences in core JavaScript behavior.
On that springs to mind is how some Prototype JS objects property counts are handled. In Firefox an object may be shown to have a length of 1, but in IE that same object had a length of 2. Another example, if memory serves, had to do with valid names of objects. IE has always been more strict in terms of using names that start with numbers, and so on.
Such differences can be hard to spot in production code, and almost always leads to hours of careful testing and debugging.
Thus, as part of my own production process I’d like to share two links that may help you determine if such issues reside in your code or the browser/library begin used.
http://sputnik.googlelabs.com/
This test is very interesting to me as it confirms, among other things, that IE 9′s JavaScript engine is generally more ‘correct’ in terms of standards that the competition. For example, when run in IE 9 I get 71 failed tests, whereas Chrome Canari generates 136 and Firefox 4 181.
In almost all of the cases that ‘fail’ we see the failed test is something the casual JavaScript author may easily do.
For example, in test s12.5_A9_T1 we check for a function declaration within an ‘if’ statement:
// Copyright 2009 the Sputnik authors. All rights reserved.
// This code is governed by the BSD license found in the LICENSE file.
/**
* @name: S12.5_A9_T1;
* @section: 12.5;
* @assertion: Function declaration within an "if" statement is not allowed;
* @description: Declaring function within an "if" statement;
* @negative;
*/
if (true) {
function __func(){};
} else {
function __func(){};
}
testCompleted();
Have I ever done this? No. Could I see others or even me late at night? Sure. The point being that as you peruse some of the test that say, Firefox 4 fails, it becomes obvious that many of the failures stem from Firefox being ‘fast and easy’ with some of the rules, which ironically, can make creating JavaScript code easier.
http://dante.dojotoolkit.org/taskspeed/
This test highlights the differences in the major JavaScript libraries. Of core importance to me are the functions that manipulate the DOM, such as append, insertbefore, insertafter, and so on.
In this post we’ll cover a topic you’ll no doubt run into when dealing with SOAP web services: parsing XML data that uses namespaces via XPath.
As I’m a PHP guy this will be PHP centric in that we’ll use SimpleXML for our parsing needs. The techniques and general ideas presented herein however, are applicable to almost all XML/XPath processing languages.
The Sunspider JavaScript Benchmark is a popular test of Web Browser performance.
As great as the newest browsers are I though it would be interesting to take a random test and port it to C++ for the sake of comparison.
I decided the rather short fannkuch test was a good candidate. The results:
Not surprisingly the C++ version is 18x faster than Firefox and 8x faster than Chrome. For the curious, the ported C++ code is after the jump.
I should mention one thing changed from the stock Sunspider site (e.g., the link above), is the number of iterations was upped from 8 to 10. At 8 iterations the C++ version was sub-millisecond, meaning I’d have had to roll a custom assembly timer to get a benchmark value. That said, when we lower the iterations down to 9, the stack heavy algorithm starts to benefit the browsers more, with Chrome coming in only 3 times slower and Firefox 11.
Lower the iteration count to the “stock” 8 and Firefox actually catches up to Chrome, with both browsers reporting ~21ms. Interesting.
In previous posts we’ve covered Inline Assembly and SSE Intrinsics coding.
In this post we’ll merge these concepts by creating a version of the CMYK to RGB conversion code strictly in raw SSE and assembly. The upshot is you’ll see how we can take existing, real-world C++ code and use GCC’s Extended Assembly syntax to interweave raw assembly code for potential performance gains.
This means this tutorial is not just about extended assembly or sse coding, it’s about using both in a real-world application. We’ll learn many concepts including data retrieval, loop processing, SSE processor instructions, floating point number representation, and much more!
PHP is my favorite language, bare none. It’s simple, elegant, and fun to use. Problem is, for highly trafficked sites it’s a touch slow and can be quite memory hungry. If you’re Facebook this can lead to problems, which is why they invented Hip Hop PHP (HPHP), a collection of tools and technology that turns our slow and hungry PHP code into lean and mean C++.
As a quick comparison I created a simple FormBoss form and ran Apache Bench (ab from the command line), to get a sense of the speed difference between Apache 2.2 and HPHP.
The top two tests are when running our simple .php files, the bottom test is when serving a simple 62 byte .xml file with 100 concurrent users:
**It’s important to note these numbers will be lower when running though a network and calling a database. Also, while other servers like Cherokee can be twice as fast as Apache, HPHP is still nearly twice as fast again.
So yes, qualifications aside, HPHP is very fast indeed.
Sure these numbers are fantastic, but using HPHP means compiling the source from scratch and then using a series of command-line switches to run and manage the compiled PHP code.
No longer–In my spare time I’ve created and now released an open-source front-end UI to HPHP.
Read on to learn more, or just download the files!
This application, while very simple, can be used to measure lag time for various AV equipment, such as projectors, your desktop monitor, and so on.
This application uses the fantastic Qt framework, and as such, is completely open source. Feel free to be change, modify, and redistributed as you see fit.
One of the gripes I have with implementing an MVC design pattern in PHP development is lack of tools to efficiently work on the model, view, and controller at the same time. Taking the MVC path means, like it or not, traversing three times as many windows and editors. It’s just not efficient for the way I want to work. And so, I’ve got an idea…
In this post we’ll review code for connecting a 32-bit Qt application to an SQL Server 2008 R2 instance running on 64-bit Windows 7.