Re: [fpc-devel] fpdoc path + system.uitypes problems.
On Fri, 29 Dec 2023, Marco van de Voort via fpc-devel wrote: Op 27/12/2023 om 13:37 schreef Marco van de Voort via fpc-devel: - The short description in the overview (#rtl) page still doesn't appear , After some debugging, my guess is that in this specific case the path chopping code in TDocNode.CreateChildren at dglobals:455 and further is to blame. The tag gets chopped up, and a node is made with name "system" not "system.uitypes" I will have a look. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc path + system.uitypes problems.
Op 27/12/2023 om 13:37 schreef Marco van de Voort via fpc-devel: - The short description in the overview (#rtl) page still doesn't appear , After some debugging, my guess is that in this specific case the path chopping code in TDocNode.CreateChildren at dglobals:455 and further is to blame. The tag gets chopped up, and a node is made with name "system" not "system.uitypes" ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc path + system.uitypes problems.
Op 26/12/2023 om 19:53 schreef Michael Van Canneyt via fpc-devel: If you say so. It is still ambiguous though, even if most common cases can disambiguated. (a.b.c.d is either symbol d in unit b.c or field d in structure type c in unit b), which is why I didn't favor it. Can you explain what the exact problem is with system.uitypes other than that the description file was not included in the build project xml ? It was that mostly, I retested it, but missed that you hadn't committed that. I built the docs with it and it is as complete as can be expected. All works as it is supposed to work, links and all. But not everything is ok. - The short description in the overview (#rtl) page still doesn't appear , - the unit description seems to be replaced by some copyright text rather than the description in the XML I'll see if I can play with that. I removed it again from the build project (commented out the relevant entries), since the xml file is horribly incomplete, and we only include completed units in the docs. Maybe that is a good policy in the general case, but with core types as TColor and -Rec that hinders lazarus. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc path + system.uitypes problems.
On Tue, 26 Dec 2023, Marco van de Voort via fpc-devel wrote: Op 26/12/2023 om 19:53 schreef Michael Van Canneyt via fpc-devel: Can you explain what the exact problem is with system.uitypes other than that the description file was not included in the build project xml ? I built the docs with it and it is as complete as can be expected. All works as it is supposed to work, links and all. See the link I posted to the daily snapshot. The lemmas of the symbols exist but only contain the declaration, no information whatsoever from the XML. Not even the short description of the unit on the main contents page. Don mostly clicked through because of the TColor description. Well, I can't reproduce it. The relevant texts are there when I generate the HTML documentation with the latest trunk version of fpdoc. Most likely the fpdoc version on idefix used to generate the daily docs needs to be updated. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc path + system.uitypes problems.
Op 26/12/2023 om 19:53 schreef Michael Van Canneyt via fpc-devel: Can you explain what the exact problem is with system.uitypes other than that the description file was not included in the build project xml ? I built the docs with it and it is as complete as can be expected. All works as it is supposed to work, links and all. See the link I posted to the daily snapshot. The lemmas of the symbols exist but only contain the declaration, no information whatsoever from the XML. Not even the short description of the unit on the main contents page. Don mostly clicked through because of the TColor description. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc path + system.uitypes problems.
On Tue, 26 Dec 2023, Marco van de Voort via fpc-devel wrote: Op 26/12/2023 om 18:20 schreef Michael Van Canneyt via fpc-devel: To fix this either we have to e.g. keep a list of packages and a list of units and then try to disambiguate to only pick the longest match. That maybe have risks that other corner cases be found or that the list of units is not yet complete at any point when this system is inside fpdoc. This requires no changes to the .xmls This is the road to take. It's similar to what the compiler does, after all. Not the easiest, not the safest, if at any time during the fpdoc run, the complete list of units is available. The complete list is always available. If you say so. It is still ambiguous though, even if most common cases can disambiguated. (a.b.c.d is either symbol d in unit b.c or field d in structure type c in unit b), which is why I didn't favor it. Can you explain what the exact problem is with system.uitypes other than that the description file was not included in the build project xml ? I built the docs with it and it is as complete as can be expected. All works as it is supposed to work, links and all. I removed it again from the build project (commented out the relevant entries), since the xml file is horribly incomplete, and we only include completed units in the docs. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc path + system.uitypes problems.
Op 26/12/2023 om 18:20 schreef Michael Van Canneyt via fpc-devel: To fix this either we have to e.g. keep a list of packages and a list of units and then try to disambiguate to only pick the longest match. That maybe have risks that other corner cases be found or that the list of units is not yet complete at any point when this system is inside fpdoc. This requires no changes to the .xmls This is the road to take. It's similar to what the compiler does, after all. Not the easiest, not the safest, if at any time during the fpdoc run, the complete list of units is available. The complete list is always available. If you say so. It is still ambiguous though, even if most common cases can disambiguated. (a.b.c.d is either symbol d in unit b.c or field d in structure type c in unit b), which is why I didn't favor it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc path + system.uitypes problems.
On Tue, 26 Dec 2023, Marco van de Voort via fpc-devel wrote: Op 26/12/2023 om 10:29 schreef Michael Van Canneyt via fpc-devel: To fix this either we have to e.g. keep a list of packages and a list of units and then try to disambiguate to only pick the longest match. That maybe have risks that other corner cases be found or that the list of units is not yet complete at any point when this system is inside fpdoc. This requires no changes to the .xmls This is the road to take. It's similar to what the compiler does, after all. Not the easiest, not the safest, if at any time during the fpdoc run, the complete list of units is available. The complete list is always available. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc path + system.uitypes problems.
Op 26/12/2023 om 10:29 schreef Michael Van Canneyt via fpc-devel: To fix this either we have to e.g. keep a list of packages and a list of units and then try to disambiguate to only pick the longest match. That maybe have risks that other corner cases be found or that the list of units is not yet complete at any point when this system is inside fpdoc. This requires no changes to the .xmls This is the road to take. It's similar to what the compiler does, after all. Not the easiest, not the safest, if at any time during the fpdoc run, the complete list of units is available. A more definitive choice is to change something about the notation and somehow replace or escape dots within identifiers. like rtl.#system.uitypes#.recordtype.fieldname or like The # notation is already taken to indicate a fully qualified name. At the start yes, I remembed that when I looked in the sources yesterday, but another escapes character can be used, it doesn't invalidate the principle. rtl.system#uitypes.recordtype.fieldname or rtl.system..uitypes.recordtype.fieldname. (exact characters to be used T.b.d. Only requires changes to the XML for dotted unit names. and everything referring to it since any cross-reference would also need to be changed. True, but how many references are there already to dotted units? Not yet that much. It looked me the easiest short term doable one. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc path + system.uitypes problems.
On Mon, 25 Dec 2023, Marco van de Voort via fpc-devel wrote: (forum thread: https://forum.lazarus.freepascal.org/index.php/topic,65629.0.html) Don noticed that the system.uitypes lemma's in the CHM are empty, both with 3.2.x as 3.3.x fpdoc. I checked the only html snapshot and it is the same: https://www.freepascal.org/daily/doc/rtl/system.uitypes/index-5.html I can remember that I tried to debug this a while back, and that this is a fundamental problem of fpdoc because it uses dots to separate the parts of a lemma. (e.g. packagename.unitname.recordtype.fieldname). Separating a path on dot then breaks the unit name. If unit name is system.uitypes.somevariable, it tries to find symbol uitypes in system, and then searches for a field in somevariable etc. This obviously needs to be extended. dotted unit names didn't exist when fpdoc was made. To fix this either we have to e.g. keep a list of packages and a list of units and then try to disambiguate to only pick the longest match. That maybe have risks that other corner cases be found or that the list of units is not yet complete at any point when this system is inside fpdoc. This requires no changes to the .xmls This is the road to take. It's similar to what the compiler does, after all. A more definitive choice is to change something about the notation and somehow replace or escape dots within identifiers. like rtl.#system.uitypes#.recordtype.fieldname or like The # notation is already taken to indicate a fully qualified name. rtl.system#uitypes.recordtype.fieldname or rtl.system..uitypes.recordtype.fieldname. (exact characters to be used T.b.d. Only requires changes to the XML for dotted unit names. and everything referring to it since any cross-reference would also need to be changed. I will have a look this week, I have holidays so I have some time. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
