Re: [fpc-devel] "helper" feature finished
On 16.04.2011 15:55, Florian Klämpfl wrote: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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 Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
On 11.04.2011 01:33, Jonas Maebe wrote: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
On 10.04.2011 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: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
On 06.04.2011 14:24, Sven Barth wrote: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
Am 05.04.2011 20:20, schrieb Sven Barth: > 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
06.04.2011 2:20, Sven Barth пишет: 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. - Is ibsymtableoptions needed? Couldn't be the value just be written to the ppu without a new entry? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
Am 05.04.2011 11:42, schrieb dhkblas...@zeelandnet.nl: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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? Regards, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
Am 05.04.2011 11:17, schrieb Sven Barth: 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 * 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. 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. * 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
Am 05.04.2011 10:19, schrieb Paul Ishenin: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
Am 05.04.2011 10:09, schrieb Paul Ishenin: > 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? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
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. 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
