Re: [fpc-devel] arm-embedded apps crash in exception handler initialization because heapmanager is not initialized

[Florian Klämpfl]

Am 02.03.2013 23:17, schrieb Michael Ring:
 I am not sure if I have hit work in progress code here
 
 my arm-embedded app crashes during initialization, the reason is that
 now exceptions are part of the rtl but there is no properly initialized
 heapmanager:
 
 Procedure InitExceptions;
 {
   Must install uncaught exception handler (ExceptProc)
   and install exceptions for system exceptions or signals.
   (e.g: SIGSEGV - ESegFault or so.)
 }
 begin
   ExceptionClass := Exception;
   ExceptProc:=@CatchUnhandledException;
   // Create objects that may have problems when there is no memory.
   //CRASH BOOM BANG in the following line
   OutOfMemory:=EOutOfMemory.Create(SOutOfMemory);
 
 
 Creating the object fails because the MemoryManager is not properly
 initialized yet.
 
 When I put heapmgr unit before sysutils im my program (this should not
 be necesary, right???)

Yes, this is a requirement.

 I can debug a little deeper in object
 initialization but still the root cause exists that there has never been
 a call to RegisterHeapBlock so objects cannot be initiated because
 there's no memory block defined that heapmgr can draw memory from.
 
 I can hack the RegisterHeapBlock call into the initialization code of
 the unit heapmgr but this is more a hack than a proper solution --
 seems a bad idea to me.
 
 How can this be properly solved?

I think allocating a small block (128 bytes for arm?) during the start
up of heapmgr should be fine?

var
  InitialBlock: array[0..255] of byte;

...
RegisterHeapBlock(@InitialBlock,sizeof(InitialBlock));

If one includes heapmgr he wants to use the heap after all.

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Daniël Mantione]

Op Sun, 3 Mar 2013, schreef Martin Schreiber:


BTW, a significant percentage of the time is waiting for FPC compiling because
FPC normally crashes without -B.


I think you should focus your efforts on getting those bugs fixed, such as 
by submitting bug reports that allow reproduction of the problem with 
programs as simple as you can get them to show the problem.


It is completely unrealistic that FPC will get the same compiler speed as 
Delphi. FPC will become slower in the future for sure, because the 
compiler will execute more algorithms to generate better code.


Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Martin Schreiber]

On Sunday 03 March 2013 10:04:54 Daniël Mantione wrote:
 Op Sun, 3 Mar 2013, schreef Martin Schreiber:
  BTW, a significant percentage of the time is waiting for FPC compiling
  because FPC normally crashes without -B.

 I think you should focus your efforts on getting those bugs fixed, such as
 by submitting bug reports that allow reproduction of the problem with
 programs as simple as you can get them to show the problem.

The problem is well known since a long time AFAIK. The answer we normally get 
when we report a unit handling related FPC crash is that FPC unit handling 
should be rewritten. I can't rewrite FPC unit handling myself because I have 
many other tasks. ;-)

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Florian Klämpfl]

Am 03.03.2013 10:46, schrieb Martin Schreiber:
 On Sunday 03 March 2013 10:04:54 Daniël Mantione wrote:
 Op Sun, 3 Mar 2013, schreef Martin Schreiber:
 BTW, a significant percentage of the time is waiting for FPC compiling
 because FPC normally crashes without -B.

 I think you should focus your efforts on getting those bugs fixed, such as
 by submitting bug reports that allow reproduction of the problem with
 programs as simple as you can get them to show the problem.

 The problem is well known since a long time AFAIK. The answer we normally get 
 when we report a unit handling related FPC crash is that FPC unit handling 
 should be rewritten. I can't rewrite FPC unit handling myself because I have 
 many other tasks. ;-)

Same here :)

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Sven Barth]

On 03.03.2013 08:23, Martin Schreiber wrote:

On Sunday 03 March 2013 08:12:28 Martin Schreiber wrote:

On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote:

On Sat, 2 Mar 2013, Martin Schreiber wrote:

On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:

Anyway, what seems obvious from your numbers is that it is the linking
stage that needs speedup. This does not really come as a surprise.


On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll
check it later, currently I try to make MSEide+MSEgui Kylix3 compatible
so we have a benchmark on Linux too.


When you do, please send me the output of a strace -f


I will take a while because it is much work to make the code both FPC and
Delphi/Kylix compatible.


BTW, a significant percentage of the time is waiting for FPC compiling because
FPC normally crashes without -B.


Do you mean compiling the compiler? If so than for real tests you SHOULD 
NOT compile the compiler by hand, but only through make cycle in the 
compiler directory or make all in the top level directory. This will 
ensure that the compiler is compiled correctly.


And yes, I know the problem with -B and it's likely related to unit 
loading. This normally happens only in more complex projects like the 
compiler. Though I've just managed yesterday to create a smaller example 
(by accident) that also chrashes. Maybe I'll find the problem and can 
fix it once and for all :)


Regards,
Sven

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Martin Schreiber]

On Sunday 03 March 2013 10:42:09 Sven Barth wrote:

 Do you mean compiling the compiler? If so than for real tests you SHOULD
 NOT compile the compiler by hand, but only through make cycle in the
 compiler directory or make all in the top level directory. This will
 ensure that the compiler is compiled correctly.

 And yes, I know the problem with -B and it's likely related to unit
 loading. This normally happens only in more complex projects like the
 compiler. Though I've just managed yesterday to create a smaller example
 (by accident) that also chrashes. Maybe I'll find the problem and can
 fix it once and for all :)

No, I mean MSEide. MSEide is a more complex application than the compiler it 
seems. :-)

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

Re: [fpc-devel] arm-embedded apps crash in exception handler initialization because heapmanager is not initialized

[Michael Ring]

Simple solutions are the best ;-) Thanks for opening my eyes to this 
easy approach.


I have created a patch for heapmgr.pp, could I ask you to commit it to svn?

For a little more flexible solution I would like to ask you one more 
questions, it may seem dumb to you but I have never been that deep into 
a compiler before so I am learning a lot atm.


I can see that the compiler param -Ch can be used to define the 
heapsize, I can also see in the assembler code of my main program that 
when I set -Ch I also get a section:


-Ch2048 results in this:

.section .data.n___heapsize
.balign 4
.globl  __heapsize
__heapsize:
.long   2048

but I do not seem to be able to access __heapsize in my code, how could 
I use this information to make the heapsize configurable?


and, it is (as far as I understand) a must to include heapmgr in the 
code because if not the program will always die on startup because of 
the object created in Exception class, where would be the right place to 
do this?


Yes, I can put heapmgr as the first unit included in my main program, 
but wouldn't it be better to put it in some global initialization loop, 
like the VariantManager, which always gets initialized without me 
triggering this in any way.


Michael




Index: rtl/embedded/heapmgr.pp
===
--- rtl/embedded/heapmgr.pp(revision 23681)
+++ rtl/embedded/heapmgr.pp(working copy)
@@ -34,6 +34,7 @@

 var
   Blocks: PHeapBlock = nil;
+  InitialBlock: array[0..255] of byte;

 procedure InternalFreeMem(Addr: Pointer; Size: ptruint); forward;

@@ -242,6 +243,7 @@

 initialization
   SetMemoryManager(MyMemoryManager);
+  RegisterHeapBlock(@InitialBlock,sizeof(InitialBlock));
 finalization
   //FinalizeHeap;
 end.







Am 03.03.13 09:52, schrieb Florian Klämpfl:

Am 02.03.2013 23:17, schrieb Michael Ring:

I am not sure if I have hit work in progress code here

my arm-embedded app crashes during initialization, the reason is that
now exceptions are part of the rtl but there is no properly initialized
heapmanager:

Procedure InitExceptions;
{
   Must install uncaught exception handler (ExceptProc)
   and install exceptions for system exceptions or signals.
   (e.g: SIGSEGV - ESegFault or so.)
}
begin
   ExceptionClass := Exception;
   ExceptProc:=@CatchUnhandledException;
   // Create objects that may have problems when there is no memory.
   //CRASH BOOM BANG in the following line
   OutOfMemory:=EOutOfMemory.Create(SOutOfMemory);


Creating the object fails because the MemoryManager is not properly
initialized yet.

When I put heapmgr unit before sysutils im my program (this should not
be necesary, right???)

Yes, this is a requirement.


I can debug a little deeper in object
initialization but still the root cause exists that there has never been
a call to RegisterHeapBlock so objects cannot be initiated because
there's no memory block defined that heapmgr can draw memory from.

I can hack the RegisterHeapBlock call into the initialization code of
the unit heapmgr but this is more a hack than a proper solution --
seems a bad idea to me.

How can this be properly solved?

I think allocating a small block (128 bytes for arm?) during the start
up of heapmgr should be fine?

var
   InitialBlock: array[0..255] of byte;

...
RegisterHeapBlock(@InitialBlock,sizeof(InitialBlock));

If one includes heapmgr he wants to use the heap after all.

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



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

Re: [fpc-devel] Delphi anonymous methods

[Sven Barth]

On 03.03.2013 08:07, Vasiliy Kevroletin wrote:

If the x is really located in the FrameObject and that object exists
only once then it is rather likely that the output of 'Before 123: '
is different from the output of 'After 123: ', right? Again I think
this is a bad thing...

I was wrong. Local variables of anonymous function located where they
should be: on stack.


That's a relieve :)


 So in my opinion an implementation with a stricter division between
the single instances of an anonymous function would be the better choice

Am I understand correctly that loop

for i := 1 to 5 do
   procArr[i] := procedure begin
  DoSmth();
end;

should create 5 separate instances?


Not the code should be seperate, but where the captured data is located. 
In Delphi there will only be one FrameObject shared by all anonymous 
functions, but in my opinion it would be better if we have each a 
Storage Object for each instance of an anonymous function. So in the 
above example there would indeed be 5 such instance (but the code would 
only exist once).



It is as I thought about closures before. But this is useless without
capturing of variables by value. During creation of anonymous method you
*can not bind any values* to it. Anonymous method have only references
to captured variables. Pascal don't allows to create static variables
inside function like in c-like languages. So you also not able to create
unique static variable which available only to one instance of same
anonymous method. Even if implementation will create many separate
objects for one anonymous function then all instances will be
equivalent. Because all instances will refer to same data.


Little side note: You can create static variables in Pascal, it's just 
not as you'd expect them ;)


=== example begin ===

procedure Test;
const
  FooBar: Integer = 42;
begin
  Writeln(FooBar);
{$push}
{$J+}
  FooBar := 21;
{$pop}
end;

Test; // 42
Test; // 21

=== example end ===

