On 28 January 2012 15:08, Michael Van Canneyt wrote:
> But if I tell you that order matters, please be so kind to assume that I
> know what I'm talking about:
Michael, maybe this "difference of opinion" can be resolved if you
post your example of the 2 units the reproduces the error (like you
me
Michael Van Canneyt schrieb:
Well, you have the sources, you can look up the actual implementation.
Then you would see that:
Please don't confuse syntax and semantics. Reading source code reveals
only *what* is done, but not *why* it's done, and what are the consequences.
* The fpdoc engin
On Sun, 29 Jan 2012, Hans-Peter Diettrich wrote:
Marco van de Voort schrieb:
In our previous episode, Michael Van Canneyt said:
The question you asked:
"How is that related to documentation and the order of input files?"
I've the feeling that Dodi assumes all references are fully qualifie
Marco van de Voort schrieb:
In our previous episode, Michael Van Canneyt said:
The question you asked:
"How is that related to documentation and the order of input files?"
I've the feeling that Dodi assumes all references are fully qualified and
not just the inter-package ones?
No. I'm fami
On Sat, 28 Jan 2012, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
The question you asked:
"How is that related to documentation and the order of input files?"
I've the feeling that Dodi assumes all references are fully qualified and
not just the inter-packag
In our previous episode, Michael Van Canneyt said:
> The question you asked:
>
> "How is that related to documentation and the order of input files?"
I've the feeling that Dodi assumes all references are fully qualified and
not just the inter-package ones?
On Sat, 28 Jan 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
On Sat, 28 Jan 2012, Hans-Peter Diettrich wrote:
I still don't understand this requirement, and how documentation writers
should establish the correct order :-(
Simple.
The same order as the compiler uses: it
Michael Van Canneyt schrieb:
On Sat, 28 Jan 2012, Hans-Peter Diettrich wrote:
I still don't understand this requirement, and how documentation
writers should establish the correct order :-(
Simple.
The same order as the compiler uses: it is 100% determined by the
uses clause.
How is that
On Sat, 28 Jan 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
On Sat, 28 Jan 2012, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
On Fri, 27 Jan 2012, Hans-Peter Diettrich wrote:
should first document dependent units. It currently does not know how
to do
Michael Van Canneyt schrieb:
On Sat, 28 Jan 2012, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
On Fri, 27 Jan 2012, Hans-Peter Diettrich wrote:
should first document dependent units. It currently does not know
how to do this by itself.
Again, what are you talking about?
On 28.01.2012 12:59, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Otherwise funny things will happen with duplicate identifiers.
I know. The problem will get only worse with nested type declarations,
which are next on my todo list.
One more problem introduced by uneducated Delph
Michael Van Canneyt schrieb:
The LCL documentation build sorts the units alphabetically, and this
also seems to work.
Of course it produces documentation, but cross-links can and will fail
because the correct target is not found.
For cross-links to be correct, the order must be correct.
P
Michael Van Canneyt schrieb:
Otherwise funny things will happen with duplicate identifiers.
I know. The problem will get only worse with nested type declarations,
which are next on my todo list.
One more problem introduced by uneducated Delphi developers. Must FPC
really follow all these a
Marco van de Voort schrieb:
In our previous episode, Michael Van Canneyt said:
Meanwhile I have a simple example using 2 units floating around somewhere.
It took me lots of time to find it, but now I know where the cause is.
Solving it is another matter entirely.
I've been thinking about it, a
On Sat, 28 Jan 2012, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
On Fri, 27 Jan 2012, Hans-Peter Diettrich wrote:
should first document dependent units. It currently does not know how to
do this by itself.
Again, what are you talking about? FPDoc doesn't require a spec
michael.vancann...@wisa.be schrieb:
On Fri, 27 Jan 2012, Hans-Peter Diettrich wrote:
should first document dependent units. It currently does not know how
to do this by itself.
Again, what are you talking about? FPDoc doesn't require a special
order of input files, neither source nor documen
Marco van de Voort schrieb:
In our previous episode, Mattias Gaertner said:
[...]
For the --input-dir there is an extra reason: the order of files is important.
Just like in the compiler, which must compile dependent units first, fpdoc
should first document dependent units. It currently does no
On Sat, 28 Jan 2012, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Meanwhile I have a simple example using 2 units floating around somewhere.
It took me lots of time to find it, but now I know where the cause is.
Solving it is another matter entirely.
I've bee
In our previous episode, Michael Van Canneyt said:
> Meanwhile I have a simple example using 2 units floating around somewhere.
> It took me lots of time to find it, but now I know where the cause is.
> Solving it is another matter entirely.
I've been thinking about it, and following the compilers
On Fri, 27 Jan 2012, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
Again, what are you talking about? FPDoc doesn't require a special order
of input files, neither source nor documentation files :-)
It does, see the explanation of Marco.
Then I wonder how I ever could g
michael.vancann...@wisa.be schrieb:
Again, what are you talking about? FPDoc doesn't require a special
order of input files, neither source nor documentation files :-)
It does, see the explanation of Marco.
Then I wonder how I ever could generate the documentation for a single unit?
The LCL
On Fri, 27 Jan 2012, Hans-Peter Diettrich wrote:
should first document dependent units. It currently does not know how to do
this by itself.
Again, what are you talking about? FPDoc doesn't require a special order of
input files, neither source nor documentation files :-)
It does, see the
In our previous episode, Mattias Gaertner said:
> >[...]
> > For the --input-dir there is an extra reason: the order of files is
> > important.
> > Just like in the compiler, which must compile dependent units first, fpdoc
> > should first document dependent units. It currently does not know how
On Fri, 27 Jan 2012 09:41:42 +0100 (CET)
michael.vancann...@wisa.be wrote:
>[...]
> For the --input-dir there is an extra reason: the order of files is important.
> Just like in the compiler, which must compile dependent units first, fpdoc
> should first document dependent units. It currently does
In our previous episode, Hans-Peter Diettrich said:
> > For the --input-dir there is an extra reason: the order of files is
> > important.
> > Just like in the compiler, which must compile dependent units first, fpdoc
> > should first document dependent units. It currently does not know how to
>
michael.vancann...@wisa.be schrieb:
As I said before:
Neither --input-dir nor --descr-dir will be put in the fpdoc
implementation.
What are you talking about? They are already in fpdoc :-)
I don't see the problem of having to specify all files that are part of the
project explicitly. Make
On Fri, 27 Jan 2012, Hans-Peter Diettrich wrote:
Unfortunately I managed to supply the EasyImports.patch twice, please drop
Mantis #21168 as a dupe of #21167. Sorry for the inconvenience :-(
Thank you. I will look at it.
Starting with this patch I suggest further improvements of fpdoc. Exce
Unfortunately I managed to supply the EasyImports.patch twice, please
drop Mantis #21168 as a dupe of #21167. Sorry for the inconvenience :-(
Starting with this patch I suggest further improvements of fpdoc. Except
for the RTL docs, which require a couple of special compiler options for
every
On Wed, 30 Nov 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
That would conflict with the GUI TApplication instance, so I really don't
see the point of this exercise.
Then another error in the logic exists: CreateDocumentation should be a
method of TFPDocProject, not of T
Michael Van Canneyt schrieb:
That would conflict with the GUI TApplication instance, so I really
don't see the point of this exercise.
Then another error in the logic exists: CreateDocumentation should be
a method of TFPDocProject, not of TFPDocAplication.
Why ? TFPDocProject is just storag
On Tue, 29 Nov 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
When this were the *only* code in the fpdoc program file, another project
could create a derived class, with a possibly specialized Run method,
without touching the declaration or implementation of TFPDocAp
On 29/11/2011, Sven Barth wrote:
>
> You could try the Jedi Code Formatter included with Lazarus. I've never
> tested it myself, because it is the first thing I disable when
That copy of JCF is bugy. Rather use the original version available
for download on SourceForge, from the JCF project. Also
On 29.11.2011 13:11, Hans-Peter Diettrich wrote:
I'm even trying to concentrate as good as possible to adhere to the
style used there,
Where's the code formatter, that would eliminate all such discussions?
You could try the Jedi Code Formatter included with Lazarus. I've never
tested it myse
michael.vancann...@wisa.be schrieb:
When this were the *only* code in the fpdoc program file, another
project could create a derived class, with a possibly specialized Run
method, without touching the declaration or implementation of
TFPDocApplication.
That would conflict with the GUI TAppli
On Tue, 29 Nov 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
begin
With TFPDocAplication.Create(Nil) do
try
Run;
finally
Free;
end;
end.
When this were the *only* code in the fpdoc program file, another project
could create a derived class, with
On Tue, 29 Nov 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
A "make -n rtl.chk > test.txt" succeeded, at least. Now I suspect some
Windows or RTL commandline limitations, which seem to truncate the long
command lines created by the scripts (4890 chars for rtl.chk).
Tomas Hajny schrieb:
The current limit of the default MS Windows shell is 8 kB according to
information found on Microsoft pages (among others). Are those 4890
characters mentioned above Unicode (UTF-16) characters (thus breaking the
limit)? Anyway, it might be possible to use a different comman
Sven Barth schrieb:
I'm not a huge fan of the style used in the compiler, but am I
complaining?
Did I?
I'm even trying to concentrate as good as possible to
adhere to the style used there,
Where's the code formatter, that would eliminate all such discussions?
so that the changes I want to
michael.vancann...@wisa.be schrieb:
2. Try to separate things. You coded a change in package selection
handling, please don't mix this with the change for writing a package
file. It makes it more difficult to debug when bugs arise.
How can I create patches for different topics, when the whole
michael.vancann...@wisa.be schrieb:
A "make -n rtl.chk > test.txt" succeeded, at least. Now I suspect some
Windows or RTL commandline limitations, which seem to truncate the
long command lines created by the scripts (4890 chars for rtl.chk).
This is a problem of windows, yes.
Argh :-(
Try
On Tue, 29 Nov 2011, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
INF or HTML), and replaced them with simple command line programs that
can be compiled from: fpc somecoolutitility.pas
You then have TProcess, the whole RTL and FCL at your disposal. MUC
In our previous episode, michael.vancann...@wisa.be said:
> > INF or HTML), and replaced them with simple command line programs that
> > can be compiled from: fpc somecoolutitility.pas
> >
> > You then have TProcess, the whole RTL and FCL at your disposal. MUCH
> > more powerful than scripts or ma
Am 29.11.2011 12:18, schrieb michael.vancann...@wisa.be:
On Tue, 29 Nov 2011, Graeme Geldenhuys wrote:
On 29/11/2011, Hans-Peter Diettrich wrote:
A "make -n rtl.chk > test.txt" succeeded, at least. Now I suspect some
Windows or RTL commandline limitations, which seem to truncate the long
c
On Tue, 29 Nov 2011, Graeme Geldenhuys wrote:
On 29/11/2011, Hans-Peter Diettrich wrote:
A "make -n rtl.chk > test.txt" succeeded, at least. Now I suspect some
Windows or RTL commandline limitations, which seem to truncate the long
command lines created by the scripts (4890 chars for rtl.ch
On 29/11/2011, Hans-Peter Diettrich wrote:
>
> A "make -n rtl.chk > test.txt" succeeded, at least. Now I suspect some
> Windows or RTL commandline limitations, which seem to truncate the long
> command lines created by the scripts (4890 chars for rtl.chk).
Does this limitation apply when using T
On Tue, November 29, 2011 10:42, michael.vancann...@wisa.be wrote:
> On Tue, 29 Nov 2011, Hans-Peter Diettrich wrote:
>> Hans-Peter Diettrich schrieb:
>>
>>> Unfortunately there remain some problems, e.g. the FPC documentation
>>> cannot
>>> be created on Windows, what is one reason for the extende
On Tue, 29 Nov 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
On Mon, 28 Nov 2011, Hans-Peter Diettrich wrote:
I just implemented and option to create an XML project from the
commandline arguments. This should allow to create projects from the
scripts and Makefiles
Am 29.11.2011 11:09, schrieb Hans-Peter Diettrich:
michael.vancann...@wisa.be schrieb:
On Mon, 28 Nov 2011, Hans-Peter Diettrich wrote:
I just implemented and option to create an XML project from the
commandline arguments. This should allow to create projects from the
scripts and Makefiles,
michael.vancann...@wisa.be schrieb:
On Mon, 28 Nov 2011, Hans-Peter Diettrich wrote:
I just implemented and option to create an XML project from the
commandline arguments. This should allow to create projects from the
scripts and Makefiles, used to build the documentation for the
standard l
On Tue, 29 Nov 2011, Hans-Peter Diettrich wrote:
Hans-Peter Diettrich schrieb:
Unfortunately there remain some problems, e.g. the FPC documentation cannot
be created on Windows, what is one reason for the extended project option,
but doesn't allow me to debug this feature with real life pro
Hans-Peter Diettrich schrieb:
Unfortunately there remain some problems, e.g. the FPC documentation
cannot be created on Windows, what is one reason for the extended
project option, but doesn't allow me to debug this feature with real
life projects (RTL...).
A "make -n rtl.chk > test.txt" suc
On Mon, 28 Nov 2011, Hans-Peter Diettrich wrote:
I just implemented and option to create an XML project from the commandline
arguments. This should allow to create projects from the scripts and
Makefiles, used to build the documentation for the standard libraries. See
Mantis #20769.
I had
I just implemented and option to create an XML project from the
commandline arguments. This should allow to create projects from the
scripts and Makefiles, used to build the documentation for the standard
libraries. See Mantis #20769.
Unfortunately there remain some problems, e.g. the FPC docu
53 matches
Mail list logo
