> On Feb 21, 2022, at 7:31 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> Hm. I'm not sure that this code does what you need.
>
> But masking is indeed not in the helpers.
>
Try it yourself, it does indeed work. How else are you supposed to test these
kinds of bit flag APIs where all
> On Feb 21, 2022, at 7:01 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> Yes, this is testbit.
>
> Why do you say it does not work ?
Oh my, I was confusing my terms I think. I wanted to do bit masking (I think
it's called). I was expecting there to be something like TestFlag in the
I tried to use the bit helpers like
https://www.freepascal.org/docs-html/rtl/sysutils/twordhelper.testbit.html but
the bit to test is 0..15. I expected this to work like
https://wiki.freepascal.org/Bit_manipulation but that doesn't seem to be the
case.
Does there exist bit helpers like
> On Feb 16, 2022, at 12:18 AM, Thomas Kurz via fpc-pascal
> wrote:
>
> What release are anonymous functions planed for? FPC 3.4.0?
They aren't even in trunk yet. Could be months or years.
Regards,
Ryan Joseph
___
fpc-pascal maillist -
> On Feb 15, 2022, at 11:09 PM, Sven Barth via fpc-pascal
> wrote:
>
> For a global function the compiler has to generate a wrapper that gets rid of
> the Self parameter of the interface.
>
The compiler generates this interface at compile time right? And then when the
scope of the
> On Feb 16, 2022, at 2:46 AM, Sven Barth via fpc-pascal
> wrote:
>
> // nested function/procedure/routine variable
> type
> TFoobarNested = function: LongInt is nested;
>
> var
>f: TFoobarFuncRef;
> begin
> // anonymous function/procedure/routine
> f := function: LongInt
>
> On Feb 15, 2022, at 8:26 PM, Sven Barth via fpc-pascal
> wrote:
>
> It's relatively "easy" to implement assigning a nested function to function
> references. However assigning a nested function variable to a function
> reference is much harder.
> Assigning a function reference to a nested
> On Feb 15, 2022, at 8:32 PM, Sven Barth via fpc-pascal
> wrote:
>
> A function reference is simply an interface of which the Invoke method can be
> called on the instance instead of manually doing "Foo.Invoke".
>
> The real "magic" is when the compiler generates the *implementation* of
> On Feb 15, 2022, at 7:10 PM, Michael Van Canneyt
> wrote:
>
> In Delphi it is not. In FPC it should be :-)
Indeed should be but that's what I'm trying to figure out with how this is
implemented.
Why wouldn't Delphi be able to do this I wonder. The calling mechanism in this
object is not
> On Feb 15, 2022, at 5:15 PM, Sven Barth wrote:
>
> It contains a capture object that backs the method.
> If nothing is captured and the right hand side is a direct function or method
> pointer then the compiler could in principle create something that is
> essentially static to avoid
> On Feb 15, 2022, at 3:32 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> I requested that this:
>
> procedure TMyObject.Demo;
>
> Procedure DoSub;
> begin
>Writeln('Sub');
> end;
>
> begin
> DoTest(DoSub);
> end;
So that means "reference to procedure" is not compatible with
> On Feb 15, 2022, at 2:09 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> I've answered this question before:
>
> The "Reference to procedure" that will be part of anonymous functionswill do
> this for you.
I'm sorry I forgot! This thing keeps coming up for me and driving me nuts but
This has been a constant problem for me with FPC and wanted to make a formal
post with code examples since I've only mentioned it in passing before.
How can it be achieved to have a caller agnostic procedure variables? I've
tried making some big crazy dispatch record that uses generics but
> On Feb 12, 2022, at 11:40 PM, Jonas Maebe via fpc-pascal
> wrote:
>
> I wouldn't consider this to be working by design, but rather because of
> implementation limitations.
I agree and it should be fixed probably.
Regards,
Ryan Joseph
> On Feb 1, 2022, at 9:22 PM, Ryan Joseph wrote:
>
>
> If anyone understands SDL I figured out how to get around this missing main
> linker error and program runs but then crashes. I've reported to SDL at
> https://discourse.libsdl.org/t/crash-in-uitextfield/34711 (along with my
> program
> On Feb 1, 2022, at 9:34 AM, Ryan Joseph wrote:
>
> My only guess is that the linker can't find the SDL main function in the
> framework, even though everything else links properly.
If anyone understands SDL I figured out how to get around this missing main
linker error and program runs
> On Feb 1, 2022, at 3:15 AM, Jonas Maebe via fpc-pascal
> wrote:
>
> It only works in your main program, not in a unit or so. Maybe that's the
> reason?
The linker wants me to redefine "main" to clear the error but this doesn't make
sense and the app crashes when launched. I.e.:
I thought I had this working some years ago but I'm confused again. :)
When trying to use SDL on iPhone I include:
{$PASCALMAINNAME SDL_main}
But when I compile I get a linker error:
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main
> On Jan 27, 2022, at 12:10 AM, Pierre Muller via fpc-pascal
> wrote:
>
> You should probably try to look for another define somewhere else!
Thanks I found it. The error was misleading as it directed me the first
occurrence when it was the second one that did it. I think using undef would
I have this macro:
{$define TCallback := TCallback2}
which gives a long list of these errors.
warning: Expanding of macros exceeds a depth of 16.
What does this warning mean and how can I resolve it?
Regards,
Ryan Joseph
___
fpc-pascal
> On Jan 20, 2022, at 8:10 PM, Ryan Joseph wrote:
>
> I just check at https://gitlab.com/freepascal.org/fpc/source/-/merge_requests
> and I don't see my merge request appeared. If it were GitHub I would expect
> to see it there. What did I do wrong?
So what I did was created a merge request
> On Jan 20, 2022, at 9:11 AM, Ryan Joseph wrote:
>
> The problem was my remote for the branch got lost after rebasing but I think
> I fixed it by re-pulling.
>
> It looks like some unrelated commits are included in my merge request but
> maybe that happened because I rebased the repo after
> On Jan 19, 2022, at 8:14 PM, Ryan Joseph wrote:
>
> Ok I got this almost done (mirroring is great I didn't know I could do that)
> and did the rebase which shows the linear history now.
>
> First a question, do I need to do the "rebase main" again before I push to
> remote or does it
Ok I got this almost done (mirroring is great I didn't know I could do that)
and did the rebase which shows the linear history now.
First a question, do I need to do the "rebase main" again before I push to
remote or does it stay this way now?
Problem is I go to push the changes to the my
> On Jan 19, 2022, at 4:19 PM, Ryan Joseph wrote:
>
> Still not following this. Do you need me to do a pull-rebase from main and
> then make my pull request?
I used git at work everyday but I'm still a newbie in many ways. Reading this
now but I'm confused because it seems too late. Please
> On Jan 19, 2022, at 4:15 PM, Michael Van Canneyt
> wrote:
>
> It's explained in the page that Sven referred to ?
>
> It's only when you merge into your feature branch from the main branch that
> you will see an effect.
Still not following this. Do you need me to do a pull-rebase from
> On Jan 19, 2022, at 1:26 PM, Sven Barth wrote:
>
> We also take merge requests. If you have a fork anyway, then a merge request
> is probably easier. Though you need to have your repository set up to use
> rebasing instead of merging, see here:
> https://wiki.freepascal.org/FPC_git#Update
> On Jan 18, 2022, at 5:28 AM, Sven Barth wrote:
>
> The values will have the same differences between each other upon each start
> so ideally this would work anyway, but if one also throws dynamic packages
> into the mix things would get messed up. So better stay with the if-clauses.
> On Jan 17, 2022, at 5:09 PM, Sven Barth wrote:
>
> The VMT writer already does that, cause the VMT pointer is required for each
> constructor call.
>
The pointer to the VMT table is just PVmt(self) right? If I make a program and
do:
writeln(PtrUInt(TObject.ClassType));
the address
> On Jan 17, 2022, at 1:55 PM, Sven Barth wrote:
>
> Question then is how you get the VMT address as a constant at compile time.
>
> I'll need to get back to you with that.
>
I didn't test yet but I think what you're saying is that VMT writer would need
to have generated this address in
> On Jan 16, 2022, at 11:15 PM, Sven Barth wrote:
>
> The class type already is a unique "ID" for each class type when doing an
> equal comparison. You can essentially take the address of the VMT as the
> constant values that the loaded value is compared against.
Does that look something
> On Jan 16, 2022, at 9:01 PM, Ryan Joseph wrote:
>
> case PtrUInt(o.ClassType) of
>4500656856: writeln('TObject');
> end;
I may have spoken too soon and without thinking the through clearly (it's
getting late here!). For this to work we would need a unique ID in the RTTI,
right? I
> On Jan 16, 2022, at 8:18 PM, Ryan Joseph wrote:
>
> https://gitlab.com/genericptr/free-pascal/-/commits/case_label_classref
I just realized too late that the way I implemented this may be not the best
idea. If the class type had an ordinal representation then you could use a
normal case
> On Jan 16, 2022, at 8:38 PM, Marco van de Voort via fpc-pascal
> wrote:
>
> What does it print in this case? I mean tobject matches, and
> tinterfacedobject too.
>
> The most logic solution would be to only run the most specialized case?
It would print the name of the class if it didn't
I had some fun today on my day off and managed to actually implement this based
on the if-statement based string case labels. Is the compiler team interested
in this feature? I think it's a clearly useful addition to OOP and an
appropriate new use of the case statement.
> On Jan 16, 2022, at 2:35 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
>
> They are.
>
> No "is", because then the order of the label will start to matter, and that
> runs contrary
> to the case statement's intent.
oh of course they are, I don't know why I forgot that. :P
Regards,
> On Jan 16, 2022, at 9:21 AM, Ryan Joseph wrote:
>
> There is a possibility for using "as" operator also though
oops I mean "is" operator. Not sure if these are technically different from
ClassType = ClassType though...
Regards,
Ryan Joseph
> On Jan 15, 2022, at 3:24 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> I don't see how an inline variable helps with the casting mess. You'll
> always need a cast.
>
> What I do is Var
> MyInstance : TObject;
> MyNeededClass : TMyNeededClass absolute myInstance:
Yes that's the
> On Jan 15, 2022, at 8:30 AM, Michael Van Canneyt via fpc-pascal
> wrote:
>
>> I saw a new syntax in Swift which I thought was clever and fits a pattern
>> I've seen before. Basically it's a case statement for class types which
>> lets you branch depending on which class type the class
I saw a new syntax in Swift which I thought was clever and fits a pattern I've
seen before. Basically it's a case statement for class types which lets you
branch depending on which class type the class instance is at run time.
I wonder if this could be implemented in FPC? The syntax would be
> On Dec 24, 2021, at 8:13 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> Our little contribution to a Merry Christmas for everyone...
Nice work. I have a hard time wrapping my head around this. Can you just write
plain HTML to STDOUT using writeln and that's enough?
Regards,
> On Dec 1, 2021, at 4:56 AM, Sven Barth wrote:
>
> If you don't allow to skip parameters then this feature can be considered
> absolutely useless. Who would voluntarily write more when many users already
> cry about Pascal being so verbose?
I thought the option of improved readability made
> On Nov 28, 2021, at 7:01 PM, Sven Barth wrote:
>
> Anything that relates to picking functions *must* be part of the overload
> handling. You can easily see this with your named argument proposal when not
> all arguments are named (and then the compiler also needs to check that
> unnamed
> On Nov 28, 2021, at 4:18 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> What do you mean? Is there already some call by arg names in some
> mode(switch)?
I mean all the plumbing is there so the feature could easily be extended from
IDispatch to work with normal function calls.
> On Nov 27, 2021, at 5:03 PM, Sven Barth wrote:
>
> candidates:=tcallcandidates.create(sym:=symtableprocentry,
> st:=symtableproc,ppn:=left,
> ignorevisibility:=ignorevisibility,allowdefaultparas:=not(nf_isproperty in
> flags),objcidcall:=cnf_objc_id_call in
>
> On Nov 27, 2021, at 5:00 PM, Sven Barth wrote:
>
> The compiler does not know which routine is called upon parsing the parameter
> declarations (which would mean that error reports would need to be deferred
> until the lookup of the routine failed).
My idea was to not actually have it
> On Nov 26, 2021, at 4:20 PM, Ryan Joseph wrote:
>
> It's mainly useful when reading code so you don't need to review the function
> definition, using code tools or any other method. I've been enjoying it in
> other languages when it's not compulsory and FPC already supports the syntax
>
> On Nov 26, 2021, at 3:31 PM, Michael Van Canneyt
> wrote:
>
> That seems like a fake argument: Of course you need to look, because you need
> the names ?
> Secondly, the IDE will simply tell you what the names are when the cursor is
> on them.
It's mainly useful when reading code so you
This was discussed before some years ago with no conclusion
(https://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg46280.html)
but I'd like to bring it up again. Can we consider extending the variant
dispatch call named parameters to normal functions? The majority of the
> On Nov 9, 2021, at 1:09 PM, Sven Barth via fpc-pascal
> wrote:
>
> No, because the function that is called with a function pointer needs to be
> inlined itself (thus becoming part of its caller) so that constant
> propagation works at all for the parameters. If a function isn't inlined
> On Nov 8, 2021, at 11:20 PM, Sven Barth via fpc-pascal
> wrote:
>
> I don't know what you mean with "new function body". If a function is inlined
> its code is contained within the surrounding function and if it's not inlined
> then nothing changes.
>
I mean if in theory you were to
> On Nov 8, 2021, at 1:27 PM, Sven Barth via fpc-pascal
> wrote:
>
> And there you have it (simplified obviously). As long as the compiler can
> determine *at compile time* the code of the function (and the function is
> inlineable) it should in theory be able to inline it. This is true no
> On Nov 7, 2021, at 2:17 PM, Jonas Maebe via fpc-pascal
> wrote:
>
>> Is there anyway a function parameter could be inlined in FPC? This would go
>> a long way in helping to parameterize functions that have tight loops in
>> them.
>
> It's theoretically possible through constant
Is there anyway a function parameter could be inlined in FPC? This would go a
long way in helping to parameterize functions that have tight loops in them.
If there isn't I wonder if this is an area where the proposed "pure" function
modifier could be used to make it possible.
===
> On Nov 5, 2021, at 10:41 PM, Benjamin Rosseaux via fpc-pascal
> wrote:
>
> I'm curious to see how it compares with my vector-based UI framework stuff at
> PasVulkan ( https://youtu.be/YR0KruyQbx4 ), where the GPU itself renders
> everything by shader, where nothing is bitmap-based, if one
> On Nov 6, 2021, at 7:09 AM, James Richters via fpc-pascal
> wrote:
>
> Do I need to use the source to re-install FPC every time I want to update it?
> If so how is this accomplished?
>
You need to rebuild the compiler every time it's updated. It can installed to a
"trunk" location so
> On Nov 3, 2021, at 8:17 PM, Bart via fpc-pascal
> wrote:
>
> Maybe use SomeString.Split([LineEnding'], ...)?
> Split has an overload that takes an array of string as first paramter.
Thanks, I guess I need to use a different way to work on all platforms.
Regards,
Ryan Joseph
> On Nov 1, 2021, at 5:12 PM, Anthony Walter via fpc-pascal
> wrote:
>
> I plan to add: Write a `redmond` win95 style theme. Write a few example
> custom controls. Add modal window support and dialog box functions.
>
How are you doing themes? I made a MacOS 8 theme by slicing up tons of
> On Oct 31, 2021, at 4:57 PM, Anthony Walter via fpc-pascal
> wrote:
>
> As mentioned before, this library will be released to a git repository soon
> with a FOSS license. It will be able to run on Windows, Mac, Linux, and Pi
> including the new Pi Zero 2 W.
>
Thanks, please post when
> On Oct 31, 2021, at 2:53 PM, Jonas Maebe via fpc-pascal
> wrote:
>
> The compiler itself does enable them by the default on any platform. However,
> the fpc.cfg file that gets installed with FPC on all platforms does enable
> them by default (it contains -Sgic). Compile with -vt and check
> On Oct 31, 2021, at 10:50 AM, Alexander Grotewohl via fpc-pascal
> wrote:
>
> Because += is a mistake and hopefully it's irreparably broken.
>
> Does using just s:=s+';'; work?
>
I thought they were behind a mode switch called "c operators" or something but
either way I don't see why
> On Oct 29, 2021, at 2:01 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> Lazarus uses macros of the form $(LazarusDir) .
>
> Did you check the fpc path in Lazarus?
> Tools / Options / Environment
So what happened here is that I as a new user on Windows decided I needed the
compiler
Sorry I didn't look up high enough in the output to see this before. It looks
like lazbuild can't find the correct version of the compiler that is packaged.
I can confirm that path exists but I think the variable $Lazarusdir may be
wrong.
What could be wrong here? I got Lazarus via an
> On Oct 29, 2021, at 4:25 AM, Anthony Walter via fpc-pascal
> wrote:
>
> Thanks for the interest Ryan. I am preparing to push my code to a public git
> repository with a FOSS license. In order to get this out soon it will be
> broken into a few releases.
Nice let us know when it's
> On Oct 28, 2021, at 9:39 PM, Dennis Lee Bieber via fpc-pascal
> wrote:
>
> Are you actually running on a 32-bit system? You appear to have
> installed a 32-bit compiler.
I think I may have downloaded the 32 bit version of the compiler and then the
64 bit Lazarus! That would make
> On Oct 16, 2021, at 5:18 AM, Anthony Walter via fpc-pascal
> wrote:
>
> Source code for the test scene is included on that page. If you want to help,
> I need to bounce ideas off people as well as test on Raspberry Pi, Mac, and
> Windows. Message me and maybe we can try to meet on a
I'm trying to build a Lazarus project on Windows and I've ran into a problem.
Since I barely know Windows all I have known to do is download the latest
version of the compiler and Lazarus then install them via their installers. I
expected then to be able to use lazbuild like I do on macOS but I
> On Aug 21, 2021, at 3:09 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> As in Delphi 'reference to' will also be used for all references where an
> anonymous functon can be used. But you can perfectly use methods and local
> functions for that. So it will function a like a catch-all
> On Aug 21, 2021, at 1:30 PM, Michael Van Canneyt
> wrote:
>
> "Reference to" can be used for the others as well.
How do you mean? Reference to is currently only available for cblocks on macOS
I think so I'm not sure how this would look.
Regards,
Ryan Joseph
> On Aug 21, 2021, at 12:08 PM, Jonas Maebe via fpc-pascal
> wrote:
>
> You can pass global functions to "is nested" procvars, so at least these
> two don't need to be separate.
>
> OTOH, there's another type: cblocks :)
So up to 4 types are needed: "is nested", "of object" and "reference
FPC has a number of function pointer types and eventually will have another in
"reference to" closures. This presents a problem of how the programmer can make
a function that is type agnostic so that we can use different types of
callbacks.
Currently this is the best solution I can think of
> On Jul 15, 2021, at 8:33 PM, Dennis Lee Bieber via fpc-pascal
> wrote:
>
> https://flylib.com/books/en/3.126.1.111/1/
>
> """
> Only writes below PIPE_BUF bytes in size are guaranteed to be atomic.
> PIPE_BUF is 512 bytes on Mac OS X. The fpathconf() system call can be used
> to retrieve
> On Jul 15, 2021, at 3:07 PM, Marco van de Voort via fpc-pascal
> wrote:
>
> Not of TProcess as far as I know, it probably depends on the OS pipe
> implementation and maybe the granularity that the processes that you run
> outputs data. (buffers its I/O iow calls write() in 512 byte
I have some code the basically does:
while bytesRead > 0 do
bytesRead := process.Output.Read(buffer^, kBufferSize);
but bytesRead is only ever 512 per call to Read.
Is this a system imposed limit or something that's part of TProcess? Setting
kBufferSize to anything larger than 512 has
> On Jul 10, 2021, at 11:18 AM, Jonas Maebe via fpc-pascal
> wrote:
>
> A constexpr function means that it must be computable at compile time if
> all of its arguments are also constexpr.
So like the "pure" functions that Gareth was working on? Seems to have moved on
from the idea but I
> On Jul 9, 2021, at 4:56 PM, Ryan Joseph wrote:
>
>> Current standings at the time of this video
>> Iterations per sec:
>> Ada: 67
>> Pascal: 143
>> Fastest language: 7301
>> Slowest language: 1
>
> So Pascal failed pretty bad it looks like. ;)
I just ran that unit with -O2 and got nearly
> On Jul 10, 2021, at 4:16 AM, Guillermo via fpc-pascal
> wrote:
>
> Hi,
>
> I remember years ago a similar test in a web page. Pascal was way low
> in the list, even below Java and Python! but we (in a forum) found that
> it wasn't Pascal fault: most versons program were optimised in code
> On Jul 9, 2021, at 11:40 AM, Wayne Sherman via fpc-pascal
> wrote:
>
> Current standings at the time of this video
> Iterations per sec:
> Ada: 67
> Pascal: 143
> Fastest language: 7301
> Slowest language: 1
So Pascal failed pretty bad it looks like. ;)
Regards,
Ryan Joseph
Is it possible something like this could work? Seems like it should but I get
an error (got MyRecord expected variant).
{$mode objfpc}
program unit_name;
type
TTuple = array of variant;
type
MyRecord = record
end;
var
t: TTuple;
r: MyRecord;
> On Jun 13, 2021, at 11:35 PM, Sven Barth via fpc-pascal
> wrote:
>
> I have not looked at your test case yet, but it *might* be related to issue
> #37164 ( https://bugs.freepascal.org/view.php?id=37164 ).
His tests didn't have an enumerator and for..in loop like in that bug report so
I'm
> On Jun 13, 2021, at 7:48 AM, denisgolovan via fpc-pascal
> wrote:
>
> Could anybody reply?
>
> Am I doing something wrong?
> Are management operators supported or not?
Maybe reduce the test down to a smaller footprint and isolate the memory leak?
That would be helpful to knowing what may
> On Jun 1, 2021, at 5:05 PM, Henry Vermaak wrote:
>
> https://en.wikipedia.org/wiki/Option_type
Yeah just use Nullable then since it sounds like that's the closest we're
going to get in FPC.
Regards,
Ryan Joseph
___
fpc-pascal maillist
> On Jun 1, 2021, at 12:56 PM, denisgolovan wrote:
>
> That would limit supported types to class instances.
> I'll like to avoid that.
> Ideally TOption type should allow any type (primitives, strings, objects,
> class instances, etc).
What are you trying to make that requires a variant
> On Jun 1, 2021, at 12:20 PM, denisgolovan via fpc-pascal
> wrote:
>
> Hi all
>
> I am trying to implement Option type in FPC.
>
> type
> generic TOption = record
>case IsSome:boolean of
>true: ( some: T );
>false: ();
> end;
You need to use a constraint like:
type
generic
> On May 12, 2021, at 4:00 PM, Sven Barth wrote:
>
> There's also Oxygene as one of the current ones.
>
Oh that's right, that's a pretty cool one. I hope once closures are finished we
can use them to implement async/await like Oxygene or JavaScript. :)
Regards,
Ryan Joseph
> On May 12, 2021, at 12:30 PM, Ralf Quint via fpc-pascal
> wrote:
>
> Thought this was kind of interesting, though it leaves short of mentioning
> the later Object Pascal evolution and thus Delphi and FreePascal...
Isn't Free Pascal and Delphi basically the only Pascal compilers left? I
> On Apr 29, 2021, at 11:22 PM, Sven Barth wrote:
>
> Well, there should *at least* be a warning and an error if range checks are
> enabled... Please file a bug report.
https://bugs.freepascal.org/view.php?id=38829
Regards,
Ryan Joseph
Is this a bug in properties and I should be getting an error?
type
TPixel = record
components: array[0..3] of byte;
property R: byte read components[10] write components[10];
end;
Regards,
Ryan Joseph
___
> On Apr 29, 2021, at 12:01 AM, Sven Barth wrote:
>
> To be precise there are two more: function/procedure variables (no special
> designator) and method variables ("of object"). Depending on what a anonymous
> function captures (or for the sake of it a nested function) it would be
>
> On Apr 28, 2021, at 10:43 AM, Graeme Geldenhuys via fpc-pascal
> wrote:
>
> Couldn't such verbose syntax be limited to {$mode delphi} behaviour,
> and then leave {$mode objfpc} free to experiment and introduce new
> less verbose syntax in the language.
Sven is having none of this and for
> On Apr 27, 2021, at 11:36 PM, Sven Barth wrote:
>
> Anyway, it would in principle be possible to convert an anonymous function to
> a "is nested" function, but that will only come *after* the whole
> implementation is here so that the chance for messing that core functionality
> (!) up is
> On Apr 27, 2021, at 2:23 PM, Ryan Joseph wrote:
>
> But why would it do that when we could use an alternate code path that uses
> nested functions instead? Maybe I'm not being clear but we can do BOTH
> depending the situation when one is better than the other. This is just an
>
> On Apr 27, 2021, at 9:58 AM, Michael Van Canneyt
> wrote:
>
> Wait.
>
> I asked Sven to make sure that nested functions are under ALL circumstances
> usable as closures or can be used instead of anonymous functions.
>
> Pas2js already supports this, and I want FPC and Pas2JS to be
> On Apr 20, 2021, at 3:10 PM, Sven Barth wrote:
>
> If you look at TFPSMap' code you'll see that BinaryCompareKey and
> BinaryCompareData are only used in the way of method pointers OnKeyPtrCompare
> and OnDataPtrCompare. In TFPGMap<,> these are then set to compare methods
> specific to
I have a question I was just curious about. From what I can tell TFPGMap uses
CompareByte to compare keys of arbitrary type, which is clever but how does
this work for ShortStrings? I have tried to use this method myself and I find
it always fails because short strings have garbage at the end
> On Apr 18, 2021, at 11:28 PM, Sven Barth wrote:
>
> Nowadays: backwards compatibility.
backwards compatibility strikes again. :)
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> On Apr 18, 2021, at 5:00 AM, Sven Barth wrote:
>
> As I have said: Delphi compatibility.
This would have been a good candidate to put behind the delphi mode switch but
I'm sure there is a reason for this also.
Regards,
Ryan Joseph
___
> On Apr 17, 2021, at 3:09 PM, Sven Barth wrote:
>
> The compiler will generate a warning in case you instantiate a class that is
> abstract or has abstract methods. You can escalate these warnings to errors
> if you need:
It's probably not practical to put that warning into all potential
> On Apr 17, 2021, at 1:07 PM, Graeme Geldenhuys via fpc-pascal
> wrote:
>
> Hi
>
> I'm looking at the wiki and official FPC language documentation. What was
> the reason for the decision to make the FPC syntax so verbose regarding
> Generics?
There is a plan to make these optional via a
From the documentation: "An abstract class is a class that cannot be
instantiated directly. Instead, a descendent class must always be instantiated.
However, for Delphi compatibility, the compiler ignores this directive."
Why does this get ignored and what does this have to do with Delphi? I
1 - 100 of 421 matches
Mail list logo