This works since at least Turbo Pascal times (and the $J enables 
writeable typed constants) and was used as the poor man's visibility 
handling


But I don't understand what you continue to write: if we create a static 
variable it would be shared by all instances and not be specific to each 
instance.
Also in my proposal the instances would not be equivalent. Delphi seems 
to create these anonymous functions


=== code begin ===

procedure Something;
var
  x, y: Integer;
  proc: reference to procedure;
  func: reference to function(aX: Integer): Integer;
begin
  x := 42;
  y := 21;
  proc := procedure
  begin
Writeln(x);
  end;
  func := function(aX: Integer): Integer
  begin
Result := aX * y;
  end;
end;

=== code end ===

this way (note: not necessarily compileable code):

=== code begin ===

procedure Something;

  type
FrameObjectClass = class(TInterfacedObject)
  x, y: Integer;
  procedure CallProc1;
  function CallFunc1(aX: Integer): Integer;
end;

procedure FrameObjectClass.CallProc1;
begin
  Writeln(x);
end;

function FrameObjectClass.CallFunc1(aX: Integer): Integer;
begin
  Result := aX * y;
end;

  var
FrameObject: FrameObjectClass;
proc: reference to procedure;
func: reference to function(aX: Integer): Integer;
begin
  FrameObject := FrameObjectClass.Create;
  FrameObject.x := 42;
  FrameObject.y := 21;
  proc := @FrameObject.CallProc1;
  func := @FrameObject.CallFunc1;
end;

=== code end ===

Now I would like to see it done like this:

=== code begin ===

procedure Something;

type
  StorageProc1 = class(TInterfacedObject)
x: Integer;
procedure Invoke;
  end;

  StorageFunc1 = class(TInterfacedObject)
y: Integer;
function Invoke(aX: Integer): Integer;
  end;

var
  x, y: Integer;
  tmp: TInterfacedObject;
  proc: reference to procedure;
  func: reference to function(aX: Integer): Integer;
begin
  x := 42;
  y := 21;
  tmp := StorageProc1.Create;
  tmp.x := x;
  proc := @tmp.Invoke;
  tmp := STorageProc1.Create;
  tmp.y := y;
  func := @tmp.Invoke;
end;

=== code end ===

Note: I'm aware that one shouldn't use interfaces this way; this is only 
an example that should illustrate my point.


So for each assignment to a reference to procvar a new such Storage 
Object will be created and so a arr[1] = arr[2] would be false in case 
of the loop.



Capturing variables by value will allow simple creation of parametrised
closures. Now you also can do parametrised anonymous method but you
should wrap generation of such method into other anonymous function. For
example like this:

=== example

for i := 1 to 5 do
   procArr[i] := Call(
 function: TProc
 var stored: Integer;
 begin
   stored := i;
   Result := procedure
 begin
   Writeln(stored);
 end;
 end );

===

This can be simplified by support of capturing by value (please 

Re: [fpc-devel] Delphi anonymous methods

[Sven Barth]

On 03.03.2013 06:08, Vasiliy Kevroletin wrote:



Do you have any ideas how and why such behaviour implemented ?


Now I can answer my question myself. *Local variables of anonymous
method are located on stack*.


I would have wondered about the state of mind of the Embarcadero 
developers if it would have been different :P


Regards,
Sven

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

Re: [fpc-devel] arm-embedded apps crash in exception handler initialization because heapmanager is not initialized

[Sven Barth]

On 03.03.2013 11:04, Michael Ring wrote:

For a little more flexible solution I would like to ask you one more
questions, it may seem dumb to you but I have never been that deep into
a compiler before so I am learning a lot atm.

I can see that the compiler param -Ch can be used to define the
heapsize, I can also see in the assembler code of my main program that
when I set -Ch I also get a section:

-Ch2048 results in this:

.section .data.n___heapsize
 .balign 4
.globl  __heapsize
__heapsize:
 .long   2048

but I do not seem to be able to access __heapsize in my code, how could
I use this information to make the heapsize configurable?


Did you try

=== code begin ===

var
  heapsize: LongWord; external name '__heapsize';

=== code end ===

?

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Sven Barth]

On 03.03.2013 11:08, Martin Schreiber wrote:

On Sunday 03 March 2013 10:42:09 Sven Barth wrote:


Do you mean compiling the compiler? If so than for real tests you SHOULD
NOT compile the compiler by hand, but only through make cycle in the
compiler directory or make all in the top level directory. This will
ensure that the compiler is compiled correctly.

And yes, I know the problem with -B and it's likely related to unit
loading. This normally happens only in more complex projects like the
compiler. Though I've just managed yesterday to create a smaller example
(by accident) that also chrashes. Maybe I'll find the problem and can
fix it once and for all :)


No, I mean MSEide. MSEide is a more complex application than the compiler it
seems. :-)


No, it's not (at least not in that sense ;) ), because the compiler 
triggers this error as well, when I compile it inside the IDE.


Regards,
Sven

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

Re: [fpc-devel] Delphi anonymous methods

[Vasiliy Kevroletin]

On 03/03/2013 09:11 PM, Sven Barth wrote:

On 03.03.2013 06:08, Vasiliy Kevroletin wrote:



Do you have any ideas how and why such behaviour implemented ?


Now I can answer my question myself. *Local variables of anonymous
method are located on stack*.


I would have wondered about the state of mind of the Embarcadero 
developers if it would have been different :P


Yes, now I don't sure how I did such assumption. May be I was under 
expression of fact that SizeOf(TProc) = 4 (on 32-bit machine).

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

Re: [fpc-devel] Delphi anonymous methods

[Vasiliy Kevroletin]

Maybe specifying how a variable should be captured would be a solution 
that can satisfy both worlds...


Good.

This will also help to split implementation.
1. Implement Sven's proposal. Anonymous functions which can capture 
local variables only by value.

2. Create Delphi-compatible capturing by reference.
3. Discuss and implement short lambdas syntax.

Vasiliy K.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] arm-embedded apps crash in exception handler initialization because heapmanager is not initialized

[Michael Ring]

This helped me to understand another puzzle piece.

Please correct me if I am wrong:

sram - Memory is divided in several areas on arm-embedded:

_data starts at start of sram ($2000 in my case)
_edata is end of _data segment ($29b4)
_bss_start defines start of static vars ($29b4)
_bss_end defines end of static vars ($2e90)

all memory from here on is used for stack, stack grows from end of 
avaliable sram ($2001) downto _bss_end


so what I could do is allocate memory for heap starting at address 
_bss_end with the size of _heapsize. or, perhaps even better:


I start using memory at address _stack_top - _stklen - _heapsize

Correct ??

Michael

Am 03.03.13 11:14, schrieb Sven Barth:

On 03.03.2013 11:04, Michael Ring wrote:

For a little more flexible solution I would like to ask you one more
questions, it may seem dumb to you but I have never been that deep into
a compiler before so I am learning a lot atm.

I can see that the compiler param -Ch can be used to define the
heapsize, I can also see in the assembler code of my main program that
when I set -Ch I also get a section:

-Ch2048 results in this:

.section .data.n___heapsize
 .balign 4
.globl  __heapsize
__heapsize:
 .long   2048

but I do not seem to be able to access __heapsize in my code, how could
I use this information to make the heapsize configurable?


Did you try

=== code begin ===

var
  heapsize: LongWord; external name '__heapsize';

=== code end ===

?

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel



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

Re: [fpc-devel] Delphi anonymous methods

[Sven Barth]

On 03.03.2013 12:26, Vasiliy Kevroletin wrote:



Maybe specifying how a variable should be captured would be a solution
that can satisfy both worlds...


Good.

This will also help to split implementation.
1. Implement Sven's proposal. Anonymous functions which can capture
local variables only by value.
2. Create Delphi-compatible capturing by reference.
3. Discuss and implement short lambdas syntax.


Yes, this can be seen as a plan. We also need to think about a 
approbiate syntax for 1 before this step can be done. And I'd also like 
to know what other core devs think about this. I myself would support 
this though.


And I'll also ask Blaise whether he can commit the missing code so that 
you could in principal use his work as a base.


Regards,
Sven

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Michael Van Canneyt]

On Sun, 3 Mar 2013, Martin Schreiber wrote:


On Sunday 03 March 2013 08:12:28 Martin Schreiber wrote:

On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote:

On Sat, 2 Mar 2013, Martin Schreiber wrote:

On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:

Anyway, what seems obvious from your numbers is that it is the linking
stage that needs speedup. This does not really come as a surprise.


On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll
check it later, currently I try to make MSEide+MSEgui Kylix3 compatible
so we have a benchmark on Linux too.


When you do, please send me the output of a strace -f


I will take a while because it is much work to make the code both FPC and
Delphi/Kylix compatible.


BTW, a significant percentage of the time is waiting for FPC compiling because
FPC normally crashes without -B.


A sure sign that you have fishy code :)
I have lots of code, and never ever experienced such a thing.
I even can't remember when the compiler last gave me a problem; and I use it 
daily.

Most problems I experience today have to do with version management.

I'm sorry, but I do not share your focus on speed. I have many projects, 
some of them have more units than mseide does, and yet I never have to wait 
more than a couple of seconds. The only exception is the Lazarus IDE.


If you say that mseide only compiles with -B, I would suggest looking for 
strange dependencies inside mseide, if you want to reduce compile time...


I do not want to say that FPC does not need speed improvements, but I do suspect you 
will get faster results looking at removing the -B requirement from mseide...


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

Re: [fpc-devel] Delphi anonymous methods

[Alexander Klenin]

On Sun, Mar 3, 2013 at 11:21 PM, Sven Barth pascaldra...@googlemail.com wrote:

 This will also help to split implementation.
 1. Implement Sven's proposal. Anonymous functions which can capture
 local variables only by value.
 2. Create Delphi-compatible capturing by reference.
 3. Discuss and implement short lambdas syntax.


 Yes, this can be seen as a plan. We also need to think about a approbiate
 syntax for 1 before this step can be done. And I'd also like to know what
 other core devs think about this. I myself would support this though.

I agree with the plan. But I am not sure about the order -- perhaps
implement Delphi-compatible variant first, since it have to be done anyway,
and there is already a spec for it.

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

[Paul Ishenin]

03.03.13, 22:09, Alexander Klenin пишет:


I agree with the plan. But I am not sure about the order -- perhaps
implement Delphi-compatible variant first, since it have to be done anyway,
and there is already a spec for it.


I also vote for Delphi-compatible feature the first, then implement 
extensions.


Best regards,
Paul Ishenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

[Sven Barth]

On 03.03.2013 15:09, Alexander Klenin wrote:

