Re: [fpc-devel] Closures/anonymous functions update

[Ryan Joseph]

> On May 26, 2019, at 9:15 PM, Ben Grasset  wrote:
> 
> Even if it doesn't happen right away, I 100% agree that this needs to be how 
> they work eventually (which will not break Delphi compatibility, because how 
> they work internally is irrelevant as long as the external means to access / 
> use anonymous functions is roughly the same.)
> 
> Currently I actually tend to avoid anonymous functions in Delphi for "small" 
> callback-esque use cases where no capturing happens, because they *are* in 
> fact objectively slower than function pointers due to how they allocate and 
> destroy a class instance on every call (for no good reason.)
> 
> That is *not* how they work in most languages, for anyone skeptical, BTW. 
> Every existing not-Delphi "native" compiler, for a multitude of different 
> languages, that implements anonymous functions in some way not only *does 
> not* allocate anything on the heap in non-capturing cases, but in fact fully 
> inlines them thus completely eliminating the function call overhead as well.
> 
> That ties in to how I'd also love to see FPC be able to inline normal 
> "procvars" like most compilers do, but I suppose that's a different 

Right now as Blaise designed them they’re totally tied to interfaces. I tried 
to make a record version from this code but ran into too many problems I 
couldn’t solve and gave up. The easiest thing to do afaik is making nested proc 
vars allow anonymous functions and turn this on automatically if it was decided 
the method doesn’t have captures and/or doesn’t get passed outside of scope. I 
already did this work some months ago 
(https://github.com/genericptr/freepascal/tree/anon_funcs) and it worked 
remarkably well (nested proc vars already do all the work required but they 
used records for the backing store).

Regards,
Ryan Joseph

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

Re: [fpc-devel] Closures/anonymous functions update

[Ben Grasset]

On Sat, May 18, 2019 at 2:57 PM Ryan Joseph 
wrote:

> I wanted to make an alternate capture mode as an optimization for closures
> that don’t get passed outside of their scope but I wasn’t able to figure
> this out yet (using old-style objects instead of classes). It’s a waste to
> allocate a new class if not needed (this would hurt realtime graphics
> applications badly) so that should be tackled eventually. Maybe they can be
> made to inline or something, not sure how to handle it though.
>

Even if it doesn't happen right away, I 100% agree that this needs to be
how they work eventually (which will not break Delphi compatibility,
because how they work internally is irrelevant as long as the external
means to access / use anonymous functions is roughly the same.)

Currently I actually tend to avoid anonymous functions in Delphi for
"small" callback-esque use cases where no capturing happens, because they
*are* in fact objectively slower than function pointers due to how they
allocate and destroy a class instance on every call (for no good reason.)

That is *not* how they work in most languages, for anyone skeptical, BTW.
Every existing not-Delphi "native" compiler, for a multitude of different
languages, that implements anonymous functions in some way not only *does
not* allocate anything on the heap in non-capturing cases, but in fact
fully inlines them thus completely eliminating the function call overhead
as well.

That ties in to how I'd also love to see FPC be able to inline normal
"procvars" like most compilers do, but I suppose that's a different story...
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures/anonymous functions update

[Ryan Joseph]

> On May 18, 2019, at 11:41 AM, Blaise Thorn  wrote:
> 
> Saturday, May 18, 2019 8:32 PM +03:00 from Ryan Joseph 
> :
>> After 2 months now I’ve not been able to get the required sources to help 
>> finish the closures branch.
>> The author Blaise did manage to contact me once but then went silent so I 
>> don’t know what happened.
> 
> Only yesterday, I have finished setting up https://hg.blaise.ru/ (which is 
> now a separate server), and issued certificates. So, it /has/ been moving 
> forward all this time, albeit slowly.

There you are! I thought you moved on. That’s good news but you can just send 
me anything you need in the mean time instead of setting up an entire server 
first. Mainly I just wanted to see the current state of it so I can know where 
to start or what’s left. Not sure if you did everything the compiler team asked 
yet or not.

Thanks for replying.

Regards,
Ryan Joseph

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

Re: [fpc-devel] Closures/anonymous functions update

[Blaise Thorn]

Saturday, May 18, 2019 8:32 PM +03:00 from Ryan Joseph 
:
> After 2 months now I’ve not been able to get the required sources to help 
> finish the closures branch.
> The author Blaise did manage to contact me once but then went silent so I 
> don’t know what happened.

Only yesterday, I have finished setting up https://hg.blaise.ru/ (which is now 
a separate server), and issued certificates. So, it /has/ been moving forward 
all this time, albeit slowly.

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

[fpc-devel] Closures/anonymous functions update

[Ryan Joseph]

After 2 months now I’ve not been able to get the required sources to help 
finish the closures branch so I guess it’s best to go to plan B and see if it’s 
feasible to finish at the last public repository I found. The author Blaise did 
manage to contact me once but then went silent so I don’t know what happened.

I’ve found a few bugs that need fixing but most of it seems to work as far as 
I’ve tested. Blaise claimed there were some "lifetime management issues” but I 
can’t find them yet (maybe this was an older version he was referring to). The 
only serious bug I can’t figure out yet is a runtime crash when declaring 
anonymous functions in class constructors.

Here’s what I managed to salvage so far with some requested changes made (see 
below).

https://github.com/genericptr/freepascal/tree/closures

Here’s the list of old comments from 2015-2016 which I was able to find using 
my detective skills and I corrected some of them. 

The only concerning thing is that Jonas had a request (reasonable however 
challenging) that the variable capturing process be unified with the existing 
code for nested procedures. I’m struggling to understand how this works however 
and I’m not certain if a) this is still important and b) if it’s even a good. 
The closures actually have a very minimal footprint in other parts of the 
compiler and is very non-invasive as it is. My feeling is that it’s not worth 
it to merge the two methods as it would complicate both but I’m really not 
sure. Anyways, if that’s required than this is the by far the biggest chunk of 
work left because it requires redoing a significant part of the design.

I wanted to make an alternate capture mode as an optimization for closures that 
don’t get passed outside of their scope but I wasn’t able to figure this out 
yet (using old-style objects instead of classes). It’s a waste to allocate a 
new class if not needed (this would hurt realtime graphics applications badly) 
so that should be tackled eventually. Maybe they can be made to inline or 
something, not sure how to handle it though.

What does the compiler team think about this? Can you guide me so I could 
finish what was started? Please update me on what needs to be done to get this 
moving along.

// https://fpc-devel.freepascal.narkive.com/ONaPiCka/closures-anonymous-methods
// http://lists.freepascal.org/pipermail/fpc-devel/2016-January/036479.html

