This never happened before when I generated fpdoc help for tiOPF. I tried
now with the latest fpdoc in Trunk (2.5.1) and I get the following errors.
I then tried with fpdoc from latest 2.4.1 branch and the same thing. The
last time I generated fpdoc help for the tiOPF project was 2009-05-28 and
the
The problem is in supporting the 'depecated' and other modifiers.
I have added support for that, but apparently, it breaks parsing
in other cases (the implementation is rather messy).
Please add bug reports for this, using small code samples.
Also, it is not necessary to report that the compile
In our previous episode, Michael Van Canneyt said:
>
> The problem is in supporting the 'depecated' and other modifiers.
> I have added support for that, but apparently, it breaks parsing
> in other cases (the implementation is rather messy).
>
> Please add bug reports for this, using small code
Marco van de Voort het geskryf:
>
> 1) I would particularly be interested if there is a difference between 2.4.1
> (say a week old maximally) and 2.5.1 (likewise). Before my holiday I
> committed a fix or two.
Marco, you are off the hook. :-)
Damn I love the 'git bisect' command. ;-) Anyway th
Marco van de Voort het geskryf:
>
> 1) I would particularly be interested if there is a difference between 2.4.1
> (say a week old maximally) and 2.5.1 (likewise). Before my holiday I
> committed a fix or two.
The 'deprecated' issue hasn't worked as far back as 2009-04 so I take it I
can safely a
Michael Van Canneyt het geskryf:
>
> Please add bug reports for this, using small code samples.
'label' and 'xxx of byte' syntax problems reported as:
http://bugs.freepascal.org/view.php?id=16476
The 'deprecated' issue has been reported as an FCL issue (due to fcl-passrc):
http://bugs.free
On Fri, 14 May 2010 14:33:57 +0200
Graeme Geldenhuys wrote:
> Marco van de Voort het geskryf:
> >
> > 1) I would particularly be interested if there is a difference between 2.4.1
> > (say a week old maximally) and 2.5.1 (likewise). Before my holiday I
> > committed a fix or two.
>
> Marco, you
Hi,
I tried using FPC 2.5.1 today to see how compatible is our application with
it compared to FPC 2.4.1
I got stacks of the following errors. Why is this change forced in FPC
2.5.1? TBulkInvoiceRateListForm class is a descendant of TfpgWindowBase so
there should be a problem. I don't understan
On Fri, 14 May 2010, Mattias Gaertner wrote:
On Fri, 14 May 2010 14:33:57 +0200
Graeme Geldenhuys wrote:
Marco van de Voort het geskryf:
1) I would particularly be interested if there is a difference between 2.4.1
(say a week old maximally) and 2.5.1 (likewise). Before my holiday I
commit
On Fri, May 14, 2010 at 11:45 AM, Graeme Geldenhuys
wrote:
> Hi,
>
> I tried using FPC 2.5.1 today to see how compatible is our application with
> it compared to FPC 2.4.1
>
> I got stacks of the following errors. Why is this change forced in FPC
> 2.5.1? TBulkInvoiceRateListForm class is a desc
On Fri, 14 May 2010, Graeme Geldenhuys wrote:
Hi,
I tried using FPC 2.5.1 today to see how compatible is our application with
it compared to FPC 2.4.1
I got stacks of the following errors. Why is this change forced in FPC
2.5.1? TBulkInvoiceRateListForm class is a descendant of TfpgWindowB
On Fri, 14 May 2010 16:45:50 +0200
Graeme Geldenhuys wrote:
>[...]
>
> I got similar issues with TStrings and TStringList. TStringList is a
> descendant of TStrings, but I can't pass a TStringList type as a parameter
> to a method declared with TStrings.
>
>
> Maybe I don't understand the var
On 14 May 2010 16:41, Mattias Gaertner wrote:
>
> I can send you my 49 smaller patches. But I doubt that would help.
Personally, I would have preferred that because it's easier to debug a
problem afterwards when things doesn't work. You have smaller commits
to work through. Having a 150K patch mea
On 14 May 2010 16:47, Michael Van Canneyt wrote:
>
> This is correct. I did (attempt to) add the support for it.
Either way using the same tiOPF code, with commit r14937 fpdoc did not
raise any error with the usage of 'label', but r14938 and onwards
does. If fcl-passrc parser 'label' correctly bef
On Fri, 14 May 2010 16:52:30 +0200
Graeme Geldenhuys wrote:
> On 14 May 2010 16:41, Mattias Gaertner wrote:
> >
> > I can send you my 49 smaller patches. But I doubt that would help.
>
> Personally, I would have preferred that because it's easier to debug a
> problem afterwards when things doesn
On Fri, 14 May 2010, Mattias Gaertner wrote:
On Fri, 14 May 2010 16:52:30 +0200
Graeme Geldenhuys wrote:
On 14 May 2010 16:41, Mattias Gaertner wrote:
I can send you my 49 smaller patches. But I doubt that would help.
Personally, I would have preferred that because it's easier to debug
On Fri, 14 May 2010 17:08:41 +0200 (CEST)
Michael Van Canneyt wrote:
>[...]
> > Probably because the former parser only parsed the interface.
> > Maybe fpdoc now tries to parse the implementation too? That's not
> > needed, is it?
>
> It should stop at the implementation keyword ?
Yes.
I think
On 14 May 2010, at 16:52, Mattias Gaertner wrote:
> "var" means, you can do this:
>
> type
> TQStrings = class(TStrings)
> end;
>
> procedure A(var s: TStrings);
> begin
> s:=TQStrings.Create;
> end;
>
> Then your TStringList will no longer be a TStringList. That's why 'var'
> must match ex
On 14 May 2010 17:08, Michael Van Canneyt wrote:
>>
>> Probably because the former parser only parsed the interface.
>> Maybe fpdoc now tries to parse the implementation too? That's not
>> needed, is it?
>
> It should stop at the implementation keyword ?
For fpdoc only! For other applications us
On 14 May 2010 17:07, Mattias Gaertner wrote:
>
> Well, I doubt that the patches would help here. I rewrote some parts
> multiple times.
'git bisect' would still have narrowed down the commit with the change
causing the problem. Smaller commits = easier to resolve a problem
introduced.
> Probabl
In our previous episode, Luiz Americo Pereira Camara said:
> > By this message I would like to encourage everybody to test recent
> > snapshots as much as possible, and also to see if previously made fixes are
> > propagated correctly.
> >
> > Note that not all 2.5.1 patches can be merged. Very lar
21 matches
Mail list logo