On Sun, Mar 3, 2013 at 11:21 PM, Sven Barth pascaldra...@googlemail.com wrote:


This will also help to split implementation.
1. Implement Sven's proposal. Anonymous functions which can capture
local variables only by value.
2. Create Delphi-compatible capturing by reference.
3. Discuss and implement short lambdas syntax.



Yes, this can be seen as a plan. We also need to think about a approbiate
syntax for 1 before this step can be done. And I'd also like to know what
other core devs think about this. I myself would support this though.


I agree with the plan. But I am not sure about the order -- perhaps
implement Delphi-compatible variant first, since it have to be done anyway,
and there is already a spec for it.


Implementing the Delphi compatible behavior first might prohibit the 
alternative behavior. So first an analysis step should be added to 
evaluate how the two ways can be implemented without prohibiting one of 
the two ways.


Regards,
Sven

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

[fpc-devel] Re: Regarding the Free Pascal closure branch

[Blaise Thorn]

On 29.01.2013 13:21, Sven Barth wrote:


Am 29.01.2013 07:34, schrieb Blaise Thorn:


On 16.12.2012 20:52, Sven Barth wrote:


out of curiosity I have taken a look at your closure branch. Can it be that you 
forgot to commit the pnameless unit?


I did not actually forget, just got distracted,


I know that problem... :)


and somewhat discouraged by the lack of readiness to accept small unrelated 
bugfixes directly.


I've looked at the mails from that time again. Jonas has said that you should 
do a bug report for things like that. Did you do that?  If not then it's more 
or less clear why it got lost... one does not always have the time to 
incorporate even a small fix, maybe because the current checkout is polluted 
with other changes, etc. Thus it's indeed normally the best to report such 
things in Mantis so it's not (as easily) forgotten.


You know, I am all for a formal process -- in fact, I did use to file bug 
reports even for tiny patches when they concerned the user-visible changes -- 
but filing bug reports for patching a memory leak on line  of .pas is 
definitely an overkill in my book.


Nevertheless I've now looked at your patch regarding pdecsub.pas. The problem 
with the not printed message is already fixed in trunk and I've now 
incorporated your fix regarding the memory leak and will commit it once I've 
checked whether it breaks something.


Thank you. Actually, that was another thing that discouraged me. I intended to 
ensure that my branch did not introduce any memory leaks, but then I found out 
that FPC leaked like a %#@!, especially when the error recovery was concerned.


I also remembered other mails regarding your progress (where you e.g. complained that 
you used goto), but I didn't find them anymore :(


You are mistaken. I did not discuss anything past the few initial messages.


Shortly thereafter, a Delphi beta test had started, and I am usually very 
involved with those, to the point of having no free time at all.

In the past weeks, I did try sync'ing my branch with the trunk, but only got up 
to r21067; there the JVM backend integration happened, so some careful manual 
merging is required, for which I have not yet found time.

Let's say if I don't find it within a week, I'll just commit everything as-is 
and be done with it.


As long as your branch compiles (and thus can be tested) someone else can do 
the hard work of merging it to trunk.


BTW, it's the things like GOTO (and occasional WTF comments) that I feel obligated to 
clean up before becoming done with it.


if the main feature closures is already finished your work could then already 
be reviewed for merging (I don't know the current state of the branch, so I can't comment 
here).


I expect it to work for the most but not all cases (for example, there should 
be some issues with capturing the parent variables from nested routines), but I 
have not actually written any comprehensive tests yet.


Did you write any tests and do you still have them? If so it would be nice if 
you'd commit them as well.


Those were pretty rudimentary. I am not sure if they can be qualified as tests 
:)


Anyway, I have started the merging process and, as I have seen the today's 
thread in the dev's list, I am CC'ing this message there.

--
βþ
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: Regarding the Free Pascal closure branch

[Sven Barth]

On 03.03.2013 17:00, Blaise Thorn wrote:

On 29.01.2013 13:21, Sven Barth wrote:


Am 29.01.2013 07:34, schrieb Blaise Thorn:


On 16.12.2012 20:52, Sven Barth wrote:


out of curiosity I have taken a look at your closure branch. Can it
be that you forgot to commit the pnameless unit?


I did not actually forget, just got distracted,


I know that problem... :)


and somewhat discouraged by the lack of readiness to accept small
unrelated bugfixes directly.


I've looked at the mails from that time again. Jonas has said that you
should do a bug report for things like that. Did you do that?  If not
then it's more or less clear why it got lost... one does not always
have the time to incorporate even a small fix, maybe because the
current checkout is polluted with other changes, etc. Thus it's indeed
normally the best to report such things in Mantis so it's not (as
easily) forgotten.


You know, I am all for a formal process -- in fact, I did use to file
bug reports even for tiny patches when they concerned the user-visible
changes -- but filing bug reports for patching a memory leak on line
 of .pas is definitely an overkill in my book.



But on the other hand you see that they can be easily forgotten. E.g. if 
I forget to mark an e-mail as important it could be that I don't 
remember it for a long time or at all...



Nevertheless I've now looked at your patch regarding pdecsub.pas. The
problem with the not printed message is already fixed in trunk and
I've now incorporated your fix regarding the memory leak and will
commit it once I've checked whether it breaks something.


Thank you. Actually, that was another thing that discouraged me. I
intended to ensure that my branch did not introduce any memory leaks,
but then I found out that FPC leaked like a %#@!, especially when the
error recovery was concerned.


We try to fix memory leaks in the error case, because while the compiler 
will stop afterwards the text mode IDE doesn't and that one contains the 
compiler compiled in. So if you find any memory leaks don't hesitate to 
report them (you can also collect some and report them as one issue).



I also remembered other mails regarding your progress (where you e.g.
complained that you used goto), but I didn't find them anymore :(


You are mistaken. I did not discuss anything past the few initial messages.


But I remember that I've already read about your goto-point below... 
could have also been inside your code though...



Shortly thereafter, a Delphi beta test had started, and I am usually
very involved with those, to the point of having no free time at all.

In the past weeks, I did try sync'ing my branch with the trunk, but
only got up to r21067; there the JVM backend integration happened, so
some careful manual merging is required, for which I have not yet
found time.

Let's say if I don't find it within a week, I'll just commit
everything as-is and be done with it.


As long as your branch compiles (and thus can be tested) someone else
can do the hard work of merging it to trunk.


BTW, it's the things like GOTO (and occasional WTF comments) that I
feel obligated to clean up before becoming done with it.


Well... we aren't *that* strict about gotos in the compiler. Sometimes 
they make the code more readable than strange loops :)



if the main feature closures is already finished your work could
then already be reviewed for merging (I don't know the current state
of the branch, so I can't comment here).


I expect it to work for the most but not all cases (for example,
there should be some issues with capturing the parent variables from
nested routines), but I have not actually written any comprehensive
tests yet.


Did you write any tests and do you still have them? If so it would be
nice if you'd commit them as well.


Those were pretty rudimentary. I am not sure if they can be qualified as
tests :)


One can always discard them later on, so I would add them. :)


Anyway, I have started the merging process and, as I have seen the
today's thread in the dev's list, I am CC'ing this message there.



Thank you. I hope that Visiliy will continue your work and maybe your 
code will show him valuable information what he can/should do in the 
compiler.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Status of SEH in FPC

[Flávio Etrusco]

On Sun, Mar 3, 2013 at 1:28 AM, Sergei Gorelkin sergei_gorel...@mail.ru wrote:
 03.03.2013 2:53, Flávio Etrusco пишет:

 Hello,

 what's the current state of the SEH in FPC trunk?
 IIRC - and according to wikipedia ;-) - SEH, at least for Windows, was
 in the 2.7 roadmap, but I can't find any related brach, or commit, or
 post.
 Also AFAIU would have some gains in both executable size and speed,
 correct?

 By now SEH is fully implemented for Win64 target, but you need to cycle the
 compiler with OPT=-dTEST_WIN64_SEH to enable it.
 The most of it was committed in revision 20098.

 The effect of SEH is two-fold: it gives some performance gain when running
 without exceptions, but big penalty when exceptions occur. It somewhat
 reduces code size but at the same time adds some data, so executable size
 may not reduce.

 The main advantage of SEH is the conformance with OS exception handing
 scheme. Without it, it was almost impossible to use DLLs that raise
 exceptions.

 Regards,
 Sergei

Thanks. And are there any plans to implement it for Win32?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Status of SEH in FPC

[Sven Barth]

On 03.03.2013 17:45, Flávio Etrusco wrote:

On Sun, Mar 3, 2013 at 1:28 AM, Sergei Gorelkin sergei_gorel...@mail.ru wrote:

03.03.2013 2:53, Flávio Etrusco пишет:


Hello,

what's the current state of the SEH in FPC trunk?
IIRC - and according to wikipedia ;-) - SEH, at least for Windows, was
in the 2.7 roadmap, but I can't find any related brach, or commit, or
post.
Also AFAIU would have some gains in both executable size and speed,
correct?


By now SEH is fully implemented for Win64 target, but you need to cycle the
compiler with OPT=-dTEST_WIN64_SEH to enable it.
The most of it was committed in revision 20098.

The effect of SEH is two-fold: it gives some performance gain when running
without exceptions, but big penalty when exceptions occur. It somewhat
reduces code size but at the same time adds some data, so executable size
may not reduce.

The main advantage of SEH is the conformance with OS exception handing
scheme. Without it, it was almost impossible to use DLLs that raise
exceptions.

Regards,
Sergei


Thanks. And are there any plans to implement it for Win32?


I don't know whether there are any plans, but I hope so...

Note: It should also be rather easy to implement SEH for arm-wince (and 
a possible future arm-winrt), because on ARM a similar exception 
mechanism is used by Windows/MSVC.


Regards,
Sven

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

Re: [fpc-devel] Status of SEH in FPC

[Sven Barth]

On 03.03.2013 17:52, Sven Barth wrote:

On 03.03.2013 17:45, Flávio Etrusco wrote:

On Sun, Mar 3, 2013 at 1:28 AM, Sergei Gorelkin
sergei_gorel...@mail.ru wrote:

03.03.2013 2:53, Flávio Etrusco пишет:


Hello,

what's the current state of the SEH in FPC trunk?
IIRC - and according to wikipedia ;-) - SEH, at least for Windows, was
in the 2.7 roadmap, but I can't find any related brach, or commit, or
post.
Also AFAIU would have some gains in both executable size and speed,
correct?


By now SEH is fully implemented for Win64 target, but you need to
cycle the
compiler with OPT=-dTEST_WIN64_SEH to enable it.
The most of it was committed in revision 20098.

