Re: [fpc-pascal] How to inline CompareFunc to Sort method in generic abstract class

[Adrian Veith via fpc-pascal]

Hi,

with standard generics in pascal there is currently no solution, but you 
can do it with a "poor man's template". They work with .inc files which 
contain the generic part of your code and they are then included in your 
specialization unit. Something like this for a generic sort - I use 
Delphi syntax !:


file mySuperSort.inc:

procedure Run;

var n, i: Integer; swapped: Boolean begin // this is the generic array 
like object you want to sort n  :=  Length(this);

  repeat
swapped  :=  false
for  i:=0 to n-1 do begin // greater is you generic compare
  if  greater(this[i], this[i+1]) then begin
swap(i,  i+1);
swapped  :=  true;
  end;
end;
n  :=  n- 1;
until not swapped;
end;

Now include it at the place where you need it. In most of the cases the 
easiest way is to create a small adapter record/object


type
  TMySortAdapter = record
this: TMyDataArray;
descending: Boolean;
procedure swap(var a, b: TMyDataType); inline;
function greater(a, b: TMyDataType); inline;
procedure sort(data: TMyDataArray; ADescending:Boolean);
  end;

procedure TMySortAdapter.swap(var a, b: TMyDataType);
var t: TMyDataType;
begin
  t:= a;
  a:= b;
  b:= t;
end;

function TMySortAdapter.greater(a, b: TMyDataType);
begin
  if not descending then
Result:= a > b // whatever you need for you compare
  else
Result:= b > a
end;

procedure TMySortAdapter.sort(data: TMyDataArray; ADescending:Boolean);
{$I mySuperSort.inc}
begin
  this:= data;
  descending:= ADescending;
  run;
end;

That's the idea behind "poor man templates". Code completely untested

Not exactly the answer you were looking for, but it works.

Adrian.

Am 14.11.22 um 19:26 schrieb Vojtěch Čihák via fpc-pascal:

Hi,
  
I wrote a generic abstract class - a list based on dynamic array (i.e. array of T;) and this class can be specialized elsewhere with any type (records or classes).

Part of the class is sorting. There are more ways how to deliver *compare 
function* to sorting method. I can pass it as a parameter or I can define it 
as: function Compare(A, B: T): Integer; virtual; abstract;. But this way the 
function cannot be inlined.
  
Question: Is there a way how to *inline* compare function to sorting method in this general purpose generic abstract class?
  
Thanks.
  
PS: The gain is 6-7%.

___
fpc-pascal maillist  -fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Stack alias for ARC like memory management?

[Adrian Veith]

Am 25.04.2018 um 08:34 schrieb Ryan Joseph:
>
>> On Apr 25, 2018, at 12:59 PM, Sven Barth via fpc-pascal 
>>  wrote:
>>
>> No. This would more often than not lead to accidents were users pass such an 
>> instance to some outer code (it doesn't even need to the routine with the 
>> stack object, but some third party routine that for some reason stores the 
>> pointer and is called from that routine) and then will trigger an exception 
>> in the best case or hard to debug errors in the worst case. 
> I assume if programmers care enough about performance they’re planning out 
> memory usage by stack vs heap they know not to do that. The pointer is only 
> alive for the duration of the scope. I thought this was a good idea because 
> it explicitly lets you opt in when know you really need it and it’s discreet.
>
> If c++ programmers know not to do that why don’t Pascal programmers? There’s 
> endless ways to screw yourself with memory in general (especially in c++) but 
> we still find a way.

If you know what you are doing, you have exactly the "object" type for
that. You can allocate them on the stack or heap and you can inherit
from them, when you need virtual methods the initialization is a bit
strange (and if you need performance virtual methods are wrong anyway).
The benefit is better performance when needed. The downside is that they
are more unsafe to use than "class" type and you should now what you do.
If I need a cheap (performance wise) "procedure of object" for example,
that can't escape from the scope I use them instead of a class:

type
  TDataArray = array of Integer;
  TFilterData = function(element: Integer): Boolean of object;

function FilterData(const data: array of Integer; filter: TFilterData):
TDataArray;
var
  i, lr, el: Integer;
begin
  Result:= nil;
  lr:= 0;
  for el in data do begin
    if filter(el) then begin
  SetLength(result, lr + 1);
  result[lr]:= el;
  inc(lr);
    end;
  end;
end;

type
  TTestClosure = object
    val: Integer;
    function less(element: Integer): Boolean;
  end;

function TTestClosure.less(element: Integer): Boolean;
begin
  Result:= element < val;
end;

procedure Test;
var
  stack: TTestClosure;
  data: TDataArray;
begin
  stack.val:= 10;
  data:= FilterData([2,4,8,10,12], stack.less);
  assert(Length(data) = 3);
end; 


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [OT] Happy tickets benchmark

[Adrian Veith]

I mark this OT because, this group is surly not interested in this and I
am not going to answer on this anymore. We have a saying in Germany:
"Wer misst, misst Mist".

cheers, Adrian.

Am 18.02.2016 um 12:15 schrieb Serguei TARASSOV:
> On 18/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:
>> Date: Wed, 17 Feb 2016 18:55:29 +0100
>> From: Adrian Veith<adr...@veith-system.de>
>> To: FPC-Pascal users discussions<fpc-pascal@lists.freepascal.org>
>> Subject: Re: [fpc-pascal] Happy tickets benchmark
>>
>> I don't want to insist on this, but: if you measure the runtime of your
>> program you result = runtime + error. If you measure a series against
>> MIN you measure MIN(result) = runtime + MIN(error) which delivers the
>> best value for runtime.
> Not at all, any series against MIN delivers the best value for
> MIN(result) not for runtime!
>
> Ex.
> Prog 1
> Run 1: 130 = 100 + 30
> Run 2: 160 = 100 + 60
> Run 3: 170 = 100 + 70
> Min = 130, Avg = 153
>
> Prog 2
> Run 1: 120 = 110 + 10
> Run 2: 150 = 110 + 40
> Run 3: 200 = 110 + 90
> Min = 120, Avg = 157
>
> MIN shows that Prog 2 is faster that is wrong.
> AVG shows that Prog 1 is faster.
>
> Regards,
> Serguei
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Adrian Veith]

I don't want to insist on this, but: if you measure the runtime of your
program you result = runtime + error. If you measure a series against
MIN you measure MIN(result) = runtime + MIN(error) which delivers the
best value for runtime.

Am 17.02.2016 um 12:28 schrieb Serguei TARASSOV:
> On 17/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:
>> Date: Tue, 16 Feb 2016 14:44:42 +0100
>> From: Adrian Veith<adr...@veith-system.de>
>> To: FPC-Pascal users discussions<fpc-pascal@lists.freepascal.org>
>> Subject: Re: [fpc-pascal] Happy tickets benchmark
>>
>> small remark for your testing series:
>> AVG makes no sense, you should test against MIN  - why ? the measured
>> results are contaminated by other activities on your system, so the
>> fastest result is the most accurate, because there is no way to make a
>> program to run faster, but many ways to make it run slower.
> No, the test against MIN shows only the case when the result was
> _minimally contaminated_ in the series. But we don't know whether the
> unused time was bigger or smaller than for other program.
> Also, it is very probably that the minimal time in series of 1000 will
> be better that in series of 10 and so on.
>
> The average approach smooth the contaminated time in series for all
> programs.
> But you could use some better approaches like the direct measure of
> the time used by CPU or simply remove extreme values.
>
> I don't suppose that it changes anything in the relative comparison
> that is the goal of test.
>
> Regards,
> Serguei
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Adrian Veith]

small remark for your testing series:
AVG makes no sense, you should test against MIN  - why ? the measured
results are contaminated by other activities on your system, so the
fastest result is the most accurate, because there is no way to make a
program to run faster, but many ways to make it run slower.

Am 16.02.2016 um 12:19 schrieb Serguei TARASSOV:
> On 16/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:
>> Date: Mon, 15 Feb 2016 13:02:48 +0100 (CET)
>> From: Michael Van Canneyt<mich...@freepascal.org>
>> To: FPC-Pascal users discussions<fpc-pascal@lists.freepascal.org>
>> Subject: Re: [fpc-pascal] Happy tickets benchmark
>>
>> On Mon, 15 Feb 2016, Serguei TARASSOV wrote:
>>
>>> >On 15/02/2016 12:00,fpc-pascal-requ...@lists.freepascal.org  wrote:
>>>> >>Date: Mon, 15 Feb 2016 07:55:55 +0100
>>>> >>From: Florian Kl?mpfl<flor...@freepascal.org>
>>>> >>To:<adr...@veith-system.de>, "FPC-Pascal users discussions"
>>>> >><fpc-pascal@lists.freepascal.org>, Adrian Veith<adr...@vtim.de>
>>>> >>Subject: Re: [fpc-pascal] Happy tickets benchmark
>>>> >>Message-ID:
>>>> >>   
>>>> <152e3b6cc90.27ef.940694a44bcba3a3e493262cc9dc5...@freepascal.org>
>>>> >>Content-Type: text/plain; charset="iso-8859-1"
>>>> >>
>>>> >>Well, as said before: if the speed of code like this is important
>>>> for you,
>>>> >>use C.
>>> >It's a wrong choice.
>>> >As we can see and reproduce, at least C# or other Pascal-like
>>> environments
>>> >(Oxygene) are significantly faster.
>>> >http://www.arbinada.com/main/en/node/1532
>>> >
>> What Florian means is that this is very artificial code, and that -
>> although
>> he has been able to apply the necessary patches to make FPC faster - the
>> necessary optimizations are not likely to help in real-life programs.
>>
>> Michael.
>
> Sounds like the real-life programs don't use inner loops or don't
> solve NP-complete problems  :)
> For info, my real-life examples are the application server and the DSL
> script engine.
> So any improvement of quality of FPC's generated code are welcome.
>
> Regards,
> Serguei
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Adrian Veith]

Hm,

doing the same trick in C, it goes down from:

40ms (original) to 3ms (omit the inner loop).

This is still the same distance to fpc (v 3.0.0 with -O4 -Ooloopunroll)

185ms (original) to 12ms (omit the inner loop).

C is 4 times faster here.

Am 14.02.2016 um 12:09 schrieb Michael Van Canneyt:
>
>
> On Sun, 14 Feb 2016, Florian Klaempfl wrote:
>
>> Am 14.02.2016 um 10:45 schrieb Mattias Gaertner:
>>> On Sun, 14 Feb 2016 10:35:22 +0100
>>> Florian Klaempfl  wrote:
>>>
 [...]
 Do you think people will bother? Nobody mentioned to the original
 poster
 so far:
 - that the used FPC is outdated
 - that only -O2 is used instead of -O3 (or -O4 with 3.0.0)
 - that even FPC 2.6.4 has a -Ooloopunroll option which is never
 enabled
 by default and which is worth a try

 I do not know if the points above really effect the example, but it
 tells me enough not to bother either :)