{ 
  = Jonas:

  First of all, thanks for your work, and sorry for the late reaction.

  I was wondering whether you could rework the above functionality based  
  on the code in ncgnstld.pas/ncgnstmm.pas. That is code which is used  
  by the JVM and LLVM code generators to access nested variables. It  
  adds all variables that are used by nested routines to a record, and  
  then passes a pointer to this record as "parentfp" parameter (since  
  those platforms do not have a stack or frame pointer register that can  
  be passed on). This seems quite similar to what you're doing with  
  load_captured_sym() etc. Alternatively, maybe your code is better and  
  that code could be refactored to make use of your routines. I have not  
  yet studied your code in detail yet.

  One advantage would be that the existing code already handles this too  
  (for plain nested routines):

  = Sven:

  Sorry that it took me so long to answer. I have looked at your changes 
  shortly after you published them, but then I forgot... Mea culpa.

  First of thank you for the work you've done. I think I've said this in 
  the private mail I sent you already, but better I do it here as well. :)

  Now of course there are still quite some things aside from those that 
  you mentioned above. I'll just list them in no particular order:

  √ use our usual license header in pnameless.pas (see for example ogomf.pas)

  √ include the fpcdefs.inc in pnameless and don't use mode Delphi

  √ please don't use features (in this case C-style operators) that are 
  neither enabled by default in mode ObjFPC nor a enabled in fpcdefs.inc

  √ I'd prefer if you'd use the term "anonym" instead of "nameless" as 
  this way one not only can derive more easily that you mean anonymous 
  functions, but in addition to that the unit name would fit into the 8.3 
  scheme (this point includes both the unit name as well as the 
  oo_is_nameless and po_nameless flags)

  √ don't have defcmp depend on pnameless; instead move 
  are_compatible_interfaces() and are_compatible_headers() to defcmp (you 
  don't need to put everything and the kitchen sink into the pnameless unit)

  - analogous for load_contextual_self(); maybe even move that to a new 
  unit altogether as this doesn't really deal with nameless/anonym 
  functions, but more with the closure part of the concept (so either 
  nutils.pas or a new nclosure.pas as it's dealing more with nodes than 
  parsing)

  √ do *not* call internalerror if the user can easily trigger it; in that 
  case it would be the one in factor() 

Re: [fpc-devel] Closures repo

[Ben Grasset]

On Thu, Mar 21, 2019 at 4:40 PM Blaise Thorn  wrote:

> Should you be interested in writing tests, I could give you the acess.
>

I'd also be very interested in assisting with this, now that I'm aware
you're willing to provide access to the repo.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures repo

[Sven Barth via fpc-devel]

Ryan Joseph  schrieb am Do., 21. März 2019,
22:43:

>
>
> > On Mar 21, 2019, at 5:01 PM, Blaise Thorn  wrote:
> >
> > Thursday, March 21, 2019 11:48 PM +03:00 from Ryan Joseph <
> r...@thealchemistguild.com>:
> >> Then maybe he’ll hear this and respond.
> >
> > I just did.
>
> Oh, you’re the author!
>

Gotta admit, that was funny to read 藍

But anyway, I hope that we can resolve this rather sooner than later as
well.

Regards,
Sven

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

Re: [fpc-devel] Closures repo

[Ryan Joseph]

> On Mar 21, 2019, at 5:01 PM, Blaise Thorn  wrote:
> 
> Thursday, March 21, 2019 11:48 PM +03:00 from Ryan Joseph 
> :
>> Then maybe he’ll hear this and respond.
> 
> I just did.

Oh, you’re the author! I recognize the email now. Yes, please tell me what the 
status is and what’s left to do. If you have a more recent git repository 
somewhere send that also so I can look it over. I already started to do some 
work on that old one from 2015 but I assume you fixed many of the minor details 
since then.

Regards,
Ryan Joseph

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

Re: [fpc-devel] Closures repo

[Blaise Thorn]

Thursday, March 21, 2019 11:48 PM +03:00 from Ryan Joseph 
:
> Then maybe he’ll hear this and respond.

I just did.

> I’m happy to write tests

I will privately email you the details next week.
(FTR, since I asked for help with writing tests on this list, you are the 
second one who volunteered in all those years).

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

Re: [fpc-devel] Closures repo

[Ryan Joseph]

> On Mar 21, 2019, at 3:54 PM, Blaise Thorn  wrote:
> 
> FTR, the author automatically monitors this list for the keyword "closures”.

Then maybe he’ll hear this and respond. He’s been mentioned repeatedly over the 
months and years but I have no idea if he’s still there or abandoned the 
project.

> 
>> From what I can tell most the work is already done
> 
> IIRC, the last publicly available version lacks lifetime management support 
> amongst other crucial stuff.
> FTR, the code is now used in production, which was not the case some time 
> ago, and which helped in identifiying some additional issues.
> 
> Should you be interested in writing tests, I could give you the acess.

So there’s a more recent version that’s being worked on? I’m happy to write 
tests or do anything else to just get this finished finally. Please tell me 
more.

From what I saw in that repo the captures are stored in an interfaced object 
which has reference counting right? Maybe expand on the lifetime management 
issues more.

Regards,
Ryan Joseph

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

Re: [fpc-devel] Closures repo

[Blaise Thorn]

> do we even have contact with the author anymore?

FTR, the author automatically monitors this list for the keyword "closures".

> From what I can tell most the work is already done

IIRC, the last publicly available version lacks lifetime management support 
amongst other crucial stuff.
FTR, the code is now used in production, which was not the case some time ago, 
and which helped in identifiying some additional issues.

Should you be interested in writing tests, I could give you the acess.

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

[fpc-devel] Closures repo

[Ryan Joseph]

So I came across a backup repo that Maciej made of the development for closures 
(from 2015, not sure when the original author stopped working on it). I know 
Sven said some months back the original author is still working on it but 
that’s been said for literally years now and do we even have contact with the 
author anymore? From what I can tell most the work is already done so can we 
just fix all the problems in his code and get this finished already? I saw a 
list of concerns from Sven and Jonas in an old email thread and they could be 
addressed pretty easily. What a waste this has been just sitting there for 3+ 
years. Hope we can get this resolved sooner than later.

https://github.com/maciej-izak/freepascal/tree/closures

Regards,
Ryan Joseph

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

Re: [fpc-devel] Closures / anonymous methods

[Marcos Douglas B. Santos]

On Thu, Jul 20, 2017 at 9:56 PM, Blaise Thorn  wrote:
> There has been some feature-level progress; in particular, capturing across
> arbitrary level of nested and nameless routines is now supported, along with
> proper lifetime management.
>
> Sven has read-write access to the source.
>
> No other features are planned by me before the merge. I am currently hung up
> on a couple of FPC bugs. Once I file them, I will enable public read access.

What is the progress?

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

Re: [fpc-devel] Closures / anonymous methods

[Blaise Thorn]

There has been some feature-level progress; in particular, capturing across 
arbitrary level of nested and nameless routines is now supported, along with 
proper lifetime management.
Sven has read-write access to the source.
No other features are planned by me before the merge. I am currently hung up on 
a couple of FPC bugs. Once I file them, I will enable public read access.
--
βþ___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures / anonymous methods

[Ondrej Pokorny]

On 05.12.2016 15:12, bla...@blaise.ru wrote:
Otherwise, as I stated above, no help/answers is required for now; and 
I am working.


What is the progress?

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

Re: [fpc-devel] Closures / anonymous methods

[Maciej Izak]

2016-12-05 17:46 GMT+01:00 :

>
> Because much communication occurred off-list.


:) in that case all is ok. Good luck. I have hope to see new release soon.
I will try to create few tests.


> if you do not have enough patience for FPC core team
>>
>
> What I do not have is respect for schismatics who create unnecessary
> forks, splitting the community and resources.


Indeed! That would be terrible. I think that is good that we don't have any
Lord Vader nor Emperor :)

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures / anonymous methods

[Blaise]

On 05.12.2016 17:57, Maciej Izak wrote:


the topic was almost dead for 1 year


Because much communication occurred off-list.


if you do not have enough patience for FPC core team


What I do not have is respect for schismatics who create unnecessary forks, 
splitting the community and resources.

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

Re: [fpc-devel] Closures / anonymous methods

[Maciej Izak]

2016-12-05 15:12 GMT+01:00 :

> On 05.12.2016 16:44, Sven Barth wrote:
>
> You mean that from around a year ago?
>>
>
> No. Your latest letter to me is dated 26.11.2016.


I see big problem with communication. Seems like I am special mediator.
Without my notification the topic was almost dead for 1 year. Now we have
similar situation again probably for another year or two.

I need that feature to start many other related features in my compiler
work. For example I like to start experiments with "yield" and other stuff
(compiler code behind closures is usefully).

>From my experience with management operators:

* The patch can't be simple as one big patch, the working feature is just a
start (in current form, closures are not in that stage yet - see problems
with already implemented "blocks" by Jonas). State of closures IMO is far
far away from "ready to merge".
* When big patch is ready you need to rework whole patch for small commits
* Each owner/author of feature, should be able to create full-test suite,
generally only author knew how it works in all details, and how to create
proper test suite to cover low level scenarios, so community could not help
much with test suite (sure - bug reports and related tests are fine but I
mean test suite prepared by core team for each new feature).
* The style of compiler code *must* be exactly same in all parts (after
many hours with compiler I think it is perfect).

Did I miss something important? I might be wrong.

Let me know if you do not have enough patience for FPC core team ;). I will
do it :P...

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures / anonymous methods

[Blaise]

On 05.12.2016 16:44, Sven Barth wrote:


You mean that from around a year ago?


No. Your latest letter to me is dated 26.11.2016.
In which, instead of accepting the offer, you chose to write a (much 
appreciated) HOWTO.
(The offer stands; should you reconsider, kindly email me directly.)

Otherwise, as I stated above, no help/answers is required for now; and I am 
working.

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

Re: [fpc-devel] Closures / anonymous methods

[Sven Barth]

Am 05.12.2016 14:37 schrieb :
>
> On 05.12.2016 13:36, Sven Barth wrote:
>
>> I didn't get any mail from Blaise during my holidays
>
>
> As agreed, I have allocated time, and I have been working.
> (FTR, I really want(ed) you to enlist for the task we discussed, so we
would work in parallel.)

You never wrote that you'd now start or that you'd now be available in IRC
or whatever. Missing that I simply worked on bugs and other stuff that came
along...

> For now, with your latest letter, I have all the info I need from you.
> (I have one pending question on terminology, but I believe it belongs to
the list, so I will ask here.)

You mean that from around a year ago? Yeah, that should contain most points.

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

Re: [fpc-devel] Closures / anonymous methods

[Blaise]

On 05.12.2016 13:36, Sven Barth wrote:


I didn't get any mail from Blaise during my holidays


As agreed, I have allocated time, and I have been working.
(FTR, I really want(ed) you to enlist for the task we discussed, so we would 
work in parallel.)

For now, with your latest letter, I have all the info I need from you.
(I have one pending question on terminology, but I believe it belongs to the 
list, so I will ask here.)

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

Re: [fpc-devel] Closures / anonymous methods

[Sven Barth]

Am 05.12.2016 11:16 schrieb "Maciej Izak" :
>
>
> 2016-11-25 19:10 GMT+01:00 Sven Barth :
>>
>> Just to be sure: we're talking about the week from 28th to 2nd. If so,
yes I'll try to make sure that I'm available. Maybe I'll even hang around
on IRC :)
>
>
> Any new info? Link to repository? Should I continue?

