Hi,

Where does the *.xml files containing the fpc documentation live?

Example:
http://lazarus-ccr.sourceforge.net/docs/fcl/contnrs/tobjectlist.html

I looked everywhere in the SubVersion repository mentioned below, and couldn't find anything...
http://svn.freepascal.org/svn/fpc/branches/fixes_2_0/

Regards,
Graeme.

http://svn.freepascal.org/svn/fpcdocs/trunk/

Thanks...

Okay, I found a bit of a problem. I first thought it was just my Web Browser fonts, then thought it must be in the documentation. After looking at the *.xml files, I now think it is in the conversion from *.xml to *.html that the problem gets introduced.

The problem is the spaces between words. Look at the example below taken from the following docs:
http://lazarus-ccr.sourceforge.net/docs/fcl/contnrs/tobjectlist.html

In the first line, there are a few mistakes. No space between "TObjectList" and "is". No space between "TList" and "descendent". etc...

This occurs all over in the FPC documentation. Note though, that it doesn't occur in the Lazarus documentation, which also used the fpdoc *.xml files. Something different in the FPC docs?

------------------------------------
Description

TObjectListis a TListdescendent which has as the default array property TObjectsinstead of pointers. By default it also manages the objects: when an object is deleted or removed from the list, it is automatically freed. This behaviour can be disabled when the list is created.

In difference with TFPObjectList, TObjectListoffers a notification mechanism of list change operations: insert, delete. This slows down bulk operations, so if the notifications are not needed, TObjectListmay be more appropriate.
------------------------------------

Regards,
Graeme.

I think it caused by the way text element after a element with a tag are parsed by the xml reader.

If you have the following xml fragment:
<p>This is <b>bold</b> text.</p>

This should be parsed by the xmlread unit into a p-element with 3 child nodes: a text node, b-element node, and another text node.

function TXMLReader.ParseElementContent parses 'This is <b>bold</b> text.'. Before it starts reading the next node, if first reads all the white space, which should not be done for text nodes, I think.

The reason that you did not see this in the LCL documentation, is because we don't use very much markup and links in the descriptions.

Vincent

I will file a bug report and post all the comments from this thread so it doesn't get forgotten.

Regards,
- Graeme -

Tonight I will update the docs on sf using fpc 2.1.1's fpdoc, it seems to be fixed in that version.

It still seems to be an issue in fpdoc from fpc 2.0.4-rc3. If that is the case, then distros creating the docs from source (maybe the fedora rpms) will have this bug too.

Michael, what version of fpdoc did you use to create the html doc for the release. Because those docs look ok.

Vincent

The latest 2.1.1 fpdoc.

Michael.

I just updated the docs on sourceforge using fpdoc 2.1.1 and I see the issue is fixed in 2.1.1. I will add a note in issues 2.0.4, that due to a bug in xmlread, you cannot create the docs correctly with the 2.0.4 fpdoc.

Vincent

Thanks for the feedback Vincent.

Regards,
- Graeme -

Hi,

How does the process work between 2.0.x and 2.1.1...?

* Experimental things get added to 2.1.1 first.
* I guess after some time those changes are deemed stable.
* Someone has to now port those changes to 2.0.x

Is this correct?
Is so, how do you keep track of what was added to 2.1.1 and not yet to 2.0.x? If I create a bug fix, should I create a patch file against 2.1.1 or 2.0.x ? What is preferred?

Regards,
- Graeme -

First of all, 2.0.x is supposed to serve as fixes branch, so most functional enhancements (especially major ones) are _not_ supposed to be applied there. When talking about fixes, we normally use the Python svnmerge script (search in Wiki for details) to merge the original patch to 2.0.x. If there are conflicts during the merge operation, they may need to be handled manually. However, in most cases the fact that conflicts exist may stem from two things:

1) Other changes weren't merged yet. If these were mostly fixes, one should consider merging them first before the dependent changes.

2) The code started to differ too much due to functional enhancements. If this is the case, you'd basically need to create a different patch than what was used for trunk. However, that means that it may behave differently too, so one should think twice before trying to merge such a fix to the fixes branch.

Tomas

Thanks for the explanation Tomas.

Regards,
- Graeme -