Am 15.10.2019 um 23:46 schrieb Ryan Joseph:
On Oct 15, 2019, at 5:26 PM, Benito van der Zander wrote:
you could do
var
it: pointer;
obj: TObject absolute it;
begin
for it in list do
begin
// continue on like before using “obj” instead of “it"
end;
That is a clever
> On Oct 15, 2019, at 6:13 PM, Michael Van Canneyt
> wrote:
>
> Of course there is: make the list the correct type. No typecasting needed
> then.
I guess I’ll get used to it but we have lots of code like this (snippet I
posted earlier from the parser):
Declarations: TFPList; // list of
On Tue, 15 Oct 2019, Ryan Joseph wrote:
On Oct 15, 2019, at 5:26 PM, Benito van der Zander wrote:
you could do
var
it: pointer;
obj: TObject absolute it;
begin
for it in list do
begin
// continue on like before using “obj” instead of “it"
end;
That is a clever solu
> On Oct 15, 2019, at 5:26 PM, Benito van der Zander wrote:
>
> you could do
>
> var
> it: pointer;
> obj: TObject absolute it;
> begin
> for it in list do
> begin
> // continue on like before using “obj” instead of “it"
> end;
>
That is a clever solution but it’s basical
On Tue, 15 Oct 2019, Benito van der Zander wrote:
Hi,
On 14.10.19 15:44, Ryan Joseph wrote:
var
it: pointer;
obj: TObject;
begin
for it in list do
begin
obj := TObject(it);
// continue on like before using “obj” instead of “it"
end;
That’s our realistic bes
On Tue, 15 Oct 2019, Ryan Joseph wrote:
On Oct 15, 2019, at 5:02 PM, Mattias Gaertner via fpc-pascal
wrote:
When parsing a program the module is a TPasProgram, which has a
ProgramSection.
Of course, thanks.
A couple other questions if you don’t mind:
1) Are there any examples of the
Hi,
On 14.10.19 15:44, Ryan Joseph wrote:
var
it: pointer;
obj: TObject;
begin
for it in list do
begin
obj := TObject(it);
// continue on like before using “obj” instead of “it"
end;
That’s our realistic best use case now but it requires 2 extra steps. I hope
> On Oct 15, 2019, at 5:02 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> When parsing a program the module is a TPasProgram, which has a
> ProgramSection.
Of course, thanks.
A couple other questions if you don’t mind:
1) Are there any examples of the resolver? I’m looking through the uni
On Tue, 15 Oct 2019 16:38:35 -0400
Ryan Joseph wrote:
> Another related question about functions.
>
> In unit files there is a InterfaceSection/ImplementationSection in
> TPasModule and I can use those to get a list of functions (because
> they descend from TPasSection). In a program file there
Another related question about functions.
In unit files there is a InterfaceSection/ImplementationSection in TPasModule
and I can use those to get a list of functions (because they descend from
TPasSection). In a program file there only seems to be a InitializationSection
but this doesn’t cont
> On Oct 14, 2019, at 8:02 AM, Sven Barth via fpc-pascal
> wrote:
>
> No. Nothing of that. There is a variable in the for-in-loop and nothing more.
> Anything else currently is a bug and *will* break.
>
I don’t disagree with anything you’re saying but this is going to make for-in
loops mu
On Mon, 14 Oct 2019 14:02:44 +0200
Sven Barth via fpc-pascal wrote:
> Mattias Gaertner via fpc-pascal
> schrieb am Mo., 14. Okt. 2019, 10:39:
>[...]
> First you agree with me and then you provide in essence the same
> examples as Ryan? So what is it now?
Ryan gave several examples.
I agreed wit
Mattias Gaertner via fpc-pascal schrieb
am Mo., 14. Okt. 2019, 10:39:
> On Mon, 14 Oct 2019 07:37:38 +0200
> Sven Barth via fpc-pascal wrote:
>
> >[...]
> > Because the iterator returns a Pointer and not whatever you think it
> > might return. If you know it's something else, you cast that insid
On Mon, 14 Oct 2019, Mattias Gaertner via fpc-pascal wrote:
On Mon, 14 Oct 2019 07:37:38 +0200
Sven Barth via fpc-pascal wrote:
[...]
Because the iterator returns a Pointer and not whatever you think it
might return. If you know it's something else, you cast that inside
the loop.
I agre
On Sun, 13 Oct 2019 23:13:04 +0200 (CEST)
Michael Van Canneyt wrote:
>[...]
> The resolver is implemented in pasresolver.pp and pasresolveeval.pas
> (but I think you'll only need the former)
The latter is used by the former.
Note that the resolver can only parse whole modules, not mere
expressio
On Mon, 14 Oct 2019 07:37:38 +0200
Sven Barth via fpc-pascal wrote:
>[...]
> Because the iterator returns a Pointer and not whatever you think it
> might return. If you know it's something else, you cast that inside
> the loop.
I agree with Sven.
What about the other way round?
For example th
Am 13.10.2019 um 23:19 schrieb Ryan Joseph:
On Oct 13, 2019, at 11:11 AM, Sven Barth via fpc-pascal
wrote:
Then specialize the list with the correct type.
This issue *will* be fixed and is not up to discussion.
Here’s some code from the parser today. TFPList is being used because it’s a
> On Oct 13, 2019, at 11:11 AM, Sven Barth via fpc-pascal
> wrote:
>
> Then specialize the list with the correct type.
>
> This issue *will* be fixed and is not up to discussion.
>
Here’s some code from the parser today. TFPList is being used because it’s a
generic storage for various di
On Sun, 13 Oct 2019, Ryan Joseph wrote:
One of my tasks for the language server is determining “references” to a
symbol, which means for functions I need to know all the times they were called.
Given the syntax tree the parser creates how do I know when a function was
called? I see there is
On Sun, 13 Oct 2019, Ryan Joseph wrote:
On Oct 13, 2019, at 12:30 PM, Michael Van Canneyt
wrote:
Ahah...
That needs to be tested then. This seems to be a bug. Can you please create
a bug with a compilable example ?
- Please test the operator because I don’t think the parser understand
One of my tasks for the language server is determining “references” to a
symbol, which means for functions I need to know all the times they were called.
Given the syntax tree the parser creates how do I know when a function was
called? I see there is a TPasImplSimple that seems related but I’m
> On Oct 13, 2019, at 12:30 PM, Michael Van Canneyt
> wrote:
>
> Ahah...
>
> That needs to be tested then. This seems to be a bug. Can you please create
> a bug with a compilable example ?
>
>> - Please test the operator because I don’t think the parser understands it.
>
> OK, that's strang
On Sun, 13 Oct 2019, Michael Van Canneyt wrote:
- This is a new version from 3 days ago.
- The record sections failed because they are inside a function. If I pull
the record out of the function they work.
Ahah...
That needs to be tested then. This seems to be a bug. Can you please creat
On Sun, 13 Oct 2019, Ryan Joseph wrote:
To be clear:
here I meant that 'currently that will definitely not be done in fcl-passrc.'
This is a problem then because I wanted to make a language server for FPC
but if the parser doesn’t understand accepted FPC syntax the whole thing
falls apart.
Ryan Joseph schrieb am So., 13. Okt. 2019, 16:22:
>
>
> > On Oct 13, 2019, at 5:58 AM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> >> Delphi does not allow it:
> >>
> >> [dcc32 Error] Project1.dpr(18): E1019 For loop control variable must be
> simple local variable
> On Oct 13, 2019, at 5:58 AM, Sven Barth via fpc-pascal
> wrote:
>
>> Delphi does not allow it:
>>
>> [dcc32 Error] Project1.dpr(18): E1019 For loop control variable must be
>> simple local variable
>>
>> I don't think this should be allowed, either.
>
> Same.
Why not?
I just had this p
> On Oct 13, 2019, at 6:18 AM, Michael Van Canneyt
> wrote:
>
>>> Well spotted. I didn't notice that the extension was missing.
>>>
>>> That will definitely not be done in fcl-passrc.
>
> To be clear:
>
> here I meant that 'currently that will definitely not be done in fcl-passrc.'
This i
On Sun, 13 Oct 2019, Sven Barth via fpc-pascal wrote:
Could the missing ".inc" be the problem? I have not checked, but it
could
be that FPC always adds ".inc" if no extension is present.
Well spotted. I didn't notice that the extension was missing.
That will definitely not be done in fcl-p
Am 13.10.2019 um 11:26 schrieb Michael Van Canneyt:
On Sun, 13 Oct 2019, Sven Barth via fpc-pascal wrote:
Just type casting because the array is an array of pointers. I get
these
errors otherwise "Incompatible types: got "Pointer"
expected “TEntity"”. I could use a proper type in a generic a
On Sun, 13 Oct 2019, Sven Barth via fpc-pascal wrote:
Just type casting because the array is an array of pointers. I get these
errors otherwise "Incompatible types: got "Pointer"
expected “TEntity"”. I could use a proper type in a generic array but I
don’t always do that.
I didn't know you
Michael Van Canneyt schrieb am So., 13. Okt. 2019,
08:20:
> > 2) For..in loops
> >
> > EParserError: Expected := or in at token "(" in file
> >
>
> /Users/ryanjoseph/Developer/Projects/FPC/NewEngine/Sources/Examples/EmptyWindow.pas
> at line 138 column
> > 1
On Sat, 12 Oct 2019, Ryan Joseph wrote:
On Oct 12, 2019, at 6:43 PM, Michael Van Canneyt
wrote:
1) class operators for records
EParserError: Expected "procedure" at token "operator" in file
/Users/ryanjoseph/Developer/Projects/FPC/GLCanvas/GLCanv
On Oct 12, 2019, at 6:43 PM, Michael Van Canneyt wrote:1) class operators for recordsEParserError: Expected "procedure" at token "operator" in file /Users/ryanjoseph/Developer/Projects/FPC/GLCanvas/GLCanvas.pas at line 115 column 7class operator TVertex3.= (constref a, b: TVertex3): boolean;beginr
On Sat, 12 Oct 2019, Ryan Joseph wrote:
More tests with the parser but it seems like it doesn’t know quite a bit of
syntax. Are these not implemented yet?
1) class operators for records
EParserError: Expected "procedure" at token "operator" in file
/Users/ryanjoseph/Developer/Projects/FPC/
More tests with the parser but it seems like it doesn’t know quite a bit of
syntax. Are these not implemented yet?
1) class operators for records
EParserError: Expected "procedure" at token "operator" in file
/Users/ryanjoseph/Developer/Projects/FPC/GLCanvas/GLCanvas.pas at line 115
column 7
On Wed, 2 Oct 2019, Ryan Joseph wrote:
On Oct 2, 2019, at 10:37 AM, Michael Van Canneyt wrote:
Correct, it is not supported.
I’ll try to implement this then if I can figure out the parser. It’s really not
that much extra syntax actually.
No it is not, but you'll have to introduce a n
> On Oct 2, 2019, at 10:37 AM, Michael Van Canneyt
> wrote:
>
> Correct, it is not supported.
I’ll try to implement this then if I can figure out the parser. It’s really not
that much extra syntax actually.
Regards,
Ryan Joseph
___
fpc-p
Michael Van Canneyt schrieb am Mi., 2. Okt. 2019,
16:37:
>
>
> On Wed, 2 Oct 2019, Ryan Joseph wrote:
>
> > How well can the parser handle the objective-c mode? At my first attempt
> it seemed to fail pretty early on so I’m not sure it’s even supported.
>
> Correct, it is not supported.
>
> I don
On Wed, 2 Oct 2019, Ryan Joseph wrote:
How well can the parser handle the objective-c mode? At my first attempt it
seemed to fail pretty early on so I’m not sure it’s even supported.
Correct, it is not supported.
I don't even know what the allowed syntax is. From your example I see
'requir
How well can the parser handle the objective-c mode? At my first attempt it
seemed to fail pretty early on so I’m not sure it’s even supported.
EParserError: Expected ";" at token "Identifier external" in file
/Developer/ObjectivePascal/MacOS_10_10/appkit/NSAccessibilityProtocols.inc at
line 31
Am 03.11.2017 um 15:31 schrieb Michael Van Canneyt:
> In this case, you can probably simply use
> TPasTreeContainer.FinishScope
> to record the end of the method.
Great, this is easy. I have created (and attached) a patch to add a
SourceEndLinenummer for all elements.
Maybe it is useful for others
On Fri, 3 Nov 2017, Michael Fuchs wrote:
Sorry, some message were not sent to list, my fault:
Am 03.11.2017 um 14:132 schrieb Michael Van Canneyt:
Are there plans for a support in future? Or can you give me some
advices how I can implement this by myself? I'm afraid I am an
absolutly newb
Sorry, some message were not sent to list, my fault:
Am 03.11.2017 um 14:132 schrieb Michael Van Canneyt:
>> Are there plans for a support in future? Or can you give me some
>> advices how I can implement this by myself? I'm afraid I am an
>> absolutly newbie in this part of of the FCL.>
> Ther
On Fri, 3 Nov 2017, Michael Fuchs wrote:
Hi,
a question to TPasElement of fcl-passrc:
To get the line in which the element starts I use the public
SourceLinenumber field. But how do I get the last line of this element?
Currently this is not supported.
Michael.
Hi,
a question to TPasElement of fcl-passrc:
To get the line in which the element starts I use the public
SourceLinenumber field. But how do I get the last line of this element?
g
Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http
On Thu, 12 Jul 2012, Seth Grover wrote:
Greetings! I've been using fcl-passrc (PParser and PasTree) to create
a tool to help me with coverage analysis. Using the example provided
in the package directory as a starting point, I've created a tool
which finds the "begin" line number for each func
Greetings! I've been using fcl-passrc (PParser and PasTree) to create
a tool to help me with coverage analysis. Using the example provided
in the package directory as a starting point, I've created a tool
which finds the "begin" line number for each function/procedure
definition and inserts a line
On Wed, Aug 25, 2010 at 11:54 AM, Graeme Geldenhuys
wrote:
> Thanks Dmitry, you can go ahead. I'm still busy with fpdoc and DocView fixes.
Passrc should be able to parse "program" units now. At least it
shouldn't be failing with error.
Program modules doesn't have interface part filled, implement
Op 2010-08-25 09:05, dmitry boyarintsev het geskryf:
>
> How's your progress Graeme? I can do this in the weekend (28th-29th).
Thanks Dmitry, you can go ahead. I'm still busy with fpdoc and DocView fixes.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
On Tue, Aug 24, 2010 at 9:45 PM, Graeme Geldenhuys
wrote:
> It's not implemented yet - just like fcl-passrc can't parse Program
> units either. Based on what I found while looking what to implement
> for Program unit parsing, it doesn't seem that difficult. Time
> permitting, I'll try and impleme
On 24 August 2010 18:29, Matthias Klumpp wrote:
> (In ParseSource() call)
> How do I make FCL-PASSRC process the lib source code too?
It's not implemented yet - just like fcl-passrc can't parse Program
units either. Based on what I found while looking what to implement
for Program unit parsing,
Hi!
At time I'm playing around with fcl-passrc to automate some actions I have
to perform with the source code.
Unfortunately, FCL-PASSRC does not process the source of a library:
Expected "unit" at token "library"
(In ParseSource() call)
How do I make FCL-PASSRC process the lib source code too?
On 28 Apr 2010, at 09:26, Michael Van Canneyt wrote:
Good idea. Are all possible constructs in FPC in the testsuite ?
Probably not, but a lot of them are.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.o
In our previous episode, Florian Klaempfl said:
> > I created a VERY small test sample in utils/fpdoc, it tests 'strange'
> > cases. It would indeed be a good idea to create a testsuite in
> > fcl-passrc itself.
>
> Wouldn't it be enough just to let it scan/parse the whole fpc test suite :)?
That
On Wed, 28 Apr 2010, Florian Klaempfl wrote:
Michael Van Canneyt schrieb:
On Tue, 27 Apr 2010, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
As soon as I get around to some bugfixing, I'll have a look at these.
Shouldn't we create some testsuite for fcl-
Michael Van Canneyt schrieb:
>
>
> On Tue, 27 Apr 2010, Marco van de Voort wrote:
>
>> In our previous episode, Michael Van Canneyt said:
>>>
>>> As soon as I get around to some bugfixing, I'll have a look at these.
>>
>> Shouldn't we create some testsuite for fcl-passrc? (or have a flag in the
On Tue, 27 Apr 2010, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
As soon as I get around to some bugfixing, I'll have a look at these.
Shouldn't we create some testsuite for fcl-passrc? (or have a flag in the
existing testsuite to exclude tests from fcl-pas
In our previous episode, Michael Van Canneyt said:
>
> As soon as I get around to some bugfixing, I'll have a look at these.
Shouldn't we create some testsuite for fcl-passrc? (or have a flag in the
existing testsuite to exclude tests from fcl-passrc or real compiler tests
or so?)
_
On Tue, 27 Apr 2010, Sven Barth wrote:
Hi!
On 27.04.2010 17:19, Michael Van Canneyt wrote:
Also, program files are not parsed by fcl-passrc, it's limited to units
for now. We would like to be able to eventually parse program files too.
I am all for it. It should not be hard to handle thi
Hi!
On 27.04.2010 17:19, Michael Van Canneyt wrote:
Also, program files are not parsed by fcl-passrc, it's limited to units
for now. We would like to be able to eventually parse program files too.
I am all for it. It should not be hard to handle this; It's like parsing
an implementation bloc
On Mon, 26 Apr 2010, Michalis Kamburelis wrote:
All the talk about the Pascal parser in fcl-passrc got me interested
recently. I did some experiments, and I thought I mention here:
1. I added a simplest example how to use fcl-passrc to the wiki:
http://wiki.freepascal.org/fcl-passrc
This i
All the talk about the Pascal parser in fcl-passrc got me interested
recently. I did some experiments, and I thought I mention here:
1. I added a simplest example how to use fcl-passrc to the wiki:
http://wiki.freepascal.org/fcl-passrc
2. And reported a couple of bugs found in fpdoc (tested on P
On Fri, 4 Sep 2009, yu ping wrote:
Is there a example using FCL-PASSRC?
Yes. utils/fpdoc contains some.
Michael.___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Is there a example using FCL-PASSRC?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
64 matches
Mail list logo
