Thursday, February 26, 2009

fbsql: Clean client-libraries for Firebird and Interbase databases

I've written this quite some time ago (and it didn't receive much love since then, but it's functional and should be bug-free), but I just noticed I haven't mentioned it on my blog: fbsql is a clean C-API that can be used to create bindings for other languages (such as Python or Ruby). It's much simpler to use than the raw Interbase/Firebird API and it uses IBPP internally. So it's basically just forwarding the function calls to IBPP and abstracting the IBPP classes to a C interface that is straight forward and intuitive.


I have included a binding to Lisp, since this was my personal main goal with this project. I noticed that there is no way at all to access Interbase and/or Firebird from Lisp, and since I like toying around with Lisp, I thought that writing small database helper applications with it is a good way to get comfortable with it. The Lisp binding has two layers: First is the CFFI that is used to access the native C functions from the fbsql C-library and the second, more lispish layer is a bit more advanced and better to use. It includes thinks like


(with-statement (st database transaction)
(statement-prepare st "select * from table")
(statement-execute st)
(while-statement-fetch st
(format t "~a~%" (statement-get-short st 1))))
This little script creates a statement to the given database and transaction, executes "select * from test" and prints everything value in column 1 (which should be a short).
Lisp is so wonderfully compact. ;-)

Sunday, January 25, 2009

ZeroBUGS: Commercial C++ debugger for Linux

Whenever working with GDB on Linux you get the feeling that it does the basics pretty well (and sometimes even crashes on those basic tasks), but a few things are just missing or too complicated. While GDB is actually a very usable debugger and freely available on virtually any Linux box, it's not 100% stable and sometimes not as high quality as you'd like it to be.


I've just found out about ZeroBUGS, a commercial debugger for Linux (and Linux only!) that's targeted to be better where GDB is lacking. I learned about it from Andrei Alexandrescu's homepage (see the "Zero" link to the left). Although it is a commercial product, there's also a free version available, but it's limited in some ways. ZeroBUGs comes with a GUI and console interface out of the box.


Here's the feature-list, taken from the official site:

  • Command Line

  • Graphical Interface

  • Expression Evaluation

  • Conditional breakpoints

  • Memory watchpoints

  • Compatible with Intel Compiler

  • Works with GCC 2.95 through 4.3

  • Supports pthread applications

  • Debug events can be disabled by thread

  • Support for debugging forked processes

  • Scriptable with Python

  • Support for wide strings and Qt strings

  • Custom visualization of data structures (via Python script)

It does not support remote-debugging, though (but you can of course use SSH or X-Forwarding for this), but I especially like that it's scriptable in Python. It even works together with valgrind, see the FAQ.


The main difference between the free and the commercial version is that the free version is BETA with untested features. Additionally, some functionality is trimmed down (only the Python console is mentioned on the website) and the free version is not optimized for speed. There's no source code of the free version either, so it's only "free as in beer".


