You can download all of the example code I wrote here, Qt Concurrent Examples

Note: I’ll be calling waitForFinished() in a few of my examples. In an actual application where the function your are calling takes some non-insignificant amount of time to return you would probably want to use QFutureWatcher to monitor the status of the QFuture.

QtConcurrent::map Example

QtConcurrent::map is used to iterate over a container or sequence and call a function on each element of the container. It is expected that your function will modify the element it is called upon in some way. In this example I wrote a simple functor that replaces each string with its upper-cased version.

#include <QtConcurrentMap>
#include <QStringList>
#include <QCoreApplication>
#include <functional>
namespace
{
  struct UpcaseString : public std::unary_function<const QString&,void>
  {
    void operator()(QString & str)
      {
        str = str.toUpper();
      }
  };
}

int main()
{
  QStringList strings;
  strings << "foo" <<  "bar" <<  "baz";

  QFuture<void> res = QtConcurrent::map(strings,UpcaseString());
  res.waitForFinished();

  for(QStringList::iterator i = strings.begin(); i != strings.end(); ++i)
    qDebug("%s",qPrintable(*i));

}

And our results,

~/mapreduce/qtconcurrentMapExample $ ./qtconcurrentMapExample
FOO
BAR
BAZ
~/mapreduce/qtconcurrentMapExample $ 

QtConcurrent::mapped Example

QtConcurrent::mapped iterates over a container or sequence and accumulates the results of a function into another sequence. This other sequence, stored in the QFuture, can then be iterated over to retrieve the results.

#include <QtConcurrentMap>
#include <QStringList>
#include <QCoreApplication>
#include <functional>

namespace
{
  struct UpcaseString : public std::unary_function<const QString&,QString>
  {
    QString operator()(const QString & str)
      {
        return str.toUpper();
      }
  };
}

int main()
{
  QStringList strings;
  strings << "foo" <<  "bar" <<  "baz";

  QFuture<QString> res = QtConcurrent::mapped(strings,UpcaseString());
  res.waitForFinished();

  for (QFuture<QString>::const_iterator i = res.begin(); i != res.end(); ++i)
    qDebug("%s",qPrintable(*i));
}

And again, our results,

~/mapreduce/qtconcurrentMappedExample $ ./qtconcurrentMappedExample
FOO
BAR
BAZ
~/mapreduce/qtconcurrentMappedExample $ 

QtConcurrent::mappedReduced Example

And finally a quick example of mappedReduced. The key difference in mappedReduced is that a second function is provided that is used to reduce the intermediate results. In this example I just used a function that concatenates strings; the end result is an upper-cased, concatenated string.

#include <QtConcurrentMap>
#include <QStringList>
#include <QCoreApplication>
#include <functional>

namespace
{
  struct UpcaseString : public std::unary_function<const QString&,QString>
  {
    QString operator()(const QString & str) const
      {
        return str.toUpper();
      }
  };

  void concatStrings(QString & result, const QString & str)
  {
    result += str;
  }
}

int main()
{
  QStringList strings;
  strings << "foo" <<  "bar" <<  "baz";

  QFuture<QString> res = QtConcurrent::mappedReduced(strings,UpcaseString(),&concatStrings);
  res.waitForFinished();

  qDebug("%s",qPrintable(res.result()));
}

And our results,

~/mapreduce/qtconcurrentMappedReduceExample $ ./qtconcurrentMappedReduceExample
FOOBARBAZ
~/mapreduce/qtconcurrentMappedReduceExample $ 

Just load it up and add the following to your .emacs

