Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements
- Original Message -
From: Florian Klaempfl [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Saturday, May 28, 2005 11:20 PM
Subject: Re: [fpc-devel] don't you think it'stime
toupdatedelphimodecompatibility? - IDispatch, implements
Besides I find that FPC 2.0 makes the executables just to big.+
C:\fpctype test1.pp
begin
writeln('Hello world');
end.
...
28.05.2005 23:1425.600 test1.exe
28.05.2005 23:1411.264 test1.exe
...
IIRC Delphi creates 16 kB something.
And did you try UPX on delphi-created executables? You cannot compare
something that's not compressed with something that IS compressed - that
makes no sense.
Other thing is that the Hello, world! app is NOT using anything. As far as I
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements
- Original Message -
From: Florian Klaempfl [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Saturday, May 28, 2005 11:20 PM
Subject: Re: [fpc-devel] don't you think it'stime
toupdatedelphimodecompatibility? - IDispatch, implements
Besides I find that FPC 2.0 makes the executables just to big.+
C:\fpctype test1.pp
begin
writeln('Hello world');
end.
...
28.05.2005 23:1425.600 test1.exe
28.05.2005 23:1411.264 test1.exe
...
IIRC Delphi creates 16 kB something.
And did you try UPX on delphi-created executables? You cannot compare
something that's not compressed with something that IS compressed - that
makes no sense.
Other thing is that the Hello, world! app is NOT using anything. AFAIK this
is not the way the apps are written :). Normally you will link the SysUtils,
Classes, and under windows the Windows unit what makes the whole thing a lot
bigger than under Delphi. A simple app that's using SysUtuils under FPC is
2x the size of the same app compiled with delphi. The other example is the
Classes unit. I agree, that after using UPX the code differs only 10% (FPC
is still 10% bigger) but using UPX is not recomended ie. for DLLs. Going on
with this and compiling the simplies FCL-based application differs really
strongly from the same done under delphi. I know you can do all of the GUI
thing using base interface for GUI (Win32 API for example) but this doesn't
solve prtability issues. I don't like my executables grow beyond some
certain point and achieving this point after adding 10 controls to my GUI
app is not acceptable. In addition comparing the sources of VCL and FCL they
don't differ that much and the source isn't that much bigger so by this kind
of differences the problem must lie with compiler/linker.
Matthias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements
On 29 May 2004, at 12:21, Matthias Hryniszak wrote: In addition comparing the sources of VCL and FCL they don't differ that much and the source isn't that much bigger so by this kind of differences the problem must lie with compiler/linker. Have you tried using smart linking? (-XX) Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it'stimetoupdatedelphimodecompatibility? - IDispatch, implements
- Original Message - From: Daniël Mantione [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sunday, May 29, 2005 12:30 PM Subject: Re: [fpc-devel] don't you think it'stimetoupdatedelphimodecompatibility? - IDispatch, implements Op Sat, 29 May 2004, schreef Matthias Hryniszak: In addition comparing the sources of VCL and FCL they don't differ that much and the source isn't that much bigger so by this kind of differences the problem must lie with compiler/linker. But then again, while I don't use the FCL very much, if have not yet seen examples of unacceptable sizes yet. Try it and then you'll see what I am talking about.. the 1.5Mb for hello, world app is really not acceptable. Matthias. ___ 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] don't you thinkit'stime toupdatedelphimodecompatibility? - IDispatch, implements
- Original Message -
From: Jamie McCracken [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Sunday, May 29, 2005 12:55 PM
Subject: Re: [fpc-devel] don't you thinkit'stime
toupdatedelphimodecompatibility? - IDispatch, implements
Daniël Mantione wrote:
Op Sat, 29 May 2004, schreef Matthias Hryniszak:
It *is* the source. The compiler is perfectly capapable of removing
unused
code ust as well as the Delphi compiler. So, if you're pointing at the
compiler I assume you either have smartlinking disabled or that there is
debug information in the executable.
I don't get it. Let's try this example:
program Hello;
{$APPTYPE CONSOLE}
uses
Classes, SysUtils;
procedure Test1(Param1: String; Param2: Integer; Param3: Char; Param4:
Word);
var
I: Integer;
L: TList;
begin
L := TList.Create;
for I := 1 to 1000 do
L.Add(Pointer(I));
L.Free;
end;
begin
Writeln('Hello, world!');
end.
Here you see a test procedure that's NOT called. with FPC 2.0 the executable
file is 133120 long. Ok, let's turn this into the standard Hello, world! app
and just leave the two useses be:
program Hello;
{$APPTYPE CONSOLE}
uses
Classes, SysUtils;
begin
Writeln('Hello, world!');
end.
And what do we have? 132608 executable. AFAIK 132608 is not the same as
133120 so there MUST BE a problem with eliminating dead/unused code.
Matthias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements
At 12:55 29-5-2005, you wrote: Daniël Mantione wrote: Op Sat, 29 May 2004, schreef Matthias Hryniszak: In addition comparing the sources of VCL and FCL they don't differ that much and the source isn't that much bigger so by this kind of differences the problem must lie with compiler/linker. It *is* the source. The compiler is perfectly capapable of removing unused code ust as well as the Delphi compiler. So, if you're pointing at the compiler I assume you either have smartlinking disabled or that there is debug information in the executable. However, not much time has been spent to make sysutils, classes etc. smaller. This effort has been done on the system unit in the past, which can explain the difference. But then again, while I don't use the FCL very much, if have not yet seen examples of unacceptable sizes yet. There are too many variables here to conclude decisively what is causing it to be much bigger. Some things that will affect executable size include: 1) Over zealous use of inlining (I dont see a command option to control how much inlining is done) There is almost none in the rtl. 2) Pascal variables not making efficient use of registers. This causes more load/store instructions to be generated than is needed (also produces less optimal code!) Use -Or. But don't think that it always generates less code. Sometimes the code is bigger on i386 because you get extra load/store operations for registers esi,edi,ebx that need to be preserved between function calls. 3) Delphi includes a fair amount of assembler in its rtl. You should also compare FPC smartlinking with the equivalent in the Gnu linker (dead code elimantion?) to see if there really is a difference. The only way to get better smartlinking is to build an integrated linker in the compiler. That way we can control everything. Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't youthinkit'stime toupdatedelphimodecompatibility? - IDispatch, implements
- Original Message -
From: Jonas Maebe [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Sunday, May 29, 2005 1:10 PM
Subject: Re: [fpc-devel] don't youthinkit'stime
toupdatedelphimodecompatibility? - IDispatch, implements
On 29 May 2004, at 13:05, Matthias Hryniszak wrote:
Here you see a test procedure that's NOT called. with FPC 2.0 the
executable file is 133120 long. Ok, let's turn this into the standard
Hello, world! app and just leave the two useses be:
program Hello;
{$APPTYPE CONSOLE}
uses
Classes, SysUtils;
begin
Writeln('Hello, world!');
end.
And what do we have? 132608 executable. AFAIK 132608 is not the same as
133120 so there MUST BE a problem with eliminating dead/ unused code.
If you want dead code to be stripped from your own written code, you must
turn on the generation of smartlinkable code (-CX), and of course also
smartlinking (-XX)
Of course I've done that already - it didn't help! That's why I suggest this
is a bug. Delphi removes my procedure and leaves the executable size like it
should be (86400b).
Matthias.
PS. Try to compile it yourself and if you'll come to the sitiation when both
examples compile to the same size I'll be glad to hear how did you do that.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you thinkit'stime toupdatedelphimodecompatibility? - IDispatch, implements
The only way to get better smartlinking is to build an integrated linker in the compiler. That way we can control everything. Might it be possible to keep a recerence counter for procedures/methods while compiling them and then not to include them in the objects that are passed to the linker? I know it sounds semi-serious, but maby that's the easiest way to go around the linker-problem and be linker-independent. Matthias ___ 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] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements
Some things that will affect executable size include: 1) Over zealous use of inlining (I dont see a command option to control how much inlining is done) There is almost none in the rtl. Doesn't the compiler attempt to inline small functions/methods automatically as part of its optimisation (even if the inline directive is not specified)? The only way to get better smartlinking is to build an integrated linker in the compiler. That way we can control everything. Or have more static stuff. It should be possible for the compiler to unbox some classes (like .Net with its boxing/unboxing optimiser) into more static stuff. jamie. Peter ___ 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] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements
On 29 May 2005, at 13:26, Jamie McCracken wrote: There is almost none in the rtl. Doesn't the compiler attempt to inline small functions/methods automatically as part of its optimisation (even if the inline directive is not specified)? No. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you thinkit'stime toupdatedelphimodecompatibility? - IDispatch, implements
On 29 May 2004, at 13:19, Matthias Hryniszak wrote: Might it be possible to keep a recerence counter for procedures/ methods while compiling them and then not to include them in the objects that are passed to the linker? I know it sounds semi- serious, but maby that's the easiest way to go around the linker- problem and be linker-independent. With -CX -XX, the linker does all the work for us (at least on platforms where the generation of smartlinkable code is supported by the compiler, and those definitely include Win32, Dos and Linux/x86 -- it does not yet work under e.g. Mac OS X). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements
There is almost none in the rtl. Doesn't the compiler attempt to inline small functions/methods automatically as part of its optimisation (even if the inline directive is not specified)? No. The inline directive is only a hint to the compiler. The behaviour is the same in D2005. Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements
On 29 May 2005, at 14:03, Jamie McCracken wrote: well thats soemthing you should add to your to do list. There are plenty of things on our todo list already to keep us busy :) We've already talked about automatic inlining in the past, but nobody has spent time on it yet afaik. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]don't youthinkit'stime toupdatedelphimodecompatibility?-IDispatch, implements
The FCL is non visual? You mean the LCL? I don't know if you can do much about it. The OOP design of the LCL makes smartlinking impossible. Yes, of course I ment LCL.. sorry. Matthias. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements
well thats soemthing you should add to your to do list. Automatic inlining can deliver a signifcant performance improvement especially as delphi uses a lot of one line procedures to set property values. A fucntion call adds quite a bit of overhead (around 10+ clock cycles at a guess) But inlining doesn't help if the one line procedures are virtual methods. Well thats not a limitation on other languages. EG for Java the get/set property methods were identified as causing one of the biggest performance hits and thats why now almost every JIT/AOT inlines them automatically (the same also applies to Mono). jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements
Jamie McCracken wrote: well thats soemthing you should add to your to do list. Automatic inlining can deliver a signifcant performance improvement especially as delphi uses a lot of one line procedures to set property values. A fucntion call adds quite a bit of overhead (around 10+ clock cycles at a guess) But inlining doesn't help if the one line procedures are virtual methods. Well thats not a limitation on other languages. EG for Java the get/set property methods were identified as causing one of the biggest performance hits and thats why now almost every JIT/AOT inlines them They are basically interpreted languages which suck anyways: http://shootout.alioth.debian.org/benchmark.php?test=alllang=gcclang2=javasort=fullcpu automatically (the same also applies to Mono). Even against FPC it doesn't help java much: http://shootout.alioth.debian.org/benchmark.php?test=alllang=javalang2=fpascalsort=fullcpu jamie. ___ 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
[fpc-devel] Bug in FPC 2.0.0
Hello, I want to report a bug I've found just after I had installed new 2.0.0 compiler. I tried to compile a function, which was compiled with version 1.9.8 without any errors. The unit uses the procedure GetHeapStatus(var status: THeapStatus). On compiling the compiler says Wrong number of parameters specified. Greetings Heinz-Werner Drechsel Heinz-Werner Drechsel Berliner Ring 23 D-71522 Backnang Phone: (+49) 7191 979176 eMail: [EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] PascalScript with FPC
Hi there, have anyone used PascalScript from RemObjects with freepascal? I'm interested in doing something like PSP (Pascal Server Pages i think) but to be able to provide pure source code on the server side instead of precompiled binaries. Does anyone have someexpirience in that field? Regards, Matthias Hryniszak ([EMAIL PROTECTED]). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Error..
Hi,can anyone tell me why most of the messages I send to this list end-up with a "host is blacklisted" return message?Matthias. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] [Mensagem Automatica] Recebi Seu E-mail
Mensagem [[Spam] DUVIDO VOCE ME RECONHER =)] recebida. Recebi seu e-mail e assim que posível entrarei em contato! Tks, Yuri Surzynskyj ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch for bug 3774
In reply to Thomas Schatzl: Another optimization for your patch is to set a var to length(s) at the beginning of the proc, and use the var instead. It's called often enough that a little time could be shaved off.Post your free ad now! Yahoo! Canada Personals___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] for cycle variable
Hi, i found that in fpc 1.9.6 assignment to "for cycle" variable is forbidden. Such behavior isincompatible with other compilers. Earlier fpc versions also had only warning. What do you think about this? var i: integer;begin for i:= 1 to 2 do inc(i);end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Fwd: bug report
fpc 2.0.0 win32
problem:
I can't see pi in proceudre pre but I can see it in procedure kmp.
pre is a procedure belongingto kmp.
I found that I could only seevars in this proceudre/function and main program, but I couldn't see vars in the procedure that this procedure belongs to.
code:
var t,p:string;procedure kmp(t,p:string); var n,m,q,i:integer; pi,match:array[1..255] of integer; procedure pre(p:string); var k,q:integer; begin pi[1]:=0; k:=0; for q:=2 to m do begin while (k0) and (p[k+1]p[q]) do k:=pi[k]; if p[k+1]=p[q] then k:=k+1; pi[q]:=k; end; end; begin n:=length(t); m:=length(p); q:=0; pre(p); fillchar(match,sizeof(match),0); for i:=1 to n do
begin while (q0) and (p[q+1]t[i]) do begin match[i-q]:=q; q:=pi[q]; end; if p[q+1]=t[i] then q:=q+1; if q=m then begin match[i-q+1]:=q; q:=pi[q]; end; end; write(match[1]); for i:=2 to n do write(' ',match[i]); writeln; end;begin readln(t); readln(p); kmp(t,p);end.[EMAIL PROTECTED]Do You Yahoo!?
150MP3
1G1000___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] system time/date
Hi folks! Some newsgroup posters have wrong system time/date on their PC's. Thus the emails are being sorted wrong. This script would help on Windows PC: @echo off net time /setsntp:ptbtime1.ptb.de w32tm -once ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] system time/date
On 29 May 2005, at 15:54, [EMAIL PROTECTED] wrote: Some newsgroup posters have wrong system time/date on their PC's. No, a number of posts were held for approval for a long time and were only now let through to the mailing list. To avoid this, turn off html posting and always post with the address you are subscribed with. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error..
From: Matthias Hryniszak [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Date sent: Sat, 29 May 2004 12:56:44 +0200 Subject:[fpc-devel] Error.. Send reply to: FPC developers' list fpc-devel@lists.freepascal.org mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hi can anyone tell me why most of the messages I send to this list end-up with a host is blacklisted return message? The SMTP server you use for sending e-mail is used for sending SPAM messages (e.g. because of wrong configuration allowing easy misuse by spammers). There should be a URL in that error message - check there what to do about that situation (or forward it to the administrator of your e-mail server). Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error..
From: Matthias Hryniszak [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Date sent: Sat, 29 May 2004 12:56:44 +0200 Subject:[fpc-devel] Error.. Send reply to: FPC developers' list fpc-devel@lists.freepascal.org mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hi can anyone tell me why most of the messages I send to this list end-up with a host is blacklisted return message? The SMTP server you use for sending e-mail is used for sending SPAM messages (e.g. because of wrong configuration allowing easy misuse by spammers). There should be a URL in that error message - check there what to do about that situation (or forward it to the administrator of your e-mail server). Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PascalScript with FPC
On Sat, 28 May 2005, Matthias Hryniszak wrote: Hi there, have anyone used PascalScript from RemObjects with freepascal? I'm interested in doing something like PSP (Pascal Server Pages i think) but to be able to provide pure source code on the server side instead of precompiled binaries. Does anyone have some expirience in that field? The predecessor of PascalScript (Innerfuse Pascal) used to compile with FPC, so I guess it shouldn't be too hard to make it work, maybe except for some of the assembler routines. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]don't youthinkit'stime toupdatedelphimodecompatibility?- IDispatch, implements
yy[ Charset ISO-8859-1 unsupported, converting... ] Nobody said that the same size can be reached, but I don't consider 132k against 86k as a real problem. If you consider it as a problem, use Delphi. That's not what I ment. I see a problem with a GUI app that's using FCL. This apps are really of size that's not acceptable. 1. To who? 2. And why? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel]don't youthinkit'stimetoupdatedelphimodecompatibility?- IDispatch, implements
exe size is significant if you wan't to get your apps good reviews on freeware sites etc. thats why people use upx in the first place. its all about perception. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Marco van de Voort Sent: 29 May 2005 20:08 To: FPC developers' list Subject: Re: [fpc-devel]don't youthinkit'stimetoupdatedelphimodecompatibility?- IDispatch, implements yy[ Charset ISO-8859-1 unsupported, converting... ] Nobody said that the same size can be reached, but I don't consider 132k against 86k as a real problem. If you consider it as a problem, use Delphi. That's not what I ment. I see a problem with a GUI app that's using FCL. This apps are really of size that's not acceptable. 1. To who? 2. And why? ___ 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] PascalScript with FPC
At 18:19 28-5-2005, you wrote: Hi there, have anyone used PascalScript from RemObjects with freepascal? I'm interested in doing something like PSP (Pascal Server Pages i think) but to be able to provide pure source code on the server side instead of precompiled binaries. Does anyone have some expirience in that field? FPC can compile it for a large part. In the past the author has added support to be able to compile with FPC. But with later changes it wasn't done anymore. It shouldn't be hard to fix that also. Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] updated errord.msg File (140k)
Karl-Michael Schindler wrote: Hi, I worked on the German error file errord.msg using msgdif and errore.msg,v 1.124 as reference. The differences should be fixed and a few additional messages have been translated. Still 138 items to translate. Since this is my first go at this, maybe this should be checked carefully. :) Michael, aka mischi Applied. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]don't youthinkit'stimetoupdatedelphimodecompatibility?- IDispatch, implements
| yy[ Charset ISO-8859-1 unsupported, converting... ] | Nobody said that the same size can be reached, but I don't consider 132k | against 86k as a real problem. If you consider it as a problem, use | Delphi. | | That's not what I ment. I see a problem with a GUI app that's using FCL. | This apps are really of size that's not acceptable. | | 1. To who? | 2. And why? | I think the guy is mixing up LCL with FCL. Lars aka L505 http://z505.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Cant link - memory exhausted
Jonas Maebe wrote: If you want dead code to be stripped from your own written code, you must turn on the generation of smartlinkable code (-CX), and of course also smartlinking (-XX) First off, Im a newbie to FPC, so when I see something on the list, I give it a try to see how it affects my code. (And when I run into something I dont understand, I ask about it) Seeing the bit about -CX and -XX, I gave it a shot. My command line: fpc -va -XS -CX -XX -O3 -So -Fu~/manndoor/units -Fu~/manndoor/units/elecom -Fu~/manndoor/units/unix lord.pas Everything compiles .. but then it cant link. Searching file /bin/LD... not found Searching file /usr/bin/ld... found Using util /usr/bin/ld lord.pas(1841,1) Error: Can't call the linker, switching to external linking Error: /usr/local/bin/ppc386 returned an error exitcode (normal if you did not specifiy a source file to be compiled) (This is something thats been discussed on the list before, but no conclusion was achieved). ppas.sh is created, so I run that. Without -CX, the program wont link the first time I run ppas.sh, but will when I run ppas.sh a second time. With -CX, the program compiles, but wont link, ppas.sh is created. I run ppas.sh and it still wont link. libpvol1.a: could not read symbols: Memory exhausted .. Whats this mean? Not enough memory available to the linker? 'top' shows about 44 megs free.. (Mem: 1031620k av, 987652k used, 43968k free, 0k shrd, 147196k buff) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
