Re: [fpc-devel] [patch] fpdoc linear writer ResolveLink fix
Op 2010-08-26 21:17, Marco van de Voort het geskryf: What is the pos() case meant to solve? If relative link starts with the current modules unit name, then try package.relativelink? I did some tests and compared output files generated. I only found 4 incorrectly resolved links in the current fpdoc version (RTL docs, dos unit). Removing the if pos(..)=1 block fixes the problem. Other than than, RTL, FCL and fpGUI documentation output was all identical. On a side note, the current version (timed with EpicTimer) was slightly fast because it needs to do less recursive calls, but the difference was only a few milliseconds in each case. I attached a patch to the original bug report to remove the if pos(..)=1 check. http://bugs.freepascal.org/view.php?id=17276 Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpc docs have hidden documentation
Hi In the case of Classes unit documentation - more specifically the TThread documentation. The default behaviour when making RTL documentation, is for it to hide/exclude the protected section from the docs. This includes the TThread.Execute and TThread.Synchronize methods, which actually has documentation elements in the classes.xml file. Now the problem is, some other areas of TThread docs reference the documentation of TThread.Execute and TThread.Synchronize. Because they are protected, they are excluded from the docs - causing unresolved links. Should we just ignore this problem? All documentation output formats are affected. Take a look at this URL, and the link right at the bottom of the page. TThread.Execute points to nothing specific, but TThread itself. http://www.freepascal.org/docs-html/rtl/classes/tthread.html That's one example, there are about 6 or so of them. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc docs have hidden documentation
On Fri, 27 Aug 2010, Graeme Geldenhuys wrote: Hi In the case of Classes unit documentation - more specifically the TThread documentation. The default behaviour when making RTL documentation, is for it to hide/exclude the protected section from the docs. This includes the TThread.Execute and TThread.Synchronize methods, which actually has documentation elements in the classes.xml file. Now the problem is, some other areas of TThread docs reference the documentation of TThread.Execute and TThread.Synchronize. Because they are protected, they are excluded from the docs - causing unresolved links. Should we just ignore this problem? We should not, but it's hard to give a satisfactory solution. It is, in fact, a known problem since quite some time. The only thing I can come up with is a 'ignorevisibility' attribute in the description file's element tag for methods that you do want shown. But it then requires 2 passes in the documentation generator for protected/private sections. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] fpdoc linear writer ResolveLink fix
In our previous episode, Graeme Geldenhuys said: What is the pos() case meant to solve? If relative link starts with the current modules unit name, then try package.relativelink? I did some tests and compared output files generated. I only found 4 incorrectly resolved links in the current fpdoc version (RTL docs, dos unit). Removing the if pos(..)=1 block fixes the problem. Maybe. But it seems to effectively disable module.identifier resolution (for modulecurrentmodule). So while it may not be the most used functionality, the question is why it must be (effectively) removed. Other than than, RTL, FCL and fpGUI documentation output was all identical. On a side note, the current version (timed with EpicTimer) was slightly fast because it needs to do less recursive calls, but the difference was only a few milliseconds in each case. Did you compare html? It has own code for a lot, and you changed this in dglobals, not some dwlinear/ipf only module. I attached a patch to the original bug report to remove the if pos(..)=1 check. I'll look at stuff tonight or somewhere during the weekend. Could you btw explain the logic behind the canweexit hack? I don't fully understand why underscores are now equal to points. Won't this cause problems for people that use unit names with underscores? If this is an IPF limitation, why is it done to a global module? Specially if users are using whole words like generics_collection or something else whose fragments might clash with other identifiers now. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] fpdoc linear writer ResolveLink fix
On Fri, 27 Aug 2010, Marco van de Voort wrote: In our previous episode, Graeme Geldenhuys said: What is the pos() case meant to solve? If relative link starts with the current modules unit name, then try package.relativelink? I did some tests and compared output files generated. I only found 4 incorrectly resolved links in the current fpdoc version (RTL docs, dos unit). Removing the if pos(..)=1 block fixes the problem. Maybe. But it seems to effectively disable module.identifier resolution (for modulecurrentmodule). So while it may not be the most used functionality, the question is why it must be (effectively) removed. It was never supported in the first place. There were only 2 supported ways: - #package.module.identifier - identifier module.identifier was never supposed to work. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc docs have hidden documentation
Am 27.08.2010 13:11, schrieb Michael Van Canneyt: On Fri, 27 Aug 2010, Graeme Geldenhuys wrote: Hi In the case of Classes unit documentation - more specifically the TThread documentation. The default behaviour when making RTL documentation, is for it to hide/exclude the protected section from the docs. This includes the TThread.Execute and TThread.Synchronize methods, which actually has documentation elements in the classes.xml file. Now the problem is, some other areas of TThread docs reference the documentation of TThread.Execute and TThread.Synchronize. Because they are protected, they are excluded from the docs - causing unresolved links. Should we just ignore this problem? We should not, but it's hard to give a satisfactory solution. It is, in fact, a known problem since quite some time. The only thing I can come up with is a 'ignorevisibility' attribute in the description file's element tag for methods that you do want shown. But it then requires 2 passes in the documentation generator for protected/private sections. Out of curiosity: Why is the protected section excluded in the RTL documentation? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc docs have hidden documentation
On Fri, 27 Aug 2010, Sven Barth wrote: Am 27.08.2010 13:11, schrieb Michael Van Canneyt: On Fri, 27 Aug 2010, Graeme Geldenhuys wrote: Hi In the case of Classes unit documentation - more specifically the TThread documentation. The default behaviour when making RTL documentation, is for it to hide/exclude the protected section from the docs. This includes the TThread.Execute and TThread.Synchronize methods, which actually has documentation elements in the classes.xml file. Now the problem is, some other areas of TThread docs reference the documentation of TThread.Execute and TThread.Synchronize. Because they are protected, they are excluded from the docs - causing unresolved links. Should we just ignore this problem? We should not, but it's hard to give a satisfactory solution. It is, in fact, a known problem since quite some time. The only thing I can come up with is a 'ignorevisibility' attribute in the description file's element tag for methods that you do want shown. But it then requires 2 passes in the documentation generator for protected/private sections. Out of curiosity: Why is the protected section excluded in the RTL documentation? Because a) it is end-user documentation, not class-writers documentation. b) If I must document protected methods as well, the day needs 48 hours instead of 24. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc docs have hidden documentation
Am 27.08.2010 13:40, schrieb Michael Van Canneyt: On Fri, 27 Aug 2010, Sven Barth wrote: Am 27.08.2010 13:11, schrieb Michael Van Canneyt: On Fri, 27 Aug 2010, Graeme Geldenhuys wrote: Hi In the case of Classes unit documentation - more specifically the TThread documentation. The default behaviour when making RTL documentation, is for it to hide/exclude the protected section from the docs. This includes the TThread.Execute and TThread.Synchronize methods, which actually has documentation elements in the classes.xml file. Now the problem is, some other areas of TThread docs reference the documentation of TThread.Execute and TThread.Synchronize. Because they are protected, they are excluded from the docs - causing unresolved links. Should we just ignore this problem? We should not, but it's hard to give a satisfactory solution. It is, in fact, a known problem since quite some time. The only thing I can come up with is a 'ignorevisibility' attribute in the description file's element tag for methods that you do want shown. But it then requires 2 passes in the documentation generator for protected/private sections. Out of curiosity: Why is the protected section excluded in the RTL documentation? Because a) it is end-user documentation, not class-writers documentation. b) If I must document protected methods as well, the day needs 48 hours instead of 24. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel But isn't a end-user often a class-writer as well? Especially in cases like the TThread class? The second reason is valid though. I know that problem as well... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] fpdoc linear writer ResolveLink fix
Op 2010-08-27 13:16, Marco van de Voort het geskryf: Did you compare html? Yes, but I used fpGUI documentation only. For RTL, FCL I used LaTex and IPF output. Could you btw explain the logic behind the canweexit hack? I don't fully understand why underscores are now equal to points. Won't this cause problems for people that use unit names with underscores? It's not a hack, just a more accurate check to know when we must exit the method. Or you don't like the method name - which I think is descriptive of what it does. ;-) ALinkDest comes in with the format something.somethingelse ResolveLink always returns something, even if the link was unresolved (in which case it returs the package name). So simply checking to see if Result contains a string longer than 0 makes no sense - hence it always exits before it got to the recursive lookup bit. A simple test: place System.Writeln([1-4]) calls before each ResolveLink call. It never reaches the 3rd or 4th iterations. So why the '.' replacement to '_'? Because ResoveLink returns the link in a underscore format. So we change ALinkDest (initially passed in value) into something in the same format as what ResolveLink returns. Then we check to see if the original string is in the Result variable - if it is, we know we resolved the link successfully, so we can exit. Any no it's not a IPF thing, and it doesn't affect unit names with underscores - fpGUI used underscores in every unit. Generating Latex, IPF or HTML documentation for fpGUI classes work fine at the moment. Specially if users are using whole words like generics_collection or something else whose fragments might clash with other identifiers now. No, it doesn't affect any identifiers I could see. Again, fpGUI uses underscores in all units, and many classes or types have underscores as well. If you know of an issue, please supply and example. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] fpdoc linear writer ResolveLink fix
Op 2010-08-27 13:32, Michael Van Canneyt het geskryf: Maybe. But it seems to effectively disable module.identifier resolution (for modulecurrentmodule). So while it may not be the most used functionality, the question is why it must be (effectively) removed. It was never supported in the first place. There were only 2 supported ways: - #package.module.identifier - identifier module.identifier was never supposed to work. Even so, I use that format a lot if fpGUI docs, and they resolve 100% now. So unofficially there is no problem using them. I'm not sure what Marco is going on about. Marco, maybe you can supply an example of where it's not working for you? (after my last patch is applied) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] fpdoc linear writer ResolveLink fix
In our previous episode, Graeme Geldenhuys said: Yes, but I used fpGUI documentation only. For RTL, FCL I used LaTex and IPF output. I'll have to digest your and Michael msgs and check all ends first before I can reply in any sane way. Till now, I fixed that routine also in a drive-by style, so it is time to really dig into it and make sure there are no problems. However this weekend is 2.4.2rc1 building, so it will probably be after. Any no it's not a IPF thing, and it doesn't affect unit names with underscores - fpGUI used underscores in every unit. Generating Latex, IPF or HTML documentation for fpGUI classes work fine at the moment. I was more thinking about e.g. identifier unitname.something and unit unitname_something clashing. Of course dotted unit names will become a problem in time too. No, it doesn't affect any identifiers I could see. Again, fpGUI uses underscores in all units, and many classes or types have underscores as well. If you know of an issue, please supply and example. Well, there is no example needed if it is a fundamental problem. Underscore is a legal identifier character, so using it as separate can introduce clashes. As said, dotted unit names will be a can of worms too. On the other hand, if there are no current problems, then at least it is not acute. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] pscanner: differentiate between EOL Tab characters from general Whitespace
On 2010-08-26 17:24, Graeme Geldenhuys wrote: I'll find it a new home tomorrow and post the link Any news? ;) Regards Žilvinas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] pscanner: differentiate between EOL Tab characters from general Whitespace
2010/8/27 Žilvinas Ledas: I'll find it a new home tomorrow and post the link Any news? ;) Yes, I placed in on GitHub. You can clone the repository as follows: via git protocol (faster): git clone git://github.com/graemeg/fpprofiler.git via http protocol: git clone http://github.com/graemeg/fpprofiler.git Alternatively (though not tested) - you should be able to download a zip archive of the latest code via this URL: http://github.com/graemeg/fpprofiler/zipball/HEAD NOTE: Make sure the code you want to profile is backed up, or in some repository. I have found cases where the profiler (fpp) failed to modify all units due to parsing errors, then failed again restoring all units to what they were. I think I fixed this bug, but I thought I better let you know. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] does fpc lock the fpc.cfg exclusive on windows?
I got a strange error while compiling, saying that fpc couldn't open the fpc.cfg file (sorry lost the exact wording) The file definitely was/is there. And on repeated compilation all worked fine. Only thing I can think off: I was compiling to different projects. The projects where completely separate, only the same compiler was used. I've done that often, and never had an issue. But *if* fpc does lock the fpc.cfg file exclusively ( for a very short time only, e.g. just open+lock, read, close), then there is the slim chance of a conflict, and this error could be explained. Anyone any idea? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
