Re: [fpc-devel] win64 on trunk broken
Vincent Snijders schreef:
Vincent Snijders schreef:
Hi,
I get an internal error when I compile fcl-db of fpc 2.3.1.
-FE. -FUunits/x86_64-win64 -gl -dx86_64 -dRELEASE src/db.pas
fields.inc(1071,12) Fatal: Internal error 200108291
Fatal: Compilation aborted
This is the same IE as in http://www.freepascal.org/mantis/view.php?id=8580
Just a quick update, I tracked down the revision that broke it:
r6855.
The following program shows the IE:
program Project1;
{$mode objfpc}{$H+}
type
TStringFieldBuffer = Array[0..8192] of Char;
var Buf : TStringFieldBuffer;
begin
Buf := #0;
end.
When I have time, I will create a bug report, unless you find the fix
tonight of course :-)
Vincent
___
fpc-devel maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] patch for heaptrc
Attached patch add the same sanity check for the frame pointer in TraceReAllocMem as
already is in TraceGetMem. It fixed crashes of Lazarus on win64 when compiled with
heaptrc.
Tested with fpc 2.1.3. fpc 2.3.1 is currently broken on win64, see mail of 8
April.
Vincent
Index: heaptrc.pp
===
--- heaptrc.pp (revision 7084)
+++ heaptrc.pp (working copy)
@@ -628,6 +628,7 @@
allocsize,
movesize,
i : ptrint;
+ oldbp,
bp : pointer;
pl : pdword;
pp : pheap_mem_info;
@@ -745,7 +746,10 @@
for i:=1 to tracesize do
begin
pp^.calls[i]:=get_caller_addr(bp);
+ oldbp:=bp;
bp:=get_caller_frame(bp);
+ if (bpoldbp) or (bp(StackBottom + StackLength)) then
+ bp:=nil;
end;
{ regenerate signature }
if usecrc then
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] win64 on trunk broken
Vincent Snijders schreef: Hi, I get an internal error when I compile fcl-db of fpc 2.3.1. -FE. -FUunits/x86_64-win64 -gl -dx86_64 -dRELEASE src/db.pas fields.inc(1071,12) Fatal: Internal error 200108291 Fatal: Compilation aborted This is the same IE as in http://www.freepascal.org/mantis/view.php?id=8580 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] win64 on trunk broken
Hi, I get an internal error when I compile fcl-db of fpc 2.3.1. make[2]: Entering directory `C:/lazarus/source/fpc/2.3/packages/fcl-db' /lazarus/source/fpcbuild/trunk/install/binw64/gmkdir.exe -p units/x86_64-win64 c:/lazarus/source/fpc/2.1/compiler/ppcx64.exe -Ur -Xs -O2 -n -S2h -Fusrc/dbase -FuC:/lazarus/source/fpc/2.3/rtl/units/x86_64-win64 -FuC:/lazarus/source/fpc/2.3/packages/base/hash/units/x86_64-win64 -FuC:/lazarus/source/fpc/2.3/packages/base/paszlib/units/x86_64-win64 -FuC:/lazarus/source/fpc/2.3/packages/base/netdb/units/x86_64-win64 -FuC:/lazarus/source/fpc/2.3/packages/fcl-base/units/x86_64-win64 -FuC:/lazarus/source/fpc/2.3/packages/base/winunits/units/x86_64-win64 -FE. -FUunits/x86_64-win64 -gl -dx86_64 -dRELEASE src/dbconst.pas c:/lazarus/source/fpc/2.1/compiler/ppcx64.exe -Ur -Xs -O2 -n -S2h -Fusrc/dbase -FuC:/lazarus/source/fpc/2.3/rtl/units/x86_64-win64 -FuC:/lazarus/source/fpc/2.3/packages/base/hash/units/x86_64-win64 -FuC:/lazarus/source/fpc/2.3/packages/base/paszlib/units/x86_64-win64 -FuC:/lazarus/source/fpc/2.3/packages/base/netdb/units/x86_64-win64 -FuC:/lazarus/source/fpc/2.3/packages/fcl-base/units/x86_64-win64 -FuC:/lazarus/source/fpc/2.3/packages/base/winunits/units/x86_64-win64 -FE. -FUunits/x86_64-win64 -gl -dx86_64 -dRELEASE src/db.pas fields.inc(1071,12) Fatal: Internal error 200108291 Fatal: Compilation aborted Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] overflow checking
Vincent Snijders schreef: Hi, I am trying to compile and run some parts of Lazarus (lcl\interfaces\win32) with -Criot. I get some overflow errors I don't understand. I tried to understand the logic behind the generated assembler and made a small test program, which doesn't give an overflow error, but that has the same (AFAICS) wrong assembler. I am using fpc 2.3.1. I think this is a bug in the compiler, so I created a bug report: http://www.freepascal.org/mantis/view.php?id=8573 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] overflow checking
Hi,
I am trying to compile and run some parts of Lazarus
(lcl\interfaces\win32) with -Criot. I get some overflow errors I don't
understand. I tried to understand the logic behind the generated
assembler and made a small test program, which doesn't give an overflow
error, but that has the same (AFAICS) wrong assembler. I am using fpc 2.3.1.
Pascal code:
program Project1;
{$mode objfpc}{$H+}
const
WAIT_OBJECT_0 = 0;
var
retVal : dword;
FWaitHandleCount: dword;
begin
retVal := 258;
FWaitHandleCount := 0;
if retVal = WAIT_OBJECT_0 + FWaitHandleCount then
writeln('OK');
readln;
end.
Generated assembler:
.Ll3:
# [14] FWaitHandleCount := 0;
movl$0,U_P$PROJECT1_FWAITHANDLECOUNT
.stabn 68,0,15,.Ll4 - _main
.Ll4:
# [15] if retVal = WAIT_OBJECT_0 + FWaitHandleCount then
movlU_P$PROJECT1_FWAITHANDLECOUNT,%eax
jnb .Lj9
callFPC_OVERFLOW
.Lj9:
cmplU_P$PROJECT1_RETVAL,%eax
je .Lj7
jmp .Lj8
Why is there an overflow check ?
What can set the carry flag used by the jnb?
If I change
if retVal = WAIT_OBJECT_0 + FWaitHandleCount then
to
if retVal = FWaitHandleCount then
then there is no overflow check.
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] merge of revision 6749
Vincent Snijders schreef: Hi, Why is revision 6749 merged in revsion 6771? It is the likely cause of bug 8492, so I would have waited with the merge, until that bug has been fixed. Since this bug has not been fixed yet, I propose to undo the merge to the fixes branch for now. After all, it would be nice if people could use xmlcfg in fpc 2.1.4. And Joost has said he will allow only build related fixes in 2.1.3, so we must undo the merge before tagging 2.1.2. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Google summer of code
Felipe Monteiro de Carvalho schreef: On 3/9/07, Vincent Snijders [EMAIL PROTECTED] wrote: I think both Mattias and Mark work in much larger parts of Lazarus. I would describe them as two people who have contributed much in almost all parts of the project (IDE, debugger, designer, codetools, LCL, different widgetsets). I know, the same applied for Peter on fpc, but they asked to be specific, so I just collected a example that came on my mind. It´s not intended to describe what they did, but just to fullfil that requisite for the application. If you want to give examples, then IDE and codetools is Mattias' expertise, debugger and general widget set interface is Marc's expertise. But I would just say, that we choose people who have both a broad general knowledge of the compiler / IDE and an in depth knowledge of their specific expertise. So they have a complete picture of either FPC or Lazarus, and know details of a specific part. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] merge of revision 6749
Hi, Why is revision 6749 merged in revsion 6771? It is the likely cause of bug 8492, so I would have waited with the merge, until that bug has been fixed. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Google summer of code
Felipe Monteiro de Carvalho schreef: Here is my initial proposal: Dear Sir or Madam, With this email we would like to apply as mentoring organization for your Summer of Code program. We hope that with your funding we can improve the project. FPC/Lazarus is the joined effort of two development teams to bring the power of RAD tools using a compiled language to all interesting platforms. Currently we support several architectures (x86, Amd64/x86_64, PowerPC, Sparc and ARM), and several operating systems (Windows, Windows CE, Linux, FreeBSD, Mac OS X, Mac OS classic, DOS, Win32, OS/2, Netware, MorphOS and others). We, the maintainers of the FreePascal and Lazarus projects would like to apply as a single organization (called FPC/Lazarus) since our projects are very closely related. FreePascal (http://www.freepascal.org/) develops a free multiplatform Pascal compiler and the runtime environment. The FreePascal project is already a very long-running OSS project, it has been developed in 1993 with a first release in 1996 (http://tinyurl.com/edolq) and since then has evolved in a rather large project, already supporting a lot of platforms on several different processor families. The FreePascal team would like to take this opportunity to extend the compiler and improve its quality even more. A collection of ideas for students working on the FreePascal can be found at http://wiki.freepascal.org/index.php/Open_tasks . Of course we are willing to provide more exact requirements for each particular task if required. Lazarus (http://www.lazarus.freepascal.org) has been founded in 1999 with the goal of developing a RAD IDE based on FPC. It provides a modern class library and an IDE for the development of GUI programs, and is compatible with Borland Delphi VCL, which allows complex GUI software created on Delphi to be ported to many platforms using Lazarus. We hope that this project will allow us to improve our project, add new features, and make it an even better cross-platform development environment. There is a collection of ideas to be implemented here: http://wiki.freepascal.org/Feature_Ideas Both the compiler and IDE are provided under the GPL, while the runtime libraries are provided under the LGPL with the explicit permission for static linking. Several of the developers have experience with teaching students or work as professional software engineers, so we think that the mentored students will be able to learn a lot about software development besides the experience they can get when participating the Summer of Code. We applied last year to participade on summer of code. We applied last year to participate on summer of code. Felipe Monteiro de Carvalho will be the organization administrator. He's e-mail is [EMAIL PROTECTED] Our mailling lists can be found at: http://www.freepascal.org/maillist.var and http://www.lazarus.freepascal.org/modules.php?op=modloadname=StaticPagefile=indexsURL=maill Our main IRC channels are #fpc and #lazarus-ide , both on FreeNode server. Best regards, Felipe Monteiro de Carvalho in behalf of the FPC/Lazarus development teams I'm not sure how to answer the following topics. I will just make a guess of how to answer them here: 11. Who will be your backup organization administrator? Please include Google Account information. I would say that probably Florian could be the backup admin Just what is a Google Account information? I think a gmail email address. 12. Who will your mentors be? Please include Google Account Information. I here thereby nominate: Mattias, Daniel Mationi, Peter, Mark, Vincent =) Daniel Mantione Later we can change this anyway. Other volunteers? 13. What criteria did you use to select these individuals as mentors? Please be as specific as possible. All the selected individuals have greatly contributed to our projects. For a short example, Peter wrote a new Internal Linker for FPC, Mattias leads the gtk development on Lazarus and Mark the Windows development. I think both Mattias and Mark work in much larger parts of Lazarus. I would describe them as two people who have contributed much in almost all parts of the project (IDE, debugger, designer, codetools, LCL, different widgetsets). Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Google summer of code
Felipe Monteiro de Carvalho schreef: reminder For what? Did you write a proposal? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Google summer of code
Felipe Monteiro de Carvalho schreef: For what? Did you write a proposal? No, because I am waiting for an answer if fpc developers agree that fpc and lazarus should have only 1 proposal, and if I can write it, and it would also be good to see the proposal from last year. I think that the fpc team isn't really motivated to apply after last years rejection. See tonight's logs on #fpc. Speaking for myself (and probably the Lazarus team), I wish you good luck and want to be supportive, but I think we have very little chance to enter, so I don't want to spend too much time on it. (It is a risky investment.) Feel free to apply as one proposal or with two proposals, whatever you think that is best. I will forward you in private some mails of last year. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Inter Process Communication
Jason P Sage schreef: I used CGI for portability - but to counter the delay of loading involved CGI executables - I created a very thin CGI client (50k on Win32 - unfortunately - 250k+ on Linux - (something about the smart linking isn't as good on linux). snip fastcgi mentioned several times My next two agendas are creating my own web server - possibly using the sockets unit if I can see a working demo that runs on both linux and win32. I'd prefer to the FPC RTL version sockets; second - I may go full bore FastCGI, which is very clear on how its supposed to work - but documentation is lacking for setting it up for non-php and non-ruby solutions (I'll figure it out eventually). FastCGI seems the right way to go - but I've yet to get one of the FastCGI programs - like echo or threaded to actually return something in a browser after much configuration experiments. Wish me well and thanx for your advice. To give you a headstart, you might want to look at fphttpd. It is a side project of lNet (See http://wiki.lazarus.freepascal.org/lNet) and is a http server written by Micha Nelissen with fpc and supporting fastcgi. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CompareValue
C Western schreef: Пётр Косаревский wrote: In the math unit are the CompareValue functions only for signed integers. Why not for DWORD and QWORD? I guess, that it's Delphi mimicing implementation (because it is Delphi-like). And it can be tricky to distinguish signed and unsigned expression values. Like, a: qword; a-1 --- ??? (anyone may know for sure that a-10 and want to subtract one) I guess it's something like that. If you check http://www.freepascal.org/mantis/view.php?id=8448 you can see this bug in action - the fpcadds and math unit provide signed and unsigned versions of CompareValue, but the correct one is not always chosen. What a lousy compiler we use! ;-) Do you have a testprogram, so I can make a fpc bug report? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CompareValue
[EMAIL PROTECTED] schreef: Quoting Vincent Snijders [EMAIL PROTECTED]: C Western schreef: ð£ÔÒ ëÏÓÁÒÅ×ÓËÉÊ wrote: In the math unit are the CompareValue functions only for signed integers. Why not for DWORD and QWORD? I guess, that it's Delphi mimicing implementation (because it is Delphi-like). And it can be tricky to distinguish signed and unsigned expression values. Like, a: qword; a-1 --- ??? (anyone may know for sure that a-10 and want to subtract one) I guess it's something like that. If you check http://www.freepascal.org/mantis/view.php?id=8448 you can see this bug in action - the fpcadds and math unit provide signed and unsigned versions of CompareValue, but the correct one is not always chosen. What a lousy compiler we use! ;-) Do you have a testprogram, so I can make a fpc bug report? I think this is inherent in the language design, as it is too easy to convert between signed and unsigned integers. For example should the call: CompareValue(0,0) use the signed or unsigned version? But in this particular case, I did not use constants, but variables of the same type. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] CompareValue
Hi,
In the math unit are the CompareValue functions only for signed integers. Why not
for DWORD and QWORD?
I tested with the program below.
For DWord is works correctly, presumely because the int64 overload is used.
For QWord without typecast the code doesn't compile, because the compile cannot
choose the right overload. With typecasts it returns the wrong values.
The math unit also has these lines:
{ this causes more trouble than it solves
function Min(a, b: Cardinal): Cardinal;
function Max(a, b: Cardinal): Cardinal;
}
It doesn't tell what problems and why.
Vincent
===
program Project1;
{$mode objfpc}{$H+}
uses
Classes, SysUtils, Math
{ add your units here };
var
d1, d2: dword;
q1, q2: qword;
begin
d1 := $F000;
d2 := 10;
writeln('CompareValue (d1,d2): ', comparevalue(d1,d2));
writeln('CompareValue (d2,d1): ', comparevalue(d2,d1));
q1 := $F000;
q2 := 10;
writeln('CompareValue (q1,q2): ', comparevalue(int64(q1),int64(q2)));
writeln('CompareValue (q2,q1): ', comparevalue(int64(q2),int64(q1)));
readln;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch:more clear definition of makeintresource, clearer definitions in wince defines.inc
Roozbeh GHolizadeh schreef: Summary : MakeIntResource was previously declared as function in win32 and wince,windows.pp files,also we had one declared in rtl\resh.inc as pchar and also there was some uses of it just as pchar in classes. All these makes some problems in lazarus,as we cant have constants declared as arrays of makeintresource and things like this. Obviously makeintresource is just a type definition,so instead of this function function MAKEINTRESOURCE(i : longint) : LPTSTR; begin MAKEINTRESOURCE:=LPTSTR(DWORD(WORD(i))); end; it could be changed into pchar(LPSTR) or pwidechar(lpwcstr). and making all other functions being declared as constants. I suggest the same changes also to win32. Who is going to look after this patch? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] daemon units in Lazarus (to Michael van Canneyt ?)
Bram Kuijvenhoven schreef: Michael Schnell wrote: How can access the SVN ? Unfortunately I suppose I can't access a Version Control System as here we ave a Firewall that only allows to do http and ftp via a proxy. IIRC SVN also can use the http protocol (exactly for this reason). Note that some proxies are broken or badly configured and don't pass webdav comments correctly. My company has such a broken proxy. As a workaround one can use the https protocol, which proxies leave untouched. But AFAIK the freepascal server doesn't listen on the https port. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] daemon units in Lazarus (to Michael van Canneyt ?)
Michael Schnell schreef: See http://www.freepascal.org/develop.var#svn for details on using SVN -- note that the command use an URL starting with http://. For Windows there is also a nice graphical Shell integrated interface to SVN, called TortoiseSVN. Using TortoiseSVN I get could not connect to server (http://snv.freepascal.org) if I try to do SNV checkout. There is a typo: use http://svn.freepascal.org Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] daemon units in Lazarus (to Michael van Canneyt ?)
Michael Schnell schreef: The URL for tortoiseSVN is http://svn.freepascal.org/svn/fpc/trunk Right. That is exactly what I did. The other error message I got was PROFIND request failed on '/svn/fpc/trunk'. That is the error I get too, because of a broken or misconfigured proxy. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] daemon units in Lazarus (to Michael van Canneyt ?)
Michael Schnell schreef: The URL for tortoiseSVN is http://svn.freepascal.org/svn/fpc/trunk Right. That is exactly what I did. The other error message I got was PROFIND request failed on '/svn/fpc/trunk'. The long delay before the error is displayed suggests that the server does not answer at all - not even with an error notification, wile explorer does display http://svn.freepascal.org/svn/fpc/trunk as a directory tree This has happened before and some people could work around it using the port 8080. svn co http://svn.freepascal.org:8080/svn/fpc/trunk Doesn't work here though: svn: PROPFIND request failed on '/svn/fpc/trunk' svn: PROPFIND of '/svn/fpc/trunk': 501 Not Implemented (http://svn.freepascal.org:8080) Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] procedure ... message
Michael Schnell schreef: peter green wrote: What does the compiler do when translating procedure ... message ? I need to know this as I want to create a non-GUI workalike of the TApplication class that can do things like TTimer TThread.Synchronize, Message events, etc, using Windows messages in Windows (for testing purpose) and system V message queues in Linux. afaict it does the same as delphi does, puts them in some form of table which is used by the dispatch method in tobject (which on delphi at least is called from wndproc which is called from mainwindowproc which is registered as the window procedure for the window and hence called by windows when the mainloop calls the windows api function dispatchmessage). Thanks a lot for your answer. I see you are still a bit lost. Maybe the documentation can help: http://www.freepascal.org/docs-html/ref/refsu24.html Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] procedure ... message
Michael Schnell schreef: I see you are still a bit lost. Maybe the documentation can help: http://www.freepascal.org/docs-html/ref/refsu24.html I in fact am lost (as I still don't dare to try to look into the compiler's source code). Unfortunately the docs text does not say what code the compiler generates to make the library assign the message to the function it generates from the users source code. That is because the compiler doesn't generate that code. Somewhere user code must call MyObject.Dispatch(MyMessage); See implementation of dispatch. It gets the message number and looks for the corresponding method in a table. The compiler generates this table at compile time. This may not be the completely accurate description, but this is how I model things in my mind and in my experiments reality hasn't falsified this model. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Command line parameter for using heaptrc without debuginfo
Hi, I want to include memory checking in my test application without having the debuginfo (since that makes the application 10 times as big and takes longer to compile). Even without debuginfo it gives information, about the number of allocated memory blocks that are not freed and whether some memory has taken place. To find the location a recompilation with debug info is needed of course. I tried to set -gh -Xs includes the debuginfo. Also the following did not work: -gh -g- or -gh -gl- What worked is -g- -Xs and add uses heaptrc to the main program. Is this the only solution? Is the current behavior (enabling debuginfo if -gh is passed) by design? Vincent P.S. While typing I got an idea: -Faheaptrc does exactly what I want. I just thought -gh would do the same. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TProcess.NumBytesAvailable
Hi,
TAsyncProcess from the LCL has a property NumBytesAvailable. Attached patch adds it
to TProcess in the FCL.
NumBytesAvailable checks how many bytes are available in TProcess.Output, so you can
decide not to read from it if there are no bytes available.
Maybe you want a different name for the property or different implementation
details. If so, let it know, so I can adapt the patch.
Vincent
Index: inc/process.pp
===
--- inc/process.pp (revision 6181)
+++ inc/process.pp (working copy)
@@ -41,6 +41,9 @@
Type
+
+ { TProcess }
+
TProcess = Class (TComponent)
Private
FProcessOptions : TProcessOptions;
@@ -69,6 +72,7 @@
dwy : Cardinal;
Procedure FreeStreams;
Function GetExitStatus : Integer;
+function GetNumBytesAvailable: dword;
Function GetRunning : Boolean;
Function GetWindowRect : TRect;
Procedure SetWindowRect (Value : TRect);
@@ -113,6 +117,7 @@
Property Stderr : TinputPipeStream Read FStderrStream;
Property ExitStatus : Integer Read GetExitStatus;
Property InheritHandles : Boolean Read FInheritHandles Write
FInheritHandles;
+Property NumBytesAvailable: dword read GetNumBytesAvailable;
Published
Property Active : Boolean Read GetRunning Write SetActive;
Property ApplicationName : String Read FApplicationName Write
SetApplicationName;
Index: unix/process.inc
===
--- unix/process.inc(revision 6181)
+++ unix/process.inc(working copy)
@@ -4,7 +4,9 @@
uses
Unix,
- Baseunix;
+ Baseunix
+ {$IFDEF linux},TermIO{$ENDIF}
+ ;
resourcestring
SErrNoSuchProgram = 'Executable not found: %s';
@@ -240,6 +242,23 @@
end;
end;
+{$ifdef BSD}
+const
+ FIONREAD = $4004667F;
+{$endif}
+
+function TProcess.GetNumBytesAvailable: dword;
+begin
+ if not (poUsePipes in Options) then
+Result := 0
+ else begin
+// FIONREAD - bytes available for reading without blocking
+if fpioctl(Output.Handle, FIONREAD, @Result)0 then
+ Result := 0;
+ end;
+end;
+
+
Procedure TProcess.Execute;
Var
Index: win/process.inc
===
--- win/process.inc (revision 6181)
+++ win/process.inc (working copy)
@@ -149,6 +149,17 @@
end;
+Function TProcess.GetNumBytesAvailable: DWORD;
+
+begin
+ if not (poUsePipes in Options) then
+Result := 0
+ else
+ if not PeekNamedPipe(Output.Handle, nil, 0, nil, @Result, nil) then
+Result := 0;
+end;
+
+
Procedure TProcess.Execute;
Index: wince/process.inc
===
--- wince/process.inc (revision 6181)
+++ wince/process.inc (working copy)
@@ -149,6 +149,14 @@
end;
+Function TProcess.GetNumBytesAvailable: DWORD;
+
+begin
+ // Windows CE doesn´t have the API function PeekNamedPipe
+ Result := 0;
+end;
+
+
Procedure TProcess.Execute;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess.NumBytesAvailable
Marc Weustink schreef: Vincent Snijders wrote: Hi, TAsyncProcess from the LCL has a property NumBytesAvailable. Attached patch adds it to TProcess in the FCL. NumBytesAvailable checks how many bytes are available in TProcess.Output, so you can decide not to read from it if there are no bytes available. What about StdErr output ? Cant this be a property of the TInputPipeStream ? Seems like an good idea. I will create a new patch. Jonas Maebe schreef: The FIONREAD constant is available in the termio units of both Darwin and FreeBSD as of 2.0.4 (not for Open/NetBSD, but that's probably the least of the things which need to be changed to get those platforms going again). Thanks for the hint. I guess this was not yet the case when TAsyncProcess was written by Micha. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess.NumBytesAvailable
Vincent Snijders schreef:
Marc Weustink schreef:
Vincent Snijders wrote:
Hi,
TAsyncProcess from the LCL has a property NumBytesAvailable. Attached
patch adds it to TProcess in the FCL.
NumBytesAvailable checks how many bytes are available in
TProcess.Output, so you can decide not to read from it if there are
no bytes available.
What about StdErr output ?
Cant this be a property of the TInputPipeStream ?
Seems like an good idea. I will create a new patch.
Jonas Maebe schreef:
The FIONREAD constant is available in the termio units of both Darwin
and FreeBSD as of 2.0.4 (not for Open/NetBSD, but that's probably the
least of the things which need to be changed to get those platforms
going again).
Thanks for the hint. I guess this was not yet the case when
TAsyncProcess was written by Micha.
Attached is a new patch.
I didn't how to implement this for OS/2.
If the CreatePipes function was not implemented, I assume that poUsePipes cannot be
used. GetNumBytesAvailable returns 0 is such cases.
Vincent
Index: amiga/pipes.inc
===
--- amiga/pipes.inc (revision 6181)
+++ amiga/pipes.inc (working copy)
@@ -20,3 +20,11 @@
begin
Result := False;
end;
+
+
+Function TInputPipeStream.GetNumBytesAvailable: DWord;
+
+begin
+ Result := 0;
+end;
+
Index: beos/pipes.inc
===
--- beos/pipes.inc (revision 6181)
+++ beos/pipes.inc (working copy)
@@ -13,10 +13,18 @@
**}
-// No pipes under dos, sorry...
+// No pipes under beos, sorry...
Function CreatePipeHandles (Var Inhandle,OutHandle : Longint) : Boolean;
begin
Result := False;
end;
+
+
+Function TInputPipeStream.GetNumBytesAvailable: DWord;
+
+begin
+ Result := 0;
+end;
+
Index: go32v2/pipes.inc
===
--- go32v2/pipes.inc(revision 6181)
+++ go32v2/pipes.inc(working copy)
@@ -20,3 +20,11 @@
begin
Result := False;
end;
+
+
+Function TInputPipeStream.GetNumBytesAvailable: DWord;
+
+begin
+ Result := 0;
+end;
+
Index: inc/pipes.pp
===
--- inc/pipes.pp(revision 6181)
+++ inc/pipes.pp(working copy)
@@ -28,13 +28,17 @@
EPipeSeek = Class (EPipeError);
EPipeCreation = Class (EPipeError);
+ { TInputPipeStream }
+
TInputPipeStream = Class(THandleStream)
Private
FPos : Int64;
+ function GetNumBytesAvailable: DWord;
public
Function Write (Const Buffer; Count : Longint) :Longint; Override;
Function Seek (Offset : Longint;Origin : Word) : longint;override;
Function Read (Var Buffer; Count : Longint) : longint; Override;
+ property NumBytesAvailable: DWord read GetNumBytesAvailable;
end;
TOutputPipeStream = Class(THandleStream)
Index: morphos/pipes.inc
===
--- morphos/pipes.inc (revision 6181)
+++ morphos/pipes.inc (working copy)
@@ -20,3 +20,11 @@
begin
Result := False;
end;
+
+
+Function TInputPipeStream.GetNumBytesAvailable: DWord;
+
+begin
+ Result := 0;
+end;
+
Index: netware/pipes.inc
===
--- netware/pipes.inc (revision 6181)
+++ netware/pipes.inc (working copy)
@@ -13,6 +13,7 @@
**}
+// Unsupported for the moment...
Function CreatePipeHandles (Var Inhandle,OutHandle : THandle) : Boolean;
@@ -20,3 +21,10 @@
Result := false; {dont know how to do that with netware clib}
end;
+
+Function TInputPipeStream.GetNumBytesAvailable: DWord;
+
+begin
+ Result := 0;
+end;
+
Index: netwlibc/pipes.inc
===
--- netwlibc/pipes.inc (revision 6181)
+++ netwlibc/pipes.inc (working copy)
@@ -13,6 +13,7 @@
**}
+// Unsupported for the moment...
Function CreatePipeHandles (Var Inhandle,OutHandle : THandle) : Boolean;
@@ -20,3 +21,10 @@
Result := false; {todo}
end;
+
+Function TInputPipeStream.GetNumBytesAvailable: DWord;
+
+begin
+ Result := 0;
+end;
+
Index: os2/pipes.inc
===
--- os2/pipes.inc (revision 6181)
+++ os2/pipes.inc (working copy)
@@ -24,3 +24,11 @@
begin
CreatePipeHandles := DosCreatePipe (InHandle, OutHandle, PipeBufSize) = 0;
end;
+
+Function TInputPipeStream.GetNumBytesAvailable: DWord;
+
+begin
+ // TODO: find out if this is possible in OS/2
+ Result := 0;
+end;
+
Index: unix/pipes.inc
===
--- unix/pipes.inc (revision 6181)
+++ unix/pipes.inc (working copy)
@@ -14,8 +14,7
Re: [fpc-devel] How to build Win32 FPC compiler for linux-arm devices?
Daniël Mantione schreef: Op Mon, 29 Jan 2007, schreef Michael Schnell: For compiling for ARM a cross compiler is necessary anyway, Yes, but, the big difference is that the ARM cross compiler for Linux is an official FPC release and therefore useable without digging into the compiler build process. Simply download 2.0.4 for ARM and ready you are. There is one big thing I forgot totally forget about in my original e-mail: Francesco Lombardi did build and upload a Win32 - ARM Linux crosscompiler snapshot sime time ago: ftp://ftp.freepascal.org/pub/fpc/snapshot/v21/arm-linux What is the best way to let the compiler find the arm-linux shared libraries that it needs for linking? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to build Win32 FPC compiler for linux-arm devices?
Daniël Mantione schreef: Op Tue, 30 Jan 2007, schreef Vincent Snijders: Daniël Mantione schreef: Op Mon, 29 Jan 2007, schreef Michael Schnell: For compiling for ARM a cross compiler is necessary anyway, Yes, but, the big difference is that the ARM cross compiler for Linux is an official FPC release and therefore useable without digging into the compiler build process. Simply download 2.0.4 for ARM and ready you are. There is one big thing I forgot totally forget about in my original e-mail: Francesco Lombardi did build and upload a Win32 - ARM Linux crosscompiler snapshot sime time ago: ftp://ftp.freepascal.org/pub/fpc/snapshot/v21/arm-linux What is the best way to let the compiler find the arm-linux shared libraries that it needs for linking? Don't use shared libraries :) Seriously, I don't know, this totally depends on the exact ARM device. A Thecus like Florian uses will likely run a glibc system, but a more limited device like the GP2x will likely use an embedded libc, uclibc is very common on ARM devices. An uclibc distribution in a directory could be a good approac. For example in c:\fpc\2.1.1\lib\arm-linux ? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SymbianOS port
Felipe Monteiro de Carvalho schreef: Hi, I added an almost empty system.pp unit to fpc/rtl/symbian just to test, but the compiler isn´t yet search on this directory for the system unit. I am using this command to use FPC 2.0.4 to compile a cross-compiler: c:\Programas\fpc21 make clean all OS_TARGET=symbian OPT=-va Compilation will fail with: pp.pas(146,1) Fatal: Can't find unit System Fatal: Compilation aborted And using -va I can see it isn´t searching fpc21/rtl/symbian I would start with make cycle. cd c:\Programas\fpc21 make cycle OS_TARGET=symbian Then I get this error: D:/lazarus/source/fpc/2.1/compiler/ppcross386.exe -Tsymbian -XPi386-symbian- -Xc -Xr -Fui386 -Fusystems -Fu../rtl -Fii386 -FE. -FUi386/units/i386-symbian -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas pp.pas(146,1) Fatal: Can't find unit System -Fu../rtl doesn't seem correct. As soon as you have a ../rtl/units/symbian directory, that one will be correct. Another point, the rtl\symbian directory is still empty. But maybe you have more locally. Vincent Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SymbianOS port
Felipe Monteiro de Carvalho schreef: On 1/25/07, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: C:\Programas\fpc21\rtl\symbianmake clean FPC=c:\Programas\fpc21\compiler\ppc386 .exe make: Nothing to be done for `clean'. ops, it should be: C:\Programas\fpc21\rtl\symbianmake FPC=c:\Programas\fpc21\compiler\ppc386.exe make: Nothing to be done for `default'. That is right, no rtl units for Symbian have been written, so the Makefile doesn't contain them. Start with the system unit I would say. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SymbianOS port
Felipe Monteiro de Carvalho schreef: Hi, On 1/25/07, Florian Klaempfl [EMAIL PROTECTED] wrote: This is rather useless imo, even a cross cycle is far away for symbian. Something like make arm in the compiler dir and make FPC=c:\fpc\compiler\ppcarm -XP$FPCTARGET- in the rtl/symbian dir should be enough Actually I´m building for i386-symbian, which is the emulator. I tryed make i386 on the compiler directory, and next: C:\Programas\fpc21\rtl\symbianmake clean FPC=c:\Programas\fpc21\compiler\ppc386 .exe make: Nothing to be done for `clean'. Could you expain more about why my previous attempt (make clean all on fpc dir) was wrong? Not wrong, just overly complicated (or a too big step). The emulator for UIQ 3 uses normal win32 pe executables. I am trying to generate that using i386-symbian target. So you don't need a cross compiler, ppc386 can be used. You do need a symbian RTL. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SymbianOS port
Felipe Monteiro de Carvalho schreef: On 1/25/07, Vincent Snijders [EMAIL PROTECTED] wrote: That is right, no rtl units for Symbian have been written, so the Makefile doesn't contain them. Start with the system unit I would say. Yes, but I added my system unit, and used fpcmake to regenerate all makefiles on the rtl directory, also used it on the symbian directory, but it still doesn´t want to compile the symbian rtl ... also tryed to regenerate all makefiles on fpc directory. I used fpcmake -Tall, so I see it lists symbian as a target. But did you add your new system unit to the makefile in rtl\symbian? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The Lazarus Indy Package
[EMAIL PROTECTED] schreef: Burkhard Carstens ha scritto: Am Mittwoch, 24. Januar 2007 12:09 schrieb [EMAIL PROTECTED]: Points 1 to 3 went good, i get this error at point 4: C:\indy\fpcd:\ALVISE\Delphi-Lazarus\IDE\lazarus\fpc\2.1.1\bin\i386-w in32\make.e xe install d:/ALVISE/Delphi-Lazarus/IDE/lazarus/fpc/2.1.1/bin/i386-win32/fpcmake .exe -p -Ti 386-win32 Makefile.fpc Processing Makefile.fpc Error: Target win32, package rtl not found d:\ALVISE\Delphi-Lazarus\IDE\lazarus\fpc\2.1.1\bin\i386-win32\make.ex e: *** [fpc _install] Error 1 How do I set rtl (and other) paths? try setting the envvar FPCDIR to point to fpc sources. In linux, I do a export FPCDIR=/usr/local/share/src/fpc-2.1.1/fpc/ Hree this is only need when building a indy-rpm .. I tryed to set some environment variables under my computer - system - advanced - environment variables But make.exe seems to ignore them, is there any command to add them manually during compile? SET FPCDIR=c:\lazarus\fpc\2.1.1\source Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SymbianOS port
Felipe Monteiro de Carvalho schreef: Hi, I can´t seam to get fpcmake to work. I did a svn update, and changed the following on fpcmmain.pp: snip next I build fpcmake with fpc 2.0.4 and tryed to run it, but it crashes, and make command doesn´t seam to have included debug info. C:\Programas\fpc21fpcmake An unhandled exception occurred at $0040C63C : EAccessViolation : $0040C63C $0044DF0D $00454DD6 $00410C46 $00401F28 Any ideas? Try compiling with debug info: make OPT=-gl Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Wince hooks and ttimer support (for roozbeh and all fpc devs)
[EMAIL PROTECTED] schreef: 2) make the ttimer work on wince, so he can call the CallAction function that manages the connection sometime indipendently from the application. That would be a workaround (so useful for me) but not the definitive solution for lnet. TTimer does not work on WINCE ?!?!? If this is the case, you can't create anything but command-line tools that just block until their work is completely done. This is OK for pure FPC programs, but anything Lazarus-Like (using the LCL) will need such a thing. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel No... the LCL works and a lot of things can be currently done, but the TTimer component is not implemented due to differences between win32 and wince api(s). Reading this: http://www.rainer-keuchel.de/wince/wince-api-diffs.txt You can read: GetSystemTime() The milli member might be zero. This is strange as GetTickCount() returns millis (but since start of system). Time is absolutely irrelevant to Timer. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm-wince errors
Michael Schnell schreef: I have created a arm-wince cross compiler installer for lazarus-win32: ftp://ftp.hu.freepascal.org/pub/lazarus/cross/Lazarus-0.9.21-fpc-2.1.1-20070103-cross-arm-wince-win32.exe In what way is the arm-wince cross compiler related to the arm-Linux cross compiler (the one I some day would like to use) ? Are the differences just the libraries or is the compiler itself involved ? The compiler is the same, but the linker and assembler (which could be viewed as part of the compiler) are different. Also I noted that the arm-linux compiler doesn't use the binary writer, but ar. This makes the building of the units very slow (5-10 times as long). Of course the compiled units have a different format too. Let me know, if you want to try this out, then I can try to build an installer for cross-arm-linux. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm-wince errors
Michael Schnell schreef: I have created a arm-wince cross compiler installer for lazarus-win32: Nokao tried to use it, but he is getting errors: http://www.lazarus.freepascal.org/index.php?name=PNphpBB2file=viewtopict=3255 (using fpc from 30-12-2006) Hi Vincent, While I was positive that it should be possible / viable to do cross compiled Free Pascal projects for ARM targets in Linux (and wince), I am very astonished that someone tries to use Lazarus for that purpose. Is the goal to use the Lazarus LCL libraries and create a visual project on an ARM target ? Is it intended / likely that this is possible for wince (e.g. PDAs) and Linux (PDAs and embedded projects without display using remote X). As I mainly am interested in embedded stuff, I might like to get involved in that project, if the remote X feature can be supported. I am not sure if we understand each other completely, so let me write my (personal) view on these things. FPC is a great compiler, which also can target several OS-es on the arm processor (linux, wince, gba and lately nintendo ds). I want Lazarus to be the best developement evironment for FPC (and still a lot has to be done). The FPC compiler can cross compiler to these arm target, native compilation on the arm is technically possible, but not very well tested, because of the memory requirements needed and a PDA doesn't have a nice screen for editing ;-). You can use Lazarus to cross compile the application you have written in the Lazarus editor. For everything written about, nothing is said about the type of applications, whether GUI with the LCL, GUI without the LCL or console or no visible display at all. Lazarus is source editor (with highlighing, codetools and help) and fpc is the compiler. Now for at least arm-wince it is possible create LCL applications. For more details about that look at http://wiki.lazarus.freepascal.org/Windows_CE_Interface. I don't know the status of gtk1 on linux PDA, but if it works, then it may be possible to use LCL applications on linux PDA's too. Since I am primarily a windows user, I don't know what you mean by 'remote X feature' exactly. I am confident that the fpc compiler can be adapted for embedded arm-linux, Lazarus can be used to interface with the compiler to compile application for it. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm-wince errors
Michael Schnell schreef: I have created a arm-wince cross compiler installer for lazarus-win32: ftp://ftp.hu.freepascal.org/pub/lazarus/cross/Lazarus-0.9.21-fpc-2.1.1-20070103-cross-arm-wince-win32.exe In what way is the arm-wince cross compiler related to the arm-Linux cross compiler (the one I some day would like to use) ? It is similar to compile: ftp://ftp.hu.freepascal.org/pub/lazarus/cross/Lazarus-0.9.21-fpc-2.1.1-20070104-cross-arm-linux-win32.exe Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm-wince errors
Michael Schnell schreef: Let me know, if you want to try this out, then I can try to build an installer for cross-arm-linux. Vincent I suppose my favorite would be cross-compiling from PC-Linux top ARM-Linux. I don't do those. But follow the advice from Florian. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm-wince errors
Michael Schnell schreef: When doing cross projects remote debugging always comes into mind. Can Lazarus do remote debugging at all ? Is same possible / planned to be possible with ARM Linux targets ? See http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/docs/RemoteDebugging.txt?root=lazarusview=markup Note its date. So it might need to be updated or it might still work. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm-wince errors
Michael Schnell schreef: See http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/docs/RemoteDebugging.txt?root=lazarusview=markup Note its date. So it might need to be updated or it might still work. Step 5: Setup the ssh debugger in the IDE ToDo That does not help much ;-) I guess not much help is needed. Just open the Debugger Options and select GNU debugger through SSH (gdb), would be my first guess. Never done this though. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm-wince errors
Michael Schnell schreef: I guess not much help is needed. Just open the Debugger Options and select GNU debugger through SSH (gdb), would be my first guess. Never done this though. Great (sorry for my being cynical :-[ ) ! So I gather that you are convinced that it does work as well PC-PC as PC-ARM (Linux and windows). Convinced about the cross compiling, optimistic about remote debugging possibilities . I'm sure I'm going to test this once the project is started. Looking forward to the test results. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question about fpcmake
Joost van der Sluis schreef: Hi all, What does this output from fpcmake mean: cd lazarus fpcmake Processing Makefile.fpc Error: Target linux, package rtl not found This happens when I make a change in the Makefile.fpc of Lazarus, and then run fpcmake. It doesn't happen on my machine, but does on others. (FC buildsystem, for example) If I do a fpcmake -Tall, it also happens on my machine but then with the gov32 target. I'm not depe enough into fpcmake, what do I miss? I start with (on windows): set FPCDIR=c:\fpc\sourcedir fpcmake -Tall the source dir contains a svn chechout of http:/svn.freepascal.org/svn/fpc/trunk. HTH, Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] arm-wince errors
Hi, I have created a arm-wince cross compiler installer for lazarus-win32: ftp://ftp.hu.freepascal.org/pub/lazarus/cross/Lazarus-0.9.21-fpc-2.1.1-20070103-cross-arm-wince-win32.exe Nokao tried to use it, but he is getting errors: http://aycu23.webshots.com/image/7382/2004535844182527357_rs.jpg (using fpc r5797) and http://www.lazarus.freepascal.org/index.php?name=PNphpBB2file=viewtopict=3255 (using fpc from 30-12-2006) Is svn head useable for arm-wince? Or does it need further testing, because I can imagine the changes in revision 5714 are far reaching. Do I need to pass (or not pass) special command line parameters (I pass -CX -gl for compiling the fpc rtl and fcl units)?. What can be the cause for these crashes? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm-wince errors
Yury Sidorov schreef: From: Vincent Snijders [EMAIL PROTECTED] Hi, I have created a arm-wince cross compiler installer for lazarus-win32: ftp://ftp.hu.freepascal.org/pub/lazarus/cross/Lazarus-0.9.21-fpc-2.1.1-20070103-cross-arm-wince-win32.exe Nokao tried to use it, but he is getting errors: http://aycu23.webshots.com/image/7382/2004535844182527357_rs.jpg (using fpc r5797) and http://www.lazarus.freepascal.org/index.php?name=PNphpBB2file=viewtopict=3255 (using fpc from 30-12-2006) Is svn head useable for arm-wince? Or does it need further testing, because I can imagine the changes in revision 5714 are far reaching. Do I need to pass (or not pass) special command line parameters (I pass -CX -gl for compiling the fpc rtl and fcl units)?. What can be the cause for these crashes? Vincent, I downloaded your cross installer and found that you included wrong binutils. You included version 2.13.2.1, but supported version is 2.15.94. Get it here: ftp://ftp.freepascal.org/pub/fpc/contrib/cross/arm-wince-binutils.zip Yuri, thanks for looking into this problem. I simply didn't update them since the last time I compiled the wince interface for lazarus (early last year, IIRC). I will update the binutils and try to create a new version tonight or tomorrow. I think GDB for arm-wince should be included to cross installer: ftp://ftp.freepascal.org/pub/fpc/contrib/cross/gdb-6.4-win32-arm-wince.zip I will do this in the future. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Modified LGPL standard notice
Graeme Geldenhuys schreef: Well, look in the file that it standard header points to. There it mentions what is different to the standard LGPL. But yes I agree that one should insert that notice as part of Lazarus IDE menu options. It will be a small change. If it's not done after Christmas, I'll implement it next week. (I'm away for the weekend) I have no problem implementing it, I just want to know what the value should be of the lisModifiedLGPLNotice constant (i.e. what text should be inserted). Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] generics
Michael Schnell schreef: No. Generics are more like using a macro when defining a type. So a := copies the memory and not a pointer and they are passed by value into a procedure. I think you cut too much context. To which question does this give an answer? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] generics
Will fpc support generic record declarations like this: type generic TFixedKeyNodeKeySize = record key: array[0..KeySize-1] of char; value: dword; end; In other word the type is not parameterized by another type but by an integer used to define the upper limit of an array. I am thinking of trying to use generics to implement the hashtable with fixed size keys for the k-nucleotide benchmark: http://shootout.alioth.debian.org/gp4/benchmark.php?test=knucleotidelang=all Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] generics
Daniël Mantione schreef: Op Wed, 20 Dec 2006, schreef Vincent Snijders: Will fpc support generic record declarations like this: type generic TFixedKeyNodeKeySize = record key: array[0..KeySize-1] of char; value: dword; end; In other word the type is not parameterized by another type but by an integer used to define the upper limit of an array. Basically, isn't this similar to a schema type like you have in Extended Pascal? No idea. I have absolutely no knowledge about Extended Pascal. Can you give a link which describes that? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Classes unit based on fgl
Hi, Since this weekend the classes unit is based upon the fgl unit. What are the advantages of this change. Does it make the code in the classes unit (for example TFPList, TList and TStringList) faster or does this just improve maintainability, e.g. because changes made in the fgl unit are automatically propagated to the lists in classes unit? Is there any time frame on a bug fix for http://www.freepascal.org/mantis/view.php?id=7910. This prevents compiling Lazarus with fpc 2.1.1. With this FGL change and the changes of last night in the resource strings, there are already two possible places for regressions. This might make things difficult when 7910 is finally fixed and I can compile Lazarus again, but not run it because of a bug in any of these (or other) things that have changed since last successful build. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposed change in simpleipc
Kris Leech schreef: Luiz Americo Pereira Camara wrote: While developing with simpleipc i found that there's no straightforward way to identify the type of a message (see the forth paragraph of http://lazarusroad.blogspot.com/2006/12/only-one-instance.html), so i looked what i could do to improve it. Look forward to reading more, anyone else have a laz/fpc blog? A couple of days ago, I gathered some links on http://wiki.lazarus.freepascal.org/Lazarus_Documentation#Lazarus_related_blogs Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] help with softfloat for arm big endian crosscompiler
[EMAIL PROTECTED] schreef: finally some of us would quite like to have a big endian system arround for testing on and as big endian systems go the slug is cheap! Well, for FPC developers (as well as others) I make accounts available to those interested via SSH. I run PPC under Debian/Sparc on a Sun Ultra 5. I might be interested for creating Lazarus and fpc snapshots (see http://wiki.lazarus.freepascal.org/Lazarus_Snapshots_Downloads), if there is actual demand for such snapshots. No need in creating files and maintaining build scripts, if nobody downloads them. How people are using or testing fpc on sparc-linux? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess change.
Vincent Snijders schreef: Michael Van Canneyt schreef: Hello, The documentation has been adapted, but is not yet published. I regenerated the docs and noticed that TProcess.WaitOnExit.Result has not been updated: http://lazarus-ccr.sourceforge.net/docs/fcl/process/tprocess.waitonexit.html As a reminder: http://www.freepascal.org/mantis/view.php?id=7968 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess change.
Michael Van Canneyt schreef: Hello, I've changed the TProcess.WaitOnExit return type to boolean; A return value of True means success, a return value of False means failure. This is a conscious break with the old DWord return value, which returned a highly inconsistent, system-dependent return value. The current solution is consistently cross-platform. I regret if this breaks any code, but you can make the code consistent with older code if you do a MyRes:=Ord(WaitOnExit); This should compile with old and new versions of FPC. (The old return value was useless anyway) The documentation has been adapted, but is not yet published. I regenerated the docs and noticed that TProcess.WaitOnExit.Result has not been updated: http://lazarus-ccr.sourceforge.net/docs/fcl/process/tprocess.waitonexit.html Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Streaming readonly properties
Michael Van Canneyt schreef: On Wed, 13 Dec 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Tue, 12 Dec 2006, [EMAIL PROTECTED] wrote: As said in an earlier mail I have problems streaming the property EditLabel: TBoundLabel read FEditLabel; of a TLabeledEdit with fpc 2.1.1. Some discussion on #fpc led to the conclusion that streaming a readonly persistant should be allowed, because you write to the properties of the readonly persistant property. Attached is a proposal to fix it. Delphi does not stream readonly properties. So we won't either. The proper solution for this is support for csSubComponent in TComponent. Can you elaborate a bit, what you mean by that? What should be changed and where? Delphi has a ComponentState csSubComponent. This flag should be set if you publish a property of type TComponent, and the TComponent instance is 'owned' by the object that publishes it, i.e. it's NOT a reference to an other existing TComponent. The owned TComponent has 'csSubComponent' in it's componentstyle. This tells delphi to stream the component's properties as part of it's owning component, and not just a reference to it. The IDE will need support for this, as well TComponent and the streaming system. (The latter part is probably the easy part ;) ) So far so good. The IDE supports this (no drop downbox in the IO, but you can expand to set the owned component's properties). The owned component has the csSubComponent in its component style: Include(FEditLabel.ComponentStyle, csSubComponent); Include(FEditLabel.ControlStyle, csNoDesignSelectable); So where should the streaming occur? Should I amend to patch to allow streaming properties of readonly subcomponents? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Streaming readonly properties
Michael Van Canneyt schreef: On Wed, 13 Dec 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Wed, 13 Dec 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Tue, 12 Dec 2006, [EMAIL PROTECTED] wrote: As said in an earlier mail I have problems streaming the property EditLabel: TBoundLabel read FEditLabel; of a TLabeledEdit with fpc 2.1.1. Some discussion on #fpc led to the conclusion that streaming a readonly persistant should be allowed, because you write to the properties of the readonly persistant property. Attached is a proposal to fix it. Delphi does not stream readonly properties. So we won't either. The proper solution for this is support for csSubComponent in TComponent. Can you elaborate a bit, what you mean by that? What should be changed and where? Delphi has a ComponentState csSubComponent. This flag should be set if you publish a property of type TComponent, and the TComponent instance is 'owned' by the object that publishes it, i.e. it's NOT a reference to an other existing TComponent. The owned TComponent has 'csSubComponent' in it's componentstyle. This tells delphi to stream the component's properties as part of it's owning component, and not just a reference to it. The IDE will need support for this, as well TComponent and the streaming system. (The latter part is probably the easy part ;) ) So far so good. The IDE supports this (no drop downbox in the IO, but you can expand to set the owned component's properties). The owned component has the csSubComponent in its component style: Include(FEditLabel.ComponentStyle, csSubComponent); Include(FEditLabel.ControlStyle, csNoDesignSelectable); So where should the streaming occur? When EditLabel is encountered ? I am not sure I understand your question. EditLabel is a published property of TLabeledEdit. Should I amend to patch to allow streaming properties of readonly subcomponents? Yes, please do. It should be quite like the check you made before... I will try. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Streaming readonly properties
Martin Schreiber schreef: On Tuesday 12 December 2006 14.54, [EMAIL PROTECTED] wrote: As said in an earlier mail I have problems streaming the property EditLabel: TBoundLabel read FEditLabel; of a TLabeledEdit with fpc 2.1.1. A usual solution: ttestcomp = class(tcomponent) private fsubcomponent: ttestsubcomponent; procedure setsubcomponent(const avalue: ttestsubcomponent); //... published property subcomponent: ttestsubcomponent read fsubcomponent write setsubcomponent; end; implementation procedure ttestcomp.setsubcomponent(const avalue: ttestsubcomponent); begin fsubcomponent.assign(avalue); end; The problem with this solution, is the write setsubcomponent; part of the declaration. I don't want the users of the LabeledEdit component can change the Label subcomponent. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TProcess.ExitStatus
The docs at http://lazarus-ccr.sourceforge.net/docs/fcl/process/tprocess.exitstatus.html say: The value of this property is only meaningful when the process is no longer running. If it is not running then the value is zero. I think not in the last sentence must be removed. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] streaming readonly properties
Aleš Katona schreef: Hi, I recently changed TReader and TWriter to be delphi compatible (they were missing a virtual read and a virtual write. It might be related, best idea is to see if all TWriter/TReader descendants which add read and write have them use override. As for the concrete problem.. not sure if it's truly related or not bug I guess RTTI did change. No, your changes are made after the bug report, so they are not the cause of the bug, at most the cause the problem I see now, but not likely. PS: I did fix TDelphiReader and TDelphiWriter to override but didn't find any other direct descendants in RTL/FCL/LCL by grep (I admit it's not the way to search for them). The TLRSObjectReader inherits from TAbstractObjectReader and has a procedure Read(var Buf; Count: LongInt); Would that be affected by your patch? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Growing a memory stream
Hi, Currently the TMemoryStream grows in steps of 4096 bytes. When writing 10 chunks of say 80 bytes to it, this causes a lot of reallocations. I think it is better to grow at least a quarter for example. The new code could look something like: function TMemoryStream.Realloc(var NewCapacity: Longint): Pointer; begin // round off to block size. If NewCapacity0 Then NewCapacity:=0 else begin if NewCapacity - Capacity Capacity div 4 then NewCapacity := Capacity + Capacity div 4; NewCapacity := (NewCapacity + (TMSGrow-1)) and not (TMSGROW-1); end; // Only now check ! If NewCapacity=FCapacity then Result:=FMemory else begin Result:=Reallocmem(FMemory,Newcapacity); If (Result=Nil) and (Newcapacity0) then Raise EStreamError.Create(SMemoryStreamError); end; end; What do you think? For background see: http://www.freepascal.org/mantis/view.php?id=7270 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Growing a memory stream
Micha Nelissen schreef: Vincent Snijders wrote: Hi, Currently the TMemoryStream grows in steps of 4096 bytes. Very nice would be a linked list of 8KB blocks or so, and when you access .Memory, then it's copied into an array. A (maybe shortsighted) drawback would be that it doubles the amount of needed memory, once for the list and once for the memory pointed to with Memory? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Growing a memory stream
Micha Nelissen schreef: Vincent Snijders wrote: A (maybe shortsighted) drawback would be that it doubles the amount of needed memory, once for the list and once for the memory pointed to with Memory? Well, the linked list would be freed (or the first item of it enlarged to the total size, depending on implementation details). Still, the peak memory use will twice the size, won't it? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Growing a memory stream
peter green schreef: Well, the linked list would be freed (or the first item of it enlarged to the total size, depending on implementation details). Still, the peak memory use will twice the size, won't it? sure but unless you are very lucky a call to reallocmem also means alocate-copy-deallocate. That is why I said shortsighted in my initial question :-) Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] new fields in OpenFileName
Hi, Attached patch adds new fields (since _WIN32_WINNT = 0x0500) to the OPENFILENAME struct. Vincent Index: struct.inc === --- struct.inc (revision 5549) +++ struct.inc (working copy) @@ -4852,6 +4852,9 @@ lCustData : LPARAM; lpfnHook : LPOFNHOOKPROC; lpTemplateName : LPCTSTR; + pvReserved: pointer; + dwReserved: DWORD; + FlagsEx: DWORD; end; LPOPENFILENAME = ^OPENFILENAME; TOPENFILENAME = OPENFILENAME; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] new fields in OpenFileName
Micha Nelissen schreef: Vincent Snijders wrote: Hi, Attached patch adds new fields (since _WIN32_WINNT = 0x0500) to the OPENFILENAME struct. This will make programs that use sizeof(OPENFILENAME) incompatible with older windows versions. (Like we already experienced with lazarus). We will see that. I already added the updated structure to the lazarus winext unit. I need to pass the big structure on version =0x0500 for multiselectdialogs with a places bar. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] - fpcUnit XSLT
Graeme Geldenhuys schreef: Hi, Attached is a new patch for the XSTL example in fpcUnit. This time the JavaScript in inside the fpcunit.xsl file and not as a separate file. I actually like this more as well. Michael, is this patch already applied? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] - fpcUnit XSLT
Graeme Geldenhuys schreef: Hi, Attached is a patch for the fpcUnit's example XSLT files. Changes: * Grouping by Test Suites is now supported in the generated HTML * Cleaned up the fpcunit.css file * Added a navi.js file, which is the JavaScript required for the grouping. (Depending on others, this could be moved into the fpcunit.xsl file if preferred). I am using fpcunit to check if all the snapshots are up to date: http://www.hu.freepascal.org/lazarus/testresults/monitor.xml I see a couple of improvements: * Add Tests, Failures, Errors, Elapsed time for testsuites too (needs a change in the xmlreporter). * Color code the test suite line (green, ok, red failures). * Allow test suites in other testsuites. As I wrote the tests the Snapshot on scenergy test suites contains most of the following test suites. So they should be hidden in it, and if I click on the scenergy snapshot, they should become visible, just like the individual test do. * Show the failure or error message as extra information of the test, so clicking on the test would show it. What do you think of these improvements? Which ones are you willing to implement? If you don't do them all (in time), I will do the remaining ones. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Efficient way to inc loop over hexadecimal values
ik schreef:
On 11/22/06, Dominique Leducq [EMAIL PROTECTED] wrote:
ik a écrit :
Hi List,
I have two cardinal numbers that represent ranges.
The 10 base value of that two variables are useless and far from
having any meaning for my needs.However the hexa number does have
meaning after I'm changing the network order (aka big endian).
I can think on many non efficient ways to while loop with inc but not
even one way to inc it in an efficient way.
So, I'm looking for an efficient way to loop from left range to right
range when the values are in Hexa-decimal.
Thank you for any help on this matter,
Ido
I'm afraid I don't understand your problem. Decimal or hexadecimal are
string representation formats, cardinal and integer values are stored
and dealt with internally in binary form !
If your values are hexadecimal number stored in strings, why not convert
them first to Cardinal ?
Could you perhaps give an example or be more precise ?
OK, I have (for this example, taken from my own testing) the following
numbers:
Decima numbers: a = 3616538624 b = 3616669696
The hexa values are: a = D790 b = D792
As you can see the range differences between the decimals are way
bigger then the hexa values.
The numerical difference is the same. The difference seems larger if you are
speaking about the string represetations of these 32 bits numbers
('3616538624','3616669696') and ('D790','D792 ')
The thing is that the hexa numbers represent chars of a UTF-8
encoding. D790 is the char א.
(http://www.utf8-chartable.de/unicode-utf8-table.pl look for Hebrew).
So I wish to run on the range between a..b (in Hexa) and to have all
of the values in between.
There are many bad ways to do it such as:
while (not hexStr (i) = b) do
begin
...
inc (i)
end;
This exampel does not cover all the possible values I might need.
Why not?
So, I'm looking for a much faster and smarter way to do it, rather the
bad way above.
Do you want to operate on strings or on numbers or on somthing else?
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Request info on static single use
Jonas Maebe schreef: On 8 nov 2006, at 17:46, Micha Nelissen wrote: Is SSU easier to implement than SSA ? No, it's a bit more work. Aren't variables often more used than assigned (so more generated variables by SSU) ? Yes. How do the achieved optimizations compare ? SSU gives somewhat better results on register-starved architectures. The change from SSA to SSU didn't make any difference for PPC for the compiler+rtl (it can give a difference for large procedures with a lot of variables which are used in different phases of course). It saves about 5kb on the compiler on Linux/i386 compared to SSA-only. Will you be working on SSA and/or SSU with control blocks (e.g. using SSA in procedures where a for loop is used) before 2.2? Or will that be released only in a later version. A synthetic example that will benefit is the CalculatePoint procedure of http://svn.freepascal.org/svn/fpc/trunk/tests/bench/shootout/src/mandelbrot.pp Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] win64 compilation failed
Hi, win64 compilation failed: c:/lazarus/source/bin/ppcx64.exe -Ur -Xs -O2 -n -Fux86_64 -Fusystems -FuC:/lazarus/source/fpcbuild/2.1/fpcsrc/rtl/units/x86_64-win64 -Fix86_64 -FE. -FUx86_64/units/x86_64-win64 -dRELEASE -dx86_64 -dGDB -dBROWSERLOG -Fux86 pp.pas symsym.pas(519,43) Error: Illegal type conversion: tderef to Int64 symsym.pas(540,29) Error: Illegal type conversion: Int64 to tderef symsym.pas(607,47) Error: Illegal type conversion: tderef to Int64 symsym.pas(2091) Fatal: There were 3 errors compiling module, stopping Fatal: Compilation aborted make.exe[4]: *** [ppcx64.exe] Error 1 Do I need to create a newer starting compiler? Or is this just a 64 bit issue? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] EXC_BAD_ACCESS on i386-darwin
Hi, I am looking at http://www.freepascal.org/mantis/view.php?id=7723 When the exception is risen the following error is given: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x004f 0x0019409e in GTKAPIWIDGETCLIENT_DRAWCARET (CLIENT=0x4d38e00, CALLEDBYTIMER=false) at gtkwinapiwindow.pp:730 730 gtkwinapiwindow.pp: No such file or directory. in gtkwinapiwindow.pp What kind of exception is this? Line 730 contains: if Visible and Blinking and (Timer = 0) The same variables are used earlier in the procedure, so I don't think the pointer to the complete record is wrong (e.g. nil). The variables accessed are fields in a TCaretInfo record acessed within a with block TCaretInfo = record X: Integer; Y: Integer; Width: Integer; Height: Integer; Visible: Boolean; // Caret is on IsDrawn: Boolean; // Caret is visible at the moment Blinking: Boolean; // Caret should blink Pixmap: PGDKPixMap; BackPixmap: PGDKPixMap; Timer: guint; ShowHideOnFocus: boolean; // true = hide on loose focus, show on get focus end; Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] EXC_BAD_ACCESS on i386-darwin
Jonas Maebe schreef: On 02 Nov 2006, at 14:37, Vincent Snijders wrote: I am looking at http://www.freepascal.org/mantis/view.php?id=7723 Can you move that issue to FPC? It's an SSU bug (for which I'm currently testing the fix). Sure, any bug you wish. :-) Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] EXC_BAD_ACCESS on i386-darwin
Jonas Maebe schreef: On 02 Nov 2006, at 14:37, Vincent Snijders wrote: I am looking at http://www.freepascal.org/mantis/view.php?id=7723 Can you move that issue to FPC? It's an SSU bug (for which I'm currently testing the fix). Thanks: http://www.freepascal.org/cgi-bin/viewcvs.cgi?rev=5182view=rev Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] EXC_BAD_ACCESS on i386-darwin
Jonas Maebe schreef: On 02 Nov 2006, at 14:37, Vincent Snijders wrote: I am looking at http://www.freepascal.org/mantis/view.php?id=7723 Can you move that issue to FPC? It's an SSU bug (for which I'm currently testing the fix). Thanks with the correct link: http://www.lazarus.freepascal.org/index.php?name=PNphpBB2file=viewtopicp=14028#14028 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch for fixing CE compilation
Marc Weustink schreef: Oro06 wrote: Marc Weustink wrote: Hi, hi, This patch fixes CE compilation. I would have applied it myself, but I've some questions about the common win dir and the wince implementation in the rtl. you can apply it Done, r5135 Currently fpc 2.1.1 is broken on windows. Maybe it has to do something with this change? c:/lazarus/source/fpcbuild/2.1/fpcsrc/compiler/ppc386.exe -Ur -Xs -O2 -n -FuC:/lazarus/source/fpcbuild/2.1/fpcsrc/rtl/units/i386-win32 -FE. -FUunits/i386-win32 -g -gl -Ur -CX -di386 -dRELEASE buildjwa.pp jwawintype.pas(164,45) Error: Identifier not found WCHAR jwawintype.pas(164,76) Error: Error in type definition jwawintype.pas(169,17) Error: Type WCHAR is not completely defined jwawintype.pas(171,16) Error: Type WCHAR is not completely defined jwawintype.pas(173,18) Error: Type WCHAR is not completely defined jwawintype.pas(175,17) Error: Type WCHAR is not completely defined jwawintype.pas(177,18) Error: Type WCHAR is not completely defined jwawintype.pas(734,18) Error: Illegal type conversion: ShortInt to erroneous type jwawintype.pas(734,26) Error: Illegal expression jwawintype.pas(1663,1) Fatal: There were 9 errors compiling module, stopping Fatal: Compilation aborted Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Daily Lazarus Win64 snapshots
Rod schreef: Would like to see daily Lazarus Win64 snapshots on http://www.hu.freepascal.org/lazarus/ Your wish has been granted. Please read on for the disclaimer ;-) Known issues: - No debugger support. There is no gdb for win64 and the win32 gdb cannot debug win64 applications. Marc is working on windows debugger (that supports win64) written with pascal. - Using a SelectDirectoryDialog crash the application. This happens in lazarus too, for example when specifying the fpc source directory or the find in files directory. If anybody finds out what is wrong with the current code, please tell. Workaround: type the path in the edit box. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tail recursion optimization
Florian Klaempfl schreef:
Daniël Mantione wrote:
Op Tue, 10 Oct 2006, schreef Florian Klaempfl:
Yesterday, I've implemented tail recursion optimization
(http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas resulting in
http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=158 pp11 is the new
compiler, fpc11 the old, both are 2.1.1).
Wow!
Well, it's use for real world applications is limited but for the typical
recursive useless benchmark stuff it's nice to have and it wasn't much work.
I tried this with the recursive benchmark:
http://svn.freepascal.org/svn/fpc/trunk/tests/bench/shootout/src/recursive.pp
Using fpc
2.0.4: 9.1 s
2.1.1: 8.1 s
with {$OPTIMIZATION tailrec}: 6.0 s.
gcc is 2.6 times faster than fpc 2.0.4 (see
http://shootout.alioth.debian.org/gp4/benchmark.php?test=recursivelang=all)
so it would do 3.5 seconds about this benchmark.
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tail recursion optimization
Florian Klaempfl schreef: Vincent Snijders wrote: I tried this with the recursive benchmark: http://svn.freepascal.org/svn/fpc/trunk/tests/bench/shootout/src/recursive.pp How much does leaving fwait away help? There is a small, but measurable difference: fpc 2.0.4: 9.04 fpc 2.0.4 without fwait: 8.96 So, there is some speedup, but not spectacular. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] using sse2 packed doubles
Florian Klaempfl wrote: Vincent Snijders schrieb: Daniël Mantione wrote: Op Fri, 6 Oct 2006, schreef Micha Nelissen: Vincent Snijders wrote: You could also start an assembler implementation of the matrix unit. I suppose using it is allowed, and a Tvector2_double looks a lot like such a double2. Unless the compiler somehow helps, inlining the assembler implementation won't work and then the speedup might be lost again. I started to add vector pascal like support, currently only i386/x86_64 are supported (no generic support). The whole (currently implemented) functionality is demonstrated by the following example. Please give some feedback if it allows benchmark speedups. Thanks Florian, for starting the vector support. I think this would help speedup in benchmarks. I cannot give real estimates how much, maybe 20 % or so. There are some problems still some bugs (or things not implemented). Given the following program: var ad1,ad2,ad3 : array[0..1] of double; begin ad2[0] := 1; ad2[1] := 3; ad3[0] := 9; ad2[1] := 12; ad1:=ad2+ad3; writeln(ad1[1]); end. It writes: 0.000E+000 Looking at the assembler, I see the ad1 in the writeln is read from memory, but the ad1 is still only in the xmm0% register. Further I encountered problems with the alignment. Vincent Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] using sse2 packed doubles
Daniël Mantione wrote: Op Sat, 7 Oct 2006, schreef Florian Klaempfl: Vincent Snijders schrieb: I started to add vector pascal like support, currently only i386/x86_64 are supported (no generic support). The whole (currently implemented) functionality is demonstrated by the following example. Please give some feedback if it allows benchmark speedups. To get a large speedup, I think you should instead of making pairs of doubles, do the pixels in parallel. I.e. in this benchmark, a row is 3000 pixels wide, so, make an array of 3000 doubles, and do the operation with arrays. With proper compiler optimization, it should be possible to achieve speeds close to 2 flops a clock cycle. The 'problem' in this benchmark is that the number of iterations of the inner loop isn't fixed, but can vary between 1 and 50. If you pair two doubles, the change you can break the loop for all elements of the vector before iteration 50 is bigger than when you combine 3000 elements. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] using sse2 packed doubles
Daniël Mantione wrote: Op Sun, 8 Oct 2006, schreef Vincent Snijders: Daniël Mantione wrote: Op Sat, 7 Oct 2006, schreef Florian Klaempfl: Vincent Snijders schrieb: I started to add vector pascal like support, currently only i386/x86_64 are supported (no generic support). The whole (currently implemented) functionality is demonstrated by the following example. Please give some feedback if it allows benchmark speedups. To get a large speedup, I think you should instead of making pairs of doubles, do the pixels in parallel. I.e. in this benchmark, a row is 3000 pixels wide, so, make an array of 3000 doubles, and do the operation with arrays. With proper compiler optimization, it should be possible to achieve speeds close to 2 flops a clock cycle. The 'problem' in this benchmark is that the number of iterations of the inner loop isn't fixed, but can vary between 1 and 50. If you pair two doubles, the change you can break the loop for all elements of the vector before iteration 50 is bigger than when you combine 3000 elements. You are right. How about doing it in blocks of 8x8 pixels? The high iteration loops are concentrated close to the borders of the set, so for most blocks the iteration can then be ended early. For starters I was thinking about blocks of 1x2 pixels ;-). The current hardware doesn't allow any more parallelism anyway. Or am I making a mistake in my thinking now? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] using sse2 packed doubles
Daniël Mantione wrote: Op Fri, 6 Oct 2006, schreef Micha Nelissen: Vincent Snijders wrote: You could also start an assembler implementation of the matrix unit. I suppose using it is allowed, and a Tvector2_double looks a lot like such a double2. Unless the compiler somehow helps, inlining the assembler implementation won't work and then the speedup might be lost again. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] using sse2 packed doubles
Hi,
I wondered if it is possible to add support for using sse2 packed doubles in
fpc.
I tried to create a sse2doubles type and define a operator + on it. Eventually I
want to move this type and all operators on it to a separate sse2 unit, so that the
user of this type doesn't need to see the assembler. The following program works,
but not as efficiently as I had hoped, because the operator is not inlined, probably
because of the assembler code.
Is it possible to create this purely in RTL /units or is compiler support needed?
Does it make sense to create a 'feature request'bug tracker item for this? Compiler
hacking is out of my league.
program optsse2;
{$mode objfpc}{$H+}{$ASMMODE ATT}
{$FPUTYPE SSE2}
type
sse2doubles = record
d1, d2: double;
end;
operator + (d1, d2: sse2doubles) : sse2doubles; assembler; inline;
{begin
result.d1 := d1.d1 + d2.d1;
result.d2 := d1.d2 + d2.d2;
end;}
asm
movupd (%eax), %xmm0
addpd (%edx), %xmm0
movupd %xmm0, (%ecx)
end;
procedure test;
var
sd1, sd2, sd3: sse2doubles;
begin
sd1.d1 := 1;
sd1.d2 := 2;
sd2.d1 := 3;
sd2.d2 := 4;
sd3 := sd1 + sd2;
writeln(sd3.d1);
writeln(sd3.d2);
end;
begin
test;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sse2 registers
Vincent Snijders schreef: I am trying out the sse2 support in fpc 2.1.1 and compile my code with -Cfsse2. The program is the mandelbrot benchmark: http://shootout.alioth.debian.org/gp4/benchmark.php?test=mandelbrotlang=fpascal The innerloop is like this: Zr := 0; Zi := 0; Tr := 0; Ti := 0; i := 0; while (i50) and (Tr + Ti limit) do begin inc(i); Zi := 2*Zr*Zi + Ci; Zr := Tr - Ti + Cr; Ti := Zi * Zi; Tr := Zr * Zr; end; If I look at the generated assembler, I noticed that only %xmm0 is used and all each time the variable needs to be retrieved from the stack. # Var Zr located in register mreg0md # Var Zi located in register mreg0md # Var Ti located in register mreg0md # Var Tr located in register mreg0md # Var Cr located in register mreg0md # Var Ci located in register mreg0md ... # [33] Zr := Tr - Ti + Cr; movsd-88(%ebp),%xmm0 subsd-80(%ebp),%xmm0 addsd-96(%ebp),%xmm0 movsd%xmm0,-112(%ebp) # [34] Ti := Zi * Zi; movsd-72(%ebp),%xmm0 mulsd-72(%ebp),%xmm0 movsd%xmm0,-80(%ebp) I thought there were more than one xmm registers. Why aren't they used? They are not used, because the same body contains a procedure call and the %xmm0 registers are volatile. See also the notes with issue 7533: http://www.freepascal.org/mantis/view.php?id=7533 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sse2 registers
Daniël Mantione schreef: Op Fri, 6 Oct 2006, schreef Vincent Snijders: They are not used, because the same body contains a procedure call and the %xmm0 registers are volatile. See also the notes with issue 7533: http://www.freepascal.org/mantis/view.php?id=7533 This is solveable with SSA, so a variable can be in a register in one part of the procedure and in memory in another part of the procedure. It should be a matter of being patient. Yes, that is the reason, why the issue is still open after the explanation. Do you have an idea if SSA with program control structures is a planned for 2.2.0 or later(2.4.0)? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] using sse2 packed doubles
Florian Klaempfl wrote: Vincent Snijders schrieb: Hi, I wondered if it is possible to add support for using sse2 packed doubles in fpc. I tried to create a sse2doubles type and define a operator + on it. Eventually I want to move this type and all operators on it to a separate sse2 unit, so that the user of this type doesn't need to see the assembler. The following program works, but not as efficiently as I had hoped, because the operator is not inlined, probably because of the assembler code. Indeed. Is it possible to create this purely in RTL /units No. or is compiler support needed? Yes. Does it make sense to create a 'feature request'bug tracker item for this? Compiler hacking is out of my league. Do you think it's allowed to use in the benchmarks? Yes, as long as it is part of the RTL. Look at http://shootout.alioth.debian.org/gp4/benchmark.php?test=mandelbrotlang=gccid=3 Using asm block would probably not allowed of course, but making use of sse2 support offered by the compiler and rtl is allowed. So if fpc hypothetically would support a type double2 = array[0..1] of double and operators like + - * on it would use the packed double instructions of sse2, then it could be used in the shoutout benchmarks. After all the following program looks perfectly normal pascal. var a, b, c, d: double2; begin d := a + b *c; end. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Typed addresses by default
Micha Nelissen wrote: Ivo Steinmann wrote: Well, it's a good idea to enable typed addresses by default, but I have got one problem with that. The pointer to an array of a type should be allowed to assign to the pointer of the same type. Example T: array[-10..10] of Integer; P: PInteger; I request that P := @T; should be allowed, because a pointer type in objfpc mode are also treated as pointer to an array of that type, that means P[...] is allways allowed also. Just a note, there will be 3 ways to write the same thing then: P := T; This only compiles without errors if Low(T)=0. P := @T; P := @T[Low(T)]; A bit odd, no ? Although in all cases it's quite clear what is meant, but I don't know if this scales to more complex expressions ? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Typed addresses by default
Jonas Maebe wrote: On 5 okt 2006, at 15:41, Jonas Maebe wrote: Or that the code in the typeinfo unit is now broken. typinfo unit is fixed. Thanks. Lazarus starts again. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Next patch for XML stuff
Sergei Gorelkin schreef: Hello, Here is the next portion of my patches to XML stuff: dom.pp: - Removed unneeded TDOMNode.FNodeName/FNodeValue fields to reduce memory requirements; - finished TDOMElement.GetElementsByTagName; - Implemented TDOMNode.TextContent property; - Implemented attribute value normalization; - Fixed TDOMNode.Normalize and TDOMNode.InsertBefore for fragments. names.inc: - rewritten in cross-platform way, added XML 1.1 data; xmlwrite.pp: - Added support for Unicode characters with code 65535; - Added writing TDOMDocumentType nodes; - Fixed handling of end-of-lines contained in node content; - Code cleaned up, so this unit is almost complete :) xmlread.pp: - At this moment, it contains only fixes needed for the whole stuff to compile. Actually I have almost developed a thing that can be called non-validating parser - capable of handling XML 1.1 and including external entities. I achieved 100% conformance with W3.org test suite. However, I feel that it's too early to release it because it does not fit into existing interface and has possibly undesired dependencies - but I'd better write a separate letter to discuss it. As far as I can see, this patch has not yet been applied. I have it locally for a month now, but didn't notice any problems. I did not specifically test it though. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Next patch for XML stuff
Sergei Gorelkin schreef: Hello, Here is the next portion of my patches to XML stuff: dom.pp: - Removed unneeded TDOMNode.FNodeName/FNodeValue fields to reduce memory requirements; - finished TDOMElement.GetElementsByTagName; - Implemented TDOMNode.TextContent property; - Implemented attribute value normalization; - Fixed TDOMNode.Normalize and TDOMNode.InsertBefore for fragments. names.inc: - rewritten in cross-platform way, added XML 1.1 data; xmlwrite.pp: - Added support for Unicode characters with code 65535; - Added writing TDOMDocumentType nodes; - Fixed handling of end-of-lines contained in node content; - Code cleaned up, so this unit is almost complete :) xmlread.pp: - At this moment, it contains only fixes needed for the whole stuff to compile. Actually I have almost developed a thing that can be called non-validating parser - capable of handling XML 1.1 and including external entities. I achieved 100% conformance with W3.org test suite. However, I feel that it's too early to release it because it does not fit into existing interface and has possibly undesired dependencies - but I'd better write a separate letter to discuss it. Thanks. Applied in revision 4775. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TLCLMemanager
Mattias Gaertner schreef: On Fri, 29 Sep 2006 16:32:23 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Fri, 29 Sep 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Fri, 29 Sep 2006, Vincent Snijders wrote: Hi, The LCL contains the non-visual unit LCLMemManager: http://svn.freepascal.org/svn/lazarus/trunk/lcl/lclmemmanager.pas I would like to propose that you rename it and add it to the FCL. It contains some simple (base) clasess for pooling records and objects. snip What name would you suggest ? A name change because of the LCL in the name. But just TMemManager is too generic, IMHO. What about TMemoryPool and TNonFreeMemoryPool? Don't you think the word MemoryManager (MM) should be in it ? This could cause confusion with TMemoryManager. like pooledmm ? (and class TPooledMemoryManager) ? I agree with Mattias. It is not a replacement for TMemoryManager like cmem. A clean up of the unit has taken place, so it is ready for moving to the FCL. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TLCLMemanager
Michael Van Canneyt wrote: On Tue, 3 Oct 2006, Vincent Snijders wrote: What about TMemoryPool and TNonFreeMemoryPool? Don't you think the word MemoryManager (MM) should be in it ? This could cause confusion with TMemoryManager. like pooledmm ? (and class TPooledMemoryManager) ? I agree with Mattias. It is not a replacement for TMemoryManager like cmem. A clean up of the unit has taken place, so it is ready for moving to the FCL. Ok, can you send me a sample demo app ? Then I'll copy it, and add the sample application. Yes, I will adapt http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=126 to compile against new unit. Did you check it in and changed its name? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 means. But maybe I missed your point. * 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. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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, but it doesn't. Test 9 fails
and said it expected 0.00 which is wrong.
Rules for rounding. If a decimal is exactly halfway (5) or more,
rounding goes up. If decimal is 5, rounding goes down. This rules
is proven by tests 5, 6, 7 and 8. So why is test 9 failing? Is this
a bug?
AssertEquals('Failing on 1', '0.10', FormatFloat('0.00', 0.1));
AssertEquals('Failing on 2', '0.01', FormatFloat('0.00', 0.01));
AssertEquals('Failing on 3', '0.00', FormatFloat('0.00', 0.001));
AssertEquals('Failing on 4', '0.50', FormatFloat('0.00', 0.5));
AssertEquals('Failing on 5', '0.01', FormatFloat('0.00', 0.0051));
AssertEquals('Failing on 6', '0.05', FormatFloat('0.00', 0.049));
AssertEquals('Failing on 7', '0.00', FormatFloat('0.00', 0.0049));
AssertEquals('Failing on 8', '0.05', FormatFloat('0.00', 0.045));
AssertEquals('Failing on 9', '0.01', FormatFloat('0.00', 0.005));
It is not a bug, it is using bankers rounding. See
http://lazarus-ccr.sourceforge.net/docs/rtl/system/round.html
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 works and what they mean by Even Number.
Take these to new tests.
AssertEquals('Failing on 10', '0.44', FormatFloat('0.00', 0.445));
AssertEquals('Failing on 11', '0.46', FormatFloat('0.00', 0.455));
Test 10:
Fails and said it expected 0.45 instead of my answer 0.44. Why?
This is how I came to my answer of 0.44. I ignore the 0. and only
look at 445 and I want that to 2 decimal digits. Lets now do what the
documentation says and go to the closest even number. 44 is even, 45
is not. So I would have thought it must round down to 0.44. It
doesn't.
by expected 0.45 you mean got 0.45, otherwise I don't understand your
reasoning.
I don't have an explanation, maybe it is due to rounding errors. 0.445 can not be
represented exactly using floating point binary numbers.
Can you see if
AssertEquals('Failing on 10', '0.12', FormatFloat('0.00', 0.125));
and
AssertEquals('Failing on 10', '0.38', FormatFloat('0.00', 0.375));
work? These number can be represented exactly.
Test 11:
Fails and said it expected 0.45 instead of my answer 0.46. Again,
the way I rounded it. Ignore the 0.' and only look at 455. I want it
to 2 decimal digits. What is the closest to a even number 45 or 46. In
this case, 46. Hence I expected it to round up and the final answer to
be 0.46. It doesn't.
I'm confused!! :-)
I
Under Delph 7 I got this ---
Failing on 9: Expected 0.00 but got 0.01
Failing on 10: Expected 0.44 but got 0.45
-- end
So what rounding does Delphi 7 use?
No idea.
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 fpc-devel@lists.freepascal.org
Subject:Re: [fpc-devel] Rounding inconsistent (critical)
Send reply to: FPC developers' list fpc-devel@lists.freepascal.org
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
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('Failing on 4', '3.04', FormatFloat('0.00', 3.045));
AssertEquals('Failing on 5', '3.05', FormatFloat('0.00', 3.04501));
Test 1: Passed
Test 2: Passed
Test 3: Passed
Test 4: Failing on 4 expected: 3.04 but was: 3.05
Test 5: Passed
See, for example,
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q42980
(there are plenty of other web sites explaining this sort of thing)
The short version is that very few numbers expressed as a decimal
fraction are representable ACCURATELY on a computer.
But 0.125 and 0.375 are representable ACCURATELY on a computer, aren't they?
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strange code in TThread in classesh.inc
Graeme Geldenhuys schreef:
On 29/09/06, Tomas Hajny [EMAIL PROTECTED] wrote:
What would be your suggestion - change it to {$IF defined(UNIX) or
defined(NETWLIBC)}? I'd say that it would be better to make the interface
completely common, i.e. to get rid of these IFDEFs completely (e.g. by
including a record defined in platform specific part of the unit).
Tomas
Yeah, I just thought it is unnecessary code duplication and extra work
if it has to be maintained. The record idea sounds like a good plan
and will get rid of the IFDEF's completely. Sound make the code much
easier to read as well.
I won't argue the maintenance aspect, but I doubt your case for readability.
If you make this change, these fields are not in the same file as the class
definition anymore, so I would have to look at two places. And the implementation
becomes more unreadible.
Instead of
FSem := 0;
It will be (assuming a record field name FPrivateData)
FPrivateData.Sem := 0;
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TLCLMemanager
Hi, The LCL contains the non-visual unit LCLMemManager: http://svn.freepascal.org/svn/lazarus/trunk/lcl/lclmemmanager.pas I would like to propose that you rename it and add it to the FCL. It contains some simple (base) clasess for pooling records and objects. For the binary trees benchmark at http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytreeslang=all I wrote an alternative using the TLCLNonFreeMemManager. The alternative runs in 40% of the time of the original and uses less memory. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TLCLMemanager
Michael Van Canneyt schreef: On Fri, 29 Sep 2006, Vincent Snijders wrote: Hi, The LCL contains the non-visual unit LCLMemManager: http://svn.freepascal.org/svn/lazarus/trunk/lcl/lclmemmanager.pas I would like to propose that you rename it and add it to the FCL. It contains some simple (base) clasess for pooling records and objects. For the binary trees benchmark at http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytreeslang=all I wrote an alternative using the TLCLNonFreeMemManager. The alternative runs in 40% of the time of the original and uses less memory. If the lazarus people agree with this, I see no problem in doing so. I think they will agree, but I will ask to make sure. What name would you suggest ? A name change because of the LCL in the name. But just TMemManager is too generic, IMHO. What about TMemoryPool and TNonFreeMemoryPool? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
