> 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 RT
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 GetBi
> 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 - f
> 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 calling
> 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 sai
> 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 alloc
> 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 I
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 becau
> 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 i
> 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 but
> 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.:
function
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 execu
> 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 maill
> 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 stay
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 remo
> 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 p
> 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 main
> 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.
Here's
> 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 chan
> 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 ad
> 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 lik
> 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 don
> 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 st
> 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 e
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.
https://gitlab.com/gener
> 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 best
> 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 insta
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 kin
> 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,
R
> 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 pa
> 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.
Regards,
> 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
> callnodeflags,explicitunit:=c
> 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 affe
> 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
> so
> 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 do
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
infrastructur
> 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 the
> 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 inl
> 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 m
> 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 propagatio
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.
===
t
> 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 i
> 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 th
> 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 old
> 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 it
> 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 Win
> 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 firs
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 installer
> 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 finishe
> 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 sen
> 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 Discor
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 pro
> 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 to
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 but
> 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 th
> 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 incre
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 n
> 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 thou
> 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;
i
> 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 reco
> 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 use
> 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
___
fpc
> 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
> possibl
> 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 go
> 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 4:53 PM, Graeme Geldenhuys via fpc-pascal
> wrote:
>
> Why must the anonymous function repeat all that information again,
> as shown in the quoted code above? Can't the compiler figure all
> that out simply by inference? All the developer should have to do
> is give the 2
> 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
> optimizati
> On Apr 27, 2021, at 2:17 PM, Sven Barth via fpc-pascal
> wrote:
>
> It will *always* create an interface. It's just how the compiler will wrap it.
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 B
> 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 compatib
> 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 the
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 an
> 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
https://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
___
fp
> 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 fi
1 - 100 of 424 matches
Mail list logo