I didn't get any mail from Blaise during my holidays... Until he's replied
again I'd say to let it be for now.

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

Re: [fpc-devel] Closures / anonymous methods

[Maciej Izak]

2016-11-25 19:10 GMT+01:00 Sven Barth :

> Just to be sure: we're talking about the week from 28th to 2nd. If so, yes
> I'll try to make sure that I'm available. Maybe I'll even hang around on
> IRC :)


Any new info? Link to repository? Should I continue?

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures / anonymous methods

[Sven Barth]

Am 25.11.2016 15:30 schrieb :
>
> On 24.11.2016 21:38, Sven Barth wrote:
>>
>> On 31.10.2016 14:58, bla...@blaise.ru wrote:
>>>
>>> I would like a commitment from at least one of the committers to work
closely with me during that period on resolving issues that prevent
merging. And by that I mean to be ready to react to my changes/questions
within a day/two/three (not a month) as we both go through the list item by
item.
>>
>> I'll be at home next week due to a vacation and my hope is that I'll be
able to work on a couple of FPC topics that are still open.
>
>
> So, is that a commitment? Do I book my next week for this? :)

Just to be sure: we're talking about the week from 28th to 2nd. If so, yes
I'll try to make sure that I'm available. Maybe I'll even hang around on
IRC :)

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

Re: [fpc-devel] Closures / anonymous methods

[Zoë Peterson]

> So what next? Blaise is still interested in? Am I alone on battle
> field?  Is Scooter Software around? I am confused.

Yes, we're still around.  Yes, we're still willing to throw some money 
at anyone else who can help get this pushed in, whether that's Blaise, 
Sven, or Maciej.  I don't have experiencing with the compiler team 
organization or patch process though, and we're preparing a new release 
right now though, so aside from money, I'm not sure we'll be able to do 
anything until it's pushed into trunk.  We need the feature for new 
code, not existing, so I don't have test cases, and I can't justify the 
time to develope that code until I know we'll be able to use it.


--
Zoë Peterson
Scooter Software

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

Re: [fpc-devel] Closures / anonymous methods

[Blaise]

On 24.11.2016 21:38, Sven Barth wrote:

On 31.10.2016 14:58, bla...@blaise.ru wrote:

I would like a commitment from at least one of the committers to work closely 
with me during that period on resolving issues that prevent merging. And by 
that I mean to be ready to react to my changes/questions within a day/two/three 
(not a month) as we both go through the list item by item.

I'll be at home next week due to a vacation and my hope is that I'll be able to 
work on a couple of FPC topics that are still open.


So, is that a commitment? Do I book my next week for this? :)

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

Re: [fpc-devel] Closures / anonymous methods

[Sven Barth]

Am 25.11.2016 09:45 schrieb "Maciej Izak" :
>
>
> 2016-11-24 19:38 GMT+01:00 Sven Barth :
>>
>> mea culpa
>
>
> So what next? Blaise is still interested in? Am I alone on battle field?
Is Scooter Software around? I am confused.

Give them some time to answer. After all I had written this mail not even
24h ago. ;)
Nevertheless I've now added both Blaise and Zoë in CC so that they're
definitely aware that there's a reply.

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

Re: [fpc-devel] Closures / anonymous methods

[Maciej Izak]

2016-11-24 19:38 GMT+01:00 Sven Barth :

> mea culpa


So what next? Blaise is still interested in? Am I alone on battle field? Is
Scooter Software around? I am confused.

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures / anonymous methods

[Sven Barth]

On 31.10.2016 14:58, bla...@blaise.ru wrote:
> On 31.10.2016 5:30, Zoë Peterson wrote:
> 
>> We do need it in FPC proper though, not New Pascal
> 
> I was going to ask you to clarify that; thanks.
> 
>> Blaise, I'm fine settling up with you if Maciej takes over. Is there a
>> foreseeable schedule for you finishing if he doesn't?
> 
> I am ready to allocate a week or two from my schedule in the next month
> for this, but:

Sorry for the long delay. I didn't want to answer this on my phone and
it had taken a while till I remembered that I wanted to answer this
while being in front of my desktop computer... mea culpa

> 1) I would like a general commitment from the decision-makers to include
> this. By that I mean A) they want the feature, B) they are ready, in
> concept, to accept this patch (it may not implement the full support,
> but it fully implements the core and hardest aspects), provided that we
> work out the easy details (how to name stuff, where to put it, and
> blocking bugs -- should we find any).

Yes, to both A and B.

> 2) I would like a commitment from at least one of the committers to work
> closely with me during that period on resolving issues that prevent
> merging. And by that I mean to be ready to react to my changes/questions
> within a day/two/three (not a month) as we both go through the list item
> by item.

That might be the biggest hurdle as this is after all a voluntary
project and how one organizes one's free time is a topic in itself...
That said I'll be at home next week due to a vacation and my hope is
that I'll be able to work on a couple of FPC topics that are still open.

> Provided that we agree on the two above points, I believe we can have it
> merged by the end of November.
> 
> Not a hard requirement, but, additionally, it would be nice if your
> staff (at Scooter Software), or someone on this mailing list, took over
> the formal tests (writing, running, integration).

Tests are very important indeed.

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

Re: [fpc-devel] Closures / anonymous methods

[Zoë Peterson]

We (Scooter Software) don't care who or how it it gets into Free Pascal, 
as long as it eventually ends up there. :)  We do need it in FPC proper 
though, not New Pascal, because we need it on Linux and macOS, and our 
build process is complicated enough that I wouldn't want to throw a 
cross compiler into the mix.


Blaise, I'm fine settling up with you if Maciej takes over.  Is there a 
foreseeable schedule for you finishing if he doesn't?


Maciej, we can kick in some additional bounty to push it through if 
it'll help.  We can discuss things off list if you get it going.


--
Zoë Peterson
Scooter Software

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

Re: [fpc-devel] Closures / anonymous methods

[Maciej Izak]

2016-10-29 13:29 GMT+02:00 Florian Klämpfl :

> While I agree that we are merging invasive changes slowly, this is a
> little bit unfair as
> Generics.Collections required a lot of bugs to be fixed before it could be
> merged:
> http://bugs.freepascal.org/view.php?id=27206
>

Last serious bug was fixed around rev. 29537 (January 2015). Ok just ~1,5
year. My bad ;). Sven had a lot of doubts about manual interfaces
:P... Anyway I am very happy that we finally have rtl-generics!

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures / anonymous methods

[Florian Klämpfl]

Am 26.10.2016 um 00:58 schrieb Maciej Izak:
> 
> to get important patches/modifications in reasonable time,
> for example merge for finished Generics.Collections took 2 years... 

While I agree that we are merging invasive changes slowly, this is a little bit 
unfair as
Generics.Collections required a lot of bugs to be fixed before it could be 
merged:
http://bugs.freepascal.org/view.php?id=27206
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures / anonymous methods

[Michael Van Canneyt]

On Wed, 26 Oct 2016, Paul van Helden wrote:


Specially when they are as invasive as yours. You are in essence
converting pascal to a C++ clone with this MO patch. Is it so bad that this
is discussed thoroughly first ?



+1 for Oxygene mode. An Oxygene mode to me will be like early Christmas and
the next 10 years' Christmases rolled together!

I disagree that modernizing Pascal is making it into a C++ clone.


It depends on how you do it.

What is being introduced with management operators is RAII. 
(Resource Acquisition Is Initialization)

This concept (using copy/clone constructors etc.) comes from C++.

Javascript doesn't have it. Python also not (to my knowledge). 
And these are so-called 'modern' languages.


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

Re: [fpc-devel] Closures / anonymous methods

[Michael Van Canneyt]

On Wed, 26 Oct 2016, Maciej Izak wrote:


2016-10-26 11:56 GMT+02:00 Michael Van Canneyt :


As long as it's really a separate mode (plus maybe modeswitches for

selected features, that other modes might profit from) I don't see a
problem with adding an Oxygene mode.



Indeed. This is the reason modes were invented.



This is obvious. I won't touch the holy OBJFPC mode ;). Ever. 
I am worried about the speed of reviewing patches and integrations. For example:

Management operators are key feature for many elements in Oxygene mode.
Today I am 28 years old. I think that maybe before my 40th birthday FPC
team decide to merging Management Operatos into trunk -,- . If Oxygene
patch is next, which relay on MO... 80th birthday?


I am happy to report that you are wrong. They are currently under discussion.
Some valid concerns were raised.

By the looks of it, they may be integrated before long.

Please understand:

Free Pascal is a team project. 
This means you cannot expect to have all patches integrated here-and-now.


Specially when they are as invasive as yours. 
You are in essence converting pascal to a C++ clone with this MO patch. 
Is it so bad that this is discussed thoroughly first ?


I understand your youthful impatience, just have a little more patience :-)

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

Re: [fpc-devel] Closures / anonymous methods

[Michael Van Canneyt]

On Wed, 26 Oct 2016, Sven Barth wrote:


