On Tue, 2006-05-23 at 16:54 +0200, Graeme Geldenhuys wrote:
> On 5/23/06, Joost van der Sluis <[EMAIL PROTECTED]> wrote:
> > > With some more makefile magic testing can be limited either to
> > > rtl/compiler or
> > > extended to everything.
> >
> > I should use option 2 - add a directory to tests
On 5/23/06, Joost van der Sluis <[EMAIL PROTECTED]> wrote:
> With some more makefile magic testing can be limited either to rtl/compiler or
> extended to everything.
I should use option 2 - add a directory to tests for the fpcunit-tests.
Then, depending on some switch you can turn of the compila
On Tue, 2006-05-23 at 14:41 +0200, Florian Klaempfl wrote:
> Michael Van Canneyt wrote:
> > On Tue, 23 May 2006, Florian Klaempfl wrote:
> >> Peter Vreman wrote:
> Michael Van Canneyt wrote:
> > 1. fpcunit didn't exist at the time the FPC tests were
> > implemented.
> >
Michael Van Canneyt wrote:
>
>
> On Tue, 23 May 2006, Florian Klaempfl wrote:
>
>> Peter Vreman wrote:
Michael Van Canneyt wrote:
> 1. fpcunit didn't exist at the time the FPC tests were
> implemented.
> 2. Using FPCunit creates a dependency on it. The tests can run
On Tue, 23 May 2006, Florian Klaempfl wrote:
Peter Vreman wrote:
Michael Van Canneyt wrote:
1. fpcunit didn't exist at the time the FPC tests were implemented.
2. Using FPCunit creates a dependency on it. The tests can run
mostly
with only the system unit...
Which dependencies? Maybe the
Peter Vreman wrote:
>> Michael Van Canneyt wrote:
>>> 1. fpcunit didn't exist at the time the FPC tests were implemented.
>>> 2. Using FPCunit creates a dependency on it. The tests can run
>>> mostly
>>>with only the system unit...
>> Which dependencies? Maybe they can be re
> I relocated the db connection code to a test decorator (part of
> fpcUnit and took 15 lines of code to implement) and now it creates a
> single connection for the lifetime of all tests in that TestSuite.
> Time to run those 27 test are now 1.9 seconds!
>
> I can't see how something like this is
On 23 mei 2006, at 12:27, Graeme Geldenhuys wrote:
Yes much faster! I just finished a case in point on our code. One of
our developers (new to unit testing) used the Setup and TearDown
methods in a TestSuite to setup a db connection, do a test and close
the connection. Over and over and over.
On Tue, 2006-05-23 at 12:27 +0200, Graeme Geldenhuys wrote:
> On 5/23/06, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> > > On the other hand, it would speed up things quite a bit.
> >
> > Correct.
> > I'm not against changing to fpcunit, but it will require again a lot of
> > work...
>
> Yes m
Graeme Geldenhuys schreef:
On 5/23/06, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> On the other hand, it would speed up things quite a bit.
Correct.
I'm not against changing to fpcunit, but it will require again a lot of
work...
Yes much faster! I just finished a case in point on our co
On 5/23/06, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> On the other hand, it would speed up things quite a bit.
Correct.
I'm not against changing to fpcunit, but it will require again a lot of
work...
Yes much faster! I just finished a case in point on our code. One of
our developers (
On Tue, 23 May 2006, Jonas Maebe wrote:
On 23 mei 2006, at 09:41, Michael Van Canneyt wrote:
I agree here. New tests can be added with fpcunit. But the basic principe
of using the halt and the dotest program needs to stay in place.
That is one of the "problems" of fpcunit: it runs a lot o
Joost van der Sluis schreef:
On Mon, 2006-05-22 at 23:06 +0200, Graeme Geldenhuys wrote:
On 5/22/06, Vincent Snijders <[EMAIL PROTECTED]> wrote:
From Greame I would like to know how he proposes to update the
TestSuite, if a new tests it added.
I am busy looking at the /tests directory now, to
On 5/23/06, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> I agree here. New tests can be added with fpcunit. But the basic principe
> of using the halt and the dotest program needs to stay in place.
That is one of the "problems" of fpcunit: it runs a lot of tests in 1
program. The test suite
Graeme Geldenhuys wrote:
On 5/22/06, Vincent Snijders <[EMAIL PROTECTED]> wrote:
> Can you introduce constants instead of all these hardcoded numbers
so the
> code is more readable ?
>
Maybe Brams mail should be incorporated, given the fact that the
constants don't have a clear meaning.
Vince
On 23 mei 2006, at 09:41, Michael Van Canneyt wrote:
I agree here. New tests can be added with fpcunit. But the basic
principe
of using the halt and the dotest program needs to stay in place.
That is one of the "problems" of fpcunit: it runs a lot of tests in 1
program. The test suite store
On Tue, 23 May 2006, Peter Vreman wrote:
Michael Van Canneyt wrote:
1. fpcunit didn't exist at the time the FPC tests were implemented.
2. Using FPCunit creates a dependency on it. The tests can run
mostly
with only the system unit...
Which dependencies? Maybe they can be reduced and a f
On Mon, 22 May 2006, Joost van der Sluis wrote:
The attached patch fixs some problems with negative TDateTimes.
It could be that the changes in DecodeDate are for the same problem as
Bram already send a patch for:
+ removed obsolete DayTable
+ fixed DateTimeToTimestamp, EncodeDate, DecodeDat
I do not know how relevant this site is but it maybe worthwhile to browse
http://www.chronos-st.org
You maybe able to develope a few libraries/units for date/timekeeping purposes
from the ideas presented on this site.
John
On Mon, May 22, 2006 at 12:04:11PM +0200, Graeme Geldenhuys wrote:
> Michael Van Canneyt wrote:
>> 1. fpcunit didn't exist at the time the FPC tests were implemented.
>> 2. Using FPCunit creates a dependency on it. The tests can run
>> mostly
>>with only the system unit...
>
> Which dependencies? Maybe they can be reduced and a fpcunit
On Mon, 2006-05-22 at 23:06 +0200, Graeme Geldenhuys wrote:
> On 5/22/06, Vincent Snijders <[EMAIL PROTECTED]> wrote:
> > From Greame I would like to know how he proposes to update the
> > TestSuite, if a new tests it added.
>
> I am busy looking at the /tests directory now, to understand how tes
On 5/22/06, Vincent Snijders <[EMAIL PROTECTED]> wrote:
From Greame I would like to know how he proposes to update the
TestSuite, if a new tests it added.
I am busy looking at the /tests directory now, to understand how tests
get grouped. This should give me a clearer idea of what is possible.
On 5/22/06, Vincent Snijders <[EMAIL PROTECTED]> wrote:
> Can you introduce constants instead of all these hardcoded numbers so the
> code is more readable ?
>
Maybe Brams mail should be incorporated, given the fact that the
constants don't have a clear meaning.
Vincent.
This is exactly why
Micha Nelissen wrote:
On Mon, 22 May 2006 18:07:52 +0200
Joost van der Sluis <[EMAIL PROTECTED]> wrote:
The attached patch fixs some problems with negative TDateTimes.
Can you introduce constants instead of all these hardcoded numbers so the
code is more readable ?
Maybe Brams mail shoul
On Mon, 22 May 2006 18:07:52 +0200
Joost van der Sluis <[EMAIL PROTECTED]> wrote:
> The attached patch fixs some problems with negative TDateTimes.
Can you introduce constants instead of all these hardcoded numbers so the
code is more readable ?
Micha
The makefile of the testsuite now simply gets the fpcunit from the fcl
dir and compiles it if necessary. Since the fpcunit depends only on rtl
units, I see no problem with this.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepa
Michael Van Canneyt wrote:
On Mon, 22 May 2006, Graeme Geldenhuys wrote:
Ok, so every set of tests is a actual program.
[I am not forcing fpcUnit, just curious as what FPC's tests can do.
Also not sure what your knowlegde is on the workings of a xUnit
testing framework. ]
So if you have to
The attached patch fixs some problems with negative TDateTimes.
It could be that the changes in DecodeDate are for the same problem as
Bram already send a patch for:
+ removed obsolete DayTable
+ fixed DateTimeToTimestamp, EncodeDate, DecodeDate, DecodeTime for
TDatetimes < 0
+ MSecsToTimeSt
Jonas Maebe wrote:
>
> On 22 mei 2006, at 16:38, Florian Klaempfl wrote:
>
>> We use the simple approach with halt because using the fpcunit for
>> basic tests
>> would require that OOP works always but it could be easily broken and
>> thus all
>> tests would fail. So we designed the test suite i
On 5/22/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
We use the simple approach with halt because using the fpcunit for basic tests
would require that OOP works always but it could be easily broken and thus all
tests would fail. So we designed the test suite in a way which keeps
prerequisits a
On Mon, 22 May 2006, Graeme Geldenhuys wrote:
Ok, so every set of tests is a actual program.
[I am not forcing fpcUnit, just curious as what FPC's tests can do.
Also not sure what your knowlegde is on the workings of a xUnit
testing framework. ]
So if you have to test something a little mor
On 22 mei 2006, at 17:01, Graeme Geldenhuys wrote:
Where in SubVersion are the fpc tests located?
fpc/tests
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Ok, so every set of tests is a actual program.
[I am not forcing fpcUnit, just curious as what FPC's tests can do.
Also not sure what your knowlegde is on the workings of a xUnit
testing framework. ]
So if you have to test something a little more complex, and every
unittest needs some predefine
On 22 mei 2006, at 16:38, Florian Klaempfl wrote:
We use the simple approach with halt because using the fpcunit for
basic tests
would require that OOP works always but it could be easily broken
and thus all
tests would fail. So we designed the test suite in a way which keeps
prerequisits a
On Mon, 22 May 2006, Florian Klaempfl wrote:
Vincent Snijders wrote:
dt := EncodeDateTime(1652, 6, 15, 12, 34, 56, 12);
if '1652-06-15 12:34:56' <> tiUtils.tiDateTimeAsIntlDateDisp(dt)
then halt(5);
[]
end.
We use the simple approach with halt because using the fpcunit for basic t
Vincent Snijders wrote:
> dt := EncodeDateTime(1652, 6, 15, 12, 34, 56, 12);
> if '1652-06-15 12:34:56' <> tiUtils.tiDateTimeAsIntlDateDisp(dt)
>then halt(5);
>
> []
> end.
We use the simple approach with halt because using the fpcunit for basic tests
would require that OOP works always
Graeme Geldenhuys schreef:
On 5/22/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> Should we convert existing tests to fpcunit ?
No, too much work, no real gain :)
Just curious...
I have never looked at the tests created in FPC, but how much work
(lines of code) would it take to test some
On 5/22/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> Should we convert existing tests to fpcunit ?
No, too much work, no real gain :)
Just curious...
I have never looked at the tests created in FPC, but how much work
(lines of code) would it take to test something like the following
sni
Michael Van Canneyt wrote:
> 1. fpcunit didn't exist at the time the FPC tests were implemented.
> 2. Using FPCunit creates a dependency on it. The tests can run mostly
>with only the system unit...
Which dependencies? Maybe they can be reduced and a fpcunit can be
ad
On Mon, 22 May 2006, Florian Klaempfl wrote:
Michael Van Canneyt wrote:
On Mon, 22 May 2006, Florian Klaempfl wrote:
Michael Van Canneyt wrote:
On Mon, 22 May 2006, Graeme Geldenhuys wrote:
On 5/22/06, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
I guess we will need plenty of unit
Michael Van Canneyt wrote:
>
>
> On Mon, 22 May 2006, Florian Klaempfl wrote:
>
>> Michael Van Canneyt wrote:
>>>
>>>
>>> On Mon, 22 May 2006, Graeme Geldenhuys wrote:
>>>
On 5/22/06, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
> I guess we will need plenty of unit tests to make sure a
On Mon, 22 May 2006, Florian Klaempfl wrote:
Michael Van Canneyt wrote:
On Mon, 22 May 2006, Graeme Geldenhuys wrote:
On 5/22/06, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
I guess we will need plenty of unit tests to make sure all the functions
work consistent, in particular also for
Michael Van Canneyt wrote:
>
>
> On Mon, 22 May 2006, Graeme Geldenhuys wrote:
>
>> On 5/22/06, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
>>> I guess we will need plenty of unit tests to make sure all the functions
>> work consistent, in particular also for dates close to and before
>> 29-12
On Mon, 22 May 2006, Graeme Geldenhuys wrote:
On 5/22/06, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
I guess we will need plenty of unit tests to make sure all the functions
work consistent, in particular also for dates close to and before 29-12-1899
:)
(Note: I sent some mail explaining
On 5/22/06, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
I guess we will need plenty of unit tests to make sure all the functions work
consistent, in particular also for dates close to and before 29-12-1899 :)
(Note: I sent some mail explaining the TryEncodeDateTime function some time ago
(21-
> On Mon, 22 May 2006, Bram Kuijvenhoven wrote:
> > This is really bad -- I supposed the TDateTime was a nice 'linear' mapping
> > of
> > time (which is much nicer for all kinds of calculations).
>
> It is, but only for dates after 1899-12-30. God only knows why Microsoft
> picked this date.
Ju
On Mon, 22 May 2006, Bram Kuijvenhoven wrote:
Michael Van Canneyt wrote:
The following remark in the Delphi help sheds more light on the issue:
"When working with negative TDateTime values, computations must handle
time portion separately. The fractional part reflects the fraction of
a 24-ho
Michael Van Canneyt wrote:
The following remark in the Delphi help sheds more light on the issue:
"When working with negative TDateTime values, computations must handle
time portion separately. The fractional part reflects the fraction of
a 24-hour day without regard to the sign of the TDateTime
On Sun, 21 May 2006 16:40:44 +0200 (Romance Daylight Time)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> They obviously judged that the idea of
> TD := EncodeDate()+encodeTime();
> was more important than strict ordering.
If they *did* use this, it *would* all work like you expect! But with
n
On Sun, 2006-05-21 at 18:09 +0200, Michael Van Canneyt wrote:
>
> On Sun, 21 May 2006, Joost van der Sluis wrote:
>
> > On Sun, 2006-05-21 at 16:40 +0200, Michael Van Canneyt wrote:
> > > On Sun, 21 May 2006, Joost van der Sluis wrote:
> > > > I have some questions about the TDateTime format.
> >
On Sun, 21 May 2006, Joost van der Sluis wrote:
> On Sun, 2006-05-21 at 16:40 +0200, Michael Van Canneyt wrote:
> > On Sun, 21 May 2006, Joost van der Sluis wrote:
> > > I have some questions about the TDateTime format.
> > >
> > > I always thought that you could do this:
> > > TD : TDateTime
On Sun, 2006-05-21 at 16:40 +0200, Michael Van Canneyt wrote:
> On Sun, 21 May 2006, Joost van der Sluis wrote:
> > I have some questions about the TDateTime format.
> >
> > I always thought that you could do this:
> > TD : TDateTime
> >
> > TD := EncodeDate()+encodeTime();
> >
> > This would mea
On Sun, 21 May 2006, Joost van der Sluis wrote:
> Hi all,
>
> I have some questions about the TDateTime format.
>
> I always thought that you could do this:
> TD : TDateTime
>
> TD := EncodeDate()+encodeTime();
>
> This would mean that you have the following: (24-hours notation)
>
> 0 = 1
Hi all,
I have some questions about the TDateTime format.
I always thought that you could do this:
TD : TDateTime
TD := EncodeDate()+encodeTime();
This would mean that you have the following: (24-hours notation)
0 = 12/30/1899 00:00(as defined)
1 = 12/31/1899 00:00
1.25
54 matches
Mail list logo
