Re: [fpc-pascal] Bit manipulation helpers
> 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 the flags are OR'd together into an LongWord? A type helper would be great because clearly this stuff is hard to remember. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bit manipulation helpers
> 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 RTL
since I can never remember the syntax "Value = (Value or Index)"
function TestFlag(Value: QWord; Index: Byte): Boolean;
begin
result := Value = (Value or Index);
end;
const
KMOD_LCTRL = $0040;
KMOD_RCTRL = $0080;
var
flags: LongWord;
begin
flags := KMOD_LCTRL + KMOD_RCTRL;
writeln('TestBit: ', flags.TestBit(KMOD_LCTRL));
writeln('TestFlag: ', TestFlag(flags, KMOD_LCTRL));
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Bit manipulation helpers
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 GetBit (from the last link) in the RTL? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Caller agnostic procedure variables
> 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 - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Caller agnostic procedure variables
> 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 function is entered the interface is allocated? I know
that's how it works for the case when state is captured but I think you're
saying this is happening any time a function reference is assigned to, even if
there is no state captured. Just trying to get an understanding of the runtime
cost to use these.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Caller agnostic procedure variables
> 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 > begin > end; > end; "However assigning a nested function variable to a function reference is much harder. Assigning a function reference to a nested function variable is hard as well. " This means if you expanded your example with: var n: TFoobarNested; begin f := n; THAT would be hard? I've never passed around nested function vars before so I don't really know the limitations of this. The important thing is the primary use case works. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Caller agnostic procedure variables
> 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 function variable is hard as well. > I'm getting lost with the terms now I think. If your function takes a function reference parameter and you assign it a nested function pointer, this is difficult? I believe this was Michaels request in that code snippet. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Caller agnostic procedure variables
> 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 said > interface. So in the end what can be assigned to a function reference depends > on the compiler being able to generate suitable implementations. So when you assign a global function to a function reference it has to generate a new function body? I guess that makes sense on how it can "capture" these different types of functions. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Caller agnostic procedure variables
> 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 clear to me so I'll wait for Sven to answer on that.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Caller agnostic procedure variables
> 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 allocations, but that would be a future > optimization. > So if we do this there is nothing being captured right? In that case we get an interface which can call a function pointer? Does the interface then know about "of object" and "is nested" types at all or does it use a totally different mechanism to call those? type TMyAction = reference to procedure; procedure MyAction; begin end; procedure Test; begin DoThis(@MyAction); end; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Caller agnostic procedure variables
> 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 "is nested"?
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Caller agnostic procedure variables
> 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
knew I asked in passing before.
So "reference to procedure" are going to be the new standard? To extend my
example it would look like this? I please remind me, is there a closure
involved which is capturing state and adding overhead?
I'm curious what this type actually is also, maybe a dispatch table which wraps
the existing types or is it something totally new?
type
TMyAction = reference to procedure;
procedure DoThis(action: TMyAction);
begin
action();
end;
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Caller agnostic procedure variables
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 because
generics don't support variable templates (like some languages have
TClass) it was limited and clunky to use.
The problem is that from the perspective of the receiver it shouldn't really
care what the caller has provided except for that there is a procedure that
needs to be called. For example if there is a "sort" function that takes a
procedure variable it shouldn't care if the procedure is a global function, a
method or a nested function (and eventually a closure).
It feels like the compiler needs a new type which encapsulates these different
types but I'm not sure how this all works internally. Any thoughts on this?
===
{$mode objfpc}
program procvars;
type
TMyAction = procedure;
TMyClass = class
procedure MyAction;
end;
procedure DoThis(action: TMyAction);
begin
action();
end;
procedure MyAction;
begin
end;
procedure Test;
procedure MyNestedAction;
begin
end;
var
c: TMyClass;
begin
// of object
c := TMyClass.Create;
DoThis(@c.MyAction); // error: Incompatible type for arg no. 1: Got
"", expected
""
// is nested
DoThis(@MyNestedAction); // error: Incompatible type for arg no. 1: Got
"", expected
""
// normal
DoThis(@MyAction);
end;
begin
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
> 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] $PASCALMAINNAME error with SDL/IPhone
> 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 if you're interested) but I don't have much hope because this could > be Pascal related and they won't know anything about this. Btw, here is the stack trace of my crash. Why is PASCALMAIN still there if I renamed it to SDL_main? Shouldn't that have changed? Thread 1 Queue : com.apple.main-thread (serial) #0 0x7fff2554864d in -[UIScrollView _adjustedContentOffsetForContentOffset:skipsAdjustmentIfScrolling:] () #1 0x7fff25548f5d in -[UIScrollView _adjustContentOffsetIfNecessary] () #2 0x7fff2551f4d7 in -[UIScrollView setFrame:] () #3 0x7fff25588cb3 in UIViewCommonInitWithFrame () #4 0x7fff25588672 in -[UIView initWithFrame:] () #5 0x7fff2551b093 in -[UIScrollView initWithFrame:] () #6 0x7fff25373471 in -[UIFieldEditor initWithTextField:] () #7 0x7fff25392007 in -[UITextField _fieldEditor] () #8 0x7fff25393d14 in -[UITextField _inputController] () #9 0x7fff2538b5bc in -[UITextField setTextAlignment:] () #10 0x7fff2538b742 in -[UITextField setDefaultTextAttributes:] () #11 0x7fff2537d554 in __55-[UITextField _initWithFrame:textLayoutManagerEnabled:]_block_invoke () #12 0x7fff25587486 in +[UIView _performSystemAppearanceModifications:] () #13 0x7fff2537d3da in -[UITextField _initWithFrame:textLayoutManagerEnabled:] () #14 0x0001094b87f9 in -[SDL_uikitviewcontroller initKeyboard] at /Users/ryanjoseph/Developer/SDL2-2.0.20/src/video/uikit/SDL_uikitviewcontroller.m:272 #15 0x0001094b7f01 in -[SDL_uikitviewcontroller initWithSDLWindow:] at /Users/ryanjoseph/Developer/SDL2-2.0.20/src/video/uikit/SDL_uikitviewcontroller.m:95 #16 0x0001094c7541 in SetupWindowData at /Users/ryanjoseph/Developer/SDL2-2.0.20/src/video/uikit/SDL_uikitwindow.m:145 #17 0x0001094c7152 in UIKit_CreateWindow at /Users/ryanjoseph/Developer/SDL2-2.0.20/src/video/uikit/SDL_uikitwindow.m:221 #18 0x00010952fff0 in SDL_CreateWindow at /Users/ryanjoseph/Developer/SDL2-2.0.20/src/video/SDL_video.c:1718 #19 0x000108c1ee6d in PASCALMAIN () #20 0x000108c4194c in FPC_SysEntry () #21 0x000108c1ed92 in FPC_SYSTEMMAIN () Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] $PASCALMAINNAME error with SDL/IPhone
> 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 then crashes. I've reported to SDL at
https://discourse.libsdl.org/t/crash-in-uitextfield/34711 (along with my
program if you're interested) but I don't have much hope because this could be
Pascal related and they won't know anything about this.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] $PASCALMAINNAME error with SDL/IPhone
> 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 main(argc: integer; argv: pchar): integer; cdecl; public; https://stackoverflow.com/questions/11976084/why-sdl-defines-main-macro states that SDL wants to rename your main function to SDL_main so that it can use its own main function (main I assume) which then calls out to your main function. I had old code from 2016 which appears to do this but for some reason now I'm getting this linker error. My only guess is that the linker can't find the SDL main function in the framework, even though everything else links properly. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] $PASCALMAINNAME error with SDL/IPhone
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 executable
(maybe you meant: _SDL_main)
Why is this?
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Macro expanding error
> 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
have been smart also.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Macro expanding error
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 maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 my own fork. Totally not what I expected when I pressed "create merge request" Oh well here is the correct merge request. https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/147 However, now it says I need to rebase anyways so my original attempt must have not been right. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 I started working on it? > Let me know if that's ok like it is. > > https://gitlab.com/genericptr/free-pascal/-/merge_requests/1 > 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? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 this way now? > > Problem is I go to push the changes to the my remote feature branch and I get > this error: > > error: failed to push some refs to > 'https://gitlab.com/genericptr/free-pascal.git' > hint: Updates were rejected because the tip of your current branch is behind > hint: its remote counterpart. Integrate the remote changes (e.g. > hint: 'git pull ...') before pushing again. > hint: See the 'Note about fast-forwards' in 'git push --help' for details. > > A pull didn't help but I think I basically broke that branch and maybe I need > to delete it and start over? 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 I started working on it? Let me know if that's ok like it is. https://gitlab.com/genericptr/free-pascal/-/merge_requests/1 Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
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 remote feature branch and I get
this error:
error: failed to push some refs to
'https://gitlab.com/genericptr/free-pascal.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
A pull didn't help but I think I basically broke that branch and maybe I need
to delete it and start over?
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 provide exact steps. :)
https://stackoverflow.com/questions/2472254/when-should-i-use-git-pull-rebase
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 and then make my pull request? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 Sorry I'm not following. Before starting this branch I did a pull from the main branch so I'm up to date. What other steps do I need to do? If I do a "git pull --rebase" on the feature branch does that even do anything? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 my issue and feature branch linked + tests. Please leave any comments since I wasn't 100% sure in a few places. https://gitlab.com/freepascal.org/fpc/source/-/issues/39535 Now that the compiler is moved to GitLab do you prefer merge requests? I assumed no and that it would clutter up the system but I'll make a merge request if you want. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 changes every time the program reloads (as expected) so how do you use a constant memory address which would map to this? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 advance of doing tcasenode.pass_1, which
could presumably get this address in some integer form. Is that basically what
you're thinking is possible?
If it's a big problem I guess the question is if the if blocks are really that
bad compared to alternative ( I would need to basically redo the entire thing
also).
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 like this then? and if so, this is better then doing
the if-statement block, like string case statements?
case PtrUInt(o.ClassType.ClassInfo) of
PtrUInt(TObject.ClassInfo): writeln('TObject');
end;
Question then is how you get the VMT address as a constant at compile time.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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't think that exists so unless it does we need to do equality
comparisons for each case.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 statement instead of making a big if-else block and doing equality
comparisons for each type. That would be faster right?
Assuming the memory address of the type worked you could do something like this
behind the scenes:
case PtrUInt(o.ClassType) of
4500656856: writeln('TObject');
end;
If so, I would have to rethink this then and come back to it later.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 exist in the list. It's an incomplete code snippet but if the class was another type it would be captured there of course. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
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/genericptr/free-pascal/-/commits/case_label_classref
Here's an example of what I did. To keep it simple you use "ClassType" to
branch off of possible class types.
o := TInterfacedObject.Create;
case o.ClassType of
TObject: writeln('TObject');
TInterfacedObject: writeln('TInterfacedObject');
TAggregatedObject: writeln('TAggregatedObject');
otherwise
writeln('OTHER: ',o.ClassName);
end;
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 option.
Anyways, the case statement in FPC allows for strings which basically fold down
into an if-else statement for comparing strings and this same logic could be
expanded for class types. Seems like a smart extension to add but does the
compiler team support this?
Something like this:
case o.ClassType of
TObject: writeln('TObject');
TInterfacedObject: writeln('TInterfacedObject');
end;
Converts to:
if o.ClassType = TObject then
writeln('TObject')
else if o.ClassType = TInterfacedObject then
writeln('TInterfacedObject');
There is a possibility for using "as" operator also though
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case statement for class introspection
> 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 instance is at run
>> time.
>
> I think Scala did it before Swift.
What did it look like? Seems like an obvious feature any OOP language should
have.
Swift has a compound switch statement which does lots of things. It's a little
messy but it accomplishes this well. For example here they have a "case is" and
"case let _ as" which tests for class type or casts to a local variable using
"as".
switch object {
case is Message:
break
case let content as MessageContent:
break
case let attachment as Attachment:
break
default: break
}
Problem for Pascal is how to handle the casting mess. C languages (and Delphi
now I guess) can do inline variable declarations to avoid the casting.
Come to think of it this a similar problem with for-loops where you want to
loop over a collection of only certain types. For example:
for monster in monsters do
if monster is TZenChan then
TZenChan(monster).Dothis;
Swift does something similar as the switch which would look kind of like this:
for case monster as TZenChan in monsters do
TZenChan(monster).Dothis;
That syntax is not so nice but I like they're trying to help us manage class
introspection using existing language constructs.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Case statement for class introspection
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 kind of clumsy though since you can't declare scoped variables in Pascal so you would need to do lots of casts but it's still cleaner than the equivalent code as if statements. = case monster of TZenChan: TZenChan(monster).DoThis; TPulPul: TPulPul(monster).DoThat; otherwise monster.DoSomething; end; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC and WebAssembly
> 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,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> 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 sense for a language like Pascal. > >> Yes I understand that the overloading happens after parsing. In your first >> example if arbitrary order was allowed new overloading rules would need to >> be applied so that you got an ambiguous function error. Not a big deal to >> resolve that I would think but it doesn't have to go in that direction >> either. >> >> Personally I'm not in favor or changing the overloading rules, just that >> some calls were easier to read by glancing over them. In fact I have seen >> IDEs which have a feature which inserts the param name into the editor for >> this very reason. > > You still don't get it. This is not about "changing the overloading rules" > but about this feature fitting into the existing overload selection > functionality. No I really do understand what the situation is if you can believe me. I don't see this is a big problem or too complicated to tackle but if you really dislike the idea so much then we'll leave it at that. There's more important potential features to work on anyways. btw kind of off topic did you like my idea of default properties for records so we can implement smart pointers? I got a good chunk of that done months ago but never heard anything about it... Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> 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 parameters aren't used for named ones as well, this gets more > complicated if the overloads have different argument names). > > You should have already learned this lesson when I pointed you in the right > direction for the implicit function specializations. > I'm not proposing we necessarily allow the reordering of arguments or allow omitting of values. In the simplest scenario they're just optional names but the parameters still need to be provided in the correct order. Very simply to make reading long functions easier at the call site. Yes I understand that the overloading happens after parsing. In your first example if arbitrary order was allowed new overloading rules would need to be applied so that you got an ambiguous function error. Not a big deal to resolve that I would think but it doesn't have to go in that direction either. Personally I'm not in favor or changing the overloading rules, just that some calls were easier to read by glancing over them. In fact I have seen IDEs which have a feature which inserts the param name into the editor for this very reason. As an aside, is it even useful to allow arbitrary parameter order? I don't recall ever wanting this and would open the door to some functions being called in different order across a codebase, which sounds like a big problem unto itself (C# allows this btw). Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> 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, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> 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:=cnf_unit_specified in > callnodeflags,searchhelpers:=callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], > anoninherited:=cnf_anon_inherited in callnodeflags,spezcontext:=spezcontext); > > So you've gained *nothing*. I wouldn't say nothing but it's still really hard to read. My only thought there was that it would open the door for some syntax coloring on the parameter name so you can scan them easier. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> 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 affect overloading except in the case where the param names don't match which would ignore the call (so in your example below nothing changes). Otherwise if the name was actually part of the overloading we would have to allow functions with the same parameter type but different names, i.e.: procedure Foo(Arg1: String = ''); procedure Foo(Arg2: String = ''); and that would be a big change to the language and have all sorts of implications. So it's really just a minor hint to make the call more readable in the case of long function names. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> 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 I thought it would be low hanging fruit.
I wanted to add a little case study from the compiler itself to see how to make
some really long function more readable.
1) Original form (the compiler doesn't use spaces between punctuation). Very
difficult to read if nothing else because the lack of spaces but it's also not
clear at all which params are which. Even code tools are going to not help very
much unless they can hilight the parameters in the editor. Either way you're
going to be spending time try to figure this one out.
candidates:=tcallcandidates.create(symtableprocentry,symtableproc,left,ignorevisibility,
not(nf_isproperty in flags),cnf_objc_id_call in
callnodeflags,cnf_unit_specified in callnodeflags,
callnodeflags*[cnf_anon_inherited,cnf_inherited]=[],cnf_anon_inherited in
callnodeflags,spezcontext);
2) Adding some line breaks helps a lot but it's still not clear what some of
the params are unless you jump to the function definition or get a tool tip on
the constructor and then even so you need to count the params to see which is
which, and this takes time and effort.
candidates:=tcallcandidates.create(symtableprocentry,
symtableproc,
left,
ignorevisibility,
not(nf_isproperty
in flags),
cnf_objc_id_call in
callnodeflags,
cnf_unit_specified
in callnodeflags,
callnodeflags*[cnf_anon_inherited,cnf_inherited]=[],
cnf_anon_inherited
in callnodeflags,
spezcontext);
3) Clearly defined names each on their own line is obviously the easiest to
read at a glance. Even if no line breaks were present the editor could style
the param names a different color and they would be easy to read.
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:=cnf_unit_specified in callnodeflags,
searchhelpers:=callnodeflags*[cnf_anon_inherited,cnf_inherited]=[],
anoninherited:=cnf_anon_inherited in callnodeflags,
spezcontext:=spezcontext);
4) For contrast here's a bad example of named params which we want to avoid.
Languages like Swift encourage this kind of thing and I think it's less
readable and adds clutter.
pt := MakePoint(x:= 1, y := 2); // cluttered and doesn't add any useful
information
pt := MakePoint(1, 2);// normal calling syntax, easy to read
and clean
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> 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 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 I thought it would be low hanging fruit. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Named optional arguments
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 infrastructure is already there so it needs to merely be extended. This is what the syntax would look like: SetupCanvas(width := 500, height := 500, eventCallback := @HandleCanvasEvents, options := [TCanvasOption.VSync]); The reason for this is of course to handle functions with many parameters so we don't need to look at the function definition to know which params mean what thing. C# has effectively added optional named parameters along with other languages I use and I consider this a solid development at this point. My complaints come with languages like Swift where the parameter names are meant to be part of the function signature and really clutter up the language in my opinion so I'd like to avoid that by making it opt-in, like C#. The basic idea: - Opt-in design so if you name the first parameter in a function all following parameters must be named, and the inverse, if the first parameter is not named the following parameters can not be named either. - Consider the parameter name during overloading resolution so that even if the values are correct the names must match also. - Enabled with a mode switch? - Parameters can be specified in any order? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inline function parameters
> 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 then > there won't be any change and the passed in function variable will be called > as usual. I mean in theory if the compiler were to support inlining function pointers that is how it could be done. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inline function parameters
> 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 inline that function variables code into the function it would need to generate a new function (I guess the name also, so the entire thing) because the function being passed in could change on per-call basis (like a normal generic function). Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inline function parameters
> 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 matter
> if it's a function variable, a method variable (pointing to a non-virtual
> method) or an anonymous function. However if somewhere between passing in the
> function address and calling the function inlining does not work for one
> reason or the other (e.g. due to open array parameters which are currently
> not supported by inlining) then the compiler obviously can't inline the
> provided function either.
Interesting, so the inlining the containing function is the key. I guess if the
container were not inlined it would basically be like a generic where a new
function body would be generated which contained the inline function pointers
body with arguments replaced.
For example:
function Map_MultBy2(aArr: TLongIntArray): TLongIntArray;
begin
SetLength(Result, Length(aArr));
for i := 0 to High(aArr) do
Result[i] := aArr[i] * 2; { MultBy2 is inlined here }
end;
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inline function parameters
> 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 propagation. I understand simple constant propagation cases but how does this apply to inlining entire functions? I think C++ can do this with closures so it's something worth looking in to for the future. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Inline function parameters
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.
===
type
TSomeFunc = function: boolean;
procedure DoThis(func: TSomeFunc);
begin
if func then
;
end;
function MyFunc: boolean; inline;
begin
end;
begin
DoThis(MyFunc);
end;
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] First Version Vector Toolkit in OpenGL
> 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 ignores the 2D > vector signed distance field textures for fonts and so on. The CPU pushes > just roughly basic draw information to the GPU, where the fragment übershader > itself applies the corresponding design look with help of 2D SDF math in an > always antialiased way then. I really like the text rendering part. I've been picking away at that problem recently and it's pretty difficult to do correctly. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Keeping current with FPC Source on gitlab
> 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 that it doesn't overwrite existing stable compiler releases. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ExtractStrings by line in Windows
> 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] First Version Vector Toolkit in OpenGL
> 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
screenshots and packing them into texture atlases then pushing them into a
sprite batcher. I wonder if making a bitmap context backend when have been
easier.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] First Version Vector Toolkit in OpenGL
> 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's up. An open question I have with OpenGL based UI libraries is how (or if) composting happens. For example, are you rendering an entire window to a frame buffer and then updating that when one of the controls requests changes, or are you just drawing the entire window and controls every frame? I made a similar UI library which is loosely based on Cocoa but I didn't use any compositing so the entire window needs to redraw itself each frame. This is good enough for basic UI's in games but it's terribly inefficient so I wanted to tackle the problem of a composition layer (frame buffer) which updates only when controls request it and update only that portion of the window. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String error on Windows
> 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 where the > compiler is getting its configuration file from. Thanks, I see -Sc now but I've always taken for granted it was always there. What confused me is that it's a command line option instead of a mode switch like other language features. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String error on Windows
> 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 Windows would disable them. They're all over my program which runs on macOS and I don't want to remove them (like that operator myself). Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazbuild error on Windows
> 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 first so I downloaded the most recent version 3.2.2. After that I wanted to use lazbuild and some Lazarus libraries so I installed that next. Problem was Lazarus uses "fpc" as the compiler path and due to the installation order that pointed to the newer version of FPC which wasn't compatible with the 3.2.0 units compiled in Lazarus. Maybe Lazarus should by default point to the version of the compiler that comes packaged with it? That would eliminate a bunch of the confusion I had and when I wanted to change the compiler version I would have had to set it explicitly myself and triggered the error but at least then I would know it was because of something I did. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazbuild error on Windows
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 so I don't know how else to set it up. PS C:\Users\Ryan Joseph\Desktop\Developer\pascal-language-server> C:\lazarus\lazbuild.exe pasls.lpi SetupCompilerFilename: The compiler path "$Lazarusdir\fpc\3.2.0\bin\i386-win32\fpc.exe" => "C:\lazarus\$Lazarusdir\fpc\3.2.0\bin\i386-win32\fpc.exe" is invalid (Error: file not found) Searching a proper one ... SearchCompilerCandidates Value=$Lazarusdir\fpc\3.2.0\bin\i386-win32\fpc.exe File=C:\lazarus\$Lazarusdir\fpc\3.2.0\bin\i386-win32\fpc.exe SearchCompilerCandidates Value=$Lazarusdir\fpc\3.2.0\bin\i386-win32\\fpc.exe File=C:\lazarus\$Lazarusdir\fpc\3.2.0\bin\i386-win32\fpc.exe SearchCompilerCandidates Value=$Lazarusdir\fpc\3.2.0\bin\i386-win32\\fpc.exe File=C:\lazarus\$Lazarusdir\fpc\3.2.0\bin\i386-win32\fpc.exe SearchCompilerCandidates Value=fpc.exe File=C:\FPC\3.2.2\bin\i386-Win32\fpc.exe > On Oct 29, 2021, at 9:46 AM, Ryan Joseph wrote: > > I think I may have downloaded the 32 bit version of the compiler and then the > 64 bit Lazarus! That would make sense it would fail then. Let me try > downloading the correct version and I'll report back. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Writing Pascal Physics and Vectors
> 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 finished.
What I did some years ago was make a plain c wrapper around Box2D so that I
could then call it from Pascal (it was c++ originally). I think the library you
used is already C so it should be easy to call from Pascal anyways event
without the OOP wrapper. Much better than Box2D which was C++ only.
https://github.com/thealchemistguild/Box2DC
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazbuild error on Windows
> 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 sense it would fail then. Let me try downloading the correct version and I'll report back. If Lazarus installed the compiler also maybe I just need to update my paths so "fpc" points to the version in Lazarus... Thanks. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Writing Pascal Physics and Vectors
> 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 Discord channel. > Just seeing this now but this looks pretty useful. I once made a Pascal wrapper for Box2D but this looks like a better more complete solution. Do you have the Pascal unit for Chipmunk2D where we can download and try it? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Lazbuild error on Windows
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 got an error
that some file is missing.
Here's the part which fails. How could lazfileutils.pas not be found? I
actually see the .ppu file where it should be so it feels like the compiler and
the version of Lazarus are not matching or something.
Free Pascal Compiler version 3.2.2 [2021/05/15] for i386
Copyright (c) 1993-2021 by Florian Klaempfl and others
(1002) Target OS: Win32 for i386
(3104) Compiling weblaz.pas
(3104) Compiling fpideexteditorinsertfilenameunit.pas
(10001) PPU Loading
C:\lazarus\components\lazutils\lib\i386-win32\lazfileutils.ppu
(10011) PPU Source: lazfileutils.pas not found
(10011) PPU Source: lazutils_defines.inc not available
(10011) PPU Source: lazfileutils.inc not available
(10011) PPU Source: winlazfileutils.inc not available
(10028) Recompiling LazFileUtils, checksum changed for
C:\FPC\3.2.2\units\i386-win32\rtl\system.ppu
C:\lazarus\components\fpweb\fpideexteditorinsertfilenameunit.pas(37,22) Fatal:
(10022) Can't find unit LazFileUtils used by fpIDEExtEditorInsertFileNameUnit
Fatal: (1018) Compilation aborted
Error: C:\FPC\3.2.2\bin\i386-Win32\ppc386.exe returned an error exitcode
Error: (lazarus) Compile package weblaz 1.0: stopped with exit code 1
Error: (lazarus) [TLazPackageGraph.CompileRequiredPackages] "Exit code 1"
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better way to handle callback types
> 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 procedural type. > > When Sven is done with the anonymous methods, you'll see it in action. But isn't this going to make the interface wrapper and allocate a class? Maybe Sven can explain how that works. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better way to handle callback types
> 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Better way to handle callback types
> 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" (for cblocks and eventually closures). Ouch. This is certainly a mess and results in tons of boiler plate for functions that use callbacks. Shouldn't the compiler have a meta-type like I made? We should be able to write a single function which takes a callback and then have the compiler figure out which type is provided on the caller side. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Better way to handle callback types
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 it's still a real mess
and tedious to setup. Here's a little snippet of a list class that has a Sort
method.
It feels to me like the compiler needs a new type which wraps all the callbacks
for us but maybe there's a better way?
type
generic TSList = class
type
TComparator = record
private type
TFuncProc = function (constref left, right: T; context: pointer):
integer;
TFuncNested = function (constref left, right: T; context: pointer):
integer is nested;
TFuncObject = function (constref left, right: T; context: pointer):
integer of object;
private
index: TFuncType;
public
function Call(constref left, right: T; context: pointer): integer;
case byte of
0: (proc: TFuncProc);
1: (nested: TFuncNested);
2: (obj: TFuncObject);
end;
...
procedure Sort(callback: TComparator.TFuncProc; context: pointer = nil);
procedure Sort(callback: TComparator.TFuncNested; context: pointer = nil);
procedure Sort(callback: TComparator.TFuncObject; context: pointer = nil);
end;
...
procedure TSList.Sort(callback: TComparator.TFuncProc; context: pointer);
var
comparator: TComparator;
begin
comparator.proc := callback;
comparator.index := TFuncType.IsProc;
{ do sorting and call comparator.Call(left, right, context); which routes to
the correct callback }
end;
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess read buffer size
> 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 the value of PIPE_BUF given a pipe descriptor. > """ > > Granted you seem to be reading -- but the other end may be what is > controlling the size of each packet (and may somehow even have set the pipe > overall size to just one "buffer"). > > Unless you can examine the writing side, or source code of your read > method... Yes I think you're right. ~$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 2784 virtual memory (kbytes, -v) unlimited It's just a PHP script that dumps 64k chunks but if the pipe buffer is 512b then I'm stuck. Is there a lower level library I can use to set the pipe size? I was curious if this is a bottle neck for me. Currently it takes about 7 seconds to read a 600MB file from one process to another, which is insanely slow. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess read buffer size
> 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 increments )
In this case the command is a PHP script that reads a file in 64k chunks and
writes the text to stdout (in PHP fread returns 64k chunks as expected).
TProcess looks like a pretty thin wrapper around pipes and common unix system
calls so I don't know where the 512 limit could come from.
How could I test this further? I think something is wrong but I don't know
where to look. I'm on macOS btw.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] TProcess read buffer size
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 no affect.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How does FPC perform in the FASTEST Computer Language Race
> 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 thought it was pretty interesting. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How does FPC perform in the FASTEST Computer Language Race
> 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 ~6000 passes on my 2020 MacBook. The C++ solution #1 got about the same. I guess that video is totally false or I'm missing something Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How does FPC perform in the FASTEST Computer Language Race
> 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
> while Pascal used brute force (also compiling using -O3 made it way
> faster than the web proclaimed so we suspect they used -O- or even
> worse a relic compiler [Turbo Pascal 1?]). Once fixed it was almost
> unoticeably behind C in both FPC and Delphi (Delphi result was a bit
> faster).
Here's the C++ version that won. Looks like the magic comes from constexpr,
which I don't understand very well in C++ except that it's a constant
expression. Can anyone explain how constexpr works here?
// ---
// PrimeCPP_CONSTEXPR.cpp : Taking advantage of compiler optimizing constants
// ---
#include
#include
#include
#include
#include
#include
#include "Sieve.h"
using namespace std;
using namespace std::chrono;
struct RESULTS
{
unsigned long long upTo;
int count;
};
constexpr RESULTS resultsDictionary[] = {
{10LL, 4}, // Historical data for validating our results - the number of
primes
{100LL, 25}, // to be found under some limit, such as 168 primes under 1000
{1000LL, 168},
{1LL, 1229},
{10LL, 9592},
{100LL, 78498},
{1000LL, 664579},
};
constexpr int find(const unsigned long long val)
{
for (const auto d : resultsDictionary)
{
if (d.upTo == val)
return d.count;
}
return -1;
}
constexpr int countPrimes(const Sieve )
{
return sieve.count();
}
constexpr bool validateResults(const Sieve )
{
const auto sieveSize = sieve.size();
const auto result = find(sieveSize);
if (-1 == result)
return false;
return result == countPrimes(sieve);
}
void printResults(const Sieve , bool showResults, double duration, int
passes, int threads)
{
const auto sieveSize = sieve.size();
if (showResults)
printf("2, ");
int count = (sieveSize >= 2); // Starting count (2 is prime)
for (int num = 3; num <= sieveSize; num += 2)
{
if (sieve.contains(num))
{
if (showResults)
printf("%d, ", num);
count++;
}
}
if (showResults)
printf("\n");
printf("Passes: %d, Time: %lf, Avg: %lf, Limit: %llu, Count1: %d, Count2:
%d, Valid: %d\n",
passes,
duration,
duration / passes,
sieveSize,
count,
countPrimes(sieve),
validateResults(sieve));
printf("\n");
printf("flo80_constexpr;%d;%f;%d;algorithm=base,faithful=no,bits=1\n",
passes, duration, threads);
}
void run(uint64_t upperLimit, const Sieve , int numberOfThreads = 1,
int runtimeSeconds = 5)
{
unsigned int passes = 0;
printf("Computing primes to %llu on %d thread%s for %d second%s.\n",
upperLimit,
numberOfThreads,
numberOfThreads == 1 ? "" : "s",
runtimeSeconds,
runtimeSeconds == 1 ? "" : "s");
const auto tStart = steady_clock::now();
while (duration_cast(steady_clock::now() - tStart).count() <
runtimeSeconds)
{
vector threadPool;
for (unsigned int i = 0; i < numberOfThreads; i++)
{
threadPool.push_back(thread([upperLimit]
{
auto sieve = Sieve(upperLimit);
sieve.runSieve();
}));
}
for (auto : threadPool)
th.join();
passes += numberOfThreads;
}
const auto tEnd = steady_clock::now();
printResults(checkSieve, false, duration_cast(tEnd -
tStart).count() / 100.0, passes, numberOfThreads);
}
int main(int argc, char **argv)
{
uint64_t upperLimit = 1'000'000L;
constexpr int runtimeSeconds = 5;
if (argc > 1)
{
upperLimit = std::max((uint64_t)atoll(argv[argc - 1]), (uint64_t)1);
assert(upperLimit < Sieve::maxSize);
}
auto checkSieve = Sieve(upperLimit);
checkSieve.runSieve();
const auto result = validateResults(checkSieve) ? checkSieve.count() : 0;
const auto numberOfThreads = thread::hardware_concurrency();
thread::hardware_concurrency();
run(upperLimit, checkSieve, numberOfThreads, runtimeSeconds);
run(upperLimit, checkSieve, 1, runtimeSeconds);
return result;
}
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How does FPC perform in the FASTEST Computer Language Race
> 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Tuples as variant arrays
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: variant;
begin
t := [1,'string', r];
for i in t do
begin
writeln(i);
end;
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Management operators memleaks
> 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 not sure. Most importantly Denis needs to isolate this into a small single program which prints out the operators like in the bug report Sven listed. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Management operators memleaks
> 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 be wrong. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Option type
> 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 - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Option type
> 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 record? I don't know what "TOption" is. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Option type
> 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 TOption = record case IsSome:boolean of true: ( some: T ); false: (); end; Not sure why though. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 50 years of Pascal, by the the author himself
> 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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 50 years of Pascal, by the the author himself
> 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 used THINK Pascal and Metrowerks Pascal in the distant past but those are all long dead. You can't really talk about Pascal in 2021 without mentioning those 2 compilers. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array range overflow in properties
> 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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Array range overflow in properties
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-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
> 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
> possible to assign it to such a type as well (for a function variable only
> global variables may be used, for a method variable additionally Self may be
> used).
As I remember the capturing code for nested functions and the new closures are
not shared. That means when the parser encounters an anonymous function it
needs to decide which type of capture it will use, right? In that case the user
may need to state that the anon function is "nested" otherwise it will use the
wrong capturing method.
>
> So once the current work is done we have 2 kinds of closures but only one of
> those is compatible with anonymous functions and this is why I want the other
> closures (nested functions) to have the same pair of functionality.
>
> Once anonymous functions are supported we can improve their compatibility
> with other constructs.
>
Great, that's what I wanted to do. It's well worth the time to get anon
functions for callbacks that return immediately, list.ForEach, list.Sort etc
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
> 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 good reason. This feature has been
collecting dust as "almost done" for years now so I would consider ourselves
lucky to get anything at all.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
> 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 reduced. Sorry I'm struggling with all these new terms myself. Yes that is what I'm proposing and what I demonstrated in that GitHub branch. We talked about this in 2018 but you said to wait until the "real thing" was finished so I let it be. I brought this up again now to say that when, and not before, the closures are finished and in trunk I will see how to integrate the "nested anonymous functions" into the new system. To clarify for myself, we have a few concepts here: - Closures: blocks which capture variables in scope and wrap them into a container (nested functions use a record I think and closures will use an interface). - Anonymous procedures: Simply an anonymous procedure/function body which lacks a name and can be declared inside code blocks. - 2 Procedure types: "reference to" and "is nested". On the caller side these are what control which kind of closure is used is used. Is that correct? So the anonymous function doesn't really become a closure until it's passed to a "reference to" or "is nested" variable. So once the current work is done we have 2 kinds of closures but only one of those is compatible with anonymous functions and this is why I want the other closures (nested functions) to have the same pair of functionality. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
> 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 > optimization that leverages existing features that are already in the > compiler anyways. Seems like a no-brainer to me. Here's what I'm proposing. Closures and nested functions should be symmetrical so that anonymous function bodies can be used without relying on the interfaces when they're not needed. type TComparator = procedure (a, b: TEntity): Integer is nested; procedure TMyClass.SortEntities(comparator: TComparator); begin end; for i := 0 to entities.Count - 1 do begin value := entities[i]; value.SortEntities(function(a, b: TEntity): integer begin // do stuff end ); end; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
> 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 compatible in > this regard. > > 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 this will be > possible. Maybe we're misunderstanding each other then. I'm responding to Sven when he says: > Getting rid of the interface only works in very narrow circumstances that are > so seldom in real world code that it is not worth the effort. I.e. all closures will be interface based because there are not enough real world use cases to support any alternative. Which is contrary to what you're saying that nested functions/closure will be compatible types. Sven can clear this up for us I guess. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How does TFPGMap key compare work?
> 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 specialization, most importantly TFPGMap<,>.KeyCompare if no
> custom compare function is set.
There's no many levels of indirection here I got confused. I see this method
below and so maybe the <> operators are overloaded for short strings?
function TFPGMap.KeyCompare(Key1, Key2: Pointer): Integer;
begin
if PKey(Key1)^ < PKey(Key2)^ then
Result := -1
else if PKey(Key1)^ > PKey(Key2)^ then
Result := 1
else
Result := 0;
end;
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] How does TFPGMap key compare work?
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 and so even if you zero out the memory (which is allocated) a short string passed as a parameter to a function will have garbage and thus fail to compare. Any ideas how this works for TFPGMap then? function TFPSMap.BinaryCompareKey(Key1, Key2: Pointer): Integer; begin Result := CompareByte(Key1^, Key2^, FKeySize); end; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Abstract classes ignored
> 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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Abstract classes ignored
> 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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Abstract classes ignored
> 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 files but a warning is still probably good enough as a reminder. It's curious though why it's not an error by default, because if the class is abstract and you instantiate it and try to use it things are going to fail anyways so why does the compiler allow it in the first place? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Background info on Generics in FPC
> 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 mode switch but it hasn't happened yet. Personally I like the "generic" keyword but the specialize keyword is annoying if you don't make a type alias (and for function calls of course). Implicit function specialization is already ready so at least we won't need to use <> at all for function calls. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Abstract classes ignored
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
personally would like for this to actually work and give a compiler error if
you instantiate the abstract class.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