Am 26.10.2016 00:58 schrieb "Maciej Izak" :

Many users likes more modern Pascal (for example oxygene mode is also one

of NewPascal targets), FPC core team likes more old fashioned Pascal... I
do not believe that core team would accept oxygene mode/patch. Anyway...

As long as it's really a separate mode (plus maybe modeswitches for
selected features, that other modes might profit from) I don't see a
problem with adding an Oxygene mode.


Indeed. This is the reason modes were invented.

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

Re: [fpc-devel] Closures / anonymous methods

[Sven Barth]

Am 26.10.2016 00:58 schrieb "Maciej Izak" :
> Many users likes more modern Pascal (for example oxygene mode is also one
of NewPascal targets), FPC core team likes more old fashioned Pascal... I
do not believe that core team would accept oxygene mode/patch. Anyway...

As long as it's really a separate mode (plus maybe modeswitches for
selected features, that other modes might profit from) I don't see a
problem with adding an Oxygene mode.

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

Re: [fpc-devel] Closures / anonymous methods

[Maciej Izak]

2016-10-26 0:03 GMT+02:00 :

> Now you have me confused.
> I thought you wanted to "take over" acceptance of this into FPC and doing
> further improvements.
> What is this NewPascal? How official is it? Are the changes ported to FPC?
> (Googling through the lists.freepascal.org did not help.)
>

NewPascal is official compiler for mORMot. NewPascal means tuned compiler
more Delphi compatible with additional support for mORMot framework, cross
compiling and early access for new features. More info about changes and
differences with comparison to official FPC:
http://newpascal.org/compass.html . All is reported on FPC bugtracker. I
can't do much in that matter.

... I also want acceptance of all important patches into FPC (that is why I
will work on your patch). We really need NewPascal fork, to get important
patches/modifications in reasonable time, for example merge for finished
Generics.Collections took 2 years...

Many users likes more modern Pascal (for example oxygene mode is also one
of NewPascal targets), FPC core team likes more old fashioned Pascal... I
do not believe that core team would accept oxygene mode/patch. Anyway...

*NewPascal is and will be as close FPC trunk/bugtracker as possible*.

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures / anonymous methods

[Blaise]

On 26.10.2016 0:36, Maciej Izak wrote:


your work (with my modifications and with regression tests) will become part of 
NewPascal release (for sure!) and I hope it makes you less frustrated :)


Now you have me confused.
I thought you wanted to "take over" acceptance of this into FPC and doing 
further improvements.
What is this NewPascal? How official is it? Are the changes ported to FPC? 
(Googling through the lists.freepascal.org did not help.)

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

Re: [fpc-devel] Closures / anonymous methods

[Maciej Izak]

2016-10-25 20:38 GMT+02:00 :
>
> 3) I have not abandoned this project (and I am as frustrated with the pace
> as you may be; although, the previous disruption was not my fault -- I had
> allocated last December to finally have this merged, but got no response
> from maintainers within a month).
>

... I understand ... :\


> TL;DR: while there may be nothing preventing you from just grabbing the
> feature-ready files and "taking over" from the legal standpoint (and I do
> not care to check), there are other implications to consider.
>

> The other reason I mentioned Scooter Software is that they may be
> interested in funding your further work. (The list does not reflect this,
> but I CC'ed my original message to them to keep them in the loop.)
>

that is very interesting for me. Thanks?

btw. your work (with my modifications and with regression tests) will
become part of NewPascal release (for sure!) and I hope it makes you less
frustrated :)

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures / anonymous methods

[Blaise]

On 25.10.2016 20:57, Maciej Izak wrote:


What Scooter Software has to GPL licensed code?


It has to do with what is right.
Allow me to provide a little background:
1) I do not use FPC at all;
2) Essentially, I was "hired" by Scooter Software (they do use FPC, I presume) 
to implement the subj (after one other person failed to improve on my earlier work);
3) I have not abandoned this project (and I am as frustrated with the pace as 
you may be; although, the previous disruption was not my fault -- I had 
allocated last December to finally have this merged, but got no response from 
maintainers within a month).

TL;DR: while there may be nothing preventing you from just grabbing the feature-ready 
files and "taking over" from the legal standpoint (and I do not care to check), 
there are other implications to consider.

The other reason I mentioned Scooter Software is that they may be interested in 
funding your further work. (The list does not reflect this, but I CC'ed my 
original message to them to keep them in the loop.)

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

Re: [fpc-devel] Closures / anonymous methods

[Maciej Izak]

2016-10-25 16:09 GMT+02:00 :

> In theory, that is fine by me (the author).
>

Good to hear that


> However, if I were to formally pass the bucket to you, I would like to
> settle with Scooter Software on my work done thus far.
>

What Scooter Software has to GPL licensed code?

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures / anonymous methods

[Maciej Izak]

2016-10-25 15:45 GMT+02:00 Michael Van Canneyt :

> One remark only: you should keep it independent of (or orthogonal to) the
> work you did on management operators. One should not depend on the other...


Yes I know and I agree :P One branch for Generics.Collections, one for
Management Operators, one for Smart Pointers, one for patches and new one
for Closures.

I hope that Github has enough space for all branches...

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures / anonymous methods

[Blaise]

On 25.10.2016 18:30, wkitt...@windstream.net wrote:


if i/we may ask, what happened to your Patch/hg repository? why did it go away?


As I said to Sven back then: "I did some server maintenance on 27th June, and I have 
had no incentive to put that part back yet".
That is the only reason: lack of time.
(But, AFAIR, there has been only a couple of minor bug fixes since then.)

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

Re: [fpc-devel] Closures / anonymous methods

[wkitty42]

On 10/25/2016 10:09 AM, bla...@blaise.ru wrote:

On 25.10.2016 16:06, Maciej Izak wrote @
http://lists.freepascal.org/pipermail/fpc-devel/2016-October/037375.html :


I'd like to take over work on closures/anonymous methods


In theory, that is fine by me (the author).
However, if I were to formally pass the bucket to you, I would like to settle
with Scooter Software on my work done thus far.


if i/we may ask, what happened to your Patch/hg repository? why did it go away?

--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list* unless
   private contact is specifically requested and granted.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures / anonymous methods

[Blaise]

On 25.10.2016 16:06, Maciej Izak wrote @ 
http://lists.freepascal.org/pipermail/fpc-devel/2016-October/037375.html :


I'd like to take over work on closures/anonymous methods


In theory, that is fine by me (the author).
However, if I were to formally pass the bucket to you, I would like to settle 
with Scooter Software on my work done thus far.

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

Re: [fpc-devel] Closures / anonymous methods

[Michael Van Canneyt]

On Tue, 25 Oct 2016, Maciej Izak wrote:


Hi,

I'd like to take over work on closures/anonymous methods:

http://newpascal.org/compass.html (point #5).

Patch/hg repository from original author has gone away but I have made
copy. My working repository is here:

https://github.com/maciej-izak/freepascal/commits/closures

I sent here original patch.

I will rework this functionality according to all suggestions from Jonas
and Sven (reference to all informations avaible in NewPascal "compass"
listed above).

any objections?


None, on the contrary. Glad that someone is taking it up.

One remark only: you should keep it independent of (or orthogonal to) 
the work you did on management operators. 
One should not depend on the other...


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

[fpc-devel] Closures / anonymous methods

[Maciej Izak]

Hi,

I'd like to take over work on closures/anonymous methods:

http://newpascal.org/compass.html (point #5).

Patch/hg repository from original author has gone away but I have made
copy. My working repository is here:

https://github.com/maciej-izak/freepascal/commits/closures

I sent here original patch.

I will rework this functionality according to all suggestions from Jonas
and Sven (reference to all informations avaible in NewPascal "compass"
listed above).

any objections?

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures

[Sven Barth]

On 09.12.2015 11:43, bla...@blaise.ru wrote:

On 09.03.2015 16:36, bla...@blaise.ru wrote:

On 15.01.2012 18:26, Blaise wrote:

I have implemented the support for the Delphi-compatible non-generic
closures.

I am ready to commit the improved (and fully compilable) version.


Four years later, here comes (vastly improved) second attempt at a
public release: http://hg.blaise.ru/public/fpc .

My plan is to:
1) Collect the initial remarks and fix the most awful bugs and
shortcomings that would prevent merging this into the trunk (I am using
Hg for this step because I want to be able to seamlessly synchronise
with trunk and branch at ease.)
2) When the overall design and implementation are deemed acceptable,
correct the remaining coding style issues and push into my branch on the
official SVN server.
3) Create a ticket and wait for the merge.

Initial tests: http://hg.blaise.ru/public/fpc-tests .

A) Things that work (at least, expected to -- before the merge):
 * embedding nameless routines into expressions;
 * accessing outer variables/parameters/Selves from such routines
and from routines nested in them;
 * new method reference type;
 * structural type equivalence for method references;
 * 100% Delphi-compatible design and implementation, including two
crucial points:
 1) closure objects are descendants of TInterfacedObject;
 2) method references are half-hidden interface types.
