Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Sven Barth via fpc-pascal]

Am 25.05.2018 um 08:42 schrieb Ryan Joseph:



On May 25, 2018, at 1:02 PM, Sven Barth via fpc-pascal 
 wrote:

Yes, that is what it does. Though a possible optimization would be that the compiler detects 
"dynarr := dynarr + [elem]" and converts it to "Insert(elem, dynarr, 
High(dynarr))”.

100%


FPC now optimizes "dynarr := dynarr + [elem]" to "Insert(elem, dynarr, 
high(sizeint))" and "dynarr := [elem] + dynarr" to "Insert(elem, dynarr, 
0)".


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

[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

[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

[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

[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

[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

[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

[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

[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] Feature announcement: Dynamic array extensions

[Sven Barth via fpc-pascal]

Ryan Joseph  schrieb am Fr., 25. Mai 2018,
12:45:

>
>
> > On May 25, 2018, at 3:57 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > If I had to guess you were probably doing something with the arrays they
> weren't designed for. :/
> >
>
> It’s a little foggy now but I think I had a dynamic array in a class which
> was being passed around some functions or the class (with the dynamic
> array) was in a record which was being passed around some functions. I
> think this was happening within tight loops also.
>
> Bottom line is if the that thread lock function does anything expensive
> then passing around dynamic arrays within tight loops could be a deal
> breaker unless you could manually declare a dynamic array as not thread
> safe.
>

When passing around dynamic arrays in such situations var and constref
parameters should be used and assignments inside those loops should be
avoided.

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

[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

Re: [fpc-pascal] Libxml2 - How to get messages on Linux?

[Henry Vermaak]

On Fri, May 25, 2018 at 12:48:20PM +0200, Gabor Boros wrote:
> 2018. 05. 24. 9:37 keltezéssel, Michael Van Canneyt írta:
> >Are these functions callbacks ? If so, is the calling convention correct ?
> 
> I used xmlSchemaSetValidErrors and the documentation say "Set the error and
> warning callback informations". Tried with and without cdecl.

These functions use varargs, so the calling convention is different:

https://www.freepascal.org/docs-html/ref/refsu87.html

I thought it only works with external code, though.  Would be useful if
the documentation mentioned anything.

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

Re: [fpc-pascal] Libxml2 - How to get messages on Linux?

[Gabor Boros]

2018. 05. 24. 9:37 keltezéssel, Michael Van Canneyt írta:

Are these functions callbacks ? If so, is the calling convention correct ?



I used xmlSchemaSetValidErrors and the documentation say "Set the error 
and warning callback informations". Tried with and without cdecl.


Meanwhile tried xmlSchemaSetValidStructuredErrors and that works with 
Win32, Win64 and Linux 64bit.


Is libxml package have a maintainer or is it a legacy/deprecated thing? 
I experienced some differences between the documentation of libxml2 and 
the "Interfaces for validating" section in xmlschemas.inc.


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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Ryan Joseph]

> On May 25, 2018, at 3:57 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> If I had to guess you were probably doing something with the arrays they 
> weren't designed for. :/
> 

It’s a little foggy now but I think I had a dynamic array in a class which was 
being passed around some functions or the class (with the dynamic array) was in 
a record which was being passed around some functions. I think this was 
happening within tight loops also.

Bottom line is if the that thread lock function does anything expensive then 
passing around dynamic arrays within tight loops could be a deal breaker unless 
you could manually declare a dynamic array as not thread safe.

Regards,
Ryan Joseph

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

[fpc-pascal] 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 = 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

[fpc-pascal] -gw3 produces garbages

[Mr Bee via fpc-pascal]

Hi all,
The `-gw3` with `godwarfcpp` flag for lldb produces garbages for string type or 
any dynamic array types. While `-gw2` only works on string but still failed on 
any dynamic array types.
Is there a way or configuration so we can debug string and dynamic array with 
lldb conveniently?
I'm using fpc 3.0.2 with lldb 360.1.70 on macos 10.11.6 (el-capitan).
Thank you.

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Sven Barth via fpc-pascal]

Ryan Joseph  schrieb am Fr., 25. Mai 2018,
10:24:

>
>
> > On May 25, 2018, at 3:18 PM, Michael Van Canneyt 
> wrote:
> >
> > I'm guessing you are not using strings either then, for performance
> reasons ? Because exactly the same happens there.
>
> really? I had a collection class with a dynamic array for the storage and
> that’s when I got the high CPU usage in the thread safe stuff. I replaced
> the storage with a pointer to a block of memory which I managed myself and
> the problem went away. I just wanted to a dynamic array that was fast,
> minimal and could append elements.
>
> I use lots of strings but I never had that problem. Are strings reference
> counted like dynamic arrays? I thought a string was just an array of 255
> chars.
>

ShortString is limited to 255 chars. AnsiString and UnicodeString don't
have that limitation and they are reference counted just like dynamic
arrays.

The type of "String" depends on the current settings:
- $H-: String = ShortString (this is the default for all modes except the
Delphi ones)
- $H+ and "$modeswitch unicodestrings-": String = AnsiString (or
AnsiString(CP_ACP) to be precise) (this is the default for mode Delphi)
- $H+ and "$modeswitch unicodestrings+": String = UnicodeString (this is
the default for mode DelphiUnicode)

If I had to guess you were probably doing something with the arrays they
weren't designed for. :/

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Sven Barth via fpc-pascal]

Michael Van Canneyt  schrieb am Fr., 25. Mai 2018,
10:15:

>
>
> On Fri, 25 May 2018, Sven Barth via fpc-pascal wrote:
>
> > Yes, that is what it does. Though a possible optimization would be that
> the
> > compiler detects "dynarr := dynarr + [elem]" and converts it to
> > "Insert(elem, dynarr, High(dynarr))".
> >
> >
> >> Since dynamic array helpers work could you expose a function that adds
> an
> >> element to the array (an grows it if needed) so we could make helpers
> for
> >> it? Pushing a value to an array is perhaps the most common function used
> >> for lists so it makes sense to get that right imo.
> >>
> >
> > That function already exists and is called Insert() (see above).
>
> Nice. I didn't know Insert() could be used to append to the end of a
> string.
>
> One learns every day ! One for the documentation :-)
>
> To be clear: for strings you can do
>
> var
>S : String;
>
> begin
>S:='123';
>Insert('456',S,Length(S)+2);
>Writeln(S);
> end.
>
> and it will append. Is the same true for dynamic arrays ?
> i.e. any insert position >= length will do an append ?
>

Correct :)

Similar for indices <= 0: they will always prepend (for strings <= 1 of
course).

Regards,
Sven

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Ryan Joseph]

> On May 25, 2018, at 3:18 PM, Michael Van Canneyt  
> wrote:
> 
> I'm guessing you are not using strings either then, for performance reasons ? 
> Because exactly the same happens there.

really? I had a collection class with a dynamic array for the storage and 
that’s when I got the high CPU usage in the thread safe stuff. I replaced the 
storage with a pointer to a block of memory which I managed myself and the 
problem went away. I just wanted to a dynamic array that was fast, minimal and 
could append elements.

I use lots of strings but I never had that problem. Are strings reference 
counted like dynamic arrays? I thought a string was just an array of 255 chars.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Bart]

On Fri, May 25, 2018 at 8:42 AM, Ryan Joseph  wrote:
> Oh Insert on the last element works like Push. There really should be a 
> Push/append etc.. function in there. I know it’s redundant but doing
>
> Insert(arr, High(arr), value) is more work than Push(arr, value) and it’s not 
> clear if we can add this ourselves easily without making tons of overloads.

Add() would sound more logical to me then.

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Michael Van Canneyt]

