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 rectangles in origin-extent and in two-point (TL, BR) representation. IMO two distinct types should be available for these, with according conversion procedures. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 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 coding minutea etc.) are discussed? I always think it is (FPC-DEV). Maybe be im completely wrong. Or, it is I that's way off the mark. But, what I had in mind was a forum/maillist where future directions are talked about. FPC-DEVEL, by definition, gets all sorts of development discussion --from FPC does not compile on platform X after recent changes to Souldn't this function result be this and not that?. I don't think another list is needed. We have already 3 (not counting Lazarus and the forums, plus IRC), that should be enough. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[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 such harsh opinions in any future emails. I know you guys are trying your best with Free Pascal, and in spite of everything I might have said, I still think Free Pascal is a great product with lots of potential. Once again, please accept my apology. [To pre-empt what Jonas will be saying... This is a off-topic message, so no replies needed.] Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[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 make cycle and things would work
fine, but using this combination I now get errors while building
packages/hash
I don't need all packages, I just need all those necessary for
Lazarus, although I am not sure which ones that is. Any ideas how I
can specify that packages/hash shouldn't be built, although I still
want all / most other packages to be built and installed?
I tryed to just delete the directory, but then make says that it is in
an unknown directory and quits =(
Here is my current script, which is strongly based on the script which
creates the Lazarus cross-installer. It also stops with errors in
packages/hash
PATH=C:\Programas\Lazarus24\fpc\2.2.0\bin\i386-win32\
mkdir C:\Programas\fpc_fixes_2_2\bin\
rm -rf *.exe
:: create a native compiler + utils
make compiler_cycle
FOR /F %%L IN ('compiler\utils\fpc.exe -PB') DO SET
COMPILER=C:\Programas\fpc_fixes_2_2\compiler\%%L
FOR /F %%L IN ('%COMPILER% -iSO') DO SET FPCSourceOS=%%L
FOR /F %%L IN ('compiler\utils\fpc.exe -PARM -PB') DO SET PPCNAME=%%L
:: rebuild the rtl without WPO information
make rtl_clean rtl PP=%COMPILER%
make -C utils/fpcm all FPC=%COMPILER%
make compiler FPC=%COMPILER% PPC_TARGET=arm EXENAME=%PPCNAME%
SET COMPILER=compiler\%PPCNAME%
SET CPU_TARGET=arm
SET OS_TARGET=wince
make -C rtl clean FPC=%COMPILER%
make -C packages clean FPC=%COMPILER%
make rtl packages FPC=%COMPILER%
FOR /F %%L IN ('%COMPILER% -iV') DO SET FPCVERSION=%%L
FOR /F %%L IN ('%COMPILER% -iW') DO SET FPCFULLVERSION=%%L
SET INSTALL_BASE=C:\Programas\fpc_fixes_2_2\bin\
SET INSTALL_BINDIR=C:\Programas\fpc_fixes_2_2\bin\
make rtl_install packages_install
FPCMAKE=%FPCSVNDIR%\fpcsrc\utils\fpcm\fpcmake.exe
INSTALL_PREFIX=%INSTALL_BASE% FPC=%COMPILER%
copy %COMPILER% %INSTALL_BINDIR%
pause
thanks,
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building a WinCE cross-compiler
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 correspond to FPC 2.2.2 using FPC 2.2.0 as the starting compiler. The problem is that I used to do a make cycle and things would work fine, but using this combination I now get errors while building packages/hash I don't need all packages, I just need all those necessary for Lazarus, although I am not sure which ones that is. Any ideas how I can specify that packages/hash shouldn't be built, although I still want all / most other packages to be built and installed? I tryed to just delete the directory, but then make says that it is in an unknown directory and quits =( Have you tried to remove the hash from the dirs= line in Makefile.fpc and then regenerate the makefiles? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building a WinCE cross-compiler
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 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 make cycle and things would work fine, but using this combination I now get errors while building packages/hash I don't need all packages, I just need all those necessary for Lazarus, although I am not sure which ones that is. Any ideas how I can specify that packages/hash shouldn't be built, although I still want all / most other packages to be built and installed? I tryed to just delete the directory, but then make says that it is in an unknown directory and quits =( Have you tried to remove the hash from the dirs= line in Makefile.fpc and then regenerate the makefiles? Hmm, you might have to remove the zlib and ldap targets, too, search for hash in Makefile.fpc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Potential merge conflict in r15401
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 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 SVN equivalent)? What is the coding standards in FPC? This is very unclear. I'm used to naming local variables as lMyVar (l prefix) and method parameters as AMyVar (A prefix), so using 'equals - aequals' as a local variable name is strange to me. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 some r14005 cherry-pick (I don't know the SVN equivalent)? What is the coding standards in FPC? This is very unclear. I'm used to naming local variables as lMyVar (l prefix) and method parameters as AMyVar (A prefix), so using 'equals - aequals' as a local variable name is strange to me. There are no official coding standards. Just one important guideline: don't change someone else's code style just to change it. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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, that will still conflict. or must one do some r14005 cherry-pick (I don't know the SVN equivalent)? 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 everything from trunk. You can also merge single revisions (is that what cherry picking means?), but eventually that branch has to be merged back into trunk so it's better to keep it completely in sync. 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 similar as the surrounding code (e.g., not introducing identifiers with camel case if the rest of the code uses all lowercase). This is very unclear. I'm used to naming local variables as lMyVar (l prefix) and method parameters as AMyVar (A prefix), so using 'equals - aequals' as a local variable name is strange to me. There are no conventions in FPC for naming parameters or local variables according to a particular pattern. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 into the current branch you are in. All the original commit information (author, date, comment etc.) is transferred. Now git log, merge, diff etc know where the new commit originated from and will not conflict. I looked in the SubVersion Red-Book doc and from that I think one can use the standard 'svn merge -r' command, but I don't think SubVersion tracks all the details like git. Anyway, it doesn't matter. My knowledge of SubVersion has degraded rapidly. Could somebody with more knowledge/confidence of SVN bring cpstrnew branch in sync with Trunk. I'll hold off on further commits I have for cpstrnew branch until then. naming. There are no fixed rules for those things, but it is recommended to keep things similar as the surrounding code (e.g., not OK, will do. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[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_reraise was called where it should not have
been called?
What could trigger it to be called?
Best Regards
Martin
On 09/06/2010 18:42, Martin wrote:
I am one tiny step forward..
The SigSegV happens in fpc_ReRaise; = but the actual error must have
been introduced further up.
Procedure fpc_ReRaise;[Public, Alias : 'FPC_RERAISE']; compilerproc;
var
_ExceptAddrStack : PExceptAddr;
begin
{$ifdef excdebug}
writeln ('In reraise');
{$endif}
_ExceptAddrStack:=ExceptAddrStack;
If _ExceptAddrStack=Nil then
DoUnHandledException;
ExceptObjectStack^.refcount := 0; //
longjmp(_ExceptAddrStack^.Buf^,FPC_Exception);
end;
This is RTL (and compiled with -O1 = it doesn't use regvar), so I
should be able to trust variables here. (I also checked the assembler
view, and memory/registers...)
- ExceptObjectStack is nil = So the line marked raises a SigSegV.
- ExceptAddrStack is not nil = so DoUnHandledException was not called
The question is, any hints where to concentrate looking, in order to
find out, how this can end up with a nil pointer there?
The content of ExceptAddrStack
record TEXCEPTADDR {
BUF = $a3ef728,
NEXT = $a3ef768,
FRAMETYPE = 1}
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 similar as the surrounding code (e.g., not introducing identifiers with camel case if the rest of the code uses all lowercase). Well. After all these years, first time I find out about this page. Luckily I follow the style as described there :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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_EXCEPTION (trunk/rtl/inc/except.inc), the only currently
available/supported value for FrameType.
Should it expect an ExceptionObject? Should it be on top of the frame
list, when in fpc_reraise?
Or does it indicate that fpc_reraise was called where it should not have
been called?
What could trigger it to be called?
First, as the name suggests, it's triggered by a 'raise' keyword in a
try..except block.
Second, and more important, any try..finally block (including the implicit ones) contains a call to
fpc_reraise. It is translated into:
try
body
except
finalization statements
raise; -- implies fpc_reraise
end;
Regards,
Sergei
On 09/06/2010 18:42, Martin wrote:
I am one tiny step forward..
The SigSegV happens in fpc_ReRaise; = but the actual error must have
been introduced further up.
Procedure fpc_ReRaise;[Public, Alias : 'FPC_RERAISE']; compilerproc;
var
_ExceptAddrStack : PExceptAddr;
begin
{$ifdef excdebug}
writeln ('In reraise');
{$endif}
_ExceptAddrStack:=ExceptAddrStack;
If _ExceptAddrStack=Nil then
DoUnHandledException;
ExceptObjectStack^.refcount := 0; //
longjmp(_ExceptAddrStack^.Buf^,FPC_Exception);
end;
This is RTL (and compiled with -O1 = it doesn't use regvar), so I
should be able to trust variables here. (I also checked the assembler
view, and memory/registers...)
- ExceptObjectStack is nil = So the line marked raises a SigSegV.
- ExceptAddrStack is not nil = so DoUnHandledException was not called
The question is, any hints where to concentrate looking, in order to
find out, how this can end up with a nil pointer there?
The content of ExceptAddrStack
record TEXCEPTADDR {
BUF = $a3ef728,
NEXT = $a3ef768,
FRAMETYPE = 1}
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[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));
writeln('BIG_B: $', IntToHex(BIG_B, sizeof(BIG_B) * 2));
q := BIG_A;
write('q: $', IntToHex(q, sizeof(q) * 2), ' ');
if (q = BIG_A) then begin
writeln('same');
end else begin
writeln('different');
end;
q := BIG_B;
write('q: $', IntToHex(q, sizeof(q) * 2), ' ');
if (q = BIG_B) then begin
writeln('same');
end else begin
writeln('different');
end;
end.
==
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 fails in the first
example, works in the second). It should work correctly whether I cast
the constant or not.
I was going to log a bug on it but mantis isn't letting me,
bug_report_page.php keeps just coming up blank for me.
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 (it fails in the first
example, works in the second). It should work correctly whether I cast
the constant or not.
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)
b) int64($AB09CD87EF653412) 0
c) hence, qwordvar = $AB09CD87EF653412 can never be true.
The code also refuses to compile with range checking enabled (and prints a
warning without range checking on).
It's the same situation as this code:
var
c: cardinal;
begin
c:=high(cardinal);
if c=-1 then
writeln('c = -1')
else
writeln('c -1');
end.
This prints, also with FPC 2.4.0, c -1.
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[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 Grover sethdgrover[at]gmail[dot]com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[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 behavior of the code between yesterday and today changed. Thanks. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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.telenet.be/Jan.Van.hijfte/qtforfpc/maemo_lcl_qt4.png http://lists.lazarus.freepascal.org/pipermail/qt/2010-June/001547.html ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