The effect of SEH is two-fold: it gives some performance gain when
running
without exceptions, but big penalty when exceptions occur. It somewhat
reduces code size but at the same time adds some data, so executable
size
may not reduce.

The main advantage of SEH is the conformance with OS exception handing
scheme. Without it, it was almost impossible to use DLLs that raise
exceptions.

Regards,
Sergei


Thanks. And are there any plans to implement it for Win32?


I don't know whether there are any plans, but I hope so...


Just so that nobody misunderstands it: this does not mean that Sergei 
must be the one that implements it...


Regards,
Sven

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

[fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

[Martin Schreiber]

On Friday 01 March 2013 18:33:56 Martin Schreiber wrote:
[...]
On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3,
Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3):
http://gitorious.org/mseide-msegui

Command line Kylix 3:
dcc -D+ -Aclasses=Classes -Adateutils=DateUtils -Afmtbcd=FMTBcd 
-Amaskutils=MaskUtils -Astrutils=StrUtils -U${DCUS} -I../../lib/common/kernel 
-U../../lib/common/kernel -U../../lib/common/audio -U../../lib/common/opengl 
-U../../lib/common/report -U../../lib/common/db -U../../lib/common/crypto 
-U../../lib/common/graphics -U../../lib/common/i18n 
-U../../lib/common/kernel/linux -U../../lib/common/image 
-U../../lib/common/widgets -U../../lib/common/designutils 
-U../../lib/common/sysutils -U../../lib/common/editwidgets 
-U../../lib/common/dialogs -U../../lib/common/regcomponents 
-U../../lib/common/serialcomm -U../../lib/common/printer -U../../lib/common/ifi 
-U../../lib/common/math -U../../lib/common/delphicompatibility 
-U../../lib/common/fpccompatibility 
mseide.pas

Result Kylix 3:
488041 lines, 4.40 seconds, 2762044 bytes code, 1220304 bytes data.
-rwxr-xr-x 1 mse users 5092836 Mar  3 18:16 mseide

Command line FPC 2.6.2:
ppc386 -O2 -g -Xg -Xs -B -Fi../../lib/common/kernel -Fu../../lib/common/kernel 
-Fu../../lib/common/audio -Fu../../lib/common/opengl -Fu../../lib/common/report 
-Fu../../lib/common/db -Fu../../lib/common/crypto -Fu../../lib/common/graphics 
-Fu../../lib/common/i18n -Fu../../lib/common/kernel/linux 
-Fu../../lib/common/image -Fu../../lib/common/widgets 
-Fu../../lib/common/designutils -Fu../../lib/common/sysutils 
-Fu../../lib/common/editwidgets -Fu../../lib/common/dialogs 
-Fu../../lib/common/regcomponents -Fu../../lib/common/serialcomm 
-Fu../../lib/common/printer -Fu../../lib/common/ifi -Fu../../lib/common/math 
-Fu../../lib/common/delphicompatibility -Fu../../lib/common/fpccompatibility 
-omseidefp 
mseide.pas

Result FPC 2.6.2:
495971 lines compiled, 89.3 sec
-rwxr-xr-x 1 mse users 7463712 Mar  3 18:19 mseidefp

Please note that smartlinking with FPC is not possible on that system because 
it has 1GB ram only.

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Martin Schreiber]

Am 02.03.2013 11:11, schrieb Martin Schreiber:

On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:


Anyway, what seems obvious from your numbers is that it is the linking
stage that needs speedup. This does not really come as a surprise.


On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it
later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a
benchmark on Linux too.


I checked again, time of FPC linking stage is about 2.5 seconds.

Martin

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Marco van de Voort]

In our previous episode, Michael Van Canneyt said:
 I'm sorry, but I do not share your focus on speed. I have many projects, 
 some of them have more units than mseide does, and yet I never have to wait 
 more than a couple of seconds. The only exception is the Lazarus IDE.

No, I have also seen it with Indy and the JCL. In the JCL case I tried to
isolate it even, (and managed to 3 or 4 units). 

And over the years, that are not the only cases.

 If you say that mseide only compiles with -B, I would suggest looking for 
 strange dependencies inside mseide, if you want to reduce compile time...

No, afaik there is certainly a problem in the compiler. Afaik I heard devs
that unit dependencies cycles with more than two units are not always
detected clearly (and probably that implies some hidden
interface-implementation dependencies?)
   
 I do not want to say that FPC does not need speed improvements, but I do 
 suspect you 
 will get faster results looking at removing the -B requirement from mseide...

That's for sure. 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Thank you for ARMV6M!!!

[Michael Ring]

I just saw that armv6m has showed up in the sourcecode of trunk version.

You guys are great, thank you very much

I just checked, I do have a LPCXpresso LPC812 Board here, now I can put 
it to good use!


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

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

[Michael Van Canneyt]

On Sun, 3 Mar 2013, Martin Schreiber wrote:


On Friday 01 March 2013 18:33:56 Martin Schreiber wrote:
[...]
On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3,
Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3):
http://gitorious.org/mseide-msegui


Impressive.

Now that we've clearly established that FPC is slower than Delphi, 
and that you consider this a serious problem (which we, in fact, 
know since some time):


When can we expect to see some constructive proposals on how to 
improve the situation?


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

[fpc-devel] ppcrossarm dies when trying to build embedded rtl (svn 23683)

[Michael Ring]

I am running on a mac, building svn 23683

svn 23681 (one before implementation of armv6m) compiles fine.

commandline for building was:

make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm 
SUBARCH=armv7m CROSSOPT=-gw2 -O- BINUTILSPREFIX=arm-none-eabi-



make -C rtl all
make -C embedded all
/bin/mkdir -p /Users/ring/devel/fpc/rtl/units/arm-embedded
/Users/ring/devel/fpc/compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur 
-Tembedded -Parm -XParm-none-eabi- -Xr -Ur -Xs -O2 -n -Fi../inc 
-Fi../arm -FE. -FU/Users/ring/devel/fpc/rtl/units/arm-embedded -darm 
-dRELEASE -gw2 -O- -Us -Sg system.pp

Fatal: Compilation aborted
An unhandled exception occurred at $:
EAccessViolation: Access violation
  $
  $00142333
  $00144647
  $00144B00
  $001AF725
  $001970A5
  $0003295E

make[3]: *** [system.ppu] Error 217
make[2]: *** [embedded_all] Error 2
make[1]: *** [rtl_all] Error 2
make: *** [base.build-stamp.arm-embedded] Error 2
[
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

[Martin Schreiber]

On Sunday 03 March 2013 20:08:43 Michael Van Canneyt wrote:
 On Sun, 3 Mar 2013, Martin Schreiber wrote:
  On Friday 01 March 2013 18:33:56 Martin Schreiber wrote:
  [...]
  On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3,
  Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3):
  http://gitorious.org/mseide-msegui

 Impressive.

 Now that we've clearly established that FPC is slower than Delphi,
 and that you consider this a serious problem (which we, in fact,
 know since some time):

 When can we expect to see some constructive proposals on how to
 improve the situation?

I supplied the benchmark, more than 10 man years of development time. A good 
start, no? ;-)

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

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

[Florian Klämpfl]

Am 03.03.2013 20:40, schrieb Martin Schreiber:
 On Sunday 03 March 2013 20:08:43 Michael Van Canneyt wrote:
 On Sun, 3 Mar 2013, Martin Schreiber wrote:
 On Friday 01 March 2013 18:33:56 Martin Schreiber wrote:
 [...]
 On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3,
 Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3):
 http://gitorious.org/mseide-msegui

 Impressive.

 Now that we've clearly established that FPC is slower than Delphi,
 and that you consider this a serious problem (which we, in fact,
 know since some time):

 When can we expect to see some constructive proposals on how to
 improve the situation?

 I supplied the benchmark, more than 10 man years of development time. A good 
 start, no? ;-)

First 10 m of a marathon done.

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

Re: [fpc-devel] Thank you for ARMV6M!!!

[Florian Klämpfl]

Am 03.03.2013 19:51, schrieb Michael Ring:
 I just saw that armv6m has showed up in the sourcecode of trunk version.
 
 You guys are great, thank you very much
 
 I just checked, I do have a LPCXpresso LPC812 Board here, now I can put
 it to good use!

Note that it is still work in progress. If you are interested in it,
having an startup unit for lpc812 would be nice ;)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

[Graeme Geldenhuys]

On 2013-03-03 19:47, Florian Klämpfl wrote:
 
 First 10 m of a marathon done.


Is that 'miles' or 'meters'?  ;-)


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

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

Re: [fpc-devel] Thank you for ARMV6M!!!

[Michael Ring]

I've already downloaded the latest Datasheet from NXP ;-)

I am very glad that I decided to switch from closed source compilers 
from mikroe.com to freepascal, the current speed of development for 
embedded target is quite impressive and in many areas I can help myself 
because everything is open source.


Michael






Am 03.03.13 20:56, schrieb Florian Klämpfl:

Am 03.03.2013 19:51, schrieb Michael Ring:

I just saw that armv6m has showed up in the sourcecode of trunk version.

You guys are great, thank you very much

I just checked, I do have a LPCXpresso LPC812 Board here, now I can put
it to good use!

Note that it is still work in progress. If you are interested in it,
having an startup unit for lpc812 would be nice ;)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel



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

Re: [fpc-devel] ppcrossarm dies when trying to build embedded rtl (svn 23683)

[Michael Ring]

I have created a new patch, this time it uses the values of the two 
commandline parameters -Ch and -Cs to set the size of Stack and Heap. I 
am not sure if those params were for this use case but in my opinion it 
makes sense.


Florian, could I ask you to apply the patch to trunk if what I am doing 
is is ok?



Index: rtl/embedded/heapmgr.pp
===
--- rtl/embedded/heapmgr.pp(revision 23681)
+++ rtl/embedded/heapmgr.pp(working copy)
@@ -34,7 +34,13 @@

 var
   Blocks: PHeapBlock = nil;
+  _heap_start : pointer;
+  _heapsize: longWord; external name '__heapsize';
+  _stklen: longword; external name '__stklen';
+  _bss_end: record end; external name '_bss_end';
+  _stack_top: record end; external name '_stack_top';

+
 procedure InternalFreeMem(Addr: Pointer; Size: ptruint); forward;

 function FindSize(p: pointer): ptruint;
@@ -242,6 +248,11 @@

 initialization
   SetMemoryManager(MyMemoryManager);
+  _heap_start := @_stack_top - _heapsize - _stklen;
+  // Only initialize Heap when there is enough space available
+  if _heap_start = @_bss_end then
+RegisterHeapBlock(_heap_start,_heapsize);
+
 finalization
   //FinalizeHeap;
 end.