>>>
>>> Maybe documentation helps here.
>>
>> You mean something like the page Size Matters? See the post of Martin
>> Schreiber how much such pages help.
>>
>>>
>>> Is there already a page "pimp my fpc"?
>>
>> In this case even fpc -h would have helped :)
>>
>> But actually, before bothering randomly with command line options, I
>> would just rewrite the inner loop. Something like
>>  for n7 := 0 to 9 do
>>if n1 + n2 + n3 + n4 - n5 - n6 - n7 in [0..9] then
>>  Inc(TicketsCount);
>> should be much better.
>
> To back up Florian with numbers:
>
> No in:
> Found 4816030 tickets. Elapsed time, msec: 171
>
> Using in:
> Found 4816030 tickets. Elapsed time, msec: 23
>
> Michael.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Adrian Veith]

When I change the programm to run inside a procedure (because this would
be the more realistic scenario) the performance decreases about 15% -
160ms in global vs 185ms inside procedure.

program HappyTickets;

uses
  SysUtils, DateUtils;

procedure run;
  var
n1, n2, n3, n4, n5, n6, n7, n8: 0..9;
TicketsCount: int64;
d1, d2: TDateTime;
  begin
TicketsCount := 0;
d1 := Now;
for n1 := 0 to 9 do
  for n2 := 0 to 9 do
for n3 := 0 to 9 do
  for n4 := 0 to 9 do
for n5 := 0 to 9 do
  for n6 := 0 to 9 do
for n7 := 0 to 9 do
  for n8 := 0 to 9 do
if n1 + n2 + n3 + n4 = n5 + n6 + n7 + n8 then
  TicketsCount := TicketsCount + 1; //
Inc(TicketsCount) may be slower in FPC
d2 := Now;
writeln('Found ', TicketsCount, ' tickets. Elapsed time, msec: ',
DateUtils.MilliSecondsBetween(d1, d2));
  end;

begin
run;
end.


Am 13.02.2016 um 11:44 schrieb Serguei TARASSOV:
> Hello,
>
> Here is my little brute-force test for FPC, C and C# compilers.
> http://arbinada.com/main/en/node/1532
>
> The results are not so good with FPC but I cannot use Delphi to
> compare on Linux.
>
> Could anyone make the series on Windows with FPC, Delphi and MS .Net?
> The test of FPC 3.0 and any other comments are welcome.
>
> Regards,
> Serguei
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Adrian Veith]

just for fun: build a node.js from the nim language version which runs
in 204ms (c version in 44ms). So fpc (185ms) is more close to js than to
c in this case

import times

proc run() =
  var TicketsCount = 0
  var d1 = epochTime() * 1000.0
  for n1 in 0 .. 9 :
for n2 in 0 .. 9 :
  for n3 in 0 .. 9 :
for n4 in 0 .. 9 :
  for n5 in 0 .. 9 :
for n6 in 0 .. 9 :
  for n7 in 0 .. 9 :
for n8 in 0 .. 9 :
  if n1 + n2 + n3 + n4 == n5 + n6 + n7 + n8 :
TicketsCount = TicketsCount + 1
  var d2 = epochTime() * 1000.0
  echo "found ", TicketsCount, " in ", d2-d1, "ms"

run()


compile and run with (remove -r to run it immediately):

nim js -d:release -d:nodejs -r happy.nim

for the c version

nim c -d:release -r happy.nim


Am 14.02.2016 um 10:51 schrieb Adrian Veith:
> When I change the programm to run inside a procedure (because this would
> be the more realistic scenario) the performance decreases about 15% -
> 160ms in global vs 185ms inside procedure.
>
> program HappyTickets;
>
> uses
>   SysUtils, DateUtils;
>
> procedure run;
>   var
> n1, n2, n3, n4, n5, n6, n7, n8: 0..9;
> TicketsCount: int64;
> d1, d2: TDateTime;
>   begin
> TicketsCount := 0;
> d1 := Now;
> for n1 := 0 to 9 do
>   for n2 := 0 to 9 do
> for n3 := 0 to 9 do
>   for n4 := 0 to 9 do
> for n5 := 0 to 9 do
>   for n6 := 0 to 9 do
> for n7 := 0 to 9 do
>   for n8 := 0 to 9 do
> if n1 + n2 + n3 + n4 = n5 + n6 + n7 + n8 then
>   TicketsCount := TicketsCount + 1; //
> Inc(TicketsCount) may be slower in FPC
> d2 := Now;
> writeln('Found ', TicketsCount, ' tickets. Elapsed time, msec: ',
> DateUtils.MilliSecondsBetween(d1, d2));
>   end;
>
> begin
> run;
> end.
>
>
> Am 13.02.2016 um 11:44 schrieb Serguei TARASSOV:
>> Hello,
>>
>> Here is my little brute-force test for FPC, C and C# compilers.
>> http://arbinada.com/main/en/node/1532
>>
>> The results are not so good with FPC but I cannot use Delphi to
>> compare on Linux.
>>
>> Could anyone make the series on Windows with FPC, Delphi and MS .Net?
>> The test of FPC 3.0 and any other comments are welcome.
>>
>> Regards,
>> Serguei
>> ___
>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Virtual Constants

[Adrian Veith]

Am 01.03.2013 21:31, schrieb Daniel Gaspary:

The idea is strange. But here it is:

Is possible to have a Class constant with different values in class
descendants ?

Would be something like that:

TA = class
const
 c1: integer; virtual;

 class function GetC1: integer; //returns c1
end;

TB = class(TA)
const
 c1: integer = 1;
end;

TC = class(TA)
const
 c1: integer = 2;
end;
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
currently I use a dirty hack to achieve something like this: I have a 
fixed naming scheme for the classname and encode the virtual const in 
the classname.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] CrossFPC is finally released

[Adrian Veith]

the website was dead for years and still nothing to download, but if I 
am not wrong one of the makers is BERO who did the impressive besen 
javascript in pascal.


Sounds interesting anyway - even if I see Object Pascal as a dead 
language for the future.


Am 29.12.2012 19:41, schrieb Graeme Geldenhuys:

Using Delphi IDE to write code, and FPC to compile or cross-compile to
64-bit Windows, 32-bit Linux etc.


http://www.crossfpc.com/


I believe it comes from the same authors that brought CrossKylix many
years back.


Regards,
   - Graeme -



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC JVM checkout problem

[Adrian Veith]

Are you connected via CABLE or WIRELESS. We have similar errors
connecting to our svn repositories via LTE because of a buggy proxy
server in between.

Am 03.01.2012 15:23, schrieb leledumbo:
 I'm checking out FPC JVM branch, however, in the middle of the process, it
 fails with Decompression of svndiff data failed. The error keeps occuring,
 so I guess it's not a connection problem or something unpredictable. I'm
 using latest TortoiseSVN by the way, which is compiled for SVN 1.7.

 --
 View this message in context: 
 http://free-pascal-general.1045716.n5.nabble.com/FPC-JVM-checkout-problem-tp5116983p5116983.html
 Sent from the Free Pascal - General mailing list archive at Nabble.com.
 ___
 fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: generics question

[Adrian Veith]

But is very strange, that this works:

type
  TTestGenT = class
constructor Create();
class function Test(val: T): string; inline;
  end;


function Blah(const val: Integer): string; inline; //overload;
begin
  Result:= IntToStr(val + 1);
end;

{function Blah(const val: string): string; inline; overload;
begin
  Result:= val + '1';
end;
}

{ TTestGen }

constructor TTestGenT.Create();
begin
end;

class function TTestGenT.Test(val: T): string;
begin
  Result:= Blah(val);
end;

type
  TTestInt = TTestGenInteger;
  //TTestString = TTestGenString;

begin
  writeln(TTestInt.Test(2));
  //writeln(TTestString.Test('2'));
  readln;
end.

T is also not yet known. Why does it not work with overloaded functions
? IMHO this is not consequent.

Cheers,

Adrian.

On 14.05.2011 11:09, leledumbo wrote:
 Err... because at the time, T is not yet known. It would still fail to
 compile even if you don't do any specialization. I guess the compiler does
 type checking while parsing the generic class (and its methods) declaration,
 not while specializing (well... it would still do type checking when
 specializing, but the error would be a little cryptic due to missing exact
 error location).

 IMHO a solution would be to have additional compile-time syntax to check the
 type of T (but this may cause a lot of headache due to inheritance concept).
 Since it's impossible with the current state, the current solution would be
 to declare a procedural type (with T as argument) inside the generic class
 and instead of calling blah directly make it a procedural variable of that
 type as argument of Test (since it's a class function). The caveat is of
 course you have to pass Blah all the time. But unfortunately... it doesn't
 work as well :(

 Here's your modified program (compiled, but just run and see its output):

 {$mode delphi}

 uses
   SysUtils;


 function Blah(const val: Integer): string; inline; overload;
 begin
   Result:= IntToStr(val + 1);
 end;

 function Blah(const val: string): string; inline; overload;
 begin
   Result:= val + '1';
 end;

 type
   TTestGenT = class
   type
 TBlah = function (const val: T): string;
   public
 constructor Create();
 class function Test(val: T; ABlah: TBlah): string; inline;
   end;

 { TTestGen }

 constructor TTestGenT.Create();
 begin
 end;

 class function TTestGenT.Test(val: T; ABlah: TBlah): string;
 begin
   Result:= ABlah(val);
 end;


 type
   TTestInt = TTestGenInteger;
   TTestString = TTestGenString;

 begin
   WriteLn(TTestInt.Test(1,@Blah));
   WriteLn(TTestString.Test('test',@Blah));
 end.

 If I don't overload Blah and pass the correct function for each call, then
 the result is correct. Somebody's gotta file a bug report.

 --
 View this message in context: 
 http://free-pascal-general.1045716.n5.nabble.com/generics-question-tp4389896p4395332.html
 Sent from the Free Pascal - General mailing list archive at Nabble.com.
 ___
 fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] generics question

[Adrian Veith]

Hi,

I try this:

type
  TTestGenT = class
constructor Create();
class function Test(val: T): string; inline;
  end;


function Blah(const val: Integer): string; inline; overload;
begin
  Result:= IntToStr(val + 1);
end;

function Blah(const val: string): string; inline; overload;
begin
  Result:= val + '1';
end;

{ TTestGen }

constructor TTestGenT.Create();
begin
end;

class function TTestGenT.Test(val: T): string;
begin
  Result:= Blah(val);
end;


type
  TTestInt = TTestGenInteger;
  TTestString = TTestGenString; 

and get an error: can't determin which overloaded function Blah to use.

It would be nice if this could work. It would be a way to inject inline
functions into a generic class - avoiding virtual functions.

BTW. If I only have one Blah and only one corresponding specialization
it works.

Cheers,

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] code optimization

