Re: [fpc-devel] FPC-JVM: Status report on Android
On Thu, Sep 1, 2011 at 1:13 AM, Sven Barth wrote: > > I'll try to improve the unit names of the android unit and its dependencies > a bit and then it might become the first package for FPC-JVM ;) > Sven, thanks for your tests. Adding hwfpo (Hello World From Pascal Only) and simple step-by-step instructions how to compile it also would be nice :) Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
On 31 Aug 2011, at 23:13, Sven Barth wrote: > On 31.08.2011 22:59, Jonas Maebe wrote: >> >> I'll do a testsuite run to see whether I introduced any bugs in the string >> handling, but to test the Android stuff you can also use a compiler compiled >> against another RTL for now. Testsuite didn't pick up anything, I'll debug it in the compiler tomorrow. > As the saying goes: a picture says more than thousand words. :D Nice :) > I'll try to improve the unit names of the android unit and its dependencies a > bit and then it might become the first package for FPC-JVM ;) Great! Note that using the jdk15 unit in the android unit is not a good idea, since it probably also exports JDK api's that are not available on android. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
On 31.08.2011 22:59, Jonas Maebe wrote: On 31 Aug 2011, at 22:44, Sven Barth wrote: No, the end is missing as well. If I change the unit output path to something like "output" (something short) though, then the "4.j" is printed. Besides that the content of the ppas file is completely different in both cases... it nearly looks as if some RAM garbage is printed... I've run it a third time and the ppas.sh is again different. Didn't you change something in the string handling? Ah, yes, it's possible that something is now broken in the non-JVM RTLs regarding string handling, I didn't test those thoroughly yet (only make fullcyle). I'm using a ppcjvm that's built using a simple "make all PPC_TARGET=jvm" in the compiler dir, so it's compiled using the default compiler's RTL rather than using the RTL in of the fpc-jvm branch. I'll do a testsuite run to see whether I introduced any bugs in the string handling, but to test the Android stuff you can also use a compiler compiled against another RTL for now. As the saying goes: a picture says more than thousand words. :D Thank you for your efforts, Jonas. I'll try to improve the unit names of the android unit and its dependencies a bit and then it might become the first package for FPC-JVM ;) Regards, Sven <>___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
On 31 Aug 2011, at 22:44, Sven Barth wrote: > No, the end is missing as well. > If I change the unit output path to something like "output" (something short) > though, then the "4.j" is printed. Besides that the content of the ppas file > is completely different in both cases... it nearly looks as if some RAM > garbage is printed... I've run it a third time and the ppas.sh is again > different. > Didn't you change something in the string handling? Ah, yes, it's possible that something is now broken in the non-JVM RTLs regarding string handling, I didn't test those thoroughly yet (only make fullcyle). I'm using a ppcjvm that's built using a simple "make all PPC_TARGET=jvm" in the compiler dir, so it's compiled using the default compiler's RTL rather than using the RTL in of the fpc-jvm branch. I'll do a testsuite run to see whether I introduced any bugs in the string handling, but to test the Android stuff you can also use a compiler compiled against another RTL for now. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
On 31.08.2011 22:35, Jonas Maebe wrote: On 31 Aug 2011, at 22:22, Sven Barth wrote: On 31.08.2011 22:14, Jonas Maebe wrote: Forgot to commit a file, sorry. Nobody is perfect :) But there seems to be another problem. When assembling the system unit I get the following error: === output begin === Assembling system ../../rtl/units/jvm-java/$system$$_fpc_nestedvars$486 -d ../../rtl/units/jvm-java/: file not found === output end === There seems to be missing a "4.j" at the end of the filename... (I might be wrong, but that seems to be the largest filename so far) That's strange, I've never seen an error like that. I cannot reproduce that problem: $ make FPC=ppcjvm60 OPT="-O2 -al -g" clean all /bin/rm -f ../../rtl/units/jvm-java/system.ppu ../../rtl/units/jvm-java/uuchar.ppu ../../rtl/units/jvm-java/objpas.ppu ../../rtl/units/jvm-java/jdk15.ppu /bin/rm -f fpcmade.jvm-java Package.fpc ppas.sh script.res link.res /bin/rm -f *.s *_ppas.bat ppcjvm60 @rtl.cfg -Tjava -Pjvm -Fi../inc -Fi../jvm -FE. -FU../../rtl/units/jvm-java -O2 -al -g -djvm -Us -Sg system.pp Free Pascal Compiler version 2.7.1 [2011/08/29] for jvm Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Java Virtual Machine Compiling system.pp Assembling system Generated: ../../rtl/units/jvm-java/org/freepascal/rtl/$system$$_fpc_nestedvars$4864.class Generated: ../../rtl/units/jvm-java/org/freepascal/rtl/system.class Generated: ../../rtl/units/jvm-java/org/freepascal/rtl/$methodpointer.class Generated: ../../rtl/units/jvm-java/org/freepascal/rtl/FpcEnumValueObtainable.class [etc] You can try executing this: /path/to/ppcjvm @rtl.cfg -Tjava -Pjvm -Fi../inc -Fi../jvm -FE. -FU../../rtl/units/jvm-java -O2 -al -g -s -djvm -Us -Sg system.pp and have a look at the generated ppas.sh No, the end is missing as well. If I change the unit output path to something like "output" (something short) though, then the "4.j" is printed. Besides that the content of the ppas file is completely different in both cases... it nearly looks as if some RAM garbage is printed... I've run it a third time and the ppas.sh is again different. Didn't you change something in the string handling? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
On 31 Aug 2011, at 22:22, Sven Barth wrote: > On 31.08.2011 22:14, Jonas Maebe wrote: >> >> Forgot to commit a file, sorry. > > Nobody is perfect :) > > But there seems to be another problem. When assembling the system unit I get > the following error: > > === output begin === > > Assembling system > ../../rtl/units/jvm-java/$system$$_fpc_nestedvars$486 -d > ../../rtl/units/jvm-java/: file not found > > === output end === > > There seems to be missing a "4.j" at the end of the filename... (I might be > wrong, but that seems to be the largest filename so far) That's strange, I've never seen an error like that. I cannot reproduce that problem: $ make FPC=ppcjvm60 OPT="-O2 -al -g" clean all /bin/rm -f ../../rtl/units/jvm-java/system.ppu ../../rtl/units/jvm-java/uuchar.ppu ../../rtl/units/jvm-java/objpas.ppu ../../rtl/units/jvm-java/jdk15.ppu /bin/rm -f fpcmade.jvm-java Package.fpc ppas.sh script.res link.res /bin/rm -f *.s *_ppas.bat ppcjvm60 @rtl.cfg -Tjava -Pjvm -Fi../inc -Fi../jvm -FE. -FU../../rtl/units/jvm-java -O2 -al -g -djvm -Us -Sg system.pp Free Pascal Compiler version 2.7.1 [2011/08/29] for jvm Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Java Virtual Machine Compiling system.pp Assembling system Generated: ../../rtl/units/jvm-java/org/freepascal/rtl/$system$$_fpc_nestedvars$4864.class Generated: ../../rtl/units/jvm-java/org/freepascal/rtl/system.class Generated: ../../rtl/units/jvm-java/org/freepascal/rtl/$methodpointer.class Generated: ../../rtl/units/jvm-java/org/freepascal/rtl/FpcEnumValueObtainable.class [etc] You can try executing this: /path/to/ppcjvm @rtl.cfg -Tjava -Pjvm -Fi../inc -Fi../jvm -FE. -FU../../rtl/units/jvm-java -O2 -al -g -s -djvm -Us -Sg system.pp and have a look at the generated ppas.sh Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
On 31.08.2011 22:14, Jonas Maebe wrote: On 31 Aug 2011, at 21:55, Sven Barth wrote: On 31 Aug 2011, at 21:36, Sven Barth wrote: On 31.08.2011 21:21, Jonas Maebe wrote: Fixed in svn, there was a bug in the abstract method accounting. When compiling the RTL (make RELEASE=1 clean all) for i386 I get the following error: Fixed. Thanks. The next problem is when compiling the Java RTL: Forgot to commit a file, sorry. Nobody is perfect :) But there seems to be another problem. When assembling the system unit I get the following error: === output begin === Assembling system ../../rtl/units/jvm-java/$system$$_fpc_nestedvars$486 -d ../../rtl/units/jvm-java/: file not found === output end === There seems to be missing a "4.j" at the end of the filename... (I might be wrong, but that seems to be the largest filename so far) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DIFF for consideration
Am 28.08.2011 19:59, schrieb David Welch: > > See attached. > Thanks, applied in r18927. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
On 31 Aug 2011, at 21:55, Sven Barth wrote: >> >> On 31 Aug 2011, at 21:36, Sven Barth wrote: >> >>> On 31.08.2011 21:21, Jonas Maebe wrote: Fixed in svn, there was a bug in the abstract method accounting. >>> >>> When compiling the RTL (make RELEASE=1 clean all) for i386 I get the >>> following error: >> >> Fixed. > > Thanks. The next problem is when compiling the Java RTL: Forgot to commit a file, sorry. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
On 31.08.2011 21:49, Jonas Maebe wrote: On 31 Aug 2011, at 21:36, Sven Barth wrote: On 31.08.2011 21:21, Jonas Maebe wrote: Fixed in svn, there was a bug in the abstract method accounting. When compiling the RTL (make RELEASE=1 clean all) for i386 I get the following error: Fixed. Thanks. The next problem is when compiling the Java RTL: === output begin === astrings.inc(734,14) Error: Identifier not found "PAnsiRec" astrings.inc(734,34) Error: Identifier not found "FirstOff" astrings.inc(736,8) Error: Identifier not found "Move" astrings.inc(736,20) Error: Illegal expression astrings.inc(736,26) Error: Illegal expression astrings.inc(737,11) Error: Identifier not found "PAnsiRec" astrings.inc(737,25) Error: Identifier not found "FirstOff" === output end === Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
On 31 Aug 2011, at 21:36, Sven Barth wrote: > On 31.08.2011 21:21, Jonas Maebe wrote: >> Fixed in svn, there was a bug in the abstract method accounting. > > When compiling the RTL (make RELEASE=1 clean all) for i386 I get the > following error: Fixed. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
On 31.08.2011 21:21, Jonas Maebe wrote: Fixed in svn, there was a bug in the abstract method accounting. When compiling the RTL (make RELEASE=1 clean all) for i386 I get the following error: === output begin === make[1]: Entering directory `/mnt/data/subversion/fpc-jvm/rtl/linux' /mnt/data/applications/fpc/2.4.4/bin/ppc386 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../unix -Fii386 -FE. -FU../../rtl/units/i386-linux -di386 -dRELEASE -Us -Sg system.pp thread.inc(414,10) Warning: Function result does not seem to be set i386.inc(1657,10) Error: Forward declaration not solved "fpc_truely_ansistr_unique(var Pointer):^untyped;" system.pp(384) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted === output end === Compiler version is 2.4.4 Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
On 30 Aug 2011, at 22:59, Jonas Maebe wrote: > On 30 Aug 2011, at 22:37, Sven Barth wrote: > >> On 30.08.2011 22:32, Jonas Maebe wrote: >>> >>> On 30 Aug 2011, at 22:26, Sven Barth wrote: >>> I've also found the class that defines the abstract methods. It's four classes above android.app.Activity in the inheritance tree (android.common.Context). I yet need to check whether all methods are overridden correctly by the subclasses (and crosscheck that with the documentation). >>> >>> If you create an instance of that class in FPC code and compile with -vw, >>> the compiler should list the abstract methods. >> >> There seems to be none :( > > Can you make the android unit available for download somewhere? Fixed in svn, there was a bug in the abstract method accounting. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Including Sorokin's TRegExpr in FPC
At 08:07 AM 8/31/2011, John Lee wrote: Just googled 'Benjamin Rosseax regexpr' and don't find anything that's trelevant! Where is it please? It might help for a start to get the name right, his last name is "Rosseaux"... http://bero.freqvibez.net/public/BESEN/BESEN.pas hth, Ralf ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Including Sorokin's TRegExpr in FPC
Just googled 'Benjamin Rosseax regexpr' and don't find anything that's trelevant! Where is it please? John On 31 August 2011 15:41, Marcos Douglas wrote: > On Wed, Aug 31, 2011 at 2:55 AM, Felipe Monteiro de Carvalho > wrote: > > On Tue, Aug 30, 2011 at 10:22 PM, Florian Klämpfl > > wrote: > >> Why didn't you just give the sorokin tregexpr unit another name? This > >> way, no incompatiblities would have been introduced. > > > > Because: > > > > 1> the old regexpr.pas had something like 20 lines of code and it's > > own description said it doesn't even support most POSIX, so it didn't > > look very useful? > > 2> Most of Joost's code is in regex.pp which was not changed, not in > > oldregexpr.pp > > 3> Compatibility with Delphi projects which use regexpr.pas where it > > means Sorokin's RegExpr (I've already found a couple of those only in > > projects which I develop, I don't know if it was included in Delphi, > > but I think it is possible because I found some projects which use it > > but don't have it in the sources) > > 4> Beginners would most likely try to use regexpr.pas which has the > > most simple name, they are better off trying to use the Sorokin > > version. > > 5> Benjamin Rosseax regexpr is a new invention, not something well > > stablished and widely used like the Sorokin unit (even Lazarus uses > > the Sorokin version), so I recommend naming it something like > > benjaminregexpr or something like that. > > If we had namespaces that could be 'renamed' inside the app... > > Marcos Douglas > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Including Sorokin's TRegExpr in FPC
On Wed, Aug 31, 2011 at 2:55 AM, Felipe Monteiro de Carvalho wrote: > On Tue, Aug 30, 2011 at 10:22 PM, Florian Klämpfl > wrote: >> Why didn't you just give the sorokin tregexpr unit another name? This >> way, no incompatiblities would have been introduced. > > Because: > > 1> the old regexpr.pas had something like 20 lines of code and it's > own description said it doesn't even support most POSIX, so it didn't > look very useful? > 2> Most of Joost's code is in regex.pp which was not changed, not in > oldregexpr.pp > 3> Compatibility with Delphi projects which use regexpr.pas where it > means Sorokin's RegExpr (I've already found a couple of those only in > projects which I develop, I don't know if it was included in Delphi, > but I think it is possible because I found some projects which use it > but don't have it in the sources) > 4> Beginners would most likely try to use regexpr.pas which has the > most simple name, they are better off trying to use the Sorokin > version. > 5> Benjamin Rosseax regexpr is a new invention, not something well > stablished and widely used like the Sorokin unit (even Lazarus uses > the Sorokin version), so I recommend naming it something like > benjaminregexpr or something like that. If we had namespaces that could be 'renamed' inside the app... Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: fpdoc extension: embed topic [Re: [fpc-devel] FPDoc sources]
On Wed, 31 Aug 2011, Hans-Peter Diettrich wrote: michael.vancann...@wisa.be schrieb: In each case, the opposite is already so. The documentation of an enumerated-typed property will normally link to the enumerated type. This doesn't make sense, because the meaning of an enum member can vary, depending on the context (class with property). Useful documentation should explain all available options together, and should not require to click through all related declarations, in order to find out what options exist. Yes. It does so in FPC. For example http://www.freepascal.org/docs-html/rtl/classes/tfilestream.create.html In fact a bad example, because the option is not an enumerated type but simple constants. So let us look at http://www.freepascal.org/docs-html/rtl/classes/talignment.html The TAlignment declaration contains a description for all options. Generated automatically by fpdoc, because it knows from the sources that TAlignment is an enumerated, and therefore it automatically prints a short description for all enumerated elements in the definition. So no need to 'click through'. All is together in 1 page. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
On 31/08/2011, Hans-Peter Diettrich wrote: > ... > process_begin: CreateProcess((null), latex user.tex, ...) failed. > make (e=2): Das System kann die angegebene Datei nicht finden. I have never tried to build the FPC documentation under Windows, but if I understood the above error correctly, it is simply trying to execute the 'latex' executable which doesn't exist on your system. Maybe the latex executable is named something different than 'latex' under Windows (eg: latexwin.exe or something). So maybe the Makefile might just need to be tweaked to use a different executable name under Windows. Just a guess. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: fpdoc extension: embed topic [Re: [fpc-devel] FPDoc sources]
Martin schrieb: Now we have 7 identifiers, all refering to the essentially same data type. IMO it's only excess work, to document all these elements by themselves, when finally only the property is of interest. Instead I'd prefer a single doc entry, for the property, that also describes the enum elements. All related elements then can be linked to that unique description. IMHO the location of where the enum is located is not relevant to the requirement of (or ability to the do without) scanning the source. You got it :-) Never the less, this could be an interesting feature. If fpdoc could be told (as part of the xml) that the documentation of an element should be embgedded in the parent (enum element, in enum type), or even embedded in a specific other node (a property specified by name, that uses the enum). I assume that this is already implemented. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: fpdoc extension: embed topic [Re: [fpc-devel] FPDoc sources]
michael.vancann...@wisa.be schrieb: In each case, the opposite is already so. The documentation of an enumerated-typed property will normally link to the enumerated type. This doesn't make sense, because the meaning of an enum member can vary, depending on the context (class with property). Useful documentation should explain all available options together, and should not require to click through all related declarations, in order to find out what options exist. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
In our previous episode, Hans-Peter Diettrich said: > >> On Windows even the makefile doesn't work, > > > > "doesn't work" is not terribly informative. Maybe you simply don't know > > windows build systems very well. > > Is this more informative? That depends on viewpoint. > $make html > ... > process_begin: CreateProcess((null), latex user.tex, ...) failed. > make (e=2): Das System kann die angegebene Datei nicht finden. I'm not going to argue on this level, I'm sorry, my time is more precious than that. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
Marco van de Voort schrieb: On Windows even the makefile doesn't work, "doesn't work" is not terribly informative. Maybe you simply don't know windows build systems very well. Is this more informative? $make html ... process_begin: CreateProcess((null), latex user.tex, ...) failed. make (e=2): Das System kann die angegebene Datei nicht finden. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: fpdoc extension: embed topic [Re: [fpc-devel] FPDoc sources]
On 31/08/2011 13:17, michael.vancann...@wisa.be wrote: On Wed, 31 Aug 2011, Martin wrote: What I meant was: - TEnum.One / TEnum.One /TEnum are still each of them documented in their own xml node, exactly as they currently are. But in TEnum xml node would be an attribute (or a node) declaring: SomePropertynameUsingTEnum This is what the '' is for. see also is different It's not useful to have only 1 "priviledged" since an enum may be used in many properties of many classes. that can only be confirmed/decided by the author of the code/docs. The original mail, that triggered the idea was: On 31/08/2011 09:43, Hans-Peter Diettrich wrote: type TMyEnum = (one, two); TMySet = set of TMyEnum; ... property MyProp: TMySet read GetIt write SetIt; Now we have 7 identifiers, all refering to the essentially same data type. IMO it's only excess work, to document all these elements by themselves, when finally only the property is of interest. Instead I'd prefer a single doc entry, for the property, that also describes the enum elements. All related elements then can be linked to that unique description. Indicating the desire to have the documentation of the enum exclusively within one property. Currently that can be done, by just putting it there by hand. That of course means, should you ever have to link it (which in the avbove case should not be needed / if it was needed it should likely not have been embedded) then the author has to remember to put in the corrected link himself Putting the enum manually into the property however means more work, if it should later be needed to move to it's own help-page. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: fpdoc extension: embed topic [Re: [fpc-devel] FPDoc sources]
On Wed, 31 Aug 2011, Martin wrote: On 31/08/2011 12:46, michael.vancann...@wisa.be wrote: On Wed, 31 Aug 2011, Martin wrote: IMHO the location of where the enum is located is not relevant to the requirement of (or ability to the do without) scanning the source. Never the less, this could be an interesting feature. If fpdoc could be told (as part of the xml) that the documentation of an element should be embgedded in the parent (enum element, in enum type), or even embedded in a specific other node (a property specified by name, that uses the enum). Then fpdoc could also automatically adjust all links to those elements. It could do this now already. It's just a matter of specifying an alias. A rule like TMyEnum. -> TMyOtherEnum. would do it. (the dot meaning that all identifiers starting with TmYEnum must be remapped) But personally, I don't want the linear XML structure disturbed. I edit the xml files manually, and having a 'tree like' XML then makes it more difficult to edit. But the fpdoc editor is another matter. You could perfectly adapt lazde to show a tree: TMyEnum +- One +- Two Same for classes functions, procedures, whatnot. It's just a matter of scanning the element name and creating separate nodes for each part in the dotted name. I am not too familiar with fpdoc, so maybe something already exists but: I wasn't referring to where the *editor* is showing the information, not even where it is in the xml. What I meant was: - TEnum.One / TEnum.One /TEnum are still each of them documented in their own xml node, exactly as they currently are. But in TEnum xml node would be an attribute (or a node) declaring: SomePropertynameUsingTEnum This is what the '' is for. It's not useful to have only 1 "priviledged" since an enum may be used in many properties of many classes. In each case, the opposite is already so. The documentation of an enumerated-typed property will normally link to the enumerated type. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: fpdoc extension: embed topic [Re: [fpc-devel] FPDoc sources]
On 31/08/2011 12:46, michael.vancann...@wisa.be wrote: On Wed, 31 Aug 2011, Martin wrote: IMHO the location of where the enum is located is not relevant to the requirement of (or ability to the do without) scanning the source. Never the less, this could be an interesting feature. If fpdoc could be told (as part of the xml) that the documentation of an element should be embgedded in the parent (enum element, in enum type), or even embedded in a specific other node (a property specified by name, that uses the enum). Then fpdoc could also automatically adjust all links to those elements. It could do this now already. It's just a matter of specifying an alias. A rule like TMyEnum. -> TMyOtherEnum. would do it. (the dot meaning that all identifiers starting with TmYEnum must be remapped) But personally, I don't want the linear XML structure disturbed. I edit the xml files manually, and having a 'tree like' XML then makes it more difficult to edit. But the fpdoc editor is another matter. You could perfectly adapt lazde to show a tree: TMyEnum +- One +- Two Same for classes functions, procedures, whatnot. It's just a matter of scanning the element name and creating separate nodes for each part in the dotted name. I am not too familiar with fpdoc, so maybe something already exists but: I wasn't referring to where the *editor* is showing the information, not even where it is in the xml. What I meant was: - TEnum.One / TEnum.One /TEnum are still each of them documented in their own xml node, exactly as they currently are. But in TEnum xml node would be an attribute (or a node) declaring: SomePropertynameUsingTEnum An editor may or may not use this to display info in different ways. But when generating the final help, fpdoc would not generate a separate topic for TEnum. it would embed the documentation in the given other element (does not have to be a propert, could be anything). And links in the documentation would be changed appropriately. This would allow to document each element on it's own as currently. Yet allow the author to specify that no separate page should be created (which may lead to fragmentation of the docs). --- Anyway, at this point it's only an idea. I have no use for it myself. But the original post *sounded* like this might be desired ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: fpdoc extension: embed topic [Re: [fpc-devel] FPDoc sources]
On Wed, 31 Aug 2011, Martin wrote: On 31/08/2011 09:43, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: Now, you could "fix" that, of course. That would require you to copy all information which is contained in the interface section of the pascal file to the XML file. For example: But, copying this information to the XML file would be a) duplicate and thus redundant information. b) require more work as soon as anything changes in the interface section. and therefor would be - in my eyes - extremely bad design. Just this design is very questionable, with regards to useful documentation. My counterexample: type TMyEnum = (one, two); TMySet = set of TMyEnum; ... property MyProp: TMySet read GetIt write SetIt; Now we have 7 identifiers, all refering to the essentially same data type. IMO it's only excess work, to document all these elements by themselves, when finally only the property is of interest. Instead I'd prefer a single doc entry, for the property, that also describes the enum elements. All related elements then can be linked to that unique description. IMHO the location of where the enum is located is not relevant to the requirement of (or ability to the do without) scanning the source. Never the less, this could be an interesting feature. If fpdoc could be told (as part of the xml) that the documentation of an element should be embgedded in the parent (enum element, in enum type), or even embedded in a specific other node (a property specified by name, that uses the enum). Then fpdoc could also automatically adjust all links to those elements. It could do this now already. It's just a matter of specifying an alias. A rule like TMyEnum. -> TMyOtherEnum. would do it. (the dot meaning that all identifiers starting with TmYEnum must be remapped) But personally, I don't want the linear XML structure disturbed. I edit the xml files manually, and having a 'tree like' XML then makes it more difficult to edit. But the fpdoc editor is another matter. You could perfectly adapt lazde to show a tree: TMyEnum +- One +- Two Same for classes functions, procedures, whatnot. It's just a matter of scanning the element name and creating separate nodes for each part in the dotted name. I can appreciate that this would be a useful option (and maybe even the default view). Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
fpdoc extension: embed topic [Re: [fpc-devel] FPDoc sources]
On 31/08/2011 09:43, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: Now, you could "fix" that, of course. That would require you to copy all information which is contained in the interface section of the pascal file to the XML file. For example: But, copying this information to the XML file would be a) duplicate and thus redundant information. b) require more work as soon as anything changes in the interface section. and therefor would be - in my eyes - extremely bad design. Just this design is very questionable, with regards to useful documentation. My counterexample: type TMyEnum = (one, two); TMySet = set of TMyEnum; ... property MyProp: TMySet read GetIt write SetIt; Now we have 7 identifiers, all refering to the essentially same data type. IMO it's only excess work, to document all these elements by themselves, when finally only the property is of interest. Instead I'd prefer a single doc entry, for the property, that also describes the enum elements. All related elements then can be linked to that unique description. IMHO the location of where the enum is located is not relevant to the requirement of (or ability to the do without) scanning the source. Never the less, this could be an interesting feature. If fpdoc could be told (as part of the xml) that the documentation of an element should be embgedded in the parent (enum element, in enum type), or even embedded in a specific other node (a property specified by name, that uses the enum). Then fpdoc could also automatically adjust all links to those elements. An fpcod-editor/ide could also check that all elements of the source do have documentation (or tell you about new elements that yet need documentation) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
On Wed, 31 Aug 2011, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: Now, you could "fix" that, of course. That would require you to copy all information which is contained in the interface section of the pascal file to the XML file. For example: But, copying this information to the XML file would be a) duplicate and thus redundant information. b) require more work as soon as anything changes in the interface section. and therefor would be - in my eyes - extremely bad design. Just this design is very questionable, with regards to useful documentation. Since the current design made the FPC docs what they are, it follows that none of the FPC docs is useful ? Thank you very much. I don't ask for an change of the design, I only ask for a complete documentation, that includes all elements of the given xml files, even if no source files are given. This is a contradiction. The part "even if no source files are given." *IMPLIES* a change of the design of fpdoc. If you don't understand that, you haven't understood anything of the way fpdoc works. I can only regret it and will say no more on the subject. Amen. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
On 08/31/2011 10:02 AM, Graeme Geldenhuys wrote: I am working on some fpdoc fixes for IPF output. I am also in the process of creating a new fpGUI release - which means I'll generate new pre-built INF help files for all relevant frameworks (RTL, FCL, LCL, fpGUI etc). This should be available for download from SourceForge in the next few days. Great ! Thanks a lot. Please keep me posted. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
In our previous episode, Graeme Geldenhuys said: [ Charset UTF-8 unsupported, converting... ] > On 31/08/2011, Hans-Peter Diettrich wrote: > > For now I only want to remove the code that skips xml files without > > according source files. In the next step the --descr option should allow > > for a directory, from which all files can be picked automatically. > > Automation with fpdoc is not always a good thing. I have already > created a command line tool which generates a documentation build > script for fpGUI, by scanning the source and xml directories - > matching up files. I soon found out that the order of units are > important to fpdoc - otherwise you end up with broken links in the > generated documentation. If you have a small example of that, could you add it to http://bugs.freepascal.org/view.php?id=19144 ? I also had that feeling, but Michael could not reproduce it. > > package or the like. No idea of fpde, it seems to be not very different > > from LazDE, and I couldn't yet make it run on Windows. > > I believe the lazde project was simply a clone of fpde - to make it > compilable with LCL. I don't think fpde has been maintained in years. http://www.stack.nl/~marcov/fpde.zip is a working windows (but GTK) version that I saved at some point. What I can remember about that is sb showing some initial version of lazde, and in the discussion about it, Sebastian said he was dropping fpgui/fpgtk, and that was pretty much the end of fpde. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
Marco van de Voort schrieb: IMHO both Dodi and you should take a step back and describe problems (or maybe even the usecase that is not possible now). Not try to argument on vague principles. Here's my problem: I cannot create local documentation for LCL, with links into RTL and FCL (...unknown: #rtl...). This seems to boil down to missing .xct files, which I couldn't create either (on Windows). No. You can also get it from the .xct's, Yes, but the XCT files are generated by fpdoc as it parses the source code. Sure. And what is the trouble with that? They could be generated from the xml files as well, or even better: from the collection of generated entries - since links to nonexisting targets are not really useful. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
On 31/08/2011, Hans-Peter Diettrich wrote: > For now I only want to remove the code that skips xml files without > according source files. In the next step the --descr option should allow > for a directory, from which all files can be picked automatically. Automation with fpdoc is not always a good thing. I have already created a command line tool which generates a documentation build script for fpGUI, by scanning the source and xml directories - matching up files. I soon found out that the order of units are important to fpdoc - otherwise you end up with broken links in the generated documentation. > This was my idea as well, but I doubt that the Lazarus packages (lpk) > contain all information, required to make fpdoc happy. Well, that information must be somewhere, because the CodeTools can find all units, include files etc. for a specific platform. > package or the like. No idea of fpde, it seems to be not very different > from LazDE, and I couldn't yet make it run on Windows. I believe the lazde project was simply a clone of fpde - to make it compilable with LCL. I don't think fpde has been maintained in years. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
In our previous episode, Hans-Peter Diettrich said: > > In our previous episode, Hans-Peter Diettrich said: > >> This would be a very useful extension, indeed. Unfortunately the RTL and > >> FCL have such irregular requirements, that much work is required to > >> provide a usable command line for the compilation of the according > >> documentation. > > > > Like "./fixdocs.sh" ? > > That's why I mentioned Windows - can you provide equivalent means for > Windows, too? Maybe I could yes, with sufficient motivation. IIRC I build the docs just fine with texlive about an year ago. Probably you can follow the above as a general recipe, and build your windows version. > On Windows even the makefile doesn't work, "doesn't work" is not terribly informative. Maybe you simply don't know windows build systems very well. > and that certainly stands in > contrast to the claim "write once, run everywhere". Please. At least try to come up with believable arguments :-) That tagline is about what project generates, not whatever theoretical tool that could be used in the project generation. Moreover you step over the fact very easily that if it doesn't work on Windows, it doesn't necessarily means it is _designed_ not to work on windows. Third, as said I've played a bit with it an year ago, and I was able to make chm's and html with a bit of testing. So even practically, it is not THAT far from working on windows. Sure, some parts of the project have a windows maintenance backlog, but I've never seen a sane patch improving the state on windows being rejected. I'm also not aware of any bugreports on this. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
On 31/08/2011, Marco van de Voort wrote: > > To avoid duplication of information (make change in pascal source of > declaration, and have to make it in the .XML source) of course. So we agree. :-) > IMHO both Dodi and you should take a step back and describe problems (or > maybe even the usecase that is not possible now). Not try to argument on > vague principles. Macro, marco, marco. Please don't jump to such incorrect conclusions. We (You, Michael and myself) are clearly agreeing on how fpdoc should work. I too, don't understand Dodi's logic about fpdoc not needing to parse the pascal sources. I think parsing the pascal sources makes a lot of sense, and fpdoc is indeed doing the correct thing. > but I think you should start with the actual problem, not with a possible > (and terribly hackish) solution. Again, it is very entertaining seeing you go off in your own direction. But I lost you here. I have no clue what you are talking about. But the fact that we actually agree on how fpdoc works (even though you clearly misunderstood my previous messages in this regard), I guess it is not important anyway. :-) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
In our previous episode, Hans-Peter Diettrich said: > > That's why the design is as it is and will not be changed anytime soon. > > I don't ask for an change of the design, I only ask for a complete > documentation, That is the objective. > that includes all elements of the given xml files, even if no source files > are given. That requirement is not part of the fpdoc design nor is it planned. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
Graeme Geldenhuys schrieb: On 30/08/2011, Hans-Peter Diettrich wrote: Unfortunately fpdoc ignores all given xml files, when no corresponding source file is given at the same time. [...] You are more than welcome to extend the tool if you want. I (and probably many others) would also welcome an alternative to Makefile usage for building fpc's docs. I loathe Makefiles. At least in theory the Makefile can be replaced by fpdoc project(s). It would be a nice feature when fpdoc could also *create* an project file, from a given commandline. This would allow to run Make once, and to use the created project(s) afterwards, on any platform. For now I only want to remove the code that skips xml files without according source files. In the next step the --descr option should allow for a directory, from which all files can be picked automatically. FCL have such irregular requirements, that much work is required to provide a usable command line for the compilation of the according documentation. Lazarus IDE already contains all that information, so it's just a matter of extracting the paths and writing the fpdoc command line options to a batch file. This was my idea as well, but I doubt that the Lazarus packages (lpk) contain all information, required to make fpdoc happy. The fcl.lpk contains only a few files, a fraction of the contained units and existing xml files. An rtl.lpk seems not to exist at all :-( The Lazarus IDE already includes the FPDoc Editor, which allows to document every identifier in the sources :-) I wasn't referring to editing documentation, but rather "managing a documentation project". Just like you use an IDE to manage a source code project, so too one could use a tool to manage a fpdoc documentation project. Currently it looks easier to edit an project file manually. Therefore my idea to let fpdoc create a project, in addition or instead of creating the documentation. In fact, I remember seeing something like that already. A quick search shows that fpde (included with FPC, but for GTK1 only), and Lazarus's lazde tool have this functionality already. See the Build dialog. You can specify the output format, source and include directories, some fpdoc parameters etc.. You can load and save a documentation project. I have no idea if it is fully implemented, but would imagine it is a bit outdated compared to fpdoc features. I can't compile either fpde or lazde projects at the moment. Maybe you have better luck. I already extended LazDE, for tracking changes to the xml files, so that e.g. translators can know what has changed in the English documentation. But its internal structure is based on single files, no chance to open a package or the like. No idea of fpde, it seems to be not very different from LazDE, and I couldn't yet make it run on Windows. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
Marco van de Voort schrieb: In our previous episode, Hans-Peter Diettrich said: This would be a very useful extension, indeed. Unfortunately the RTL and FCL have such irregular requirements, that much work is required to provide a usable command line for the compilation of the according documentation. Like "./fixdocs.sh" ? That's why I mentioned Windows - can you provide equivalent means for Windows, too? On Windows even the makefile doesn't work, and that certainly stands in contrast to the claim "write once, run everywhere". DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
Michael Van Canneyt schrieb: Now, you could "fix" that, of course. That would require you to copy all information which is contained in the interface section of the pascal file to the XML file. For example: But, copying this information to the XML file would be a) duplicate and thus redundant information. b) require more work as soon as anything changes in the interface section. and therefor would be - in my eyes - extremely bad design. Just this design is very questionable, with regards to useful documentation. My counterexample: type TMyEnum = (one, two); TMySet = set of TMyEnum; ... property MyProp: TMySet read GetIt write SetIt; Now we have 7 identifiers, all refering to the essentially same data type. IMO it's only excess work, to document all these elements by themselves, when finally only the property is of interest. Instead I'd prefer a single doc entry, for the property, that also describes the enum elements. All related elements then can be linked to that unique description. That's why the design is as it is and will not be changed anytime soon. I don't ask for an change of the design, I only ask for a complete documentation, that includes all elements of the given xml files, even if no source files are given. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] -dEXTDEBUG and compilation failures
What is the status of the EXTDEBUG code? I know that I have to define that to be able to use the compiler's -an option, but if enabled 2.4.4 doesn't compile. The fix is fairly trivial but if I notice this should I be bug-reporting it? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
In our previous episode, Graeme Geldenhuys said: > >> I beg to differ. Seeing the signature of a method, procedure, function > >> etc is valuable information to a developer. > > > > True. But that doesn't make it important to be in every fileformat. > > I don't understand your statement about "every file format". The bit is that the .XML not having this info is something else then the backend not having it. > Do you meant fpdoc output formats? If so, why would you want limited > information in one format, but not in another format? To avoid duplication of information (make change in pascal source of declaration, and have to make it in the .XML source) of course. Duh! And this means that the representation of the sources (the declarations) adapt if the FPC parser or fpdoc output generated is improved. Not exactly a theoretic case either. > > if you have an IDE that can't parse the source to get that info, you > > could develop a fairly simple fpdoc backend to generate a helper file > > for the IDE. > > An interesting idea. Or one could stream the entire tree to some XML (just like .xct) More or less that would make .xct the stuff fpdoc needs, and the secondary (and much bigger XML) some format that IDEs could import for own purposes. Such schemes are discussible IMHO, if describes a clear case and wants to do the work. But I haven't seen an actual problem described in this thread, just random bits of problems which till now sound more "invented" then real. IMHO both Dodi and you should take a step back and describe problems (or maybe even the usecase that is not possible now). Not try to argument on vague principles. > > No. You can also get it from the .xct's, > > Yes, but the XCT files are generated by fpdoc as it parses the source code. Sure. And what is the trouble with that? > Can you tell fpdoc to not generate an XCT, and then you manually > create such a file from scratch using a text editor [which fpdoc can > use]? Is so, the latter would be a huge waist of somebody's time. I have no idea what you are hinting at here. You can build the rtl and fcl via separate makefile targets I guess if you want to processing inbetween, but I think you should start with the actual problem, not with a possible (and terribly hackish) solution. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
On 31/08/2011, Michael Schnell wrote: > > Might this discussion lead to us being able to create a current version > of all inf files necessary for docview ? I am working on some fpdoc fixes for IPF output. I am also in the process of creating a new fpGUI release - which means I'll generate new pre-built INF help files for all relevant frameworks (RTL, FCL, LCL, fpGUI etc). This should be available for download from SourceForge in the next few days. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
On Wed, 31 Aug 2011, Marco van de Voort wrote: Having a inheritance hierarchy is also very valuable, which the current fpdoc XML format doesn't describe at all. This information is only available when parsing the pascal source code. No. You can also get it from the .xct's, which, for the last release, are available in the doc-chm package. The 2.4.4 release is the first that also contains interface inheritance data. The Xct contains just enough info to be able to reconstruct a correct inheritance tree. Other than that, it's basically just a list of identifiers and file names. No type info at all. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
On 31/08/2011, Marco van de Voort wrote: >> I beg to differ. Seeing the signature of a method, procedure, function >> etc is valuable information to a developer. > > True. But that doesn't make it important to be in every fileformat. I don't understand your statement about "every file format". Do you meant fpdoc output formats? If so, why would you want limited information in one format, but not in another format? > if you have an IDE that can't parse the source to get that info, you could > develop a fairly simple fpdoc backend to generate a helper file for the IDE. An interesting idea. > No. You can also get it from the .xct's, Yes, but the XCT files are generated by fpdoc as it parses the source code. Can you tell fpdoc to not generate an XCT, and then you manually create such a file from scratch using a text editor [which fpdoc can use]? Is so, the latter would be a huge waist of somebody's time. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
In our previous episode, Graeme Geldenhuys said: > > This is the purpose of makeskel. Afterwards useful information has to be > > added to all items, before finally meaningful documentation can be > > generated. > > I personally think makeskel is a terrible idea. It generates a whole > bunch of elements making it really hard to find out what is and what > isn't documented. It also generates lots of unnecessary elements - > obfuscating the xml and documentation more. Only the former. Generation of documentation for empty nodes can be surpressed in fpdoc. > > contained in the xml files. There exists no need for adding further > > information from the source code, that's more eye candy than essential > > information. > > I beg to differ. Seeing the signature of a method, procedure, function > etc is valuable information to a developer. True. But that doesn't make it important to be in every fileformat. > Not all IDE's or programming editors support "parameter hints", or some > developers prefer to keep such feature disabled to speed up the > editor/ide. So having such information [method signatures] available in > the help is very useful. Which is the case now, even though they are not in the XML. Stronger even, if you have an IDE that can't parse the source to get that info, you could develop a fairly simple fpdoc backend to generate a helper file for the IDE. > Having a inheritance hierarchy is also very valuable, which the > current fpdoc XML format doesn't describe at all. This information is > only available when parsing the pascal source code. No. You can also get it from the .xct's, which, for the last release, are available in the doc-chm package. The 2.4.4 release is the first that also contains interface inheritance data. That being said, the .xct format is a bit cumbersome, and I believe Michael already planned to change it to XML. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc sources
On 08/30/2011 05:17 PM, Graeme Geldenhuys wrote: ... Graeme, as you are on this issue: Might this discussion lead to us being able to create a current version of all inf files necessary for docview ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
