Graeme Geldenhuys hat am 2. Dezember 2011 um 08:05
geschrieben:
>[...]
> Excellent documentation means nothing if you can search and find something.
You make every developer of search tools/engines proud.
There is some Confucius' wisdom in your statement. The opposite with "can't" is
true
On Thu, December 1, 2011 13:27, michael.vancann...@wisa.be wrote:
> On Thu, 1 Dec 2011, Marco van de Voort wrote:
>
>> In our previous episode, Hans-Peter Diettrich said:
>>> commandline, which are not handled properly by the Windows shell. I
>>> fixed this manually, by editing the Makefile.
>>>
>>
In our previous episode, Tomas Hajny said:
>
> Is this the right fix? Shouldn't it be possible to generate docs based on
> other targets as an option?
What do you expect from that, other then that a few symbols disappear ? (that
are hopefully already annotated as platform specific?)
On Fri, 2 Dec 2011, Tomas Hajny wrote:
On Thu, December 1, 2011 13:27, michael.vancann...@wisa.be wrote:
On Thu, 1 Dec 2011, Marco van de Voort wrote:
In our previous episode, Hans-Peter Diettrich said:
commandline, which are not handled properly by the Windows shell. I
fixed this manually
On Fri, 2 Dec 2011, Hans-Peter Diettrich wrote:
FPDoc issues many warnings about unknown link targets. Some of these seem to
result from intrinsic types, e.g. for PSmallInt the target SmallInt does not
exist. It doesn't look good when the docs do not include the most basic
types, like Boolea
On Fri, 2 Dec 2011, Graeme Geldenhuys wrote:
On 2 December 2011 03:17, Hans-Peter Diettrich wrote:
exist. It doesn't look good when the docs do not include the most basic
types, like Boolean, Byte, Char, Pointer etc. :-(
Those are all basic built-in types. Built into the compiler, not
defin
Michael Van Canneyt schrieb:
The patch changes nothing to the content of the docs, it just makes sure
that the parser finds all files on Windows.
If there are any platform-specific identifiers, the docs have always
contained the linux-specific ones.
The patch changes nothing about this.
Ri
Graeme Geldenhuys schrieb:
I'm not sure how the Makefiles in the FPC_Docs repository generates
fpdoc parameters, but I found that I only need to specify the search
paths in the first --input parameter.
This doesn't look correct to me, at least not for the trunk fpdoc and
the RTL documentation
Michael Van Canneyt schrieb:
If there are any platform-specific identifiers, the docs have always
contained the linux-specific ones.
I'm just about to create a Windows version of the RTL docs. In contrast
to the assumption, that one XML file could hold descriptions of multiple
modules, I tes
On Fri, December 2, 2011 11:27, Michael Van Canneyt wrote:
> On Fri, 2 Dec 2011, Tomas Hajny wrote:
>> On Thu, December 1, 2011 13:27, michael.vancann...@wisa.be wrote:
>>> On Thu, 1 Dec 2011, Marco van de Voort wrote:
.
.
Afaik the docs are hardwired for Linux. Even if you are on host
On Fri, December 2, 2011 11:18, Marco van de Voort wrote:
> In our previous episode, Tomas Hajny said:
>>
>> Is this the right fix? Shouldn't it be possible to generate docs based
>> on
>> other targets as an option?
>
> What do you expect from that, other then that a few symbols disappear ?
> (tha
On 2 December 2011 12:43, Michael Van Canneyt wrote:
>
> You will be pleased to hear then, that we've developed - in FPC - a search
> engine for the HTML docs :-)
Excellent. How fast does it do searching across the RTL and FCL HTML
docs? Does it need to first build a search/keyword database?
I re
On 2 December 2011 09:05, Graeme Geldenhuys wrote:
> Excellent documentation means nothing if you can search and
> find something.
Typo alert!
The above should read: "Excellent documentation means nothing if you
_can't_ search it and find something."
--
Regards,
- Graeme -
__
On 1 December 2011 13:44, Michael Schnell wrote:
> I (tried to) use DocView (*.inf files) for local help. Seems very
> promising.
I've just released fpGUI v0.8. With that release comes pre-built
binaries for DocView, and pre-built documentation in INF format. You
can download them from the follo
On Fri, 2 Dec 2011, Graeme Geldenhuys wrote:
On 2 December 2011 12:43, Michael Van Canneyt wrote:
You will be pleased to hear then, that we've developed - in FPC - a search
engine for the HTML docs :-)
Excellent. How fast does it do searching across the RTL and FCL HTML
docs? Does it need
On Fri, 2 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
If there are any platform-specific identifiers, the docs have always
contained the linux-specific ones.
I'm just about to create a Windows version of the RTL docs. In contrast to
the assumption, that one XML file
Am 02.12.2011 17:21, schrieb Michael Van Canneyt:
This means that we can document platform-specific items in additional
files, which are automatically merged with the other descriptions. The
description file specifications can be extended by a platform
attribute, so that problems arising from mu
I'm not yet familiar with the new string model, and compiling fpdoc
results in a lot of Unicode conversion warnings.
When somebody tries to eliminate these warnings, DOMString deserves a
closer look - should it become an UnicodeString instead of WideString?
BTW Where can I learn more about th
On Fri, 2 Dec 2011, Sven Barth wrote:
Am 02.12.2011 17:21, schrieb Michael Van Canneyt:
This means that we can document platform-specific items in additional
files, which are automatically merged with the other descriptions. The
description file specifications can be extended by a platform
a
On Fri, 2 Dec 2011, Michael Van Canneyt wrote:
You would be far better off making separate tools that implement these
automatisms. You can write a e.g. tool that creates or updates a project file
based on a directory scan.
I have no problem including such tools in the FPC distribution, wherea
On 02.12.2011 19:37, Michael Van Canneyt wrote:
On Fri, 2 Dec 2011, Sven Barth wrote:
Am 02.12.2011 17:21, schrieb Michael Van Canneyt:
This means that we can document platform-specific items in additional
files, which are automatically merged with the other descriptions. The
description fi
Michael Van Canneyt schrieb:
This means that we can document platform-specific items in additional
files, which are automatically merged with the other descriptions. The
description file specifications can be extended by a platform
attribute, so that problems arising from multiple (platform sp
Sven Barth schrieb:
Out of curiosity: How could/would one create one documentation of source
which supports multiple platforms, but where there are identifiers that
are only available for some platforms? (like our RTL)
Right, that's a problem - but how many identifiers are really affected?
I
On Fri, 2 Dec 2011, Sven Barth wrote:
On 02.12.2011 19:37, Michael Van Canneyt wrote:
On Fri, 2 Dec 2011, Sven Barth wrote:
Am 02.12.2011 17:21, schrieb Michael Van Canneyt:
This means that we can document platform-specific items in additional
files, which are automatically merged with
On Fri, 2 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
This means that we can document platform-specific items in additional
files, which are automatically merged with the other descriptions. The
description file specifications can be extended by a platform attribute,
Michael Van Canneyt schrieb:
One objection is for instance that your proposal will cause all XML
files to be loaded both when FCL and RTL documentation are created.
Already included: all XML files are discarded, when they don't
contribute to the current package :-)
Because of the loose coup
Michael Van Canneyt schrieb:
I split the tool so the class that does the actual work can be
integrated in e.g. a GUI tool for quick manipulation of project files.
I expect and hope the tool will solve most - if not all - of the
problems you experienced as well.
A first note:
A commandline
27 matches
Mail list logo
