Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

Am 27.06.2019 um 21:09 schrieb Martin: The below compiles, and writes 1 2 Are indexes to properties intentionally allowed to take "var param"? Btw it even compiles with an "out" param. program Project1; type   { TFoo }   TFoo = class   private     function GetFoo(var AIndex: Integer):

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

Am 28.06.2019 um 00:00 schrieb Ryan Joseph: On Jun 27, 2019, at 5:57 PM, Sven Barth via fpc-devel wrote: If it's a bug (what I do indeed think of this and the other bug you mentioned) it's considered acceptable to break backwards compatibility. After all we wouldn't be able to fix

[fpc-devel] Initial implementation of a "functional" array helper unit, as suggested by Sven Barth on the Lazarus forums.

The relevant forum post can be found here. Currently, this just implements "Map", "Filter" and "Reduce", but I thought I'd get some feedback / opinions on what the best area of the FPC codebase for the unit to

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

On 28/06/2019 00:09, Ben Grasset wrote: On Thu, Jun 27, 2019 at 4:12 PM Martin > wrote: Are indexes to properties intentionally allowed to take "var param"? Btw it even compiles with an "out" param. "Var" and "Out" seem bad, although I've always though that

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

In the meantime, I have some optimisations that I would be grateful could be evaluated - two of them are specific to the compiler, but one is much more general-purpose, relating to case blocks. https://bugs.freepascal.org/view.php?id=34859 https://bugs.freepascal.org/view.php?id=35346

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

On Thu, Jun 27, 2019 at 4:12 PM Martin wrote: > Are indexes to properties intentionally allowed to take "var param"? > Btw it even compiles with an "out" param. > "Var" and "Out" seem bad, although I've always though that "Constref" *should* be allowed.

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

> On Jun 27, 2019, at 5:57 PM, Sven Barth via fpc-devel > wrote: > > If it's a bug (what I do indeed think of this and the other bug you > mentioned) it's considered acceptable to break backwards compatibility. After > all we wouldn't be able to fix essentially anything as some code out

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

Ryan Joseph schrieb am Do., 27. Juni 2019, 23:50: > > > > On Jun 27, 2019, at 3:09 PM, Martin wrote: > > > > The below compiles, and writes > > 1 2 > > > > Are indexes to properties intentionally allowed to take "var param"? > > Btw it even compiles with an "out" param. > > That sounds like a

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

> On Jun 27, 2019, at 3:09 PM, Martin wrote: > > The below compiles, and writes > 1 2 > > Are indexes to properties intentionally allowed to take "var param"? > Btw it even compiles with an "out" param. That sounds like a bug or something that should be prevented. I just found out default

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

Am 27.06.2019 um 20:40 schrieb Ryan Joseph: As an side since you’re talking about optimizations what would it take to make the copy/addref record operators be inline? Unless I’m mistaken that’s one of the bigger issues that makes custom ref counted objects slower than built in compiler types.

[fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

The below compiles, and writes 1 2 Are indexes to properties intentionally allowed to take "var param"? Btw it even compiles with an "out" param. program Project1; type   { TFoo }   TFoo = class   private     function GetFoo(var AIndex: Integer): Integer;   public     property Foo[var

[fpc-devel] Patch for AVR DWARF information

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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

As an side since you’re talking about optimizations what would it take to make the copy/addref record operators be inline? Unless I’m mistaken that’s one of the bigger issues that makes custom ref counted objects slower than built in compiler types. Just curious... Regards, Ryan Joseph

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

On Thu, Jun 27, 2019 at 8:15 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > I think having record fields in registers would already go a long way. > Global variables aren't used /that/ often in modern, object oriented code > anyway. > Aren't they already?

Re: [fpc-devel] [] property overloads

On Thu, 27 Jun 2019, Ryan Joseph wrote: Another user just reported that default properties can ALREADY be overloaded (https://bugs.freepascal.org/view.php?id=35772). The syntax is kind of awkward (thus we weren’t able to infer it) but it seems to work. Does this mean we should ignore my

Re: [fpc-devel] [] property overloads

Another user just reported that default properties can ALREADY be overloaded (https://bugs.freepascal.org/view.php?id=35772). The syntax is kind of awkward (thus we weren’t able to infer it) but it seems to work. Does this mean we should ignore my patch or still go with it because of Delphi

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

J. Gareth Moreton schrieb am Do., 27. Juni 2019, 12:18: > One thing I have been considering is to promote fields and global > variables to local registers to reduce memory accesses. However, it would > make multi-threaded code a bit trickier to write and demand the use of the > "volatile"

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

One thing I have been considering is to promote fields and global variables to local registers to reduce memory accesses.  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. Before I

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

Hi Gareth, there are more optimizations to look at An user could write custom string enumerators to replace such assignments in loops and try to manually solve that issue. But then https://bugs.freepascal.org/view.php?id=34915 the enumerators are stored in memory rather than registers, so

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

I figured you were serious with it.  I've garned a reputation, it seems! I have some organisation to figure out first, since I've got to fix a bug , begin development of pure functions and update my patches for the x86-64 optimiser overhaul so it

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

On Thu, 27 Jun 2019, J. Gareth Moreton wrote: https://bugs.freepascal.org/view.php?id=35775 I'm both honoured and amused!  Thank you. Well, it was meant seriously. You mentioned more than once that you like optimizations. This one would be a real big improvement for a pattern that is often

Re: [fpc-devel] XML node dump feature

Perhaps "DETERMINISTIC" (used in Oracle) is more accurate than "PURE". https://docs.oracle.com/en/database/oracle/oracle-database/12.2/lnpls/DETERMINISTIC-clause.html#GUID-6AECC957-27CC-4334-9F43-0FBE88F92654 Petr Kohut -Original Message- From: fpc-devel On Behalf Of J. Gareth

[fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

https://bugs.freepascal.org/view.php?id=35775 I'm both honoured and amused!  Thank you. Gareth aka. Kit --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist -