the first reply to this
thread. Allow me to quote my response:
On 26.12.2021 15:40, Blaise--- via fpc-devel wrote:
On 26.12.2021 11:50, Michael Van Canneyt via fpc-devel wrote:
As I see it, it's just shorthand syntax to allow skipping the name 'Invoke'.
None of what is shown
On 27.12.2021 0:57, Martin Frb via fpc-devel wrote:
writeln( aC(33) );
aC('hello');
the above examples are probably intended to show the syntax. But not indented
to show any useful application?
The test you quoted demonstrates what is already possible, syntactically and
semantically,
On 27.12.2021 0:03, Michael Van Canneyt via fpc-devel wrote:
On Sun, 26 Dec 2021, Blaise--- via fpc-devel wrote:
On 26.12.2021 19:33, Michael Van Canneyt via fpc-devel wrote:
On Sun, 26 Dec 2021, Blaise--- via fpc-devel wrote:
following your reasoning, the same should be said about
On 26.12.2021 23:47, Blaise--- via fpc-devel wrote:
---8<---
type R = record
procedure Foo(...); operator ();
function Bar(const A, B: R): R; operator +;
end;
---8<---
Made a blunder there, sorry: for Bar, it should either be
function Bar(const Other:
On 26.12.2021 19:33, Michael Van Canneyt via fpc-devel wrote:
On Sun, 26 Dec 2021, Blaise--- via fpc-devel wrote:
On 26.12.2021 11:50, Michael Van Canneyt via fpc-devel wrote:
None of what is shown below cannot be handled by ordinary methods
Well, yes. But, following your reasoning, the same
On 26.12.2021 17:40, Ryan Joseph via fpc-devel wrote:
I'm 99% certain using the method name "Invoke" would be rejected on the grounds
of backwards compatibility.
Not to argue for the "procedure/function Invoke" syntax, but it hardly breaks backward
compatibility. Only in the purest non-practi
On 26.12.2021 11:50, Michael Van Canneyt via fpc-devel wrote:
Please explain what's the point or benefit of this.
Do you mean "in general", or "specifically to FPC"?
A) In general: I reckon that the article covers the matter quite well; I have
nothing to add.
B) Specifically for FPC: it is up
I propose that the support for https://en.wikipedia.org/wiki/Function_object be
added to the FPC.
A subset of such functionality already existed as a part of my implementation
of closures, so I extended that part to implement the core feature for allowing
functors -- overloading of the call op
The attached modeswitch_closures.patch introduces {$modeswitch Closures}; it is
included in {$mode Delphi}.
There is a distinction between anonymous routines (defined in-place, without a
name) and closures (capture the context they are invoked with). The switch
encompasses both, but goes for t
DCC allows the subj (provided that the class type is known at compile time),
FPC does not.
The attached init_methptr_with_classmeth.patch implements this feature.
---8<---
type C = class
class procedure Foo;
end;
class procedure C.Foo; begin end;
type CC = class of C;
type H = c
On 22.12.2021 21:16, Blaise wrote:
1) The attached metaclass_meth_to_procvar-1.patch fixes the internal error
reported for:
[ICE] Assigning class methods, accessed via a class reference type, to
incompatible procvars
Also fixes:
1B) [ICE] Assigning class static methods, accessed via an
Subj silently produces invalid codegen:
---8<---
var Z: procedure of object;
type R = record
procedure Foo;
end;
procedure R.Foo; begin end;
type O = object
procedure Foo;
end;
procedure O.Foo; begin end;
type C = class
procedure Foo;
class procedure Clas
Subj silently produces invalid codegen:
---8<---
type C = class end;
type H = class helper for C
class procedure Bar;
end;
class procedure H.Bar;
begin
writeln('H.Bar(self=', ClassName, ')')
end;
var Z: procedure of object;
begin
Z := H.Bar; // BadCG: GARBAGE
1) The attached metaclass_meth_to_procvar-1.patch fixes the internal error
reported for:
[ICE] Assigning class methods, accessed via a class reference type, to
incompatible procvars
---8<---
type C = class
class procedure NonStatic;
class procedure Static; static;
end;
cl
1) The following three routines:
pdecsub.pas!parse_parameter_dec
pdecvar.pas!maybe_parse_proc_directives
ptype.pas!read_named_type\procvar_dec
create a dummy typesym for the procdef, for the sole purpose of invoking
parse_var_proc_directives, which merely extracts that pro
On 19.12.2020 16:51, Sven Barth wrote:
Considering that it's only intended for internal use, yes I'm aboard with that.
Here is the first change: http://hg.blaise.ru/public/fpc/rev/7c78bfdaed9a
(attached).
Strictly speaking, some local classes and interfaces can be compiled without
that -- th
Behind the scene, the Closures implementation declares classes and interfaces.
And, because I strongly believe it to be conceptually the right way, such
entities are declared in the innermost routine scope. For example,
---8<---
procedure Foo;
type Local = reference to procedure;
The patch http://hg.blaise.ru/public/fpc/rev/698389953e49 (attached) fixes the
following:
---8<---
// EXPECTED: 'Error: Illegal function result type'
// ACTUAL: gets compiled
type M = function : file;
begin
end.
---8<---
--
βþ
# HG changeset patch
# User Blaise.ru
# Date 1608281
The patch http://hg.blaise.ru/public/fpc/rev/544a934d262e (attached) fixes the
following:
---8<---
{$Mode Delphi}
type G = class
var X: T;
// EXPECTED: gets compiled
// ACTUAL: 'Error: Generics without specialization cannot be used as a
type for a variable'
The patch http://hg.blaise.ru/public/fpc/rev/0a8aff8d8273 (attached) fixes the
following:
---8<---
{$Mode Delphi}
type R = record
var X: Integer;
function Foo: Integer;
end;
function R.Foo: Integer;
begin
result := X
end;
var F: function : Integer of object;
On 16.12.2020 12:24, Michael Van Canneyt via fpc-devel wrote:
To be correct: Result is not the name of the result value, it is an alias.
I did not dispute that. The important point here is: "an alias" to /what/?
You can still use the function name for the result, so "Result" is in fact an
al
On 16.12.2020 0:07, Sven Barth wrote:
No, those two are in fact correct this way.
Is that the /team's/ consensus?
The modeswitch Result enables the use of Result as an alias for *any* routine …
Incorrect. The identifier Result does not alias the routine, it aliases the
routine's return val
Consider this test case:
---8<---
{$mode ObjFPC}
// EXPECTED: 'Error: Identifier not found "result"'
// ACTUAL BUG #1: gets compiled
operator - (const L, R: Char) returned: Char;
begin
result := 'Z'
end;
// EXPECTED: gets compiled
// ACTUAL BUG #2: 'Error: Duplicate identifier "r
I have questions/suggestions WRT Jonas' SVN r42342:
https://github.com/graemeg/freepascal/commit/40d31e34116efffa239b6dc94373fcfccedfa646
1) Why was `typesym.owner` used instead of `owner`? Beside efficiency, this
hurts understandability: is it possible for a typedef to reside in a symtable
sep
On 09.12.2019 11:18, Jonas Maebe wrote:
replying to almost every line of every mail how every different way of saying
more or less the same thing is wrong.
I take issue with that description. Sven was not "saying more or less the same thing" in
"different way". Instead, on every next step, w
On 08.12.2019 22:30, Sven Barth wrote:
there is no official way to access such parameters
1) At the time of providing that answer on Stack Overflow, Barry Kelly worked as a DCC
developer. While it is not truly official, it is pretty close, and satisfies my criterion
of "fully conforming to th
On 07.12.2019 21:39, Sven Barth wrote:
I'm arguing that there is no builtin way to *access* the parameters passed in
such a way.
You are arguing that /now/, but it is not what you said earlier. You said,
verbatim:
one can not access VarArgs parameters inside a Delphi function (without
resor
On 07.12.2019 14:21, Sven Barth wrote:
I stand by my point that the combination of anonymous function variables with
calling conventions and cblocks occurs very, very seldomly.
I am not necessarily disputing that point, I am disputing your design decision,
which was misinformed, but you cont
Beforehand, to provide a context, here are some excerpts from private
correspondence:
On 11.12.2016 22:00:37 +0300, bla...@blaise.ru wrote in
1c51a35a-bbbc-c99d-232f-0bf6529df...@blaise.ru:
my progress thus far
9) Method reference directives are now allowed:
type M = reference to proce
1) Currently, the following snippet
vmtbuilder:=TVMTBuilder.Create(...);
vmtbuilder.generate_vmt;
vmtbuilder.free;
is present @
types_dec :objectdef
generate_specialization_phase2 :objectdef
jvm_maybe_create_enum_class
jvm_create_procvar_cl
TVMTBuilder.generate_vmt has
_class.resetvmtentries;
and TVMTBuilder.generate_vmt_def has
{ the VMT definition may already exist in case of generics }
if assigned(try_search_current_module_type(vmtdefname)) then
exit;
Thus, it appears that VMT regeneration use
On 01.12.2019 20:27, Ryan Joseph wrote:
how are the closures coming?
You are literally looking at them coming.
you could submit it into trunk
That is exactly what I am doing. In small self-contained reviewable changesets.
It's been some 6 months now
My last submission in August got no r
On 01.12.2019 19:15, bla...@blaise.ru wrote:
With the following two exceptions, there are no other assigned(vmtentries)
checks before dereferencing.
And one assertion @ TVMTBuilder.generate_vmt :
if assigned(_class.childof) then
begin
if not assigned(_class.c
1) Maybe it was not always the case, but tobjectdef.vmtentries is never nil
(initialised to an empty list @ .create & @ .ppuload. With the following two
exceptions, there are no other assigned(vmtentries) checks before dereferencing. I
propose that these two useless checks be removed.
@ TVMTWr
On 30.11.2019 20:47, Sven Barth via fpc-devel wrote:
Am 30.11.2019 um 13:27 schrieb bla...@blaise.ru:
{ This is a resubmission of
https://lists.freepascal.org/pipermail/fpc-devel/2019-August/041915.html }
trecorddef.create_global_internal generates internal RecordDef names as
'$InternalRec'
{ This is a resubmission of
https://lists.freepascal.org/pipermail/fpc-devel/2019-August/041915.html }
trecorddef.create_global_internal generates internal RecordDef names as
'$InternalRec'+tostr(current_module.deflist.count)
However, since such internal RecordDefs are not necessarily re
On 03.08.2019 16:54, bla...@blaise.ru wrote:
trecorddef.create_global_internal
Currently, autogenerated internal names are composed as
'$InternalRec'+tostr(current_module.deflist.count)
IMO, this is misleading: it appears as if such names 1) would be unique within
a module, and 2) woul
On 03.08.2019 15:01, Sven Barth via fpc-devel wrote:
In principle one could do that, though more often than not inside the compiler
maintainability beats performance. I'd prefer an opinion of Florian and/or
Jonas on this though...
Leaving the issue of current_filepos for a moment, the change
Before the main course, I offer the attached refactorings for
trecorddef.create_global_internal:
1) streamline insertions into the symtable;
2) avoid shadow-copying of the parameter "n", which is now const
--
βþ
# HG changeset patch
# User Blaise
# Date 1564833600 -10800
# Sat Au
On 02.08.2019 21:36, bla...@blaise.ru wrote:
embed a copy of the body of insert_struct_hidden_paras into
TVMTBuilder.generate_vmt, then merge those two procdef-member traversals into
one (hey, performance!)
Would you guys oppose such a change? Then we could rename
insert_struct_hidden_paras
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 yeste
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
> 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
On 22.06.2018 21:42, Jonas Maebe wrote:
The rationale for the above is that they need symbols that are longer than 255
characters.
And such symbols could not be shortened by hashing heads or tails?
The reason the rest uses shortstrings is this is assumed to be faster.
I see that overloade
On 15.06.2018 11:54, Blaise wrote:
What is the official maximum symbol length? If it is 255, as the definition "TSymStr
= ShortString" suggests, then FPC does not always take proper care of it.
In particular, TGNUAssembler.WriteTree has plenty of concatenations similar to
What is the official maximum symbol length? If it is 255, as the definition "TSymStr
= ShortString" suggests, then FPC does not always take proper care of it.
In particular, TGNUAssembler.WriteTree has plenty of concatenations similar to
this one
writer.AsmWriteLn(tai_symbol(hp).sym.name
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
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
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.)
Otherwi
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 hav
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
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
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
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 (a
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 o
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 settl
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 wit
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
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
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 maillis
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
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
On 02.02.2012 1:46, Blaise Thorn wrote:
For know, I am here for a different request: I reckon that small fixes,
especially those not directly related to closures, ought to be submitted
separately.
Or I could create something like http://svn.freepascal.org/svn/fpc/branches/blaise/misc
and
On 15.01.2012 19:26, Blaise Thorn wrote:
I have implemented the support for the Delphi-compatible non-generic closures.
OK, I have started committing into
http://svn.freepascal.org/svn/fpc/branches/blaise/closures
(Be warned, though: I have not even finished with the work I have already done
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 i
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 namele
66 matches
Mail list logo