(require 'qt-pro)
(add-to-list 'auto-mode-alist '("\\.pr[io]$" . qt-pro-mode))

Get it here qt-pro.el

I have WordPress installed, but it should work for any other blogging software with the same XMLRPC interface.

Acquiring weblogger.el

First grab the latest copy of weblogger.el and xml-rpc.el from Savannah. It’s your typical Web-CVS interface, just click the .el file and then click “download”.

Once you’ve gotten both weblogger.el and xml-rpc.el place them somewhere that Emacs can find them. I’ve added ~/.emacs.d/ to my load-path so I placed both weblogger and xml-rpc there. (Note: xml-rpc comes with Emacs 22, so it may not be needed. The version at Savannah is newer though so if you run into any problems get it as well.)

Initial Setup

First you need to load weblogger. I added a require line for weblogger to my ~/.emacs.

; load-path setting is only needed if the directory you put
; weblogger.el in isn't already in your load-path
(add-to-list 'load-path "~/.emacs.d/")

; Load weblogger
(require 'weblogger)

Hit C-x C-e with the cursor after the sexp to evaluate it and load weblogger. Finally weblogger is loaded and you are ready to set it up and post.

First type M-x weblogger-setup-weblog . This will create a profile for posting, saving the username, url, and some settings to your ~/.emacs. You will be asked for the “Server Endpoint (url)” which for WordPress is http://www.server.com/xmlrpc.php.

Posting

You’re now ready to make your first post. Hit M-x weblogger-start-entry to start your first entry. When you are finished hit C-x C-s to save and submit the post. To save your post as a draft without submitting it hit C-c C-c.

Editing Earlier Posts (including Drafts)

To come back to a previous post hit M-x weblogger-fetch-entries. This will open a buffer with your latest entry. You can then move to previous entries with C-c C-p and later entries with C-c C-n.

I did notice a bug though, which may actually be in WordPress’s XMLRPC code. If you use the <!--more--> tag in your post you will not get the entire post when you try to edit the entry in weblogger. You need to remove the tag with the WordPress entry and then editing the post from Emacs will work again.

C++ Standard

The return type of an overriding function shall be either identical to the return type of the overridden function or covariant with the classes of the functions. If a function D::f overrides a function B::f, the return types of the functions are covariant if they satisfy the following criteria:

• both are pointers to classes or references to classes
• the class in the return type of B::f is the same class as the class in the return type of D::f or, is an unambiguous direct or indirect base class of the class in the return type of D::f and is accessible in D
• both pointers or references have the same cv-qualification and the class type in the return type of D::f has the same cv-qualification as or less cv-qualification than the class type in the return type of B::f.

Example Code

And a quick example that uses this feature:

#include <iostream>

// Just create a class, and a subclass
class Foo {};
class Bar : public Foo {};

class Baz
{
public:
  virtual Foo * create()
    {
      return new Foo();
    }
};

class Quux : public Baz
{
public:
  // Different return type, but it's allowed by the standard since Bar
  // is derived from Foo
  virtual Bar * create()
    {
      return new Bar();
    }
};

int main()
{
  Quux *tmp = new Quux();
  Bar *bar = tmp->create();

}

I’ve recently found several forums that have “users” asking how to crack the passwd file found on my site….

American Site (The user seems to think it is a Windows password file)
German Site
Czech Site
Russian Site

scp -q "VIMD72e7.tmp" "host:/path/to/file.txt"
VIMD7E7.tmp: No such file or directory
shell returned 1
Hit any key to close this window...

I think that this is a result of the autochdir option being set. My fix is to do a

:lcd $TEMP

in the buffer with the remote file loaded prior to writing the file. This lets scp find the temporary file and the copy/write succeeds.

Falling Snow Source

;; Swank started at port: 36773.
36773
* 
Process inferior-lisp hangup

From searching, this appears to be a problem with Emacs and my version of the Linux Kernel (2.6.8). The workaround is apparently to set the inferior lisp to “nohup sbcl” which prevents SBCL from receiving the hangup signal. Unfortunately it also redirects STDOUT/STDIN which seems to cause a problem with the SLIME from CVS.

The solution that I’ve found is to start swank (the Lisp portion of SLIME) manually in SBCL.

; Load swank
(load "/path/to/swank-loader.lisp")
 
; Start the swank server
(swank:create-server)

Then in Emacs start SLIME with M-x slime-connect, the defaults of Host: 127.0.0.1 and Port: 4005 should be fine.