[Adrian Veith]

On 23.09.2010 17:03, Jonas Maebe wrote:

 On 23 Sep 2010, at 16:59, Adrian Veith wrote:

 I analyzed your code - I think the problem is the array element address
 calculation of the fpc compiler. You have a lot of code like
 Bar[MinValley] etc. The delphi compile uses the lea assembler code for
 this, whereas fpc calculates the address of one element with imul  which
 is much slower.

 Please see the last paragraph of
 http://lists.freepascal.org/lists/fpc-pascal/2010-September/026510.html

 Anyway you could speed up your code significantly if you
 help the compiler by reducing the address calculations with the help of
 pointers like this:

 It may help a lot, but only because it will reduce register pressure,
 not because the multiplications are gone.

It reduces the total number of multiplications about 70% - I gave the
code to one of my guys and he changed the code using pointers to
elements wherever possible. This are the differences:

fpc - original code: 17s
fpc - pointer to elements: 12 s
delphi - original code: 9s

tested on a AMD notebook.

We haven't tested the new code with delphi yet, but the benefits should
be marginal compared to fpc.

As a conclusion one can say, that fpc's array arithmetic is suboptimal.

Cheers,

Adrian
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] code optimization

[Adrian Veith]

On 24.09.2010 14:35, Jonas Maebe wrote:

 On 24 Sep 2010, at 11:48, Adrian Veith wrote:

 Changing to pointers reduces the amount of multiplications for accessing
 the nth element in an array - if you compare the delphi code to th fpc
 code on assembler base, this is the main difference in both generated
 codes.

 Did you actually try replacing only the multiplications with lea's in
 the assembler code generated by FPC (one lea to multiply by 5 and then
 the times 4 during the load/store)? I did before posting my initial
 reply because it also seemed to be the most logical explanation to me.
 It turned out to be a red herring:

 With imull $20:
 # iterations: 26662054
 no solution found
 runtime:10.75s

 With lea (%reg,%reg,4),%reg followed by movl (%xxx,%reg,4),%yyy
 (not just for mov, but for every single memory expression that depends
 on an imull $20):
 # iterations: 26662054
 no solution found
 runtime:10.06s

 Kylix 3 (~ Delphi 6.5):
 # iterations: 26662054
 no solution found
 runtime: 6.65s

I must confess - I did not - but I will because that's interesting.
Maybe this will behave different on different CPUs, because the picture
is very different on my I7 compared to the older AMD.

fpc:

on i7:

orig: 9s
opt1: 7s = -22%
opt2: 6s = -14% total -33%

on AMD:

orig: 17s
opt1: 12s = -30%
opt2: 7s = -41% total -58%

so the older AMD suffers much more from the not optimized code than the
newer i7. At the end they are almost on the same speed.

same code with delphi (5):

on i7:

orig:  6s
opt1: 5.5s = -8%
opt2: 4.5s = -18% total  -25%

on AMD:

orig:  9s
opt1: 8s = -11%
opt2: 6s = -25% total -33%

Strange picture (I did all tests 3 times and took the medium).


 Register allocation is on a comparable level for both versions.

 Delphi keeps the Bar pointer in a register, while FPC spills it to
 the stack. Because Bar is used in most of the most-executed
 statements, this has a huge impact.


you got me ;-)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] code optimization

[Adrian Veith]

 Hi Stefan,

I analyzed your code - I think the problem is the array element address
calculation of the fpc compiler. You have a lot of code like
Bar[MinValley] etc. The delphi compile uses the lea assembler code for
this, whereas fpc calculates the address of one element with imul  which
is much slower. Anyway you could speed up your code significantly if you
help the compiler by reducing the address calculations with the help of
pointers like this:

MinValley:= ...
PBarMinValley:= @Bar[MinValley]

and replace any following Bar[MinValley].FOO with PBarMinValley.FOO

and the same with any other index.

This will speed up the code for Delphi and fpc as well, because both
compilers are not smart enough the see the unnecessary repeated address
calculations.

Cheers,

Adrian.



On 22.09.2010 16:08, stefan...@web.de wrote:
 Hi Adrian,

 it is a scientific application that I have, which has about 2000 lines of 
 code. By extracting the most time consuming routine I now have 360 lines of 
 code. With this code I get the following runtime results:

 optimized FPC pascal   *** is  58% SLOWER  ***  than optimized DELPHI 7
 unoptimized FPC pascal *** is 60% SLOWER *** than optimized DELPHI 7
 unoptimized Delphi 7  *** is 62% SLOWER *** than optimized DELPHI 7

 Thus it looks like FPC pascal is doing very bad on optimizing the code. 
 I agree, that I also have seen examples where FPC pascal code is about 10% 
 faster than Delphi code. 
 So why does FPC pascal fail on this code?

 I have included the code below. I compiled it with Delphi 7 , optimization 
 on, range checking off, stack checking off, I/O checking off.
 For FPC pascal I used the compiler options:  -Mdelphi -O3 -OpPENTIUMM -Cfsse2 
 -Cr- -Co- -CO- -Ci-
 The FPC compiler version is 2.4.0, I run under Windows XP.

 any suggestions?
 Stefan


 -Ursprüngliche Nachricht-
 Von: Adrian Veith adr...@veith-system.de
 Gesendet: 22.09.2010 08:08:45
 An: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org
 Betreff: Re: [fpc-pascal] code optimization

 Hi Stefan,

 is this a benchmark program or a complex program you are talking about.
 If it is a benchmark, then it would be interesting to see the code,
 because from my experience I doubt that Delphi produces better code than
 fpc (in general it is the other way round). If it is a complex program,
 then you need to analyze carefully which part of the program consumes
 the most time and why. A number of 50% is in anyway unrealistic (this is
 something you get if you compare inlined code against uninlined) ,
 because the differences you get from code optimization are in a range
 from +/-10% normally - unless you have found a real performance
 bottleneck. And sometimes (most of) it is only an unoptimized library code.

 Adrian.

 Here is the code (I was not able to cut it down in size further):

 program P;

 {$APPTYPE CONSOLE}


 uses
  Math,
  SysUtils,
  Windows;


 type
  TRectangle   =  object
  width   : Integer;
  Area: Int64;
  NextUnusedRectangle: Integer;
  end;

  TRectangleArray  = Array of TRectangle;


 var
  UnsortedRectangle: TRectangleArray;
  NumRectangles: Integer;
  BoundingBox  : TRectangle;



 function GapAlgorithm: Boolean;

  type
  TBarEntry = record
  Height: Integer;
  Width : Integer;
  Start : Integer;
  Next  : Integer;
  Prev  : Integer;
  end;

  var
  SolutionFound: Boolean;
  Bar  : Array of TBarEntry;
  FreeBarEntry : Array of Integer;
  NumFreeBarEntries: Integer;
  NumIterations: Int64;


  procedure  ExtendPartialSolution (NumPlacedRectangles, FirstUnusedRectangle: 
 Integer);
  type
  TBarCase = (BarCase1, BarCase2, BarCase3, BarCase4, BarCase5, BarCase6);

  var
  i, MinValley, MinValleyWidth: Integer;
  PrevBar, NextBar: Integer;
  RectWidth   : Integer;
  BarCase : TBarCase;
  NextBarWidth: Integer;
  NewEntry, NewEntry2 : Integer;
  MinValleyArea   : Int64;
  MinValleyHeight : Integer;
  TotalAreaOfFittingRectangles: Int64;
  CurrentRectangle: Integer;
  PreviousRectangle   : Integer;
  OldFirstUnusedRectangle : Integer;
  OldPrevNextRectangle: Integer;

  begin

  if NumPlacedRectangles = NumRectangles
  then begin
  writeln ('Solution found');
  SolutionFound := true;
  exit;
  end
  else begin
  inc (NumIterations);

  MinValleyWidth := BoundingBox.Width+1;
  PrevBar := 1;
  i   := Bar[PrevBar].Next;
  NextBar := Bar[i].Next;
  while NextBar  0 do begin
  if (Bar[i].Width MinValleyWidth) and
  (Bar[PrevBar].Height  Bar[i].Height) and
  (Bar[NextBar].Height  Bar[i].Height)
  then begin
  MinValleyWidth  := Bar[i].Width;
  MinValley   := i;
  end;
  PrevBar := i;
  i   := NextBar;
  NextBar := Bar[i].Next;
  end;

  MinValleyHeight := min(Bar[Bar[MinValley].Prev].Height, 
 Bar[Bar[MinValley].Next].Height)- Bar[MinValley].Height;
  MinValleyArea   := int64(MinValleyHeight

Re: [fpc-pascal] code optimization

[Adrian Veith]

 Hi Stefan,

is this a benchmark program or a complex program you are talking about.
If it is a benchmark, then it would be interesting to see the code,
because from my experience I doubt that Delphi produces better code than
fpc (in general it is the other way round). If it is a complex program,
then you need to analyze carefully which part of the program consumes
the most time and why. A number of 50% is in anyway unrealistic (this is
something you get if you compare inlined code against uninlined) ,
because the differences you get from code optimization are in a range
from +/-10% normally - unless you have found a real performance
bottleneck. And sometimes (most of) it is only an unoptimized library code.

Adrian.

On 21.09.2010 16:39, stefan...@web.de wrote:
 Hi all,
  
 I am currently trying to get the fastest possible code from fpc on a  modern 
 CPU (Intel Xeon) under Windows XP. I use the compiler options:
  
 fpc -Mdelphi -O3 -OpPENTIUMM -Cfsse2 -Cr- -Co- -CO- -Ci- myprogram.dpr
  
 Are there any better settings I should use? Compiling exactly the same  
 program with Delphi7 results in 50% faster code. I understand that fpc  does 
 not support the most recent CPUs, but neither does DELPHI 7. So  what 
 optimizations are done by Delphi 7 that are not done by fpc and why  is this 
 the case?
  
  Stefan
 ___
 Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
 Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02
 ___
 fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpGUI Toolkit on WinCE

[Adrian Veith]

Paul,

yes I agree with you, that fpGUI is very nice for embedded GUI systems -
and I think it has potential for more. The next thing I will look at, is
why it draws a frame around labels etc. in WinCE - do you have the same
issue ? Should be a minor problem.

Adrian.

Am 16.03.2010 17:59, schrieb Paul Breneman:
 Adrian,

 Thank you *very* much for getting fpGUI working better on WinCE.  A
 few months ago I spent quite a bit of time doing the initial work but
 as you've seen in the comments I only had a Motorola Symbol MC1000
 barcode scanner to work with and that just has a 240x240 monochrome
 display.

 I hope to get a better WinCE system like this to use with fpGUI:
   http://www.cubloc.com/product/06_02.php

 I've been using fpGUI on this 7 Linux touchscreen:
 http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390

 If fpGUI gets DirectFB support that should help on the low-powered
 Linux systems.

 When I did all my work a few months ago I hoped someone else would
 come along to take it further so I am *very* pleased to see your
 messages today.  It appears it is going to get even easier to show how
 FreePascal and fpGUI provide simple entry to embedded GUI systems.  :)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpGUI Toolkit on WinCE