B) Things that do not work (not planned to be addressed before the merge):
 * accessing outer local-variables/parameters/Selves that are
located more than one level higher than the nameless routine;
 * omitting currently mandatory () for invoking method references
without arguments;
 * assigning normal routines and methods to method references;
 * support for generics.
C) Future possibilities:
 * special handling for nameless routines that do not capture anything.
May go into A) or B): capturing large parameters by value may have
issues -- needs checking.
Known bugs, mostly for A):
http://hg.blaise.ru/public/fpc-tests/file/tip/closures/TODO .



Sorry that it took me so long to answer. I have looked at your changes 
shortly after you published them, but then I forgot... Mea culpa.


First of thank you for the work you've done. I think I've said this in 
the private mail I sent you already, but better I do it here as well. :)


Now of course there are still quite some things aside from those that 
you mentioned above. I'll just list them in no particular order:


- use our usual license header in pnameless.pas (see for example ogomf.pas)
- include the fpcdefs.inc in pnameless and don't use mode Delphi
- please don't use features (in this case C-style operators) that are 
neither enabled by default in mode ObjFPC nor a enabled in fpcdefs.inc
- I'd prefer if you'd use the term "anonym" instead of "nameless" as 
this way one not only can derive more easily that you mean anonymous 
functions, but in addition to that the unit name would fit into the 8.3 
scheme (this point includes both the unit name as well as the 
oo_is_nameless and po_nameless flags)
- don't have defcmp depend on pnameless; instead move 
are_compatible_interfaces() and are_compatible_headers() to defcmp (you 
don't need to put everything and the kitchen sink into the pnameless unit)
- analogous for load_contextual_self(); maybe even move that to a new 
unit altogether as this doesn't really deal with nameless/anonym 
functions, but more with the closure part of the concept (so either 
nutils.pas or a new nclosure.pas as it's dealing more with nodes than 
parsing)
- adhere to the coding style of the compiler; this includes quite some 
code in pnameless.pas (e.g. " := " or variable declarations with ": " 
instead of " : "), but more importantly to pexpr.pas for example where 
you used "ELSE AGAIN:=FALSE" which should be

"else
  again:=false"

instead
- do *not* call internalerror if the user can easily trigger it; in that 
case it would be the one in factor() of pexpr.pas
- use a "anonymousfunctions" modeswitch instead of checking for mode 
Delphi; there might be users who want to use them in other modes as well
- the flag oo_is_nameless (or oo_is_anonym) is okay; we won't go for 
type coersion
- get rid of parse_method_reference(); instead integrate the code into 
procvar_dec() and have that return the interface def based on a boolean 
flag (Note: your code as is would result in wrong parsing if modeswitch 
blocks would be activated in mode Delphi)
- based on the above point you can also get rid of the 
ppm_method_reference flag; the remaining ppm_nameless_routine I'd 
instead convert into a set together with the isgeneric parameter


Those are my observations so far. I'm still a bit uneasy with the 
capturing process itself though. Maybe Jonas' remark will help there to 
clean things up a bit and to unify the two approaches a bit (I know that 
they can't be completely unified as one uses records while the other 

Re: [fpc-devel] Closures

[Jonas Maebe]

Blaise wrote on Wed, 09 Dec 2015:


On 09.03.2015 16:36, bla...@blaise.ru wrote:



A) Things that work (at least, expected to -- before the merge):
	* accessing outer variables/parameters/Selves from such routines  
and from routines nested in them;


First of all, thanks for your work, and sorry for the late reaction.

I was wondering whether you could rework the above functionality based  
on the code in ncgnstld.pas/ncgnstmm.pas. That is code which is used  
by the JVM and LLVM code generators to access nested variables. It  
adds all variables that are used by nested routines to a record, and  
then passes a pointer to this record as "parentfp" parameter (since  
those platforms do not have a stack or frame pointer register that can  
be passed on). This seems quite similar to what you're doing with  
load_captured_sym() etc. Alternatively, maybe your code is better and  
that code could be refactored to make use of your routines. I have not  
yet studied your code in detail yet.


One advantage would be that the existing code already handles this too  
(for plain nested routines):



B) Things that do not work (not planned to be addressed before the merge):
	* accessing outer local-variables/parameters/Selves that are  
located more than one level higher than the nameless routine;



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

Re: [fpc-devel] Closures

[Blaise]

On 09.03.2015 16:36, bla...@blaise.ru wrote:

On 15.01.2012 18:26, Blaise wrote:

I have implemented the support for the Delphi-compatible non-generic closures.

I am ready to commit the improved (and fully compilable) version.


Four years later, here comes (vastly improved) second attempt at a public 
release: http://hg.blaise.ru/public/fpc .

My plan is to:
1) Collect the initial remarks and fix the most awful bugs and shortcomings 
that would prevent merging this into the trunk (I am using Hg for this step 
because I want to be able to seamlessly synchronise with trunk and branch at 
ease.)
2) When the overall design and implementation are deemed acceptable, correct 
the remaining coding style issues and push into my branch on the official SVN 
server.
3) Create a ticket and wait for the merge.

Initial tests: http://hg.blaise.ru/public/fpc-tests .

A) Things that work (at least, expected to -- before the merge):
* embedding nameless routines into expressions;
* accessing outer variables/parameters/Selves from such routines and 
from routines nested in them;
* new method reference type;
* structural type equivalence for method references;
* 100% Delphi-compatible design and implementation, including two 
crucial points:
1) closure objects are descendants of TInterfacedObject;
2) method references are half-hidden interface types.
B) Things that do not work (not planned to be addressed before the merge):
* accessing outer local-variables/parameters/Selves that are located 
more than one level higher than the nameless routine;
* omitting currently mandatory () for invoking method references 
without arguments;
* assigning normal routines and methods to method references;
* support for generics.
C) Future possibilities:
* special handling for nameless routines that do not capture anything.
May go into A) or B): capturing large parameters by value may have issues -- 
needs checking.
Known bugs, mostly for A): 
http://hg.blaise.ru/public/fpc-tests/file/tip/closures/TODO .

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

Re: [fpc-devel] Closures

[Blaise]

On 09.12.2015 13:43, bla...@blaise.ru wrote:


http://hg.blaise.ru/public/fpc


Sorry, forgot:
In case someone wants to play, but does not want to clone & compile for himself 
(and runs untrusted binaries), the executable for Windows/x86 is 
http://blaise.ru/fpc/fpc-closures-9.7z . Should work with compiled units from 
ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/i386-win32/fpc-3.1.1.i386-win32.zip 
. NB: built with EXTDEBUG -- beware of bogus diagnostic compiler messages.

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

Re: [fpc-devel] Closures

[Michael Schnell]

Great !

I am using a kind of home-brew pseudo closure (a function that ends with 
"free;") in a project I am preparing.I'd be happy to use the formally 
correct stuff.


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

Re: [fpc-devel] Closures

[Maciej Izak]

2015-12-09 11:43 GMT+01:00 :

> On 09.03.2015 16:36, bla...@blaise.ru wrote:
>
>> On 15.01.2012 18:26, Blaise wrote:
>>
>>> I have implemented the support for the Delphi-compatible non-generic
>>> closures.
>>>
>> I am ready to commit the improved (and fully compilable) version.
>>
>
> Four years later, here comes (vastly improved) second attempt at a public
> release: http://hg.blaise.ru/public/fpc .
>

Sounds good.  I'm waiting for this for a long time. Anonymous methods are
cool :)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp

[Hans-Peter Diettrich]

Am 09.03.2015 um 14:36 schrieb bla...@blaise.ru:
FPC trunk r30150, compiled with EXTDEBUG, emits a debug warning for 
the following program:

--8--
type T = interface
procedure Bar;
end;

function Foo: T;
begin
result := nil
end;

begin
Foo().Bar()
// ^-- Warning: tgobj: (FreeTemp) temp at pos -44 is already free !
end.
--8--
Does this indicate a problem in the compiler, or is this warning bogus?

I'd assume that the warning refers to result := nil in Foo(). Assign 
something different and try again to find out more.


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

Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp

[Jonas Maebe]

On 09 Mar 2015, at 14:36, bla...@blaise.ru wrote:


On 15.01.2012 18:26, Blaise Thorn wrote:

I have implemented the support for the Delphi-compatible non- 
generic closures.


I am ready to commit the improved (and fully compilable) version.
Per Jonas Maebe's suggestion, I am going to create a new branch  
(also, last time I tried to commit into the existing closures  
branch, I was consistently getting 500 Internal Server Error).


Do you already have an svn account?


begin
Foo().Bar()
// ^-- Warning: tgobj: (FreeTemp) temp at pos -44 is already free !
end.
--8--
Does this indicate a problem in the compiler, or is this warning  
bogus?


It indicates a problem in the compiler. As the message indicates, it  
means that you (or someone else before you) are trying to free a temp  
(allocated via tg.gettemp or the like) twice. The generated code will  
still be ok in this case, but it could lead to trouble in case a temp  
would be allocated again in between which would happen to get the same  
address as the old one, since then the second free of the old temp  
will free the new temp.



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

Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp

[Blaise]

On 10.03.2015 15:47, Jonas Maebe wrote:


Do you already have an svn account?


The one I had back in 2012.
My old branch is here: 
http://svn.freepascal.org/svn/fpc/branches/blaise/closures


It indicates a problem in the compiler.


Thanks.
Shall I file it in the bug tracker, then?


As the message indicates, it means that you (or someone else before you) are 
trying to free a temp (allocated via tg.gettemp or the like) twice.


I am slightly confused by your choice of the pronoun, so allow me to reiterate: the issue 
exists in the stock compiler, even without my patches applied.


The generated code will still be ok in this case, but it could lead to trouble 
in case a temp would be allocated again in between which would happen to get 
the same address as the old one, since then the second free of the old temp 
will free the new temp.


I am not at all familiar with this part of the compiler, so devising a test 
case, that would result in invalid codegen, would be difficult for me.
Based on your explanation, it seems it would be something like
Foo().Bar( YieldAnotherTemp() )
assuming that YieldAnotherTemp() is called after Foo()?

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

Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp

[Jonas Maebe]

On 10 Mar 2015, at 14:29, bla...@blaise.ru wrote:


On 10.03.2015 15:47, Jonas Maebe wrote:


Do you already have an svn account?


The one I had back in 2012.
My old branch is here: 
http://svn.freepascal.org/svn/fpc/branches/blaise/closures


You should still have access to everything under 
http://svn.freepascal.org/svn/fpc/branches/blaise


It indicates a problem in the compiler.


Thanks.
Shall I file it in the bug tracker, then?


Can't hurt.

As the message indicates, it means that you (or someone else before  
you) are trying to free a temp (allocated via tg.gettemp or the  
like) twice.


I am slightly confused by your choice of the pronoun, so allow me to  
reiterate: the issue exists in the stock compiler, even without my  
patches applied.


Then it will be someone else before you.

The generated code will still be ok in this case, but it could lead  
to trouble in case a temp would be allocated again in between which  
would happen to get the same address as the old one, since then the  
second free of the old temp will free the new temp.


I am not at all familiar with this part of the compiler, so devising  
a test case, that would result in invalid codegen, would be  
difficult for me.

Based on your explanation, it seems it would be something like
Foo().Bar( YieldAnotherTemp() )
assuming that YieldAnotherTemp() is called after Foo()?


It depends on when exactly the second free of the initial temp occurs.  
A testcase that results in invalid code is not necessary, however. It  
should be easily debuggable without that (although fixing it may be  
more tricky).



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

Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp

[Blaise]

On 10.03.2015 15:09, Hans-Peter Diettrich wrote:


I'd assume that the warning refers to result := nil in Foo().


Wrong. And the comment clearly indicates to which line it refers.
This happens because of the call chaining.

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

Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp

[Blaise]

On 15.01.2012 18:26, Blaise Thorn wrote:


I have implemented the support for the Delphi-compatible non-generic closures.


I am ready to commit the improved (and fully compilable) version.
Per Jonas Maebe's suggestion, I am going to create a new branch (also, last time I tried 
to commit into the existing closures branch, I was consistently getting 500 
Internal Server Error).

I would like to acknowledge the participation of Craig Peterson of Scooter 
Software, who was persistent enough to nudge me into completing this, provided 
additional testing, and offered a compensation for the time spent on the last 
stage.


Whilst I mutilate the source code into compatibility with the FPC coding 
style, I have some questions that can be raised even before the code is 
committed.

FPC trunk r30150, compiled with EXTDEBUG, emits a debug warning for the 
following program:
--8--
type T = interface
procedure Bar;
end;

function Foo: T;
begin
result := nil
end;

begin
Foo().Bar()
// ^-- Warning: tgobj: (FreeTemp) temp at pos -44 is already free !
end.
--8--
Does this indicate a problem in the compiler, or is this warning bogus?

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

Re: [fpc-devel] Closures via interfaces

[Sven Barth]

On 07.06.2013 18:44, Vasiliy Kevroletin wrote:



It's not yet available in trunk, just a work in progress. Though I DO
hope that it will be part of trunk once Vasiliy is finished :)

Regards,
Sven


I also hope that my work will be in trunk in the future. But instead of
big merge of separate brunch I would prefer to produce series of small
patches. I prepare first such patch. It will allow to parse anonymous
functions but will not allow to capture variables. Next patch will be
capturing of variables(it already works). Further refactoring, bugfixes,
optimizations.
First patch can produce some negative side effect. Next will be safer.
It should not affect programs which don't use closures.
I uploaded patches for review into mantis. Changes are synchronized with
latest revision and coding style is fixed.
Fate of this changes is important for me, because it's my graduate work.
That is why I need feedback from developers. Most important question:
does my work make sense for you? If someone will find time to attentive
review then comments about changes quality are welcome. And if first
patch is ok but have some minor problems then I'm ready to quickly fix it.


I'll try to take a look at it tomorrow.

Regards,
Sven

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

Re: [fpc-devel] Closures via interfaces

[Vasiliy Kevroletin]

It's not yet available in trunk, just a work in progress. Though I DO 
hope that it will be part of trunk once Vasiliy is finished :)


Regards,
Sven


I also hope that my work will be in trunk in the future. But instead of 
big merge of separate brunch I would prefer to produce series of small 
patches. I prepare first such patch. It will allow to parse anonymous 
functions but will not allow to capture variables. Next patch will be 
capturing of variables(it already works). Further refactoring, bugfixes, 
optimizations.
First patch can produce some negative side effect. Next will be safer. 
It should not affect programs which don't use closures.
I uploaded patches for review into mantis. Changes are synchronized with 
latest revision and coding style is fixed.
Fate of this changes is important for me, because it's my graduate work. 
That is why I need feedback from developers. Most important question: 
does my work make sense for you? If someone will find time to attentive 
review then comments about changes quality are welcome. And if first 
patch is ok but have some minor problems then I'm ready to quickly fix it.


Thanks,
Vasiliy

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

Re: [fpc-devel] Closures via interfaces

[Sven Barth]

Am 27.05.2013 02:31 schrieb Paul Ishenin i...@kmiac.ru:

 27.05.2013 5:52, Maciej Izak пишет:


 So I am waiting impatiently ^^. I think it's interesting time for
 FPC! To be completely happy, there is only one seriously lack - extended
 RTTI. :)


 RTTI has been extended recently:
http://wiki.lazarus.freepascal.org/User_Changes_Trunk#RTTI_changes

 Please tell what exactly you are waiting for?

The new extended RTTI introduced in Delphi 2009 which allows access to
private/protected/public members as well together with attributes and
things like TVirtualMethodInterceptor, Invoke and TValue.

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

Re: [fpc-devel] Closures via interfaces

[Paul Ishenin]

27.05.2013 15:32, Sven Barth пишет:


The new extended RTTI introduced in Delphi 2009 which allows access to
private/protected/public members as well together with attributes and
things like TVirtualMethodInterceptor, Invoke and TValue.


Sven, I did not ask what and how delphi implemented. I asked Maciej Izak 
what he wants from extended RTTI. Maybe this is a small subset which is 
not very hard to implement.


Best regards,
Paul Ishenin

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

Re: [fpc-devel] Closures via interfaces

[Maciej Izak]

 Sven, I did not ask what and how delphi implemented. I asked Maciej Izak
 what he wants from extended RTTI. Maybe this is a small subset which is not
 very hard to implement.
 Best regards,
 Paul Ishenin


Unfortunately, Sven is right :). I need this to share another free library
for FPC. It was originally intended for sale to the Embarcadero. Absolute
automatic binary streaming (seriously, for each type that exists in Pascal,
including Class, ClassRef, Interfaces, Pointers, menaged records with help
of attributes). Small demo:

