-Message d'origine-
De : Florian Klaempfl [mailto:[EMAIL PROTECTED]
Envoyé : lundi 22 mai 2006 19:56
À : [EMAIL PROTECTED]; FPC developers' list
Objet : Re: [fpc-devel] shared libraries on x86_64 Linux ?
Dominique Leducq wrote:
Hello,
I'm new to this list (and to Free
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
added to tests?
fpcunit
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:
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,
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
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 stores
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.
Vincent.
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
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
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 of tests in 1
program.
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 of
On Tue, 23 May 2006 08:29:00 +0200
Dominique Leducq [EMAIL PROTECTED] wrote:
Well, I already tried that with 2.0.2 : make rtl OPT=-Cg (is that right ?),
but it didn't work (yes, I checked that the right system unit was used by the
linker)
I will try again with 2.1.1
So it works with 2.1.1
On 5/23/06, Tomas Hajny [EMAIL PROTECTED] wrote:
Couldn't it happen that one of the tests just crashes the whole program,
so further tests are not run at all then?
Nope. That is the beauty of xUnit testing frameworks. A Failures
(something you are testing for) and Errors (unexpected like
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
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
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 much faster! I
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
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 fpcunit can be
added
Here it is.
SPI* constants are ordered by number and by os version required.
definespatch.diff
Description: Binary data
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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
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
mostly
with only the system
Graeme Geldenhuys wrote:
On 5/23/06, Tomas Hajny [EMAIL PROTECTED] wrote:
Couldn't it happen that one of the tests just crashes the whole program,
so further tests are not run at all then?
Nope. That is the beauty of xUnit testing frameworks. A Failures
(something you are testing for) and
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.
2. Using FPCunit creates a dependency
---
Mime-Version: 1.0
X-Mailer: mPOP Web-Mail 2.19
X-Originating-IP: [194.150.126.26]
Date: Tue, 23 May 2006 18:27:07 +0400
Reply-To: =?koi8-r?Q?=F0=A3=D4=D2=20=EB=CF=D3=C1=D2=C5=D7=D3=CB=C9=CA?= [EMAIL
PROTECTED]
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
On 5/23/06, Tomas Hajny [EMAIL PROTECTED] wrote:
believe this may happen for other targets too - if you have a misbehaving
RTL routine that overwrites half of your heap, you'll probably end up in
the whole program crashing (i.e. if all the tests are run in one process,
some of the tests will
Graeme Geldenhuys wrote:
On 5/23/06, Tomas Hajny [EMAIL PROTECTED] wrote:
believe this may happen for other targets too - if you have a misbehaving
RTL routine that overwrites half of your heap, you'll probably end up in
the whole program crashing (i.e. if all the tests are run in one process,
Graeme Geldenhuys schreef:
On 5/23/06, Tomas Hajny [EMAIL PROTECTED] wrote:
believe this may happen for other targets too - if you have a misbehaving
RTL routine that overwrites half of your heap, you'll probably end up in
the whole program crashing (i.e. if all the tests are run in one
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
On 5/23/06, Vincent Snijders [EMAIL PROTECTED] wrote:
The problem is, that you can not expect a developer to test it on all 10+
supported
platforms before committing.
Umm, I keep forgetting FPC is a *beast* !!
Our apps only get deployed under Windows and Linux. We are able to
use VMWare for
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 for the
Graeme Geldenhuys wrote:
On 5/23/06, Vincent Snijders [EMAIL PROTECTED] wrote:
The problem is, that you can not expect a developer to test it on all
10+ supported
platforms before committing.
Umm, I keep forgetting FPC is a *beast* !!
Our apps only get deployed under Windows and Linux. We
However (as Maxim Ganetsky, who invented the patch, noted) the
windows console is a mess.
It is indeed. Windows uses the ANSI code page for most GUI stuff but uses
the OEM code page for the console (at least by default i belive there may be
ways to change it). In MOST cases the ANSI and OEM
On 5/23/06, Tomas Hajny [EMAIL PROTECTED] wrote:
believe this may happen for other targets too - if you have a misbehaving
RTL routine that overwrites half of your heap, you'll probably end up in
the whole program crashing (i.e. if all the tests are run in one process,
some of the tests
On 5/23/06, Marco van de Voort [EMAIL PROTECTED] wrote:
This process works for our company and we love to slap developers that
break the nightly build!!;-)
I hope that above points make clear that an OSS project is not a company.
Point taken, and the slap was meant with a smiley face at the
However (as Maxim Ganetsky, who invented the patch, noted) the
windows console is a mess.
pg It is indeed. Windows uses the ANSI code page for most GUI stuff but uses
pg the OEM code page for the console (at least by default i belive there may be
pg ways to change it). In MOST cases the ANSI and
Giulio Bernardi wrote:
Here it is.
SPI* constants are ordered by number and by os version required.
Applied, thx.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
It is matter of priorities: the mappings are long known. Unicode
standard is quite open too. If I had much free time, I'd work on
porting such a thing (from somewhere, there are many places) to FPC.
But I'm not yet accustommed to my full-time job:(
oh yes writing the converters is easy, but
They do not appear to be in any way GUI related so if my understanding of
the definitions is correct they belongs in FCL
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
sorry it seems i was mistaken, it seems to be a mixed visual and non-visual
unit :( But some of the stuff in there is pretty damn usefull to non-lazarus
apps.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of peter green
Sent: 24 May 2006 02:20
To:
39 matches
Mail list logo
