Re: [fpc-devel] Proof of Concept ARC implementation

Am 09.10.2015 19:29 schrieb "Fabrício Srdic" : > > Any progress to ARC implementation? Not much feedback here... Also not every core developer agrees with the approach I've taken and at least with a feature as fundamental as this I'd like to have at least /some/

Re: [fpc-devel] Proof of Concept ARC implementation

Any progress to ARC implementation? Best regards ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

Here is the program I've been working on: https://bitbucket.org/hinst/sillychatIt was created with purpose of demonstrating how reference-counted objects could be used in a program which actually does something and now it works more or less. And it's beautifulಠ_ಠ Because there are no .Free calls,

Re: [fpc-devel] Proof of Concept ARC implementation

On 19.11.2014 17:29, hinsta...@yandex.ru wrote: Here is the program I've been working on: https://bitbucket.org/hinst/sillychat It was created with purpose of demonstrating how reference-counted objects could be used in a program which actually does something and now it works more or less. And

Re: [fpc-devel] Proof of Concept ARC implementation

I dunno. Just wanted to see if it is going to work with implicit exceptions turned off. I rather dance around and fix memory leaks when they appear than have implicit try-except block in every procedure. I did measurements once; found out that each try-except adds increases stack usage by

Re: [fpc-devel] Proof of Concept ARC implementation

On 20.11.2014 00:08, hinstance wrote: I dunno. Just wanted to see if it is going to work with implicit exceptions turned off. I rather dance around and fix memory leaks when they appear than have implicit try-except block in every procedure. 1. they are try-finally blocks 2. then you'll have

Re: [fpc-devel] Proof of Concept ARC implementation

I think I discovered another issue. Not sure if you are already aware of it. Don't remember it being reported before. Seems like using heaptrc feature (memory leak reporting) with refc-compiler leads to program crashing on exit. In particular, it appears that heaptrc starts reporting memory

Re: [fpc-devel] Proof of Concept ARC implementation

eh sorry; false alarm. You know how it is, when encountering a bug, you first think that it's someone else's fault)) or maybe it's just me who tends to think in such way((. It works)) 10.11.2014, 18:47, hinsta...@yandex.ru hinsta...@yandex.ru: I think I discovered another issue. Not sure if

Re: [fpc-devel] Proof of Concept ARC implementation

Not bad. I confirm that both Lazarus 1.3 and variables of refcounted type declared in another unit work now. I wanted to assemble some prototype application with refcounted objects to see how would such feature behave in a more or less complex program; but in spite of lack of free time I am

Re: [fpc-devel] Proof of Concept ARC implementation

Am 05.11.2014 21:55 schrieb hinsta...@yandex.ru: Not bad. I confirm that both Lazarus 1.3 and variables of refcounted type declared in another unit work now. Good to know :) I wanted to assemble some prototype application with refcounted objects to see how would such feature behave in a more

Re: [fpc-devel] Proof of Concept ARC implementation

On 31.10.2014 15:31, Sven Barth wrote: Am 30.10.2014 11:34 schrieb hinsta...@yandex.ru mailto:hinsta...@yandex.ru hinsta...@yandex.ru mailto:hinsta...@yandex.ru: okay sorry for spamming the mailing list So basically the other problem I reported before (generic + refcounted does not work)

Re: [fpc-devel] Proof of Concept ARC implementation

On 30.10.2014 11:00, hinsta...@yandex.ru wrote: Even if line numbers are slightly different, you can easily find the place where exception is raised: in jitforms.pp: in procedure GetVMTVirtualMethodOffset: raise Exception.Create('GetVMTVirtualMethodOffset Parent Virtual Method not found'); I

Re: [fpc-devel] Proof of Concept ARC implementation

Am 31.10.2014 06:05 schrieb Hans-Peter Diettrich drdiettri...@aol.com: Sven Barth schrieb: On 30.10.2014 04:14, Hans-Peter Diettrich wrote: I wonder how difficult it would be to implement the existing Interface refcounting model for TObject, so that this runtime variation could be tested

Re: [fpc-devel] Proof of Concept ARC implementation