Am 03.03.13 20:09, schrieb Michael Ring:

I am running on a mac, building svn 23683

svn 23681 (one before implementation of armv6m) compiles fine.

commandline for building was:

make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm 
SUBARCH=armv7m CROSSOPT=-gw2 -O- BINUTILSPREFIX=arm-none-eabi-



make -C rtl all
make -C embedded all
/bin/mkdir -p /Users/ring/devel/fpc/rtl/units/arm-embedded
/Users/ring/devel/fpc/compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur 
-Tembedded -Parm -XParm-none-eabi- -Xr -Ur -Xs -O2 -n -Fi../inc 
-Fi../arm -FE. -FU/Users/ring/devel/fpc/rtl/units/arm-embedded -darm 
-dRELEASE -gw2 -O- -Us -Sg system.pp

Fatal: Compilation aborted
An unhandled exception occurred at $:
EAccessViolation: Access violation
  $
  $00142333
  $00144647
  $00144B00
  $001AF725
  $001970A5
  $0003295E

make[3]: *** [system.ppu] Error 217
make[2]: *** [embedded_all] Error 2
make[1]: *** [rtl_all] Error 2
make: *** [base.build-stamp.arm-embedded] Error 2
[
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel



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

Re: [fpc-devel] ppcrossarm dies when trying to build embedded rtl (svn 23683)

[Florian Klämpfl]

Am 03.03.2013 21:27, schrieb Michael Ring:
 I have created a new patch, this time it uses the values of the two
 commandline parameters -Ch and -Cs to set the size of Stack and Heap. I
 am not sure if those params were for this use case but in my opinion it
 makes sense.
 
 Florian, could I ask you to apply the patch to trunk if what I am doing
 is is ok?

It looks reasonable, but after some thinking I came to the conclusion
that maybe the heap should be already allocated during linking, i.e. so
heapmgr does not need to calculate an _heap_start.

 
 
 Index: rtl/embedded/heapmgr.pp
 ===
 --- rtl/embedded/heapmgr.pp(revision 23681)
 +++ rtl/embedded/heapmgr.pp(working copy)
 @@ -34,7 +34,13 @@
 
  var
Blocks: PHeapBlock = nil;
 +  _heap_start : pointer;
 +  _heapsize: longWord; external name '__heapsize';
 +  _stklen: longword; external name '__stklen';
 +  _bss_end: record end; external name '_bss_end';
 +  _stack_top: record end; external name '_stack_top';
 
 +
  procedure InternalFreeMem(Addr: Pointer; Size: ptruint); forward;
 
  function FindSize(p: pointer): ptruint;
 @@ -242,6 +248,11 @@
 
  initialization
SetMemoryManager(MyMemoryManager);
 +  _heap_start := @_stack_top - _heapsize - _stklen;
 +  // Only initialize Heap when there is enough space available
 +  if _heap_start = @_bss_end then
 +RegisterHeapBlock(_heap_start,_heapsize);
 +
  finalization
//FinalizeHeap;
  end.
 
 
 
 
 
 Am 03.03.13 20:09, schrieb Michael Ring:
 I am running on a mac, building svn 23683

 svn 23681 (one before implementation of armv6m) compiles fine.

 commandline for building was:

 make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
 SUBARCH=armv7m CROSSOPT=-gw2 -O- BINUTILSPREFIX=arm-none-eabi-


 make -C rtl all
 make -C embedded all
 /bin/mkdir -p /Users/ring/devel/fpc/rtl/units/arm-embedded
 /Users/ring/devel/fpc/compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur
 -Tembedded -Parm -XParm-none-eabi- -Xr -Ur -Xs -O2 -n -Fi../inc
 -Fi../arm -FE. -FU/Users/ring/devel/fpc/rtl/units/arm-embedded -darm
 -dRELEASE -gw2 -O- -Us -Sg system.pp
 Fatal: Compilation aborted
 An unhandled exception occurred at $:
 EAccessViolation: Access violation
   $
   $00142333
   $00144647
   $00144B00
   $001AF725
   $001970A5
   $0003295E

 make[3]: *** [system.ppu] Error 217
 make[2]: *** [embedded_all] Error 2
 make[1]: *** [rtl_all] Error 2
 make: *** [base.build-stamp.arm-embedded] Error 2
 [
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-devel

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

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

Re: [fpc-devel] ppcrossarm dies when trying to build embedded rtl (svn 23683)

[Michel Catudal]

On 2013-03-03 14:09, Michael Ring wrote:

I am running on a mac, building svn 23683

svn 23681 (one before implementation of armv6m) compiles fine.

commandline for building was:

make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm 
SUBARCH=armv7m CROSSOPT=-gw2 -O- BINUTILSPREFIX=arm-none-eabi-



make -C rtl all
make -C embedded all
/bin/mkdir -p /Users/ring/devel/fpc/rtl/units/arm-embedded
/Users/ring/devel/fpc/compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur 
-Tembedded -Parm -XParm-none-eabi- -Xr -Ur -Xs -O2 -n -Fi../inc 
-Fi../arm -FE. -FU/Users/ring/devel/fpc/rtl/units/arm-embedded -darm 
-dRELEASE -gw2 -O- -Us -Sg system.pp

Fatal: Compilation aborted
An unhandled exception occurred at $:
EAccessViolation: Access violation
  $
  $00142333
  $00144647
  $00144B00
  $001AF725
  $001970A5
  $0003295E

make[3]: *** [system.ppu] Error 217
make[2]: *** [embedded_all] Error 2
make[1]: *** [rtl_all] Error 2
make: *** [base.build-stamp.arm-embedded] Error 2
[
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Interesting, I have a similar problem with AVR32.

--
For Linux Software visit
http://home.comcast.net/~mcatudal

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

Re: [fpc-devel] arm-embedded apps crash in exception handler initialization because heapmanager is not initialized

[Michael Ring]

That would of course be even better, the compiler could calculate if 
vars+stack+heap fit in the given memory configuration and issue at 
minimum a warning or even better a compile error.


But this is definitely something that is out of my league, Florin, could 
you implement this?


Michael


Am 03.03.13 21:45, schrieb Florian Klämpfl:
 Am 03.03.2013 21:27, schrieb Michael Ring:
 I have created a new patch, this time it uses the values of the two
 commandline parameters -Ch and -Cs to set the size of Stack and Heap. I
 am not sure if those params were for this use case but in my opinion it
 makes sense.

 Florian, could I ask you to apply the patch to trunk if what I am doing
 is is ok?

 It looks reasonable, but after some thinking I came to the conclusion
 that maybe the heap should be already allocated during linking, i.e. so
 heapmgr does not need to calculate an _heap_start.



 Index: rtl/embedded/heapmgr.pp
 ===
 --- rtl/embedded/heapmgr.pp(revision 23681)
 +++ rtl/embedded/heapmgr.pp(working copy)
 @@ -34,7 +34,13 @@

  var
Blocks: PHeapBlock = nil;
 +  _heap_start : pointer;
 +  _heapsize: longWord; external name '__heapsize';
 +  _stklen: longword; external name '__stklen';
 +  _bss_end: record end; external name '_bss_end';
 +  _stack_top: record end; external name '_stack_top';

 +
  procedure InternalFreeMem(Addr: Pointer; Size: ptruint); forward;

  function FindSize(p: pointer): ptruint;
 @@ -242,6 +248,11 @@

  initialization
SetMemoryManager(MyMemoryManager);
 +  _heap_start := @_stack_top - _heapsize - _stklen;
 +  // Only initialize Heap when there is enough space available
 +  if _heap_start = @_bss_end then
 +RegisterHeapBlock(_heap_start,_heapsize);
 +
  finalization
//FinalizeHeap;
  end.




Am 03.03.13 12:36, schrieb Michael Ring:

This helped me to understand another puzzle piece.

Please correct me if I am wrong:

sram - Memory is divided in several areas on arm-embedded:

_data starts at start of sram ($2000 in my case)
_edata is end of _data segment ($29b4)
_bss_start defines start of static vars ($29b4)
_bss_end defines end of static vars ($2e90)

all memory from here on is used for stack, stack grows from end of 
avaliable sram ($2001) downto _bss_end


so what I could do is allocate memory for heap starting at address 
_bss_end with the size of _heapsize. or, perhaps even better:


I start using memory at address _stack_top - _stklen - _heapsize

Correct ??

Michael

Am 03.03.13 11:14, schrieb Sven Barth:

On 03.03.2013 11:04, Michael Ring wrote:

For a little more flexible solution I would like to ask you one more
questions, it may seem dumb to you but I have never been that deep into
a compiler before so I am learning a lot atm.

I can see that the compiler param -Ch can be used to define the
heapsize, I can also see in the assembler code of my main program that
when I set -Ch I also get a section:

-Ch2048 results in this:

.section .data.n___heapsize
 .balign 4
.globl  __heapsize
__heapsize:
 .long   2048

but I do not seem to be able to access __heapsize in my code, how could
I use this information to make the heapsize configurable?


Did you try

=== code begin ===

var
  heapsize: LongWord; external name '__heapsize';

=== code end ===

?

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel



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



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

Re: [fpc-devel] arm-embedded apps crash in exception handler initialization because heapmanager is not initialized

[Florian Klämpfl]

Am 03.03.2013 22:09, schrieb Michael Ring:
 That would of course be even better, the compiler could calculate if
 vars+stack+heap fit in the given memory configuration and issue at
 minimum a warning or even better a compile error.
 
 But this is definitely something that is out of my league, Florin, could
 you implement this?


I'll look into this the next days.

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

Re: [fpc-devel] ppcrossarm dies when trying to build embedded rtl (svn 23683)

[Florian Klämpfl]

Am 03.03.2013 20:09, schrieb Michael Ring:
   $
   $00142333
   $00144647
   $00144B00
   $001AF725
   $001970A5
   $0003295E
 
 make[3]: *** [system.ppu] Error 217
 make[2]: *** [embedded_all] Error 2
 make[1]: *** [rtl_all] Error 2
 make: *** [base.build-stamp.arm-embedded] Error 2

Fixed.

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

Re: [fpc-devel] ppcrossarm dies when trying to build embedded rtl (svn 23683)

[Michael Ring]

Verified, works again on my mac, TnX!

Michael

Am 03.03.13 23:00, schrieb Florian Klämpfl:

Am 03.03.2013 20:09, schrieb Michael Ring:

   $
   $00142333
   $00144647
   $00144B00
   $001AF725
   $001970A5
   $0003295E

make[3]: *** [system.ppu] Error 217
make[2]: *** [embedded_all] Error 2
make[1]: *** [rtl_all] Error 2
make: *** [base.build-stamp.arm-embedded] Error 2

Fixed.

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



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

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

[Marcos Douglas]

On Sun, Mar 3, 2013 at 5:16 PM, Graeme Geldenhuys
gra...@geldenhuys.co.uk wrote:

 On 2013-03-03 19:47, Florian Klämpfl wrote:
 
  First 10 m of a marathon done.


 Is that 'miles' or 'meters'?  ;-)

Sad. Instead of fight, why not walking together?

IMHO Martin Schreiber is doing a great job using these comparisons and
some improvements could be made in FPC... but he is making a mistake
in their approach of how to present FPC's defects.

Martin:
I do not know nothing about compilers, but I know the Florian Klämpfl
will do nothing about you're saying because do you do not have
proposed improvements! You are only showing the Delphi/Kylix speed is
extremely superior (even knowing that Delphi do not is multiplataform
and do not have the complexity that FPC has, AFAIK).
One more thing: try do not thinking only in MSEgui in your thoughts,
in your great ideas.
IMHO the MSEgui should be part of FPC, somehow, but...

FPC Team:
Try to hear Martin otherwise, because he is a great developer with great ideas.

Best regards,
Marcos Douglas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

[Vittorio Giovara]

On 04/mar/2013, at 00:21, Marcos Douglas m...@delfire.net wrote:

 On Sun, Mar 3, 2013 at 5:16 PM, Graeme Geldenhuys
 gra...@geldenhuys.co.uk wrote:

 On 2013-03-03 19:47, Florian Klämpfl wrote:

 First 10 m of a marathon done.


 Is that 'miles' or 'meters'?  ;-)

 Sad. Instead of fight, why not walking together?

 IMHO Martin Schreiber is doing a great job using these comparisons and
 some improvements could be made in FPC... but he is making a mistake
 in their approach of how to present FPC's defects.

I am not so sure about this... I know nothing of dcc switches but he
is comparing the compiler speed with a different set of features, it
is easy to spot how flawed the comparison is: -O2 -Xg -Xs are all
optimization flags and it is expected that optimizing code takes time.

Could be interesting to see the speed and size of the binary produced
by the two compilers, slower compilation time over faster or smaller
code is something I would pick any time!

 FPC Team:
 Try to hear Martin otherwise, because he is a great developer with great 
 ideas.

I am no fpc dev here, but patches are welcome I guess.

Jm2c
Vittorio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

[Marcos Douglas]

On Sun, Mar 3, 2013 at 8:29 PM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
 On 04/mar/2013, at 00:21, Marcos Douglas m...@delfire.net wrote:

 [cut]

 FPC Team:
 Try to hear Martin otherwise, because he is a great developer with great 
 ideas.

 I am no fpc dev here, but patches are welcome I guess.

That's what I meant when I spoke he is making a mistake in their
approach of how to present FPC's defects.

Marcos Douglas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

[Graeme Geldenhuys]

On 2013-03-03 23:21, Marcos Douglas wrote:
 
 Sad. Instead of fight, why not walking together?

I'm not joining any fight, simply wanted to know what the 'm' stood for.


 I do not know nothing about compilers, but I know the Florian Klämpfl
 will do nothing about you're saying because do you do not have
 proposed improvements!

You said it yourself... most of us know nothing about compiler coding.
So how are we supposed to propose improvements! All we can do is file
bug reports on things we can duplicate, or highlight issues. This is
what Martin is doing here.

4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That
is just too a huge performance difference to justify. Yes, we all know
the argument about more platforms, maintainable code etc, but that
couldn't possible be the only reason for such a huge speed difference.
Somewhere there is a serious bottleneck(s), or the FPC team simply
disregard optimization completely. From why I have heard them say, the
latter is more likely [unfortunately].

But let me repeat what you said earlier. Some of use know nothing about
compilers coding, so not much we can do about it. The task falls
squarely on the select few, but they have no interest in that.
Optimization is boring work, compared to implementing the latest CPU
target or language feature. I understand that fully. A great pity.


 You are only showing the Delphi/Kylix speed is
 extremely superior

And Martin is just showing half the problem. The Delphi  Kylix
compilers also produce executables that run 10+ times faster than what
FPC 2.6.0 can produce. Even on the more optimized 32-bit compiler. And
don't even think of mentioning that faster hardware will mask the
problem - it doesn't. I have a i7-2660K running at 3.6Ghz with high
performance RAM and 450MB read speed SSD. I noticed a  10+ times
difference in running executables on my hardware.

And comments from Florian like expect FPC to get even slower by the
next release doesn't help much.

Nobody expects FPC to beat Delphi or Kylix performance, but FPC
degrading its speed (compile time and executable run time) year-on-year
is not a good sign for the long run.


Anyway, this is nothing new. I mentioned this long ago, and made my
peace with it. I have to cherish the fact that FPC is luckily still
faster that C/C++ compilers.

Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

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

Re: [fpc-devel] Delphi anonymous methods

[Graeme Geldenhuys]

On 2013-03-02 19:03, vrt277 wrote:
 
 I want to implement support of Delphi anonymous methods for fpc.


Just curious... why must such a feature be allowed in Object Pascal?
Referring to the recent butchering of the Object Pascal language
thread we had recently in fpc-pascal.

It was clearly stated in the past that FPC will not support the C/C++
language feature of declaration a variable in-line inside code blocks,
but only in var sections.

Example of not allowed code:

  for i: integer = 0 to 10 do
  begin
  end;

or

  var
s: string;
  begin
s := 'string'
...
i: integer := 0; // I must be declared in var section instead
Inc(i, 5);
...
  end;


From what I can see, anonymous methods are just like the above code...
allowing a declaration of a procedure/method in-line inside a code block
where in shouldn't belong. It is very, very un-Pascal like. The end
result is unreadable code, probably hard to debug etc.


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

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

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

[Marcos Douglas]

On Sun, Mar 3, 2013 at 9:00 PM, Graeme Geldenhuys
gra...@geldenhuys.co.uk wrote:
 On 2013-03-03 23:21, Marcos Douglas wrote:

 Sad. Instead of fight, why not walking together?

 I'm not joining any fight, simply wanted to know what the 'm' stood for.

I know. I just used the last mail on this thread -- in that case, your
mail. Sorry.

 I do not know nothing about compilers, but I know the Florian Klämpfl
 will do nothing about you're saying because do you do not have
 proposed improvements!

 You said it yourself... most of us know nothing about compiler coding.
 So how are we supposed to propose improvements! All we can do is file
 bug reports on things we can duplicate, or highlight issues. This is
 what Martin is doing here.

Yes, I agree... but I feel a fight between Martin and FPC Team,
don't you agree?

 4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That
 is just too a huge performance difference to justify. Yes, we all know
 the argument about more platforms, maintainable code etc, but that
 couldn't possible be the only reason for such a huge speed difference.
 Somewhere there is a serious bottleneck(s), or the FPC team simply
 disregard optimization completely. From why I have heard them say, the
 latter is more likely [unfortunately].

 But let me repeat what you said earlier. Some of use know nothing about
 compilers coding, so not much we can do about it. The task falls
 squarely on the select few, but they have no interest in that.
 Optimization is boring work, compared to implementing the latest CPU
 target or language feature. I understand that fully. A great pity.

I feel the same... but we can not force people who work for free to do
tasks that are not important to them.

 You are only showing the Delphi/Kylix speed is
 extremely superior

 And Martin is just showing half the problem. The Delphi  Kylix
 compilers also produce executables that run 10+ times faster than what
 FPC 2.6.0 can produce. Even on the more optimized 32-bit compiler. And
 don't even think of mentioning that faster hardware will mask the
 problem - it doesn't. I have a i7-2660K running at 3.6Ghz with high
 performance RAM and 450MB read speed SSD. I noticed a  10+ times
 difference in running executables on my hardware.

Again I repeat: I agree with you.
The Pascal is known because it is simple, elegant,  [,,,] and FAST.

 And comments from Florian like expect FPC to get even slower by the
 next release doesn't help much.

Yeah... very sad.

 Nobody expects FPC to beat Delphi or Kylix performance, but FPC
 degrading its speed (compile time and executable run time) year-on-year
 is not a good sign for the long run.

Many many improvements trying to following Delphi, Java, whatever.

 Anyway, this is nothing new. I mentioned this long ago, and made my
 peace with it. I have to cherish the fact that FPC is luckily still
 faster that C/C++ compilers.

For the time being... :)

