> 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 Wed, 19 Jan 2022, Ryan Joseph via fpc-pascal wrote:
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
no
> 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 Wed, 19 Jan 2022, Ryan Joseph via fpc-pascal wrote:
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 h
> 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
Am 19.01.2022 um 02:48 schrieb Ryan Joseph via fpc-pascal:
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 mes
> 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
Am 17.01.2022 um 13:58 schrieb Ryan Joseph via fpc-pascal:
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:
writ
> 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
Ryan Joseph via fpc-pascal schrieb am
Mo., 17. Jan. 2022, 08:53:
>
>
> > 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 wh
> 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
Ryan Joseph via fpc-pascal schrieb am
Mo., 17. Jan. 2022, 02:38:
>
>
> > 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 value
> 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
Am 16.01.2022 um 15:25 schrieb Ryan Joseph via fpc-pascal:
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 wor
> 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
On 16-1-2022 14:18, Ryan Joseph via fpc-pascal wrote:
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
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 Sun, 16 Jan 2022, Ryan Joseph via fpc-pascal wrote:
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...
They are.
> 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 Sat, 15 Jan 2022, Ryan Joseph via fpc-pascal wrote:
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 branc
> 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
On Sat, 15 Jan 2022, Ryan Joseph 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 S
30 matches
Mail list logo