Am 30.10.2014 11:34 schrieb hinsta...@yandex.ru hinsta...@yandex.ru: okay sorry for spamming the mailing list So basically the other problem I reported before (generic + refcounted does not work) turns out to be something different: Declaring variable of refcounted type in a different unit

Re: [fpc-devel] Proof of Concept ARC implementation

Am 30.10.2014 11:01 schrieb hinsta...@yandex.ru hinsta...@yandex.ru: I managed to acquire some additional information on Lazarus 1.3 + FPC ARC edition problem First of all, I tested if Lazarus 1.3 trunk compiled with FPC trunk works correctly. It does. However, Lazarus 1.3 trunk with FPC ARC

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: On 28.10.2014 10:15, Michael Schnell wrote: On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote: Something like ShortString and AnsiString? Only that ShortStrings can easily be avoided (AFAIK, no great performance advantage to use them) and hence are seldom used right

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: On 28.10.2014 10:19, Michael Schnell wrote: On 10/27/2014 07:59 PM, Sven Barth wrote: - in code that does not use ARC (modeswitch arc off - the default; or maybe better a local directive) all instance variables are considered weak While I do have a vision what weak means

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: On 28.10.2014 09:57, Hans-Peter Diettrich wrote: Something like ShortString and AnsiString? Take unit Typinfo for example where quite some methods take a TObject instance. The TypInfo methods can determine the exact type of their arguments, and act inside

Re: [fpc-devel] Proof of Concept ARC implementation

On 30.10.2014 04:16, Hans-Peter Diettrich wrote: Sven Barth schrieb: On 28.10.2014 10:19, Michael Schnell wrote: On 10/27/2014 07:59 PM, Sven Barth wrote: - in code that does not use ARC (modeswitch arc off - the default; or maybe better a local directive) all instance variables are

Re: [fpc-devel] Proof of Concept ARC implementation

On 30.10.2014 00:28, ListMember wrote: On 2014-10-29 14:58, Sven Barth wrote: Delphi introduced weak variable to break up cycling, I implemented them similary in my branch (not using the attribute syntax though) and in Florian's suggestions all object instance variables in legacy code would be

Re: [fpc-devel] Proof of Concept ARC implementation

On 30.10.2014 04:15, Hans-Peter Diettrich wrote: Sven Barth schrieb: On 28.10.2014 09:57, Hans-Peter Diettrich wrote: Something like ShortString and AnsiString? Take unit Typinfo for example where quite some methods take a TObject instance. The TypInfo methods can determine the exact

Re: [fpc-devel] Proof of Concept ARC implementation