===begin code===
  // save
  f := TFileStream.Create(dSaveLDFM.FileName, fmCreate);
  f.WriteAnsiChar(4, FILE_TAG[0]);
  f.WriteUInt32(1);
  f.WriteTArraystring(FDfmDictionary.Keys.ToArray);
  f.Free;

  // read
  f := TFileStream.Create(dOpenLDFM.FileName, fmOpenRead);
  f.ReadAnsiChar(4, stag);
  if stag  FILE_TAG then raise EProgrammerNotFound.Create('File is
corrupted');
  if f.ReadUInt32  1 then raise EProgrammerNotFound.Create('Wrong file
version');
  f.ReadTArraystring(LList);
  f.Free;
===end code===

Implemented as helpers for streams :). It will be another stress test for
generic types, and RTTI.
To done this, FPC needs:

1. Extended RTTI (especially with attributes and access to
private/protected/public members. This library don't need
TVirtualMethodInterceptor,
Invoke (but I think attributes needs Invoke :( ) and TValue)
2. Fix/implementation of: http://bugs.freepascal.org/view.php?id=24254

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

Re: [fpc-devel] Closures via interfaces

[Paul Ishenin]

27.05.2013 17:17, Maciej Izak wrote:


Unfortunately, Sven is right :). I need this to share another free
library for FPC. It was originally intended for sale to the Embarcadero.
Absolute automatic binary streaming (seriously, for each type that
exists in Pascal, including Class, ClassRef, Interfaces, Pointers,
menaged records with help of attributes). Small demo:


...


1. Extended RTTI (especially with attributes and access to
private/protected/public members. This library don't need
TVirtualMethodInterceptor, Invoke (but I think attributes needs Invoke
:( ) and TValue)


If you don't need RTTI unit then it will be much more simplier to 
implement your requirements.


Attributes are half ready in a branch. RTTI for non-published elements 
(together with $RTTI directive) is not a very hard task.


Best regards,
Paul Ishenin

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

Re: [fpc-devel] Closures via interfaces

[Maciej Izak]

 If you don't need RTTI unit then it will be much more simplier to
 implement your requirements.

 Attributes are half ready in a branch. RTTI for non-published elements
 (together with $RTTI directive) is not a very hard task.


I use a lot of TypInfo. If I get RTTI for non-published elements and
attributes I think I can elminate RTTI module (or write my own compatible
implementation for RTTI). But also important is fix for 24254.

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

Re: [fpc-devel] Closures via interfaces

[Hans-Peter Diettrich]

Vasiliy Kevroletin schrieb:

I described details of proposed and partly implemented approach in 
mantis. This is Delphi's approach. Some people call it closures via 
interfaces. In slightly modified way it will allow to capture variables 
by value (which was requested in previous discussion). I like this 
approach because it's simple: it doesn't require to change codegenerator 
or rtl. On the other hand for each closure it creates new interface. And 
almost for each closure it creates new class. As a result: space 
overhead because of virtual tables and rtti.


My question to community is: what do you think about proposed 
implementation? Are there arguments for another approach?


In contrast to anonymous procedures, true closures require fixed and
immutable parameters. This requirement will disallow also references to
variables outside the function, e.g. in their enclosing procedure. This
would require deep(!) copies of all values/variables used in the
anonymous procedure body, together with tests of already copied memory
objects. How to create a deep copy at all, of e.g. an interface
reference or a Handle?

IMO we have to decide in the first place whether to implement anonymous
procedures for Delphi compatibility *only*, or whether we want true
closures (functional programming) inside the imperative OPL.

ATM I have no opinion about this matter, because I don't plan to use
neither anonymous procedures nor functional programming myself. To me it
looks safer (better controllable) to use ordinary callback procedures
instead of anonymous ones, and for functional programming I'd only
accept an full-featured implementation, e.g. a LISP like sub-system
*written* in Pascal.

DoDi

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

Re: [fpc-devel] Closures via interfaces

[Sven Barth]

Am 27.05.2013 16:18 schrieb Hans-Peter Diettrich drdiettri...@aol.com:

 Vasiliy Kevroletin schrieb:


 I described details of proposed and partly implemented approach in
mantis. This is Delphi's approach. Some people call it closures via
interfaces. In slightly modified way it will allow to capture variables by
value (which was requested in previous discussion). I like this approach
because it's simple: it doesn't require to change codegenerator or rtl. On
the other hand for each closure it creates new interface. And almost for
each closure it creates new class. As a result: space overhead because of
virtual tables and rtti.

 My question to community is: what do you think about proposed
implementation? Are there arguments for another approach?


 In contrast to anonymous procedures, true closures require fixed and
 immutable parameters. This requirement will disallow also references to
 variables outside the function, e.g. in their enclosing procedure. This
 would require deep(!) copies of all values/variables used in the
 anonymous procedure body, together with tests of already copied memory
 objects. How to create a deep copy at all, of e.g. an interface
 reference or a Handle?

 IMO we have to decide in the first place whether to implement anonymous
 procedures for Delphi compatibility *only*, or whether we want true
 closures (functional programming) inside the imperative OPL.

The values of local variables are captured for each closure. While in
Delphi they are captured by reference (basically; it's in fact a bit more
complicated) Vasiliy plans to also allow capturing by value. Inside the
procedure body itself the usual rules apply, so there won't be any
immutability. Global variables will behave like in normal procedures and
also the state of object oriented variables can be modified. So it's mostly
consistent with the remaining way that Pascal's procedures work with a few
additional concepts that heed to be documented accordingly.

Also there is no true way of closures, as in the end each language does
have its own behavior.

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

[fpc-devel] Closures via interfaces

[Vasiliy Kevroletin]

Hi all,

About 2 months ago there was a big discussion about closures(thread 
Delphi anonymous methods). After this discussion I started work on 
Delhi-like closures for fpc. I am far from finish and current 
implementation is not perfect. But I already have positive results: it's 
possible to declare and use anonymous functions. After few changes 
closures will be able to capture variables. I created mantis#24481 to 
handle this work. Everyone who is interested in closures and good in 
compiler is welcome into mantis. I would be happy if someone looked into 
changes and said few words.


I described details of proposed and partly implemented approach in 
mantis. This is Delphi's approach. Some people call it closures via 
interfaces. In slightly modified way it will allow to capture variables 
by value (which was requested in previous discussion). I like this 
approach because it's simple: it doesn't require to change codegenerator 
or rtl. On the other hand for each closure it creates new interface. And 
almost for each closure it creates new class. As a result: space 
overhead because of virtual tables and rtti.


My question to community is: what do you think about proposed 
implementation? Are there arguments for another approach?


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

Re: [fpc-devel] Closures via interfaces

[Sven Barth]

On 26.05.2013 12:12, Vasiliy Kevroletin wrote:

Hi all,

About 2 months ago there was a big discussion about closures(thread
Delphi anonymous methods). After this discussion I started work on
Delhi-like closures for fpc. I am far from finish and current
implementation is not perfect. But I already have positive results: it's
possible to declare and use anonymous functions. After few changes
closures will be able to capture variables. I created mantis#24481 to
handle this work. Everyone who is interested in closures and good in
compiler is welcome into mantis. I would be happy if someone looked into
changes and said few words.

I described details of proposed and partly implemented approach in
mantis. This is Delphi's approach. Some people call it closures via
interfaces. In slightly modified way it will allow to capture variables
by value (which was requested in previous discussion). I like this
approach because it's simple: it doesn't require to change codegenerator
or rtl. On the other hand for each closure it creates new interface. And
almost for each closure it creates new class. As a result: space
overhead because of virtual tables and rtti.

My question to community is: what do you think about proposed
implementation? Are there arguments for another approach?


Thank you for the update. I'm still looking at your changes, but one 
thing I noticed: please adhere to the coding style used in the compiler 
(look at pgenutil.pas for example). For example don't use 1 line 
if-statements (e.g. if x then foo;), but put the statement into a 
seperate line.


I should have told you this before you started, but I've forgotten it :(

Regards,
Sven

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

Re: [fpc-devel] Closures via interfaces

[Sven Barth]

On 26.05.2013 16:05, Sven Barth wrote:

On 26.05.2013 12:12, Vasiliy Kevroletin wrote:

Hi all,

About 2 months ago there was a big discussion about closures(thread
Delphi anonymous methods). After this discussion I started work on
Delhi-like closures for fpc. I am far from finish and current
implementation is not perfect. But I already have positive results: it's
possible to declare and use anonymous functions. After few changes
closures will be able to capture variables. I created mantis#24481 to
handle this work. Everyone who is interested in closures and good in
compiler is welcome into mantis. I would be happy if someone looked into
changes and said few words.

I described details of proposed and partly implemented approach in
mantis. This is Delphi's approach. Some people call it closures via
interfaces. In slightly modified way it will allow to capture variables
by value (which was requested in previous discussion). I like this
approach because it's simple: it doesn't require to change codegenerator
or rtl. On the other hand for each closure it creates new interface. And
almost for each closure it creates new class. As a result: space
overhead because of virtual tables and rtti.

My question to community is: what do you think about proposed
implementation? Are there arguments for another approach?


Thank you for the update. I'm still looking at your changes, but one
thing I noticed: please adhere to the coding style used in the compiler
(look at pgenutil.pas for example). For example don't use 1 line
if-statements (e.g. if x then foo;), but put the statement into a
seperate line.

I should have told you this before you started, but I've forgotten it :(


Ah, now that I've reached the last commit I see that you've already 
adjusted most cases. Please change IsClosure to is_closure as well.


Regards,
Sven

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

Re: [fpc-devel] Closures via interfaces

[Maciej Izak]

Cool! Now I can fully complete library Generics.Collections for FPC
(especially Generics.Defaults) ;D (
https://code.google.com/p/fpc-generics-collections/ ).

FPC is getting stronger!

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

Re: [fpc-devel] Closures via interfaces

[Sven Barth]

On 26.05.2013 21:16, Maciej Izak wrote:

Cool! Now I can fully complete library Generics.Collections for FPC
(especially Generics.Defaults) ;D (
https://code.google.com/p/fpc-generics-collections/ ).


It's not yet available in trunk, just a work in progress. Though I DO 
hope that it will be part of trunk once Vasiliy is finished :)


Regards,
Sven


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

Re: [fpc-devel] Closures via interfaces

[Maciej Izak]

 It's not yet available in trunk, just a work in progress. Though I DO hope
 that it will be part of trunk once Vasiliy is finished :)


So I am waiting impatiently ^^. I think it's interesting time for FPC! To
be completely happy, there is only one seriously lack - extended RTTI. :)

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

Re: [fpc-devel] Closures via interfaces

[Paul Ishenin]

27.05.2013 5:52, Maciej Izak пишет:


So I am waiting impatiently ^^. I think it's interesting time for
FPC! To be completely happy, there is only one seriously lack - extended
RTTI. :)