Marcos Douglas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

[Marcos Douglas]

On Sun, Mar 3, 2013 at 9:15 PM, Graeme Geldenhuys
gra...@geldenhuys.co.uk wrote:
 On 2013-03-02 19:03, vrt277 wrote:

 I want to implement support of Delphi anonymous methods for fpc.


 Just curious... why must such a feature be allowed in Object Pascal?
 Referring to the recent butchering of the Object Pascal language
 thread we had recently in fpc-pascal.

 It was clearly stated in the past that FPC will not support the C/C++
 language feature of declaration a variable in-line inside code blocks,
 but only in var sections.

 Example of not allowed code:

   for i: integer = 0 to 10 do
   begin
   end;

 or

   var
 s: string;
   begin
 s := 'string'
 ...
 i: integer := 0; // I must be declared in var section instead
 Inc(i, 5);
 ...
   end;


 From what I can see, anonymous methods are just like the above code...
 allowing a declaration of a procedure/method in-line inside a code block
 where in shouldn't belong. It is very, very un-Pascal like. The end
 result is unreadable code, probably hard to debug etc.

+1

Marcos Douglas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

[Boian Mitov]

Strongly disagree.
Anonymous methods are a critical feature of any mother language, and allow 
vast improvements of the code and the readability. I recently started 
rewriting our libraries with anonymous methods and that alone allowed for 
cutting over 2 lines of code, while adding vast number of new features. 
Any language that does not support anonymous methods is just a joke IMHO.


If you have never developed with them, (as was I), you never know what you 
have been missing. They are actually more important than having object 
oriented support IMHO.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---



From what I can see, anonymous methods are just like the above code...

allowing a declaration of a procedure/method in-line inside a code block
where in shouldn't belong. It is very, very un-Pascal like. The end
result is unreadable code, probably hard to debug etc.


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

Re: [fpc-devel] Delphi anonymous methods

[Martin]

On 04/03/2013 01:47, Boian Mitov wrote:

Strongly disagree.
Anonymous methods are a critical feature of any mother language, and 
allow vast improvements of the code and the readability. I recently 
started rewriting our libraries with anonymous methods and that alone 
allowed for cutting over 2 lines of code, while adding vast number 
of new features. Any language that does not support anonymous methods 
is just a joke IMHO.