On Fri, 25 May 2018, Ryan Joseph wrote:





On May 25, 2018, at 1:06 PM, Michael Van Canneyt  wrote:

Dynamic arrays are reference counted. The interlocked increment is there to
make the operations thread safe. I do not know whether the classes you speak
of are thread safe. If there is no FPC_INTERLOCKEDINCREMENT64, most likely
they are not.

Dynamic arrays have their reason for existence. For one thing, they are a 
continuous block
in memory, properly aligned and whatnot. The collection classes make no such
guarantees.


I made my own class because I wanted to guarantee nothing silly was going on 
behind the scenes. I didn’t need thread safe so opting out of all the extra 
work done to make them safe is important sometimes. That would be nice if you 
could do the same with dynamic arrays honestly.


I'm guessing you are not using strings either then, for performance reasons ? 
Because exactly the same happens there.


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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Michael Van Canneyt]

On Fri, 25 May 2018, Sven Barth via fpc-pascal wrote:


Yes, that is what it does. Though a possible optimization would be that the
compiler detects "dynarr := dynarr + [elem]" and converts it to
"Insert(elem, dynarr, High(dynarr))".



Since dynamic array helpers work could you expose a function that adds an
element to the array (an grows it if needed) so we could make helpers for
it? Pushing a value to an array is perhaps the most common function used
for lists so it makes sense to get that right imo.



That function already exists and is called Insert() (see above).


Nice. I didn't know Insert() could be used to append to the end of a string.

One learns every day ! One for the documentation :-)

To be clear: for strings you can do

var
  S : String;

begin
  S:='123';
  Insert('456',S,Length(S)+2);
  Writeln(S);
end.

and it will append. Is the same true for dynamic arrays ? 
i.e. any insert position >= length will do an append ?


Michael.

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Ryan Joseph]

> On May 25, 2018, at 1:02 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> Yes, that is what it does. Though a possible optimization would be that the 
> compiler detects "dynarr := dynarr + [elem]" and converts it to "Insert(elem, 
> dynarr, High(dynarr))”. 

100%

> 
> 
> Since dynamic array helpers work could you expose a function that adds an 
> element to the array (an grows it if needed) so we could make helpers for it? 
> Pushing a value to an array is perhaps the most common function used for 
> lists so it makes sense to get that right imo.
> 
> That function already exists and is called Insert() (see above). 
> 

