Re: [fpc-devel] First benchmark of Abbrevia 4.0
Michael Van Canneyt wrote: On Sun, 27 Mar 2005, DrDiettrich wrote: A friend of mine just has tested my archiver, with the following results for an TAR with a million of files: PowerArchiver: 530 minutes. My Unarch: 160 minutes. Huh ? Who creates archives with million of files ? Who creates a million of files in the first place ?! It's a CD archive, with descriptions of all known music CDs (FreeDB/expd). I hope to get the original .tgz archive soon, in order to test it with GNU gzip and tar as well. The time may decrease again when the log is redirected into an file... It should, definitely if the test was run on Windows; You guessed it ;-) If you need testers, I'm always prepared to help. Later, when I've ported the zip support. There are a lot of things to explore, like the actual contents of time stamps and other OS specific fields in the file descriptors. The current version is written for Delphi and Windows, a port to FPC and other OS or machines will require some adaptations; this is where somebody could jump in... Hmm, the ~4 core units (90 KB) should be sufficiently stable for an FPC and Linux port, if somebody is interested in such stuff. The documentation (9 KB HTML) is not up to date, my code is intended to be self-explanatory ;-) Another thing is the grid control for a GUI (~50 KB), based on TCustomGrid... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Friend classes?
Marco van de Voort wrote: Do you mean that only one level of dependencies must be checked with uses, whereas even the indirectly #included files must be checked for changes? You always have to do the #include. Always. Pre-compiled headers are possible, not trivial, since it requires a comparison of the entire preprocessor state to see if a header needs recompilation. With precompiled headers it's almost like with compiled units: every compiled file contains a list of dependend files, dates and/or checksums. If something has changed, the affected unit or module must be recompiled. If nothing has changed, the preprocessor states can not have changed as well. That allows the compiler to auto-find the compilation order.. A compilation order only applies to units. A Pascal compiler or linker starts with the root unit, and then descends into all used units. C projects instead consist of a single (flat) list of modules, which can be compiled in any order. A C project doesn't require any compilation order, every module can be compiled independently from other modules. Implementation: yes. Header: no. Hmm, perhaps we have a different idea of precompiled header files. Let me explain what BC 3.1 did: Header files are not precompiled for themselves, one by one, instead there must exist something like a root module (*.c) which contains a list of #include's. These included files are precompiled together, in the given order. Multiple modules can share the same precompiled headers only if the modules #include the same header files in the same sequence. The precompiled header files, for all modules of a project, reside in the same precompiled file. This file in fact is a library, containing distinct sets of precompiled headers, in different extent or order. IOW modules with exactly the same #include's in sequence share a single precompiled header module. The file may be organized as a tree of header modules, with bifurcations when different files are #included after a preceding identical sequence. Borland also introduced a #pragma headerstop, that delimits the list of precompiled header files. All modules with the same #include's before this pragma can share the same header module, eventually following #includes are not precompiled. This feature allows to precompile a reasonable number of header files into one header module. AFAIR it was easier to #include exactly the same header files in all modules of a project, regardless of the actual needs of every module. The resulting precompiled header file, for a Win3.1 project, then could be as small as 20 MB, in contrast to 80 MB for less, but different, #includes in the source modules. Regardless of such optimization, as long as the header files are not touched themselves, and the #include's in the source modules are unchanged, a recompilation of the header files is never required. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Patch for bug 2453
(My ISP's mail server is blacklisted, so sending this from Yahoo. Ugh.)
This is my first shot, so be gentle :-)
The patch assumes FP wantscompatibility with BP 7. If so, it fixes two problems; if not, at least it was a fun exercise.
First, BP ignores non-numeric characters when a ReadLn is called with an integer parameter. To fix this, I changed ReadNumeric's end condition to explicitly terminate on all non-numerics.
Second, BP will not read a Text file past an EOF character at all, regardless of its location in the file. The fix for this is inelegant (inline buffer check), but I can move this out to an external proc if it's onerous to maintain.
It's likely there are things I haven't thought of, so I appreciate comments on it.
Sterling Post your free ad now! Yahoo! Canada PersonalsIndex: text.inc
===
RCS file: /FPC/CVS/fpc/rtl/inc/text.inc,v
retrieving revision 1.29
diff -w -b -i -u -p -1 -0 -r1.29 text.inc
--- text.inc14 Feb 2005 17:13:29 - 1.29
+++ text.inc26 Mar 2005 21:34:02 -
@@ -756,21 +756,21 @@ Begin
End;
{$endif HASWIDECHAR}
{*
Read(Ln)
*}
Function NextChar(var f:Text;var s:string):Boolean;
begin
- if TextRec(f).BufPosTextRec(f).BufEnd then
+ if (TextRec(f).BufPosTextRec(f).BufEnd) {$ifdef EOF_CTRLZ} and
(TextRec(f).Bufptr^[TextRec(f).BufPos]#26) {$endif} then
begin
if length(s)high(s) then
begin
inc(s[0]);
s[length(s)]:=TextRec(f).BufPtr^[TextRec(f).BufPos];
end;
Inc(TextRec(f).BufPos);
If TextRec(f).BufPos=TextRec(f).BufEnd Then
FileFunc(TextRec(f).InOutFunc)(TextRec(f));
NextChar:=true;
@@ -784,43 +784,43 @@ Function IgnoreSpaces(var f:Text):Boolea
{
Removes all leading spaces,tab,eols from the input buffer, returns true if
the buffer is empty
}
var
s : string;
begin
s:='';
IgnoreSpaces:=false;
{ Return false when already at EOF }
- if (TextRec(f).BufPos=TextRec(f).BufEnd) then
+ if (TextRec(f).BufPos=TextRec(f).BufEnd) {$ifdef EOF_CTRLZ} and
(TextRec(f).Bufptr^[TextRec(f).BufPos]=#26) {$endif} then
exit;
while (TextRec(f).Bufptr^[TextRec(f).BufPos] in [#9,#10,#13,' ']) do
begin
if not NextChar(f,s) then
exit;
{ EOF? }
- if (TextRec(f).BufPos=TextRec(f).BufEnd) then
+ if (TextRec(f).BufPos=TextRec(f).BufEnd) {$ifdef EOF_CTRLZ} or
(TextRec(f).Bufptr^[TextRec(f).BufPos]=#26) {$endif} then
break;
end;
IgnoreSpaces:=true;
end;
procedure ReadNumeric(var f:Text;var s:string);
{
Read numeric input, if buffer is empty then return True
}
begin
repeat
if not NextChar(f,s) then
exit;
- until (length(s)=high(s)) or (TextRec(f).BufPtr^[TextRec(f).BufPos] in
[#9,#10,#13,' ']);
+ until (length(s)=high(s)) or not (TextRec(f).BufPtr^[TextRec(f).BufPos] in
['+','-','.',',','0'..'9']);
end;
Procedure fpc_Read_End(var f:Text);[Public,Alias:'FPC_READ_END']; iocheck;
{$ifdef hascompilerproc} compilerproc; {$endif}
begin
if TextRec(f).FlushFuncnil then
FileFunc(TextRec(f).FlushFunc)(TextRec(f));
end;
@@ -1049,24 +1049,25 @@ Begin
end;
exit;
end;
If TextRec(f).BufPos=TextRec(f).BufEnd Then
FileFunc(TextRec(f).InOutFunc)(TextRec(f));
hs:='';
if IgnoreSpaces(f) then
begin
{ When spaces were found and we are now at EOF,
then we return 0 }
- if (TextRec(f).BufPos=TextRec(f).BufEnd) then
+ if (TextRec(f).BufPos=TextRec(f).BufEnd) {$ifdef EOF_CTRLZ} or
(TextRec(f).Bufptr^[TextRec(f).BufPos]=#26) {$endif} then
exit;
ReadNumeric(f,hs);
end;
+ if (hs '') then
{$ifdef hascompilerproc}
Val(hs,l,code);
{$else hascompilerproc}
Val(hs,fpc_Read_Text_SInt,code);
{$endif hascompilerproc}
If code0 Then
InOutRes:=106;
End;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Quick patch for bug 3762
Turns out the CRT unit in OS/2-- which, by my searches, uses #13#10 as CRLF -- was recognizing #13 alone as CRLF. #10 was completed ignored. SterlingPost your free ad now! Yahoo! Canada PersonalsIndex: crt.pas === RCS file: /FPC/CVS/fpc/rtl/os2/crt.pas,v retrieving revision 1.8 diff -w -b -i -u -p -1 -0 -r1.8 crt.pas --- crt.pas 14 Feb 2005 17:13:31 - 1.8 +++ crt.pas 27 Mar 2005 04:27:58 - @@ -379,25 +379,22 @@ var ca:Pchar; begin i:=0; getcursor(y,x); while i=len-1 do begin case s[i] of #8: x:=x-1; #9: x:=(x-lo(windmin)) and $fff8+8+lo(windmin); - #10: ; - #13: begin - x:=lo(windmin); - inc(y); -end; + #10: inc(y); + #13: x:=lo(windmin); else begin ca:[EMAIL PROTECTED]; n:=1; while not(s[i+1] in [#8,#9,#10,#13]) and (x+n=lo(windmax)) and (ilen-1) do begin inc(n); inc(i); end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Patch for bug 2453
This is my first shot, so be gentle :-)
The patch assumes FP wants sufficient compatibility with BP 7. If so, it
fixes two problems; if not, at least it was a fun exercise.
First, BP ignores non-numeric characters when a ReadLn is called with an
integer parameter. To fix this, I changed ReadNumeric's end condition to
explicitly terminate on all non-numerics.
Second, BP will not read a Text file past an EOF character at all,
regardless of its location in the file. The fix for this is inelegant
(inline buffer check), but I can move this out to an external proc if it's
onerous to maintain.
It's likely there are things I haven't thought of, so I appreciate comments
on it.
Sterling
Index: text.inc
===
RCS file: /FPC/CVS/fpc/rtl/inc/text.inc,v
retrieving revision 1.29
diff -w -b -i -u -p -1 -0 -r1.29 text.inc
--- text.inc14 Feb 2005 17:13:29 - 1.29
+++ text.inc26 Mar 2005 21:34:02 -
@@ -756,21 +756,21 @@ Begin
End;
{$endif HASWIDECHAR}
{*
Read(Ln)
*}
Function NextChar(var f:Text;var s:string):Boolean;
begin
- if TextRec(f).BufPosTextRec(f).BufEnd then
+ if (TextRec(f).BufPosTextRec(f).BufEnd) {$ifdef EOF_CTRLZ} and
(TextRec(f).Bufptr^[TextRec(f).BufPos]#26) {$endif} then
begin
if length(s)high(s) then
begin
inc(s[0]);
s[length(s)]:=TextRec(f).BufPtr^[TextRec(f).BufPos];
end;
Inc(TextRec(f).BufPos);
If TextRec(f).BufPos=TextRec(f).BufEnd Then
FileFunc(TextRec(f).InOutFunc)(TextRec(f));
NextChar:=true;
@@ -784,43 +784,43 @@ Function IgnoreSpaces(var f:Text):Boolea
{
Removes all leading spaces,tab,eols from the input buffer, returns true if
the buffer is empty
}
var
s : string;
begin
s:='';
IgnoreSpaces:=false;
{ Return false when already at EOF }
- if (TextRec(f).BufPos=TextRec(f).BufEnd) then
+ if (TextRec(f).BufPos=TextRec(f).BufEnd) {$ifdef EOF_CTRLZ} and
(TextRec(f).Bufptr^[TextRec(f).BufPos]=#26) {$endif} then
exit;
while (TextRec(f).Bufptr^[TextRec(f).BufPos] in [#9,#10,#13,' ']) do
begin
if not NextChar(f,s) then
exit;
{ EOF? }
- if (TextRec(f).BufPos=TextRec(f).BufEnd) then
+ if (TextRec(f).BufPos=TextRec(f).BufEnd) {$ifdef EOF_CTRLZ} or
(TextRec(f).Bufptr^[TextRec(f).BufPos]=#26) {$endif} then
break;
end;
IgnoreSpaces:=true;
end;
procedure ReadNumeric(var f:Text;var s:string);
{
Read numeric input, if buffer is empty then return True
}
begin
repeat
if not NextChar(f,s) then
exit;
- until (length(s)=high(s)) or (TextRec(f).BufPtr^[TextRec(f).BufPos] in
[#9,#10,#13,' ']);
+ until (length(s)=high(s)) or not (TextRec(f).BufPtr^[TextRec(f).BufPos] in
['+','-','.',',','0'..'9']);
end;
Procedure fpc_Read_End(var f:Text);[Public,Alias:'FPC_READ_END']; iocheck;
{$ifdef hascompilerproc} compilerproc; {$endif}
begin
if TextRec(f).FlushFuncnil then
FileFunc(TextRec(f).FlushFunc)(TextRec(f));
end;
@@ -1049,24 +1049,25 @@ Begin
end;
exit;
end;
If TextRec(f).BufPos=TextRec(f).BufEnd Then
FileFunc(TextRec(f).InOutFunc)(TextRec(f));
hs:='';
if IgnoreSpaces(f) then
begin
{ When spaces were found and we are now at EOF,
then we return 0 }
- if (TextRec(f).BufPos=TextRec(f).BufEnd) then
+ if (TextRec(f).BufPos=TextRec(f).BufEnd) {$ifdef EOF_CTRLZ} or
(TextRec(f).Bufptr^[TextRec(f).BufPos]=#26) {$endif} then
exit;
ReadNumeric(f,hs);
end;
+ if (hs '') then
{$ifdef hascompilerproc}
Val(hs,l,code);
{$else hascompilerproc}
Val(hs,fpc_Read_Text_SInt,code);
{$endif hascompilerproc}
If code0 Then
InOutRes:=106;
End;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Patch for bug 3774
This patch adds recognition for hex to Val().
SterlingPost your free ad now! Yahoo! Canada PersonalsIndex: sstrings.inc
===
RCS file: /FPC/CVS/fpc/rtl/inc/sstrings.inc,v
retrieving revision 1.35
diff -w -b -i -u -p -1 -0 -r1.35 sstrings.inc
--- sstrings.inc20 Mar 2005 12:45:19 - 1.35
+++ sstrings.inc27 Mar 2005 05:12:42 -
@@ -552,20 +552,25 @@ begin
'%' : begin
base:=2;
inc(code);
end;
'' : begin
Base:=8;
repeat
inc(code);
until (code=length(s)) or (s[code]'0');
end;
+ '0' : if (code length(s)) and (s[code+1]='x') then
+begin
+ base := 16;
+ Inc(code, 2);
+end;
end;
end;
InitVal:=code;
end;
Function fpc_Val_SInt_ShortStr(DestSize: SizeInt; Const S: ShortString; var
Code: ValSInt): ValSInt; [public, alias:'FPC_VAL_SINT_SHORTSTR']; {$ifdef
hascompilerproc} compilerproc; {$endif}
var
u, temp, prev, maxPrevValue, maxNewValue: ValUInt;
base : byte;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
I had exactly the same situation with fpc for fink and solved it exactly as suggested by Daniel Herzog. I would go for Individual bootstrap tar balls for each arch, because this saves a lot of bandwidth. I called the one for macosx/darwin: fpc-1.9.8.darwin.bootstrap.tar.gz. maybe it should be fpc-1.9.8.darwin-ppc.bootstrap.tar.gz. But since we do not support darwin-x86, yet, I did not consider the cpu :) The tar ball includes the bootstrap binary and the default fpc.cfg file. Is debian for linux only? If so, just the combination of linux with every cpu is needed, and not any combination of os and cpu. But even for a case of any os with any cpu, do you really think that case would be to much? What is your guess about the distribution impact through debian packages. I guess is that it is noticable, what actually have to wait and see the effect of the fink package. Best wishes ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Quick patch for bug 3762
From: Sterling Bates [EMAIL PROTECTED] To: fpc-devel@lists.freepascal.org Subject: [fpc-devel] Quick patch for bug 3762 Date: 30.3.2005 - 12:18:31 Hi Sterling Turns out the CRT unit in OS/2 -- which, by my searches, uses #13#10 as CRLF -- was recognizing #13 alone as CRLF. #10 was completed ignored. Thanks for your patch, it's correct and I'll apply it once I get to a machine with CVS access (unless somebody else applies it earlier ;-) ). Unfortunately, the problem is wider - there are several other issues with the current OS/2 implementation (if you just quickly compare it with e.g. the GO32v2 implementation, you'd find some other problems too - e.g. handling of #8 is surely incorrect etc.). The main problem is that there's a lot platform independent functionality in Crt unit which is re-implemented for every platform again and again. The best solution would be to throw all the individual implementations away completely and implement cross-platform Crt unit based on capabilities provided by units Keyboard and Video (possibly missing functionalities within these units necessary for Crt could be either handled by platform specific include file, or by extending current Keyboard and/or Video). This issue has been discussed several times in the core team already, but nobody found the time for doing it yet due to higher priority tasks. Would you be willing to give it a try by any chance? Regards Tomas -- Akcni unorova nabidka 3 za cenu 1! Ziskejte VOLNY ADSL 512/128 3GB za cenu 1GB! http://adsl.volny.cz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Quick patch for bug 3762
On 30 mrt 2005, at 13:39, Tomas Hajny wrote: The best solution would be to throw all the individual implementations away completely and implement cross-platform Crt unit based on capabilities provided by units Keyboard and Video (possibly missing functionalities within these units necessary for Crt could be either handled by platform specific include file, or by extending current Keyboard and/or Video). This issue has been discussed several times in the core team already, but nobody found the time for doing it yet due to higher priority tasks. Would you be willing to give it a try by any chance? We can't give you a free computer if you do so, though :) Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch for bug 2453
From: Sterling Bates [EMAIL PROTECTED] To: fpc-devel@lists.freepascal.org Subject: [fpc-devel] Patch for bug 2453 Date: 30.3.2005 - 12:18:36 This is my first shot, so be gentle :-) The patch assumes FP wants sufficient compatibility with BP 7. If so, it fixes two problems; if not, at least it was a fun exercise. The EOF part looks correctly to me (although I didn't check whether there aren't other places where the check should be added too). The current behaviour when the character is recognized in Eof function (depending on EOF_CTRLZ conditional), but not otherwise, isn't very consistent, IMHO. However, let's wait what other core team members would think about it. Regarding function ReadNumeric, I think there's at least one open issue there, and that's missing handling of 'e' (or 'E') character for exponent. I'm not sure whether there are any other allowed characters, but at least this one should be supported. Tomas -- ! NOVINKA ! -- SURVIVAL L-Carnitin+Chrom -- Zbav se kil a dej se do formy! http://www.sportwave.cz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch for bug 3774
Sterling Bates schrieb:
This patch adds recognition for hex to Val().
+ '0' : if (code length(s)) and (s[code+1]='x') then
+begin
+ base := 16;
+ Inc(code, 2);
+end;
Here's a patch (Delphi also accepts uppercased X) and optimization for
the patch =) (To be applied to the same code version as your patch)
Regards,
Thomas
548,550c548
repeat
inc(code);
until (code=length(s)) or (s[code]'0');
---
inc(code);
554c552
inc(code);
---
inc(code);
558,560c556,563
repeat
inc(code);
until (code=length(s)) or (s[code]'0');
---
inc(code);
end;
'0' : begin
if (code length(s)) and (s[code+1] in ['x', 'X']) then
begin
inc(code, 2);
base := 16;
end;
562a566,569
end;
{ strip leading zeros }
while ((code length(s)) and (s[code] = '0')) do begin
inc(code);
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
Even better:
One single archive containing all ppc* starting compilers - this way i
could also package it quite easily for all arches, and it would easy to
script it using ppc${ARCH} everywhere...you see?
I don't see it. Because that package will be huge since you need a ppc for
every cpu-os combination.
Well...then on per cpu-os combination...for example ppc linux or
something - not neccessarily those seldomly used stuff like mips or so...
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
I had exactly the same situation with fpc for fink and solved it exactly as suggested by Daniel Herzog. I would go for Individual bootstrap tar balls for each arch, because this saves a lot of bandwidth. I called the one for macosx/darwin: fpc-1.9.8.darwin.bootstrap.tar.gz. maybe it should be fpc-1.9.8.darwin-ppc.bootstrap.tar.gz. But since we do not support darwin-x86, yet, I did not consider the cpu :) The tar ball includes the bootstrap binary and the default fpc.cfg file. Is debian for linux only? If so, just the combination of linux with every cpu is needed, and not any combination of os and cpu. But even for a case of any os with any cpu, do you really think that case would be to much? What is your guess about the distribution impact through debian packages. I guess is that it is noticable, what actually have to wait and see the effect of the fink package. Best wishes I want to package for Gentoo, which, for now, supports the following: alpha amd64 arm hppaia64mipsppc ppc64 ppc macos s390sh sparc x86 But the most important ones are x86, ppc and amd64. There even are devs working on *BSD - it works, but they didnt have official releases yet afaik. So if you just place a ppc386, ppcppc and a ppc??? somewhere that would be perfectly fine. For now i waste your bandwidth by getting the complete binary.tar. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
Peter Vreman schrieb: Jonas Maebe schrieb: On 29 mrt 2005, at 16:40, Daniel Herzog wrote: Here it doesnt. I even tried to change the mtu of all relevant systems to 1400 instead of 1500, which didnt help also...and i cant lower my mtu far more...i want some troughput. I don't know what or where the problem is, but you're the first person I hear of who can't reach it. Jonas It worked for ages here, while i never touched my router for about 2 years now... Maybe someone responsible for the webserver could show up and tell me if there were changes done to it recently or not? The webserver (apache2) uses the defaults from Suse 9.2. Nothing special is configured. Quite a few now said it might be the case that it's firewall blocks all icmp packages. Try lowering the servers mtu for the fun with it. Mine is 1442, automatically lowered to the highest value working everywhere. Think of possible PPPoE headers, since you seem to have a dsl connection. dunno what the exact setup looks like. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
Does the darwin ppcppc binary actually work on linux-ppc? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On Wed, 30 Mar 2005 19:24:13 +0200 Daniel Herzog [EMAIL PROTECTED] wrote: Quite a few now said it might be the case that it's firewall blocks all icmp packages. Try lowering the servers mtu for the fun with it. Yes, any sensible sysadmin ought to know that ICMP fragment error packets (type 3, code 4?) should always be allowed. HTH, Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
On 30 mrt 2005, at 19:32, Dr. Karl-Michael Schindler wrote: Does the darwin ppcppc binary actually work on linux-ppc? No, you need a different ppcppc for that. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On Wed, 30 Mar 2005, Daniel Herzog wrote: Peter Vreman schrieb: Jonas Maebe schrieb: On 29 mrt 2005, at 16:40, Daniel Herzog wrote: Here it doesnt. I even tried to change the mtu of all relevant systems to 1400 instead of 1500, which didnt help also...and i cant lower my mtu far more...i want some troughput. I don't know what or where the problem is, but you're the first person I hear of who can't reach it. Jonas It worked for ages here, while i never touched my router for about 2 years now... Maybe someone responsible for the webserver could show up and tell me if there were changes done to it recently or not? The webserver (apache2) uses the defaults from Suse 9.2. Nothing special is configured. Quite a few now said it might be the case that it's firewall blocks all icmp packages. Try lowering the servers mtu for the fun with it. Mine is 1442, automatically lowered to the highest value working everywhere. Think of possible PPPoE headers, since you seem to have a dsl connection. dunno what the exact setup looks like. I don't think it is the server, as the MTU size of the server didn't change. The router is outside my control; It's controlled by the ISP; So there is nothing I can do about it. If you can tell me how to determine it's MTU size, then I can try to do something about it. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
Does the darwin ppcppc binary actually work on linux-ppc? No. - i just tought ppcppc was linux on ppcwell then, replace it with the correct one :-) $ ./ppcppc bash: ./ppcppc: cannot execute binary file $ file ppcppc ppcppc: Mach-O executable ppc $ file ppc386 ppc386: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On Wed, 30 Mar 2005, Micha Nelissen wrote: On Wed, 30 Mar 2005 19:24:13 +0200 Daniel Herzog [EMAIL PROTECTED] wrote: Quite a few now said it might be the case that it's firewall blocks all icmp packages. Try lowering the servers mtu for the fun with it. Yes, any sensible sysadmin ought to know that ICMP fragment error packets (type 3, code 4?) should always be allowed. Can you please translate this to plain english ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
On Wed, 2005-03-30 at 20:52 +0200, Daniel Herzog wrote: No. - i just tought ppcppc was linux on ppcwell then, replace it with the correct one :-) It is also called ppcppc on linux: $ file /usr/lib/fpc/1.9.4/ppcppc /usr/lib/fpc/1.9.4/ppcppc: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, stripped Therefore, you'd have to have something like both ppcppclinux and ppcppcosx for your scheme to work. johannes signature.asc Description: This is a digitally signed message part ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On Wed, 2005-03-30 at 22:17 +0200, Michael Van Canneyt wrote: I don't think it is the server, as the MTU size of the server didn't change. The router is outside my control; It's controlled by the ISP; So there is nothing I can do about it. If you can tell me how to determine it's MTU size, then I can try to do something about it. *If* there is a problem on your end then it is your server's firewall, if it was letting through ICMP fragmentation needed packets this problem should not exist. OTOH, that problem might be elsewhere too. johannes signature.asc Description: This is a digitally signed message part ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Packaging
the second part of the filename of the compiler specifies the target cpu (ie what cpu it produces code for) no information on the system the compiler itself is meant to run on is contained in the file name -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Daniel Herzog Sent: 30 March 2005 19:52 To: FPC developers' list Subject: Re: [fpc-devel] Packaging Does the darwin ppcppc binary actually work on linux-ppc? No. - i just tought ppcppc was linux on ppcwell then, replace it with the correct one :-) $ ./ppcppc bash: ./ppcppc: cannot execute binary file $ file ppcppc ppcppc: Mach-O executable ppc $ file ppc386 ppc386: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On Wed, 30 Mar 2005, Johannes Berg wrote: On Wed, 2005-03-30 at 22:17 +0200, Michael Van Canneyt wrote: I don't think it is the server, as the MTU size of the server didn't change. The router is outside my control; It's controlled by the ISP; So there is nothing I can do about it. If you can tell me how to determine it's MTU size, then I can try to do something about it. *If* there is a problem on your end then it is your server's firewall, if it was letting through ICMP fragmentation needed packets this problem should not exist. OTOH, that problem might be elsewhere too. Then the problem is elsewhere. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
On Wed, 2005-03-30 at 20:52 +0200, Daniel Herzog wrote: No. - i just tought ppcppc was linux on ppcwell then, replace it with the correct one :-) It is also called ppcppc on linux: $ file /usr/lib/fpc/1.9.4/ppcppc /usr/lib/fpc/1.9.4/ppcppc: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, stripped Therefore, you'd have to have something like both ppcppclinux and ppcppcosx for your scheme to work. All files should have arch+os+version_it_is_meant_to_bootstrap. Both OS and arch are a bit dangerous, since FPC notation, ppcx notation, GNU notation and uname notation might not match. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On Wed, 30 Mar 2005, Daniel Herzog wrote: Michael Van Canneyt schrieb: On Wed, 30 Mar 2005, Daniel Herzog wrote: Peter Vreman schrieb: Jonas Maebe schrieb: On 29 mrt 2005, at 16:40, Daniel Herzog wrote: Here it doesnt. I even tried to change the mtu of all relevant systems to 1400 instead of 1500, which didnt help also...and i cant lower my mtu far more...i want some troughput. I don't know what or where the problem is, but you're the first person I hear of who can't reach it. Jonas It worked for ages here, while i never touched my router for about 2 years now... Maybe someone responsible for the webserver could show up and tell me if there were changes done to it recently or not? The webserver (apache2) uses the defaults from Suse 9.2. Nothing special is configured. Quite a few now said it might be the case that it's firewall blocks all icmp packages. Try lowering the servers mtu for the fun with it. Mine is 1442, automatically lowered to the highest value working everywhere. Think of possible PPPoE headers, since you seem to have a dsl connection. dunno what the exact setup looks like. I don't think it is the server, as the MTU size of the server didn't change. The router is outside my control; It's controlled by the ISP; So there is nothing I can do about it. If you can tell me how to determine it's MTU size, then I can try to do something about it. Michael. you could maybe try to ping google or something with huge package. remember to add the header size in mind. Works with size up to 1472. (+28=1500, so this figures) Conslusion you pull from this test ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On Wed, 30 Mar 2005, Daniel Herzog wrote: you could maybe try to ping google or something with huge package. remember to add the header size in mind. Works with size up to 1472. (+28=1500, so this figures) Conslusion you pull from this test ? Same here, and I can ping www.freepascal.org till 8184. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
I think this should be a nice solution: bootstrap-arch-os-the version i can bootstrap with this.tar.gz This results in: bootstrap-386-linux-1.9.8.tar.gz containing a 1.0.10 version binary, for example. Please note i used 386 for arch, not x86, or something. So arch is always a valid ppc* ending. This eases up scripting. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
From the ping tests that have just been sent in, it's clear that it works for high MTUs also. But it doesnt neccessarily show that any Fragmentation needed packages can reach the server - which is the thing we need to proof or disproof, I'd say... And i'm sorry - i have no idea how this could be done - anyone? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On Wed, 2005-03-30 at 21:45 +0200, Marco van de Voort wrote: Same here, and I can ping www.freepascal.org till 8184. The size at which you can ping www.freepascal.org isn't relevant, that just means that you are not blocking 'fragmentation needed' packets. Interesting might be the size at which www.freepascal.org itself can ping, for example, xzone.dyndns.org (our dynamic behind-dsl IP which has a MTU lower than 1500) johannes signature.asc Description: This is a digitally signed message part ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On Wed, 30 Mar 2005, Johannes Berg wrote: On Wed, 2005-03-30 at 21:45 +0200, Marco van de Voort wrote: Same here, and I can ping www.freepascal.org till 8184. The size at which you can ping www.freepascal.org isn't relevant, that just means that you are not blocking 'fragmentation needed' packets. Interesting might be the size at which www.freepascal.org itself can ping, for example, xzone.dyndns.org (our dynamic behind-dsl IP which has a MTU lower than 1500) That is what I did: I pinged www.google.be from www.freepascal.org. and the maximum size was 1472. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
On Wed, 2005-03-30 at 23:44 +0200, Michael Van Canneyt wrote: That is what I did: I pinged www.google.be from www.freepascal.org. and the maximum size was 1472. You should be able to ping much higher unless you do 'ping -M dont ...' since The fact that you cannot suggests that there may be some router/firewall blocking these ICMP packets. johannes signature.asc Description: This is a digitally signed message part ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packaging
I think this should be a nice solution: bootstrap-arch-os-the version i can bootstrap with this.tar.gz This results in: bootstrap-386-linux-1.9.8.tar.gz containing a 1.0.10 version binary, for example. Please note i used 386 for arch, not x86, or something. So arch is always a valid ppc* ending. This eases up scripting. In the FPC crosbuild and installation scripts there are some conversions for this, e.g. # conversion from long to short archname for ppcx case $FPCTARGET in m68k*) PPCSUFFIX=68k;; sparc*) PPCSUFFIX=sparc;; i386*) PPCSUFFIX=386;; powerpc*) PPCSUFFIX=ppc;; arm*) PPCSUFFIX=arm;; x86_64*) PPCSUFFIX=x64;; mips*) PPCSUFFIX=mips;; ia64*) PPCSUFFIX=ia64;; alpha*) PPCSUFFIX=alpha;; esac See install/ directory. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
Date sent: Wed, 30 Mar 2005 23:44:20 +0200 (CEST) From: Michael Van Canneyt [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Subject:Re: [fpc-devel] webserver Send reply to: FPC developers' list fpc-devel@lists.freepascal.org mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Same here, and I can ping www.freepascal.org till 8184. The size at which you can ping www.freepascal.org isn't relevant, that just means that you are not blocking 'fragmentation needed' packets. Interesting might be the size at which www.freepascal.org itself can ping, for example, xzone.dyndns.org (our dynamic behind-dsl IP which has a MTU lower than 1500) That is what I did: I pinged www.google.be from www.freepascal.org. and the maximum size was 1472. However, I just tried to ping from www.freepascal.org to the machine mentioned here by someone (xzone.dyndns.org) and packets with size of 16000 went through without problems... Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Bug 3543
Hello. Bug 3543 has been closed as unreproducable, but I can not compile this program at least with fpc 1.9.8 on Win32: Uses Keyboard; begin repeat until KeyPressed; end. Error: Identifier not found KeyPressed -- Best regards, Maxim mailto:[EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug 3543
Maxim Ganetsky schrieb: Hello, Bug 3543 has been closed as unreproducable, but I can not compile this program at least with fpc 1.9.8 on Win32: Uses Keyboard; begin repeat until KeyPressed; end. Error: Identifier not found KeyPressed According to the unit sources there is no keypressed() function in the keyboard unit, the docs are wrong (I think so at least) or it has been removed. Additionally you have to initialize the keyboard unit before using it, and deinitialize it afterwards manually, otherwise the keyboard methods won't work. But there's a solution, I think you can simulate the keypressed function with the PollKeyEvent method as suggested in the docs: uses keyboard; function keypressed : boolean; begin keypressed := PollKeyEvent 0; end; begin InitKeyBoard(); repeat until keypressed; DoneKeyBoard(); end. Regards, Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
Michael Van Canneyt schrieb: On Wed, 30 Mar 2005, Johannes Berg wrote: On Wed, 2005-03-30 at 21:45 +0200, Marco van de Voort wrote: Same here, and I can ping www.freepascal.org till 8184. The size at which you can ping www.freepascal.org isn't relevant, that just means that you are not blocking 'fragmentation needed' packets. Interesting might be the size at which www.freepascal.org itself can ping, for example, xzone.dyndns.org (our dynamic behind-dsl IP which has a MTU lower than 1500) That is what I did: I pinged www.google.be from www.freepascal.org. and the maximum size was 1472. Michael. If you're on freenode, query me (expose) please - and try to ping me - since i myself can ping google with real big packages also - but not www.freepascal.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Quick patch for bug 3762
In response to Tomas Hajny:
I'd certainly be willing to give it a try. Granted, I only have Windows XP, but if I'm careful it should be a smooth transition. No promises on a timeline :)
Another problem with Windows (not sure about other OSs) is in bug 2084. (Use the second example in the description.) I was able to narrow down what the problem is, and it's pretty daunting. Essentially, initmouse will call SetMouseEventHandler() in winevent.pp. This spawns a thread that runs EventHandleThread in a fairly tight loop, which captures all console input.
The problem comes when ReadKey then calls KeyPressed, which also attempts to read console input. No matter what, EventHandleThread will capture the input (since it places a call to WaitForSingleObject, waking up the instant something is in the queue), leaving KeyPressed with nothing to process.
My initial attempt to get around this is to tie KeyPressed to EventHandleThread as well. (If you can't beat 'em, join 'em, right?) I've attached the work I've done so far, but it's not quite right. With two ReadKey calls in a row, the first will read the key, the second will exit without even reading the queue. I think this is because the first ReadKey hasn't had a chance to clear the ScanCode variable before the second ReadKey call to KeyPressed (which exits when ScanCode #0). This results in the DOS window outputting a garbage character when the program finishes because there's still something in the queue.
It's possible to fix it by wrapping the contents of ReadKey in a critical section, but that, to me, is just more overhead. I think there's a more elegant solution waiting to be discovered :-)
Thanks,
Sterling
Your message below:
--
Unfortunately, the problem is wider - there are several other issues with the current OS/2 implementation (if you just quickly compare it with e.g. the GO32v2 implementation, you'd find some other problems too - e.g. handling of #8 is surely incorrect etc.).
The main problem is that there's a lot platform independent functionality in Crt unit which is re-implemented for every platform again and again. The best solution would be to throw all the individual implementations away completely and implement cross-platform Crt unit based on capabilities provided by units Keyboard and Video (possibly missing functionalities within these units necessary for Crt could be either handled by platform specific include file, or by extending current Keyboard and/or Video). This issue has been discussed several times in the core team already, but nobody found the time for doing it yet due to higher priority tasks. Would you be willing to give it a try by any chance?Post your free ad now! Yahoo! Canada Personals===
RCS file: /FPC/CVS/fpc/rtl/win32/crt.pp,v
retrieving revision 1.24
diff -w -b -i -u -p -1 -0 -r1.24 crt.pp
--- crt.pp 14 Feb 2005 17:13:32 - 1.24
+++ crt.pp 31 Mar 2005 06:08:59 -
@@ -20,21 +20,22 @@ interface
{$i crth.inc}
procedure Window32(X1,Y1,X2,Y2: DWord);
procedure GotoXY32(X,Y: DWord);
function WhereX32: DWord;
function WhereY32: DWord;
implementation
uses
- windows;
+ windows,
+ winevent;
var
SaveCursorSize: Longint;
{
definition of textrec is in textrec.inc
}
{$i textrec.inc}
@@ -347,130 +348,138 @@ begin
end
else
case Scancode of
// Function keys
$57..$58: inc(Scancode, $2E); // F11 and F12
end;
RemapScanCode := ScanCode;
end;
+var
+ KeyEvt: THandle; // signal that a key is ready for processing
+ KeyPrcEvt: THandle; // signal that the key has been processed
+ KeyBuf: PInputRecord; // pointer to incoming INPUT_RECORD
+ KeyCS: TCriticalSection; // restricts KeyPressed access to single thread
+
+
+procedure OnKeyEvent(var ir: INPUT_RECORD);
+begin
+ KeyBuf := @ir;
+ Windows.SetEvent(KeyEvt);
+ WaitForSingleObject(KeyPrcEvt, INFINITE);
+ Windows.ResetEvent(KeyEvt);
+end;
+
+
function KeyPressed : boolean;
var
nevents,nread : dword;
- buf : TINPUTRECORD;
AltKey: Boolean;
c : longint;
begin
KeyPressed := FALSE;
+ { Leave KeyPrcEvt set at the end of the proc; this avoids deadlocks in }
+ { OnKeyEvent while waiting for the event to signal. }
+ Windows.ResetEvent(KeyPrcEvt);
+
if ScanCode #0 then
KeyPressed := TRUE
else
begin
- GetNumberOfConsoleInputEvents(TextRec(input).Handle,nevents);
- while nevents0 do
- begin
- ReadConsoleInputA(TextRec(input).Handle,buf,1,nread);
- if buf.EventType = KEY_EVENT then
-if buf.Event.KeyEvent.bKeyDown then
+ WaitForSingleObject(KeyEvt, INFINITE);
+
+ if KeyBuf^.Event.KeyEvent.bKeyDown then
begin
{ Alt key is VK_MENU }
{ Capslock key is VK_CAPITAL }
- AltKey := ((Buf.Event.KeyEvent.dwControlKeyState AND
+ AltKey :=
Re: RE: [fpc-devel] Quick patch for bug 3762
From: Sterling Bates [EMAIL PROTECTED] To: fpc-devel@lists.freepascal.org Subject: RE: [fpc-devel] Quick patch for bug 3762 Date: 31.3.2005 - 8:26:06 I'd certainly be willing to give it a try. Granted, I only have Windows XP, but if I'm careful it should be a smooth transition. No promises on a timeline :) Fine. I can perform testing for OS/2 and GO32v2, and testers for Unix targets shouldn't be difficult to find in FPC core team, I guess... ;-) In addition, you can do everything on one platform (successively replacing all Win32 API calls with the low-level functions from our console units) and then perform necessary testing on other platforms just before switching them to the common implementation, so this is rather easy to handle, IMHO. I'd just suggest to refer to the GO32v2 implementation while working on it, because this one is probably the most compatible one to TP/BP behaviour. Another problem with Windows (not sure about other OSs) is in bug 2084. (Use the second example in the description.) I was That's the point - there are quite a few different issues on different platforms. Instead of trying to address them in platform-specific implementations, it would be probably better to replace them with common implementation based on existing console units (Keyboard, Video, Mouse) which are already used in FVision and thus in our text-mode IDE (so there's quite some chance they might be working fairly well nowadays). I don't know whether this would eliminate all the problems (see below too), but if not, it would probably mean that the problem already exists in these console units and should be fixed there anyway. Especially the clash between Crt and console (former FPC API units) appearing in bug 2084 is exactly something which should get automatically resolved with this Crt unit rewrite. able to narrow down what the problem is, and it's pretty daunting. Essentially, initmouse will call SetMouseEventHandler() in winevent.pp. This spawns a thread that runs EventHandleThread in a fairly tight loop, which captures all console input. The problem comes when ReadKey then calls KeyPressed, which also attempts to read console input. No matter what, EventHandleThread will capture the input (since it places a call to WaitForSingleObject, waking up the instant something is in the queue), leaving KeyPressed with nothing to process. My initial attempt to get around this is to tie KeyPressed to EventHandleThread as well. (If you can't beat 'em, join 'em, right?) I've attached the work I've done so far, but it's not quite right. With two ReadKey calls in a row, the first will read the key, the second will exit without even reading the queue. I think this is because the first ReadKey hasn't had a chance to clear the ScanCode variable before the second ReadKey call to KeyPressed (which exits when ScanCode #0). This results in the DOS window outputting a garbage character when the program finishes because there's still something in the queue. I'm no Win32 person, so I wouldn't be probably able to help with details here. However - does unit Keyboard suffer from the same problem (GetKeyEvent versus PollKeyEvent)? It's possible to fix it by wrapping the contents of ReadKey in a critical section, but that, to me, is just more overhead. I think there's a more elegant solution waiting to be discovered :-) The fewer critical sections the better - I'd try to avoid that unless absolutely necessary. Tomas -- ! NOVINKA ! -- SURVIVAL L-Carnitin+Chrom -- Zbav se kil a dej se do formy! http://www.sportwave.cz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
