31 May 2010

XML Parsing and Indexing

One of the idea behind GFE ([dje-fe], see previous post) is to be the less intrusive and the most reactive application. A front-end shouldnt need long processes stopping the user about to play, nor any private files written on disk (especially if you want it running from a DVD).
But GFE needs to display informations about currently selected game (from a collection of 10000 items).
Such data exists and is usually available through (big) xml files... They're generated by Mame.exe, or available from the Net (google 'dat file emulator').
Hence the idea to parse like 40 Megs of xml data on the fly (at each run), and index/map the document to avoid keeping the whole file in memory.
After two weeks studying the topic, it's time for conclusions :
  1. Microsoft Xml Pull Parser is fast. Written in .Net, but *correctly* written, it's generally a good tool for your xml needs. It's a pull system, easier to manipulate than SAX, and probably faster (look at XmlTextReader for reference). It takes 750 ms to walk 40 megs of data (8800 records) on my computer.
  2. Unfortunately you can't bookmark the interesting parts of your document with it. We could rely on the line/character pair this parser is returning but then another text parser should extract text blocks from line/characters pairs. Maybe tricky to implement and we'll lose some horsepower in the process.
  3. Note that parsing xml files is easy as long as we don't want document validation or xpath support: state machine only has to handle 10-12 token types, c# is silently handling various character format.
So what ? Why not writing a dedicated indexing-xml-pull-parser ?
Some results after a dozen hour of coding, a custom pull parsing implementation:
  1. It's now as fast as MS XmlTextReader:  first version wasn't :) too much function calls is hitting very hard c# performance (8 times slower than the original !), solution is to pack the whole state machine into a single function: now it's easily indexing  50 Megs of xml per second.
  2. It's able to give file stream position information about each element start and end: during some initialization pass, an indexer stores each record key and location values in a dictionnary, for further fast access.
  3. When GFE needs a particular record info, the dictionnary is requested for the location of the fragment which is read from huge file, and loaded  into memory to be thoroughly parsed. Apparently it's fast enough for 100 random requests per second. It's 100 times enough :)
  4. there is no 4.
This 'works' and fits a particular situation for a particular embedded application: no memory stress, no alien file creation. Currently it's only limited by a minimal support of character types (it's only handling ANSI+unicode).
But definitely it looks like an achievable way to go if you feel somewhat embarassed with existing implementation.
Below is the code source of the main state machine function: contact me for more implementation details.
public TokenType Next(TokenType notifs)
{
_insideElement:
    if (_currentType < TokenType.END_ELEMENT)
    {
        for (; ; )
        {
            //attribute
            switch (_ioBuffer[_bufferIndex])
            {
                case ' ':
                case '\t':
                case '\r':
                case '\n':
                    _bufferIndex++;
                    continue;
                case '>': //end of start element
                    _bufferIndex++;
                    _depth++;
                    goto _beyondElement;
                case '/': //empty element
                    _bufferIndex++;
                    if (_bufferIndex + 1 > _dataLen)
                        PrefetchIO(1);
                    if (_ioBuffer[_bufferIndex] == '>')
                    {
                        _bufferIndex++;
                        _tokenEndOffset = _bytesParsed + _bufferIndex;
                        _currentType = TokenType.END_ELEMENT; //EMPTY ELEMENT ! it starts and ends on the same token
                        if ((notifs & TokenType.END_ELEMENT) != 0)
                            return _currentType;
                        goto _beyondElement;
                    }
                    return DoExpected(">");
                case '\0':
                    if (!FillIOBuffer())
                        return TokenType.END_OF_STREAM;
                    continue;
                default:
                    _currentType = ProcessAttribute((notifs & TokenType.ATTRIBUTE) != 0);
                    if ((notifs & TokenType.ATTRIBUTE) != 0)
                        return _currentType;
                    continue;

            }
        }
    }
//
//beyond element: data, or comment, or pi, cdata
_beyondElement:
    for (; ; )
    {
    _start:
        switch (_ioBuffer[_bufferIndex])
        {
            case ' ':
            case '\t':
            case '\r':
            case '\n':
                ++_bufferIndex;
                continue;
            case '\0':
                if (!FillIOBuffer())
                    return (_currentType = DoEndOfStream());
                continue;
            case '<':
                _tokenStartOffset = _bytesParsed + _bufferIndex;
                ++_bufferIndex;
                for (; ; )
                {
                    switch (_ioBuffer[_bufferIndex])
                    {
                        case '!': //comment, cdata, doctype
                            _bufferIndex++;
                            if (_bufferIndex + 7 > _dataLen)
                                PrefetchIO(7);
                            if ((_ioBuffer[_bufferIndex] == '-') && (_ioBuffer[_bufferIndex + 1] == '-'))
                            {
                                _bufferIndex += 2;
                                ProcessComment();
                                goto _start;
                            }
                            if ((_ioBuffer[_bufferIndex] == '[') && (_ioBuffer[_bufferIndex + 1] == 'C') && (_ioBuffer[_bufferIndex + 2] == 'D') &&
                                (_ioBuffer[_bufferIndex + 3] == 'A') && (_ioBuffer[_bufferIndex + 4] == 'T') && (_ioBuffer[_bufferIndex + 5] == 'A') &&
                                (_ioBuffer[_bufferIndex + 6] == '['))
                            {
                                _bufferIndex += 7;
                                ProcessCData();
                                goto _start;
                            }
                            if ((_ioBuffer[_bufferIndex] == 'D') && (_ioBuffer[_bufferIndex + 1] == 'O') && (_ioBuffer[_bufferIndex + 2] == 'C') &&
                                (_ioBuffer[_bufferIndex + 3] == 'T') && (_ioBuffer[_bufferIndex + 4] == 'Y') && (_ioBuffer[_bufferIndex + 5] == 'P') &&
                                (_ioBuffer[_bufferIndex + 6] == 'E'))
                            {
                                _bufferIndex += 7;
                                ProcessDocType();
                                goto _start;
                            }
                            return DoUnexpected("-");
                        case '?': //pi
                            _bufferIndex++;
                            ProcessPI();
                            goto _start;
                        case '\0':
                            //--- fill data
                            if (!FillIOBuffer())
                                return (_currentType = TokenType.END_OF_STREAM);
                            continue;
                        case '/': //end element 
                            _bufferIndex++;
                            _currentType = ProcessEndElement((notifs & TokenType.END_ELEMENT) != 0);
                            if ((notifs & TokenType.END_ELEMENT) != 0)
                                return _currentType;
                            goto _start;
                        default:  //new element
                            //(notifs & TokenType.START_ELEMENT) != 0);
                            _currentType = ProcessStartElement(true);//always in full as element name may is extremely usefull to get
                            if ((notifs & TokenType.START_ELEMENT) != 0)
                                return _currentType;
                            goto _insideElement;
                    }

                }
            default: //element data. (probably.)
                _currentType = ProcessData((notifs & TokenType.DATA) != 0);
                if ((notifs & TokenType.DATA) != 0)
                    return _currentType;
                goto _start;
        }
    }
}

