On 2019-11-08 22:33, Bart via fpc-devel wrote:
Hi,
> 2.
A rather more serious issue.
Compile time errors occur with e.g.
ANativeInt.SetBit(High(TNativeIntBitIndex)) in modes tp (32-bit), fpc
(32-bit), objfpc (32+64-bit) and delphi (32+64-bit)
Range check error while evaluating constants (21474
Am 10.11.19 um 11:45 schrieb Jonas Maebe:
On 2019-11-10 10:54, Michael Van Canneyt wrote:
It's not just the waste of time, it's also the origanization of the
sources.
See my mail to Florian. I have 1 application that has all the tests. It's
easy to navigate & whatnot.
The nice thing about you
Am 10.11.19 um 10:54 schrieb Michael Van Canneyt:
On Sat, 9 Nov 2019, Jonas Maebe wrote:
On 09/11/2019 20:17, Michael Van Canneyt wrote:
On Sat, 9 Nov 2019, Jonas Maebe wrote:
I definitely want to help to integrate the tests somehow in the daily
testrun, but I will not use the slow tests
On 2019-11-10 10:54, Michael Van Canneyt wrote:
It's not just the waste of time, it's also the origanization of the
sources.
See my mail to Florian. I have 1 application that has all the tests.
It's
easy to navigate & whatnot.
The nice thing about your punit-based tests is that they can just
On Sat, 9 Nov 2019, Jonas Maebe wrote:
On 09/11/2019 20:17, Michael Van Canneyt wrote:
On Sat, 9 Nov 2019, Jonas Maebe wrote:
I definitely want to help to integrate the tests somehow in the daily
testrun, but I will not use the slow testsuite.
With parallel compilation, it will be barel
On Sat, 9 Nov 2019, Jonas Maebe wrote:
On 09/11/2019 20:17, Michael Van Canneyt wrote:
home:~/fpc> time make clean all PP=ppcx64-3.0.4 > out
/usr/bin/ld: warning: x86_64/bin/x86_64-linux/link.res contains output
sections; did you forget -T?
119.139u 11.763s 1:47.32 121.9% 0+0k 179800+1292024i
On 09/11/2019 20:17, Michael Van Canneyt wrote:
> home:~/fpc> time make clean all PP=ppcx64-3.0.4 > out
> /usr/bin/ld: warning: x86_64/bin/x86_64-linux/link.res contains output
> sections; did you forget -T?
> 119.139u 11.763s 1:47.32 121.9% 0+0k 179800+1292024io 2pf+0w
>
> home:~/fpc> time make c
On 09/11/2019 20:17, Michael Van Canneyt wrote:
>
>
> On Sat, 9 Nov 2019, Jonas Maebe wrote:
>
>>> I definitely want to help to integrate the tests somehow in the daily
>>> testrun, but I will not use the slow testsuite.
>>
>> With parallel compilation, it will be barely slower.
>
> home:~/rtl>
Florian Klämpfl schrieb am Sa., 9. Nov. 2019,
20:45:
> Am 09.11.19 um 20:26 schrieb Michael Van Canneyt:
> >
> >
> > On Sat, 9 Nov 2019, Florian Klämpfl wrote:
> >
> >> Am 09.11.19 um 20:02 schrieb Michael Van Canneyt:
> >>>
> >>>
> >>> On Sat, 9 Nov 2019, Florian Klämpfl wrote:
> >>>
> > Wha
Am 09.11.19 um 20:26 schrieb Michael Van Canneyt:
On Sat, 9 Nov 2019, Florian Klämpfl wrote:
Am 09.11.19 um 20:02 schrieb Michael Van Canneyt:
On Sat, 9 Nov 2019, Florian Klämpfl wrote:
What matters is we have the tests.
Yes. But I see no point in having the rtl tests cluttered to
dif
On Sat, 9 Nov 2019, Florian Klämpfl wrote:
Am 09.11.19 um 20:02 schrieb Michael Van Canneyt:
On Sat, 9 Nov 2019, Florian Klämpfl wrote:
What matters is we have the tests.
Yes. But I see no point in having the rtl tests cluttered to different
locations.
Exactly.
My solution is WAY su
On Sat, 9 Nov 2019, Jonas Maebe wrote:
I definitely want to help to integrate the tests somehow in the daily
testrun, but I will not use the slow testsuite.
With parallel compilation, it will be barely slower.
home:~/rtl> time retest Classes > out
3.400u 0.628s 0:04.02 100.0%0+0k 0+33
Am 09.11.19 um 20:02 schrieb Michael Van Canneyt:
On Sat, 9 Nov 2019, Florian Klämpfl wrote:
What matters is we have the tests.
Yes. But I see no point in having the rtl tests cluttered to different
locations.
Exactly.
My solution is WAY superior to yours in this respect.
I have exactl
On Sat, 9 Nov 2019, Florian Klämpfl wrote:
What matters is we have the tests.
Yes. But I see no point in having the rtl tests cluttered to different
locations.
Exactly.
My solution is WAY superior to yours in this respect.
I have exactly 1 application which I open in lazarus.
I can nav
Op 2019-11-09 om 18:29 schreef Florian Klämpfl:
And you don't call this unix only docompile.sh not cumbersome with the
compiler parameters in some configuration file?
I definitely want to help to integrate the tests somehow in the daily
testrun, but I will not use the slow testsuite.
As
Op 2019-11-09 om 18:28 schreef Jonas Maebe:
That's why I proposed to add support for running only the tests specific
to the RTL and/or specific units.
A tagging system for tests in the .pp tests might be the best?
Occasionally some central admin would have to be updated (automatically)
and co
Am 09.11.19 um 18:19 schrieb Michael Van Canneyt:
On Sat, 9 Nov 2019, Jonas Maebe wrote:
On 09/11/2019 17:40, Michael Van Canneyt wrote:
I have extensively argued before why I think the testsuite is completely
unsuitable for testing single unit functionality, I will not repeat my
arguments a
On 09/11/2019 18:19, Michael Van Canneyt wrote:
>
> Running the testsuite (even part of it) requires too much preparation
> and takes too much time.
For testing RTL units, all that would be required is
a) compile the RTL
b) cd tests
c) make TEST_FPC=fpc tests_all -j 4 (or e.g. make TEST_FPC=fpc
t
Am 09.11.19 um 18:08 schrieb Michael Van Canneyt:
On Sat, 9 Nov 2019, Florian Klämpfl wrote:
We don't need custom-formatted reports for the testsuite, just exit
codes from individual test programs. It seems we can easily create
those
by simply creating programs that include individual units
On Sat, 9 Nov 2019, Jonas Maebe wrote:
On 09/11/2019 17:40, Michael Van Canneyt wrote:
I have extensively argued before why I think the testsuite is completely
unsuitable for testing single unit functionality, I will not repeat my
arguments again.
We can add testsuite makefile targets that
On Sat, 9 Nov 2019, Florian Klämpfl wrote:
We don't need custom-formatted reports for the testsuite, just exit
codes from individual test programs. It seems we can easily create those
by simply creating programs that include individual units. The punit
unit can be moved to tests/tstunits when
On 09/11/2019 17:40, Michael Van Canneyt wrote:
> I have extensively argued before why I think the testsuite is completely
> unsuitable for testing single unit functionality, I will not repeat my
> arguments again.
We can add testsuite makefile targets that only run the tests under
units, or even
Am 09.11.19 um 17:40 schrieb Michael Van Canneyt:
On Sat, 9 Nov 2019, Jonas Maebe wrote:
On 09/11/2019 14:43, Michael Van Canneyt wrote:
Let me know what you need extra to be able to run them with the compiler
testsuite.
Do you know which tests were copied from the existing testsuite at s
On Sat, 9 Nov 2019, Jonas Maebe wrote:
On 09/11/2019 14:43, Michael Van Canneyt wrote:
Let me know what you need extra to be able to run them with the compiler
testsuite.
Do you know which tests were copied from the existing testsuite at some
point? E.g. utrwsync.pp is derived from an old
On 09/11/2019 14:43, Michael Van Canneyt wrote:
>
> Let me know what you need extra to be able to run them with the compiler
> testsuite.
Do you know which tests were copied from the existing testsuite at some
point? E.g. utrwsync.pp is derived from an old (buggy) version of
tests/test/sysutils/t
On Sat, 9 Nov 2019, Jonas Maebe wrote:
On 09/11/2019 13:29, Michael Van Canneyt wrote:
When testing I converted the tests to the format suitable for my rtl
testsuite, so they are run whenever I run that testsuite.
They're even more useful if they can be run by anyone, and are
automatically
On 09/11/2019 13:29, Michael Van Canneyt wrote:
> When testing I converted the tests to the format suitable for my rtl
> testsuite, so they are run whenever I run that testsuite.
They're even more useful if they can be run by anyone, and are
automatically used during the nightly testsuite run.
J
On Sat, 9 Nov 2019, Bart via fpc-devel wrote:
On Sat, Nov 9, 2019 at 9:08 AM Michael Van Canneyt
wrote:
That is why I decided to keep it: the mode of sysutils is known and will
never change. A user is supposed to take this into account.
OK.
This error was confirmed as a compiler bug. It
On Sat, Nov 9, 2019 at 9:08 AM Michael Van Canneyt
wrote:
> That is why I decided to keep it: the mode of sysutils is known and will
> never change. A user is supposed to take this into account.
OK.
> This error was confirmed as a compiler bug. It also disappears if you remove
> the inline from
On Fri, 8 Nov 2019, Bart via fpc-devel wrote:
1.
Minor issue.
Defining the ranges TByteBitIndex will confuse users if they define a
constant array with that range and then compile their program in
either mode fpc or mode tp.
I have something like:
const
Expected: array[TIntegerBitIndex] of I
Hi,
I would like to raise some concerns about the current implementation
of ordinal bithelpers in r 43417.
I do not have the rights to re-open that issue, and I did not want to
open a new one for it.
My concerns basically are the same I described in the associated
bugtracker issue (https://bugs.
31 matches
Mail list logo