[Adrian Veith]

Am 16.03.2010 16:11, schrieb Graeme Geldenhuys:
 On 16 March 2010 15:03, Adrian Veith adr...@veith-system.de wrote:
   
 
 Now my second solution works:
 

 Thank you very much. I'll take a look at the code and test on my
 Garmin in the next day or two.
   

yes please,  and if it works please fix the code on git. I will also
look at the issue with frames around labels etc

I have read, that you mentioned to think about AggPas as a target for
fpGUI.  For me it would be very interesting to combine both (I fixed
already the code of AggPas to compile for ARM, but there is a problem,
that the demo applications don't start - I guess its a missing system
call).

I would like to have a small widget set (pure pascal, so that it can be
easy ported to all the platforms fpc can target) with very mighty
drawing capabilities, which can be styled like HTML and CSS.

For example: why do we need widgets like Panel and Button and Bitmap
Button (if I look at my Delphi installation, which is still my main
developing environment - I have about 50 different Button widgets and
about 20 Panels). In fact all are rectangular areas which are drawn with
different styles and borders, some are transparent, some contain images,
some are for toolbars, some can contain styled text. If I look at HTML
you have a div with different styles and depending if you have events
attached to it or not, it behaves like a button or a panel. That kind of
simplicity and flexibility is what I want - separate code from layout
and design, but with mighty design possibilities.

That's why I look at fpGUI. fpGUI has very straight forward design and
is easy to change and runs on all platforms. If we bring the amazing
drawing capabilities of AggPas to fpGUI and have a (to be written) style
engine a la CSS - et voila we could have a little gemstone, which is far
beyond existing frameworks - ok. I am dreaming now ;-).

Adrian.






___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpGUI Toolkit on WinCE

[Adrian Veith]

Am 15.03.2010 16:20, schrieb Graeme Geldenhuys:

 WinCE is experimental, so expect some issue. But that is no excuse. ;-)  I
 can duplicate the slow down on my Garmin iQue M5, so will try and resolve
 the issue before the final v0.7 release. Thanks for bringing this to my
 attention.
   

Ok - I got another issue with reading and painting bitmaps. The original
code throws an error when reading a bitmap file in ReadImage_BMP for 32
bit depths images.

I change the code in the loop:

while (p)  (pdata) do
begin
  //pcol^ := Plongword(p)^; -- changed
  pcol^ := (LongWord(p[3]) shl 24) + (LongWord(p[2]) shl 16) +
(LongWord(p[1]) shl 8) + LongWord(p[0]);
  //Writeln('color: ',HexStr(pcol^,8));
  Inc(pcol);
  //Inc(Plongword(p)); -- changed
  inc(p, 4);
  Inc(pixelcnt);
end;

this reads the bitmap so far, but there is still a problem with painting
bitmaps in WinCE. It seems, that memory layout is different or something
like that, because the bitmaps look scrambled and have different colors.
I haven't found the solution for this yet.

BTW. is there another place to discuss fpGUI related problems ?

cheers,

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpGUI Toolkit on WinCE

[Adrian Veith]

Am 16.03.2010 10:45, schrieb Matt Emson:
 Adrian Veith wrote:
 ..the bitmaps look scrambled and have different colors.
 I haven't found the solution for this yet.
 Ignore that last message. It seems WinCE is only ever little endian.
 So it is probably more to do with DIB vs general device dependent
 Bitmaps. Have you tried converting the bitmap in question to a DIB?