11 May 2010

GFE: Game FrontEnd (emu frontend)

Hey,

I spent the last months fighting/juggling/coding with WPF. Not the easiest hobby in town, should i mention, anyway: this is GFE.

The idea behind the project is to be able to... Play. No fuss, and more generally minimal settings, to be able to list and launch a vast collection of games: emulated, freeware, flash, choice is vast.

Basically GFE is listing a directory of... things (roms, zip, pics, you tell), probably thousands of them.

Background scanners are trying to match every entry with snapshots and movies (furtherly stats and extra infos from web). And apart from primary enumeration, everything else is asynchronous for a smoother experience.

All settings are guessed from a directory structure passed as application argument or preferably from a gameinfo.xml file.

It's using low level inputs, preferably a joystick, enabling some interaction with GFE running in the background. And it's a WPF project: so all the frontend rendering is done through DirectX and accelerated hardware if available.

OK now, this is the very first version of GFE, and, well: it's usable, but probably not versatile or cute enough. I'm working on that: you can help with suggestions, money, or simple greetings.

Binary:  GFE-0.5.0.zip (45 Ko)
Technical details:
  Windows - .NET 3.5, works on XP and Seven
  Joystick (XInput compatible) or Keyboard
How to run it:
  Modify included GameInfo.xml and use it as the application parameter.
Note: when in background, both LB+RB button (Ctrl+Back) is killing launched app and bring back GFE to front. LB+Y exits GFE.

alimbourg at gmail.com for any question.

This is GFE Emu FrontEnd (yes it's all animated, and video is playing from the selected game):

25 August 2009

Mercurial on Synology

First telnet, and boostrap to install ipkg, classic (look at this and uses this).

Then ipkg install py26-mercurial (many mercurial flavours in repository btw: one for every major python version).

Now mercurial should be installed somewhere in '/opt/bin' (which redirects to '/volume1/@optware/bin'), type hg -v to check this (or maybe hg-2.6 -v as ipkg apparently let me do the symbolic link: ln /opt/bin/hg /opt/bin/hg-2.6).

You need to have some directory ready to hold a code repository, e.g. '//volume1/repos', executing hg init /volume1/repos/testhg will init/create a mercurial dir with (hidden) management files in it.

We could start working in this, as a shared folder on the network (\\diskstation\repos\testhg), or via http (execute cd /volume1/repos/testhg, and hg serv, it mounts an http server on port 8000, accessible via 'http://192.168.0.X:8000' !), or via ssh (through 'ssh://user@192.168.0.x//volume1/repos/testhg') ! So Nice !

I finally choosed the ssh way, to easily secure transaction.

So, now ssh on synology:

Let's activate the service using the web interface.
Test it using kitty or plink with: plink.exe -ssh -2 root@192.168.0.X "set" should print a lot of variables contents.

But, if we execute plink.exe -ssh -2 root@192.168.0.X "hg": it should fail with ash: hg: not found. When the ssh daemon starts a session, it uses only a subset of the usual user environment, so our PATH variable is missing directories, hence cant find hg.

We might override this by editing (vi) /etc/ssh/sshd_config on the synology, to set PermitUserEnvironment yes.
(to restart the ssh daemon after this, type killall sshd and /usr/syno/etc.defaults/rc.d/S95sshd.sh start)
This script mod triggers the execution of a script $HOME/.ssh/environment for each ssh session creation: let's create such (executable) script with the line PATH=/opt/bin:/opt/sbin:$PATH in it.

Now back to plink: we should now be able to execute hg through ssh.

And... Everything should roll from this point :)

