Re: [fpc-devel] Suggestion for change: Overly strict check

On Monday 02 October 2006 19:20, Micha Nelissen wrote: > Christian Iversen wrote: > >> procedure TTest.DoWithFirst(a, First: Integer); > >> begin > >> First:=a; // ??? > >> FSomething:=First; // ??? > >> end; > > > > Ales, there is _no_ confusion here. Normal scope rules ensures that the > > fi

Re: [fpc-devel] ANN: Further patch for h2pas to use the ctypes unit

On Mon, 2 Oct 2006, J. Peter Mugaas wrote: > On Mon, 2 Oct 2006 20:41:49 +0200 (CEST), Michael Van Canneyt wrote: > > > > > > On Mon, 2 Oct 2006, J. Peter Mugaas wrote: > > > >> I have posted a patch that supplements my original patch to the > >> h2pas utility. This removes some WriteLn debug s

Re: [fpc-devel] va(r)_arg vs open array

Op Mon, 2 Oct 2006, schreef ik: > > Well, I think that this is also a functional thing. > > > > > > > > * Syntactically, both methods can be safe. > > > * Syntactically, the FPC/Delphi one is more powerfull. > > > > Well take a look at the way Java implement it: > > > > function varrags(

Re: [fpc-devel] va(r)_arg vs open array

On 10/2/06, Marco van de Voort <[EMAIL PROTECTED]> wrote: > On 10/2/06, Marco van de Voort <[EMAIL PROTECTED]> wrote: > > > 1. It's not a va_args. > > > > So? Other language, other syntax. We don't use {} either. > > Sure you do, {$include file.inc} {$H+} {Comment} We just don't use it > as the C

Re: [fpc-devel] last change to xmlreporter.pas (part of fpcUnit) not working

I did a diff to see what exactly changed in the xmlreporter. Just looking at the code makes no sense why it shouldn't work. Well, maybe it just isn't that obvious. :-) It looks like the FDoc.FindNode isn't working (it doesn't find the node and recreates it). Also the FindNode in TDOMDocument

Re: [fpc-devel] ANN: Further patch for h2pas to use the ctypes unit

On Mon, 2 Oct 2006, J. Peter Mugaas wrote: > I have posted a patch that supplements my original patch to the h2pas > utility. This removes some WriteLn debug statements that I made. I also > removed some pointer type redefinitions from the translated header. Those > pointer types are in ct

Re: [fpc-devel] va(r)_arg vs open array

> On 10/2/06, Marco van de Voort <[EMAIL PROTECTED]> wrote: > > > 1. It's not a va_args. > > > > So? Other language, other syntax. We don't use {} either. > > Sure you do, {$include file.inc} {$H+} {Comment} We just don't use it > as the C syntax wishes ... I hope it was obvious that I meant bloc

Re: [fpc-devel] va(r)_arg vs open array

On 10/2/06, Daniël Mantione <[EMAIL PROTECTED]> wrote: Op Mon, 2 Oct 2006, schreef ik: > > > 2. The usage of []. > > > > Same. Penalty for being safe. It is also required being able to mix non > > array of const and normal parameters. > > What is the difference ? I mean, what is the difference

[fpc-devel] ANN: Further patch for h2pas to use the ctypes unit

I have posted a patch that supplements my original patch to the h2pas utility. This removes some WriteLn debug statements that I made. I also removed some pointer type redefinitions from the translated header. Those pointer types are in ctypes. The patch works works better when you are not u

[fpc-devel] More on rounding bug(?)

(I am sorry to start a different thread but, from the location that I have a working FPC, I do not have access to the original posts.) 1. Delphi 6, 7, and TurboDelphi define the Round function as using Banker's Rounding by default. However, the Round function only rounds to an integer. (Beware,

Re: [fpc-devel] last change to xmlreporter.pas (part of fpcUnit) not working

Dean Zobec ha scritto: > Graeme Geldenhuys ha scritto: >> Hi, >> >> I got an update of FPC 2.1.1 today, and my fpcUnit test results are >> not correct anymore. The XML test listener (xmlreporter.pas) is not >> writing the Failures correctly. It keeps creating new (duplicate) >> list nodes for each

Re: [fpc-devel] Suggestion for change: Overly strict check

Christian Iversen wrote: >> procedure TTest.DoWithFirst(a, First: Integer); >> begin >> First:=a; // ??? >> FSomething:=First; // ??? >> end; > > Ales, there is _no_ confusion here. Normal scope rules ensures that the first > line only assigns the param "a" to the param "first". There are no

Re: [fpc-devel] va(r)_arg vs open array

