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

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 management operators were? ___ fpc-devel

[fpc-devel] Why/how does the compiler have a non-trivial number of memory leaks after over two decades of development?

I was feeling inquisitive today, so I added 'SetHeapTraceOutput('log.trc');" to the first line of pp.pas and built myself a debug copy of the compiler using Lazarus. After building the following very simple program: program Test2; {$mode objfpc}{$H+} procedure TestProc(const S: String); begin

Re: [fpc-devel] FreeInstance

> I’m still trying to find this with no luck. Doing a quick search for the word "freeinstance" in the compiler source shows two places where it looks for a member function with that name in the global "current_structdef" variable. I'm fairly certain the one you're looking for is in a function call

Re: [fpc-devel] FreeInstance

> On Wed, Aug 1, 2018 at 11:27 AM, Ryan Joseph wrote: > Yeah, this is the first place I looked but current_structdef is always nil so it never progresses past that point. > Is this test program not enough to get FreeInstance called? You need to declare a class, and give that class at least one me

Re: [fpc-devel] FreeInstance

Forgot to mention a record or object with at least one method will get to the first part also, but never the FreeInstance part as they can never have destructors. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bi

Re: [fpc-devel] Why/how does the compiler have a non-trivial number of memory leaks after over two decades of development?

I'm somewhat surprised to see all the mentions of try-finally in response to this. The issues I found and described here are all clearly just simple cases of variables being created and then never freed. Part of what likely leads to this is that the compiler relies in many places on checking

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

On Thu, Oct 25, 2018 at 3:06 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Simon Kissel schrieb am Do., 25. Okt. > 2018, 08:54: > >> - Complete the LLVM branch of FPC. It looks like Jonas has stopped >> working on it two years ago, which is a pity. >> > > I personally d

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

On Sat, Oct 27, 2018 at 8:47 AM Jonas Maebe wrote: > On 27/10/18 05:45, Ben Grasset wrote: > You also need "opt" if you want to perform full optimizations (or just > use clang, which a.o. combines the functionality of llc and opt). > > There's one more problem I

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

On Sat, Oct 27, 2018 at 1:38 PM Florian Klämpfl wrote: > That it is useful to work on table based exception handling for all targets > Not arguing with that at all. I was just trying to point out that I'm not a fan of the idea that FPC's code generators are "good enough" as is. _

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

On Sat, Oct 27, 2018 at 6:46 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Except of course for optimizations that can be done on the platform > independent node tree. > That specifically is IMO the "key" to a higher compiler-wide level of optimization capabilities, as sh

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

On Sat, Oct 27, 2018 at 8:22 PM Ozz Nixon wrote: > * Sorry for off topic - just that grabbed my "What did he just say?" > button.. > Huh? I said "Also linked lists absolutely everywhere, that would perform much better as array based lists." Meaning, exactly the same thing you just implied. You

Re: [fpc-devel] The 15k bounty: Optimizing executable speed forLinux x86 / LLVM

On Sun, Oct 28, 2018 at 12:40 AM J. Gareth Moreton < gar...@moreton-family.com> wrote: > Part of my incentive is that I like to design games and am also an amateur > mathematician, both fields that can benefit from speed gains, so if I can > make Free Pascal into something that is suitable for suc

Re: [fpc-devel] Array assignment operator

On Sat, Nov 3, 2018 at 8:01 AM Schindler Karl-Michael < karl-michael.schind...@web.de> wrote: > Hi > > I would like to use a simple assignment operator for arrays, with which > all elements of an array are assigned to the same value, similar to an > extended initialize, not to zero but to a value

Re: [fpc-devel] Array assignment operator

On Sat, Nov 3, 2018 at 4:44 PM Gennady Agranov wrote: > Hi, > > Leaving aside the reason why the MiSchi's solution doesn't work the main > question is still not answered :) > > If you have integer dynamic array "MyArray" is there a way for the > following statement to compile and work correctly:

[fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. You ha

I've been happily building 64-bit FPC natively on Windows for over five years now. It works fine. It is stable. There is no logical reason whatsoever to use a 32-bit to 64-bit FPC cross compiler in 2018 if you are running 64-bit Windows natively, and anyone who thinks there is doesn't use Windows e

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

M, wkitt...@windstream.net wrote: > > On 11/3/18 7:09 PM, Ben Grasset wrote: > >> (The same could be said about the various other wildly outdated bits of > >> information on the overall site and the fact that it gives > >> now-hugely-irrelevant topics like "porti

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

ld ever be "daunting." On Sun, Nov 4, 2018 at 7:41 AM wrote: > On 11/3/18 7:09 PM, Ben Grasset wrote: > > (The same could be said about the various other wildly outdated bits of > > information on the overall site and the fact that it gives > > now-hugely-irrelevant

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

ve 64-bit is definitely objectively better in various ways, many not necessarily related building Lazarus specifically. As I said I've been building it myself for years, and I use it daily. On Sun, Nov 4, 2018 at 6:16 AM Jonas Maebe wrote: > On 04/11/18 00:09, Ben Grasset wrote: > > s j

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

I just strongly disagree that there's much merit or reality to the overall concept people keep floating here that FPC's *actual *user base consists largely of a magical non-stop stream of 50+ year olds who have randomly decided out of the blue to "pick up Pascal again" and re-live the whimsical goo

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

even if the code isn't > already written. > > > On 11/4/2018 7:41 AM, wkitt...@windstream.net wrote: > > On 11/3/18 7:09 PM, Ben Grasset wrote: > >> (The same could be said about the various other wildly outdated bits of > >> information on the overall site and

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

On Mon, Nov 5, 2018 at 12:22 PM Tomas Hajny wrote: > I'd appreciate if this part of the discussion related to importance of TP > compatibility is finished for everybody. For what it's worth my original message only mentioned the TP thing in passing, and I specifically said it was a "different i

Re: [fpc-devel] x86_64 Optimizer Overhaul

On Sat, Dec 15, 2018 at 1:01 PM Martok wrote: > I just tested something, and I'm a surprised by how big the difference is. > Should this really be surprising at all though? To me it seems obvious why that would be the case. Delphi the compiler (not the IDE) is not written in Pascal. It's written

Re: [fpc-devel] x86_64 Optimizer Overhaul

On Sat, Dec 15, 2018 at 1:14 PM J. Gareth Moreton wrote: > P.S. This thread is supposed to be for the x86_64 optimizer overhaul that > I presented! > Despite the other reply I just sent about the memory management stuff I also agree here! Your changes look very beneficial and it would be nice to

Re: [fpc-devel] x86_64 Optimizer Overhaul

On Sat, Dec 15, 2018 at 2:37 PM Martok wrote: > In any case, FPC's cmem on Win32 calls into mscvrt, and that is so slow > that I > killed the test code after a couple of minutes, where even FPC-builtin was > done > after 10 seconds. > Interesting. On Win64 I've found it to be consistently faster

[fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

TSize and TPoint, the other two advanced records defined there, have (well, mostly, they're also missing a couple) all record parameters in their method signatures declared "const", for what is presumably performance / efficiency reasons. That is to say, record parameters specified without "var",

Re: [fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

On Sat, Jan 26, 2019 at 7:06 PM Marco van de Voort < f...@pascalprogramming.org> wrote: > Anyway, a patch would be welcome. > Ok, I'll work one up that merges properly against the current trunk versions. Thanks for the quick response also, I was actually not sure who had written those files... di

Re: [fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

On Sun, Jan 27, 2019 at 8:00 AM Marco van de Voort < f...@pascalprogramming.org> wrote: > I wonder though that maybe makes passing properties etc difficult? > As far I know "const" has no tangible effect on how properties can be passed. Here's a little example to demonstrate: program Test; {$mo

Re: [fpc-devel] Fppkg

On Mon, Feb 4, 2019 at 9:53 AM Martok wrote: > the first-ever fppkg.exe invocation on a machine > Do people actually use fppkg for anything? More specifically what is the point of integrating it with Lazarus, which already has the OPM? ___ fpc-devel ma

Re: [fpc-devel] "Blank slate" next version of FPC

On Fri, Feb 15, 2019 at 4:07 AM James via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > I'm interested in starting (or joining) a discussion on the next (*non* > backwards compatible) version of FPC. Instead of being classically object > oriented, there is merit in examining a model with ad

Re: [fpc-devel] "Blank slate" next version of FPC

On Fri, Feb 15, 2019 at 3:33 PM Jonas Maebe wrote: > As mentioned by others, that's not really something any of the current > FPC developers are interested in working on. Martin Schreiber, however, > was working on a project like that before he passed away > I don't want to speak ill of the dead

Re: [fpc-devel] "Blank slate" next version of FPC

On Sun, Feb 17, 2019 at 3:15 AM Florian Klämpfl wrote: > This is a property of production compiler code. > I'm not sure about that. I don't think FPC's codebase is (for the most part) a mess, although the style is a little bit inconsistent sometimes. _

Re: [fpc-devel] "Blank slate" next version of FPC

On Sat, Feb 16, 2019 at 5:44 PM Benito van der Zander wrote > it can turn out the enumerators are slower than an old school loop > The trick with enumerators is to never make them classes, and use advanced records instead, I've found. This way you avoid the heap allocation and the implicit try/f

Re: [fpc-devel] "Blank slate" next version of FPC

On Fri, Feb 22, 2019 at 1:07 AM Paul van Helden wrote: > How do you make a (for in) enumerator with a record? I don't use them for > exactly this reason, and they did seem to be another useful language > feature that turned out to be poorly implemented by Embarcadero. (Haven't > checked with FPC

Re: [fpc-devel] "Blank slate" next version of FPC

test %al,%al > 004012C2 75cc jne0x401290 > > Nearly every line is accessing some memory, when it could keep everything > in a few registers. amd64 has 16 registers, but fpc seems to only know > three when records are involved > >

Re: [fpc-devel] Successful implementation of inline support forpure assembler routines on x86

Inlining of pure assembler functions would actually be immediately, specifically useful to me! I've been having a go at improving FPC scores on "BenchmarksGames", and was so far successful with Binary Trees simple by throwing a really good threading library at it, however, there are some benchmarks

Re: [fpc-devel] Successful implementation of inline support forpure assembler routines on x86

On Sun, Mar 17, 2019 at 1:57 PM Florian Klämpfl wrote: > > How is it better than intrinsics support (similiar to gcc/icc etc.)? > Well, it wouldn't be better than a literal equivalent to those intriniscs, if that's what we're talking about. By which I mean, like, say how in Clang/GCC (or languag

Re: [fpc-devel] Successful implementation of inline support forpure assembler routines on x86

To clarify my last message, what I had said previously was that FPC needs *either* inlinable assembler *or* intrinsics. Just basically something that ultimately can be called as a "normal" Pascal function, but that does *not* end up as an un-inlined function call. I have no preference as to how exa

Re: [fpc-devel] Closures repo

On Thu, Mar 21, 2019 at 4:40 PM Blaise Thorn wrote: > Should you be interested in writing tests, I could give you the acess. > I'd also be very interested in assisting with this, now that I'm aware you're willing to provide access to the repo. ___ fpc-

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

On Sun, Mar 24, 2019 at 6:22 PM Bart wrote: > Extract from fpc.cfg from 3.0.4 (created by offcial installer) > # searchpath for units and other system dependent things > -FuC:\devel\fpc\3.0.4/units/$fpctarget > -FuC:\devel\fpc\3.0.4/units/$fpctarget/* > -FuC:\devel\fpc\3.0.4/units/$fpctarget/rtl

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

On Mon, Mar 25, 2019 at 5:34 PM Ben Grasset wrote: > To be properly cross-platform, it should really generate something like > "-Fu..\..\units\$fpctarget" > I meant to say, "generate something like that specifically for Windows." Perhaps just have an IFDEF UNIX

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

On Tue, Mar 26, 2019 at 2:33 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Those paths are not handled relative to the compiler binary, they are > handled relative to the current directory when calling the compiler. The > compiler does not differentiate whether a parameter

Re: [fpc-devel] Vectorisation, optimisation etc.

On Wed, Mar 27, 2019 at 11:32 AM J. Gareth Moreton < gar...@moreton-family.com> wrote: > So with the false start that was pure inline assembly, I like to talk > about how to move forward with FPC, or at least with x86_64. > It occurred to me today, aren't you the person who fixed the -Sv compiler

Re: [fpc-devel] Vectorisation, optimisation etc.

On Sat, Apr 6, 2019 at 5:27 PM Jeppe Johansen wrote: > That can't happen or won't benefit much, before the compiler supports > super-natual alignments. So there's a deeper level of support needed. > I'm fairly confident the existing functionality could be improved upon in a useful way. Gareth has

Re: [fpc-devel] Vectorisation, optimisation etc.

On Sat, Apr 6, 2019 at 6:56 PM Jeppe Johansen wrote: > Perhaps but it's a nightmare in so many places to satisfy requirements for > potential uses. Ideally the programmer would specify minimum alignment > requirements per type > Actively worrying about alignment in the vast majority of cases is

Re: [fpc-devel] Operator overloading and {$mode delphi}

On Sat, Apr 13, 2019 at 6:04 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Maybe we should mention that in the documentation... > AFAIK it's never been possible to use FPC-style operator overloading in mode Delphi... is it supposed to be allowed? For example: unit Unit1

Re: [fpc-devel] Possible idea... "safe" subroutines/methods

On Sat, May 4, 2019 at 5:31 PM J. Gareth Moreton wrote: > I figure data-flow analysis will address everything eventually, but I > can't promise the compiler won't become very inefficient as a result. > I mean no offense by this, and note that I think you've done more for FPC in the last year (or

Re: [fpc-devel] Compiler picks wrong overload

On Wed, May 22, 2019 at 12:53 PM Pascal Riekenberg wrote: > No one? This is a showstopper! > FWIW, you can comment out the new TBytes definitions as a temporary fix. They are not actually used anywhere in the FPC codebase. More broadly I think the bigger problem is FPC's internal over-eagerness

Re: [fpc-devel] Closures/anonymous functions update

On Sat, May 18, 2019 at 2:57 PM Ryan Joseph wrote: > I wanted to make an alternate capture mode as an optimization for closures > that don’t get passed outside of their scope but I wasn’t able to figure > this out yet (using old-style objects instead of classes). It’s a waste to > allocate a new

Re: [fpc-devel] Minor request with case else branches

On Fri, May 24, 2019 at 5:46 PM J. Gareth Moreton wrote: > Whenever I come across a section of code in my own projects where "*else * > ;" is necessary, or any empty branch for that matter, I put a "{ Do > nothing }" comment just to make it absolutely clear that the block is > there deliberately

Re: [fpc-devel] When will the next version of FPC be released?

On Sat, Jun 1, 2019 at 6:00 AM Michael Van Canneyt wrote: > I don't think this syntax is a good idea. > > What with overloads ? > > Procedure MyProc(a:T); > Procedure MyProc(a : TObject); > > How do I know which one will be called ? > I think it would have to work like: if something is a TObject

Re: [fpc-devel] When will the next version of FPC be released?

On Sat, Jun 1, 2019 at 10:58 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > I personally consider it a worthwhile addition. > What version did Delphi add that in? I honestly had no idea it was a thing. Makes it seem especially strange that they still don't have freestandi

Re: [fpc-devel] Constants in generics patch

On Tue, May 21, 2019 at 12:23 AM Ryan Joseph wrote: > I believe I got it all tested and it’s fully functional now (another user > has been tested it also as you’ll see in the notes). > That's me! And yeah, I'd love to see some movement on this as it's an extremely powerful / useful feature.

Re: [fpc-devel] Standard generic classes

On Tue, Jun 4, 2019 at 4:40 PM J. Gareth Moreton wrote: > I may be missing the obvious here, but I've noticed that there are some > notable absences in the Free Generics Library. > All of that stuff is available in "rtl-generics" (currently trunk-only, but AFAIK works on 3.0.4 if you copy the so

Re: [fpc-devel] Standard generic classes

On Wed, Jun 5, 2019 at 11:11 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > You could try to adjust the FGL unit to use the pluggable sorting system > introduced here: > https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=41167 > Wouldn't that system itsel

[fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

For example, consider the following code, that implements a generic "memcpy"-style procedure using a static advanced-record method: program Example; {$mode Delphi} type TMem = record public type PT = ^T; public class procedure Copy(Dest: PT; Src: PT; Len: PtrUInt); static; inline;

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Fri, Jun 7, 2019 at 1:47 PM Jonas Maebe wrote: > It would be inconsistent to only allow such declaration for pointers, > and not for other types (a programming language should strive to be as > orthogonal as possible, with as few exceptions as possible). > I can't think of any particular vari

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Fri, Jun 7, 2019 at 2:35 PM Jonas Maebe wrote: > None of these can be defined as a type in parameter lists. Keep in mind > that "^Type" defines a new type. Semantically, it's at the same level as > "0..5" and "record a, b: longint end;". > Right, that's the point. There's nothing else that *w

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Fri, Jun 7, 2019 at 3:26 PM Jonas Maebe wrote: > So if you add something in it that is in fact the same as a regular type > definition, something is wrong. > What exactly is "wrong" there, though? In a world where they both worked, doing this, as we've discussed: procedure Proc(Param: ^TSome

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Fri, Jun 7, 2019 at 3:44 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > No, I think you *missed* the point. "^Type" defines a new type. "0..5" > defines a new type. "set of (Alpha, Beta, Gamma)" defines a new type. > "record a, b: longint end" defines a new types. All fo

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Fri, Jun 7, 2019 at 3:44 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > "0..5" defines a new type. "set of (Alpha, Beta, Gamma)" defines a new > type. "record a, b: longint end" defines a new types. > Building on my last reply, also, here's an example that shows what I

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

Two final things: A) I didn't really make this thread with to imply I necessarily wanted *someone else* to implement this. What I ultimately was trying to figure out is basically would I be wasting my time if I was able to implement this on my own, probably under a new modeswitch (maybe {$modeswit

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 11:26 AM Florian Klämpfl wrote: > Yes, but this has *nothing* to do with the output of -vp. Nothing. > My point with that was more just getting at "clearly typed pointer aliases are not actually that big of a deal internally for FPC", as in it doesn't really matter if it *

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 8:11 PM Dmitry Boyarintsev wrote: > One can't do > function myFunc(var a: record a,b: integer; end): integer; > the record type has to be declared separately. > Of course not. That would be rather nonsensical, *for very obvious reasons*, that I've already gone out of my

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 11:23 AM Ryan Joseph wrote: > var > a: ^integer; > begin > DoThis(a0); I'm assuming "a0" was just a typo there?... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinf

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 8:37 PM Bernd Oppolzer wrote: > the base type must have been declared already > Well, not necessarily in FPC, because generics, but that would just follow the same way generic parameters are currently "filled in later" in all other areas. On Sun, Jun 9, 2019 at 8:37 PM Be

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 9:19 PM Dmitry Boyarintsev wrote: > Ah... I found it now. It's all about generics. Well, there's nothing I > can argue about here. > Well, not *really.* As I stated in the original message, it's just as useful for non-generic procedures or non-generic anything else. On S

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 10:00 PM Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > Should the flowing code (inside of DoSomething body) be ok as well? > ((^Integer)(b))^ := a^; > I mean, like *many, many, many *things, yes it is technically possible for that to be valid Pascal syntax. As

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 10:28 PM Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > Distantly? you're proposing to introduce a reference-to-type declaration > within a parameter. Without giving it any name. > Fine. But that would requires a type-casting within the code to the same > type as h

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

> > On Sun, Jun 9, 2019 at 10:28 PM Dmitry Boyarintsev < > skalogryz.li...@gmail.com> wrote: > >> t's kinda what language designers HAVE to do. >> It's nice just to throw out the "next-big-thing-cool-idea" out there and >> make yourself look smart. >> But you actually HAVE to think everything throu

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Mon, Jun 10, 2019 at 12:15 AM Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > You've been told before. Variable types are not the same as parameter > types. > That *doesn't matter* in any *practical *sense. How you *used *something declared as "^Type" would always be the same no matte

Re: [fpc-devel] Object upgrades

On Mon, Jun 10, 2019 at 1:56 PM Ryan Joseph wrote: > I don’t think this is possible. Just did little test and the size of > “result” is always the size of the base class. Does this work? > Result in your example is the size of a *pointer* in all cases, which is fine / exactly what you'd expect i

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Mon, Jun 10, 2019 at 6:21 AM Martin Frb wrote: > If you did have "procedure P1(x: ^Byte); overload;", how would you call it? > I would think it should be compatible *not* with this: type PB = type ^byte; but with anything declared like this: type PB = ^byte; On Mon, Jun 10, 2019 at 6:21 A

Re: [fpc-devel] Copy/move operator

On Sun, Jun 16, 2019 at 9:30 AM Ryan Joseph wrote: > Here’s a little example of the problem. What I propose is that we either > add a 3rd boolean parameter to the Copy operator or add a new Move operator > which is preferred over the Copy operator if it exists (this is much more > work obviously

Re: [fpc-devel] Copy/move operator

On Mon, Jun 17, 2019 at 5:57 PM Ryan Joseph wrote: > The copy operator is always called on all assignments. Try actually > running that and you’ll see. :) > Yeah, I noticed that afterwards once I checked. I'm not sure how much sense that actually makes when the TList is a function *result* as it

Re: [fpc-devel] Copy/move operator

On Mon, Jun 17, 2019 at 5:57 PM Ryan Joseph wrote: > The copy operator is always called on all assignments. Try actually > running that and you’ll see. :) > Actually, after thinking about it some more, here's what I'd actually write (in a perfect world where it was possible.) program Test; {$m

Re: [fpc-devel] Copy/move operator

On Tue, Jun 18, 2019 at 11:08 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Those operators can't be inlined, because they're called from helper code, > not from the compiler directly. The LLVM backend won't change anything here. > Is there any real purpose to implementin

Re: [fpc-devel] Copy/move operator

On Wed, Jun 19, 2019 at 12:01 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > It wouldn't matter if the function is called Copy, operator:= or > "jdjfjsje". Once a copy management operator is defined the record type is > considered "managed" and thus all assignment operation

Re: [fpc-devel] Copy/move operator

On Wed, Jun 19, 2019 at 5:02 PM Ryan Joseph wrote: > It’s used for making reference counted types at the user level. > I'm not sure why you'd necessarily need to implement Copy specifically for that kind of thing, though. Initialize and Finalize would be much more relevant, I'd say.

Re: [fpc-devel] Copy/move operator

On Wed, Jun 19, 2019 at 5:45 PM Ben Grasset wrote: > On Wed, Jun 19, 2019 at 5:02 PM Ryan Joseph wrote: > >> It’s used for making reference counted types at the user level. >> > > I'm not sure why you'd necessarily need to implement Copy specifically for > t

Re: [fpc-devel] Copy/move operator

On Wed, Jun 19, 2019 at 6:19 PM Ryan Joseph wrote: > Because a copy isn’t necessarily an assignment. See the dynamic array > example again. The only way the record knows it was copied into the array > is via the copy operator. > I guess what I'm trying to get at is: A) Most of the time, the def

Re: [fpc-devel] XML node dump feature

On Sat, Jun 22, 2019 at 4:36 PM J. Gareth Moreton wrote: > I've noticed you're particularly keen on pure functions... what's the > main use that you envision for them? > I'm not the same person of course, but I'm pretty excited about them in regards to the initialization of constants. E.G. I'd

Re: [fpc-devel] XML node dump feature

On Mon, Jun 24, 2019 at 4:11 PM J. Gareth Moreton wrote: > "constexpr" is essentially to C++ as "pure" would be to FPC. Some of the > methods that involve pointers and var parameters (which is probably the > closest equivalent to the "&" parameters in C++) may be flagged as impure > because they

Re: [fpc-devel] XML node dump feature

On Tue, Jun 25, 2019 at 1:20 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Correct. Though considering that we're talking about *compile time* the > compiler *could* treat consts (in {$J-} mode) as constants if pure > functions are involved... > I'd be fine with the {$J-}

Re: [fpc-devel] XML node dump feature

On Tue, Jun 25, 2019 at 11:58 AM J. Gareth Moreton < gar...@moreton-family.com> wrote: > While pure and inline do have a lot of overlap and, internally, probably > share some features for convenience (like a copy of the node tree), they > are not the same > Oh yeah, not arguing that at all. Again

Re: [fpc-devel] Record types with unbounded trailing data

On Mon, Jun 24, 2019 at 12:41 AM Michael Van Canneyt wrote: > If you want to get rid of warnings, define it as > LOGPALETTE = record > palVersion : WORD; > palNumEntries : WORD; > palPalEntry : array[0..(MAXINT div sizeof(PALETTEENTRY)] of > PALETTEENTRY; > end; > Wouldn't that expli

Re: [fpc-devel] XML node dump feature

On Tue, Jun 25, 2019 at 3:23 PM denisgolovan wrote: > e.g. what about returning dynamic arrays? Like: > > type TIntArray = array of Integer; > function ArrInit(): TIntArray; > begin > SetLength(Result, 1); > Result[0]:=1; > end; > Stuff like that is pretty much impossible, because you can't

Re: [fpc-devel] XML node dump feature

On Tue, Jun 25, 2019 at 12:28 AM Marģers . via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Sorry to say but, this should not work even with > *pure* function. Typed constants are not truly > constants. > It's no different at all from doing something like this, which does work, specifica

Re: [fpc-devel] XML node dump feature

On Wed, Jun 26, 2019 at 1:48 AM J. Gareth Moreton wrote: > Maybe I'm misreading this, but does that mean you're not a fan of the > "pure" directive, Jonas? > It seems like if anything, he may have misunderstood that in this context, "in the hands of the user" is not intended to mean that people

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] 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. __

[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 go

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, a

[fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

This has been discussed I think several times in the past, but I thought I'd bring it up once more as it has never made sense to me that FPC happily supports multi-line *comments* of any length, while having no such multi-line equivalent for string literals. I was fiddling around with what the cle

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Wed, Jul 3, 2019 at 9:29 AM Ben Grasset wrote: > classic round-bracket-plus-apostrophe multi-line-Pascal-comment syntax. > I meant "round-bracket-plus-asterisk" here, of course. ___ fpc-devel maillist - fpc-devel@lists.free

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Wed, Jul 3, 2019 at 9:29 AM Ben Grasset wrote: > const SingleLineString = > That one was supposed to also say "const MultiLineString = ". ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Wed, Jul 3, 2019 at 9:34 AM Michael Van Canneyt wrote: > If multiline string support ever makes it into FPC, I hope it will be > simpler, with a backtick character: ` > I mean, I'd be fine with that also, if it was generally considered a better way of doing it. ___

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On Tue, Jul 2, 2019 at 7:38 PM Ondrej Pokorny wrote: > A good real-word example is the cast from a pointer: > > program Project1; > uses Classes; > var >Value: TPersistent; >P: Pointer; > begin >P := TObject.Create; >Value := TPersistent(P); >if Value is TPersistent then >

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Wed, Jul 3, 2019 at 10:22 AM Marcus Sackrow wrote: > I use an operator overload(not for constants but inside the code) > because I'm used to our script engine have the '/' as operator for > strings as line break. > That's certainly a neat use of operator overloading! However, I think that it

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Wed, Jul 3, 2019 at 2:43 PM Michael Van Canneyt wrote: > But the main question is: do we actually want a multiline string ? > As far as I am concerned, that question needs to be answered first, and for > me personally the answer to that is still a resounding "no". > Why, though? What makes it

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Wed, Jul 3, 2019 at 3:27 PM gabor wrote: > I am also against this program Example; (* This is a perfectly normal multi-line Pascal comment. *) const SA = ` This is a multiline string using hypothetical backticks. Imagine it was fully syntax-highlighted like normal strings and

  1   2   3   >