I see that Sven refactored the compiler and added texprflags. Thanks
Sven! I uploaded a new patch that takes advantage of texprflags.
/property-enumerator-4.patch/
On 31.10.2015 12:06, Jonas Maebe wrote:
* don't use the "is" operator unless there is absolutely no other way
to achieve the same
On 03.11.2015 11:55, Sven Barth wrote:
>> - extend comp_expr by another boolean parameter (which is set in
for_in_loop_create) and pass that down to factor (even better: convert
the boolean parameters of comp_expr, sub_expr and factor to a set,
would be cleaner anyway, IMHO) (pro: the state i
> On 02.11.2015 20:24, Sven Barth wrote:
>>>
>>> The only thing we need is a new flag/whatever so that
>>> *create_for_in_loop* knows that "tcallnode(expr)" contains an
enumerator
>>> function. tnode.flags seems to be full :( Do you have any suggestions?
>>> If we sort this out, 2 more arguments ag
First of all thanks Sven and Michael for the positive feedback! I was
already worried that I was completely misunderstood with the property
array enumerator extension.
About your 3 points, Sven:
On 02.11.2015 20:24, Sven Barth wrote:
The only thing we need is a new flag/whatever so that
*crea
On Tue, 3 Nov 2015, Ondrej Pokorny wrote:
On 02.11.2015 20:52, Sven Barth wrote:
I couldn't reproduce the previous example without arguments though (didn't
have the idea to try /more/ parameters). But the one you just showed is
troubling as well... would you please add that as an additional
On 02.11.2015 20:52, Sven Barth wrote:
I couldn't reproduce the previous example without arguments though
(didn't have the idea to try /more/ parameters). But the one you just
showed is troubling as well... would you please add that as an
additional example to the bug report that you'll hopeful
With pleasure :)
Yes it looks like if the parameter count matches, there is a compile
error (correct). If it doesn't match (there are less or more
parameters), it compiles (wrong).
Furthermore it doesn't only affect the getter but also the setter. All
possible combinations compile. See attac
On 02.11.2015 20:47, Ondrej Pokorny wrote:
On 02.11.2015 20:08, Sven Barth wrote:
It's not a general compiler bug, but only in relationship with helpers
(I can't trigger it if I have a class constructed that way without a
helper).
It is a general compiler bug. Not even related to a for-in or a
On 02.11.2015 20:08, Sven Barth wrote:
It's not a general compiler bug, but only in relationship with helpers
(I can't trigger it if I have a class constructed that way without a
helper).
It is a general compiler bug. Not even related to a for-in or anything else.
See:
*program arraypropbug;
On 01.11.2015 06:26, Ondrej Pokorny wrote:
+ I was wrong about the need to use "tenumeratornode". Actually you can
use "tcallnode" and get *pd* and *expr* for
*create_enumerator_for_in_loop* from its properties in function
*create_for_in_loop*:
expr:=tcallnode(expr).methodpointer;
pd:=tprocdef(tc
On 02.11.2015 16:12, Ondrej Pokorny wrote:
On 01.11.2015 21:03, Ondrej Pokorny wrote:
You cannot assign an array property to a variable. It does not exist
without the index parameter.
OK, there is a bug in ppc that allows to use an array property with *any
paramete**r(s)* (also no parameter).
On 01.11.2015 21:03, Ondrej Pokorny wrote:
You cannot assign an array property to a variable. It does not exist
without the index parameter.
OK, there is a bug in ppc that allows to use an array property with *any
paramete**r(s)* (also no parameter). Delphi does not allow it.
Actually ppc do
On 01.11.2015 16:38, Jonas Maebe wrote:
1) do you a) forbid an enumerator specification if the class already
has an enumerator
No, it's not needed.
b) hide the existing enumerator
No, it's not needed.
or c) allow enumerating both via the property and the original class
enumerator?
There can n
On 01.11.2015 16:38, Jonas Maebe wrote:
The basic issue is that you need extra context for supporting this
extension. Normally, an enumerator is searched based on the class
type. In your case, it's searched either based on the class type, or
if the class is returned from a property with an "enu
On 01/11/15 06:26, Ondrej Pokorny wrote:
On 01.11.2015 00:11, Jonas Maebe wrote:
On 31/10/15 21:28, Ondrej Pokorny wrote:
The argument that the tenumeratornode concept is completely different
from other nodes is correct - but if you think about the syntax you will
see that also the syntax is co
On 01.11.2015 00:11, Jonas Maebe wrote:
On 31/10/15 21:28, Ondrej Pokorny wrote:
The argument that the tenumeratornode concept is completely different
from other nodes is correct - but if you think about the syntax you will
see that also the syntax is completely different from other pascal
synta
On 31/10/15 21:28, Ondrej Pokorny wrote:
The argument that the tenumeratornode concept is completely different
from other nodes is correct - but if you think about the syntax you will
see that also the syntax is completely different from other pascal
syntax so you need such a unique node.
That
I have thought about the problem and I have some new ideas:
On 31.10.2015 12:06, Jonas Maebe wrote:
Independent of whether it will be integrated, there are definitely a
number things that should be changed first:
* don't use the "is" operator unless there is absolutely no other way
to achieve t
Thanks for the feedback!
Independent of whether it will be integrated, there are definitely a
number things that should be changed first:
* don't use the "is" operator unless there is absolutely no other way
to achieve the same effect. In the compiler, every node has a
"nodetype" field that ca
On 31/10/15 11:33, Ondrej Pokorny wrote:
Yes, indeed. It's always good to know that a patch will at least be
considered for including into the trunk before taking the step and
trying to write one. Otherwise it's wasted time ;)
Thanks for your tips! I uploaded a patch and commented on the issue
r
On 30.10.2015 19:38, Sven Barth wrote:
On 30.10.2015 16:01, Ondrej Pokorny wrote:
just out of curiosity, I wanted to play with the debugger and try to add
http://bugs.freepascal.org/view.php?id=28820
Seems like my little hint helped :P
Yes, indeed. It's always good to know that a patch will
On 30.10.2015 16:01, Ondrej Pokorny wrote:
just out of curiosity, I wanted to play with the debugger and try to add
http://bugs.freepascal.org/view.php?id=28820
Seems like my little hint helped :P
2.) I set run parameters to:
-MObjFPC -Scghi -O1 -g -gl -l -vewnhibq
-FiP:\programs\lazarus\_zk\
Got it working, wrong target directory!
Ondrej
___
fpc-devel maillist - [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hello,
just out of curiosity, I wanted to play with the debugger and try to add
http://bugs.freepascal.org/view.php?id=28820
As the first step, I want to debug the compiler while it is compiling my
simple project.
What I did:
1.) I opened "compiler\ppx86_64.lpi" from FPC trunk.
2.) I set r
24 matches
Mail list logo
