Re: [fpc-devel] Attn. Generics.Collections and rev. 39345 and speed slowdown

Maciej Izak schrieb am Sa., 30. Juni 2018, 08:16: > Hi, > > renaming for TMormotHashFactory to TGenericsHashFactory is somehow > acceptable (but IMO bad taste) but change for default hashing algorithm in > such important library is really really really bad idea. > No, the bad taste is too have

Re: [fpc-devel] Generics.Collections June update

Maciej Izak schrieb am Sa., 30. Juni 2018, 08:15: > 2018-06-28 22:13 GMT+02:00 Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org>: > >> - why is it that you adjusted DaThoX' copyright range, but not yours at >> the top? >> > > on the top is date

Re: [fpc-devel] Managed Types, Undefined Bhaviour

Willibald Krenn schrieb am Sa., 30. Juni 2018, 08:01: > TBH, I didn't know this issue existed in Delphi and I've done my share of > Delphi over time. I still maintain that for managed types the compiler is > responsible for some minimal initialization (like it's done for records > etc, no?). >

Re: [fpc-devel] Generics.Collections June update

Am 28.06.2018 um 08:52 schrieb Maciej Izak: * some new proper credits in few places Two questions regarding this: - who is DaThoX and in how far are they related to you and your work? (just out of curiosity) - why is it that you adjusted DaThoX' copyright range, but not yours at the top?

Re: [fpc-devel] Attn Sven: New flags related to management operators

Am 27.06.2018 um 13:02 schrieb Maciej Izak: 2018-06-22 21:08 GMT+02:00 Maciej Izak >: I see 4 options: 1. integration of FastRTTI 2. limited integration, only part of "FastRTTI" branch (only table with initialization operators and related compiler and

Re: [fpc-devel] FPC Macros: Could it be used for unit aliases?

Marcos Douglas B. Santos schrieb am Mi., 27. Juni 2018, 14:37: > Sven and all, > Is there any change to implement this? > Not from me. I don't care about that. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Maximum symbol length -- answer needed

Am 23.06.2018 um 10:48 schrieb Jonas Maebe: I would propose to switch all targets to use use ansistrings for symbol names. Is this the consensus? Personally, if I had any stake in this, I would be against it. I mean, FPC is already slower than DCC. I doubt this is a major contributor to

Re: [fpc-devel] Attn Sven: New flags related to management operators

Am 20.06.2018 um 23:41 schrieb Maciej Izak: Hi Sven, I saw the new commits related to Management Operators (I mean new flags riifNonTrivialChild and riifParentHasNonTrivialChild) and I wonder what next. When I was developing management operators (and FastRTTI related to speed up things) I

Re: [fpc-devel] TThread.Queue and TThread.Destroy

Am 21.06.2018 um 10:26 schrieb Martin: On 21/06/2018 01:27, Martin wrote: fpc 3.0.4 / Linux 64bit (Fedora) What should happen if: - A Thread has queued a call with "TThread.Queue" - The Thread gets Terminated and Destroyed before the queued method can be executed.   That is the thread checks

Re: [fpc-devel] FPC fails on overload

Am 19.06.2018 um 02:47 schrieb J. Gareth Moreton: Technically it's a regression because it worked fine before and it breaks now.  However, I do agree... how should a string literal be interpreted? Technically either a WideString or UnicodeString is correct, so the compiler cannot decide

Re: [fpc-devel] RandomFrom vs Generics

Gabor Boros schrieb am Mi., 6. Juni 2018, 10:15: > 2018. 06. 06. 9:05 keltezéssel, Sven Barth via fpc-devel írta: > > Seems like a bug due to there being multiple overloads plus the generic. > > Would you please report that to the bug tracker? > > > Done: > > https:

Re: [fpc-devel] RandomFrom vs Generics

Gabor Boros schrieb am Mi., 6. Juni 2018, 08:09: > Hi All, > > This > > var >x:Integer; >a:array of Integer; > > begin >x:=RandomFrom(a); > > code works with 3.0.4 but cannot compile with trunk and got "Error: > Generics without specialization cannot be used as a type for a >

Re: [fpc-devel] procedure ShowException

Am 01.06.2018 um 21:14 schrieb Ondrej Pokorny: Hello, is there any reason the OnShowException event is ignored for console applications? The OnShowException event is a feature of FPC (Delphi doesn't have it), so whoever added it probably thought that it makes more sense this way 路‍♀️

Re: [fpc-devel] x86_64-win64 compilation failure

J. Gareth Moreton schrieb am Fr., 1. Juni 2018, 21:02: > It seems to have been fixed now after I did a manual deletion of all .o > and .ppu files. Not sure what that was all about. Sorry to waste anyone's > time - emergency over. Just to be sure: you are doing a "make clean all" at the top

Re: [fpc-devel] x86-64 compilation of while loops

J. Gareth Moreton schrieb am Mo., 28. Mai 2018, 02:55: > In this case, the ".balign" hint adds 2 bytes to pad the loop. However, > my question is this... why does it immediately jump to the end of the loop > to check the condition (which is very likely to be true on

Re: [fpc-devel] Found compiler bug while working on Deep Optimiser

Am 27.05.2018 um 02:48 schrieb J. Gareth Moreton: Hi guys, So I'm still experimenting and researching with the deep optimiser, and I'm starting to have some successes... until I found a compiler bug! https://bugs.freepascal.org/view.php?id=33794 What I'm trying to do, and something which

Re: [fpc-devel] FPC trunk compiler slower than 3.0.4

Marco van de Voort schrieb am Mo., 21. Mai 2018, 21:05: > In our previous episode, Florian Kl?mpfl said: > > > 1:40 with FPC trunk > > > > > > Do you observe the same? Any hints why? > > > > New features? E.g. helpers made fpc a lot slower (or are they already in > 3.0.x?)

Re: [fpc-devel] Debugging Loop Unroll Optimization

Martok schrieb am Fr., 18. Mai 2018, 15:40: > > Citation: "If the loop was terminated prematurely with an exception or a > > break statement, the loop variable retains the value it had when the > > loop was exited." > As a quick fix, not unrolling loops left with exit

Re: [fpc-devel] NewPascal plans, Generics.Collections and FPC trunk

Maciej Izak <hnb.c...@gmail.com> schrieb am Mi., 2. Mai 2018, 19:59: > 2018-05-02 18:41 GMT+02:00 Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org>: > >> Please note that the pnameless.pas file by Blaise does not yet have a GPL >> compatible license h

Re: [fpc-devel] Broken frac functionin FPC3.1.1 / Windows x86_64

J. Gareth Moreton schrieb am Do., 3. Mai 2018, 04:55: > Tests complete! It turns out that I was using SetExceptionMask wrong and > subtracting rather than adding exInvalidOp. > > When exceptions are disabled, this new Frac function returns NaN when you > pass in plus

Re: [fpc-devel] NewPascal plans, Generics.Collections and FPC trunk

Maciej Izak schrieb am Mi., 2. Mai 2018, 18:21: > I will continue my all work as much as possible with NewPascal (which will > be synced with FPC trunk few times in the year - or more often if needed), > I mean here all stuff, including updates for Generics.Collections

Re: [fpc-devel] Broken frac functionin FPC3.1.1 / Windows x86_64

J. Gareth Moreton schrieb am Mi., 2. Mai 2018, 11:10: > > > > > On Wed 02/05/18 06:55 , Sven Barth pascaldra...@googlemail.com sent: > > ... > Thank you for the work so far. Does it also work correctly when exceptions > are disabled? > > Regards, > Sven > > > I confess

Re: [fpc-devel] Broken frac functionin FPC3.1.1 / Windows x86_64

J. Gareth Moreton schrieb am Di., 1. Mai 2018, 23:39: > It turns out I did over-engineer the solution somewhat - this version is > far more efficient, honours NaNs and triggers SIGFPE if infinity is passed > in (subsd triggers it), hence there are no regressions. > >

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

Anthony Walter schrieb am So., 29. Apr. 2018, 21:27: > I've run into an almost must have use case for FPC smart pointers as > described and implemented by Maciej. I wanted to know from the people who > make decision about what to merge, what's the status of rolling his >

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

Am 28.04.2018 um 11:28 schrieb Thorsten Engler: Basically that. For doubles that don't fit into an Int64, any fraction is beyond the significant number of digits that the double can store anyway, so 0 is the valid and correct result for Frac in that case. Since a float only stores the

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

Am 28.04.2018 um 10:11 schrieb Thorsten Engler: Oops, small mistake caused by last minute change (I replaced rol with shl): it needs to be shr (or ror or rol, they all perform about the same on my cpu). And in case anyone wonders, the first cmp and branch returns 0 for numbers that would

Re: [fpc-devel] Case of string

Am 27.04.2018 um 22:48 schrieb Bart: On Fri, Apr 27, 2018 at 5:49 PM, Sven Barth via fpc-devel <fpc-devel@lists.freepascal.org> wrote: It's a bug due to refactoring. I'll commit the fix once I got to run the testsuite. So, I need not file a bugreport then? Nope, fixed in

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

Thorsten Engler schrieb am Fr., 27. Apr. 2018, 18:48: > For what it’s worth, Delphi simply decided to give up on doing it > correctly and silently fail if the double is too large to fit in an Int64. > > > > WriteLn(Frac(1e15+0.5)); > > WriteLn(Frac(1e16+0.5)); > > > >

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

Thorsten Engler schrieb am Fr., 27. Apr. 2018, 17:47: > > That's true for i386. But on x86_64 cvt(t)sd2si instuctions can > > deal with int64 range, if destination register is a 64-bit one. > > You are still going to be at least 960-bit short... > I've disabled the SSE

Re: [fpc-devel] Case of string

Bart schrieb am Do., 26. Apr. 2018, 19:29: > Is this a bug, or was it changed by design? > It's a bug due to refactoring. I'll commit the fix once I got to run the testsuite. Regards, Sven > ___ fpc-devel maillist -

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

Thorsten Engler schrieb am Fr., 27. Apr. 2018, 16:09: > Highest integer that fits in a Int64: > > 9223372036854775808 > > 1e20: > > 1 > > > > Your Int is overflowing. > > > > You can’t implement Frac by going through an Integer, that will never >

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

Bart schrieb am Fr., 27. Apr. 2018, 13:42: > On Wed, Apr 25, 2018 at 11:04 AM, wrote: > > > If you compile and run this 64-bit program on Win 64 you get a crash > > And AFAICS your analysis of the cause (see bugtracker) is correct as well. > >

Re: [fpc-devel] Dangerous optimization in CASE..OF

Alexander Grotewohl schrieb am Sa., 21. Apr. 2018, 16:40: > To be honest I agree with what he's saying. We're bending enums to do > things normal people just wouldn't (and shouldn't) do. > > And seriously, "Delphi, Delphi, Delphi!" .. why don't we strive for > something a

Re: [fpc-devel] Dangerous optimization in CASE..OF

Thorsten Engler schrieb am Sa., 21. Apr. 2018, 14:12: > > -Original Message- > > From: fpc-devel On Behalf Of > > Martok > > Sent: Saturday, 21 April 2018 21:39 > > To: fpc-devel@lists.freepascal.org > > Subject: Re:

Re: [fpc-devel] Creating Generic Object

Bart <bartjun...@gmail.com> schrieb am Mo., 16. Apr. 2018, 12:18: > On Mon, Apr 16, 2018 at 7:53 AM, Sven Barth via fpc-devel > <fpc-devel@lists.freepascal.org> wrote: > > >> This is very nice feature since I do not need define every Map/List/etc > >>

Re: [fpc-devel] Creating Generic Object

Amir schrieb am So., 15. Apr. 2018, 23:51: > Hi all, > >Currently, FPC allows declaring objects as > var >MyMap: specialize TFPGMap; > > This is very nice feature since I do not need define every Map/List/etc > as a separate type. > > But to create

Re: [fpc-devel] What's the status on the "record default field" functionality?

Ben Grasset schrieb am So., 15. Apr. 2018, 09:05: > AFAIK it's been working for over a year in a separate branch. The smart > pointer example demos worked perfectly as far as I could tell. Is there a > particular reason it hasn't been added to the main codebase the way >

Re: [fpc-devel] Dangerous optimization in CASE..OF

Ondrej Pokorny <laza...@kluug.net> schrieb am Fr., 13. Apr. 2018, 21:16: > On 13.04.2018 14:08, Sven Barth via fpc-devel wrote: > > Ondrej Pokorny <laza...@kluug.net> schrieb am Fr., 13. Apr. 2018, 12:52: > >> I introduced the AS operator for enumerations in

Re: [fpc-devel] Wrong docs: not initialized global variables

Martok schrieb am Do., 5. Apr. 2018, 16:29: > > From this rule, it follows that every variable must be explicitly > initialized [...] > > Be it with an assignment or an 'var a: type = someonstant;'. > ... for which the syntactic sugar was rejected not two weeks ago. >

Re: [fpc-devel] Some RTL bug fixes and suggestions

NetSpirit schrieb am Mo., 26. März 2018, 16:10: > packages\pasjpeg > > Error usage after compile in -Mdelphiunicode mode. > In file 'packages\pasjpeg\src\jpeglib.pas' member > jpeg_error_mgr.format_message still uses AnsiString which is wrong. > Because at the end of file

Re: [fpc-devel] Wrong docs: not initialized global variables

Ondrej Pokorny schrieb am Sa., 24. März 2018, 20:49: > This is not correct. Global simple variables are always initialized. At > least in Delphi it is so: > http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Variables_(Delphi) "If > you do not explicitly initialize a global

Re: [fpc-devel] Multiple variable initialization

Anthony Walter schrieb am Sa., 24. März 2018, 14:51: > If you were going to patch I'd also consider allowing: > > program Test; > var > B, C: Integer = 0, 1; // sets B = 0, and C = 1 > begin > end. > No, that is only confusing. Regards, Sven

Re: [fpc-devel] Fix CamelCase in unit and method names

R0b0t1 schrieb am Fr., 23. März 2018, 16:07: > > > > IMHO preferably not the unit names (as in 'unit XxX') - with case > > sensitive file names on Unix, this change might increase time for > > searching the respective file (somewhat). Obviously, all further > > references of

Re: [fpc-devel] Fix CamelCase in unit and method names

Mark Morgan Lloyd schrieb am Do., 22. März 2018, 17:57: > On 22/03/18 15:30, Juha Manninen wrote: > > On Thu, Mar 22, 2018 at 3:15 PM, Denis Kozlov > wrote:> Please do... It has caused enough eye (OCD) stress over the years ;) > > +1Yes, it

Re: [fpc-devel] MACRO - correct syntax?

Am 25.02.2018 12:14 schrieb "Mark Morgan Lloyd" < markmll.fpc-de...@telemetry.co.uk>: On 25/02/18 10:30, Florian Klämpfl wrote: > Am 25.02.2018 um 11:12 schrieb Mark Morgan Lloyd:> On 25/02/18 02:15, Ozz > Nixon wrote:>> {$MACRO ON}>> {$DEFINE _CTASSERT(X,Y,Z):=assert(x=y,z);}>> > Begin

Re: [fpc-devel] MACRO - correct syntax?

Am 25.02.2018 03:01 schrieb "Ozz Nixon" : {$MACRO ON} {$DEFINE _CTASSERT(X,Y,Z):=assert(x=y,z);} Begin _CTASSERT(1,1,'Constant failed.'); end. Macros with arguments are not supported. Regards, Sven ___ fpc-devel maillist -

Re: [fpc-devel] Suspicion about TThread.Synchronize

On 05.02.2018 03:03, Martin wrote: > Ok, I got it again in the debugger. > > Since it is nor reproducible all the times, I am using auto continue > breakpoints, and just record that they were hit. So I have limited data. > > - After a long series of syncs ThreadQueueTail is nil. > - A thread

Re: [fpc-devel] Suspicion about TThread.Synchronize

On 04.02.2018 20:37, Martin wrote: > On 04/02/2018 19:17, Sven Barth via fpc-devel wrote: >> On 03.02.2018 17:39, Martin wrote: >>> All based on win32 >>> >>> Pretext: >>> I have an issue with a crash in PopThreadQueueHead called by >>> CheckS

Re: [fpc-devel] Suspicion about TThread.Synchronize

On 03.02.2018 17:39, Martin wrote: > All based on win32 > > Pretext: > I have an issue with a crash in PopThreadQueueHead called by > CheckSynchronize.  (3.0.2) > It happens in the Lazarus IDE, but at a low percentage only. (And not > yet in the debugger) > I don't think the below is related, but

Re: [fpc-devel] End of support for Win XP?

Am 01.02.2018 14:31 schrieb "Michael Van Canneyt" : On Thu, 1 Feb 2018, Denis Kozlov wrote: A proposal: > 1) Use windirs.GetWindowsSpecialDir in fpttf.pp, which already uses a more > backwards compatible SHGetFolderPath(). > 2) Optionally, improve

