> On Jan 9, 2022, at 2:09 PM, J. Gareth Moreton via fpc-devel
> wrote:
>
> https://www.patreon.com/posts/60922821
Your plans are vectorization are an important gain for linear algebra and
games.
Could you detect things like:
var
a, b, c: TVec2;
begin
c := a + b * V2(10, 10);
where
> On Dec 27, 2021, at 1:44 AM, bla...@blaise.ru wrote:
>
> So, in your book, introducing a /new/ operator identifier "doesn't present
> any new syntax" (and I agree), but semantically allowing the /existing/
> directive DEFAULT to appear in the existing list of method directives is
> somehow
> On Dec 26, 2021, at 3:50 PM, Michael Van Canneyt via fpc-devel
> wrote:
>
> Please explain what's the point or benefit of this.
To aid in the usage of classes that have the sole intent of being called.
Surely though the compiler team will say this is not *needed* and can be
achieved
> On Dec 26, 2021, at 3:50 PM, Michael Van Canneyt via fpc-devel
> wrote:
>
> I think the idea of using a fixed member identifier for special purposes is
> really
> stupid design. I'll never forgive Embarcadero their 'GetEnumerator' idea...
I'm 99% certain using the method name "Invoke"
Thank you for continuing work on this, we all really appreciate your efforts.
> On Dec 23, 2021, at 1:16 AM, Blaise--- via fpc-devel
> wrote:
>
> 1) The attached metaclass_meth_to_procvar-1.patch fixes the internal error
> reported for:
Regards,
Ryan Joseph
> On Nov 14, 2021, at 4:58 PM, Jonas Maebe via fpc-devel
> wrote:
>
> Afaik there's also a C binding (or at least there used to be one).
There is some c bindings but they seem incomplete, or at least I couldn't
figure out how to follow the tutorial using what was provided there.
>
>> How
As a fun weekend project I wanted to follow along with the tutorial at
https://llvm.org/docs/tutorial/index.html but I noticed the API in in C++ so it
wouldn't be possible to do this in Pascal without at least some plain C API.
How did Free Pascal/Jonas accomplish this in the LLVM backend?
> 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
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
> 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
> 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
> 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
> 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
> 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
> 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
> 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,
> 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
> 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
> 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
> 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
>
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
> 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;
>
> 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
>
> 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?
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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;
>
>
> 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
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
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
> 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
> 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
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
> 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
> 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
> 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
> 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
> 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
>
> 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
> 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
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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
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
> 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
> 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
> 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
>
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
> 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
> 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
> 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
> 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:
>
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
> 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
> 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
> 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;
> 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 -
> 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
> 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
> 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
> 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
> 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
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
> 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
> 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
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
> 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
> 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
> 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
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
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
> 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.
> 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
> 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
> 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)
> 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
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.
> 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
> 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.
> 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,
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. :)
1 - 100 of 107 matches
Mail list logo
