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 rectangles
On Thu, 10 Jun 2010, Adem wrote:
On 2010-06-10 00:11, German Gentile wrote:
2010/6/9 Adem listmem...@letterboxes.org
mailto:listmem...@letterboxes.org
So, what I am getting at is this: Is there such a list/platform
where only architectural/design issues (no commit details, no
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
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
On 10 June 2010 10:12, Felipe Monteiro de Carvalho
felipemonteiro.carva...@gmail.com 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
On 10 June 2010 10:15, Henry Vermaak henry.verm...@gmail.com wrote:
On 10 June 2010 10:12, Felipe Monteiro de Carvalho
felipemonteiro.carva...@gmail.com 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
I just reviewed r15401:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revrevision=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=14004r2=14005
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 SVN
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
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,
-
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,
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 into the
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
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
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
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));
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 (it
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.
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
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).
20 matches
Mail list logo
