doh ignore my last two posts it seems its only a mixed unit in delphi.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of peter green
> Sent: 24 May 2006 02:20
> To: fpc-devel@lists.freepascal.org
> Subject: [fpc-devel] Filectrl and fileutil should move fr
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: fp
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
>
> 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,
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
>> 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 AN
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
> 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 t
> 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 co
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
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, 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 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
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 proces
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
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 ne
---
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 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.
> >
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
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
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
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 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 ex
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
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
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
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
40 matches
Mail list logo
