Port QAssistant

[Dmitry A. Kuminov]

QAssistant (an online help tool) cannot be built right now because it depends on CLucene (source:/trunk/src/3rdparty/clucene) that needs to be ported to OS/2 itself.

[Silvan Scherrer]

i will take a look at it on friday latest.

[psmedley]

i have this compiling, but not yet linking - failing due to pthread symbols

Trying to force cmake into using pthread.lib now

[Dmitry A. Kuminov]

Paul, you are trying to go the wrong way IMHO. You don't need pthreads, you don't need cmake, you only need to port CLucene to native OS/2 threads. Basically, it's a couple of very simple classes and a bunch of defines. Easily doable (half day max), but I don't want to spend time on it unless we decide we want to have Assistant in the GA.

[Dmitry A. Kuminov]

qtdemo doesn't build because of the absense of the QtHelp and AssistantClient library. Temporarily disabled it in r515. Must be rolled back when Qt Assistant is done.

[Dmitry A. Kuminov]

Also, disabled some examples in r540 (to be rolled back too).

[rudi]

I've hacked that native mutex support into CLucene (Qt 4.5.1 GA). However, Assistant dies a few seconds after starting up with "Killed by SIGABRT". I have not found any register dump or something that helped me to narrow down the problem. Somehow I suspect mmap...

The "old" version pf Assistant (aka Assistant_adp) appears to work.

[Dmitry A. Kuminov]

Could you please provide the patches you hacked in?

[rudi]

Sure. But be aware: this is against 4.5.1 GA. Even though the difference to the 4.6.1 trunk isn't that big, it's not 100% identical...

[rudi]

Just to add: Assistant's behavior on 4.6.1 is identical. It also exits shortly after startup while the first page has been loaded and the progress indicator in the lower left corner is moving stating "Updating search index".

BTW, I had a problem with assistant\lib\lib.pro in 4.6.1: The generated makefile "forgot" to link to CLucene when building QtHelp. For some reason lib.pro adds the import lib to LIBS_PRIVATE, which doesn't seem to work on OS/2. As a quick hack I inserted:

os2:LIBS += -l$$qclucene

but I'm, not so sure that this is the correct way.

[Dmitry A. Kuminov]

Added missing qmake support for LIBS_PRIVATE in r629. Applied your CLucene patches in r630. Enabled QAssistant build in r631.

At first run, assistant.exe worked well. Then I tried to search for something on the Search tab and it crashed and now crashes right at stratup. Investigating.

[Dmitry A. Kuminov]

CLucene uses wchar_t for strings under G++ by default and this is the reason why it crashes: ​http://svn.netlabs.org/libc/ticket/219. I will see if Qt likes when CLucene uses char instead.

[Dmitry A. Kuminov]

Made it like _ASCII in r632 and set this mode on OS/2 by default for now (until wcscmp() is fixed). Assistant seems to work now and I can even perform full text search. I couldn't test non-ASCII search though since I don't have non-English documents so far but at least I changed the Qt functions to use the local 8-bit encoding when converting from/to CLucene's TCHAR in _ASCII mode instead of just using ASCII so theoretically it should work (I'll try it later).

Remaining things are enabling building the documentation and enabling the qtdemo application and a bunch of examples.

[Dmitry A. Kuminov]

Reverted r515 and r540 to enable related demos and examples. qtdemo now builds and it looks really impressive.

The help/remotecontrol example has some problems (inter-process communication) which may indicate some bug in Qt. Will investigate this before the release.

[Dmitry A. Kuminov]

The remotecontrol application shows exactly the same problem as QSynth (#124) -- an attempt to create a QSocketNotifier on a stdin handle makes it almost hang. Note that in remotecontrol they also, like in QSynth, use a special code path for Windows. I will investigate why QSocketNotifier is getting 99% CPU load in the first place.

[Dmitry A. Kuminov]

Okay, it seems to be pretty clear: select() in kLIBC doesn't work with the OS/2 file handles which stdin/stdout/stderr are. As a result, select() is getting constantly called in a tight loop (after immediately returning EINVAL each time) which explains the high CPU load.

I can't fix select() in kLIBC but I can at least make it not eat all the CPU.

[Dmitry A. Kuminov]

Or, to be exact make it not completely freeze the system. Now, it issues a warning to the console and a DosSleep() after each failure which at least lets the user close the application (r643). This also resolves #124.

[Dmitry A. Kuminov]

The problem in assistant is fixed in r647. This defect may be closed now.