(Once in a while, telnet into your box (putty) and ipkg update and ipkg upgrade)

31 July 2009

Obese debug information (sqlite and qtcreator)

SQLite.c is the 'amalgemon' version of the Database: a huge .c file containing all the dependencies to compile SQLite into our projects.

Using GCC, and standard mingw compilation option, we probably all notice the ton of compilation warning telling us that debug infos are too huge to be handled correctly (if you tried that, it's impossible to trace sqlite sources with gdb).
The problem is concerning the embedded debugging information in STABS format: GCC is handling more modern types of debugging info. We just have to tell it to use them (http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html)


in your .pro file (assuming you're using QtCreator), force these flags to be used:

#remove standard debug generation for c files
QMAKE_CFLAGS_DEBUG -= -g
#(*= 'if not present'), force uber debug infos, perfect for gdb
QMAKE_CFLAGS_DEBUG *= -ggdb


No more compilation warning=quickest compilation, and we're now able to trace sqlite.c in gdb... Another win ;-)

Mame 132 and automated avi creation

This is an How-To build a special mame.exe, wich allows some automation from AutoIt.

I needed to find a way to send keys inputs which would trigger AVI recording of my games: but as Mame is using 'raw inputs', it cant be fooled with standard windows messages injection

Fortunately the Mame project is really really (really) easy to modify and build, so i patched some sources to allow that.

First, go there and follow every steps: http://mamedev.org/tools/

Once you get your first build, modify some sources:

Add More Windows Message to allow events from the outside:

Augment raw inputs with incoming windows messages:

Build it and voila. You should have a brand new mame.exe, listening for your external messages.
I have such a binary build available for willing people.
Next post should be an explanation for the whole Mame Avi Move Maker build with AutoIt...
Regards (and eventually leave comments)

30 July 2009

Clutter 1.0.0: Win32/MinGW (updated)

Personal Hack for a win32 build of clutter-1.0.0 libraries.
  • static libraries,
  • interactive.exe and the whole dll package (glib, pango, etc),
  • and a configuration package (prebuild.zip)
In there.
Basically all you need is:

Get Code::Blocks/QtCreator whatever (but a Mingw flavor): http://www.codeblocks.org/downloads/5

Get Clutter-1.0.0, and unzip-it somewhere on your hdd: http://www.clutter-project.org/sources/clutter/1.0/
Get GTK dependencies from http://www.gtk.org/download-windows.html (binaries+dev packages): pango, cairo, glib, gtk+
Get some other Mingw port from http://sourceforge.net/project/showfiles.php?group_id=7382 :
gettext, libiconv

I put all those libraries side by side with clutter-1.0.0.

Concerning mingw, it's likely that the package delivered with cb/qtcreator is outdated:
Get latest mingw API For MS Windows (http://sourceforge.net/projects/mingw/files/ , dev version) and unzip it into your mingw directory
Get latest glext.h (http://www.opengl.org/registry/api/glext.h), to update your probably old \mingw\include\GL\GLext.h.

Now some autoconf stuff:

Get And Unzip prebuild.zip (http://alimbourg.free.fr/clutter-1.0.0) into clutter-1.0.0/build/
It will create some qtcreator\ dir as it's my primary develoment platform, but rename it at will.
The configuration package uses perl (i'm using tinyperl, included in archive) to autoconfigure clutter build, generate marshaling info and glib-enum-typing header files. It makes it ready to compile.
Edit configure.pl to match your installation directories as it needs GLIB for some prebuild steps.
Then, execute configure.bat.

(Finally, it tweaks some qtcreator .pro project files to list every needed source files all the content from clutter\, clutter\COGL, clutter\Pango, clutter\json, clutter\win32: this, of course, has to be done 'by hand' for the other tools)

It's now ready to compile...

27 May 2009

QtCreator Debug Helper...

QtCreator (1.1 for now) is great tool to work with...

The whole Qt thing is, too.

I'm sharing some experience with the beast.

If you need some relevant debug infos concerning the Qt class guts, you need to instruct gdb on how to print them.

It's done via a 'debugging helper': some dll/plugin loaded by gdb on startup.

On my machine they didnt work without a rebuild after each Qt SDK every integration:

  • go to Tools->Options...->Qt4->Qt Versions,
  • check the active Qt SDK, and its path (QT_PATH).
  • *remove* the whole *QT_PATH/qtc-debugging-helper* directory via explorer
  • back to the Options Pane, select the active SDK, and press *Rebuild*
  • go to Options->Debugger->Debugging Helper, check 'Use debugging helper', uncheck 'Use debugging helper from custom location'
  • next time you debug your qt app, you should get some '43 custom... loaded' from gdb