Re: [fpc-pascal] Feature announcement: Dynamic array extensions
Am 25.05.2018 um 08:42 schrieb Ryan Joseph: On May 25, 2018, at 1:02 PM, Sven Barth via fpc-pascalwrote: 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
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
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 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 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
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
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 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
Maciej Izakschrieb 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
Ryan Josephschrieb 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
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?
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?
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
> 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
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
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
Ryan Josephschrieb 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
Michael Van Canneytschrieb 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
> 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
On Fri, May 25, 2018 at 8:42 AM, Ryan Josephwrote: > 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
On Fri, 25 May 2018, Ryan Joseph wrote: On May 25, 2018, at 1:06 PM, Michael Van Canneytwrote: 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
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
> 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
> 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
Ryan Josephschrieb 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
On Fri, 25 May 2018, Ryan Joseph wrote: On May 25, 2018, at 12:43 PM, Michael Van Canneytwrote: 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
Ryan Josephschrieb 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