Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

2019-12-08 Thread Ryan Joseph via fpc-devel
> On Dec 8, 2019, at 2:30 PM, Sven Barth via fpc-devel > wrote: > > And no, your patch WILL NOT allow that. We've consciously decided AGAINST > implementing varargs functions in Pascal (see > https://wiki.freepascal.org/User_Changes_2.6.0#Array_of_const_parameters_and_cdecl_routines > )

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

2019-12-10 Thread Ryan Joseph via fpc-devel
> On Dec 10, 2019, at 11:38 AM, Sven Barth via fpc-devel > wrote: > > First of Object Pascal supports "array of const" which is safer due to a > added type field for each entry. > From the users standpoint only real difference is the [] syntax and if the array of const is the last (or

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

2019-12-14 Thread Ryan Joseph via fpc-devel
> On Dec 14, 2019, at 12:18 PM, Sven Barth via fpc-devel > wrote: > > In r43684 the syntax was now adjusted, so that an additional "cblock" > directive is required (in addition to the calling convention which for macOS > can be cdecl or mwpascal). can you please post an example snippet of

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

2019-12-11 Thread Ryan Joseph via fpc-devel
> On Dec 10, 2019, at 5:14 PM, Sven Barth via fpc-devel > wrote: > > From the view of the *caller* you are mostly right. Though the square > brackets can't be left away, cause we're talking about an array parameter > here. If it would be allowed for array of const then it would also need to

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

2019-12-11 Thread Ryan Joseph via fpc-devel
> On Dec 11, 2019, at 4:16 PM, Michael Van Canneyt > wrote: > > It does gain something: it tells you it is NOT a varargs, but an array of > const, which is a different beast altogether. But it's a syntax equivalent for "a variable amount of arguments", i.e. varargs. ;) I guess others don't

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

2019-12-12 Thread Ryan Joseph via fpc-devel
> On Dec 12, 2019, at 11:13 AM, Martin Frb wrote: > > I brought an example, where actually the "drop [] for last param" would break > code. > Therefore it no longer matters if it is or is not against good design. > Dropping the [], (in the new case, for last param) will break code that >

Re: [fpc-devel] Memory leak @ tobjectdef.getcopy

2019-12-01 Thread Ryan Joseph via fpc-devel
Blaise how are the closures coming? I think you have enough done you could submit it into trunk so we can start testing. Please if you can get to this we have people willing to help. It's been some 6 months now since I offered to help and it's still in limbo. Sorry to pester you but we're

Re: [fpc-devel] New feature announcement: constant parameters for generics

2020-04-27 Thread Ryan Joseph via fpc-devel
I think constants in generics may be the only way to create dynamically sized types at compile time (via static arrays). That seems like a really narrow usage but it opens a lot of doors most of us have probably never thought about. I suspect in time more good usages will be discovered.

Re: [fpc-devel] New feature announcement: constant parameters for generics

2020-04-25 Thread Ryan Joseph via fpc-devel
> On Apr 26, 2020, at 5:13 AM, Sven Barth via fpc-devel > wrote: > > The Free Pascal team is happy to announce the addition of a new language > feature: constant parameters for generics. Excellent! Thanks for getting this merged. It was a long battle but it's finally over. ;) Regards,

Re: [fpc-devel] New feature announcement: constant parameters for generics

2020-04-26 Thread Ryan Joseph via fpc-devel
> On Apr 26, 2020, at 2:38 PM, Michael Van Canneyt > wrote: > > As the original author, can you say something about the intended use of this > feature ? It was meant for a pretty narrow use of array types. If I knew how much work it would be to implement I probably would have not done it.

Re: [fpc-devel] New feature announcement: constant parameters for generics

2020-04-26 Thread Ryan Joseph via fpc-devel
> On Apr 26, 2020, at 4:02 PM, Michael Van Canneyt > wrote: > > Fixed-length arrays are the only practical use I can think of. I think you're right. Here's what I'll say next time: They're for composing types of dynamic size at compile time. :) Regards, Ryan Joseph

Re: [fpc-devel] Pure function development

2020-05-01 Thread Ryan Joseph via fpc-devel
> On May 1, 2020, at 6:46 AM, J. Gareth Moreton > wrote: > > Is there a good way to show you guys the work in progress and for you to make > more informed comments on the design along with any bugs and shortcomings? > I'm making progress with make a pure factorial function, but it's

Re: [fpc-devel] Pure function development

2020-05-01 Thread Ryan Joseph via fpc-devel
> On May 1, 2020, at 4:05 PM, J. Gareth Moreton > wrote: > > Okay, I'll give that a try - do I need to post the entire FPC repository > there with my changes, or just the diff/patch files? It shows the diffs for you. Fork the FPC project on GitHub (https://github.com/genericptr/freepascal)