The price is as low as $39.95, so it's even affordable to hobbyists when the free version just is not enough. Unfortunately I've never used it (well, I've just found out about it a few minutes ago), but I'll surely try it out next time I'll be working on a bigger Linux-project. I hope I can provide some actual field-experiences with ZeroBUGs anytime soon.

Thursday, January 15, 2009

Bjarne's new book: Programming: Principles and Practice Using C++

I've reported about this book earlier last year. The original release-date was slated for august last year, but it seems it was delayed till last month.


It's in stock at amazon.com now. I think I'm gonna order a copy of it for our trainees at work. There's never enough of good C++ teaching books.

German translation of Firebird security article

There's an article on the Firebird Documentation web-page about Firebird File and Metadata Security. Since this is an interesting topic to our customers, I took the time to translate it to German.


The article describes the fundamental problems in securing network connections. One of the biggest problem is key management. Since the Firebird server is usually controlled by and installed at the client's site, you don't have any control over it. So, theoretically, someone could always build his own Firebird server to spy on the password. But that's only one of the problems discussed.


Many thanks to Geoff Worboys, the author of the original article, and Paul Vinkenoog for publishing it on the official web-site.

Wednesday, December 3, 2008

Embedding Qt Widgets into QtWebKit

Qt has it's awesome built-in WebKit support which makes it extremely easy to have full-featured browser/html-viewer capabilities in your application (including JavaScript!).


It is possible to embedd any Qt Widget into your QWebPage. The necessary steps for that are quite simple. You have to derive from QWebPage and overload the createPlugin() function, make sure that PluginsEnabled is set for the QWebPage's settings and assign that WebPage to any QWebView.


It is now possible to embed widgets that are known to Qt's runtime MetaType-system into a WebView. You can make a widget accessible using both, the Q_DECLARE_METATYPE macro and the qRegisterMetaType function.


To show the widget, you have to add an HTML object-Tag to your page, like this:


<object type="application/x-qt-plugin"; classid="YourClass" name="myObject" />
It's now visible and can even be manipulated through JavaScript. You can access it's properties and it's public slots.


I've create a small demo that shows you how to do it and what is possible. It consists of a QMake-project (.pro-file), two pairs of header and implementation files for the MyWebKit/MyWebPage and MyWidget classes and a demo HTML page. It should compile and run on any supported platform (Windows, Linux, Mac). Of course only when QtWebKit is enabled in the Qt installation.


Step 1


First, we should derive from the necessary QtWebKit-classes to create our own MyWebView class that always has Qt plug-ins enabled.


MyWebKit.h



#ifndef MY_WEBKIT_H
#define MY_WEBKIT_H
#include
#include

// Derive from QWebPage, because a WebPage handles
// plugin creation
class MyWebPage: public QWebPage
{
Q_OBJECT
protected:
QObject *createPlugin(
const QString &classid,
const QUrl &url,
const QStringList ¶mNames,
const QStringList & paramValues);
public:
MyWebPage(QObject *parent = 0);
};

// Derive a new class from QWebView for convenience.
// Otherwise you'd always have to create a QWebView
// and a MyWebPage and assign the MyWebPage object
// to the QWebView. This class does that for you
// automatically.
class MyWebView: public QWebView
{
Q_OBJECT
private:
MyWebPage m_page;
public:
MyWebView(QWidget *parent = 0);
};

#endif


MyWebKit.cpp



#include "MyWebKit.h"

#include

MyWebPage::MyWebPage(QObject *parent):
QWebPage(parent)
{
// Enable plugin support
settings()->setAttribute(QWebSettings::PluginsEnabled, true);
}

QObject *MyWebPage::createPlugin(
const QString &classid,
const QUrl &url,
const QStringList ¶mNames,
const QStringList & paramValues)
{
// Create the widget using QUiLoader.
// This means that the widgets don't need to be registered
// with the meta object system.
// On the other hand, non-gui objects can't be created this
// way. When we'd like to create non-visual objects in
// Html to use them via JavaScript, we'd use a different
// mechanism than this.
QUiLoader loader;
return loader.createWidget(classid, view());
}

MyWebView::MyWebView(QWidget *parent):
QWebView(parent),
m_page(this)
{
// Set the page of our own PageView class, MyPageView,
// because only objects of this class will handle
// object-tags correctly.
setPage(&m_page);
}

It's now possible to use Qt classes using the above-mentioned object tags.


Step 2


The second step is to create a class that's known by the Qt runtime meta type system. We can't directly use Qt widgets in this way, because runtime meta types need copy-
constructors. So we derive from a Qt widget and add a kinda dull copy-constructor to it.

MyWidget.h



#ifndef MY_WIDGET_H
#define MY_WIDGET_H

#include
#include

class MyCalendarWidget: public QCalendarWidget
{
Q_OBJECT
public:
MyCalendarWidget(QWidget *parent = 0);
// Q_DECLARE_METATYPE requires a copy-constructor
MyCalendarWidget(const MyCalendarWidget ©);
};
Q_DECLARE_METATYPE(MyCalendarWidget)


#endif

We use a calendar widget because it's something that doesn't already exist in HTML and could be quite useful. Additionally, it has some few properties that we'd want to access from JavaScript.


Step 3


The final step is to build the HTML page that embeds the widget and executes some JavaScript on it. Here's my example:

Test.html



<html>
<head>
<title>QtWebKit Plug-in Test</title>
</head>
<body>
<object type="application/x-qt-plugin" classid="MyCalendarWidget" name="calendar" height=300 width=500></object>
<script>
calendar.setGridVisible(true);
calendar.setCurrentPage(1985, 5);
</script>
</body>
</html>

The example set the gridVisible property to true and shows the month that I am born in. Of course, the possibilities seem endless! :-)


Conclusion


The only thing that I am still missing is connecting signals to JavaScript functions, similar to what you do with AJAX. It's possible to export non-visual objects and use them from within JavaScript, too (think of a database connection, for example).


You can download the complete project, which should work out-of-the-box when you have Qt with WebKit support installed, here

Friday, September 12, 2008

Nekthuth - Making Vim Love Lisp

My friend DieMumiee pointed me to a project call Nekthuth that is supposed to be a mini-version of slime, just for my beloved Vim. The web-site looks promising, there are even screenshots and short, but good documentation. Using it it's quite easy to get Nekthuth installed and getting started.


However, my current SBCL is kinda broken. Dunno what I did to it, but after an apt-get update it segfaulted while compiling some scripts and just seems defective. I tried Nekthuth anyways, just to experience a broken pipe. Ouch. :-(


So you're invited to test it out and send reports to me and the original author. I'm quite interested in whether this project could become at least a partial slime-replacement and drive more Lispers to use Vim, and make Lisp available to Vimmers.

Monday, September 1, 2008

Google's own browser: Chrome

I usualy don't like blogging about a blog-post, but I'll make an exception for this one:


Philipp Lenssen writes in his blog that he received a comic-book from Google that describes a new, upcoming browser called Chrome. You can read about everything announced in his blog-post. IMHO there's nothing special mentioned in the list, nothing that hasn't been done before. Probably the most "exciting" thing about Chrome is that the tabs are above the address-bar, which basically makes no difference, but looks different to all the other browsers.


My guess about some technical details about Chrome is that it is built using WebKit as it's back-end. More specifically, using QtWebKit from the new Qt 4.4 release. As Google has been a customer of Trolltech for Google Earth and maybe other tools before, QtWebKit is just the best tool to build a browser from-scratch.


Because usually Google-tools are high-quality and sometimes even revolutionary, we probably can expect more than has been mentioned in the comic from the browser. Nobody will give away his secrets before launch, anyways.


Update:There is coverage of this on heise, too: Google Chrome: Google greift Microsoft mit eigenem Browser an, but it's a bit too focused on Internet Explorer, imho. Some more interesting things about the relation of Google to the Mozilla Foundation, how it evolved and how Google Chrome might change it, can be found here. In this article I've been proven right that they use WebKit as their rendering engine. No word on Qt, though. The probably most interesting thing about Chrome is separating browser tabs in individual processes.