I am so far that I found that the procedure SetDIBits is not supported
on WinCE (that's why it is commented out in the WinCE build). So the
Bitmap is not initialized with the data loaded from the file and shows
random crap.

I have to find  way how to initialize the bitmap without SetDIBits (and
in a efficient way).

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpGUI Toolkit on WinCE

[Adrian Veith]

Am 16.03.2010 11:22, schrieb Adrian Veith:
 Am 16.03.2010 10:45, schrieb Matt Emson:
   
 Adrian Veith wrote:
 
 ..the bitmaps look scrambled and have different colors.
 I haven't found the solution for this yet.
   
 Ignore that last message. It seems WinCE is only ever little endian.
 So it is probably more to do with DIB vs general device dependent
 Bitmaps. Have you tried converting the bitmap in question to a DIB?

 
 I am so far that I found that the procedure SetDIBits is not supported
 on WinCE (that's why it is commented out in the WinCE build). So the
 Bitmap is not initialized with the data loaded from the file and shows
 random crap.

 I have to find  way how to initialize the bitmap without SetDIBits (and
 in a efficient way).

   

My solution for the moment is:

{$IFDEF wince}
procedure WinCESetInitBMP(BMP: HBITMAP; awidth, aheight, depth: Integer;
aimgdata: Pointer);
var
  hdcSrc, hdcDest: HDC;
  hbmSrc: HBITMAP;
  bm: BITMAP;
  data, p, pend: pByte;
begin
  hdcSrc:= CreateCompatibleDC(0);
  hdcDest:= CreateCompatibleDC(0);
  hbmSrc:= CreateBitmap(awidth, aheight, 1, depth, nil);
  if depth = 32 then
SetBitmapBits(hbmSrc, (awidth * aheight) *4, aimgdata)
  else
SetBitmapBits(hbmSrc, (awidth * aheight) div 8, aimgdata);
  SelectObject(hdcSrc, hbmSrc);
  SelectObject(hdcDest, BMP);
  BitBlt(hdcDest, 0, 0, awidth, aheight, hdcSrc, 0, 0, SRCCOPY);
  DeleteDC(hdcSrc);
  DeleteDC(hdcDest);
  DeleteObject(hbmSrc);
end;
{$ENDIF}


and change the code in TfpgGDIImage.DoInitImage to

  {$IFNDEF wince}
  SetDIBits(wapplication.display, FBMPHandle, 0, aheight, aimgdata, bi,
DIB_RGB_COLORS);
  {$else}
  WinCESetInitBMP(FBMPHandle, awidth, aheight, bi.bmiHeader.biBitCount,
aimgdata);
  {$ENDIF}

and in TfpgGDIImage.DoInitImageMask to:

  {$IFNDEF wince}
  SetDIBits(wapplication.display, FMaskHandle, 0, aheight, aimgdata,
pbi^, DIB_RGB_COLORS);
  {$ELSE}
  WinCESetInitBMP(FMaskHandle, awidth, aheight, bi.bmiHeader.biBitCount,
aimgdata);
  {$ENDIF}

now bitmaps are loaded an painted correctly, but still the stdimg.xxx
(e.g. stdimg.close) are not painted correctly 
- I guess there is a problem with the masking.

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpGUI Toolkit on WinCE

[Adrian Veith]

Am 16.03.2010 13:17, schrieb Adrian Veith:
 Am 16.03.2010 11:22, schrieb Adrian Veith:
   
 Am 16.03.2010 10:45, schrieb Matt Emson:
   
 
 Adrian Veith wrote:
 
   
 ..the bitmaps look scrambled and have different colors.
 I haven't found the solution for this yet.
   
 
 Ignore that last message. It seems WinCE is only ever little endian.
 So it is probably more to do with DIB vs general device dependent
 Bitmaps. Have you tried converting the bitmap in question to a DIB?

 
   
 I am so far that I found that the procedure SetDIBits is not supported
 on WinCE (that's why it is commented out in the WinCE build). So the
 Bitmap is not initialized with the data loaded from the file and shows
 random crap.

 I have to find  way how to initialize the bitmap without SetDIBits (and
 in a efficient way).

 
Now my second solution works:

{$IFDEF wince}
procedure WinCESetDibBits(BMP: HBITMAP; awidth, aheight: Integer;
aimgdata: Pointer; var bi: TBitmapInfo);
var
  hdcSrc, hdcDest: HDC;
  hbmSrc: HBITMAP;
  bm: BITMAP;
begin
  hdcDest:= CreateCompatibleDC(0);
  SelectObject(hdcDest, BMP);
  if bi.bmiHeader.biBitCount = 1 then begin
SetDIBitsToDevice(hdcDest, 0, 0, awidth, aheight, 0, 0, 0, aheight,
aimgdata, bi, DIB_RGB_COLORS);
  end else begin
hdcSrc:= CreateCompatibleDC(0);
hbmSrc:= CreateBitmap(awidth, aheight, 1, bi.bmiHeader.biBitCount,
aimgdata);
SelectObject(hdcSrc, hbmSrc);
BitBlt(hdcDest, 0, 0, awidth, aheight, hdcSrc, 0, 0, SRCCOPY);
DeleteDC(hdcSrc);
DeleteObject(hbmSrc);
  end;
  DeleteDC(hdcDest);
end;

{$ENDIF}

and the change for TfpgGDIImage.DoInitImage:

  {$IFNDEF wince}
  SetDIBits(wapplication.display, FBMPHandle, 0, aheight, aimgdata, bi,
DIB_RGB_COLORS);
  {$else}
  WinCESetDibBits(FBMPHandle, awidth, aheight, aimgdata, bi);
  {$ENDIF}


and for TfpgGDIImage.DoInitImageMask

  {$IFNDEF wince}
  SetDIBits(wapplication.display, FMaskHandle, 0, aheight, aimgdata,
pbi^, DIB_RGB_COLORS);
  {$ELSE}
  WinCESetDibBits(FMaskHandle, awidth, aheight, aimgdata, pbi^);
  {$ENDIF}

with the patch for loading 32bit bitmaps posted before you can call
fpgCreateStandardImages; in fpg_main:

  {--$IFNDEF wince}
  fpgCreateStandardImages;
  (*  causes EBusError on Symbol MC1000 WinCE 4.2
  see: http://wiki.freepascal.org/Windows_CE_Development_Notes
  Using ARM processors, some times you may get a EBusError exception with
  a message about misaligned data access.  The following section explains
  what this is and how to fix it. - fixed
  *)
  {--$ENDIF}

cheers Adrian.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] fpGUI Toolkit on WinCE

[Adrian Veith]

Am 09.03.2010 14:16, schrieb Graeme Geldenhuys:
 fpGUI v0.7-rc1 is available
 ---
   
Hi, this is the first time I looked at fpGUI. Very nice work !

I tried to cross compile some examples for WinCE and it worked so far -
looks like my search is over and I found a nice little GUI framework for
that platform. I was not satisfied with LCL (much too big), KOL (too
weird) and I even thought of switching to c++ and QT, but QT apps take
ages to load on a phone.

One thing I found is, that when a fpGUI application is running on my
WinCE phone (even when it is in the background), the phone will slow
down dramatically. I guess there is an event loop which is too busy -
any idea ?

cheers, Adrian.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpGUI Toolkit v0.7-rc1 for FPC 2.4

[Adrian Veith]

Am 09.03.2010 14:16, schrieb Graeme Geldenhuys:
 fpGUI v0.7-rc1 is available
   

when compiling uidesigner with actual fpc from svn it fails with
duplicate identifier unitname in vfdfile.pas. It seems to be a name
clash with the new class procedure unitname in TObject. I don't know why
fpc raises an error - is there a rule, that a local identifier cannot
have the same name as a class procedure ? (makes no real sense, because
a class procedure can be accessed via a full qualified name). Anyway if
you change unitname in NewFileSkeleton to aunitname it compiles.

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpGUI Toolkit v0.7-rc1 for FPC 2.4

[Adrian Veith]

Am 15.03.2010 16:23, schrieb Jonas Maebe:

 On 15 Mar 2010, at 16:17, Adrian Veith wrote:

 when compiling uidesigner with actual fpc from svn it fails with
 duplicate identifier unitname in vfdfile.pas. It seems to be a name
 clash with the new class procedure unitname in TObject.

 http://wiki.freepascal.org/User_Changes_Trunk#TObject_class_declaration

 I don't know why
 fpc raises an error - is there a rule, that a local identifier cannot
 have the same name as a class procedure ? (makes no real sense, because
 a class procedure can be accessed via a full qualified name).

 It makes sense because that way you can accidentally hide an
 identifier, which can result in all sorts of hard to debug behaviour.
 It's one of the core differences between objfpc and Delphi mode.


If it makes sense or not - I get the same error in delphi mode.

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpGUI Toolkit v0.7-rc1 for FPC 2.4

[Adrian Veith]

Am 15.03.2010 16:38, schrieb Adrian Veith:
 If it makes sense or not - I get the same error in delphi mode.
   

my error - forget it

Adrian

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Servlet server for Fpc apps

[Adrian Veith]

Bee schrieb:
 Using haxe for web applications is very effective, because you use the
 same language for back-end and front-end. With pascal4neko you can use
 your existing pascal code or use pascal for low level tasks.
 

 Have you heard about ExtPascal? It wraps ExtJS library into Pascal
 unit so you can use ExtJS as if you're using V/LCL components. Powtils
 also has PasJS which could compile your pascal code into JS, though it
 only supports very basic of pascal language. Unfortunately, both
 project seems to be stalled. :(

 Have you heard about Morfik? I think this one is better than haXe
 since it directly produces native code from *pascal* code, both for
 server and client side.
   

I have seen ExtPascal and looked at the ExtJS library which seemed
interesting, but if I am right the license is not LGPL or something
similar. Same with Morfik interesting, but expensive and not open. Haxe
is opensource and, if you are used to pascal like me since 30 years now,
as a language not so far away (at least from all C - styled languages
the most comfortable in my point of view).

I have never heard of Powtils but will take a look at it.

Thanks,

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Servlet server for Fpc apps

[Adrian Veith]

Eduardo Morras schrieb:
 I want to ask (and know) if i can use apache-tomcat to serve servlets
 developed with freepascal. If not, is there a similar server for fpc?
 Note that i want/need servlet like in java and other languages, not a
 propetary format or cgi or anyother.



Maybe you want to look at www.haxe.org and
http://code.google.com/p/pascal4neko/

I am using the new haxe language to build neko modules, which are
running in the visual synapse webserver written in pascal. At the
pascal4neko website is a modified version of the webserver, which is
able to run neko module in a compatible way of the mod_neko apache
module described here: http://haxe.org/doc and here
http://nekovm.org/doc/mod_neko

Using haxe for web applications is very effective, because you use the
same language for back-end and front-end. With pascal4neko you can use
your existing pascal code or use pascal for low level tasks.

Hope this helps.

Cheers, Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Boehm GC

[Adrian Veith]

Hi bd,

than I guess, this is why you look at the boehm gc (that's why I was
looking at it). I have put some haxe/neko pascal related code at
http://code.google.com/p/pascal4neko/
The code is only tested with delphi, but should work with fpc as well.
There is no memory manager for boehm, but some code which shows how to
handle the gc for objects and interfaces. If you have any questions, you
can contact me directly, because this a bit OT for this list.

Cheers,
Adrian.

ritchie turner schrieb:
 Hi Adrian,

 Guilty!

 bd.



 On Wed, 2009-03-18 at 17:03 +0100, Adrian Veith wrote:
   
 ritchie turner schrieb:
 
 Thanks all, I've got something to go on now.

 bd.
   
   
 bye the way - are you black dog from the haxe list ?

 Cheers,

 Adrian.
 ___
 fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-pascal
 

 ___
 fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-pascal
   
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Boehm GC

[Adrian Veith]

ritchie turner schrieb:
 I'm new to fpc and pascal, i.e. I've never done a project in it, but
 i've been following the lists for a while and dabbling.

 I like using a garbage collector and I know you can replace the memory
 manager in fpc so i guess it's probably trivial to replace the standard
 with boehm. Wondered if anyone's done it and how they got on, and if
 there are issues with the idea.

   
It is quite easy to use the boehm gc inside delphi. I did some test a
few years ago. Since the fpc memory manager interface is very close to
delphi, it should be no problem to port the boehm gc to fpc.

the major disadvantage I see, is, that all the existing code is not gc
aware - you loose the benefits of a gc.

cheers,

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Boehm GC

[Adrian Veith]

ritchie turner schrieb:
 Thanks all, I've got something to go on now.

 bd.
   
bye the way - are you black dog from the haxe list ?

Cheers,

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Creating FPC enabled websites

[Adrian Veith]

Hello Francisco,

I use the following for my applications:

- synapse with visualsynapse ( I modified visualsynapse to perform
Keep-Alive http connections)
- HaXe/Neko for remoting (www.haxe.org) - very easy to use ! same
language for client/ server/ flash

I have created a pascal framework for embedding neko modules in pascal
applications, which can be found at http://code.google.com/p/pascal4neko/
the modified version of visualsynapse can also be found there.

Cheers,

Adrian.


Francisco Reyes schrieb:
 Any recommendations on which library to use to create web enabled FPC
 apps?

 Have found a few libraries and wonder if anyone has had good success
 with any of these or otheres.

 So far I found
 embeddable webserver
 http://www.eilers.net/pascal
 Site doesn't have much info


 Synapse
 http://www.ararat.cz/synapse/doku.php
 Seems very low level.

 Powtils
 http://z505.com/powtils/idx.shtml
 This one has a number of examples and seems the most promissing.


 ___
 fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: crossplatform networking

[Adrian Veith]

Paul Nicholls schrieb:
 Bee bisma-96w4lwiwc1nexsysy73...@public.gmane.org
 mailto:bisma-96w4lwiwc1nexsysy73...@public.gmane.org wrote in message
 news:49817e1f.8080...@brawijaya.ac.id...
  Hi all,
 
  I need to build some crossplatform networking applications. It'd be
  UDP-based. It should be able to support at least 3 mainstream OSes:
  Windows, Linux, and Mac. It also should be able to run on 64bit
  environment (at any OSes).
 
  Any suggestion what is the best crossplatform networking framework for
  FPC? At least able to run on the above 3 OSes. Indy? Synapse? lNet? And
  for what reasons?
 
  I don't need GUI/widget support as it would be only server-to-server
  communication and mostly run as daemon/service.
 
  TIA.
 
  -Bee-

 I would suggest Synapse, as that works under Windows, Linux and I
 think also
 Mac :-)
 I'm not sure about 64bit OSes though - probably.


I would vote for it as well - and it works for WinCE (but you need my
WinCE socket units, which are not official part of synapse, since Lukas
wants to use the fpc socket for ARM based targets as well).

Cheers,

Adian.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Built in Query language (or abuse)

[Adrian Veith]

L schrieb:

A creative idea:

--Another idea--
Remember the file of Record innovation in pascal?

Table of Record...

A file of record allows one to remain strongly typed. What about a 
DatabaseTable of Record.


var
 // F: File Of DataRec;
 DB: Table of DataRec; // aka a RelVar



We do something similar with our dbGonzales Database engine with 
standard pascal code. The tables are typed and have coresponding 
interface classes in oo-pascal. A table can hold any of the subclasses 
of its baseclass. If you access a record you get automatically the 
corresponding interface class and can use its methods.


A small demo to visualize this is here 
http://www.db-gonzales.de/download/GDemo.zip. The demo draws objects 
(circle, line, rectangle, ellips) stored in database and animates them 
(or adds new). If you start more instances of the demo, you can see what 
the other instance is doing with the objects.


If you look at the source of the demo, you can see, that it is also 
possible to write queries with pascal notation, which are already 
checked at compile time - but I must admit, that this a little bit clumsy.


   qy:= TGdfFilteredTableOp.Create(tb, [],
   TfComp.New(tb.BaseClass.FieldByName('ParentID'), 
TvVariant.Val(Null), [cvEQ]));


could also be written as:

   qy:= TGdfFilteredTableOp.Create(tb, [],
   TfComp.New(TPaintObject(tb.BaseInterfaceClass).ParentID, 
TvVariant.Val(Null), [cvEQ]));


and is the same as:

   qy:= TGdfFilteredTableOp.Create(tb, [],
   'ParentID is null' );

which is better readable.


So my opinion is - we don't need to change pascal to achieve things like 
that, it's already in the language


Cheers, Adrian.

p.s: The information on the webpage about the database is outdated - i 
haven't found the time to write a documentation.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal Coding style

[Adrian Veith]

Graeme Geldenhuys schrieb:

On 21/01/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote:
  

No, there isn't. I follow Borland coding style, but some others don't.
You cannot force everyone to use the same style. And you should not.



That's why we need a editor that supports 'elastic tab stops'.  ;-)
It's a brilliant idea, but might make your processor work a bit harder
(but considering that most CPU's sit at idle 90% of their life, that's
not really an issue).

For more information on 'elastic tab stops' see the following website.
He has a simple java demo editor showing it in action.
  http://nickgravgaard.com/elastictabstops/

  


I tried the example in action and its awefull.

I tried this:

if x = 1 then beginTAB// my comment on ifs
TABy:= 2;TAB//yes y gets 2
end;

this was NOT what I wanted - to make it better i changed to:


if TABx = 1 then beginTAB// my comment on ifs
TABy:= 2;TAB//yes y gets 2
end;

not nice eighter - I am to stupid for those smart elastic tabs.

cheers,

Adrian.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] cdecl or stdcall on WinCE for ARM

[Adrian Veith]

Florian Klaempfl schrieb:

Adrian Veith schrieb:
  

Hi,

what is the right calling convention for using system libraries on wince
for ARM ?

I wrote a pascal wrapper for a system dll and used stdcall for the
calling convention - and the program worked.
I changed to cdecl - and the program works as well.

In my opinion the program should have crashed on one of the two.

Now I am puzzled.




Both are equal on arm, you could even use register and things won't change.
  



I have guessed something like that - otherwise it would be impossible.

Thanks,

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] cdecl or stdcall on WinCE for ARM

[Adrian Veith]

Hi,

what is the right calling convention for using system libraries on wince 
for ARM ?


I wrote a pascal wrapper for a system dll and used stdcall for the 
calling convention - and the program worked.

I changed to cdecl - and the program works as well.

In my opinion the program should have crashed on one of the two.

Now I am puzzled.

Cheers,

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] D language and Object Pascal

[Adrian Veith]

Jilani Khaldi schrieb:

Hi All,
just curious about the D language 
(http://www.digitalmars.com/d/index.html), I read some articles on the 
site, downloaded the compiler... and wrote some little examples. Well, 
many of the things that the author presented as new and hot features 
are already present in Turbo Pascal or in Delphi for a decade (objects 
by reference, strings...).

oh D has more interesting things for a compiled language:
 - dynamic closures or delegates to nested functions
 - lazy evaluation
 - template mixins
 - garbage collection

I am not sure if all these things are really useful - but it looks 
interesting. especially the delegates stuff.


What I don't understand is, that they haven't changed the idiotic switch 
statement.


cheers,

Adrian.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] FPU Configuration inside a library

[Adrian Veith]

Hi,

i posted this already under a differnt subject, but didn't get a feedback.

A .dll written in fpc changes the configuration of the FPU (FPUCW). This 
might cause a strange behavior inside the loading program.


If the loading program allows division by zero (1.0 / 0.0), it will 
crash after the .dll written in freepascal is loaded. What is really bad 
with this is, that the crash occurs at total different place and time 
inside the loading program (very hard to find).


The initialization of fpc should only change the FPU configuration 
inside a program not inside a library.


IMHO same should be true with other settings like LOCALE settings.

Cheers,

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] FPUCW in a .dll

[Adrian Veith]

Hi,

a .dll written in fpc changes the FPUCW when it is loaded. I think, that 
this is the wrong behavior, because it should be the task of the loading 
program to setup the FPUCW. As far as I can see, a Delphi .dll doesn't 
change the FPUCW.


Cheers,

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Compiler Crash

[Adrian Veith]

Hello,

my fpc (current version from svn ) compiler crashes, when I compile a 
procedure like this:


procedure Crash;
var
 c0: function: pointer; cdecl;
 c1: function: integer; cdecl;
 m: HMODULE;
begin
 m:= LoadLibrary('blah.dll');
 c0:= GetProcAddress(m, 'c0');
 c1:= c0();
 c1;
end;

btw. is there a known problem when using cdecl ?

cheers,

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Problem with dynamic libraries

[Adrian Veith]

no - that was not the problem. I have my linux running in a coLinux 
session and it seems that the linker fails, when the file is in a 
windows drive, even as root. other programms don't have problems to read 
or write to this drive.


but there is still a strange problem with the dynamic library:

the code compiles with fpc fails, when one of the units have some 
initialization code. When I move this code to an extra procedure and 
call it later it works.


Is there a difference, when the initialization code of an dll is called 
between delphi and fpc ?


thanks,

Adrian.

Leonardo M. Ramé schrieb:

Replace procedure HalloWelt; with

procedure HalloWelt; cdecl; 

  

procedure HalloWelt;
begin
end;





Leonardo M. Ramé
http://leonardorame.blogspot.com


   

Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

  

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Problem with dynamic libraries

[Adrian Veith]

Hi,

i have written a dll (pasForNeko) in delphi / windows which can be 
called from the haxe/neko language, in order to use existing object 
pascal code from this language. now I try to port this to fpc and linux 
and run into some problems:


1. I can't compile even the simplest library from fpc (i use 2.1.4) in linux

library testdll; 


uses
 SysUtils,
 Classes;

procedure HalloWelt;
begin
end;

exports
 HalloWelt;

begin
end.

causes an: Error  while linking
in linux when compiled with

fpc testdll.pas

in windows it works with fpc

2. the delphi/windows version of the pasForNeko works fine. the same 
code compiled with fpc in windows fails to run with an exception.


Are there known pitfalls when compiling dlls in fpc which are called 
from applications written in C ?



Thanx,

Adrian.




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] 0.9.20 released

[Adrian Veith]

Hello,

I did a plain install from scratch (the 
Lazarus-0.9.20-fpc-2.0.4-20061105-win32.exe) and wanted to rebuild 
Lazarus. The rebuild with the preinstalled fpc-2.0.4 stops with an error:


Compiling svn2revisioninc.pas
Linking .\svn2revisioninc.exe
.\svn2revisioninc.o(.data+0x14): In function `FINDREVISION':
svn2revisioninc.pas:150: undefined reference to `DEBUGINFO_WINDOWS'
C:\lazarus.0.9.20\fpc\2.0.4\units\i386-win32\rtl\libpsystem.a(system0s884.o)(.text+0x68): 
In function `SYSTEM_init':

system.pp:1133: undefined reference to `_stkptr'
Error: Error while linking

Next problem:

Because I prefer the fpc2.1.1 compiler i changed the setup to use my 
fpc-2.1.1. (current svn snapshot). I did a make clean all Everything 
builds well, but when i try to start lazarus it throws an exception: 
Error reading SplashForm.Left. Unknown property Left


The same errror is thrown, when you install the 
Lazarus-0.9.21-fpc-2.1.1-20061108-win32.exe and start lazarus.


Seems like the 2.1.1 compiler has problems with RTTI.

I know, the daily snapshots are not tested, but i think its nice to use 
lazarus, with the 2.1.1 compiler.


cheers,

Adrian.




Mattias Gaertner schrieb:

The Lazarus team is glad to announce the 0.9.20 release. This release
is based on fpc 2.0.4.

This release can be downloaded from the sourceforge download page:
http://sourceforge.net/project/showfiles.php?group_id=89339

Detailed list of changes:

New widgetset: fpgui

updated translations: german, finnish, catalan, russian,
  italian, africaans (af-za), spanish
IDE: renaming a component now automatically renames methods
  with default names, and inherited components
made TColorButton a TCustomSpeedButton descendant
  from Tom Gregorovic
Capture any mouse button by setting TControl.CaptureMouseButton
  property from Tom Gregorovic (#7653)
LCL: published TAction.DisableIfNoHandler
LCL: setup better default properties for png writer
  from Tom Gregorovic
IDE: project directory is now added to the include path
  of all project directories
sqldb package: added TOracleConnection to component palette
win32 installer: fixed including the binutils from fpcbuild
creating package makefiles: the win64 OS uses the win32 widget set
svn2revisioninc can parse svn 1.4 meta data to determine a version
debugger: added dwarfloading to windebugger
  added exception dissection
  added linenumber address resolving
  added setting of breakpoints
the search results window now has a close button for non gtk users
trayiconlaz: moved TTrayIcon to 'additional' tab in component
  palette for Delphi compatibility
LCL: added TStaticText to 'additional' tab in component palette
  for Delphi compatibility
IDEIntf: image list editor: implemented auto splitting
  of added image  from Etrusco
synedit: codefolding is now completely implemented and
  enabled as default in the IDE. It uses simple begin..end blocks
  as demonstration. Eventually nicer block boundaries will be used.
grids, picklist select fixed
TrimFilename no longer reduces ${Macro}/.. directories
cups printing: implemented default paper sizes  from Jesus
moved code from TControlScrollBar to TScrollingWinControl,
  deriving TScrollingWinControl from TCustomControl  from Flavio
added example to add IDE help for the sources of a package
  examples/helpforpackage/demopackagewithhelp.lpk
test runner: added writing results to file
  and showing simple progress
fpcunit: new console runner uses new fpcunitconsolerunner package

qt intf:
  Patch from zeljko. Implements TQtAbstractSlider, TQtScrollBar,
  TQtTrackBar, TQtPen (CreatePenIndirect)
  and TQtRegion (CreateRectRgn).
  Unified qt4 header files. Updated bindings to 1.21
  added support for menus, font, progressbar and statusbar
  Combobox

And two hundred fixes and minor improvements.

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

  

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Hardware

[Adrian Veith]

google for the Jedi JCL library, it contains many useful routines for 
delphi - object pascal. with some handwork, the routines should work 
with fpc as well.


Adrian.

Fabrício F. Kammer schrieb:

Thanks A.J.

Do you know where can I get some example of how to do this?

Is it possible to have a conditional compile to do this?

Thanks again,

Fabrício

A.J. Venter escreveu:

I'm working in a software that I don't want that it runs in a different
of the orginal installation then I'll save this informations in a
crypted file and I'll read and check with the hardware in the moment of
the software is open.

There is no platform independent way to do this, since the the two 
OS's have very different approaches. Under windows you need to get 
the information from the registry, under linux you can get it by 
reading the files in /proc and /sys.


At some point somebody with some time should write a component that 
can give most used hardware information via a single interface with 
platform specific code to retrieve it. It's on my TODO list :)


A.J.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TCP Server

[Adrian Veith]

Hello Fabricio,

there are some examples at the synapse wiki page. I suggest that you 
also subscribe to the synalist at sourceforge.net - this is the right 
place to ask questions about synapse. There are many active users which 
can answer your questions.


Anyway, if you have the echo server running, than you have almost done 
the job. Instead of echoing the the data back to the client, you have to 
analyze the commands and send the results back to client.


Cheers,

Adrian.

Fabrício F. Kammer schrieb:
OK I was able to run the echo server example. Now I need to know how 
can I make a server that gets the commands sends by my client 
application and make the right actions with these commands.


Can anyone help with this?

PS: I'm trying to install the indy on windows xp without succes, if 
someone can help me I'll be thanks.


[]s

Fabrício

Andreas Berger escreveu:



OK,

I downloaded the synapse, but I don't know how to use it to make a 
TCP server.


I need to do a server that listen on a specific port. After 
connected the client will send some commands to the server that will 
make some actions and return the results to the client.


Basicly the client will send strings to the server and receive 
another strings.

Check out the echo demo in synapse. It seem to be exactly what you want.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TCP Server

[Adrian Veith]

Use Synapse instead of Indy.  After I have found Synapse, I dumped Indy.

goto http://www.ararat.cz/synapse/

Lukas has done a very fine tool !!

Cheers, Adrian.

Fabrício F. Kammer schrieb:

Hi all,

I need to developer an application to act as a tcp server that be 
compatible with windows/linux (debian).


I want to make a command line application (without graphical 
interface) because my linux server don't have the X installed.


I need of an example of how can I make this.

Does someone have an example of a tcp server to send me?

Regards,

Fabrício
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Cross compiling from win32 to linux

[Adrian Veith]

I try to crosscompile in win32 to linux with fpc 2.1.1.
I use the options: -Sd -B -Tlinux

The compiler compiles all the sources without problem, but the linker 
reports an errror: unrecognised emulation mode: elf_i386

this is because fpc calls ld instead of i386-linux-ld
when i rename i386-linux-ld to ld, the linker reports another error: 
cannot find -lpthread


where is my fault ?

thanks,

Adrian Veith.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] First Test of FastMM4 for fpc