Op Mon, 2 Oct 2006, schreef ik: > > > 2. The usage of []. > > > > Same. Penalty for being safe. It is also required being able to mix non > > array of const and normal parameters. > > What is the difference ? I mean, what is the difference between > fnc(a,b,c,d,e,f,g,h,i,j); > and > fnc(a,[bcd

Re: [fpc-devel] Suggestion for change: Overly strict check

Chris Cheney wrote: >> I'm pretty sure he means that no can no longer, for example, copy a function >> from one class to another, without risking having to rewrite all the >> parameter names. > > You have understood me correctly - I would have expressed it a little > differently, but not as suc

Re: [fpc-devel] last change to xmlreporter.pas (part of fpcUnit) not working

Graeme Geldenhuys ha scritto: > Hi, > > I got an update of FPC 2.1.1 today, and my fpcUnit test results are > not correct anymore. The XML test listener (xmlreporter.pas) is not > writing the Failures correctly. It keeps creating new (duplicate) > list nodes for each Failure. The Error nodes are

Re: [fpc-devel] Suggestion for change: Overly strict check

Christian Iversen wrote: > On Monday 02 October 2006 10:40, Vincent Snijders wrote: >>> * The restriction increases the number of incompatibilities with Delphi >>> and therefore increases the difficulty of porting existing programs. >> For porting Delphi programs, compile the unit with -Sd. > > Th

Re: [fpc-devel] va(r)_arg vs open array

On 10/2/06, Marco van de Voort <[EMAIL PROTECTED]> wrote: > On 10/2/06, Dani?l Mantione <[EMAIL PROTECTED]> wrote: > > > > Syntactically you cannot. However, the array of const is just as powerfull > > (actually more powerfull, since you can pass multiple arrays). We consider > > adding a trick t

Re: [fpc-devel] va(r)_arg vs open array

> On 10/2/06, Dani?l Mantione <[EMAIL PROTECTED]> wrote: > > > > Syntactically you cannot. However, the array of const is just as powerfull > > (actually more powerfull, since you can pass multiple arrays). We consider > > adding a trick to make it syntactically behave like writeln unnecessary. >

Re: [fpc-devel] va(r)_arg vs open array

Op Mon, 2 Oct 2006, schreef ik: > > > > Now we have open array, that's a really cool thing, but I can't > > > > understand why I can't have a feature such as the compiler voodoo > > > > magic of the "write" procedure. > > > > > > Syntactically you cannot. However, the array of const is just as >

Re: [fpc-devel] va(r)_arg vs open array

On 10/2/06, Daniël Mantione <[EMAIL PROTECTED]> wrote: Op Mon, 2 Oct 2006, schreef ik: > Hi, > > I'm wondering why Pascal as a language (and FPC with it's extensions) > does not support va_args (or var_args in the java language). It does: array of const. If you declare a procedure cdecl it is

Re: [fpc-devel] va(r)_arg vs open array

Op Mon, 2 Oct 2006, schreef ik: > Hi, > > I'm wondering why Pascal as a language (and FPC with it's extensions) > does not support va_args (or var_args in the java language). It does: array of const. If you declare a procedure cdecl it is even binary compatible with a C varargs. > Now we hav

[fpc-devel] va(r)_arg vs open array

Hi, I'm wondering why Pascal as a language (and FPC with it's extensions) does not support va_args (or var_args in the java language). Now we have open array, that's a really cool thing, but I can't understand why I can't have a feature such as the compiler voodoo magic of the "write" procedure.

Re: [fpc-devel] Rounding inconsistent (critical)

On 02/10/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: But 0.125 and 0.375 are representable ACCURATELY on a computer, aren't they? Vincent Yes they can, so FPC still has a bug in Banker's Rounding. What is really interresting is that I never really thought about irrational number and how

Re: [fpc-devel] Suggestion for change: Overly strict check

Here's the better example: TTest = class protected FField: Integer; public procedure Helper(Field: Integer); property Field: Integer read FField write FField; end; { TTest } procedure TTest.Helper(Field: Integer); begin with Self do Field:=Field; Writeln(Self.Field

Re: [fpc-devel] Suggestion for change: Overly strict check

> Ales, there is _no_ confusion here. Oh believe me there is. Especialy if you're writing just some little overriden method in a class which doesn't even have "property" visible anymore. You don't think about it and bang, error and a very neatly hidden one at that. It's not that I don't know wha

Re: [fpc-devel] Rounding inconsistent (critical)

Chris Cheney schreef: Date sent: Mon, 2 Oct 2006 12:59:45 +0200 From: "Graeme Geldenhuys" <[EMAIL PROTECTED]> To: "FPC developers' list" Subject:Re: [fpc-devel] Rounding inconsistent (critical) Send reply to: FPC develo

Re: [fpc-devel] Rounding inconsistent (critical)

Date sent: Mon, 2 Oct 2006 12:59:45 +0200 From: "Graeme Geldenhuys" <[EMAIL PROTECTED]> To: "FPC developers' list" Subject:Re: [fpc-devel] Rounding inconsistent (critical) Send reply to: FPC developers' list

Re: [fpc-devel] Rounding inconsistent (critical)