Oh Insert on the last element works like Push. There really should be a 
Push/append etc.. function in there. I know it’s redundant but doing 

Insert(arr, High(arr), value) is more work than Push(arr, value) and it’s not 
clear if we can add this ourselves easily without making tons of overloads.


Regards,
Ryan Joseph

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Ryan Joseph]

> On May 25, 2018, at 1:06 PM, Michael Van Canneyt  
> wrote:
> 
> Dynamic arrays are reference counted. The interlocked increment is there to
> make the operations thread safe. I do not know whether the classes you speak
> of are thread safe. If there is no FPC_INTERLOCKEDINCREMENT64, most likely
> they are not.
> 
> Dynamic arrays have their reason for existence. For one thing, they are a 
> continuous block
> in memory, properly aligned and whatnot. The collection classes make no such
> guarantees.

I made my own class because I wanted to guarantee nothing silly was going on 
behind the scenes. I didn’t need thread safe so opting out of all the extra 
work done to make them safe is important sometimes. That would be nice if you 
could do the same with dynamic arrays honestly.

> 
>> 
>> The procedural syntax of Insert(arr, 0, value) is less enticing than 
>> arr.Insert(0, value) also but again we can fix that with type helpers.
> 
> Arrays are not objects. They do not have methods.
> 
> I understand where the tendency to make everything an object comes from
> but the basic pascal types (including dynamic arrays) have always been handled
> procedurally. Nothing wrong with that. I often write small programs
> procedurally.
> 
> And that is why type helpers exist, to tack on an object-like approach.

Agreed but sometimes we like to just type arr.insert() because it’s faster or 
more consistent with other code. I suspect FPC users are already making their 
own type helper wrappers for this.

One of the worst things I’ve encountered recently is C# forcing EVERYTHING to 
be a class. Total nightmare.


Regards,
Ryan Joseph

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Sven Barth via fpc-pascal]

Ryan Joseph  schrieb am Fr., 25. Mai 2018,
07:55:

> The procedural syntax of Insert(arr, 0, value) is less enticing than
> arr.Insert(0, value) also but again we can fix that with type helpers.
>

You are overestimating what type helpers are capable of doing for dynamic
arrays - see my remark about named types and matching types in my first
reply to you.

Regards,
Sven

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Michael Van Canneyt]

On Fri, 25 May 2018, Ryan Joseph wrote:





On May 25, 2018, at 12:43 PM, Michael Van Canneyt  
wrote:

I think the above is "right", and completely equivalent to sets, which are in 
some ways
like an array: a "collection" of same typed values.

To add an element to a set you also do
 MySet:=MySet+[aValue];

That said, sets do have
 Include(MySet,AValue);
to include a single value.

Maybe this syntax can be extended to dynamic arrays.


We can do + operator overloads on array classes though so it’s not totally 
crazy to see this syntax in code. Ultimately if it’s optimized well doing [xx] 
is no big problem I suppose.

Having said that my feeling with dynamic arrays is that they’re more
difficult to use than collection classes and lack basic functionality
(until perhaps just now) so why use them?  I just got burned really bad by
some call to FPC_INTERLOCKEDINCREMENT64 from dynamic arrays which killed
performance (who knows why) so I had to pull them out of all my code just
in case.


Dynamic arrays are reference counted. The interlocked increment is there to
make the operations thread safe. I do not know whether the classes you speak
of are thread safe. If there is no FPC_INTERLOCKEDINCREMENT64, most likely
they are not.

Dynamic arrays have their reason for existence. For one thing, they are a 
continuous block
in memory, properly aligned and whatnot. The collection classes make no such
guarantees.



The procedural syntax of Insert(arr, 0, value) is less enticing than 
arr.Insert(0, value) also but again we can fix that with type helpers.


Arrays are not objects. They do not have methods.

I understand where the tendency to make everything an object comes from
but the basic pascal types (including dynamic arrays) have always been handled
procedurally. Nothing wrong with that. I often write small programs
procedurally.

And that is why type helpers exist, to tack on an object-like approach.

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Sven Barth via fpc-pascal]

Ryan Joseph  schrieb am Fr., 25. Mai 2018,
04:35:

>
>
> > On May 25, 2018, at 1:37 AM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > This is currently not supported. And to avoid backwards compatibility
> problems with existing operator overloads you'd probably need to convert it
> to a dynamic array first:
> >
> > === code begin ===
> >
> > a += ['foo'];
> >
> > === code end ===
>
> What is that doing being the scenes? If it’s creating a whole new array
> and appending it then it’s probably pretty inefficient and hopefully can be
> optimized away.
>

Yes, that is what it does. Though a possible optimization would be that the
compiler detects "dynarr := dynarr + [elem]" and converts it to
"Insert(elem, dynarr, High(dynarr))".


> Since dynamic array helpers work could you expose a function that adds an
> element to the array (an grows it if needed) so we could make helpers for
> it? Pushing a value to an array is perhaps the most common function used
> for lists so it makes sense to get that right imo.
>

That function already exists and is called Insert() (see above).

Regards,
Sven

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