Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?
Ryan Joseph schrieb am Fr., 28. Juni 2019, 20:12: > > > > On Jun 28, 2019, at 1:39 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > I just tested with Delphi and it works there as well. So contrary to > what we thought this does not seem to be a bug... > > I think it’s still buggy. Why does this compile? I guess it would make > sense if the property didn’t have any parameters and just mapped to any of > the overloaded functions but with the parameters it doesn’t make any sense. > I was talking about the var/out stuff. The overload one doesn't work in Delphi either. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?
> On Jun 28, 2019, at 1:39 AM, Sven Barth via fpc-devel > wrote: > > I just tested with Delphi and it works there as well. So contrary to what we > thought this does not seem to be a bug... I think it’s still buggy. Why does this compile? I guess it would make sense if the property didn’t have any parameters and just mapped to any of the overloaded functions but with the parameters it doesn’t make any sense. I submitted my patch for multiple default properties (https://bugs.freepascal.org/view.php?id=35772) which is a more sane solution than allowing this: program test; type tINIFile = object private function GetAsText( akey:integer):PAnsiChar; overload; function GetAsText(ans,asection,akey:PAnsiChar):PAnsiChar; overload; public property Value [ans:PAnsiChar; asection:PAnsiChar; akey:PAnsiChar]:PAnsiChar read GetAsText; default; end; function tINIFile.GetAsText( akey:integer):PAnsiChar; begin end; function tINIFile.GetAsText(ans,asection,akey:PAnsiChar):PAnsiChar; begin end; var o: tINIFile; s: PAnsiChar; begin s := o[1]; s := o['a','b','c']; end. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Initial implementation of a "functional" array helper unit, as suggested by Sven Barth on the Lazarus forums.
On 6/28/19 12:39 PM, Ben Grasset wrote: Yikes, I didn't realize the "preformatted" code from the Lazarus HTML exporter would show up with a bunch of asterisks outside of a real email client. FWIW: it did that because it *BOLD*ed those lines or at least attempted to... yeah, it is another reason to use plain-text for mailing list and newsgroup posts ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Initial implementation of a "functional" array helper unit, as suggested by Sven Barth on the Lazarus forums.
On Thu, Jun 27, 2019 at 9:09 PM Ben Grasset wrote:
> -snip-
>
> Yikes, I didn't realize the "preformatted" code from the Lazarus HTML
exporter would show up with a bunch of asterisks outside of a real email
client.
Here's normal text versions of both the unit, and the example program:
unit Functional;
{$mode Delphi}{$H+}
interface
type
TArrayHelper = record
public type
TMapModifier = function(constref Current: T): T;
TFilterTest = function(constref Current: T): boolean;
TReduceModifier = procedure(var Accumulator: T; constref Current: T);
ArrayType = array of T;
THelperImpl = record helper for ArrayType
function Map(const Modifier: TMapModifier): ArrayType; overload;
function Filter(const Test: TFilterTest): ArrayType; overload;
function Reduce(const Modifier: TReduceModifier): T; overload;
class function Map(constref Values: array of T; const Modifier:
TMapModifier): ArrayType; static; overload;
class function Filter(constref Values: array of T; const Test:
TFilterTest): ArrayType; static; overload;
class function Reduce(constref Values: array of T; const Modifier:
TReduceModifier): T; static; overload;
end;
end;
(* These are defined without the usual T prefix to avoid any conflict
with possible existing type aliases. *)
UInt8Array = TArrayHelper.ArrayType;
ShortIntArray = TArrayHelper.ArrayType;
SmallIntArray = TArrayHelper.ArrayType;
UInt16Array = TArrayHelper.ArrayType;
UInt32Array = TArrayHelper.ArrayType;
Int32Array = TArrayHelper.ArrayType;
Int64Array = TArrayHelper.ArrayType;
UInt64Array = TArrayHelper.ArrayType;
Float32Array = TArrayHelper.ArrayType;
Float64Array = TArrayHelper.ArrayType;
ShortStringArray = TArrayHelper.ArrayType;
AnsiStringArray = TArrayHelper.ArrayType;
UnicodeStringArray = TArrayHelper.ArrayType;
implementation
function TArrayHelper.THelperImpl.Map(const Modifier: TMapModifier):
ArrayType;
var I: PtrUInt;
begin
SetLength(Result, Length(Self));
for I := 0 to High(Self) do
Result[I] := Modifier(Self[I]);
end;
function TArrayHelper.THelperImpl.Filter(const Test: TFilterTest):
ArrayType;
var I, J: PtrUInt;
begin
J := 0;
SetLength(Result, Length(Self));
for I := 0 to High(Self) do
if Test(Self[I]) then begin
Result[J] := Self[I];
Inc(J);
end;
SetLength(Result, J);
end;
function TArrayHelper.THelperImpl.Reduce(const Modifier:
TReduceModifier): T;
var I: PtrUInt;
begin
Result := Self[0];
for I := 1 to High(Self) do
Modifier(Result, Self[I]);
end;
class function TArrayHelper.THelperImpl.Map(constref Values: array of T;
const Modifier: TMapModifier): ArrayType;
var I: PtrUInt;
begin
SetLength(Result, Length(Values));
for I := 0 to High(Values) do
Result[I] := Modifier(Values[I]);
end;
class function TArrayHelper.THelperImpl.Filter(constref Values: array of
T; const Test: TFilterTest): ArrayType;
var I, J: PtrUInt;
begin
J := 0;
SetLength(Result, Length(Values));
for I := 0 to High(Values) do
if Test(Values[I]) then begin
Result[J] := Values[I];
Inc(J);
end;
SetLength(Result, J);
end;
class function TArrayHelper.THelperImpl.Reduce(constref Values: array of
T; const Modifier: TReduceModifier): T;
var I: PtrUInt;
begin
Result := Values[0];
for I := 1 to High(Values) do
Modifier(Result, Values[I]);
end;
end.
///
program TestFunctional;
{$mode ObjFPC}{$H+}
uses Functional;
function NumMap(constref Current: LongInt): LongInt;
begin
Result := Current + Current;
end;
function NumFilter(constref Current: LongInt): Boolean;
begin
Result := Current > 5;
end;
procedure NumReduce(var Accumulator: LongInt; constref Current: LongInt);
begin
Accumulator += Current;
end;
function StringMap(constref Current: AnsiString): AnsiString;
begin
Result := Current + Current;
end;
function StringFilter(constref Current: AnsiString): boolean;
begin
Result := Current > 'e';
end;
procedure StringReduce(var Accumulator: AnsiString; constref Current:
AnsiString);
begin
Accumulator += Current;
end;
var
I: LongInt;
S: AnsiString;
begin
WriteLn('Instanced Integer Map!');
for I in Int32Array.Create(1, 2, 3, 4, 5, 6, 7, 8, 9, 10).Map(@NumMap) do
WriteLn(I);
WriteLn('Instanced Integer Filter!');
for I in Int32Array.Create(1, 2, 3, 4, 5, 6, 7, 8, 9,
10).Filter(@NumFilter) do WriteLn(I);
WriteLn('Instanced Integer Reduce!');
WriteLn(Int32Array.Create(1, 2, 3, 4, 5, 6, 7, 8, 9,
10).Reduce(@NumReduce));
WriteLn('Static Integer Map!');
for I in Int32Array.Map([1, 2, 3, 4, 5, 6, 7, 8, 9, 10], @NumMap) do
WriteLn(I);
WriteLn('Static Integer Filter!');
for I in Int32Array.Filter([1, 2, 3, 4, 5, 6, 7, 8, 9, 10], @NumFilter)
do WriteLn(I);
WriteLn('Static Integer Reduce!');
WriteLn(Int32Array.Reduce([1, 2, 3, 4, 5, 6, 7, 8, 9, 10], @NumReduce));
WriteLn('Instanced String Map!');
for S in AnsiStringArray.Create('a', 'b', 'c', 'd', 'e', 'f', 'g', 'h',
Re: [fpc-devel] viewvc breoken
Yes temporarily, on purpose. We were experiencing a DDOS attack using it. Michael. On Fri, 28 Jun 2019, John Lee wrote: URL for viewvc broken... svn.freepascal.org/cgi-bin/viewvc.cgi/?sortby=date#dirlist ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] viewvc breoken
URL for viewvc broken... svn.freepascal.org/cgi-bin/viewvc.cgi/?sortby=date#dirlist > > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?
On 28/06/2019 07:39, Sven Barth via fpc-devel wrote:
Am 27.06.2019 um 21:09 schrieb Martin:
{ TFoo }
TFoo = class
private
function GetFoo(var AIndex: Integer): Integer;
public
property Foo[var AIndex: Integer]: Integer read GetFoo;
end;
I just tested with Delphi and it works there as well. So contrary to
what we thought this does not seem to be a bug...
What does Delphi do with
property Foo[AIndex: Integer; BIndex: Integer = 0]: Integer read
GetFoo;
Because FPC rejects this one. (And IMHO rightfully so)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "
George Bakhtadze schrieb am Fr., 28. Juni 2019, 08:26: > Hello, > > > One thing I have been considering is to promote fields and global > variables to local registers to reduce memory accesses. > > That would be great. But multithreaded code which assume (incorrectly) > that those fields and globals are in memory may be broken. > This assumption is *not* incorrect. Only on the LLVM based Delphi NewGen and FPC's LLVM backend the assumption is incorrect which can be seen by them having added "volatile" mechanisms. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch for AVR DWARF information
I can second that wish, It would be really great to have this patch in trunk, I use it successfully for a while now and debugging on avr is working as expected and increases productivity a lot. Michael Am 27.06.19 um 21:13 schrieb christo: Today is the anniversary of bug report 0033914. It took me a couple of tries, but I think I eventually arrived at a decent patch for this issue some time ago. Can I interest any of the core developers to evaluate this patch? Best regards, Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "
Hello, > One thing I have been considering is to promote fields and global variables to local registers to reduce memory accesses. That would be great. But multithreaded code which assume (incorrectly) that those fields and globals are in memory may be broken.Other languages don't allow to assume anything about such entities in multithreaded code.From the other side, such languages do have a memory model which tells when a assignment result will become visible to other threads (if ever). > However, it would make multi-threaded code a bit trickier to write and demand the use of the "volatile" intrinsic on things like the conditions of while loops. Volatile (I assume you mean a C-like volatile) is usable in very rare special cases. Such as work with hardware buffers. In optimization sphere FPC can be improved in many ways. For example, expressions like: x + y * Ord(x > y)FPC 3.0.4 does use IMUL instruction. But it can be compiled much more effective with cmov:cmp edi, esimov eax, 0cmovle esi, eaxadd edi, esihttps://godbolt.org/z/Cf-AQE Don't know how hard is to implement such oiptimization though. ---Best regards, George___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
