Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2018-05

Management operators question

12 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

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

Reply by email

Maciej Izak
to Ryan Joseph

2018-05-25 12:19 GMT+02:00 Ryan Joseph :

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

Reply by email

Sven Barth
to Maciej Izak

Maciej Izak schrieb am Fr., 25. Mai 2018, 14:03:

Show quoted text 5 lines
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

Reply by email

Maciej Izak
to Sven Barth

2018-05-25 14:44 GMT+02:00 Sven Barth via fpc-pascal <

Show quoted text 5 lines
: 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

Reply by email

Tomas Hajny
to Maciej Izak: 2018-05-25 12:19 GMT+02:00 Ryan Joseph : all is balanced :) you forgot to handle operator…

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)

Reply by email

Tomas Hajny
to Maciej Izak: 2018-05-25 14:44 GMT+02:00 Sven Barth via fpc-pascal < Spreading such nonsense? Nobody…
Maciej Izak wrote
2018-05-25 14:44 GMT+02:00 Sven Barth via fpc-pascal < >:

.
.

Show quoted text 6 lines
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 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

Reply by email

Ryan Joseph
to Maciej Izak: 2018-05-25 12:19 GMT+02:00 Ryan Joseph : all is balanced :) you forgot to handle operator…
Show quoted text 13 lines
On May 25, 2018, at 7:03 PM, Maciej Izak 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

Reply by email

Maciej Izak
to Tomas Hajny: . . . . The sentence above is not appropriate, please adjust your communication and stop…

2018-05-25 15:58 GMT+02:00 Tomas Hajny :

Show quoted text 6 lines
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

Reply by email

Maciej Izak
to Tomas Hajny: . . I assume that the functionality added to trunk (and as far as I remember also…

2018-05-25 16:10 GMT+02:00 Tomas Hajny :

Show quoted text 10 lines
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 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

Reply by email

Alexander Grotewohl
to Maciej Izak

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

Maciej Izak wrote 64 lines
2018-05-25 16:10 GMT+02:00 Tomas Hajny < >: 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 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 - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply by email

Tomas Hajny
to Maciej Izak: 2018-05-25 15:58 GMT+02:00 Tomas Hajny : Ok, thanks :). Let me just say few more things…
Maciej Izak wrote 14 lines
2018-05-25 15:58 GMT+02:00 Tomas Hajny : > 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

Reply by email

Ryan Joseph
to Maciej Izak: 2018-05-25 12:19 GMT+02:00 Ryan Joseph : all is balanced :) you forgot to handle operator…
Show quoted text 12 lines
On May 25, 2018, at 7:03 PM, Maciej Izak 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

Reply by email