[fpc-devel] Advanced objects

2020-03-23 Thread Ryan Joseph via fpc-devel
Checking in on old bug report for "advanced objects" which was marked as acknowledged on the tracker. Was there ever any discussion of this and possibility of it being applied? I don't think it caused any controversy so I was hoping to get to use it some time soon. :)

Re: [fpc-devel] Feature request/discussion - SetLengthNoInit

2020-09-15 Thread Ryan Joseph via fpc-devel
> On Sep 15, 2020, at 10:34 PM, J. Gareth Moreton via fpc-devel > wrote: > > I'm willing to settle with SetLength(array, len, ... len, NoInit: Boolean = > False), but of course it depends on the overall support for it, which isn't > looking too promising currently! > > I'd rather put the

Re: [fpc-devel] Github hosting of FPC utilities and [stable] sources

2020-10-13 Thread Ryan Joseph via fpc-devel
> On Oct 13, 2020, at 7:06 AM, Michael Van Canneyt via fpc-devel > wrote: > > This is planned, we wait for 3.2.2 and then we move to git. will it go on GitHub also and replace the old mirror site we've been using or will you host it on the free pascal website? Regards, Ryan Joseph

Re: [fpc-devel] Planning to experiment with FPC extentions

2020-08-25 Thread Ryan Joseph via fpc-devel
I started by using lazbuild with one of the .lpi files included in the fpc sources (add debug information when building also). lazbuild /fpc/compiler/ppcx64.lpi Next thing to do is put a syntax error in a example program and build it using the compiler (/fpc/compiler/ppcx64 myprog.pas for

Re: [fpc-devel] Planning to experiment with FPC extentions

2020-08-28 Thread Ryan Joseph via fpc-devel
Boian just today I made a little patch for a bug in the compiler (https://bugs.freepascal.org/view.php?id=37650) and I recorded a short 8 min video showing the process. I'm admittedly pretty terrible at making videos but it may be useful to just see the basics. I'm using VSCode as the

Re: [fpc-devel] Proposal/discussion: Simple nested functions and 'outlining'

2020-10-01 Thread Ryan Joseph via fpc-devel
> On Oct 1, 2020, at 10:37 AM, J. Gareth Moreton via fpc-devel > wrote: > > In situations where a nested function has no parameters, is it feasible and > beneficial to programmatically merge it into the main procedure What do you mean by "merge"? Like inlining? Regards, Ryan Joseph

[fpc-devel] Unknown compilerproc in r 46894

2020-09-18 Thread Ryan Joseph via fpc-devel
I was just going to test the applied patch https://bugs.freepascal.org/view.php?id=36909 with revision 46894 and I got this error. Any ideas? /usr/local/lib/fpc/3.0.4/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/Users/ryanjoseph/Developer/fpc/rtl/units/x86_64-darwin -Fix86_64

Re: [fpc-devel] Unknown compilerproc in r 46894

2020-09-19 Thread Ryan Joseph via fpc-devel
> On Sep 19, 2020, at 5:43 PM, Jonas Maebe via fpc-devel > wrote: > > It will work if you start your build with FPC 3.2.0 instead of 3.0.4. yes, that worked. thanks. 3.0.4 is officially not possible to use for bootstrapping I guess. Regards, Ryan Joseph

Re: [fpc-devel] Unknown compilerproc in r 46894

2020-09-19 Thread Ryan Joseph via fpc-devel
> On Sep 19, 2020, at 2:35 PM, Michael Van Canneyt > wrote: > > > It is a known issue, needs still to be fixed. > > Michael. A quick search suggests that https://bugs.freepascal.org/view.php?id=37221 is causing the problem. Sven applied my patch (array related) as well as this one which

Re: [fpc-devel] Feature request/discussion - SetLengthNoInit

2020-09-17 Thread Ryan Joseph via fpc-devel
> On Sep 17, 2020, at 11:33 AM, J. Gareth Moreton via fpc-devel > wrote: > > I think the difficulty with getting things like this approved is that it > crosses into the realm of defining the language itself. I can't say I speak > on behalf of Florian or Jonas, but I sense they want to

Re: [fpc-devel] Feature request/discussion - SetLengthNoInit

2020-09-18 Thread Ryan Joseph via fpc-devel
> On Sep 17, 2020, at 7:23 PM, Ryan Joseph wrote: > > Certainly. I think it depends on what the solution is. It's a known short > coming of the [] property and if the solution is as easy as allowing a var > param variant then maybe it's feasible. I'm remembering now I believe we did

Re: [fpc-devel] Feature request/discussion - SetLengthNoInit

2020-09-16 Thread Ryan Joseph via fpc-devel
> On Sep 16, 2020, at 9:10 PM, J. Gareth Moreton via fpc-devel > wrote: > > I figure I could design a dynamic array class, but it will very likely be > incompatible with SetLength no matter what I try to do, and unless I'm > mistaken, it won't have the benefit of automatically gaining an

Re: [fpc-devel] Feature request/discussion - SetLengthNoInit

2020-09-16 Thread Ryan Joseph via fpc-devel
> On Sep 17, 2020, at 9:59 AM, J. Gareth Moreton via fpc-devel > wrote: > > type generic TMyArray = record > Data: ^T; > Length: PtrUInt; > end; > > The compiler will complain about T being an unresolved forward declaration. > Outside of specifying a second parameter for the pointer

Re: [fpc-devel] Feature request/discussion - SetLengthNoInit

2020-09-16 Thread Ryan Joseph via fpc-devel
Here's an example of the main problem that keeps us from using custom types to replace dynamic arrays. We basically a need [] property modifier that treats records the same way the dynamic array syntax does. GetValue could be a procedure and use a var parameter and maybe even that would be

Re: [fpc-devel] [fpc-announce] FPC 3.2.0 released!

2020-07-04 Thread Ryan Joseph via fpc-devel
> On Jul 4, 2020, at 8:10 PM, Marco van de Voort > wrote: > > But the syntax will be CARD(variable), and there are some minor > things wrong with it: (anyone?) I'm waiting on my patch for implicit function specialization to be reviewed since I did a redesign (as per Svens request). If

Re: [fpc-devel] Advanced objects

2020-07-23 Thread Ryan Joseph via fpc-devel
> On Jul 23, 2020, at 7:32 AM, Kostas Michalopoulos via fpc-devel > wrote: > > Hi, > > I'd also like to repeat that question since i was just trying to use > management operators for a generic object type (not class, not record) > that i want it to automatically initialize/shutdown itself

Re: [fpc-devel] Advanced objects

2020-07-23 Thread Ryan Joseph via fpc-devel
> On Jul 24, 2020, at 6:07 AM, Kostas Michalopoulos via fpc-devel > wrote: > > There should be at least support for operators. I have a custom > dynamic array object type (i use objects instead of classes to avoid > unnecessary heap allocations) which would benefit a lot from such > support.

Re: [fpc-devel] Compiler message colour scheme

2020-11-23 Thread Ryan Joseph via fpc-devel
> On Nov 23, 2020, at 1:33 AM, Michael Van Canneyt via fpc-devel > wrote: > > I ran the compiler on linux through a ssh session: > > The colors display just fine, so I see no reason to disable on darwin except > that the termio unit is not found... If Florian wants to provide some

Re: [fpc-devel] Compiler message colour scheme

2020-11-22 Thread Ryan Joseph via fpc-devel
> On Nov 22, 2020, at 7:59 AM, J. Gareth Moreton via fpc-devel > wrote: > > Hi everyone, > > This might be me being a little bit picky, but I noticed the new colouring > scheme for words like "Warning" and "Error" in the output logs. Is there any > particular reason why "Warning" is in

Re: [fpc-devel] Compiler message colour scheme

2020-11-22 Thread Ryan Joseph via fpc-devel
> On Nov 22, 2020, at 8:57 AM, Jonas Maebe via fpc-devel > wrote: > > It's only enabled on Linux and Windows currently. Why is that? Mac has colors in the terminal also. Regards, Ryan Joseph ___ fpc-devel maillist -

Re: [fpc-devel] Compiler message colour scheme

2020-11-22 Thread Ryan Joseph via fpc-devel
> On Nov 22, 2020, at 9:29 AM, Florian Klämpfl via fpc-devel > wrote: > > Because I have no Mac so I couldn't test it. I see. It's this easy. const ANSI_FORE_BLACK = 30; ANSI_FORE_RED = 31; ANSI_FORE_GREEN = 32; ANSI_FORE_YELLOW = 33;

Re: [fpc-devel] Compiler message colour scheme

2020-11-22 Thread Ryan Joseph via fpc-devel
> On Nov 22, 2020, at 10:09 AM, J. Gareth Moreton via fpc-devel > wrote: > > Personally I'd write the function as something like "function > GenerateColorCode(codes: array of Byte): ansistring;", mostly in anticipation > of pure functions, because then the compiler can just replace the call

Re: [fpc-devel] FPC & Lazarus moving to gitlab

2021-06-22 Thread Ryan Joseph via fpc-devel
> On Jun 22, 2021, at 10:05 AM, Michael Van Canneyt via fpc-devel > wrote: > > The date for the final conversion has been established as the weekend of > 17/18 july. People that wish to report bugs after that will have to create a > gitlab account in order to do so. (Those with a github

Re: [fpc-devel] FPC & Lazarus moving to gitlab

2021-06-22 Thread Ryan Joseph via fpc-devel
> On Jun 22, 2021, at 4:02 PM, Sven Barth wrote: > > The plan has *never* been GitHub. The original plan was self hosted with a > *mirror* on GitHub. Now we'll instead use GitLab as main repository with a > mirror on GitHub. > How does the mirroring work? It seems 99% of the dev world is

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-10 Thread Ryan Joseph via fpc-devel
> On May 10, 2021, at 3:05 PM, Sven Barth via fpc-devel > wrote: > > Why should they? You pass the reference to a non-reference counted > parameter/field/variable, the reference count is increased and then what? It > sits there for the remaining life time of the program, because nothing >

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-10 Thread Ryan Joseph via fpc-devel
Over the weekend I fixed up my old default property code to work with records only which implement classes (which reduced lots of the complexity). It's actually a pretty clean and small implementation so I put a patch you can look at and try. It's not decided upon but this is a place to start

Re: [fpc-devel] Defer keyword

2021-05-10 Thread Ryan Joseph via fpc-devel
> On May 10, 2021, at 5:59 PM, Kostas Michalopoulos via fpc-devel > wrote: > > You do not need any special language feature for that, you can simply do > something like > >ReleaseLater(TObject.Create) yes but we can't get back the reference. It's a small thing but making this possible

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-06 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 7:14 PM, Ryan Joseph wrote: > > This can be detected at compile and at least give a warning. "a" is a member > of TR and the element type of "a" is TR, then we're assigning TR to said > array. It's that simple I think. It also occurs to me that record management

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-06 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 5:41 PM, Martin Frb via fpc-devel > wrote: > > You can already cause ref circles, no classes needed. > > type > TR = record > a: array of TR; > end; > > var > x: TR; > begin > SetLength(x.a,99); > x.a[0] := x; > end. This can be detected at compile and at

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-08 Thread Ryan Joseph via fpc-devel
> On May 8, 2021, at 7:59 AM, Sven Barth via fpc-devel > wrote: > > It has the exact same problems that my branch had (especially the interaction > of reference counted instances with non-reference counted ones). > > Using a variable/parameter/field based approach (like the idea with

Re: [fpc-devel] Defer keyword

2021-05-08 Thread Ryan Joseph via fpc-devel
> On May 8, 2021, at 8:05 AM, Sven Barth wrote: > >> a := TArray.Create([1,2,3]).AutoRelease; >> >> We can't do this in Pascal because the AutoRelease functions return type is >> not compatible with the type of the caller. Could we add something like an >> "Any" return type to Pascal which

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-08 Thread Ryan Joseph via fpc-devel
> On May 8, 2021, at 11:18 AM, Sven Barth wrote: > > It's not about reference counted classes vs. managed records, but about > whether it's *per type* or *per variable*, the implementation details are > completely irrelevant for now. So the biggest concern you see if that classes are easier

Re: [fpc-devel] Implicit function specialization precedence

2021-05-08 Thread Ryan Joseph via fpc-devel
> On May 8, 2021, at 12:04 PM, Sven Barth wrote: > > You need to use ChangeOwner as well, but as I wrote you need to pay attention > for which created symbol you do it at what time. Ok, maybe this is what I got wrong didn't use ChangeOwner. When you say "add to" what exactly do you mean?

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-09 Thread Ryan Joseph via fpc-devel
> On May 9, 2021, at 3:40 AM, Sven Barth wrote: > > === code begin === > > {$mode objfpc} > > type > TTest = class > protected > procedure DoSomething; > end; > > TTestSub = class refcounted(TTest) > public > procedure Test; > end; > > procedure TTest.DoSomething; >

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-09 Thread Ryan Joseph via fpc-devel
> On May 9, 2021, at 3:40 AM, Sven Barth wrote: > > It seems that you don't work much with classes then. If one disallows the > assignment of a reference counted class to a non-reference counted one then > you can't use e.g. TStringList.Objects. There is also the problem of method >

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Ryan Joseph via fpc-devel
> On May 7, 2021, at 3:08 AM, Michael Van Canneyt via fpc-devel > wrote: > > The introduction of generics and their abundant use in Delphi has noticably > slowed down the compiler and increased binary sizes. To my dismay, compile > times of 20 seconds up to 2 minutes have become not

[fpc-devel] default property (was Defer keyword)

2021-05-07 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 11:40 PM, Sven Barth wrote: > > In my opinion the better solution is to continue the road that Maciej started > and to implement that "default field" concept together with operator > hoistening so that records with management operators can be used as > containers. This

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Ryan Joseph via fpc-devel
> On May 7, 2021, at 9:40 AM, Benito van der Zander via fpc-devel > wrote: > > the classic Delphi way was to use an interface for freeing. It only requires > one type and nothing blows up. > That's clever but even try..finally is less overhead. Regards, Ryan Joseph

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Ryan Joseph via fpc-devel
> On May 7, 2021, at 2:46 AM, Sven Barth via fpc-devel > wrote: > > I cannot speak for others, but I think 90% of potential use cases for ref > counting > would be covered like this in my code: objects that only live inside a > procedure. > > I think the same. There's also a function

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-07 Thread Ryan Joseph via fpc-devel
> On May 7, 2021, at 2:52 PM, Sven Barth wrote: > > As said the main problem of reference counting on object instances, > especially if enabled by default like the Delphi NextGen compiler did, will > lead to problems in *existing* code and thus is a no-go. > What did you think about me

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 11:40 PM, Sven Barth wrote: > > There is no "finalization" section. It's really just an implicit try ... > finally block that the compiler inserts. Look for "cs_implicit_exceptions" > and "pi_needs_implicit_finally" if you want to learn more. Does that mean if you

Re: [fpc-devel] Implicit function specialization precedence

2021-05-06 Thread Ryan Joseph via fpc-devel
I found something sneaky I'd like to confirm before I decide what to do about it. 1) "T" in TAnyClass is specialized as Integer from the first parameter with TSomeClass (which is TAnyClass). 2) "U" is getting specialized as String by looking at the parameters in Compare() in which "U"(the

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 11:39 AM, J. Gareth Moreton via fpc-devel > wrote: > > In the example given: > > obj := TObject.Create; > defer objects.Free; > > What's wrong with Pascal's existing functionality? > > obj := TObject.Create; > try >... > finally >objects.Free; > end; > >

[fpc-devel] Defer keyword

2021-05-06 Thread Ryan Joseph via fpc-devel
Something which annoys me about Pascal is cleanup in which a function exits in multiple places but there is no formal way to free memory which may be used in the current scope. I say ultimately Pascal needs some opt-in automatic reference counting for TObject but the "defer" keyword would be

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 10:44 AM, Marco van de Voort via fpc-devel > wrote: > > But those types have refcounting built-in and always active. Things like > defer don't, which makes that all objects gets refcounting overhead in case > somebody needs it for "defer". > > Contrary to Pascal both

Re: [fpc-devel] Implicit function specialization precedence

2021-05-15 Thread Ryan Joseph via fpc-devel
> On May 15, 2021, at 10:49 AM, Ryan Joseph wrote: > > Also it looks like ChangeOwnerAndName isn't making the compiler happy. Sorry for the noise, I figured out it was because the name had spaces. How should I make the name then? I'm doing this for now which is certainly unique but it's not

Re: [fpc-devel] Implicit function specialization precedence

2021-05-15 Thread Ryan Joseph via fpc-devel
> On May 13, 2021, at 2:38 PM, Sven Barth wrote: > > Ah, you need to use ChangeOwnerAndName then and simply pass in the same name > you used for the constructor (cause otherwise it tries to use the name that > is currently stored in the list). Looking at this again today and I have yet

Re: [fpc-devel] Implicit function specialization precedence

2021-05-15 Thread Ryan Joseph via fpc-devel
> On May 15, 2021, at 10:27 AM, Ryan Joseph wrote: > > Looking at this again today and I have yet another question to confirm. I > create one of the types using ctypesym.create but the others were just > references from the system unit. We only want to change owner of the symbol I > create,

Re: [fpc-devel] Implicit function specialization precedence

2021-05-12 Thread Ryan Joseph via fpc-devel
> On May 9, 2021, at 1:30 AM, Sven Barth wrote: > > Essentially it will boil down to sym.ChangeOwner(pd.parast) > > However you need to keep the Owner (which is different from what you change > with ChangeOwner) different as otherwise is_specialization of the procdef > will not work

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-16 Thread Ryan Joseph via fpc-devel
> On May 10, 2021, at 3:18 PM, Ryan Joseph wrote: > > Lets focus on the record approach for now then. I don't think I know enough > to understand where are the pitfalls are. This was another thing I wanted off my mind since a couple years ago already so I got a pretty good start of an

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 4:05 PM, Sven Barth via fpc-devel > wrote: > > Other than that, you're right and what Ryan is trying to do is definitely the > intended purpose of try ... finally. > Is there any runtime code involved with try..finally or does it just reorganize the code to run at the

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Ryan Joseph via fpc-devel
> On May 6, 2021, at 4:26 PM, J. Gareth Moreton via fpc-devel > wrote: > > There is a performance penalty when using them, which one reason why the > compiler sources don't use them. There's probably other reasons too. There > might be some speed-up potential where standard Exit calls are

Re: [fpc-devel] Implicit function specialization precedence

2021-04-29 Thread Ryan Joseph via fpc-devel
> On Apr 22, 2021, at 9:52 AM, Ryan Joseph wrote: > >> Got this all integrated and put up the changes to >> https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another >> final review. :) > > The next thing to do now is to handle a memory leak. From the bug tracker: I just

Re: [fpc-devel] Implicit function specialization precedence

2021-04-22 Thread Ryan Joseph via fpc-devel
> On Apr 16, 2021, at 11:35 AM, Ryan Joseph wrote: > > Got this all integrated and put up the changes to > https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another > final review. :) The next thing to do now is to handle a memory leak. From the bug tracker: > You

Re: [fpc-devel] Nested function closures

2021-04-27 Thread Ryan Joseph via fpc-devel
> On Apr 27, 2021, at 12:10 PM, Sven Barth via fpc-devel > wrote: > >> So as Sven wrote, you would be duplicating effort, needlessly, since it has >> to work always... If the compiler can decide that the heap interface is not >> needed and optimize it away: so much the better. But I doubt

[fpc-devel] Nested function closures

2021-04-27 Thread Ryan Joseph via fpc-devel
Continued from our discussion at https://bugs.freepascal.org/view.php?id=24481. > if the compiler devs will allow me as soon as this is finished I want to > allow the existing nested functions functionality to work with anonymous > functions, so at the very least we don't need to generate the

Re: [fpc-devel] Implicit function specialization precedence

2021-04-06 Thread Ryan Joseph via fpc-devel
> On Apr 6, 2021, at 12:57 PM, Sven Barth wrote: > > In this specific case the two functions also are *not* ambigous, because for > the non-generic Test the parameter requires an implicit conversion, but the > implicit specialization does not. For example if there would be a "Test(aArg: >

Re: [fpc-devel] Implicit function specialization precedence

2021-04-06 Thread Ryan Joseph via fpc-devel
> On Apr 6, 2021, at 12:57 PM, Sven Barth wrote: > > In the example you posted below, I agree with you, but that is not what I > said. Look at my example again: Also could you please verify that $H+ isn't causing problems? The string literal 'Hello World' is a short string but "String" is

[fpc-devel] Implicit function specialization precedence

2021-04-06 Thread Ryan Joseph via fpc-devel
Finally some movement is happening on implicit function specialization and I'm almost finished now except some questions about precedence have been raised again. Initially I thought we decided on non-generic functions taking precedence in the case of *any* name collisions (the original thread

Re: [fpc-devel] Implicit function specialization precedence

2021-04-08 Thread Ryan Joseph via fpc-devel
> On Apr 7, 2021, at 1:56 PM, Ryan Joseph wrote: > > Ok, so with $H+ constant strings will be specialized as AnsiStrings. And > there is another unicode string mode I should do a similar thing with? Also > if you happen to know where I can get the state of $H+ that would be helpful >

Re: [fpc-devel] Implicit function specialization precedence

2021-04-07 Thread Ryan Joseph via fpc-devel
> On Apr 6, 2021, at 11:34 PM, Sven Barth wrote: > > In the second case the compiler will have the non-generic Test(String) due to > the implicit operator as well as Test(LongInt) due to the implicit > specialization. Here it will pick the generic one, because a call without a > type

Re: [fpc-devel] Implicit function specialization precedence

2021-04-07 Thread Ryan Joseph via fpc-devel
> On Apr 7, 2021, at 1:42 PM, Sven Barth via fpc-devel > wrote: > > Yes, we want to change that for two reasons: > - the constant string might be larger than 255 characters > - ShortString is worse for passing as a by-value parameter (which will be the > default after all) than AnsiString or

Re: [fpc-devel] Implicit function specialization precedence

2021-04-08 Thread Ryan Joseph via fpc-devel
> On Apr 8, 2021, at 3:53 PM, Sven Barth wrote: > > 1. you should not blindly assume that the def is a stringdef if it's not an > arraydef; at least use an internalerror to protect against problems here > 2. if it's really a stringdef and the return type is st_shortstring you > should indeed

Re: [fpc-devel] Implicit function specialization precedence

2021-04-07 Thread Ryan Joseph via fpc-devel
With the requested changes I believe some precedence rules have changed. These both should be "Can't determine which overloaded function to call" errors or the non-generic should take precedence because the functions are ambiguous (by appearance at least). Currently the compiler thinks DoThis

Re: [fpc-devel] Implicit function specialization precedence

2021-04-15 Thread Ryan Joseph via fpc-devel
> On Apr 14, 2021, at 3:49 PM, Ryan Joseph wrote: > > It works but it thinks this array is array of const also so it's too strict I > believe. > > ['aaa', 'bbb']; About this, shouldn't we just be doing this? Any array constructor that has elements which are which are incompatible is "array

Re: [fpc-devel] Implicit function specialization precedence

2021-04-15 Thread Ryan Joseph via fpc-devel
> On Apr 14, 2021, at 11:39 PM, Sven Barth wrote: > > Well, then I'll have to improve the check. But for now you can continue, > right? I can continue but if I include the check some tests will fail. Currently I've only made some changes in create_unamed_typesym and now this check to reject

Re: [fpc-devel] Implicit function specialization precedence

2021-04-09 Thread Ryan Joseph via fpc-devel
> On Apr 9, 2021, at 4:31 PM, Sven Barth via fpc-devel > wrote: > > You mean what you did for is_array_literal? A pure array constructor can be > found with is_array_constructor, though it might be better to use > is_open_array, cause someone might pass an open array parameter to a generic

Re: [fpc-devel] Implicit function specialization precedence

2021-04-09 Thread Ryan Joseph via fpc-devel
> On Apr 9, 2021, at 3:08 PM, Sven Barth wrote: > > Possibly, yes... > > You could provide the various utility functions in a separate patch. Well I'm going to use them for this patch so they would all be batched together. Any idea about the "array of const" issue I raised in the other

Re: [fpc-devel] Implicit function specialization precedence

2021-04-10 Thread Ryan Joseph via fpc-devel
> On Apr 10, 2021, at 6:54 AM, Sven Barth wrote: > > As an additional note: if you take a look at > tarrayconstructornode.pass_typecheck you can see that the array type always > has the ado_IsConstructor set and if it contains of incompatible types the > ado_IsVariant is set as well. So if

Re: [fpc-devel] Implicit function specialization precedence

2021-04-10 Thread Ryan Joseph via fpc-devel
> On Apr 10, 2021, at 9:18 AM, Ryan Joseph wrote: > > I checked before and here's what I got. Maybe pass_typecheck hasn't been > called yet? If not I'll have to reproduce that code and determine how it > knows the elements are not uniform. Thanks. Just checked and pass_typecheck is called

Re: [fpc-devel] Generic class comparison operators

2021-04-21 Thread Ryan Joseph via fpc-devel
> On Apr 21, 2021, at 7:44 AM, Benito van der Zander via fpc-devel > wrote: > > Hi, > > what about overloading operators for OBJECTs? > > They do not conflict with any default operators. > > I expected this to work, but it did not compile: > > > > type generic TXQHashset = object

[fpc-devel] Generic class comparison operators

2021-04-17 Thread Ryan Joseph via fpc-devel
Since I'm working on generics right now can we finally, at the very least, allow class operators for comparison operators? This is literally the only way for a generic class to override the = operator (along with some others) so there's no reason not to allow this. I understand the objection to

Re: [fpc-devel] Generic class comparison operators

2021-04-17 Thread Ryan Joseph via fpc-devel
> On Apr 17, 2021, at 2:12 PM, Jonas Maebe via fpc-devel > wrote: > > The issue with allowing it for classes (generic or not) is that the the = > operator already has a meaning for them (pointer equality). I think in > general we don't allow overloading operators that have a built-in

Re: [fpc-devel] Implicit function specialization precedence

2021-04-16 Thread Ryan Joseph via fpc-devel
> On Apr 16, 2021, at 2:44 AM, Sven Barth via fpc-devel > wrote: > > Yes, do that for now. > Got this all integrated and put up the changes to https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another final review. :) Regards, Ryan Joseph

Re: [fpc-devel] Implicit function specialization precedence

2021-04-09 Thread Ryan Joseph via fpc-devel
> On Apr 8, 2021, at 11:37 PM, Sven Barth via fpc-devel > wrote: > > That is because before the introduction of type helpers such functions > weren't really needed. Other mechanisms caught such constants, but for both > type helpers and these implicit specializations it's hard to do it

Re: [fpc-devel] Implicit function specialization precedence

2021-04-09 Thread Ryan Joseph via fpc-devel
I just realized one more type introspection related issue. This currently will specialize as DoThis because the array constructor element type is "shortint" as is derived from the first element 1. This of course is not correct so I'd like to reject "array of const constructors" but I don't see

Re: [fpc-devel] Implicit function specialization precedence

2021-04-14 Thread Ryan Joseph via fpc-devel
> On Apr 14, 2021, at 2:33 PM, Sven Barth wrote: > > Had a bit of time to look at this. You can try the attached patch. You can > then check for both ado_IsConstructor and ado_IsArrayOfConst to detect such a > mixed array. It works but it thinks this array is array of const also so it's too

Re: [fpc-devel] Implicit function specialization precedence

2021-04-11 Thread Ryan Joseph via fpc-devel
> On Apr 11, 2021, at 3:33 PM, Sven Barth wrote: > > Looking at it, it could be that there is a bug in > tarrayconstructornode.pass_typecheck that hasn't really surfaced yet... I'll > have to look at that first, but I don't know when I'll have the time for that. sure I'll just leave it as

Re: [fpc-devel] Implicit function specialization precedence

2021-04-11 Thread Ryan Joseph via fpc-devel
> On Apr 10, 2021, at 9:47 AM, Ryan Joseph wrote: > > Just checked and pass_typecheck is called before overloading but > ado_IsVariant is simply never set for that array. In tarraydef.GetTypeName > you can see that "array of const" is associated with many flags so maybe we > need to make a

Re: [fpc-devel] [fpc-pascal] How does TFPGMap key compare work?

2021-04-22 Thread Ryan Joseph via fpc-devel
> On Apr 21, 2021, at 11:21 PM, Sven Barth wrote: > > You need to use named types, though for operators this is less useful, > because the compiler will implicitly convert different ShortString types to > find a suitable operator overload: Then the compiler must do this for all strings

Re: [fpc-devel] Generic class comparison operators

2021-04-21 Thread Ryan Joseph via fpc-devel
> On Apr 18, 2021, at 1:37 AM, Sven Barth wrote: > > It has been decided back when operator overloads were introduced that they do > not replace existing, built in operators. This decision still stands. And we > see no reason to change that. This way a user can *rely* on what a certain >

Re: [fpc-devel] Generic class comparison operators

2021-04-21 Thread Ryan Joseph via fpc-devel
> On Apr 21, 2021, at 12:57 PM, Sven Barth via fpc-devel > wrote: > > You can only use global operators with objects. yes but not with *generic* objects. I find it very hard to understand why this is being blocked for objects. Without this there is no way to have *generic* record

Re: [fpc-devel] [fpc-pascal] How does TFPGMap key compare work?

2021-04-21 Thread Ryan Joseph via fpc-devel
> On Apr 20, 2021, at 11:38 PM, Sven Barth wrote: > > All four string types provide built in > and < operators: On a side note how do you even make overloads (or type helpers for that matter) for short strings because String[10] isn't the same type as String[100]? Regards, Ryan

Re: [fpc-devel] RTTI status in 3.2.0 and 3.2.2

2021-09-20 Thread Ryan Joseph via fpc-devel
> On Sep 19, 2021, at 7:01 AM, Sven Barth via fpc-devel > wrote: > > No, this is not yet supported, but it's a work in progress, but it will > arrive the earliest with 3.4 which is not yet planned. > We're nearly finished with right now so it could appear in the trunk version within a

Re: [fpc-devel] To all Mantis (Bugtracker) account holders - prepare for the move to Gitlab - Now

2021-07-17 Thread Ryan Joseph via fpc-devel
> On Jul 17, 2021, at 4:09 PM, Michael Van Canneyt via fpc-devel > wrote: > > Yes. ok, thanks. https://bugs.freepascal.org/view.php?id=39238 Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] To all Mantis (Bugtracker) account holders - prepare for the move to Gitlab - Now

2021-07-17 Thread Ryan Joseph via fpc-devel
> On Jul 17, 2021, at 12:58 PM, Michael Van Canneyt via fpc-devel > > > To map your gitlab user name (or ID) to the > mantis user, we ask that you file an issue in the mantis project of the > current bugtracker > https://bugs.freepascal.org/bug_report_page.php?project_id=4 > Assign it the

Re: [fpc-devel] Moving to gitlab.

2021-07-27 Thread Ryan Joseph via fpc-devel
I see the old bug reporter has been taken down now. Can anyone explain how to see my old bug reports now? I went to https://gitlab.com/groups/freepascal.org/fpc/-/issues and filtered by my username "genericptr" but nothing came up. Regards, Ryan Joseph

  1   2   >