Really, just by dropping the names? Or did you mean, you did all that by 
using closures?



From what I can see, anonymous methods are just like the above code...

allowing a declaration of a procedure/method in-line inside a code block
where in shouldn't belong. It is very, very un-Pascal like. The end
result is unreadable code, probably hard to debug etc.


Closures, do not need to be written/declared in the middle of other code 
(in-line)

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

Re: [fpc-devel] Delphi anonymous methods

[Boian Mitov]

Yes, really!
Then again this is over 4 mln mines of code after all. :-D
Thank you for letting me know what closure is :-D . Can you imagine, me 
being component vendor for over 16 years and not knowing what closure is 
:-D.
Anonymous methods lead to a different way of thinking altogether and allow 
you to do things that you can't even imagine with closures ;-) .
And they make the code infinitely easier to read, especially if like me this 
is a huge codebase ;-) . After all we sell well over 400 components not to 
mention some of our other Delphi based products ;-) .
Sure, if you have small code you can do just fine with closures, as I have 
for many years, then again I did just fine without having classes, and 
objects in the old days, and also did fine in the older days in Assembler 
:-D .
So according to this logic, we really should be doing everything in machine 
code (as I actually did briefly 24 years ago :-D ), who needs new features 
such as those whatmacallit... ohhh yeahh... compilers :-D .


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Martin

Sent: Sunday, March 03, 2013 7:38 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

On 04/03/2013 01:47, Boian Mitov wrote:
Really, just by dropping the names? Or did you mean, you did all that by
using closures?

Closures, do not need to be written/declared in the middle of other code
(in-line)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel 


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

Re: [fpc-devel] Delphi anonymous methods

[Boian Mitov]

Actually the biggest benefit was that it now allows me to design parallel 
execution code of complexity I was not able to design otherwise. I am just 
starting to scratch the surface. Hell... I have not even started really 
using the anonymous methods yet :-D .


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Martin

Sent: Sunday, March 03, 2013 7:38 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

On 04/03/2013 01:47, Boian Mitov wrote:
Really, just by dropping the names? Or did you mean, you did all that by
using closures?


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

Re: [fpc-devel] Delphi anonymous methods

[Alexander Klenin]

On Mon, Mar 4, 2013 at 11:15 AM, Graeme Geldenhuys
gra...@geldenhuys.co.uk wrote:
 From what I can see, anonymous methods are just like the above code...
 allowing a declaration of a procedure/method in-line inside a code block
 where in shouldn't belong. It is very, very un-Pascal like.

Because computer science is advancing, and there is a limit after which
programming language can not ignore those advancements and stay relevant.
Imagine Pascal without records, or enumerated types, or properties, or
built-in strings.
These are all revolutionary features that were introduced to the language at
various stages of its development -- some at the inception, some later.
Now, that does not mean that a particular Delphi implementation of
some features is optimal, and we do discuss options in this thread.

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

[Boian Mitov]

100% agree revolutionary is a very good word to describe it indeed! :-) .
I remember people asking in the old days, why we need objects. Those ware 
old school Pascal people claiming that they can do just fine with records, 
and who needs classes :-D . They ware so un Pascal ! :-D .

I am not kidding, I really new such people personally :-D .

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Alexander Klenin

Sent: Sunday, March 03, 2013 7:59 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

These are all revolutionary features that were introduced to the language 
at

various stages of its development -- some at the inception, some later.

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

Re: [fpc-devel] Delphi anonymous methods

[Martin]

On 04/03/2013 03:49, Boian Mitov wrote:

Yes, really!
Then again this is over 4 mln mines of code after all. :-D
Thank you for letting me know what closure is :-D . Can you imagine, 
me being component vendor for over 16 years and not knowing what 
closure is :-D.
Did I? Wow, I didn't know I did. Didn't mean to neither. I was just 
checking, if you accidentally used the wrong word. (Happens to everyone, 
even the very best / so no judgement implied)


Anonymous methods lead to a different way of thinking altogether and 
allow you to do things that you can't even imagine with closures ;-) .
And they make the code infinitely easier to read, especially if like 
me this is a huge codebase ;-) . After all we sell well over 400 
components not to mention some of our other Delphi based products ;-) .
Sure, if you have small code you can do just fine with closures, as I 
have for many years, then again I did just fine without having 
classes, and objects in the old days, and also did fine in the older 
days in Assembler :-D .
So according to this logic, we really should be doing everything in 
machine code (as I actually did briefly 24 years ago :-D ), who needs 
new features such as those whatmacallit... ohhh yeahh... compilers 
:-D .
Well I give you the benefit of the doubt, and believe you. But that does 
not help me, because I still do not know which case you are talking 
about So for my benefit, please enlighten me with an example.


From your above statement, I take, that you already used closures, and 
that the big improvements really happened of a result of anonymous methods.
Just to be save, let me state the obvious: We are talking of dropping 
the function name; and introducing the ability, to declare the function 
anywhere within the code (probably the latter being the important). That 
are the 2 only things, that anonymous methods do offer? (OR am I missing 
anything?)


If so then I do not see how they save 2 lines?
- The name is part of the declaration line, SO it should not affect the 
line count at all). Unless you always write the name on a separate line 
(which I would consider a very special case)

- the place of declaration also does not change the line count.



-Original Message- From: Martin
Sent: Sunday, March 03, 2013 7:38 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

On 04/03/2013 01:47, Boian Mitov wrote:
Really, just by dropping the names? Or did you mean, you did all that by
using closures?

Closures, do not need to be written/declared in the middle of other code
(in-line)


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

Re: [fpc-devel] Delphi anonymous methods

[Boian Mitov]

Here is example:

Parallel execution with selection of executor:

for i := 0 to AMaxScaleIndex - 1 do
 begin
 APerIterationLocations.Add( TRTDynamicListTVLImageRect.Create() );
 AExecutionTask.Add( AExecutor.Execute(
 procedure()
 begin
   ProcessOne( levelScale[ i ], img, hitThreshold, winStride, padding, 
APerIterationLocations[ i ] );

 end
   ));

 end;

In this case, not only you save declaration, you save the need to write a 
whole new class just for the task.

This code reduced well over 30 lines of code alone.
I have a lot of other examples as well ;-) .

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Martin

Sent: Sunday, March 03, 2013 8:42 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

On 04/03/2013 03:49, Boian Mitov wrote:
Well I give you the benefit of the doubt, and believe you. But that does
not help me, because I still do not know which case you are talking
about So for my benefit, please enlighten me with an example.


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

Re: [fpc-devel] Delphi anonymous methods

[Boian Mitov]

One thing for sure, I probably will very much never need to declare TThread 
inherited classes. I can use a single anonymous method for that, thanks to 
the ability of the anonymous method to capture local and member variables.
This is something not doable with closure as it has fixed number of 
parameters ;-) .


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Boian Mitov

Sent: Sunday, March 03, 2013 8:54 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

Here is example:

Parallel execution with selection of executor:

for i := 0 to AMaxScaleIndex - 1 do
 begin
 APerIterationLocations.Add( TRTDynamicListTVLImageRect.Create() );
 AExecutionTask.Add( AExecutor.Execute(
 procedure()
 begin
   ProcessOne( levelScale[ i ], img, hitThreshold, winStride, padding,
APerIterationLocations[ i ] );
 end
   ));

 end;

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

Re: [fpc-devel] Delphi anonymous methods

[Boian Mitov]

Here is another even simpler example:

AItem := GComponentEditorList.Find(
   function( AItem : IComponentEditorItem ) : Boolean
   begin
 Result := ( AComponent is 
AItem.GetInstance().ComponentClass );

   end
);


In this case you will either need additional member class variable (It will 
increase the memory usage), or you will need to declare a whole class just 
to achieve what I do with one line of code :-) . Sweet! :-)



With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Martin

Sent: Sunday, March 03, 2013 8:42 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

On 04/03/2013 03:49, Boian Mitov wrote:

Yes, really!
Then again this is over 4 mln mines of code after all. :-D
Thank you for letting me know what closure is :-D . Can you imagine, me 
being component vendor for over 16 years and not knowing what closure is 
:-D.

Did I? Wow, I didn't know I did. Didn't mean to neither. I was just
checking, if you accidentally used the wrong word. (Happens to everyone,
even the very best / so no judgement implied)

Anonymous methods lead to a different way of thinking altogether and allow 
you to do things that you can't even imagine with closures ;-) .
And they make the code infinitely easier to read, especially if like me 
this is a huge codebase ;-) . After all we sell well over 400 components 
not to mention some of our other Delphi based products ;-) .
Sure, if you have small code you can do just fine with closures, as I have 
for many years, then again I did just fine without having classes, and 
objects in the old days, and also did fine in the older days in Assembler 
:-D .
So according to this logic, we really should be doing everything in 
machine code (as I actually did briefly 24 years ago :-D ), who needs new 
features such as those whatmacallit... ohhh yeahh... compilers :-D .

Well I give you the benefit of the doubt, and believe you. But that does
not help me, because I still do not know which case you are talking
about So for my benefit, please enlighten me with an example.


From your above statement, I take, that you already used closures, and

that the big improvements really happened of a result of anonymous methods.
Just to be save, let me state the obvious: We are talking of dropping
the function name; and introducing the ability, to declare the function
anywhere within the code (probably the latter being the important). That
are the 2 only things, that anonymous methods do offer? (OR am I missing
anything?)

If so then I do not see how they save 2 lines?
- The name is part of the declaration line, SO it should not affect the
line count at all). Unless you always write the name on a separate line
(which I would consider a very special case)
- the place of declaration also does not change the line count.



-Original Message- From: Martin
Sent: Sunday, March 03, 2013 7:38 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

On 04/03/2013 01:47, Boian Mitov wrote:
Really, just by dropping the names? Or did you mean, you did all that by
using closures?

Closures, do not need to be written/declared in the middle of other code
(in-line)


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


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

Re: [fpc-devel] Delphi anonymous methods

[Boian Mitov]

Or even more drastic example like this one:

AAttributes := TRTRtti.GetType( 
Component.ClassType() ).GetCustomAttributes( 
TVLCommonFilterHostedPreviewAttribute, True );

