On Mon, 7 Oct 2019, Bart wrote:
On Mon, Oct 7, 2019 at 10:30 PM Luca Olivetti wrote:
My bad, I'm not on trunk, I'm on the fixes_3_2 branch :-(
Sorry for the confusion.
I checked out the latest version of that branch (I'm not confident
enough to use trunk in production) but it has the same p
On Tue, 8 Oct 2019, Alexey Tor. wrote:
Ubuntu 18.x x64. FPC 3.3 trunk.
I get handle of '/proc/version' using func below (e.g. handle=22).
Now I want to get file size of that file. and read all contents into
THandleStream. But problem is: THandleSteam.Size gets 0.
I guess THandleStream can ove
Ubuntu 18.x x64. FPC 3.3 trunk.
I get handle of '/proc/version' using func below (e.g. handle=22).
Now I want to get file size of that file. and read all contents into
THandleStream. But problem is: THandleSteam.Size gets 0.
I guess THandleStream can override GetSize to get size smarter. Maybe
s
On Mon, Oct 7, 2019 at 10:30 PM Luca Olivetti wrote:
> My bad, I'm not on trunk, I'm on the fixes_3_2 branch :-(
> Sorry for the confusion.
> I checked out the latest version of that branch (I'm not confident
> enough to use trunk in production) but it has the same problem.
> Oh, well, I can use
On Mon, 7 Oct 2019 16:35:42 -0400
Ryan Joseph wrote:
>[...]
> procedure Run(a: integer; b: string);
> begin
> end;
>
> generic procedure Run(a: S; b: T; c: integer);
> begin
> end;
>
>
> // fails because the non-generic Run() will always be picked and the
> parameter count will be wrong. Run(1
> On Oct 7, 2019, at 12:42 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
>> I mean what happens here? The non-generic functions wins right?
>>
>> procedure Run(a:T; b: word);
>> procedure Run(a: word; b: T);
>> procedure Run(a: word; b: word);
>
> Only for
> Run(word(1),word(2));
Ok, then
El 7/10/19 a les 18:29, Michael Van Canneyt ha escrit:
On Mon, 7 Oct 2019, Luca Olivetti wrote:
El 7/10/19 a les 15:18, Michael Van Canneyt ha escrit:
On Mon, 7 Oct 2019, Luca Olivetti wrote:
I'm facing a strange issue, I don't know if it's StreamIO or
TMemoryStream. The following progra
On Mon, 7 Oct 2019 19:47:58 +0200
Sven Barth via fpc-pascal wrote:
> Mattias Gaertner via fpc-pascal
> schrieb am Mo., 7. Okt. 2019, 18:42:
>
> > On Mon, 7 Oct 2019 12:38:51 -0400
> > Ryan Joseph wrote:
> >
> > > > On Oct 7, 2019, at 10:19 AM, Mattias Gaertner via fpc-pascal
> > > > wrote:
Mattias Gaertner via fpc-pascal schrieb
am Mo., 7. Okt. 2019, 18:42:
> On Mon, 7 Oct 2019 12:38:51 -0400
> Ryan Joseph wrote:
>
> > > On Oct 7, 2019, at 10:19 AM, Mattias Gaertner via fpc-pascal
> > > wrote:
> > >
> > > Note that in Delphi the "non-generic-wins" rule is per parameter:
> > >
> >
On Mon, 7 Oct 2019 12:38:51 -0400
Ryan Joseph wrote:
> > On Oct 7, 2019, at 10:19 AM, Mattias Gaertner via fpc-pascal
> > wrote:
> >
> > Note that in Delphi the "non-generic-wins" rule is per parameter:
> >
> > procedure Run(a:T; b: word);
> > procedure Run(a: word; b: T);
>
> I mean what h
> On Oct 7, 2019, at 10:19 AM, Mattias Gaertner via fpc-pascal
> wrote:
>
> Note that in Delphi the "non-generic-wins" rule is per parameter:
>
> procedure Run(a:T; b: word);
> procedure Run(a: word; b: T);
I mean what happens here? The non-generic functions wins right?
procedure Run(a:T; b
On Mon, 7 Oct 2019, Luca Olivetti wrote:
El 7/10/19 a les 15:18, Michael Van Canneyt ha escrit:
On Mon, 7 Oct 2019, Luca Olivetti wrote:
I'm facing a strange issue, I don't know if it's StreamIO or
TMemoryStream. The following program, compiled with fpc
Free Pascal Compiler version 3.2.
El 7/10/19 a les 15:18, Michael Van Canneyt ha escrit:
On Mon, 7 Oct 2019, Luca Olivetti wrote:
I'm facing a strange issue, I don't know if it's StreamIO or
TMemoryStream. The following program, compiled with fpc
Free Pascal Compiler version 3.2.0-beta [2019/04/26] for i386
(I checked trun
Ryan Joseph schrieb am Mo., 7. Okt. 2019, 15:51:
> That bug aside the rule is that non-generic overloads always win over
> generics. I remember this was discussed at length if we can find the old
> thread.
>
Here:
https://lists.freepascal.org/pipermail/fpc-pascal/2018-December/055225.html
Lucki
On Mon, 7 Oct 2019 09:38:45 -0400
Ryan Joseph wrote:
>[...]
> > This means you don't support:
> > generic procedure Run(a: T; b:S); overload;
>
> That’s correct, this breaks the logic entirely. This to me looks like
> a sneaky way to trick the compiler and since it’s trying to infer
> somethin
On Mon, 7 Oct 2019 09:51:47 -0400
Ryan Joseph wrote:
> Right now this gives an error because you can’t add normal functions
> AFTER generic functions with the same name in the same scope. I can’t
> find the bug report but I think Sven fixed this recently or gave a
> better error at least.
I see
On Mon, 7 Oct 2019 15:37:46 +0200 (CEST)
Michael Van Canneyt wrote:
>[...]
> > You mean, if a bad overload can be nullified by a good one? That
> > would be insane...
> >
> > Yes, Delphi eats it without warning.
> >
> > And it works even with a generic param:
> >
> > generic function Run(a: T; b:
> On Oct 7, 2019, at 1:54 AM, Sven Barth via fpc-pascal
> wrote:
>
> There is nothing debatable here. If a generic parameter is not used in the
> parameter list (cause it's used in the result type (either directly or to
> specialize something else), only the body of the routine or even not a
Right now this gives an error because you can’t add normal functions AFTER
generic functions with the same name in the same scope. I can’t find the bug
report but I think Sven fixed this recently or gave a better error at least.
generic function DoThis(a: T): T; overload;
begin
end;
generic fu
> On Oct 7, 2019, at 5:39 AM, Mattias Gaertner via fpc-pascal
> wrote:
>
> I'm baffled. That's more basic algorithm than I expected. ;)
All contributions are welcome. It sounds like we need make some changes or
overhaul the entire thing.
>
> This means you don't support:
> generic procedur
On Mon, 7 Oct 2019, Mattias Gaertner via fpc-pascal wrote:
Should the compiler choose the 3rd non-generic function, or still
give an error ?
You mean, if a bad overload can be nullified by a good one? That would
be insane...
Yes, Delphi eats it without warning.
And it works even with a ge
On Mon, 7 Oct 2019, Luca Olivetti wrote:
I'm facing a strange issue, I don't know if it's StreamIO or
TMemoryStream. The following program, compiled with fpc
Free Pascal Compiler version 3.2.0-beta [2019/04/26] for i386
(I checked trunk and I don't see changes in streams or streamio)
I te
I'm facing a strange issue, I don't know if it's StreamIO or
TMemoryStream. The following program, compiled with fpc
Free Pascal Compiler version 3.2.0-beta [2019/04/26] for i386
(I checked trunk and I don't see changes in streams or streamio)
prints 3 lines but they are empty!
---
---
---
I
On Mon, 7 Oct 2019 14:37:16 +0200 (CEST)
Michael Van Canneyt wrote:
> On Mon, 7 Oct 2019, Mattias Gaertner via fpc-pascal wrote:
>
>[...]
> I think sven means if you have e.g. 3 functions:
>
> generic function DoThis(a: T): T; overload;
> begin end;
>
> generic function DoThis(a: T): U; overlo
On Mon, 7 Oct 2019, Mattias Gaertner via fpc-pascal wrote:
On Mon, 7 Oct 2019 14:12:32 +0200
Sven Barth via fpc-pascal wrote:
[...]
> > > > generic function DoThis(a: T): T; overload;
> > > > begin end;
> > > > generic function DoThis(a: T): U; overload;
> > > > begin end;
> > > >
> > > > b
On Mon, 7 Oct 2019 14:12:32 +0200
Sven Barth via fpc-pascal wrote:
>[...]
> > > > > generic function DoThis(a: T): T; overload;
> > > > > begin end;
> > > > > generic function DoThis(a: T): U; overload;
> > > > > begin end;
> > > > >
> > > > > begin
> > > > > DoThis(3); // both fits, should give
Mattias Gaertner schrieb am Mo., 7. Okt. 2019,
11:59:
> On Mon, 7 Oct 2019 07:54:51 +0200
> Sven Barth via fpc-pascal wrote:
>
> > Ryan Joseph schrieb am Mo., 7. Okt. 2019,
> > 00:16:
> >[...]
> > > >>> 3.
> > > >>> timpfuncspez2.pp
> > > >>> DoThis
> > > >>> DoThis
> > > >>> Delphi gives an er
On Mon, 7 Oct 2019 07:54:51 +0200
Sven Barth via fpc-pascal wrote:
> Ryan Joseph schrieb am Mo., 7. Okt. 2019,
> 00:16:
>[...]
> > >>> 3.
> > >>> timpfuncspez2.pp
> > >>> DoThis
> > >>> DoThis
> > >>> Delphi gives an error "Ambiguous call to DoThis". FPC silently
> > >>> selects the one with on
On Sun, 6 Oct 2019 18:16:16 -0400
Ryan Joseph wrote:
>[...]
> I think my logic is different from what you expect though and I’m
> happy to change it if we need to.
>
> There’s the comment I left in the code for the
> “try_implicit_specialization” function.
>
> { find generic procsyms by p
On Sun, 6 Oct 2019 18:16:16 -0400
Ryan Joseph wrote:
>[...]
> >>> 3.
> >>> timpfuncspez2.pp
> >>> DoThis
> >>> DoThis
> >>> Delphi gives an error "Ambiguous call to DoThis". FPC silently
> >>> selects the one with only one param. IMO this is dangerous, it
> >>> should give an error.
> >
> >
On Sun, 6 Oct 2019 18:16:16 -0400
Ryan Joseph wrote:
> > On Oct 6, 2019, at 5:40 PM, Mattias Gaertner via fpc-pascal
> > wrote:
> >> Which test? Please post a sample.
> >
> > generic procedure DoThis(a:T; b:T);
> > begin end;
> >
> > begin
> > DoThis(1,200); // 1 sets T to shortint, so the
On Sun, 6 Oct 2019 18:19:37 -0400
Ryan Joseph wrote:
>[...]
> That works then. Added a test:
> [...]
Thanks.
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
32 matches
Mail list logo