[Adrian Veith]

Florian Klaempfl schrieb:

Adrian Veith wrote:

I compiled fpc from the sources from the svn repository today, but 
the results are almost the same as I posted yesterday (I marked with 
** where the results have changed):


Test1:
** fpc (standard MM):  3.0 sec - factor = 1.30
fpc (FastMM4):  2.9 sec - factor = 1.30
delphi (standard MM): 3.1 sec - factor = 1.34
delphi (FastMM4): 2.3 sec - factor = 1

Test2:
fpc (standard MM): 2.8  sec - factor =  1.47  ** fpc (FastMM4):  2.1 
sec - factor = 1.10

delphi (standard MM): 2.9 sec - factor = 1.52
delphi (FastMM4): 1.9 sec - factor = 1

Test3:
fpc (standard MM):  2.5 sec - factor = 1,19
fpc (FastMM4):  2.1 sec - factor = 1
delphi (standard MM): 3.4 sec - factor = 1.61
delphi (FastMM4): 2.1 sec - factor = 1


Strange, for me most tests improved by at least 10 %. Did you use a 
recompiled rtl compiled with -O3p3r?





You are right again ;-) I didn't compile the rtl with the new source...

Now it looks like this:

Test1:
fpc (standard MM):  3.0 sec - factor = 1.30
fpc (FastMM4):  2.8 sec - factor = 1.21
delphi (standard MM): 3.1 sec - factor = 1.34
delphi (FastMM4): 2.3 sec - factor = 1

Test2:
fpc (standard MM): 2.1  sec - factor =  1.23  
fpc (FastMM4):  1.7 sec - factor = 1

delphi (standard MM): 2.9 sec - factor = 1.70
delphi (FastMM4): 1.9 sec - factor = 1.11

Test3:
fpc (standard MM):  2.3 sec - factor = 1,15
fpc (FastMM4):  2.0 sec - factor = 1
delphi (standard MM): 3.4 sec - factor = 1.70
delphi (FastMM4): 2.1 sec - factor = 1.05


Test1 isn't relevant anymore. And in Test2 and Test3 fpc beats delphi 
clearly. The benefits for the FastMM4 are now not that big anymore, but 
it helps to compare delphi and fpc on a fair base, since the impact of 
the MM is now leveled out.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] First Test of FastMM4 for fpc

[Adrian Veith]

Peter Vreman schrieb:

I took a look at the MM and found that this test is not representative at
all. At least in the FPC MM it triggers only a single code path for
Reallocmem. And that code path is even the fastest for a
not-in-place-reallocation. And looking at the (unmaintable) FastMM4
sources i guess that the FPC code path is even shorter.

Also i don't know why you make the remark (and it reports memory leeks).
FPC already supports that for years with the heaptrc units. And with
compiling with debug info and adding the lineinfo you get output with
source information.

  


please forget the remark - after more than 20 years of tp and delphi I 
am starting with fpc - and i havn't learned yet all the things that are  
possible with fpc, which are not possible with delphi.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] First Test of FastMM4 for fpc

[Adrian Veith]

Micha Nelissen schrieb:

On Thu, 15 Dec 2005 18:21:18 +0100
Adrian Veith [EMAIL PROTECTED] wrote:

  
I have changed the FastMM4 that it seemd to work with fpc now. Here are 
the results of my prior tests now with FastMM4 for fpc:



How did you fix FastReallocMem? FPC uses a 'var APointer', but delphi
doesn't, apparantly.

Are you using the assembly optimized routines here ?
  


I wrote a small wrapper for ReallocMem.

{$ifdef fpc}
function FastReallocMemFP(var APointer: Pointer; ANewSize: Integer): 
Pointer;

begin
 if APointer = nil then
   Result:= FastAllocMem(ANewSize)
 else
   Result:= FastReallocMem(APointer, ANewSize);
 APointer:= Result;
end;
{$endif}

In my tests I use the asm routines, but the pascal routines work as 
well. Only the Debug-routines don't work (or need some overwork), 
because they access the vmt, which is different in delphi and fpc.



Adrian Veith.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] AnsiStrings and Memory Management

[Adrian Veith]

Peter Vreman schrieb:

(astonishing that  ShortStrings are slower than AnsiStrings in this
example
  

in delphi).

Not really. Delphi is silently upcasting your shortstrings to AnsiStrings
in
the background. You would probably have to recompile the VCL to get around
this ;-)



I've commited a few small fixes to improve performance, please try again
with current 2.1.1 from svn



  


I just tried the 2.1.1 version. The increase of speed is remarkable. Thanks.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] FastMM4 for fpc

[Adrian Veith]

I tried to modify the FastMM4 to work with with fpc.
I had no big problems for the non-assembly language version, but with 
the assembly language version i have the problem, that fpc is allways 
generating a stack frame, even if i use the {$STACKFRAMES OFF} directive.


Is it not possible at the moment, or do I miss something ?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] AnsiStrings and Memory Management

[Adrian Veith]

Hi,

two days ago i posted a comment about my experiences porting our 
database server to fpc. yesterday i tried to figure out where the speed 
differences between delphi and fpc come from. At the moment i stuck a 
little bit, because the results i get don't make any sense at the moment 
to me.
Anyway i dropped over another problem, which might be part of the cause 
of my problems. I tried to create a test base for my investigations and 
created a function NumberToText which converts an integer to written 
text  (like NumberToText(1234) - one thousand two hundred thirty 
four). When I filled my database with these generated strings I found 
some significant speed differences between delphi and fpc (over factor 
10), which made me curious. According to your comments about my first 
posting, i suspected the Memory Manager and created three different 
versions of this NumberToText function and three test loops which each 
calls the according NumberToText function for 0..99. Here are the 
results for fpc and delphi (w and w/o FastMM4)


Test1 uses optimized string concatention which avoids heap fragmentation
Test2 passes the string results using a var parameter
Test3 passes the string results as function results

Test1:
   fpc:  18.8 sec - factor = 8.17
   delphi (standard MM): 3.1 sec - factor = 1.34
   delphi (FastMM4): 2.3 sec - factor = 1

   fpc (ShortStrings): 1.25 sec - factor = 1.04
   delphi (ShortStrings): 1.20 sec - factor = 1

Test2:
   fpc:  45.2 sec - factor = 23.78
   delphi (standard MM): 2.9 sec - factor = 1.52
   delphi (FastMM4): 1.9 sec - factor = 1

   fpc (ShortStrings): 0.72 sec - factor = 1
   delphi (ShortStrings): 5.97 sec - factor = 8.29

Test3:
   fpc:  27.1 sec - factor = 12.9
   delphi (standard MM): 3.4 sec - factor = 1.61
   delphi (FastMM4): 2.1 sec - factor = 1

   fpc (ShortStrings): 1.27 sec - factor = 1
   delphi (ShortStrings): 4.84 sec - factor = 3.81

as you can see the optimized version (test 1) brings great benefits 
for fpc compared to the more natural approach (test 3). If someone has 
optimized code for delphi usage (test 2), he will suffer with the 
greatest performance hit in fpc.
Anyway these results have nothing to do with the code quality of the 
compiler (look at the ShortString results), but i think it's quite an 
important rtl and memory manager issue - and Delphi proves, that it a 
much higher speed with AnsiStrings is possible (astonishing that 
ShortStrings are slower than AnsiStrings in this example in delphi).


cheers,

Adrian Veith.

Code is below:

program Bench2;
{$APPTYPE CONSOLE}
{$H+}

uses
 //{$ifndef fpc} FastMM4, {$endif}
   sysutils,
   Windows;

const
 cTimes = 99;
   Number1: array [0..19] of string = (
   'zero', 'one', 'two', 'three', 'four', 'five',
   'six', 'seven', 'eight', 'nine', 'ten', 'eleven',
   'twelve', 'thirteen', 'fourteen', 'fifteen', 'sixteen',
   'seventeen', 'eighteen', 'nineteen');
   
 Number9: array [0..9] of string = (

   '', ' one', ' two', ' three', ' four', ' five',
   ' six', ' seven', ' eight', ' nine');

   Number10: array [0..9] of string = (
   'zero', 'ten', 'twenty', 'thirty', 'fourty', 'fifty',
   'sixty', 'seventy', 'eighty', 'ninety');

var
   StartTick: Cardinal;

procedure StartLog(const Text: string; Count: Integer);
begin
   if Count  0 then
   write(Text, ': ', Count, ' ... ')
   else
   write(Text, ' ... ');
   StartTick:= GetTickCount;
end;

procedure EndLog(const Text: string);
begin
   writeln(Text, ' done in ', (GetTickCount - StartTick) / 1000.0: 0: 
3, ' sec');

end;

type
 TFastStringRec = record
   l: Cardinal;
   s: string;
 end;

procedure FS_Clear(var AFS: TFastStringRec); inline;
begin
 AFS.L:= 0;
 AFS.S:= '';
end;

procedure FS_Assign(var AFS: TFastStringRec; const s: string); inline;
begin
 AFS.l:= Length(s);
 SetLength(AFS.s, (AFS.l and not 63) + 64);
 if AFS.l  0 then
   Move(s[1], AFS.s[1], AFS.l);
end;

procedure FS_Append(var AFS: TFastStringRec; const s: string); overload; 
inline;

var
 L, ls: Cardinal;
begin
 ls:= Length(s);
 if ls  0 then begin
   L:= AFS.l;
   AFS.l:= L + ls;
   SetLength(AFS.s, (AFS.l and not 63) + 64);
   Move(s[1], AFS.s[1 + L], ls);
 end;
end;

procedure FS_Append(var AFS, S: TFastStringRec); overload; inline;
var
 L: Cardinal;
begin
 if S.L  0 then begin
   L:= AFS.l;
   AFS.l:= L + S.L;
   SetLength(AFS.s, (AFS.l and not 63) + 64);
   Move(S.S[1], AFS.S[1 + L], S.L);
 end;