Re: [fpc-devel] End of support for Win XP?

Am 01.02.2018 14:08 schrieb "Denis Kozlov" : A proposal: 1) Use windirs.GetWindowsSpecialDir in fpttf.pp, which already uses a more backwards compatible SHGetFolderPath(). 2) Optionally, improve windirs.GetWindowsSpecialDir to use a newer SHGetKnownFolderPath() when it is

Re: [fpc-devel] Internal error 2018011401

Am 15.01.2018 10:14 schrieb "Mattias Gaertner" : Hi, Using fpc trunk. What means error Error: Internal error 2018011401 ? Seems like the addition of that code wasn't as thought out by me as I hoped it was... You can remove the internal error and the check that leads

Re: [fpc-devel] Internal error with division by QWord (Issue #33004)

Am 11.01.2018 21:46 schrieb "J. Gareth Moreton" : Possibly related, but the compiler automatically treats numbers larger than or equal to $8000 as signed (Int64) regardless of the context or what it's being assigned to (this usually involves compiler

Re: [fpc-devel] What's the best way to debug the fpc compiler?

Am 28.12.2017 11:30 schrieb "Giuliano Colla" : Hi fpc developers, I'm playing a bit with the compiler. In order to debug my changes I need to compile some test programs. To stay on the safe side, currently when I modify something I rebuild everything (make all -

Re: [fpc-devel] An extension of fpc language: the BASED construct

Am 27.12.2017 00:54 schrieb "Giuliano Colla" <giuliano.co...@fastwebnet.it>: Il 26/12/2017 18:26, Sven Barth via fpc-devel ha scritto: Am 26.12.2017 13:33 schrieb "Giuliano Colla" <giuliano.co...@fastwebnet.it>: If the idea is not rejected, then a number

Re: [fpc-devel] An extension of fpc language: the BASED construct

Am 26.12.2017 13:33 schrieb "Giuliano Colla" : If the idea is not rejected, then a number of refinements (which I'm ready to implement) are required to make the feature generally available: My following remarks are independent of an eventual acceptance of the

Re: [fpc-devel] *** GMX Spamverdacht *** An extension of fpc language: the BASED construct

Am 26.12.2017 14:44 schrieb "Thorsten Engler" : > Item: BYTE BASED ItemPtr; Ignoring any other considerations for now, I would have at least used a logical extension derived from already supported syntax: Item: Byte absolute ItemPtr^; I agree, as it avoids adding a

Re: [fpc-devel] Vectorization

Am 23.12.2017 11:01 schrieb "Adriaan van Os" : J. Gareth Moreton wrote: > Hey Adriaan, > > I dare ask - did the patch help out your issue at all? I did supply it to > Florian as well, although he has his own work in progress for > vectorization, so whether my code is

Re: [fpc-devel] First pas2js public release

Am 18.12.2017 14:56 schrieb "Benito van der Zander" : Isn't speed the main idea of using pointers? It would be to port all existing pascal code But that isn't the goal of pas2js. That is what WebAsm is for. You may want to take a look at asm.js, which has a working model

Re: [fpc-devel] String constant without code page

Am 14.12.2017 09:37 schrieb "Petr Kristan" : Hi. I compile whole project with -FcUTF8, but sometimes should be useful to define string constant with CP_NONE to prevent conversions. Example: DefaultSystemCodePage:=1250 variable s contains text with cp=1250 s := s + '#';

Re: [fpc-devel] Vectorization

Am 10.12.2017 20:01 schrieb "J. Gareth Moreton" : The idea I had currently (this is without looking at any previous theory) was to use a kind of sliding window, similar to how ZIP and other LZ77-based algorithms work when compressing repeating strings, to look backwards

Re: [fpc-devel] Quickly recompiling fpc

Am 09.12.2017 14:57 schrieb "Benito van der Zander" : Hi, how do you recompile fpc after making a small change in the compiler, like enabling the debugmsg define in x86/aoptx86.pas? make buildbase says nothing was changed, and make clean; make buildbase recompiles not just

Re: [fpc-devel] FillWord, FillDWord and FillQWord are very poorly optimised on Win64 (not sure about x86-64 on Linux)

Am 01.11.2017 05:58 schrieb "J. Gareth Moreton" : Would it be worth opening up a bug report for this, with the attached assembler routines as suggestions? I haven't worked out how to implement internal functions into the compiler yet, and I rather clear it with you guys

Re: [fpc-devel] Multiple type sections - Far forward type declarations [feasible feature request?]

Am 31.10.2017 10:47 schrieb "Michael Van Canneyt" : On Tue, 31 Oct 2017, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: > >> >> With your extended "forward type resolution" this would no longer be >> possible. >> Theoretically it probably

Re: [fpc-devel] x86_64.inc CompareByte

Am 16.10.2017 23:04 schrieb "Markus Beth" : > > On 16.10.2017 22:41, Florian Klämpfl wrote: >> BTW: I would really like to see a PCMPSTR based implementation :) > > PCMPSTR is (at the moment) out of my scope. I thought PCMPSTR is part of SSE4.2. How would you deal with Intel

Re: [fpc-devel] Can't compile FPC trunk x86_64-win64

Am 30.09.2017 07:37 schrieb "Ondrej Pokorny" <laza...@kluug.net>: > > On 30.09.2017 0:10, Sven Barth via fpc-devel wrote: >> >> Are you sure that you're compiling with the correct compiler? Cause that sounds quite like you're trying to compile the Win64 RTL with a

Re: [fpc-devel] Can't compile FPC trunk x86_64-win64

Am 29.09.2017 22:14 schrieb "Ondrej Pokorny" : > > Hello, > > I can't compile latest trunk for x86_64-win64: the first error message is: > > system.pp(136,18) Error: invalid register name > > i386-win32 compiles fine. Are you sure that you're compiling with the correct

Re: [fpc-devel] trunk broken

On 02.09.2017 20:01, Benito van der Zander wrote: > Hi, > > trunk is always broken, is it not? Huh? It's rather seldom that we have real build breakages and even then more often than not only on certain systems. Regards, Sven ___ fpc-devel maillist

Re: [fpc-devel] trunk broken

Am 02.09.2017 17:06 schrieb "Karoly Balogh (Charlie/SGR)" < char...@scenergy.dfmk.hu>: > > Hi, > > On Sat, 2 Sep 2017, Marco van de Voort wrote: > > > The expansion of texpropcode in r37108 (Mattias) breaks fppasjs because it > > defines an array with texpropcode as range. > > > > This prohibits

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 01.09.2017 14:50 schrieb "Stefan Glienke" : > > > For generics the only way to support them is that you must explicitly specialize a generic helper type. The compiler won't do any type inference for you. > > IMO this makes them rather useless. Is that a technical limitation

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 01.09.2017 14:41 schrieb "Maciej Izak" : > > 2017-09-01 14:30 GMT+02:00 Michael Van Canneyt : >>> >>> >>> No, directives won't be abused for something like that. >> >> >> I am glad I am not the only one who thins so :) > > > I like experiments as you

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 01.09.2017 12:15 schrieb "Maciej Izak" : > > 2017-09-01 11:41 GMT+02:00 Stefan Glienke : >> >> Again you will cause unnecessary headaches because now your helper has the dependency of the builtin and the third party one. >> How would third party one and

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 01.09.2017 11:51 schrieb "Stefan Glienke" : > > What I am lobbying for in Delphi are interface helpers and helpers for generic types in general. > > I just saw that FPC currently has the same limitation. That also on your list? > Interface helpers are implemented in trunk

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 01.09.2017 08:47 schrieb "Stefan Glienke" : > Therefor I argue that the "only the last one in scope is applied" restriction should be removed. > If there are any clashes because two helpers introduce a any ambiguity well then it is the compilers job to warn or error about

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 31.08.2017 17:48 schrieb "Ondrej Pokorny" <laza...@kluug.net>: > > On 31.08.2017 17:22, Sven Barth via fpc-devel wrote: >> >> > I remember a compiler bug in class destructor order call in Delphi: https://stackoverflow.com/questions/19332847/delphi-class-var

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 31.08.2017 15:55 schrieb "Ondrej Pokorny" <laza...@kluug.net>: > > On 31.08.2017 14:55, Sven Barth via fpc-devel wrote: >> >> >> > Yeah, they might enable record helper inheritance for example :P (Record helper inheritance was documented to work fo

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 31.08.2017 12:07 schrieb "Ondrej Pokorny" : > > On 29.08.2017 22:30, Maciej Izak wrote: >> >> >>> >>> Btw. record helpers support inheritance in all modes but Delphi. It doesn't make sense to disallow it for record helpers but allow it for type helpers... Too overcomplicated

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 29.08.2017 17:39 schrieb "Ondrej Pokorny" : > So yes, your description of {$modeswitch typehelpers} makes sense for 3.0.0 but not for trunk any more. So what is your intention - 3.0.0 behavior or trunk behavior? Maybe it would indeed make more sense to adjust the meaning of

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 29.08.2017 12:44 schrieb "Ondrej Pokorny" <laza...@kluug.net>: > > On 29.08.2017 11:48, Sven Barth via fpc-devel wrote: >> >> The idea is okay as well, but I'd name it RecordHelperInheritance, cause if we'd allow "type helper" in mode Delphi (as Macie

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 29.08.2017 10:37 schrieb "Ondrej Pokorny" <laza...@kluug.net>: > > On 29.08.2017 8:47, Michael Van Canneyt wrote: >> >> On Tue, 29 Aug 2017, Sven Barth via fpc-devel wrote: >> >>> Suggested name is "NonDelphiExtensions". >>

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 29.08.2017 08:47 schrieb "Michael Van Canneyt" <mich...@freepascal.org>: > > > > On Tue, 29 Aug 2017, Sven Barth via fpc-devel wrote: > >> Am 28.08.2017 23:11 schrieb "Ondrej Pokorny" <laza...@kluug.net>: >>> >>> >&g

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 28.08.2017 23:11 schrieb "Ondrej Pokorny" : > > Hello! > > I find it unnecessary to disable record helper inheritance in Delphi mode. Due to this artificial limitation I have to change unit mode from Delphi to ObjFPC. > > Reasons: > 1.) It's a limitation of a feature that

Re: [fpc-devel] Optimizing unused return values of inline functions

Am 22.08.2017 13:15 schrieb "Michael Van Canneyt" : > > > > On Tue, 22 Aug 2017, Thaddy de Koning wrote: > >>> On 21.08.2017 13:22, Michael Van Canneyt wrote: On Mon, 21 Aug 2017, Benito van der Zander wrote: > Hi, > >> This pattern is

Re: [fpc-devel] Optimizing unused return values of inline functions

On 21.08.2017 21:15, Marco van de Voort wrote: > In our previous episode, Sven Barth via fpc-devel said: >>> I am asking, why do you think *this pattern* (of always returning self) >>> should be inherently more efficient ? >> >> The pattern definitely has its us

Re: [fpc-devel] Optimizing unused return values of inline functions

On 21.08.2017 13:22, Michael Van Canneyt wrote: > > > On Mon, 21 Aug 2017, Benito van der Zander wrote: > >> Hi, >> >>> This pattern is not inherently efficient. Why should it be ? >> >> >> It is not efficient, because of the pointless instruction! > > I am not speaking of the current FPC

Re: [fpc-devel] Multiple inheritance

Am 19.08.2017 09:12 schrieb "Ondrej Pokorny" : > > Hello! > > Has anybody thought about multiple inheritance in object pascal? I am now working on a client-server service that entirely uses ORM. I have several patterns that repeat all over and some of them do not match into the

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 05.06.2017 20:37, Denis Kozlov wrote: > > I just wanted to highlight that these cases as legal and I presume not > uncommon, particularly if values are deserialized and typecasted. They are legal in the sense that they result in undefined behavior and in that case the compiler is free to act

Re: [fpc-devel] UTF-8 string literals

On 07.05.2017 14:16, Marco van de Voort wrote: > In our previous episode, Sven Barth via fpc-devel said: >>>> Is there a plan to fix it? >>> >>> Now it is fixed :D (revision 36116; maybe we should merge that to fixes >> once I or someone else tested a

Re: [fpc-devel] UTF-8 string literals

Am 05.05.2017 16:08 schrieb "Sven Barth" : > > Am 05.05.2017 16:03 schrieb "Juha Manninen" : > > > > On Fri, May 5, 2017 at 2:53 PM, Mattias Gaertner > > wrote: > > > 1. When using a character outside BMP FPC stops

Re: [fpc-devel] UTF-8 string literals

Am 06.05.2017 08:18 schrieb "Martok" : > PS: adding to the discussion over on the Lazarus ML: I just found a fourth wiki > page describing a slightly different Unicode support. This is getting ridiculous. That might be the one from Michael Schnell. Probably it should be

Re: [fpc-devel] UTF-8 string literals

Am 05.05.2017 15:55 schrieb "Michael Van Canneyt" : > > > > On Fri, 5 May 2017, Mattias Gaertner wrote: > >> On Fri, 5 May 2017 14:30:32 +0200 (CEST) >> Michael Van Canneyt wrote: >> >>> [...] >>> > AFAIK FPC stores UTF-8 string literals (-Fcutf8)

Re: [fpc-devel] UTF-8 string literals

Am 05.05.2017 16:03 schrieb "Juha Manninen" : > > On Fri, May 5, 2017 at 2:53 PM, Mattias Gaertner > wrote: > > 1. When using a character outside BMP FPC stops with: > > Error: UTF-8 code greater than 65535 found > > For example: > > const

Re: [fpc-devel] Let's Encrypt cert and mantis.freepascal.org

On 03.05.2017 09:06, Michael Van Canneyt wrote: > > > On Wed, 3 May 2017, Tomas Hajny wrote: > >> On Wed, May 3, 2017 00:33, Michael Van Canneyt wrote: >>> On Tue, 2 May 2017, Martin wrote: On 02/05/2017 22:59, Michael Van Canneyt wrote: > >> That's probably good as the fastest /

Re: [fpc-devel] Discussion about "Dynamic packages"

Am 13.04.2017 23:54 schrieb "gabor" <ga...@poczta.onet.pl>: > > > > W dniu 2017-04-13 o 22:27, Sven Barth via fpc-devel pisze: > >> And it's not about saving RAM or disk memory! It's about *binary code >> reuse*, the ability to fix a bug in multiple

Re: [fpc-devel] Discussion about "Dynamic packages"

bler code to see what I mean). > 04/13/17 12:28:02, Sven Barth via fpc-devel > <fpc-devel@lists.freepascal.org>: >> Yes, they are specifically for Pascal code and more specifically only FPC >> code as you can't use a Delphi dynamic package with FPC or the > other wa

Re: [fpc-devel] Discussion about "Dynamic packages"

Am 13.04.2017 12:03 schrieb "Mattias Gaertner" <nc-gaert...@netcologne.de>: > > On Thu, 13 Apr 2017 11:28:02 +0200 > Sven Barth via fpc-devel <fpc-devel@lists.freepascal.org> wrote: > > >[...] > > The intended purpose of dynamic packages (and l

Re: [fpc-devel] Discussion about "Dynamic packages"

Am 13.04.2017 08:44 schrieb "Bishop via fpc-devel" < fpc-devel@lists.freepascal.org>: > At first I would like to designate a circle of tasks which in principle can effectively decide by means of system of dynamic packets. Lets remember for what DLL`s and SO`s was be created. It was for memory

Re: [fpc-devel] LineInfo

Am 04.04.2017 10:42 schrieb "Tomas Hajny" <xhaj...@hajny.biz>: > > On Tue, April 4, 2017 10:21, Michael Van Canneyt wrote: > > On Tue, 4 Apr 2017, Sven Barth via fpc-devel wrote: > >> Am 04.04.2017 08:52 schrieb "Martok" <list...@ma

Re: [fpc-devel] LineInfo

Am 04.04.2017 08:52 schrieb "Martok" : > > >> Does it is possible that the LineInfo trace (-gl option) are broken (no output) > >> in 3.0.2 version on Linux (at least)? > > > > Hm. Indeed. I can reproduce the issue :/ > AFAIR lineinfo.pp only works with Stabs? Didn't the

Re: [fpc-devel] Detecting clashing ppus

Am 01.04.2017 10:53 schrieb "C Western" : > Is this a sensible change? I'd say so. If no other core dev complains during the day I'll commit it tomorrow. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

<    2   3   4   5   6   7   8   >