[fpc-pascal] fpdoc is broken for LINK'ed documentation
Hi, I've been trying to figure this out all morning, and after 2 hours I still can't see why fpdoc doesn't work correctly. I have linked documentation in descendant classes - so as not to duplicate documentation in the XML description files. I currently use the IPF linear output writer, and DO specify the --duplinkeddoc parameter (which I originally implemented myself). It used to work, but now with FPC 2.6.1 and FPC 2.7.1 I can't get it to work at all. The nodes that have linked documentation doesn't even appear inside fpdoc as a TPasElement instance?? Thus putting a breakpoint inside TLinearWriter.WriteProperty() looking for a specific property name (eg: HelpFile) for example, is never reached.for the TfpgApplication class. This makes no sense. Here is a snippet of the XML description file. [ fpg_main.xml] element name=TfpgApplication shortA concrete class that encapsulates a fpGUI application/short /element element name=TfpgApplication.InvokeHelp link=#fpgui.fpg_base.TfpgApplicationBase.InvokeHelp shortfake/short /element element name=TfpgApplication.HelpFile link=#fpgui.fpg_base.TfpgApplicationBase.HelpFile shortfake/short /element --- The fpg_base.xml file does contain the documentation for the HelpFile and InvokeHelp topics. I can see them in the final IPF help output under the TfpgApplicationBase class. But the TfpgApplication class documentation doesn't contain either of those. What I have tried: * I changed the 'link' value by removing the package name, then by removing the unit name. Neither makes any difference. * I first had no 'short' description tags in the TfpgApplication elements, so add them to think that it might help fpdoc find those documentation elements. It made no difference. * I implemented a fpdoc project file, instead of using a script. That made no difference. * I tied various fpdoc output formats (HTML, TXT, RTF, IPF etc). That made no difference. Anybody got a clue what is going on? Is there some obvious (to others) that I am doing wrong? If you wanted to test this, all the fpdoc description files are in the fpGUI repository. You can pull it from the git repository, or if you don't have git installed, you can download a tarbal of the latest code from GitHub. Here is the direct link for the tarbal download: https://github.com/graemeg/fpGUI/tarball/master I also attached my test script I used to generate the IPF documentation. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net runme2.sh Description: Bourne shell script ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: xterm -e program-compiled-with-fpc2.4.0 doesn't work
Thank you for your tips and suggestions. It seems that FPSYSTEM from rtl-Sysutils is the 1:1 replacement for the old SHELL function but that made no difference to my problem. I dug out the previsious fpc version 1.9.4 from archive.debian.org which fortunately could be installed [for how long?] and hey presto: the good old xterm -e program runs again. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/xterm-e-program-compiled-with-fpc2-4-0-doesn-t-work-tp5519778p5527471.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: OT: Amazing new development tools
On 29/02/2012 11:44, Mark Morgan Lloyd wrote: Martin wrote: Sure one *could* record *all* variables, and the callstack... But what if - you add a new variable, what to initialize it with? - remove the function that called the current code, or even delete the line where you just paused? Or one could record all input, and replay the app. But that has limits too. Neither of those are likely to happen btw on some platforms, gdb can step backwards (again limitations apply). But it's not integrated in Lazarus yet... Noting what I described looking at in http://lists.freepascal.org/lists/fpc-other/2012-February/000670.html, I found myself wondering whether the IDE could tweak (writable?) constants at runtime, or possibly closures once they exist. Being able to tune e.g. the exact position of visible components could be rather useful. The evaluate dialog, offers a way to change values. Yes it is not at all comfortable ... And be warned, it performs no checks. Trying to change managed types (string, dyn array) will almost certainly crash your app. I guess, if you have a Form you can change it's values. Only to make those thinks visible on screen, it is not enough to change them. You need to call the setter. And calling functions from the debugger is not yet there... - If you work on the IDE itself try the package IdeInspector (it adds itself to view Ide Internals if installed) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Duplicate Identifier
On Thu, Mar 1, 2012 at 5:49 PM, Sven Barth pascaldra...@googlemail.com wrote:
On 01.03.2012 21:42, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 5:14 PM, Sven Barthpascaldra...@googlemail.com
wrote:
On 01.03.2012 16:34, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 4:29 AM, leledumboleledumbo_c...@yahoo.co.id
wrote:
That's different case IMHO (In My Humble Observation), I guess it's
something
like this:
{$mode objfpc}
type
TTestClass = class
FTile: Integer;
property Tile: Integer read FTile write FTile;
procedure Test;
end;
procedure TTestClass.Test;
var
Tile: Integer;
begin
end;
begin
end.
In this case, the local variable has the same name as one of the class
properties. This does trigger the duplicate identifier error because
both
have the same scope.
Well, for me the local Tile variable should have preference because
the scope is local, not global for class.
Would be equal the use of arguments, IMHO, where we can use an
identifier that already exists in the class.
In mode Delphi this is true, but in non-Delphi modes it was decided that
the
above code is not allowed at all to avoid any disambiguities that might
arise.
Regards,
Sven
So, I have to invent a prefix or suffix in all local variables to
avoid problems if I add a property with same name in the future,
right?
ex:
lTile: Integer
Tile1: Integer
vTile: Integer
...well, I already do that, but I don't think this is correct.
The compiler will generate an error if you do add a property with the same
name, so you can change the name of the variable in the method on demand.
But if I have many methods with a identifier like Value, I will have
to modify all methods and put something like lValue, Value1, etc.
Also note that this feature is not a recent one. This is part of FPC AFAIK
at least since 2.2.0 (which is the first version I used). So if you didn't
encounter the problem yet, maybe you never will ;)
I had problems. I use FPC 2.6. Because that problems I'm using such
abstract prefix in all local variables.. =|
Marcos Douglas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Duplicate Identifier
But if I have many methods with a identifier like Value, I will have to modify all methods and put something like lValue, Value1, etc. Trust me, that's MUCH better than letting the compiler compiles wrong code. i.e. it refers to identifier we don't mean to refer. I've had a lot of this before and the compiler really helps here to avoid hidden error. I usually don't use prefix on identifiers but rename it to something more appropriate (or specific) instead. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Re-Duplicate-Identifier-tp5526700p5531014.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Duplicate Identifier
On Fri, Mar 2, 2012 at 10:48 AM, leledumbo leledumbo_c...@yahoo.co.id wrote: But if I have many methods with a identifier like Value, I will have to modify all methods and put something like lValue, Value1, etc. Trust me, that's MUCH better than letting the compiler compiles wrong code. i.e. it refers to identifier we don't mean to refer. I've had a lot of this before and the compiler really helps here to avoid hidden error. I usually don't use prefix on identifiers but rename it to something more appropriate (or specific) instead. The prefix approach pattern is used a long time in arguments, e.g., AValue (I prefer aValue). We do not have case-sensitive so, everything should have a prefix or something to distinguish an indentifier of other (types, classes, interfaces, units, etc); I'm just following the pattern of language. ;-) Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Duplicate Identifier
Am 02.03.2012 13:23, schrieb Marcos Douglas:
On Thu, Mar 1, 2012 at 5:49 PM, Sven Barthpascaldra...@googlemail.com wrote:
On 01.03.2012 21:42, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 5:14 PM, Sven Barthpascaldra...@googlemail.com
wrote:
On 01.03.2012 16:34, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 4:29 AM, leledumboleledumbo_c...@yahoo.co.id
wrote:
That's different case IMHO (In My Humble Observation), I guess it's
something
like this:
{$mode objfpc}
type
TTestClass = class
FTile: Integer;
property Tile: Integer read FTile write FTile;
procedure Test;
end;
procedure TTestClass.Test;
var
Tile: Integer;
begin
end;
begin
end.
In this case, the local variable has the same name as one of the class
properties. This does trigger the duplicate identifier error because
both
have the same scope.
Well, for me the local Tile variable should have preference because
the scope is local, not global for class.
Would be equal the use of arguments, IMHO, where we can use an
identifier that already exists in the class.
In mode Delphi this is true, but in non-Delphi modes it was decided that
the
above code is not allowed at all to avoid any disambiguities that might
arise.
Regards,
Sven
So, I have to invent a prefix or suffix in all local variables to
avoid problems if I add a property with same name in the future,
right?
ex:
lTile: Integer
Tile1: Integer
vTile: Integer
...well, I already do that, but I don't think this is correct.
The compiler will generate an error if you do add a property with the same
name, so you can change the name of the variable in the method on demand.
But if I have many methods with a identifier like Value, I will have
to modify all methods and put something like lValue, Value1, etc.
If the methods belong to a class where you introdouced a Value field
or property, yes, you'll either need to change the variable/parameter of
the method or choose a different name for the field/property.
Also note that this feature is not a recent one. This is part of FPC AFAIK
at least since 2.2.0 (which is the first version I used). So if you didn't
encounter the problem yet, maybe you never will ;)
I had problems. I use FPC 2.6. Because that problems I'm using such
abstract prefix in all local variables.. =|
As I said: this feature is older than my first usage of FPC. So you'll
have to life with it as we all need to (yes, I would know how to disable
it and no, I don't want to). If you want to use ambitious naming then
use mode Delphi.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Variant vs Pointer
On Wed, Feb 29, 2012 at 10:38 PM, Marcos Douglas m...@delfire.net wrote: Hi, The TField class have the FValueBuffer: Pointer attribute and have also SetData(Buffer: Pointer,...) method that all T***Field subclasses use to set themselves. The methods AsInteger, AsString, etc use FValueBuffer to convert in an especific type. So, FValueBuffer could be anything. My question is: What would be the difference in performance if FValueBuffer were a Variant type? Marcos Douglas Nobody knows? I need implements a similar structure but I need know if the use of Variant have very cost. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Duplicate Identifier
On Fri, Mar 2, 2012 at 10:39 AM, Sven Barth pascaldra...@googlemail.com wrote:
Am 02.03.2012 13:23, schrieb Marcos Douglas:
On Thu, Mar 1, 2012 at 5:49 PM, Sven Barthpascaldra...@googlemail.com
wrote:
On 01.03.2012 21:42, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 5:14 PM, Sven Barthpascaldra...@googlemail.com
wrote:
On 01.03.2012 16:34, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 4:29 AM, leledumboleledumbo_c...@yahoo.co.id
wrote:
That's different case IMHO (In My Humble Observation), I guess it's
something
like this:
{$mode objfpc}
type
TTestClass = class
FTile: Integer;
property Tile: Integer read FTile write FTile;
procedure Test;
end;
procedure TTestClass.Test;
var
Tile: Integer;
begin
end;
begin
end.
In this case, the local variable has the same name as one of the
class
properties. This does trigger the duplicate identifier error
because
both
have the same scope.
Well, for me the local Tile variable should have preference because
the scope is local, not global for class.
Would be equal the use of arguments, IMHO, where we can use an
identifier that already exists in the class.
In mode Delphi this is true, but in non-Delphi modes it was decided
that
the
above code is not allowed at all to avoid any disambiguities that might
arise.
Regards,
Sven
So, I have to invent a prefix or suffix in all local variables to
avoid problems if I add a property with same name in the future,
right?
ex:
lTile: Integer
Tile1: Integer
vTile: Integer
...well, I already do that, but I don't think this is correct.
The compiler will generate an error if you do add a property with the
same
name, so you can change the name of the variable in the method on demand.
But if I have many methods with a identifier like Value, I will have
to modify all methods and put something like lValue, Value1, etc.
If the methods belong to a class where you introdouced a Value field or
property, yes, you'll either need to change the variable/parameter of the
method or choose a different name for the field/property.
Also note that this feature is not a recent one. This is part of FPC
AFAIK
at least since 2.2.0 (which is the first version I used). So if you
didn't
encounter the problem yet, maybe you never will ;)
I had problems. I use FPC 2.6. Because that problems I'm using such
abstract prefix in all local variables.. =|
As I said: this feature is older than my first usage of FPC. So you'll have
to life with it as we all need to (yes, I would know how to disable it and
no, I don't want to). If you want to use ambitious naming then use mode
Delphi.
OK Sven, I already understood.
One more question: why this feature isn't works when used with arguments?
The arguments could have the same name of a property.
Marcos Douglas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Variant vs Pointer
On Fri, 2 Mar 2012, Marcos Douglas wrote: On Wed, Feb 29, 2012 at 10:38 PM, Marcos Douglas m...@delfire.net wrote: Hi, The TField class have the FValueBuffer: Pointer attribute and have also SetData(Buffer: Pointer,...) method that all T***Field subclasses use to set themselves. The methods AsInteger, AsString, etc use FValueBuffer to convert in an especific type. So, FValueBuffer could be anything. My question is: What would be the difference in performance if FValueBuffer were a Variant type? Marcos Douglas Nobody knows? I need implements a similar structure but I need know if the use of Variant have very cost. It has a cost. The reason for using a buffer in tdataset is that a record's data normally is located in one continuous buffer, from which a value is picked from the right spot (including strings) You can't have that with variants. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Duplicate Identifier
Am 02.03.2012 16:48 schrieb Marcos Douglas m...@delfire.net:
On Fri, Mar 2, 2012 at 10:39 AM, Sven Barth pascaldra...@googlemail.com
wrote:
Am 02.03.2012 13:23, schrieb Marcos Douglas:
On Thu, Mar 1, 2012 at 5:49 PM, Sven Barthpascaldra...@googlemail.com
wrote:
On 01.03.2012 21:42, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 5:14 PM, Sven Barth
pascaldra...@googlemail.com
wrote:
On 01.03.2012 16:34, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 4:29 AM, leledumbo
leledumbo_c...@yahoo.co.id
wrote:
That's different case IMHO (In My Humble Observation), I guess
it's
something
like this:
{$mode objfpc}
type
TTestClass = class
FTile: Integer;
property Tile: Integer read FTile write FTile;
procedure Test;
end;
procedure TTestClass.Test;
var
Tile: Integer;
begin
end;
begin
end.
In this case, the local variable has the same name as one of the
class
properties. This does trigger the duplicate identifier error
because
both
have the same scope.
Well, for me the local Tile variable should have preference
because
the scope is local, not global for class.
Would be equal the use of arguments, IMHO, where we can use an
identifier that already exists in the class.
In mode Delphi this is true, but in non-Delphi modes it was decided
that
the
above code is not allowed at all to avoid any disambiguities that
might
arise.
Regards,
Sven
So, I have to invent a prefix or suffix in all local variables to
avoid problems if I add a property with same name in the future,
right?
ex:
lTile: Integer
Tile1: Integer
vTile: Integer
...well, I already do that, but I don't think this is correct.
The compiler will generate an error if you do add a property with the
same
name, so you can change the name of the variable in the method on
demand.
But if I have many methods with a identifier like Value, I will have
to modify all methods and put something like lValue, Value1, etc.
If the methods belong to a class where you introdouced a Value field
or
property, yes, you'll either need to change the variable/parameter of
the
method or choose a different name for the field/property.
Also note that this feature is not a recent one. This is part of FPC
AFAIK
at least since 2.2.0 (which is the first version I used). So if you
didn't
encounter the problem yet, maybe you never will ;)
I had problems. I use FPC 2.6. Because that problems I'm using such
abstract prefix in all local variables.. =|
As I said: this feature is older than my first usage of FPC. So you'll
have
to life with it as we all need to (yes, I would know how to disable it
and
no, I don't want to). If you want to use ambitious naming then use mode
Delphi.
OK Sven, I already understood.
One more question: why this feature isn't works when used with arguments?
The arguments could have the same name of a property.
Normally it should work with arguments as well, but there is a bug if you
define a property with an identifier that's used in a method that was
defined before the property. In that latter case the check does not work.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Variant vs Pointer
On Fri, Mar 2, 2012 at 1:02 PM, michael.vancann...@wisa.be wrote: On Fri, 2 Mar 2012, Marcos Douglas wrote: On Wed, Feb 29, 2012 at 10:38 PM, Marcos Douglas m...@delfire.net wrote: Hi, The TField class have the FValueBuffer: Pointer attribute and have also SetData(Buffer: Pointer,...) method that all T***Field subclasses use to set themselves. The methods AsInteger, AsString, etc use FValueBuffer to convert in an especific type. So, FValueBuffer could be anything. My question is: What would be the difference in performance if FValueBuffer were a Variant type? Marcos Douglas Nobody knows? I need implements a similar structure but I need know if the use of Variant have very cost. It has a cost. The reason for using a buffer in tdataset is that a record's data normally is located in one continuous buffer, from which a value is picked from the right spot (including strings) You can't have that with variants. Hm... right. So, if I will have a class like a TParam, that have FValue: Variant attribute, Would you change the implementation to not use Variant? Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Duplicate Identifier
On 02.03.2012 20:03, Sven Barth wrote:
One more question: why this feature isn't works when used with arguments?
The arguments could have the same name of a property.
Normally it should work with arguments as well, but there is a bug if
you define a property with an identifier that's used in a method that
was defined before the property. In that latter case the check does not
work.
To illustrate this a bit:
=== source begin ===
program dupidenttest;
{$mode objfpc}
type
TTest1 = class
fFoo: LongInt;
property Foo: LongInt read fFoo;
procedure Bar(Foo: LongInt);
end;
TTest2 = class
fFoo: LongInt;
procedure Bar(Foo: LongInt);
property Foo: LongInt read fFoo;
end;
procedure TTest1.Bar(Foo: LongInt);
begin
end;
procedure TTest2.Bar(Foo: LongInt);
begin
end;
begin
end.
=== source end ===
results in the following compiler output:
=== output begin ===
Free Pascal Compiler version 2.6.0 [2011/12/23] for i386
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Linux for i386
Compiling dupidenttest.pas
dupidenttest.pas(9,19) Error: Duplicate identifier Foo
dupidenttest.pas(31) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /mnt/data/applications/fpc/2.6.0/bin/ppc386 returned an error
exitcode (normal if you did not specify a source file to be compiled)
=== output end ===
If I comment out TTest1 then the program compiles successfully.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Duplicate Identifier
On Fri, Mar 2, 2012 at 5:14 PM, Sven Barth pascaldra...@googlemail.com wrote:
On 02.03.2012 20:03, Sven Barth wrote:
One more question: why this feature isn't works when used with
arguments?
The arguments could have the same name of a property.
Normally it should work with arguments as well, but there is a bug if
you define a property with an identifier that's used in a method that
was defined before the property. In that latter case the check does not
work.
To illustrate this a bit:
=== source begin ===
program dupidenttest;
{$mode objfpc}
type
TTest1 = class
fFoo: LongInt;
property Foo: LongInt read fFoo;
procedure Bar(Foo: LongInt);
end;
TTest2 = class
fFoo: LongInt;
procedure Bar(Foo: LongInt);
property Foo: LongInt read fFoo;
end;
procedure TTest1.Bar(Foo: LongInt);
begin
end;
procedure TTest2.Bar(Foo: LongInt);
begin
end;
begin
end.
=== source end ===
results in the following compiler output:
=== output begin ===
Free Pascal Compiler version 2.6.0 [2011/12/23] for i386
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Linux for i386
Compiling dupidenttest.pas
dupidenttest.pas(9,19) Error: Duplicate identifier Foo
dupidenttest.pas(31) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /mnt/data/applications/fpc/2.6.0/bin/ppc386 returned an error
exitcode (normal if you did not specify a source file to be compiled)
=== output end ===
If I comment out TTest1 then the program compiles successfully.
Regards,
Sven
OK.
Well, the safe way is using a prefix/suffix in everything.
Thanks for the example.
Marcos Douglas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] Re: Variant vs Pointer
I need implements a similar structure but I need know if the use of Variant have very cost. It has a cost. The reason for using a buffer in tdataset is that a record's data normally is located in one continuous buffer, from which a value is picked from the right spot (including strings) You can't have that with variants. Hm... right. So, if I will have a class like a TParam, that have FValue: Variant attribute, Would you change the implementation to not use Variant? Not sure what you want to do but as Michael explained, the internal format in tdataset is very much linked to the source of the data. Databases don't understand pascal variants. They use only strictly typed data on the wire. Using a variant as an internal format would only introduce overhead and eventually data loss (fe. precision on decimals) without any gain. The TField variant properties should be considered a convenience only and be avoided as much as possible. If your new class has no links with the outside world you can use whatever you want. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