On 30.10.2014 04:14, Hans-Peter Diettrich wrote: Sven Barth schrieb: On 28.10.2014 10:15, Michael Schnell wrote: On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote: Something like ShortString and AnsiString? Only that ShortStrings can easily be avoided (AFAIK, no great performance

Re: [fpc-devel] Proof of Concept ARC implementation

I managed to acquire some additional information on Lazarus 1.3 + FPC ARC edition problemFirst of all, I tested if Lazarus 1.3 trunk compiled with FPC trunk works correctly. It does.However, Lazarus 1.3 trunk with FPC ARC crashes.Lazarus trunk by FreePascal trunk - OKLazarus trunk by FreePascal

Re: [fpc-devel] Proof of Concept ARC implementation

okay sorry for spamming the mailing list So basically the other problem I reported before (generic + refcounted does not work) turns out to be something different:Declaring variable of refcounted type in a different unit makes the compiler stop with error 2014092205 Assume in unit Aunit I have 

Re: [fpc-devel] Proof of Concept ARC implementation

Very good initiative Sven! Can you create a branch on Github (https://github.com/graemeg/freepascal)? Thank you very much! -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: On 30.10.2014 04:14, Hans-Peter Diettrich wrote: I wonder how difficult it would be to implement the existing Interface refcounting model for TObject, so that this runtime variation could be tested and benchmarked as well, in addition to the current compiletime approach.

Re: [fpc-devel] Proof of Concept ARC implementation

Considering the multiple discussions recently here done on the New Strings, that also introduce multiple compiler-relevant brands of a single type, IMHO there are some restrictions to be payed attention to, if the user is enable to use both ref-counted and not ref-counted Objects. Otherwise we

Re: [fpc-devel] Proof of Concept ARC implementation

On 10/29/2014 01:27 PM, Michael Schnell wrote: I forgot: ...(b1) you can't assign a ref counted object to a variable of the not ref counted type brand: this will result in a runtime error (as the ref counted TObject type can hold not ref-counted objects by ref-count = -1) ...(b2) you can

Re: [fpc-devel] Proof of Concept ARC implementation

On 28.10.2014 10:19, Michael Schnell wrote: On 10/27/2014 07:59 PM, Sven Barth wrote: - in code that does not use ARC (modeswitch arc off - the default; or maybe better a local directive) all instance variables are considered weak While I do have a vision what weak means here, can you give

Re: [fpc-devel] Proof of Concept ARC implementation

On 28.10.2014 09:57, Hans-Peter Diettrich wrote: Sven Barth schrieb: Am 27.10.2014 21:00, schrieb Hans-Peter Diettrich: Sven Barth schrieb: Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich drdiettri...@aol.com mailto:drdiettri...@aol.com: Something like ShortString and AnsiString? With

Re: [fpc-devel] Proof of Concept ARC implementation

On 28.10.2014 10:15, Michael Schnell wrote: On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote: Something like ShortString and AnsiString? Only that ShortStrings can easily be avoided (AFAIK, no great performance advantage to use them) and hence are seldom used right now. ShortStrings

Re: [fpc-devel] Proof of Concept ARC implementation

On 28.10.2014 11:20, hinsta...@yandex.ru wrote: I attached a very small sample project which can not be compiled with FreePascal ARC edition. Thanks, I can reproduce it with that example. + one more thing I noticed: Lazarus 1.3 (trunk) compiled with FreePascal ARC edition refuses to start.

Re: [fpc-devel] Proof of Concept ARC implementation

On 27 Oct 2014, at 19:59, Sven Barth wrote: Florian has written me an idea two weeks ago regarding the backwards compatibility aspect (I won't argue the performance impact one ;) ): - TObject and all descendants are reference counted (please no size and performance discussion here) - in

Re: [fpc-devel] Proof of Concept ARC implementation

On 29/10/2014 13:03, Sven Barth wrote: On 28.10.2014 09:57, Hans-Peter Diettrich wrote: Sven Barth schrieb: Take unit Typinfo for example where quite some methods take a TObject instance. The TypInfo methods can determine the exact type of their arguments, and act inside accordingly. If

Re: [fpc-devel] Proof of Concept ARC implementation

I believe you overcomplicate itVariable type should define if variable is reference-counted or not.class refcounted = refcountedclass descendant from class refcounted = refcountednormal class = not refcountedpass refcounted instance as TObject = not refcounted at all...Consider existing COM

Re: [fpc-devel] Proof of Concept ARC implementation

On 10/29/2014 01:58 PM, Sven Barth wrote: - no change in reference count when assigning a refcounted object variable to it - no change in reference count when assigning it to a refcounted object variable - no change in reference conut when assigning between weak variables Thanks for the

Re: [fpc-devel] Proof of Concept ARC implementation

On 10/29/2014 03:09 PM, hinsta...@yandex.ru wrote: I believe you overcomplicate it No. We are going to run into the same mess with incompatible brands of the same types as with New Strings :-( -Michael ___ fpc-devel maillist -

Re: [fpc-devel] Proof of Concept ARC implementation

I believe that whoever came up with new strings overcomplicated it Consider Java and C# : they do not store encoding in string variables 29.10.2014, 17:30, Michael Schnell mschn...@lumino.de: On 10/29/2014 03:09 PM, hinsta...@yandex.ru wrote:  I believe you overcomplicate it No. We are going

Re: [fpc-devel] Proof of Concept ARC implementation

On Wed, Oct 29, 2014 at 10:38 AM, Dmitry Boyarintsev skalogryz.li...@gmail.com wrote: ... about Delphi compatibility. That's the number two (and some times number one) reason, why FPC has to deal with the new features as ref-counting, anonymous functions, strings ...etc.

Re: [fpc-devel] Proof of Concept ARC implementation

Whatever; I disagree refcounted descendants of non-refcounted objects should be assignable to any variable of parent type; just like any variable is assignable to a variable of parent type type TRefc = class refcounted(TObject) end; var thing: TObject; refThing: TRefc; begin ...

Re: [fpc-devel] Proof of Concept ARC implementation

On 10/29/2014 03:33 PM, hinsta...@yandex.ru wrote: I believe that whoever came up with new strings overcomplicated it Consider Java and C# : they do not store encoding in string variables Yep. dynamically encoded Strings are a nice feature if done appropriately. But I don't think they are

Re: [fpc-devel] Proof of Concept ARC implementation

On 10/29/2014 03:56 PM, hinsta...@yandex.ru wrote: Whatever; I disagree refcounted descendants of non-refcounted objects should be assignable to any variable of parent type; just like any variable is assignable to a variable of parent type And what about TLIst ? If TList is done for not

Re: [fpc-devel] Proof of Concept ARC implementation

I suggest leaving TList from FPC RTL as is. It works with pointers, so leave it be. For refcounted objects we would use generic list like TFPGList from fgl unit. However, currently existing TFPGList implementation would be unable to deal with refcounted objects correctly because TFPGLists uses

Re: [fpc-devel] Proof of Concept ARC implementation

On 29.10.2014 14:23, Jonas Maebe wrote: On 27 Oct 2014, at 19:59, Sven Barth wrote: Florian has written me an idea two weeks ago regarding the backwards compatibility aspect (I won't argue the performance impact one ;) ): - TObject and all descendants are reference counted (please no size and

Re: [fpc-devel] Proof of Concept ARC implementation

On 29.10.2014 15:33, hinsta...@yandex.ru wrote: I believe that whoever came up with new strings overcomplicated it Consider Java and C# : they do not store encoding in string variables Because in C# and Java they are UTF-16. Keep in mind that Delphi also changed to UTF-16 based strings

Re: [fpc-devel] Proof of Concept ARC implementation

On 29.10.2014 16:17, hinsta...@yandex.ru wrote: I suggest leaving TList from FPC RTL as is. It works with pointers, so leave it be. For refcounted objects we would use generic list like TFPGList from fgl unit. However, currently existing TFPGList implementation would be unable to deal with

Re: [fpc-devel] Proof of Concept ARC implementation

On 29.10.2014 15:56, hinsta...@yandex.ru wrote: however mandatory explicit casting is also a viable option: thing := TObject(refThing); // okay, compiler, I know what I'm doing, now do your thing, cast this for me Mandatory explicit typecasts would indeed be an option. This way one would

Re: [fpc-devel] Proof of Concept ARC implementation

On 29 Oct 2014, at 16:30, Sven Barth wrote: On 29.10.2014 14:23, Jonas Maebe wrote: Apple also supports mixing ARC and non-ARC code in Objective-C, but the only way this works is by requiring the programmer to manually perform the reference counting in non-ARC code. I don't think there's

Re: [fpc-devel] Proof of Concept ARC implementation

On 10/29/2014 04:17 PM, hinsta...@yandex.ru wrote: I suggest leaving TList from FPC RTL as is. It works with pointers, so leave it be. OK. Repeating the argument for TObjectList. -Michael ___ fpc-devel maillist -

Re: [fpc-devel] Proof of Concept ARC implementation

On 29.10.2014 16:59, Michael Schnell wrote: On 10/29/2014 04:17 PM, hinsta...@yandex.ru wrote: I suggest leaving TList from FPC RTL as is. It works with pointers, so leave it be. OK. Repeating the argument for TObjectList. TObjectList could (and IMHO should) be extended with support for

Re: [fpc-devel] Proof of Concept ARC implementation

On 29.10.2014 16:45, Jonas Maebe wrote: On 29 Oct 2014, at 16:30, Sven Barth wrote: On 29.10.2014 14:23, Jonas Maebe wrote: Apple also supports mixing ARC and non-ARC code in Objective-C, but the only way this works is by requiring the programmer to manually perform the reference counting

Re: [fpc-devel] Proof of Concept ARC implementation

On 29/10/14 17:50, Sven Barth wrote: On 29.10.2014 16:45, Jonas Maebe wrote: That's indeed only useful if you then also require that all code not written in non-ARC mode performs manual reference counting (like Apple does). Having it as a possibility does not solve the problem of

Re: [fpc-devel] Proof of Concept ARC implementation

Am 27.10.2014 23:41 schrieb Boian Mitov mi...@mitov.com: Well... we may differ on this one. I absolutely love attributes, but I guess that is just me :-D . I think attributes are the greatest thing that has happened to Delphi ever, I just wish they ware not so limited. Attributes allowed us to

Re: [fpc-devel] Proof of Concept ARC implementation

On 10/27/2014 10:44 PM, Boian Mitov wrote: In general the C/C++ notion of doing as little in the language as possible, and as much in library has worked very well for it over the years. Yes, pluggable languages concept has existed at least since C ;-) . I agree, and as I said has worked well.

Re: [fpc-devel] Proof of Concept ARC implementation

On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote: Something like ShortString and AnsiString? Only that ShortStrings can easily be avoided (AFAIK, no great performance advantage to use them) and hence are seldom used right now. -Michael ___

Re: [fpc-devel] Proof of Concept ARC implementation

On 10/27/2014 07:59 PM, Sven Barth wrote: - in code that does not use ARC (modeswitch arc off - the default; or maybe better a local directive) all instance variables are considered weak While I do have a vision what weak means here, can you give an exact description ? -Michael

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: Am 27.10.2014 21:00, schrieb Hans-Peter Diettrich: Sven Barth schrieb: Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich drdiettri...@aol.com mailto:drdiettri...@aol.com: Something like ShortString and AnsiString? With the difference that Short- and AnsiString are

Re: [fpc-devel] Proof of Concept ARC implementation

Boian Mitov schrieb: In general the C/C++ notion of doing as little in the language as possible, and as much in library has worked very well for it over the years. Yes, pluggable languages concept has existed at least since C ;-) . I agree, and as I said has worked well. AFAIR such languages

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: Am 27.10.2014 23:41 schrieb Boian Mitov mi...@mitov.com mailto:mi...@mitov.com: Well... we may differ on this one. I absolutely love attributes, but I guess that is just me :-D . I think attributes are the greatest thing that has happened to Delphi ever, I just wish

Re: [fpc-devel] Proof of Concept ARC implementation

- From: Hans-Peter Diettrich Sent: Tuesday, October 28, 2014 2:08 AM To: FPC developers' list Subject: Re: [fpc-devel] Proof of Concept ARC implementation AFAIR such languages lack compatibility with themselves, as soon as projects start using their private extensions. Then no project can

Re: [fpc-devel] Proof of Concept ARC implementation

On 2014-10-27 00:00, Sven Barth wrote: On 26.10.2014 12:17, Kostas Michalopoulos wrote: On Sun, Oct 26, 2014 at 8:32 AM, Sven Barth pascaldra...@googlemail.com mailto:pascaldra...@googlemail.com wrote: Definitely not. We are in Pascal and there such directives are placed afterwards.

Re: [fpc-devel] Proof of Concept ARC implementation

On Mon, 27 Oct 2014, ListMember wrote: On 2014-10-27 00:00, Sven Barth wrote: On 26.10.2014 12:17, Kostas Michalopoulos wrote: On Sun, Oct 26, 2014 at 8:32 AM, Sven Barth pascaldra...@googlemail.com mailto:pascaldra...@googlemail.com wrote:    

Re: [fpc-devel] Proof of Concept ARC implementation

On 2014-10-27 09:39, Michael Van Canneyt wrote: On Mon, 27 Oct 2014, ListMember wrote: On 2014-10-27 00:00, Sven Barth wrote: On 26.10.2014 12:17, Kostas Michalopoulos wrote: On Sun, Oct 26, 2014 at 8:32 AM, Sven Barth pascaldra...@googlemail.com

Re: [fpc-devel] Proof of Concept ARC implementation

On Mon, 27 Oct 2014, ListMember wrote: On 2014-10-27 09:39, Michael Van Canneyt wrote: On Mon, 27 Oct 2014, ListMember wrote: On 2014-10-27 00:00, Sven Barth wrote: On 26.10.2014 12:17, Kostas Michalopoulos wrote: On Sun, Oct 26, 2014 at 8:32 AM, Sven Barth

Re: [fpc-devel] Proof of Concept ARC implementation

Hello Sven! 25.10.2014 0:23, Sven Barth: Hello together! I've now finished my Proof of Concept ARC implementation which is based on the RFC I published a few weeks back: [...] Could you please elaborate a bit on what will happen to cyclic references? Is there autodetection in place already?

Re: [fpc-devel] Proof of Concept ARC implementation

On 27.10.2014 11:12, Nikolai Zhubr wrote: Hello Sven! 25.10.2014 0:23, Sven Barth: Hello together! I've now finished my Proof of Concept ARC implementation which is based on the RFC I published a few weeks back: [...] Could you please elaborate a bit on what will happen to cyclic

Re: [fpc-devel] Proof of Concept ARC implementation

In my opinion, such thing as cycle detector would be an unnecessary complication; however I have not studied the subject in depth therefore not sure 27.10.2014, 13:10, Sven Barth pascaldra...@googlemail.com: On 27.10.2014 11:12, Nikolai Zhubr wrote:  Hello Sven!  25.10.2014 0:23, Sven Barth:

Re: [fpc-devel] Proof of Concept ARC implementation

On 27 Oct 2014, at 11:10, Sven Barth wrote: A third possiblity would be to implement a cycle detector in the decrement helper, but I haven't come around that for now as I wanted to get a first rough implementation out to you all ;) I think that a cycle detector should be an independent

Re: [fpc-devel] Proof of Concept ARC implementation

On 10/27/2014 11:26 AM, Jonas Maebe wrote: I think that a cycle detector should be an independent component, just like heaptrc is an independent add-on to detect memory problems in regular programs. So you suggest cyclic references should be forbidden (erroneous programming technique).

Re: [fpc-devel] Proof of Concept ARC implementation

On 10/27/2014 11:26 AM, Jonas Maebe wrote: (e.g. suppose that inherited method inserts self into a linked list). Or using TList with it ? Would we need an alternate TList for ref-counted objects ? -Michael ___ fpc-devel maillist -

Re: [fpc-devel] Proof of Concept ARC implementation

I think we should just roll out this feature to FPC trunk and let people test it; so those who are interested in it would test it and detect potential problems in practice rather than in thought experiments 27.10.2014, 13:35, Michael Schnell mschn...@lumino.de: On 10/27/2014 11:26 AM, Jonas

Re: [fpc-devel] Proof of Concept ARC implementation

On Mon, Oct 27, 2014 at 11:32 AM, Michael Schnell mschn...@lumino.de wrote: So you suggest cyclic references should be forbidden (erroneous programming technique). Are they ? IMO if a program takes care to avoid cyclic references (with a heaptrc-like unit to find such cases), it shouldn't

Re: [fpc-devel] Proof of Concept ARC implementation

In our previous episode, Kostas Michalopoulos said: I think it is a bad idea to introduce a new keyword placement if there isn't already one since it breaks consistency (all those other keywords are placed in front of the type name whereas this special one is placed after). There are

Re: [fpc-devel] Proof of Concept ARC implementation

On Mon, 27 Oct 2014, Kostas Michalopoulos wrote: On Mon, Oct 27, 2014 at 11:32 AM, Michael Schnell mschn...@lumino.de wrote: So you suggest cyclic references should be forbidden (erroneous programming technique). Are they ? IMO if a program takes care to avoid cyclic references

Re: [fpc-devel] Proof of Concept ARC implementation

On Mon, 27 Oct 2014, Michael Van Canneyt wrote: On Mon, 27 Oct 2014, Kostas Michalopoulos wrote: On Mon, Oct 27, 2014 at 11:32 AM, Michael Schnell mschn...@lumino.de wrote: So you suggest cyclic references should be forbidden (erroneous programming technique). Are they ? IMO

Re: [fpc-devel] Proof of Concept ARC implementation

On 10/27/2014 11:37 AM, hinsta...@yandex.ru wrote: I think we should just roll out this feature to FPC trunk and let people test it; so those who are interested in it would test it and detect potential problems in practice rather than in thought experiments Hmm. The potential TList problem

Re: [fpc-devel] Proof of Concept ARC implementation

Am 27.10.2014 11:26 schrieb Jonas Maebe jonas.ma...@elis.ugent.be: On 27 Oct 2014, at 11:10, Sven Barth wrote: A third possiblity would be to implement a cycle detector in the decrement helper, but I haven't come around that for now as I wanted to get a first rough implementation out to you

Re: [fpc-devel] Proof of Concept ARC implementation

I tested it a bit; thoughts so far:1. generic and refcounted do not work well together: no matter how I arrange it, a class can't be both generic and refcounted, it causes the compiler to produce some internal error 2014092205.2. Lazarus CodeTools parser hates refcounted keyword, but can be fooled

Re: [fpc-devel] Proof of Concept ARC implementation

Am 27.10.2014 14:54 schrieb hinsta...@yandex.ru hinsta...@yandex.ru: I tested it a bit; thoughts so far: 1. generic and refcounted do not work well together: no matter how I arrange it, a class can't be both generic and refcounted, it causes the compiler to produce some internal error

Re: [fpc-devel] Proof of Concept ARC implementation

On Mon, Oct 27, 2014 at 11:50 AM, Marco van de Voort mar...@stack.nl wrote: There are multiple existing ones already see e.g. http://www.freepascal.org/docs-html/ref/refse21.html But all of those (and absolute that Sven mentioned) are not used in function parameters (something that i already

Re: [fpc-devel] Proof of Concept ARC implementation

Jonas Maebe schrieb: Additionally, as mentioned before, I still believe it's a very bad idea to be able to inherited from a regular class and turn it into a reference counted class. Reference counted and non-reference-counted classes are different language entities with different behaviour and

Re: [fpc-devel] Proof of Concept ARC implementation

On Mon, Oct 27, 2014 at 5:17 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Then the compiler can safely generate refcounting code for *all* objects and non-weak references, and the counting methods take care of required operations Wouldn't that cause all objects to pay (both in terms

Re: [fpc-devel] Proof of Concept ARC implementation

Am 27.10.2014 17:19 schrieb Kostas Michalopoulos badsectorac...@gmail.com : On Mon, Oct 27, 2014 at 11:50 AM, Marco van de Voort mar...@stack.nl wrote: There are multiple existing ones already see e.g. http://www.freepascal.org/docs-html/ref/refse21.html But all of those (and absolute that

Re: [fpc-devel] Proof of Concept ARC implementation

Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich drdiettri...@aol.com: Jonas Maebe schrieb: Additionally, as mentioned before, I still believe it's a very bad idea to be able to inherited from a regular class and turn it into a reference counted class. Reference counted and

Re: [fpc-devel] Proof of Concept ARC implementation

On Mon, 27 Oct 2014, Sven Barth wrote: Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich drdiettri...@aol.com: Jonas Maebe schrieb: Additionally, as mentioned before, I still believe it's a very bad idea to be able to inherited from a regular class and turn it into a reference counted

Re: [fpc-devel] Proof of Concept ARC implementation

Am 27.10.2014 16:23, schrieb Sven Barth: Am 27.10.2014 14:54 schrieb hinsta...@yandex.ru mailto:hinsta...@yandex.ru hinsta...@yandex.ru mailto:hinsta...@yandex.ru: I tested it a bit; thoughts so far: 1. generic and refcounted do not work well together: no matter how I arrange it, a class

Re: [fpc-devel] Proof of Concept ARC implementation

Am 27.10.2014 19:24, schrieb Michael Van Canneyt: On Mon, 27 Oct 2014, Sven Barth wrote: Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich drdiettri...@aol.com: Jonas Maebe schrieb: Additionally, as mentioned before, I still believe it's a very bad idea to be able to inherited from a

Re: [fpc-devel] Proof of Concept ARC implementation

--- -Original Message- From: Sven Barth Sent: Friday, October 24, 2014 2:23 PM To: FPC developers' list Subject: [fpc-devel] Proof of Concept ARC implementation Hello together! I've now finished my Proof of Concept ARC implementation which is based on the RFC I

Re: [fpc-devel] Proof of Concept ARC implementation

In our previous episode, Sven Barth said: Florian has written me an idea two weeks ago regarding the backwards compatibility aspect (I won't argue the performance impact one ;) ): Let's not christen this a step forward. So talking about backwards is premature :-) - TObject and all

Re: [fpc-devel] Proof of Concept ARC implementation

Message- From: Michael Van Canneyt Sent: Monday, October 27, 2014 1:53 AM To: FPC developers' list Subject: Re: [fpc-devel] Proof of Concept ARC implementation On Mon, 27 Oct 2014, ListMember wrote: To me, 'weak' is modifying the type rather than the variable itself (much like 'packed

Re: [fpc-devel] Proof of Concept ARC implementation

--- -Original Message- From: hinsta...@yandex.ru Sent: Monday, October 27, 2014 3:37 AM To: FPC developers' list Subject: Re: [fpc-devel] Proof of Concept ARC implementation I think we should just roll out this feature to FPC trunk and let people test it; so those who are interested

Re: [fpc-devel] Proof of Concept ARC implementation

Subject: Re: [fpc-devel] Proof of Concept ARC implementation In our previous episode, Kostas Michalopoulos said: I think it is a bad idea to introduce a new keyword placement if there isn't already one since it breaks consistency (all those other keywords are placed in front of the type name

Re: [fpc-devel] Proof of Concept ARC implementation

In our previous episode, Boian Mitov said: I think that we should start considering using attributes instead of introducing new keywords. This should reduce the compatibility issues due to the new keywords, keep the language cleaner IMHO. No, they just move the potential conflicts from

Re: [fpc-devel] Proof of Concept ARC implementation

--- Mitov Software www.mitov.com --- -Original Message- From: Marco van de Voort Sent: Monday, October 27, 2014 1:17 PM To: FPC developers' list Subject: Re: [fpc-devel] Proof of Concept ARC implementation In our previous episode, Boian

Re: [fpc-devel] Proof of Concept ARC implementation

--- From: hinsta...@yandex.ru Sent: Monday, October 27, 2014 6:48 AM To: FPC developers' list Subject: Re: [fpc-devel] Proof of Concept ARC implementation I tested it a bit; thoughts so far: 1. generic and refcounted do not work well together: no matter how I arrange it, a class can't

Re: [fpc-devel] Proof of Concept ARC implementation

In our previous episode, Boian Mitov said: Except attributes can't be confused with variables ;-). The variables can't be confused with attributes. Attributes are only useful in addition to an established languages, and as extensions/implementation specific parts (so that the simpler parsers

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: Am 27.10.2014 17:20 schrieb Hans-Peter Diettrich drdiettri...@aol.com mailto:drdiettri...@aol.com: Something like ShortString and AnsiString? With the difference that Short- and AnsiString are assignable to eachother while Jonas does not want that for reference counted

Re: [fpc-devel] Proof of Concept ARC implementation

Kostas Michalopoulos schrieb: On Mon, Oct 27, 2014 at 5:17 PM, Hans-Peter Diettrich drdiettri...@aol.com mailto:drdiettri...@aol.com wrote: Then the compiler can safely generate refcounting code for *all* objects and non-weak references, and the counting methods take care of

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: A semicolon has the problem that you need to distinguish between it being a modifier and a normal following identifier as not every keyword is a keyword in every context (like for example read and write for properties). In this discussion I almost miss the elementary

Re: [fpc-devel] Proof of Concept ARC implementation

--- Mitov Software www.mitov.com --- -Original Message- From: Marco van de Voort Sent: Monday, October 27, 2014 1:42 PM To: FPC developers' list Subject: Re: [fpc-devel] Proof of Concept ARC

  1   2   >