Re: [fpc-pascal] Management operators question

2018-05-25 Thread Ryan Joseph


> 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; var dest: TDynArray);
>  
> and 
> 
> class operator AddRef(var a: TDynArray);
> 
> 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 7FFEEFBFF828
dealloc 7FFEEFBFF828
push 1 to 7FFEEFBFF828 <—— here’s where I’m confused

type
generic TDynArray = 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;
var
d: TIntArray;
begin
d := TIntArray.Create([1, 2, 3]);
d.Push(100);
end;

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


Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Management operators question

2018-05-25 Thread 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 >:


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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Management operators question

2018-05-25 Thread Tomas Hajny
On Fri, May 25, 2018 17:27, Maciej Izak wrote:
> 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


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Management operators question

2018-05-25 Thread Maciej Izak
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 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Management operators question

2018-05-25 Thread Maciej Izak
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?
* 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Management operators question

2018-05-25 Thread Ryan Joseph


> 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; var dest: TDynArray);
>  
> and 
> 
> class operator AddRef(var a: TDynArray);
> 
> 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Management operators question

2018-05-25 Thread Tomas Hajny
On Fri, May 25, 2018 15:16, Maciej Izak wrote:
> 2018-05-25 14:44 GMT+02:00 Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org>:
 .
 .
> 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Management operators question

2018-05-25 Thread Tomas Hajny
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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Management operators question

2018-05-25 Thread Maciej Izak
2018-05-25 14:44 GMT+02:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Management operators question

2018-05-25 Thread Sven Barth via fpc-pascal
Maciej Izak  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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Management operators question

2018-05-25 Thread Maciej Izak
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; var dest: TDynArray);

and

class operator AddRef(var a: TDynArray);

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Management operators question

2018-05-25 Thread 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 = 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;
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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal