Management operators question

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Management operators question

Ryan Joseph
Talking about dynamic arrays I was just curious if we could us the new management operators to make dynamic arrays that are managed on the stack.

Here’s a quick demo I typed up but I don’t understand why the init/dealloc count isn’t balanced. Calling the constructor seems to be the culprit, but why?    

type
        generic TDynArray<T> = record
                private type TDynArrayTable = array[0..0] of T;
                private type TDynArrayTablePtr = ^TDynArrayTable;
                private
                        table: TDynArrayTablePtr;
                public
                        constructor Create (values: array of T);
                        procedure Push(value: T);
                        class operator Finalize(var a: TDynArray);
                        class operator Initialize(var a: TDynArray);
        end;

constructor TDynArray.Create (values: array of T);
var
        value: T;
begin
        for value in values do
                Push(value);
end;

class operator TDynArray.Initialize(var a: TDynArray);
begin
        writeln('init');
        a.table := nil;
end;

class operator TDynArray.Finalize(var a: TDynArray);
begin
        FreeMem(a.table);
        a.table := nil;
        writeln('dealloc');
end;

procedure TDynArray.Push(value: T);
begin
        if table = nil then
                table := GetMem(0);
        writeln('push ', value); // grow array etc...
end;

procedure TestDynArray;
type
        TIntArray = specialize TDynArray<Integer>;
var
        d: TIntArray;
begin
        d := TIntArray.Create([1, 2, 3]);
        d.Push(100);
end;

========

init
init
dealloc
push 1
push 2
push 3
push 100
dealloc
dealloc




Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Management operators question

Maciej Izak
2018-05-25 12:19 GMT+02:00 Ryan Joseph <[hidden email]>:
Here’s a quick demo I typed up but I don’t understand why the init/dealloc count isn’t balanced. Calling the constructor seems to be the culprit, but why? 

all is balanced :) you forgot to handle operator :

class operator Copy(constref src: TDynArray<T>; var dest: TDynArray<T>);
 
and 

class operator AddRef(var a: TDynArray<T>);

for the line from example "d := TIntArray.Create([1, 2, 3]);" the "Copy" operator is executed (you need to check when which operator is used - this is the best way to learn, on the beginning it may looks a bit complicated): so for each AddRef, Copy and Initialization the Finalization operator is executed.

anyway you should not use management operators in FPC trunk, the work is discontinued on the trunk and may be removed (not my fault - for one person in FPC core with admin rights, emotional personal revenge and victimization is more important than work and future of Pascal).

The management operators feature has not yet full potential, some related things are not finished (for example FastRTTI to speed up all managed types usage), all of my work will be continued in NewPascal.org project (default field/property, new management operators, bug fixes for some problems, smart pointers).

In the case of any questions you can use mORMot forum, sorry for inconvenience! :(

NOTE: also rtl-generics/Generics.Collections is discontinued in trunk, so any new collections, bug fixes and related compiler fixes can be found in NewPascal and in https://github.com/maciej-izak/generics.collections (for now it works for trunk and 3.0.4 but may stops to work with tunk/3.0.4 at some point).

NOTE 2: I have hope at some point to merge back all my patches and features with official FPC trunk.

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Management operators question

Free Pascal - General mailing list
Maciej Izak <[hidden email]> schrieb am Fr., 25. Mai 2018, 14:03:
anyway you should not use management operators in FPC trunk, the work is discontinued on the trunk and may be removed (not my fault - for one person in FPC core with admin rights, emotional personal revenge and victimization is more important than work and future of Pascal).

Would you please stop spreading such nonsense? No one - not even Michael - said anything about removing it.

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Management operators question

Maciej Izak
2018-05-25 14:44 GMT+02:00 Sven Barth via fpc-pascal <[hidden email]>:
Would you please stop spreading such nonsense? No one - not even Michael - said anything about removing it.

Spreading such nonsense? Nobody can be sure anything (for me it looks like Michael has absolute power on the project - finally Michael was involved in a "conflict" and was both: judge and executioner for my ban without any communication). Not directly, but Michael said :

"A bunch of changes are introduced, things are rammed through our throat which we didn't ask for and then we're told "this is the price for progress'."

even you were against when patch for management operators was ready, so it is not nonsense. The MO is not the part of official release and it exist only in trunk, so potentially still may be removed. Just 1 + 1 calculation. The work is discontinued and MO without further work / other features is not fully usefully so removing MO from trunk seems for me like rational step. Am I wrong in some point? If yes then please explain me :).

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Management operators question

Tomas Hajny-2
In reply to this post by Maciej Izak
On Fri, May 25, 2018 14:03, Maciej Izak wrote:
 .
 .
> anyway you should not use management operators in FPC trunk, the work is
> discontinued on the trunk and may be removed (not my fault - for one
> person in FPC core with admin rights, emotional personal revenge and
> victimization is more important than work and future of Pascal).
 .
 .

The sentence above is not appropriate, please adjust your communication
and stop blaming people for revenge, etc. You'll receive an official
statement to the previous events from the FPC core team during the
weekend. Also, note that this is a FPC mailing list, not a 'NewPascal'
mailing list - make sure your posts are on-topic with regard to FPC.

Thanks

Tomas
(one of FPC mailing lists moderators)


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Management operators question

Tomas Hajny-2
In reply to this post by Maciej Izak
On Fri, May 25, 2018 15:16, Maciej Izak wrote:
> 2018-05-25 14:44 GMT+02:00 Sven Barth via fpc-pascal <
> [hidden email]>:
 .
 .
> even you were against when patch for management operators was ready, so it
> is not nonsense. The MO is not the part of official release and it exist
> only in trunk, so potentially still may be removed. Just 1 + 1
> calculation. The work is discontinued and MO without further work / other
> features is not fully usefully so removing MO from trunk seems for me like
> rational step. Am I wrong in some point? If yes then please explain me :).

I assume that the functionality added to trunk (and as far as I remember
also announced in the list) was finished to the extent that it works and
may be used (although with some possible limitations), otherwise there
would be no sense in adding it to trunk at all. As such, it's as supported
as any other part of FPC (i.e. bug reports and feature requests may be
created, etc.). If it doesn't work and noone can fix it, it might be
removed (as with any other unfinished and not working feature), but I
don't have any information about this. Could we focus the discussion to
real problems, if necessary, rather then speculations?

Thanks

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Management operators question

Ryan Joseph
In reply to this post by Maciej Izak


> On May 25, 2018, at 7:03 PM, Maciej Izak <[hidden email]> wrote:
>
> all is balanced :) you forgot to handle operator :
>
> class operator Copy(constref src: TDynArray<T>; var dest: TDynArray<T>);
>  
> and
>
> class operator AddRef(var a: TDynArray<T>);
>
> for the line from example "d := TIntArray.Create([1, 2, 3]);" the "Copy" operator is executed (you need to check when which operator is used - this is the best way to learn, on the beginning it may looks a bit complicated): so for each AddRef, Copy and Initialization the Finalization operator is executed.
>
> anyway you should not use management operators in FPC trunk, the work is discontinued on the trunk and may be removed (not my fault - for one person in FPC core with admin rights, emotional personal revenge and victimization is more important than work and future of Pascal).

So I need to keep a ref count in the record to balance the calls? I think I get what you’re saying but I’ll try it tomorrow.

I have no idea what’s happening with this drama but hopefully it cools down so you don’t have to remove features or abandon work. Personally I think they’re a great feature and have lots of potential.


Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Management operators question

Maciej Izak
In reply to this post by Tomas Hajny-2
2018-05-25 15:58 GMT+02:00 Tomas Hajny <[hidden email]>:
The sentence above is not appropriate, please adjust your communication
and stop blaming people for revenge, etc. You'll receive an official
statement to the previous events from the FPC core team during the
weekend. Also, note that this is a FPC mailing list, not a 'NewPascal'
mailing list - make sure your posts are on-topic with regard to FPC.

Ok, thanks :). Let me just say few more things related to your message and let me to ask few small questions. 

* Is that mean that any messages about MSELang or about NewPascal is forbidden in this mailing list?
* Sorry if my statement about revenge is untrue, but this is look like this. Why one of FPC core developer can say everything in public place in not appropriate way? 
* Is there any consequence for Michael?

My work was consulted with Michael, he was happy with FastRTTI and after few months he says about my work in very roughly way (the patch and all details was the same so I don't understand this).

* How any other person outside core team can contribute to FPC project? It seems impossible, even when you do all with "FPC core" requirements and with full consultation, point by point at the end you need to read :

"A bunch of changes are introduced, things are rammed through our throat which we didn't ask for and then we're told "this is the price for progress'."

this is just for FastRTTI. The same situation happens for management operators, at the end of road, patch for MO feature was almost rejected in the similar way (maybe not in roughly way)

Is that normal in all open source project? (no irony here I have just no idea).

I have hope that official statement will explain all things. I am waiting for any concrete message almost since month.

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Management operators question

Maciej Izak
In reply to this post by Tomas Hajny-2
2018-05-25 16:10 GMT+02:00 Tomas Hajny <[hidden email]>:
I assume that the functionality added to trunk (and as far as I remember
also announced in the list) was finished to the extent that it works and
may be used (although with some possible limitations), otherwise there
would be no sense in adding it to trunk at all. As such, it's as supported
as any other part of FPC (i.e. bug reports and feature requests may be
created, etc.). If it doesn't work and noone can fix it, it might be
removed (as with any other unfinished and not working feature), but I
don't have any information about this. Could we focus the discussion to
real problems, if necessary, rather then speculations?

Sorry if any part of my message sounds like speculation. Is really hard to say anything without communication with core team (almost no communication - just ban). I was asking/talking in more private or public places but almost no one was interested to write any concrete reply.

I am always trying to act like professional, sometimes it is hard :). For sure removing MO from trunk is not good for me and means more work on my side for NewPascal, but the main goal of MO was introduction of smart pointers, nullable types and simplified ARC objects. Also in this context FastRTTI is very important, more extensive usage of smart pointers/nullable types/arc objects mean much faster final code. Every element is related: FastRTTI , MO and all smart pointers variants. So removing MO from trunk has sense if FastRTTI is not finished or smart pointers are not planned in near time.

If any of the core member is interested to finish this (FastRTTI, smart pointers, etc) I will be very happy, finally core has many more talented programmers than me. If someone other will finish this I will be happy too (finally the end effect will be good or even better for whole community).

Also the good solution may be to remove temporary MO from trunk, I can finish this in NewPascal (maybe I will be able to create more end-user friendly form, so temporary may be good to not break backward-compatibility) and we can talk how to merge things back.

I am always opened to any cooperation. For less frustration for both sides would be good to keeps both projects alive. I can continue NewPascal with my ideas and vision but at the same time I see no reason why FPC should not benefit from my work in less "neuralgic" code parts. If the core will change opinions about new features from NewPascal (I can also change any features or re-implement any of feature if FPC core wish that) any of feature can be merged back into FPC trunk. IMO this path is beneficial for all. In the worst scenario I will "burn out" (which is not planned by me) but in general FPC will be better.

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Management operators question

Alexander Grotewohl

I don't really know why this NewPascal stuff is on this mailing list.


On 05/25/2018 11:59 AM, Maciej Izak wrote:
2018-05-25 16:10 GMT+02:00 Tomas Hajny <[hidden email]>:
I assume that the functionality added to trunk (and as far as I remember
also announced in the list) was finished to the extent that it works and
may be used (although with some possible limitations), otherwise there
would be no sense in adding it to trunk at all. As such, it's as supported
as any other part of FPC (i.e. bug reports and feature requests may be
created, etc.). If it doesn't work and noone can fix it, it might be
removed (as with any other unfinished and not working feature), but I
don't have any information about this. Could we focus the discussion to
real problems, if necessary, rather then speculations?

Sorry if any part of my message sounds like speculation. Is really hard to say anything without communication with core team (almost no communication - just ban). I was asking/talking in more private or public places but almost no one was interested to write any concrete reply.

I am always trying to act like professional, sometimes it is hard :). For sure removing MO from trunk is not good for me and means more work on my side for NewPascal, but the main goal of MO was introduction of smart pointers, nullable types and simplified ARC objects. Also in this context FastRTTI is very important, more extensive usage of smart pointers/nullable types/arc objects mean much faster final code. Every element is related: FastRTTI , MO and all smart pointers variants. So removing MO from trunk has sense if FastRTTI is not finished or smart pointers are not planned in near time.

If any of the core member is interested to finish this (FastRTTI, smart pointers, etc) I will be very happy, finally core has many more talented programmers than me. If someone other will finish this I will be happy too (finally the end effect will be good or even better for whole community).

Also the good solution may be to remove temporary MO from trunk, I can finish this in NewPascal (maybe I will be able to create more end-user friendly form, so temporary may be good to not break backward-compatibility) and we can talk how to merge things back.

I am always opened to any cooperation. For less frustration for both sides would be good to keeps both projects alive. I can continue NewPascal with my ideas and vision but at the same time I see no reason why FPC should not benefit from my work in less "neuralgic" code parts. If the core will change opinions about new features from NewPascal (I can also change any features or re-implement any of feature if FPC core wish that) any of feature can be merged back into FPC trunk. IMO this path is beneficial for all. In the worst scenario I will "burn out" (which is not planned by me) but in general FPC will be better.

--
Best regards,
Maciej Izak


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Management operators question

Tomas Hajny-2
In reply to this post by Maciej Izak
On Fri, May 25, 2018 17:27, Maciej Izak wrote:

> 2018-05-25 15:58 GMT+02:00 Tomas Hajny <[hidden email]>:
>
>> The sentence above is not appropriate, please adjust your communication
>> and stop blaming people for revenge, etc. You'll receive an official
>> statement to the previous events from the FPC core team during the
>> weekend. Also, note that this is a FPC mailing list, not a 'NewPascal'
>> mailing list - make sure your posts are on-topic with regard to FPC.
>>
>
> Ok, thanks :). Let me just say few more things related to your message and
> let me to ask few small questions.
>
> * Is that mean that any messages about MSELang or about NewPascal is
> forbidden in this mailing list?

They may be relevant when making comparisons (when prompted to do so by
one of the users, etc.), but not for announcements / "PR" messages. Feel
free to use fpc-other for that.


> * Sorry if my statement about revenge is untrue, but this is look like
> this. Why one of FPC core developer can say everything in public place in
> not appropriate way?

Nobody should use inappropriate languague in the mailing list, full stop.
I'm not aware of a 'FPC core developer' doing so but if this happens, I'll
send a moderation message as well - feel free to send me a private e-mail
about such cases if I miss them.


> * Is there any consequence for Michael?
 .
 .

This question is not on-topic and no discussion should be held about it in
this list. If you persist on discussing it in one of the FPC mailing lists
(rather than waiting for the promised summary), use fpc-other.


 .
 .
> * How any other person outside core team can contribute to FPC project? It
> seems impossible, even when you do all with "FPC core" requirements and
> with full consultation, point by point at the end you need to read :
 .
 .

As witnessed by all the contributions incorporated to the FPC source code,
it is certainly possible.


 .
 .
> Is that normal in all open source project? (no irony here I have just no
> idea).

Yes, it is. Any open source project needs some kind of management,
otherwise it results in a disaster. Noone guarantees that each and every
contribution will be incorporated. As you certainly know, you are free to
fork the project (it's an open source) and try to manage your fork better.
But then it is not the original project any longer.


> I have hope that official statement will explain all things. I am waiting
> for any concrete message almost since month.

We are all working on FPC in our free time as a hobby. There are no SLAs
with guaranteed response times.

Please, make sure not to respond to this message in this mailing list, no
further reactions would belong here.

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Management operators question

Ryan Joseph
In reply to this post by Maciej Izak


> On May 25, 2018, at 7:03 PM, Maciej Izak <[hidden email]> wrote:
>
> all is balanced :) you forgot to handle operator :
>
> class operator Copy(constref src: TDynArray<T>; var dest: TDynArray<T>);
>  
> and
>
> class operator AddRef(var a: TDynArray<T>);
>
> for the line from example "d := TIntArray.Create([1, 2, 3]);" the "Copy" operator is executed (you need to check when which operator is used - this is the best way to learn, on the beginning it may looks a bit complicated): so for each AddRef, Copy and Initialization the Finalization operator is executed.
>

I expanded the example but there’s still one thing I don’t get. How can it be that Initialize/Finalize are called in a pair then push is called directly after? I expected Finalize to be the final call before the the object is out of scope and not usable anymore. If I was keeping reference counts I would already be at 0 when the first push call was made.


init 00007FFEEFBFF828
dealloc 00007FFEEFBFF828
push 1 to 00007FFEEFBFF828 <—— here’s where I’m confused

type
        generic TDynArray<T> = record
                private type TDynArrayTable = array[0..0] of T;
                private type TDynArrayTablePtr = ^TDynArrayTable;
                private
                        table: TDynArrayTablePtr;
                public
                        constructor Create (values: array of T);
                        procedure Push(value: T);
                        class operator Finalize(var a: TDynArray);
                        class operator Initialize(var a: TDynArray);
                        class operator AddRef(var a: TDynArray);
                        class operator Copy(constref aSrc: TDynArray; var aDst: TDynArray);
        end;

constructor TDynArray.Create (values: array of T);
var
        value: T;
begin
        for value in values do
                Push(value);
end;

class operator TDynArray.AddRef(var a: TDynArray);
begin
        writeln('addref');
end;

class operator TDynArray.Copy(constref aSrc: TDynArray; var aDst: TDynArray);
begin
        writeln('copy ', HexStr(@aSrc), ' to ', HexStr(@aDst));
end;

class operator TDynArray.Initialize(var a: TDynArray);
begin
        writeln('init ', HexStr(@a));
        a.table := nil;
end;

class operator TDynArray.Finalize(var a: TDynArray);
begin
        if a.table <> nil then
                begin
                        FreeMem(a.table);
                        writeln('free');
                        a.table := nil;
                end;
        writeln('dealloc ', HexStr(@a));
end;

procedure TDynArray.Push(value: T);
begin
        if table = nil then
                table := GetMem(0);
        writeln('push ', value, ' to ', HexStr(@self)); // grow array etc...
end;

procedure TestDynArray;
type
        TIntArray = specialize TDynArray<Integer>;
var
        d: TIntArray;
begin
        d := TIntArray.Create([1, 2, 3]);
        d.Push(100);
end;

init 00007FFEEFBFF7C0
init 00007FFEEFBFF828
dealloc 00007FFEEFBFF828
push 1 to 00007FFEEFBFF828
push 2 to 00007FFEEFBFF828
push 3 to 00007FFEEFBFF828
copy 00007FFEEFBFF828 to 00007FFEEFBFF7C0
push 100 to 00007FFEEFBFF7C0
free
dealloc 00007FFEEFBFF828
free
dealloc 00007FFEEFBFF7C0


Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal