Last night I added binary index support to the CHM package, and regenerated all CHM packages, and packaged a new snapshot (nr 7)

http://www.stack.nl/~marcov/doc-chm.zip

note that Michael is currently updating the docs for 2.4.0, and he hasn't committed the bulk of the changes yet, so these don't differ that much from the last snapshot (nr 6).

I noticed that while kchmviewer (4.0/linux) loads the index noticably faster (startup in 1-2 sec), it has some limitation with big indexes (rtl, lcl). I already notified the author, but I don't know if kchmviewer has some way to override binary index loading.

kchmviewer 4.1 on windows is slower (slower treeview?) and has the same bug.

For the time being I added some switches to fpdoc to disable CHM binary toc/indexing:

--no-bintoc disables the binary TOC
--no-binindex disables the binary Index.

Remarks, suggestions etc, can be directed to me. I assume Andrew is already updating LView :-)

Marco van de Voort wrote

Last night I added binary index support to the CHM package, and regenerated all CHM packages, and packaged a new snapshot (nr 7)

What exactly is included - RTL, FCL and LCL help? Any of the language reference, programmer reference documentation, or is the snapshot only limited to class library help?

I've been working this weekend on a LaTeX to INF converter so the programmers & language reference documentation can be converted to INF. I'm implementing it as a table lookup design so tweaking the INF output should not require much in code changes.

No worries, I downloaded the snapshot and saw the prog and ref docs are included too.

All. Fpdoc also.

I just fixed the textmode IDE to use binindex, and as expected, index loading speed did not improved much. The slowliness is probably in the sorting of the index, and the many times copying of the result as part of the helpsystem abstraction.

Also the index with its 40000+ keywords is pretty non navigatable in the textmode ide (which renders it as a two column table with 20000 entries).

Hi, I have updated lhelp locally but I need to make a define so that lhelp will not try to use the new methods if an older fpc is used.

What define can I use?

{$if (fpc_version=2) and (fpc_release>5) ((fpc_version=1) and
(fpc_release=5) and (fpc_patch>1))} ?

Regards,

Andrew

I saw,thanks. Now how do you enable CHM help in the Lazarus IDE? I want to use the RTL, FCL, LCL and Lang Ref CHM help so that when I press F1 over a method, or language keyword, my preferred CHM help viewer is loaded with the correct help displayed.

BTW:
The 'prog' and 'ref' CHM help doesn't look so nice formatting wise, plus many hyperlinks are "fake" and go nowhere when clicked. But I guess this is not the CHM help's fault, but rather the same old problem of a shitty LaTeX to HTML converter - similar formatting issues as in the online help.

Good news for you at least, is that you have some converted to HTML and then CHM. I have to write my own converter from LaTeX to IPF (and then compile to INF). :-( Why has nobody here written a decent LaTeX to HTML converter?

So far only the lcl rtl and fcl chms are supported. To enable chm support all you have to do is install

components/chm/packages/idehelp/chmhelppkg.lpk

In recent versions of lazarus this is all that's needed. In older versions there is a README.txt in components/chm/ that explains it.

I highly recommend the latest version of lazarus to get the most stable chm help.

There are some instructions here as well
http://wiki.lazarus.freepascal.org/IDE_Development#Builtin_CHM_help

Regards,

Andrew

No, since 2.4.2 might have it.

Untested:

{$define donthaveit}
{$ifndef ver2_2}
{$if FPC_FULLVERSION > 204000}
  {$undef donthaveit}
{$endif}
{$endif}

http://bugs.freepascal.org/view.php?id=11568

I don't know if the ifndef is necessary.

Afaik the hyperlinks are generally ok. However that is in the textmode IDE that cuts all label information (since the helpsystem abstraction doesn't deal with labels)

Good news for you at least, is that you have some converted to HTML and then CHM. I have to write my own converter from LaTeX to IPF (and then compile to INF). :-( Why has nobody here written a decent LaTeX to HTML converter?

Because LaTeX is more than simple markup. Afaik LaTeX is Turing complete, and thus more a programming language.

Please don't keep in the dark any longer.

Benchmarks, benchmarks of binindex !!! :-)

Marco van de Voort wrote

Please don't keep in the dark any longer. Benchmarks, benchmarks of binindex !!! :-)

okay here are my benchmarks :)

AMD Athlon(tm) 64 Processor 3500+ 2200MHZ

Start ==== fcl.chm
Text Toc read time: 00.116
Bin Toc read time: 00.021
Text Index read time: 00.176
Bin Index read time: 00.020
Finish ==== fcl.chm

Start ==== lcl.chm
Text Toc read time: 00.215
Bin Toc read time: 00.193
Text Index read time: 01.176
Bin Index read time: 00.375
Finish ==== lcl.chm

Start ==== rtl.chm
Text Toc read time: 00.228
Bin Toc read time: 00.158
Text Index read time: 00.357
Bin Index read time: 00.155
Finish ==== rtl.chm

It's alot faster :) congratulations! Especially noticeable on large files.

I used the attached program to test.

Regards,

Andrew

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed... Name: project1.lpr
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20091011/570141ae/attachment-0001.ksh>

Marco van de Voort wrote

Afaik the hyperlinks are generally ok. However that is in the textmode IDE that cuts all label information (since the helpsystem abstraction doesn't deal with labels)

No, I was using GnoCHM under Linux. All headings are hyperlinks (eg: 3.4 Pointers), but they seem to be pointing to themselves. So quite pointless being hyperlinks.

Because LaTeX is more than simple markup. Afaik LaTeX is Turing complete, and thus more a programming language.

Hey, programming languages are parsed, so LaTeX should be too. ;-) So far I can parse and convert some basic latex files and produce relatively ok looking INF help from them. As soon as I added more lookup rules, I'll attempt the more complex latex files like ref.tex

Oh, I always skip that one. Took 40 seconds to open the LCL, and I never tried again.

All headings are hyperlinks (eg: 3.4 Pointers), but they seem to be pointing to themselves. So quite pointless being hyperlinks.

Still yes. That is a minor problem of the html converter I guess.

Maybe it can be made of use, e.g. convert them into alinks when they are supported. Then such "pointers" link will refer to all "pointers" keywords by means of a popup. Across helpfiles.

> Because LaTeX is more than simple markup. Afaik LaTeX is Turing complete, > and thus more a programming language. Hey, programming languages are parsed, so LaTeX should be too. ;-)

Parsing in the direction they are meant, or translating to a different abstraction is hard.

A C preprocessor can parse header files, but without knowing the usage of the header, I can't even guess the meaning of some stuff there (and that is fundamental, not lack of C knowledge!)

So far I can parse and convert some basic latex files

^^^^^

If you sufficiently dumb things down, there are never any problems:-) But that is not the problem in the case of latex->html conversion. That was the general case.

and produce relatively ok looking INF help from them. As soon as I added more lookup rules, I'll attempt the more complex latex files like ref.tex

We'll see what you come up with. When can we expect something?

[...]

Start ==== rtl.chm Text Toc read time: 00.228 Bin Toc read time: 00.158

I love comparisons. :-) Here are some of my tests results for the OS/2 INF help file format using my INF help viewer implementation. I got todays FPC & Docs from subversion and generated INF help for the RTL and FCL. I still can't generate LCL help because the fpdoc's IPF output has quite a few formatting errors and kills the wipfc help compiler. FPDOC also doesn't generate index support for IPF output, so no Index timing either. I'll try and fix both these issues during this week. I'm keen to see the LCL timings because it is quite a bit bigger compared to the RTL and FCL.

Anyway, here is what I have. Table of Content reading for RTL and FCL

---------------------------------------------
On system is a AMD Athlon(tm) 3000+ 1830Mhz

Start ==== fcl.inf
TOC reading plus word dictionary population - read time: 00.003

Start ==== rtl.inf
TOC reading plus word dictionary population - read time: 00.008 ---------------------------------------------

INF file sizes are as follows:
---------------------------
$ ls -hl *.inf
total 2.1M
-rw-r--r-- 1 graemeg graemeg 458K 2009-10-11 23:30 fcl.inf -rw-r--r-- 1 graemeg graemeg 1.7M 2009-10-11 23:30 rtl.inf ---------------------------

I then wanted to know how long would it take to load the TOC, word dictionary and INDEX, and then build and display the TOC in a treeview, including displaying the first topic (help page) from the treeview. This is what the end-user would experience after all. ---------------------------------------------
fcl.inf read & display time: 00.098

rtl.inf read & display time: 00.140
---------------------------------------------

What's interesting about this is that even though the RTL is 3.7x larger than FCL in file size, it doesn't take that much longer to load and display.

Here are some more details regarding each INF file and the data they contain.

Filename: fcl.inf (458Kb)
Title: Free Pascal Component Library
Dictionary word count: 3774
Topic count: 1268
Index count: 0

Filename: rtl.inf (1.7Mb)
Title: Free Pascal Runtime Library
Dictionary word count: 12960
Topic count: 3491
Index count: 0

That's all I had installed on this system. My work PC as 'lhelp' and something else - SeeCHM (or something like that), but the latter doesn't have Index or Bookmark support.

If you sufficiently dumb things down, there are never any problems:-) But

Hey, you have to start simple and work your way up. I don't want to discourage myself on day one! :-)

We'll see what you come up with. When can we expect something?

The INF viewer is quite workable at the moment - just the richtext viewer component that needs a bit more tweaking. I hope get around to fixing fpdoc's IPF output this week.

Hmm, less than I thought. Probably this is because we build the chmsitemap abstraction back. For now, I'm not running makeskel on the various Windows and OS X headers.

btw getbinaryindex/toc now have a boolean (default) parameter to force XML.

Btw, do not forget to test lview on Windows. Kchmviewer was horrible slow there (compared to the same version on fedora core), and I suspect the commctrl treeview widget, which is a known bottleneck, also in Delphi circles.

2009/10/12 Marco van de Voort :

But that shouldn't make a difference to his timing results published? His test application did not use any GUI components, so timing results should stay the same on whatever platform is used.

The treeview in lazarus is a custom component and does not use the native treeview.

Also I have no windows to test on :)

Regards,

Andrew

True, but not factoring in treeview slowliness would make that a pretty useless timing.

But I actually hoped to provoke some response from sb more knowledgable in Lazarus about the state of the win32 treeview widget :-)

And it seems it is ok.

Zitat von Marco van de Voort :

The lazarus TTreeView is custom drawn and you can add about 100.000 nodes per second. The main work is the measurement of the width/height of each node, which is needed for the scrollbars.
So far I only tested trees with about 300.000 nodes and speed was ok. Just make sure you use BeginUpdate/EndUpdate.
For bigger trees you should consider adding/deleting the nodes on expand/collapse.

Mattias