RTTI has been extended recently: 
http://wiki.lazarus.freepascal.org/User_Changes_Trunk#RTTI_changes


Please tell what exactly you are waiting for?

Best regards,
Paul Ishenin

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

Re: [fpc-devel] Closures via interfaces

[Dimitri Smits]

Paul,

I think the OP meant the unit called 'rtti' in recent XE versions of Delphi.

kind regards,
Dimitri Smits

- Oorspronkelijk e-mail -
 Van: Paul Ishenin i...@kmiac.ru
 Aan: FPC developers' list fpc-devel@lists.freepascal.org
 Verzonden: Maandag 27 mei 2013 02:30:40
 Onderwerp: Re: [fpc-devel] Closures via interfaces

 27.05.2013 5:52, Maciej Izak пишет:

  So I am waiting impatiently ^^. I think it's interesting time for
  FPC! To be completely happy, there is only one seriously lack -
  extended
  RTTI. :)

 RTTI has been extended recently:
 http://wiki.lazarus.freepascal.org/User_Changes_Trunk#RTTI_changes

 Please tell what exactly you are waiting for?

 Best regards,
 Paul Ishenin

 ___
 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] Closures

[Sven Barth]

Am 15.01.2012 16:27 schrieb Blaise Thorn m...@blaise.ru:

 Hello.

 I have implemented the support for the Delphi-compatible non-generic
closures.

 Gradually, I plan to extend that support with:
  * generic closures (I am not sure, though, how much current generics are
expected to be compatible with Delphi);

How firm are you with the implementation of generics inside the compiler?
If you're not that firm it might be better if I implement generic
procedures/methods first and then you can build on that (as that should
hopefully be reusable by you).

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

Re: [fpc-devel] Closures

[Blaise Thorn]

On 16.01.2012 16:05, Sven Barth wrote:


How firm are you with the implementation of generics inside the compiler?


Totally blank. Since you are the person who has been working on that area most 
recently, I would actually appreciate if you could compile a document (on the 
wiki?) outlining the internal workings of generics in FPC; for the current 
documentation, I understand, is quite lacking. On my part, I already have a 
document (only in Russian, though) describing the implementation of closures; I 
will translate and publish it after my initial commits (which I expect to be on 
We/Th this week).


If you're not that firm it might be better if I implement generic 
procedures/methods first and then you can build on that (as that should 
hopefully be reusable by you).


For now, I don't reckon that any ordering is required.
Note that the only thing in closures that can have type parameters is method 
references
type MT = reference to procedure(const X: T);
which are converted, internally, into generic interfaces.
A nameless routine (closure) can only /refer/ to generic type parameters of the 
enclosing routine/class, and I hope that making it generic-aware/generic-safe 
wouldn't be that hard.

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

Re: [fpc-devel] Closures

[Sven Barth]

On 16.01.2012 15:11, Blaise Thorn wrote:

On 16.01.2012 16:05, Sven Barth wrote:


How firm are you with the implementation of generics inside the compiler?


Totally blank. Since you are the person who has been working on that
area most recently, I would actually appreciate if you could compile a
document (on the wiki?) outlining the internal workings of generics in
FPC; for the current documentation, I understand, is quite lacking. On
my part, I already have a document (only in Russian, though) describing
the implementation of closures; I will translate and publish it after my
initial commits (which I expect to be on We/Th this week).



Might be an idea... currently I'm a bit busy with university, but after 
that (beginning or middle of February) I hope to fully start through 
again :)



If you're not that firm it might be better if I implement generic
procedures/methods first and then you can build on that (as that
should hopefully be reusable by you).


For now, I don't reckon that any ordering is required.
Note that the only thing in closures that can have type parameters is
method references
type MT = reference to procedure(const X: T);
which are converted, internally, into generic interfaces.
A nameless routine (closure) can only /refer/ to generic type parameters
of the enclosing routine/class, and I hope that making it
generic-aware/generic-safe wouldn't be that hard.



Ahhh, now I see. I haven't used closures yet, so I didn't know exactly 
in what context generics can be used. Depending on how you parse the 
reference to (are you using the parsing of procedure variables here?) 
then you might only need to add the type such a closure is parsed as to 
the types for which generics are supported. If they are indeed converted 
to interfaces you might not have to change that much at all...


Btw: in mode ObjFPC (or non-Delphi modes in general) the declaration 
would then look like this (to be conform with other generic declarations):


type
  generic MT = reference to procedure(const X: T);

Again you shouldn't need to change that much.

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

[fpc-devel] Closures

[Blaise Thorn]

Hello.

I have implemented the support for the Delphi-compatible non-generic closures.

Gradually, I plan to extend that support with:
 * generic closures (I am not sure, though, how much current generics are 
expected to be compatible with Delphi);
 * Delphi-incompatible extensions (simple nameless routines, without capturing 
of variables, for one).

There are also several Delphi-compatibility fixes that should be made, not 
directly related to closures.

My question is: how the work should be organised? Should a separate SVN branch 
be created for this?

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

Re: [fpc-devel] Closures

[Florian Klämpfl]

Am 15.01.2012 16:26, schrieb Blaise Thorn:
 My question is: how the work should be organised? Should a separate SVN
 branch be created for this?

The best is to create an svn branch. See private mail.

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

Re: [fpc-devel] Closures

[ik]

On Sun, Jan 15, 2012 at 17:38, Florian Klämpfl flor...@freepascal.orgwrote:

 Am 15.01.2012 16:26, schrieb Blaise Thorn:
  My question is: how the work should be organised? Should a separate SVN
  branch be created for this?

 The best is to create an svn branch. See private mail.


‎The best way is to use distributed version control imho.
Git, hg etc provide the ability to store the changes locally and push them
also to remote places.
It also allow me not to disturb you when working on the same files for
different needs.

My 2 cents in the matter (Graeme behind you :))



 ___
 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] Closures

[Florian Klämpfl]

Am 15.01.2012 16:45, schrieb ik:
 On Sun, Jan 15, 2012 at 17:38, Florian Klämpfl flor...@freepascal.org
 mailto:flor...@freepascal.org wrote:
 
 Am 15.01.2012 16:26, schrieb Blaise Thorn:
  My question is: how the work should be organised? Should a
 separate SVN
  branch be created for this?
 
 The best is to create an svn branch. See private mail.
 
 
 ‎The best way is to use distributed version control imho.
 Git, hg etc provide the ability to store the changes locally and push
 them also to remote places.

Yes, and probably pushed somewhere nobody notices or lost with the next
hd crash because never pushed. Having it in the central fpc svn
repository allows everybody to review it what e.g. I try to do with
every commit to the central fpc svn repository.

 It also allow me not to disturb you when working on the same files for
 different needs.

The same applies for a svn branch.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Closures

[Sven Barth]

On 15.01.2012 16:56, Florian Klämpfl wrote:

Am 15.01.2012 16:45, schrieb ik:

On Sun, Jan 15, 2012 at 17:38, Florian Klämpflflor...@freepascal.org
mailto:flor...@freepascal.org  wrote:

 Am 15.01.2012 16:26, schrieb Blaise Thorn:
   My question is: how the work should be organised? Should a
 separate SVN
   branch be created for this?

 The best is to create an svn branch. See private mail.


‎The best way is to use distributed version control imho.
Git, hg etc provide the ability to store the changes locally and push
them also to remote places.


Yes, and probably pushed somewhere nobody notices or lost with the next
hd crash because never pushed. Having it in the central fpc svn
repository allows everybody to review it what e.g. I try to do with
every commit to the central fpc svn repository.


Well... at least for me the use of Git (together with Git-SVN) provided 
the possibility for me to commit code while on the train (I have a data 
flatrate only since August and even then doing a SVN commit or update 
while on the train is sometimes not the best ^^) [also I didn't want to 
sync every night when at home, because often I'd simply forget that ;) ]


Regards,
Sven

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

Re: [fpc-devel] Closures

[Marco van de Voort]

In our previous episode, Sven Barth said:
  repository allows everybody to review it what e.g. I try to do with
  every commit to the central fpc svn repository.
 
 Well... at least for me the use of Git (together with Git-SVN) provided 
 the possibility for me to commit code while on the train (I have a data 
 flatrate only since August and even then doing a SVN commit or update 
 while on the train is sometimes not the best ^^) [also I didn't want to 
 sync every night when at home, because often I'd simply forget that ;) ]

I use SVN on the train too. If you need a checkout, just copy the repo and
revert.

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