Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2011-04

"helper" feature finished

32 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Sven Barth

Hello together!

Today I have run the final tests on the helper branch and I'm satisfied with their results, thus I'd like you to review and hopefully merge my work. The wiki page I have started will be updated as soon as I find the time.

Both "class helpers" and "record helpers" are implemented and work as Delphi compatible as reasonably possible.

The following differences (that I'm aware of) exist:

* in mode ObjFPC the method modifiers "message", "virtual", "override", "final" and "reintroduce" are forbidden as they can't be used in a useful way for helpers anyway (they are ignored in mode Delphi).("abstract" is rejected in both modes)
* in mode ObjFPC inheritance (and also "inherited") is enabled for "record helpers" while it's forbidden for them in mode Delphi (note: "inherited" is also needed inside a helper to call a method of the extended type when a method with the same name (and maybe parameters) exists in the helper as well)
* Delphi does not respect the visibility of nested helpers, FPC does (this was reported at Embarcadero's code central)
* the biggest difference between Delphi and FPC is in the RTTI: while in Delphi helpers are "magically enhanced" descendants of a "TClassHelperBase" class (which in turn inherits from "TInterfacedObject"), helpers are a type of their own in FPC (are such types called "first class types"?). Thus they have their own RTTI type (tkHelper) and their own type data which contains the parent helper (like Delphi) and the extended type (Delphi does not provide this). I have decided to follow this route as I was already too advanced to change my implementation and I also didn't want to carry around a reference to a class that's only needed to satisfy Delphi compatibilty in a corner case.

Some notes regarding the tests:
* two of the general helper tests (thlp*) fail because of missing generic features (generic methods and generic constraints) - to be more precise: one fails because generic methods are missing and should not fail, the other one fails because constraints are missing, butit should fail anyway...
* three record helper tests (trhlp*) fail, because nested types are not supported by (advanced) records (two should fail nevertheless, because they try to access (strict) private helpers, the third should succeed)
* three more record helper tests fail, because the abbreviated syntax to access default properties is not supported

I'll report bugs for the last two points as those work in Delphi.

Regarding performance:
For projects that don't use helper types (like currently all code provided by FPC) there isn't much speed difference, because
1. I check whether a symtable contains a helper at all (using the new symtable options) before searching through it when it's pushed on the symtable stack
2. I check whether the current module contains helped types at all

Thus there isn't that much speed difference between the modified compiler and an unmodified trunk one. It will only become noticeable when a project contains helpers. Maybe then a possible reduction of performance could be achieved by caching the mangled name of a type (which is used as lookup key) instead of generating it each time that type is accessed (I didn't want to do such a change during the implementation of the helper feature).

Regards,
Sven

Reply by email

Paul Ishenin
to Sven Barth
Sven Barth wrote
Both "class helpers" and "record helpers" are implemented and work as Delphi compatible as reasonably possible.

Congratulations.

Some notes regarding the tests: * three record helper tests (trhlp*) fail, because nested types are not supported by (advanced) records (two should fail nevertheless, because they try to access (strict) private helpers, the third should succeed)

Nested types in records are supported actually. Maybe you found a bug?

* three more record helper tests fail, because the abbreviated syntax to access default properties is not supported

Indeed, I forgot about this feature during the implementation.

Show quoted text 7 lines
Regarding performance: For projects that don't use helper types (like currently all code provided by FPC) there isn't much speed difference, because 1. I check whether a symtable contains a helper at all (using the new symtable options) before searching through it when it's pushed on the symtable stack 2. I check whether the current module contains helped types at all

We probably can extend these tricks for other types and may be speedup the compiler.

I think your branch should be reviewed either by Florian or by Jonas before the merge.

Best regards,
Paul Ishenin

Reply by email

Florian Klaempfl
to Paul Ishenin
Paul Ishenin wrote 5 lines
We probably can extend these tricks for other types and may be speedup the compiler. I think your branch should be reviewed either by Florian or by Jonas before the merge.

I can review the coding style etc. but not if the semantics or syntax of the class helpers are correct, complete etc.

Reply by email

Paul Ishenin
to Florian Klaempfl

05.04.2011 14:26, Florian Klaempfl пишет:

Show quoted text 9 lines
Am 05.04.2011 04:27, schrieb Paul Ishenin: > We probably can extend these tricks for other types and may be speedup > the compiler. > > I think your branch should be reviewed either by Florian or by Jonas > before the merge. I can review the coding style etc. but not if the semantics or syntax of the class helpers are correct, complete etc.

Sintax and semantics are covered by those 100 new tests which Sven has invented I believe.

Best regards,
Paul Ishenin

Reply by email

Florian Klaempfl
to Paul Ishenin
Paul Ishenin wrote 13 lines
05.04.2011 14:26, Florian Klaempfl пишет: > Am 05.04.2011 04:27, schrieb Paul Ishenin: >> We probably can extend these tricks for other types and may be speedup >> the compiler. >> >> I think your branch should be reviewed either by Florian or by Jonas >> before the merge. > > I can review the coding style etc. but not if the semantics or syntax of > the class helpers are correct, complete etc. Sintax and semantics are covered by those 100 new tests which Sven has invented I believe.

Yes, but but they need to be reviewed as well, no?

Reply by email

Sven Barth
to Paul Ishenin
Paul Ishenin wrote 5 lines
05.04.2011 16:11, Florian Klaempfl wrote: > Yes, but but they need to be reviewed as well, no? If they all were tested with delphi xe then no.

I developed them in Delphi XE first before I copied them into my branch. (the only problem with my Starter is that it doesn't support command line compilation -.-)

Regards,
Sven

Reply by email

Sven Barth
to Paul Ishenin: Congratulations. Nested types in records are supported actually. Maybe you found a bug?…
Paul Ishenin wrote 7 lines
05.04.2011 3:51, Sven Barth wrote: > Both "class helpers" and "record helpers" are implemented and work as > Delphi compatible as reasonably possible. Congratulations.

Thank you.

Show quoted text 7 lines
> Some notes regarding the tests: > * three record helper tests (trhlp*) fail, because nested types are not > supported by (advanced) records (two should fail nevertheless, because > they try to access (strict) private helpers, the third should succeed) Nested types in records are supported actually. Maybe you found a bug?

It seems so. I'll report them shortly as I've written tests for them.

Show quoted text 5 lines
> * three more record helper tests fail, because the abbreviated syntax to > access default properties is not supported Indeed, I forgot about this feature during the implementation.

Will report a bug as well.

Show quoted text 13 lines
> Regarding performance: > For projects that don't use helper types (like currently all code > provided by FPC) there isn't much speed difference, because > 1. I check whether a symtable contains a helper at all (using the new > symtable options) before searching through it when it's pushed on the > symtable stack > 2. I check whether the current module contains helped types at all We probably can extend these tricks for other types and may be speedup the compiler. I think your branch should be reviewed either by Florian or by Jonas before the merge.

Regards,
Sven

Reply by email

Sven Barth
to Sven Barth
Sven Barth wrote 10 lines
>> Some notes regarding the tests: >> * three record helper tests (trhlp*) fail, because nested types are not >> supported by (advanced) records (two should fail nevertheless, because >> they try to access (strict) private helpers, the third should succeed) > > Nested types in records are supported actually. Maybe you found a bug? > It seems so. I'll report them shortly as I've written tests for them.

Reported here: http://bugs.freepascal.org/view.php?id=19099

Show quoted text 7 lines
>> * three more record helper tests fail, because the abbreviated syntax to >> access default properties is not supported > > Indeed, I forgot about this feature during the implementation. > Will report a bug as well.

Reported here: http://bugs.freepascal.org/view.php?id=19098

Regards,
Sven

Reply by email

Unknown author
to Sven Barth: Thank you. It seems so. I'll report them shortly as I've written tests for them. Will…
Sven Barth wrote 11 lines
Am 05.04.2011 04:27, schrieb Paul Ishenin: > 05.04.2011 3:51, Sven Barth wrote: > >> Both "class helpers" and "record helpers" are implemented and work >> as >> Delphi compatible as reasonably possible. > > Congratulations. > Thank you.

Just from my curiosity. What is the special benefit of a class helper over inheritance?

Regards, Darius

Reply by email

Sven Barth
to Unknown author

Am 05.04.2011 11:42, schrieb

Show quoted text 15 lines
On Tue, 05 Apr 2011 11:17:48 +0200, Sven Barth wrote: > Am 05.04.2011 04:27, schrieb Paul Ishenin: >> 05.04.2011 3:51, Sven Barth wrote: >> >>> Both "class helpers" and "record helpers" are implemented and work as >>> Delphi compatible as reasonably possible. >> >> Congratulations. >> > > Thank you. Just from my curiosity. What is the special benefit of a class helper over inheritance?

You can add methods to a class that you can't inherit from (e.g. you have a 3rd party component that you can't extend, because it's declared as sealed). Or instead of defining (global) utility procedures for e.g. TStringList in some unit you can create a helper and call those methods as if those belong to TStringList.

The question that got me to start this feature was the question whether one could get the count of all checked items in a TCheckListBox.

A (simple) helper implementation for this would be the following:

==== source begin ====

TCheckListBoxHelper = class helper for TCheckListBox
private
   function GetCheckedCount: Integer;
public
   property CheckedCount: Integer read GetCheckedCount;
end;
function TCheckListBoxHelper.GetCheckedCount: Integer;
begin
   Result := 0;
   for i := 0 to Count - 1 do
     if Checked[i] then
       Inc(Result);
end;

==== source end ====

Also using the record helpers you can add methods to records that are not declared with methods (e.g. some Windows structs or something like that...).

Regards,
Sven

Reply by email

Florian Klaempfl
to Paul Ishenin: Congratulations. Nested types in records are supported actually. Maybe you found a bug?…
Paul Ishenin wrote
I think your branch should be reviewed either by Florian

I did a quick review and found nothing important, only a few remarks:
- current_syssym: is it really needed? Can't the type checking be done during the type check pass? If it's needed, it should be reset to 0 somewhere during parser initialization because in case of a fatal error when the compiler is compiled into an ide, at the next start current_syssym would have a wrong value.
- Is ibsymtableoptions needed? Couldn't be the value just be written to the ppu without a new entry?

Reply by email

Sven Barth
to Florian Klaempfl
Florian Klaempfl wrote 10 lines
Am 05.04.2011 04:27, schrieb Paul Ishenin: > > I think your branch should be reviewed either by Florian I did a quick review and found nothing important, only a few remarks: - current_syssym: is it really needed? Can't the type checking be done during the type check pass? If it's needed, it should be reset to 0 somewhere during parser initialization because in case of a fatal error when the compiler is compiled into an ide, at the next start current_syssym would have a wrong value.

The problem is that basically all references to class helpers are forbidden except inside of SizeOf and TypeInfo (and BitSizeOf). Thus when one of those symbols is encountered the checks against the use of a class helper type reference are already "active". So the only way out I have found was the introduction of that current_syssym variable to check whether I'm currently inside one of those three functions. If you have an idea how to solve this with by using the type check pass I'll be glad to do so.

Regarding the initialization: Will do that.

- Is ibsymtableoptions needed? Couldn't be the value just be written to the ppu without a new entry?

It didn't work the first time I added that, but it might be because of other errors I had at that time. I'll recheck that to be sure.

Regards,
Sven

Reply by email

Sven Barth
to Sven Barth
Sven Barth wrote 5 lines
> - Is ibsymtableoptions needed? Couldn't be the value just be written to > the ppu without a new entry? It didn't work the first time I added that, but it might be because of other errors I had at that time. I'll recheck that to be sure.

I now remember why I did it...

PPUs are entry based and symtables (tstoreddef) don't have a PPU entry for themselves. They "only" write two entries: one for the defs and one for the symbols. So if I wouldn't have introduced a new entry for the options I would have broken all read operations when they'd read that new PPU or I would have needed to add the value to either the symbol entry or the def entry (both solutions are rather unclean).

So yes, the entry is needed.

Regards,
Sven

Reply by email

Paul Ishenin
to Sven Barth

06.04.2011 2:20, Sven Barth пишет:

Show quoted text 15 lines
On 05.04.2011 17:34, Sven Barth wrote: >> - Is ibsymtableoptions needed? Couldn't be the value just be written to >> the ppu without a new entry? > > It didn't work the first time I added that, but it might be because of > other errors I had at that time. I'll recheck that to be sure. I now remember why I did it... PPUs are entry based and symtables (tstoreddef) don't have a PPU entry for themselves. They "only" write two entries: one for the defs and one for the symbols. So if I wouldn't have introduced a new entry for the options I would have broken all read operations when they'd read that new PPU or I would have needed to add the value to either the symbol entry or the def entry (both solutions are rather unclean).

And what will happen if you write options before defs and symbols?

Best regards,
Paul Ishenin.

Reply by email

Florian Klaempfl
to Sven Barth: I now remember why I did it... PPUs are entry based and symtables (tstoreddef) don't have…
Sven Barth wrote 17 lines
On 05.04.2011 17:34, Sven Barth wrote: >> - Is ibsymtableoptions needed? Couldn't be the value just be written to >> the ppu without a new entry? > > It didn't work the first time I added that, but it might be because of > other errors I had at that time. I'll recheck that to be sure. I now remember why I did it... PPUs are entry based and symtables (tstoreddef) don't have a PPU entry for themselves. They "only" write two entries: one for the defs and one for the symbols. So if I wouldn't have introduced a new entry for the options I would have broken all read operations when they'd read that new PPU or I would have needed to add the value to either the symbol entry or the def entry (both solutions are rather unclean). So yes, the entry is needed.

Ok, I think we should leave this as it is. Maybe it can be fixed later on.

Reply by email

Florian Klaempfl
to Sven Barth: The problem is that basically all references to class helpers are forbidden except inside…
Sven Barth wrote 20 lines
Am 05.04.2011 17:06, schrieb Florian Klaempfl: > Am 05.04.2011 04:27, schrieb Paul Ishenin: >> >> I think your branch should be reviewed either by Florian > > I did a quick review and found nothing important, only a few remarks: > - current_syssym: is it really needed? Can't the type checking be done > during the type check pass? If it's needed, it should be reset to 0 > somewhere during parser initialization because in case of a fatal error > when the compiler is compiled into an ide, at the next start > current_syssym would have a wrong value. The problem is that basically all references to class helpers are forbidden except inside of SizeOf and TypeInfo (and BitSizeOf). Thus when one of those symbols is encountered the checks against the use of a class helper type reference are already "active". So the only way out I have found was the introduction of that current_syssym variable to check whether I'm currently inside one of those three functions. If you have an idea how to solve this with by using the type check pass I'll be glad to do so.

Just let me ask different: what code compiles, if the check is not here? The expressions accepting a type node but not a class helper should be easily fixable.

Reply by email

Sven Barth
to Florian Klaempfl
Florian Klaempfl wrote 26 lines
Am 05.04.2011 17:34, schrieb Sven Barth: > Am 05.04.2011 17:06, schrieb Florian Klaempfl: >> Am 05.04.2011 04:27, schrieb Paul Ishenin: >>> >>> I think your branch should be reviewed either by Florian >> >> I did a quick review and found nothing important, only a few remarks: >> - current_syssym: is it really needed? Can't the type checking be done >> during the type check pass? If it's needed, it should be reset to 0 >> somewhere during parser initialization because in case of a fatal error >> when the compiler is compiled into an ide, at the next start >> current_syssym would have a wrong value. > > The problem is that basically all references to class helpers are > forbidden except inside of SizeOf and TypeInfo (and BitSizeOf). Thus > when one of those symbols is encountered the checks against the use of a > class helper type reference are already "active". So the only way out I > have found was the introduction of that current_syssym variable to check > whether I'm currently inside one of those three functions. If you have > an idea how to solve this with by using the type check pass I'll be glad > to do so. Just let me ask different: what code compiles, if the check is not here? The expressions accepting a type node but not a class helper should be easily fixable.

If I remember correctly (and my comment at the location is correct which I hope it is ^^) the case should be the following:

TMyHelperType.SomeClassMethod;

But I'll recheck that later to be sure.

Regards,
Sven

Reply by email

Sven Barth
to Sven Barth
Sven Barth wrote 34 lines
Am 06.04.2011 13:35, schrieb Florian Klaempfl: > Am 05.04.2011 17:34, schrieb Sven Barth: >> Am 05.04.2011 17:06, schrieb Florian Klaempfl: >>> Am 05.04.2011 04:27, schrieb Paul Ishenin: >>>> >>>> I think your branch should be reviewed either by Florian >>> >>> I did a quick review and found nothing important, only a few remarks: >>> - current_syssym: is it really needed? Can't the type checking be done >>> during the type check pass? If it's needed, it should be reset to 0 >>> somewhere during parser initialization because in case of a fatal error >>> when the compiler is compiled into an ide, at the next start >>> current_syssym would have a wrong value. >> >> The problem is that basically all references to class helpers are >> forbidden except inside of SizeOf and TypeInfo (and BitSizeOf). Thus >> when one of those symbols is encountered the checks against the use of a >> class helper type reference are already "active". So the only way out I >> have found was the introduction of that current_syssym variable to check >> whether I'm currently inside one of those three functions. If you have >> an idea how to solve this with by using the type check pass I'll be glad >> to do so. > > > Just let me ask different: what code compiles, if the check is not here? > The expressions accepting a type node but not a class helper should be > easily fixable. If I remember correctly (and my comment at the location is correct which I hope it is ^^) the case should be the following: TMyHelperType.SomeClassMethod; But I'll recheck that later to be sure.

Yes, I was right.

When I disable the check that uses current_syssym the only test that fails is that for the case mentioned in the above mail.

Regards,
Sven

Reply by email

Sven Barth
to Florian Klaempfl: Just let me ask different: what code compiles, if the check is not here? The expressions…
Florian Klaempfl wrote 26 lines
Am 05.04.2011 17:34, schrieb Sven Barth: > Am 05.04.2011 17:06, schrieb Florian Klaempfl: >> Am 05.04.2011 04:27, schrieb Paul Ishenin: >>> >>> I think your branch should be reviewed either by Florian >> >> I did a quick review and found nothing important, only a few remarks: >> - current_syssym: is it really needed? Can't the type checking be done >> during the type check pass? If it's needed, it should be reset to 0 >> somewhere during parser initialization because in case of a fatal error >> when the compiler is compiled into an ide, at the next start >> current_syssym would have a wrong value. > > The problem is that basically all references to class helpers are > forbidden except inside of SizeOf and TypeInfo (and BitSizeOf). Thus > when one of those symbols is encountered the checks against the use of a > class helper type reference are already "active". So the only way out I > have found was the introduction of that current_syssym variable to check > whether I'm currently inside one of those three functions. If you have > an idea how to solve this with by using the type check pass I'll be glad > to do so. Just let me ask different: what code compiles, if the check is not here? The expressions accepting a type node but not a class helper should be easily fixable.

I've now looked at that again and I still don't see a possibility to "drop" current_syssym again (of course I don't know whether I've looked at the correct locations and understood everything correctly...).

You basically suggest to extend ttypenode.typecheck_pass to check for a class helper, correct? If so then the problem is that I can't check whether I'm inside one of the three allowed syssyms as no node is generated for them (yet). Also typecheck_pass is already called inside comp_expr (by postfixoperators) so I can't even say to simply not do do_typecheckpass_changed.

So if I haven't misunderstood the concept somewhere (point 1) or you haven't got a better/correct solution (point 2) then I'm afraid that current_syssym needs to stay (of course with a proper initialization ^^).

Regards,
Sven

Reply by email

Jonas Maebe
to Sven Barth
Sven Barth wrote
You basically suggest to extend ttypenode.typecheck_pass to check for a class helper, correct? If so then the problem is that I can't check whether I'm inside one of the three allowed syssyms as no node is generated for them (yet). Also typecheck_pass is already called inside comp_expr (by postfixoperators) so I can't even say to simply not do do_typecheckpass_changed.

Maybe you can do it in pass_1 instead, and add another boolean field to ttypenode similar to allowed (such as classhelper_allowed). Then you can set this "allowed" to true from the typecheck pass of sizeof/bitsizeof/typeinfo.

Jonas

Reply by email

Florian Klämpfl
to Jonas Maebe
Jonas Maebe wrote 14 lines
On 08 Apr 2011, at 08:58, Sven Barth wrote: > You basically suggest to extend ttypenode.typecheck_pass to check > for a class helper, correct? If so then the problem is that I can't > check whether I'm inside one of the three allowed syssyms as no > node is generated for them (yet). Also typecheck_pass is already > called inside comp_expr (by postfixoperators) so I can't even say > to simply not do do_typecheckpass_changed. Maybe you can do it in pass_1 instead, and add another boolean field to ttypenode similar to allowed (such as classhelper_allowed). Then you can set this "allowed" to true from the typecheck pass of sizeof/bitsizeof/typeinfo.

Well, this is a hack as well, no?

Reply by email

Sven Barth
to Florian Klämpfl
Florian Klämpfl wrote 17 lines
Am 08.04.2011 09:07, schrieb Jonas Maebe: > > On 08 Apr 2011, at 08:58, Sven Barth wrote: > >> You basically suggest to extend ttypenode.typecheck_pass to check >> for a class helper, correct? If so then the problem is that I can't >> check whether I'm inside one of the three allowed syssyms as no >> node is generated for them (yet). Also typecheck_pass is already >> called inside comp_expr (by postfixoperators) so I can't even say >> to simply not do do_typecheckpass_changed. > > Maybe you can do it in pass_1 instead, and add another boolean field > to ttypenode similar to allowed (such as classhelper_allowed). Then > you can set this "allowed" to true from the typecheck pass of > sizeof/bitsizeof/typeinfo. Well, this is a hack as well, no?

At least I can't comment on this yet, as I yet have to try that (I'll do that tomorrow morning on my ride to Munich ^^).

Regards,
Sven

Reply by email

Jonas Maebe
to Florian Klämpfl: Well, this is a hack as well, no?
Florian Klämpfl wrote 10 lines
Am 08.04.2011 09:07, schrieb Jonas Maebe: > > On 08 Apr 2011, at 08:58, Sven Barth wrote: > > Maybe you can do it in pass_1 instead, and add another boolean field > to ttypenode similar to allowed (such as classhelper_allowed). Then > you can set this "allowed" to true from the typecheck pass of > sizeof/bitsizeof/typeinfo. Well, this is a hack as well, no?

At least it doesn't require a global variable, and it's a hack that already exists (in the sense that it won't introduce a new hack nor the same hack in an additional place, but reuse the same hack for the new functionality). So if the current "allowed"-field hack for the ttypenodes is fixed, this one should be fixable at the same time in the same way.

Jonas

Reply by email

Sven Barth
to Jonas Maebe
Jonas Maebe wrote 15 lines
On 10 Apr 2011, at 21:49, Florian Klämpfl wrote: > Am 08.04.2011 09:07, schrieb Jonas Maebe: >> >> On 08 Apr 2011, at 08:58, Sven Barth wrote: >> >> Maybe you can do it in pass_1 instead, and add another boolean field >> to ttypenode similar to allowed (such as classhelper_allowed). Then >> you can set this "allowed" to true from the typecheck pass of >> sizeof/bitsizeof/typeinfo. > > Well, this is a hack as well, no? At least it doesn't require a global variable, and it's a hack that already exists (in the sense that it won't introduce a new hack nor the same hack in an additional place, but reuse the same hack for the new functionality). So if the current "allowed"-field hack for the ttypenodes is fixed, this one should be fixable at the same time in the same way.

Implementing the hack wasn't as "straightforward" then the "allowed" hack though...

The problem is, that ttypenode.pass_1 is never called in a situation like "THelperType.SomeMethod", because the node of "THelperType" is just passed to tcallnode as method pointer. Thus I needed to implement the check in tcallnode.pass_1 while the flag is defined in ttypenode (the check is in place in ttypenode.pass_1 as well though). As a side effect I also needed to activate the flag "helperallowed:=true" for "inherited" as there the situation "tcallnode with a ttypenode" (which triggers the check at the end) is encountered as well.

The latter change is not yet commited (I will do that tomorrow), but the implementation of the flag and the removing of "current_syssym" are already commited.

Regards,
Sven

Reply by email

Sven Barth
to Sven Barth
Sven Barth wrote
The latter change is not yet commited (I will do that tomorrow), but the implementation of the flag and the removing of "current_syssym" are already commited.

Done.

Regards,
Sven

Reply by email

Florian Klämpfl
to Sven Barth: Done. Sven
Sven Barth wrote 6 lines
Am 12.04.2011 21:41, schrieb Sven Barth: > The latter change is not yet commited (I will do that tomorrow), but the > implementation of the flag and the removing of "current_syssym" are > already commited. Done.

Looks good to me now. So imo it can be merged.

Reply by email

Sven Barth
to Florian Klämpfl
Florian Klämpfl wrote 9 lines
Am 13.04.2011 12:11, schrieb Sven Barth: > Am 12.04.2011 21:41, schrieb Sven Barth: >> The latter change is not yet commited (I will do that tomorrow), but the >> implementation of the flag and the removing of "current_syssym" are >> already commited. > > Done. Looks good to me now. So imo it can be merged.

Jippieh :D

Regards,
Sven

Reply by email

Florian Klämpfl
to Sven Barth
Sven Barth wrote 13 lines
Am 14.04.2011 22:29, schrieb Florian Klämpfl: > Am 13.04.2011 12:11, schrieb Sven Barth: >> Am 12.04.2011 21:41, schrieb Sven Barth: >>> The latter change is not yet commited (I will do that tomorrow), but >>> the >>> implementation of the flag and the removing of "current_syssym" are >>> already commited. >> >> Done. > > Looks good to me now. So imo it can be merged. Jippieh :D

Just tried the merge. Is it on purpose that
thlp[8,9,10,19,29]
cause test suite failures?

Reply by email

Florian Klämpfl
to Florian Klämpfl
Florian Klämpfl wrote 18 lines
Am 15.04.2011 11:39, schrieb Sven Barth: > Am 14.04.2011 22:29, schrieb Florian Klämpfl: >> Am 13.04.2011 12:11, schrieb Sven Barth: >>> Am 12.04.2011 21:41, schrieb Sven Barth: >>>> The latter change is not yet commited (I will do that tomorrow), but >>>> the >>>> implementation of the flag and the removing of "current_syssym" are >>>> already commited. >>> >>> Done. >> >> Looks good to me now. So imo it can be merged. > > Jippieh :D Just tried the merge. Is it on purpose that thlp[8,9,10,19,29] cause test suite failures?

Sorry, they are
trhlp[8,9,10,19]
and
thlp29

Reply by email

Sven Barth
to Florian Klämpfl
Florian Klämpfl wrote 24 lines
Am 16.04.2011 15:27, schrieb Florian Klämpfl: > Am 15.04.2011 11:39, schrieb Sven Barth: >> Am 14.04.2011 22:29, schrieb Florian Klämpfl: >>> Am 13.04.2011 12:11, schrieb Sven Barth: >>>> Am 12.04.2011 21:41, schrieb Sven Barth: >>>>> The latter change is not yet commited (I will do that tomorrow), but >>>>> the >>>>> implementation of the flag and the removing of "current_syssym" are >>>>> already commited. >>>> >>>> Done. >>> >>> Looks good to me now. So imo it can be merged. >> >> Jippieh :D > > Just tried the merge. Is it on purpose that > thlp[8,9,10,19,29] > cause test suite failures? Sorry, they are trhlp[8,9,10,19] and thlp29

The tr* ones are failing because of
http://bugs.freepascal.org/view.php?id=19098 (trhlp[8,9,10) and
http://bugs.freepascal.org/view.php?id=19099 (trhlp19) Please note that trhlp17 and trhlp18 are failing, because of the same reason as trhlp19 is (missing nested type support for records), and not because of the correct reason (visibility).

thlp29 fails, because generic methods are not yet supported. (thlp30 fails out of the wrong reason as well)

You can also take a look at the log entry of revision 17237 where I've explained all this as well (
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=17237 )

Regards,
Sven

Reply by email