I also ran the exact example given on the Wikipedia site and I also got errors. AssertEquals('Failing on 1', '3.02', FormatFloat('0.00', 3.016)); AssertEquals('Failing on 2', '3.01', FormatFloat('0.00', 3.013)); AssertEquals('Failing on 3', '3.02', FormatFloat('0.00', 3.015)); AssertEquals('F

Re: [fpc-devel] Rounding inconsistent (critical)

On 02/10/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: > AssertEquals('Failing on 10', '0.44', FormatFloat('0.00', 0.445)); > AssertEquals('Failing on 11', '0.46', FormatFloat('0.00', 0.455)); Sorry, I shouldn't have used the work expected in my description, as that does confuse things a bi

Re: [fpc-devel] Rounding inconsistent (critical)

Graeme Geldenhuys schreef: On 02/10/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: It is not a bug, it is using bankers rounding. See http://lazarus-ccr.sourceforge.net/docs/rtl/system/round.html Vincent Exactly, but it is still wrong, except if I really don't know how Banker's rounding work

Re: [fpc-devel] Rounding inconsistent (critical)

Oh, I followed the rules as define for Banker's Rounding (round-to-even) show on Wikipedia http://en.wikipedia.org/wiki/Rounding Use that to round 0.445 and 0.455. I gather that Delphi 7 defaults to Common Rounding and not Banker's Rounding. Should FPC follow the Delphi rules on this to stay c

Re: [fpc-devel] Suggestion for change: Overly strict check

On Thursday 28 September 2006 10.54, Chris Cheney wrote: > > The restriction could be subject to a configurable option (perhaps it is > already) but, without a configurable option, the restriction should be > omitted. If the language is changed to suit the whims of the developers, > it might end up

Re: [fpc-devel] Rounding inconsistent (critical)

On 02/10/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: It is not a bug, it is using bankers rounding. See http://lazarus-ccr.sourceforge.net/docs/rtl/system/round.html Vincent Exactly, but it is still wrong, except if I really don't know how Banker's rounding works and what they mean by Even

Re: [fpc-devel] Suggestion for change: Overly strict check

On Monday 02 October 2006 11:46, Ales Katona wrote: > Having same function names as parameter names per se isn't a biggy but > the biggest problem is: > > TFirst = class > protected > FFirst: Integer; > public > property First: Integer read FFirst write FFirst; > end; > > TTest = class(TFirst

Re: [fpc-devel] Suggestion for change: Overly strict check

Having same function names as parameter names per se isn't a biggy but the biggest problem is: TFirst = class protected FFirst: Integer; public property First: Integer read FFirst write FFirst; end; TTest = class(TFirst) FSomething: Integer; public procedure DoWithFirst(a, First: Integ

Re: [fpc-devel] Rounding inconsistent (critical)

Graeme Geldenhuys schreef: Hi, I created the follow fpcUnit tests. For those that don't know fpcUnit, the AssertEquals takes three parameters: Failing message, Expected Value, Actual Value. Now from the tests below, I am formatting all values to 2 decimal values. I expected all tests to pass,

[fpc-devel] Rounding inconsistent (critical)

Hi, I created the follow fpcUnit tests. For those that don't know fpcUnit, the AssertEquals takes three parameters: Failing message, Expected Value, Actual Value. Now from the tests below, I am formatting all values to 2 decimal values. I expected all tests to pass, but it doesn't. Test 9 fail

Re: [fpc-devel] PIC support for x86_64

Florian Klaempfl a écrit : Dominique Leducq wrote: Could someone please tell me about the status of PIC support for x86_64 in FPC ? Is it supported in fpc 2.0.4 ? Is it supposed to work in 2.1.1 ? If yes, which revision(s) ? If no, will it be any time soon ? It is supposed to work in

Re: [fpc-devel] Suggestion for change: Overly strict check

> On Monday 02 October 2006 10:40, Vincent Snijders wrote: > > Chris Cheney schreef: > > > C'est magnifique, mais ce n'est pas la guerre. > > > > > > Two Very Bad Things: > > > > > > * The restriction increases the context sensitivity of the language. > > > > What do you mean? It thought it reduces

Re: [fpc-devel] Suggestion for change: Overly strict check

On Monday 02 October 2006 10:40, Vincent Snijders wrote: > Chris Cheney schreef: > > C'est magnifique, mais ce n'est pas la guerre. > > > > Two Very Bad Things: > > > > * The restriction increases the context sensitivity of the language. > > What do you mean? It thought it reduces the context sensi

Re: [fpc-devel] Suggestion for change: Overly strict check

Chris Cheney schreef: C'est magnifique, mais ce n'est pas la guerre. Two Very Bad Things: * The restriction increases the context sensitivity of the language. What do you mean? It thought it reduces the context sensitivity, because the context is less important to determine what a identifier

Re: [fpc-devel] Suggestion for change: Overly strict check

C'est magnifique, mais ce n'est pas la guerre. Two Very Bad Things: * The restriction increases the context sensitivity of the language. * The restriction increases the number of incompatibilities with Delphi and therefore increases the difficulty of porting existing programs. The restriction