for AAttribute in AAttributes do
 if( AAttribute is TLPComponentEditorAttribute ) then
   begin
   AAttrItem := GComponentEditorAttributeList.Find(
 function( AItem : IComponentEditorAttributeItem ) : 
Boolean

 var
   AAttributes : IRTAttributes;
   AAttributeClass : TCustomAttributeClass;

 begin
   AAttributeClass := 
AItem.GetInstance().AttributeClass;
   AAttributes := TRTRtti.GetType( 
Component.ClassType() ).GetCustomAttributes( TLPSuppressAttribute, True );

   if( AAttributes.Find(
   function ( ASupressAttribute : 
TCustomAttribute ) : Boolean

   begin
 Result := ( AAttributeClass = 
TLPSuppressAttribute( ASupressAttribute ).Attribute );

   end
 )  NIL ) then
 Exit( False );

   Result := ( AAttribute is AAttributeClass );
 end
  );

   Exit( AAttrItem.GetInstance().ComponentEditor.Create( Component, 
Designer ));

   end;

Try to write this without anonymous methods ;-) :-D .


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Martin

Sent: Sunday, March 03, 2013 8:42 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

On 04/03/2013 03:49, Boian Mitov wrote:

Yes, really!
Then again this is over 4 mln mines of code after all. :-D
Thank you for letting me know what closure is :-D . Can you imagine, me 
being component vendor for over 16 years and not knowing what closure is 
:-D.

Did I? Wow, I didn't know I did. Didn't mean to neither. I was just
checking, if you accidentally used the wrong word. (Happens to everyone,
even the very best / so no judgement implied)

Anonymous methods lead to a different way of thinking altogether and allow 
you to do things that you can't even imagine with closures ;-) .
And they make the code infinitely easier to read, especially if like me 
this is a huge codebase ;-) . After all we sell well over 400 components 
not to mention some of our other Delphi based products ;-) .
Sure, if you have small code you can do just fine with closures, as I have 
for many years, then again I did just fine without having classes, and 
objects in the old days, and also did fine in the older days in Assembler 
:-D .
So according to this logic, we really should be doing everything in 
machine code (as I actually did briefly 24 years ago :-D ), who needs new 
features such as those whatmacallit... ohhh yeahh... compilers :-D .

Well I give you the benefit of the doubt, and believe you. But that does
not help me, because I still do not know which case you are talking
about So for my benefit, please enlighten me with an example.


From your above statement, I take, that you already used closures, and

that the big improvements really happened of a result of anonymous methods.
Just to be save, let me state the obvious: We are talking of dropping
the function name; and introducing the ability, to declare the function
anywhere within the code (probably the latter being the important). That
are the 2 only things, that anonymous methods do offer? (OR am I missing
anything?)

If so then I do not see how they save 2 lines?
- The name is part of the declaration line, SO it should not affect the
line count at all). Unless you always write the name on a separate line
(which I would consider a very special case)
- the place of declaration also does not change the line count.



-Original Message- From: Martin
Sent: Sunday, March 03, 2013 7:38 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

On 04/03/2013 01:47, Boian Mitov wrote:
Really, just by dropping the names? Or did you mean, you did all that by
using closures?

Closures, do not need to be written/declared in the middle of other code
(in-line)


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


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

Re: [fpc-devel] Delphi anonymous methods

[Alexander Klenin]

On Mon, Mar 4, 2013 at 4:06 PM, Boian Mitov mi...@mitov.com wrote:
 Here is another even simpler example:

 AItem := GComponentEditorList.Find(
function( AItem : IComponentEditorItem ) : Boolean
begin
  Result := ( AComponent is AItem.GetInstance().ComponentClass 
 );
end
 );

Note that with proposed lambda syntax this will be even shorter:

AItem := GComponentEditorList.Find(
   lambda TComponentEditorListFilter as
 AComponent is AItem.GetInstance().ComponentClass;
);

P. S. Boian, could you please
stop top-posting and splitting your thoughts into so many emails?
It will make discussion much easier to follow.

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

[Boian Mitov]

What people don't usually realize is that an anonymous method indeed is 
internally expanded to a full blown object of unique class, with member 
variables and all. Indeed I use the anonymous methods to effectively declare 
a new class and make instance of it right in place with only couple of lines 
of code. In most cases anonymous methods effectively eliminate the need to 
declare new class for certain purpose.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Boian Mitov

Sent: Sunday, March 03, 2013 9:06 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

Here is another even simpler example:

AItem := GComponentEditorList.Find(
   function( AItem : IComponentEditorItem ) : Boolean
   begin
 Result := ( AComponent is
AItem.GetInstance().ComponentClass );
   end
);


In this case you will either need additional member class variable (It will
increase the memory usage), or you will need to declare a whole class just
to achieve what I do with one line of code :-) . Sweet! :-)

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

Re: [fpc-devel] Delphi anonymous methods

[Boian Mitov]

Thank you!
I am sorry, got overexcited.
I like the lambda proposal, but on the other hand, I have to use Delphi (at 
least for now).
The advantage of the Delphi implementation is that it uses familiar 
Pascal like syntax, but I am sure we can get used to the lambda syntax.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Alexander Klenin

Sent: Sunday, March 03, 2013 9:11 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

On Mon, Mar 4, 2013 at 4:06 PM, Boian Mitov mi...@mitov.com wrote:

Note that with proposed lambda syntax this will be even shorter:

AItem := GComponentEditorList.Find(
  lambda TComponentEditorListFilter as
AComponent is AItem.GetInstance().ComponentClass;
   );

P. S. Boian, could you please
stop top-posting and splitting your thoughts into so many emails?
It will make discussion much easier to follow.

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel 


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

Re: [fpc-devel] Delphi anonymous methods

[Alexander Klenin]

On Mon, Mar 4, 2013 at 2:38 PM, Martin laza...@mfriebe.de wrote:

 Closures, do not need to be written/declared in the middle of other code
 (in-line)

Strictly speaking, they do not. However, if the closures are required
to be named,
their expressive power and readability will suffer greatly.


Nevertheless, I agree what the implementation plan can be detailed even further:
1) Anonymous procedures *without* closures -- basically, just another
syntax for nested procedures.
  This is an important step for several reasons:
1.1) Syntax part is already done in a branch -- so just code clean-up
and merge left.
1.2) This would be useful as an optimization even after the full
closure support is implemented.
  Note that closures introduce significant overhead -- in particular,
if I understand correctly,
  in Delphi every local variable access becomes a reference to the
frame object field,
  *even in the parent procedure*. So nested anonymous procedures,
together with
  good inlining support, are crucial for the efficient implementation
of, for example,
  various ForEach methods.
  Of course, after closure support is implemented, closures should be
somehow distinguished from
  nested procedures -- either by additional syntax or via statical
code analysis by the optimizer.

2) Named closures support -- while I do think that anonymous
procedures are useful,
  Martin has a point too -- it feels strange that you *must* use
anonymous procedure in order to create a closure.
  Perhaps a named nested procedures should be explicitly extendabe to
closures too:

  type
TIntProcRef = reference to procedure (X: Integer);
  function Outer(A, B: Integer): TIntProcRef;
  var
i, j: Integer;
procedure Inner1(C: Integer); A := i; end;
procedure Inner2(D: Integer) closure (var A; i); A := i; end;
  begin
Result := Inner1; // type error, Inner1 if of type procedure ... is nested
Result := Inner2; // ok
  end;
  Note the following details:
  2.0) The exact syntax is, of course, up to debate.
  2.1) Explicit closures allow specify by-value vs by-reference method
of closing over every variable,
  2.2) It is possible to even add modifiers like const and out in
the future.
  2.3) There should probably be some way to automatically close over
all variables used --
for example:
procedure Inner2(D: Integer) closure (var *); A := i; end; // All
variables by reference
procedure Inner2(D: Integer) closure (*); A := i; end; // All
variables by value
procedure Inner2(D: Integer) closure; A := i; end; // By reference
in Delphi mode, by value otherwise ??
  again, syntax is debatable
  2.4) Conversely, compiler could check that every variable reference
inside the closure is specified in the header,
thus avoiding some typical errors.

3) Anonymous closures support -- a combination of the above:
   // Delphi-compatible syntax. Could be made to *not* use closures in
ObjFPC as an optimization.
   // Of course no-closures variant will fail if Apply procedure
stores the reference in a global variable for some reason.
   Apply(AIntArray, function (var AValue: Integer): Integer; begin
Result := a + x; end;)
   // Same as above, but a closure is forced.
  Apply(AIntArray, function (var AValue: Integer): Integer closure(x);
begin Result := a + x; end;)
   // Using lambda syntax.
   Apply(AIntArray, lambda TIntIntFunc closure(x) as a + x;)
   // Shortest variant.
   Apply(AIntArray, lambda TIntIntFunc as a + x;)

4) As stated above, either a syntax to explicitly turn off a closure
for anonymous procedure,
  or intelligent enough optimizer to do that automatically. I have
some ideas on both fronts,
  but I suggest we first discuss previous points.

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

[Boian Mitov]

It may be a good idea to analyze the current Delphi implementation.
In essence the anonymous method expands to a class and interface.
The interface Execute method has the parameters of the anonymous function. 
and the corresponding interface has the Execute method.
The class contains all the variables that are captured from the current 
context, and the constructor of the class does the capture.
The class is reference counted trough the interface, and is disposed when 
all references are released.
There are some interesting side effects and benefits from the 
implementation, and there are fear number of articles about that on the web.


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- 
From: Alexander Klenin

Sent: Sunday, March 03, 2013 9:57 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

On Mon, Mar 4, 2013 at 2:38 PM, Martin laza...@mfriebe.de wrote:


Nevertheless, I agree what the implementation plan can be detailed even 
further:

1) Anonymous procedures *without* closures -- basically, just another
syntax for nested procedures.
 This is an important step for several reasons:
 


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

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

[Martin Schreiber]

On Monday 04 March 2013 00:29:51 Vittorio Giovara wrote:

  IMHO Martin Schreiber is doing a great job using these comparisons and
  some improvements could be made in FPC... but he is making a mistake
  in their approach of how to present FPC's defects.

 I am not so sure about this... I know nothing of dcc switches but he
 is comparing the compiler speed with a different set of features, it
 is easy to spot how flawed the comparison is: -O2 -Xg -Xs are all
 optimization flags and it is expected that optimizing code takes time.

 Could be interesting to see the speed and size of the binary produced
 by the two compilers, slower compilation time over faster or smaller
 code is something I would pick any time!

Please note that Delphi/Kylix produce both smaller and faster code than FPC in 
the testcase, they do full optimisation by default. Quality of the produced 
code is another goal of the comparisons.

MSEide sizes


Delphi 7:   5'062'144
FPC 2.6.2 Windows with smart linking:   6'026'259
Kylix 3:5'092'836   
 
FPC 2.6.2 Linux without smart linking   7'463'712
(it can't smartlink with 1MB ram only) 

Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC 
counterpart which is especially surprising for Delphi because Delphi 
widestrings are not reference counted.

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