end;

function FS_ToStr(var AFS: TFastStringRec): string; inline;
begin
 if AFS.L   0 then begin
   SetLength(Result, AFS.L);
   Move(AFS.S[1], Result[1], AFS.L);
 end else
   Result:= '';
end;

procedure NumberToText_V1(out s: string; n: Integer);

 procedure TensToText(var s: TFastStringRec; dig: Integer);
 var
   x: Integer;
 begin
 if dig  0 then begin
 if dig = 20 then begin
   x:= dig mod 10;
   FS_Assign(s, Number10[dig div 10]);
 if x  0 then
  FS_Append(s, Number9[x]);
 end else begin

Re: [fpc-pascal] FreePascal 2.0.2 available

[Adrian Veith]

Congratulations,

with fpc 2.0.2 it's the first time, we were able to compile and run our 
dbGonzales database server (complete delphi code). In earlier versions 
of fpc, we always had some problems (mostly with variants), which caused 
runtime crashes.
First tests show that the execution speed of  the server is about 10% - 
30% slower than the same code compiled with delphi (win32). On the first 
glance, i would say, that these performance problems are in the string 
related routines. But this is really a minor problem, since with fpc we 
are now able to port to other platforms and it seems that the code 
quality improves with each release of fpc.


Thanks for this great compiler.

Adrian Veith.

--

Veith System GmbH



Florian Klaempfl schrieb:

Hi,

FPC 2.0.2 is finally available for various platforms. 2.0.2 is mainly a
bug fix release to 2.0.0 though also some little features were added.

Get FPC 2.0.2 from http://www.freepascal.org/download.html or read the
whatsnew.txt here: ftp://ftp.freepascal.org/pub/fpc/dist/whatsnew.txt

Have fun.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

  

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal 2.0.2 available

[Adrian Veith]

Marco van de Voort schrieb:

Congratulations,

with fpc 2.0.2 it's the first time, we were able to compile and run our 
dbGonzales database server (complete delphi code). In earlier versions 
of fpc, we always had some problems (mostly with variants), which caused 
runtime crashes.
First tests show that the execution speed of  the server is about 10% - 
30% slower than the same code compiled with delphi (win32). On the first 
glance, i would say, that these performance problems are in the string 
related routines. But this is really a minor problem, since with fpc we 
are now able to port to other platforms and it seems that the code 
quality improves with each release of fpc.



- do you compile with optimizations, e.g. -OG2p2r ?
  
yes I did compile with -OG3p3r, but I did a rebuild with -OG2p2r and  
the results look the same.

- a few strategically helped inline directives in tight code can do wonders. 
However this
is not universal.
  


I already use some inline directives for the delphi2005(6) compiler, and 
have them also enabled when the source compiles with fpc. but anyway, 
this shouldn't be source of the differences in runtime performance.

- Delphi apps are often hand-tuned to the default memory manager (iow it's 
deficiencies
are worked around with e.g. pooling, and the strengths are left relatively 
unoptimized)
 Profiling time spent in the memory manager on both systems and e.g. on Delphi 
 with an alternate memmgrs like FastMM can help decide if this is the issue.
  
right, it looks like that some of the performance issues come from the 
memory handler and the string routines. when i compile the delphi code 
without FastMM4, the delphi results are more closer to fpc, but still 
faster. With FastMM4 delphi leads in the string intensive benchmarks 
about factor 1.5 - 1.8. Has somebody already ported FastMM4 to fpc ?



- A profile comparison in both cases is interesting anyway.
  


I will try to nail the problem down to some example code. But at the 
moment the picture for me is like this:

Task: Full table scan 100 times of 25000 records
a) Comparing an integer field with a constant value: delphi 0.750 sec - 
fpc 0.765 - factor 1.02
b) Comparing a char field with a constant value ( = operation): delphi 
3.219 sec - fpc 4.734 - factor 1.47
c) Comparing a char field with a constant value (like operation): delphi 
3.453 sec - fpc 6.547 sec - factor 1.89
d) Comparing a char field with a constant value (optimized like 
operation): delphi 2.219 sec - fpc 3.968 sec - factor 1.78


the database dependent operations are similar for all 3 tests. the 
difference is in the operation which is performed 250.000 times.
in a) its getting the integer value of the database field and compare it 
to the value (the compare is without a runtime library call)
b) get the string value of the database field and compare it to the 
value (the compare is done with a runtime lib call to AnsiCompareStr).
c) same as b) but call a function which does a like operation. this 
function is the same for delphi and fpc.
d) get a pointer to string in the database field and call the same like 
function as in c)


I will try to analyze which part of the code makes these differences.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Optimizer in 2.0

[Adrian Veith]

Florian Klaempfl schrieb:


Adrian Veith wrote:
 


It shows with useless code like simple nested for .. to loops, but also
with some more useful code like the attached RSA_Angriff from the C'T
magazine.

My results are with:

fpc -Sd -OG3rp3 -XX RSA_Angriff_D5.dpr

5266 ms

with:

fpc -Sd -XX RSA_Angriff_D5.dpr

4844 ms

The unoptimized code is faster than the optimized code.
   



For me the version compiled with -OG3rp3 is the fastest (AthlonXP). Just
curious, what CPU do you use?
 


Intel Pentium M 730.

I will do the test on a Athlon XP as well. Maybe the picture changes.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Optimizer in 2.0

[Adrian Veith]

Hi,

I am newbie with fpc (but not with pascal, which I use more than 20y now).
We have lot of existing delphi code, which some of it, I want to port to 
new platforms - and fpc looks like the right tool for it. But I am 
concerned about the speed. I did some basic benchmarks and it seems, 
that the optimizers has no effect in the 2.0 compiler (or the code even 
get's slower).


With the 1.9.8 compiler, the same code executes 4 times quicker - what 
happend (or what do I wrong) ?


For optimizing I use the -OG3rp3 switch  - is it still valid ?

Thanks,

Adrian.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Optimizer in 2.0

[Adrian Veith]

It shows with useless code like simple nested for .. to loops, but also 
with some more useful code like the attached RSA_Angriff from the C'T 
magazine.


My results are with:

fpc -Sd -OG3rp3 -XX RSA_Angriff_D5.dpr

5266 ms

with:

fpc -Sd -XX RSA_Angriff_D5.dpr

4844 ms

The unoptimized code is faster than the optimized code.

(BTW. I choosed an example where the Delphi compiler is really worse ;-) 
: 65953 ms)


Same picture with the whet.pas (whether or not the whetstone benchmark 
is useful) from your source distribution.


With optimization on:  7393.72 MIPS

With optimization off:  8368.20 MIPS

cheers,

Adrian.

Florian Klaempfl schrieb:


Adrian Veith wrote:

 


Hi,

I am newbie with fpc (but not with pascal, which I use more than 20y now).
We have lot of existing delphi code, which some of it, I want to port to
new platforms - and fpc looks like the right tool for it. But I am
concerned about the speed. I did some basic benchmarks and it seems,
that the optimizers has no effect in the 2.0 compiler (or the code even
get's slower).
   



This shouldn't be the case in general, can you give examples or post the
benchmark? And don't try with useless code, we don't care about optimziations
which test only useless code which never happens in real programs.

 


With the 1.9.8 compiler, the same code executes 4 times quicker - what
happend (or what do I wrong) ?

For optimizing I use the -OG3rp3 switch  - is it still valid ?

Thanks,

Adrian.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
   




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

 

program RSA_Angriff_D5;
(* Benchmarkversion testet Laufzeitverhalten primitiver Datentypen.
 *  - Konsolenprogramm
 *  - Auswahl zwischen bitorientierter Routine mit aufwändiger Rekursion 
DoPrim2()
 *und BruteForce-Routine DoPrimBruteForce() schlicht durch Auskommentieren 
in main()
 *  - zu zerlegende Zahl als BigNumber definiert.
 *
 *  Anmerkung: DoPrimBruteForce() findet auch kleine Primfaktoren,
 * DoPrim2() ignoriert diese, da RSA-Paare immer große Primfaktoren 
haben
 * (thats a bug, but also a feature)
*)

{$APPTYPE CONSOLE}
uses
SysUtils,
Windows;

const
  BigNumber: int64 = 34571237124234713;

procedure DoPrimBruteForce(NumberToCrunch: int64);
var i, j, UBound: int64; UBoundC: Comp;
begin
  i := 3;
  // ohne den Umweg über eine Gleitkommazahl
  // schafft Delphi das nicht
  UBoundC := NumberToCrunch;
UBound := Round(Sqrt(UBoundC));
while i  UBound do
  begin
if NumberToCrunch mod i = 0 then
begin
  j := NumberToCrunch div i;
  Writeln(i, ' * ', j, ' = ', j * i);
end;
Inc(i,2);
  end;
end;

procedure DoPrim2(NumberToCrunch: int64);
var UBound, z: int64;

  procedure Prim(
n: Integer;   // Bitmaske bis m-te Stelle, also 2^m - 1
m: Integer;   // Stelle (Zweierpotenz)
i,// 1. Kandidat für Primzahl
j,// 2. Kandidat für Primzahl
res: int64);   // bisher auf m Stellen synthetisiertes Produkt
  var
product: int64;
z0: int64;
m1, n1: Integer;
im, jm: int64;
  begin
product := i * j;   // Überlauf? dann Ende der Rekursion

// Rekursion bricht ab, wenn
//   - 1. Kandidat größer als Wurzel der Zahl
//   - Produkt zu groß
//   - m wegen überlauf negativ wird
if (i  UBound) and (product  z) and (m  0) then
begin
z0 := z and n;   // Ausfiltern der relevanten 
Stellen
m1 := m shl 1; // nächste Stelle
n1 := n or m1; // Bitmaske erweitern

// Tiefensuche rekursiv!
// Es gibt vier mögliche Fälle, je zwei pro Kandidat
// zwei davon gehen in die Rekursion
// relevant sind nur m Stellen

if (res and n) = z0// +0, +0 (i, j 
unverändert)
then Prim(n1, m1, i, j, res);

im := i or m; // m-tes Bit der Kandidaten 
setzen
jm := j or m;
// Testen ob die letzten m Stellen des Kandidatenprodukts stimmen
res := im * j;
if (res and n) = z0// +1, +0 (m-tes Bit von i gesetzt)
  then Prim(n1, m1, im, j, res);
res := jm * i; // +0, +1 (m-tes Bit von j gesetzt)
if (res and n) = z0
then Prim(n1, m1, i, jm, res);
res := im * jm;// +1, +1 (m-tes Bit von i,j gesetzt)
if (res and n) = z0
then Prim(n1, m1, im, jm, res);
end else
begin // Rekursion bricht ab. Stimmt das Produkt etwa?
if (i