Re: [fpc-devel] Armel problems

On Sunday 23 May 2010 21:51:17 Den Jean wrote: > I made a demo program of the bug, > using the style of one of the fpc test suite program tcalext2.pp > > http://bugs.freepascal.org/view.php?id=16520 thanks to the fpc arm fix of Jonas, fpc is now working on the Nokia N900 (arm). http://users.tel

[fpc-devel] Re: large constant and qword comparison broken in fixes_2_4 rev 15403

Jonas wrote: > I'm not sure about that. The reason it doesn't work is because > a) $AB09CD87EF653412 is interpreted as an int64 constant (this was already > the case before the change) If that's the case, then I can accept that and just cast the constant as a qword. I just reported it because the

[fpc-devel] Re: large constant and qword comparison broken in fixes_2_4 rev 15403

My problem connecting to mantis has somehow resolved itself, so I did log the bug. Apologies for reporting it here as well as there. http://bugs.freepascal.org/view.php?id=16694 -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth

Re: [fpc-devel] large constant and qword comparison broken in fixes_2_4 rev 15403

On 10 Jun 2010, at 20:06, Seth Grover wrote: > A recent change to fixes_2_4 (I think it was rev 15403) has broken > this example. With yesterday's code the code prints out "same" both > times (which is correct), but after pulling today's revision it only > works if the constant is cast as a qword

[fpc-devel] large constant and qword comparison broken in fixes_2_4 rev 15403

Given this example (http://pastebin.com/JQVqF7SV): == program project1; {$mode objfpc}{$H+} uses SysUtils; const BIG_A = $AB09CD87EF653412; BIG_B = qword($AB09CD87EF653412); var q : qword; begin writeln('BIG_A: $', IntToHex(BIG_A, sizeof(BIG_A) * 2)); wri

Re: [fpc-devel] ExceptAddrStack FRAMETYPE=1 ?

Martin wrote: I am still stuck on this issue. I don't know if fpc_reraise has been entered while it should not; or if the data was corrupted. Normally you should be able to figure it out by examining the call stack/backtrace. What does FRAMETYPE = 1 mean? Guess it is the value of FPC_EXC

Re: [fpc-devel] Potential merge conflict in r15401

On Thu, 10 Jun 2010, Jonas Maebe wrote: What is the coding standards in FPC? In general: http://wiki.freepascal.org/Coding_style As you'll notice, many things are not defined, such as identifier naming. There are no fixed rules for those things, but it is recommended to keep things simila

[fpc-devel] ExceptAddrStack FRAMETYPE=1 ?

I am still stuck on this issue. I don't know if fpc_reraise has been entered while it should not; or if the data was corrupted. What does FRAMETYPE = 1 mean? Should it expect an ExceptionObject? Should it be on top of the frame list, when in fpc_reraise? Or does it indicate that fpc_rerai

Re: [fpc-devel] Potential merge conflict in r15401

Op 2010-06-10 14:17, Jonas Maebe het geskryf: > > And I don't know what "cherry picking" is. r14005 has to be reverted, > and then the entire branch should be brought up-to-date by merging I take it you meant r15401. "cherry picking" is taking the same commit from another branch and merge it in

Re: [fpc-devel] Potential merge conflict in r15401

On 10 Jun 2010, at 14:03, Graeme Geldenhuys wrote: Op 2010-06-10 13:45, Vincent Snijders het geskryf: I think it would be better to revert it and apply the changes from r14005, so that it can be merged more easily. Can I simply change the 'lEquals' to 'aequals' in a new commit, No, tha

Re: [fpc-devel] Potential merge conflict in r15401

Op 2010-06-10 14:13, Michael Van Canneyt het geskryf: > > There are no official coding standards. Just one important guideline: > don't change someone else's code style "just to change it". OK thanks. I knew about that rule, and just to be clear, that wasn't the reason for r15401. Regards, -

Re: [fpc-devel] Potential merge conflict in r15401

On Thu, 10 Jun 2010, Graeme Geldenhuys wrote: Op 2010-06-10 13:45, Vincent Snijders het geskryf: I think it would be better to revert it and apply the changes from r14005, so that it can be merged more easily. Can I simply change the 'lEquals' to 'aequals' in a new commit, or must one do

Re: [fpc-devel] Potential merge conflict in r15401

Op 2010-06-10 13:45, Vincent Snijders het geskryf: > > I think it would be better to revert it and apply the changes from r14005, so > that > it can be merged more easily. Can I simply change the 'lEquals' to 'aequals' in a new commit, or must one do some r14005 cherry-pick (I don't know the SV

[fpc-devel] Potential merge conflict in r15401

I just reviewed r15401: http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=15401 I think it would be better to revert it and apply the changes from r14005, so that it can be merged more easily. http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/nobj.pas?r1=14004&r2=14005 V

Re: [fpc-devel] Building a WinCE cross-compiler

Thanks, That worked, but curiously I had to change the dirs= part and even add winceunits to it. Just changing the dirs_wince= part didn't help. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freep

Re: [fpc-devel] Building a WinCE cross-compiler

On 10 June 2010 10:15, Henry Vermaak wrote: > On 10 June 2010 10:12, Felipe Monteiro de Carvalho > wrote: >> Hello, >> >> I am trying to build revisions between FPC 2.2.2 and FPC 2.2.0. Those >> should be wince cross-compilers. For this initial part consider that I >> am building rev11490 from fi

Re: [fpc-devel] Building a WinCE cross-compiler

On 10 June 2010 10:12, Felipe Monteiro de Carvalho wrote: > Hello, > > I am trying to build revisions between FPC 2.2.2 and FPC 2.2.0. Those > should be wince cross-compilers. For this initial part consider that I > am building rev11490 from fixes_2_2 which should correspond to FPC > 2.2.2 using F

[fpc-devel] Building a WinCE cross-compiler

Hello, I am trying to build revisions between FPC 2.2.2 and FPC 2.2.0. Those should be wince cross-compilers. For this initial part consider that I am building rev11490 from fixes_2_2 which should correspond to FPC 2.2.2 using FPC 2.2.0 as the starting compiler. The problem is that I used to do a

[fpc-devel] my appologies

Hi everybody, I know this is a bit off-topic here, but at least I can reach all persons it question in one go. I apologize for my outbursts in recent months. I guess it's stress at home and work which is taking it's toll on me. I don't handle stress well. I'll try my best to refrain from posting

Re: [fpc-devel] fpc-architect list? [was: Slight calculation error in Bounds() procedure in Classes unit.]

On Thu, 10 Jun 2010, Adem wrote: On 2010-06-10 00:11, German Gentile wrote: 2010/6/9 Adem > So, what I am getting at is this: Is there such a list/platform where only architectural/design issues (no commit details, no coding minutea etc.) are d

Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.

Graeme Geldenhuys schrieb: Bounds is used a lot in Delphi and LCL applications. So for "delphi compatibility" we now need to duplicate Delphi bugs in FPC too? FPC <> DELPHI. It's not a bug, it's a commonly accepted graphics model. The only thing I'm missing is a distinction between rectang