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/ consens... Regards, Sven _

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

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 to

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 about

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

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, e

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" : > I think I discovered another issue. Not sure if you are already aw

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 le

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

Am 05.11.2014 21:55 schrieb : > > 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 or less complex p

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 no

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 leav

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>>: > > okay sorry for spamming the mailing list > > So basically the other problem I reported before (generic + refcounted does not work) turns out

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

Am 30.10.2014 11:01 schrieb "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 crashes. >

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

Am 30.10.2014 11:34 schrieb "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 makes the compi

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

Am 31.10.2014 06:05 schrieb "Hans-Peter Diettrich" : > > 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

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. Ac

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 http://lis

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  typ

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 AR

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 advantage

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 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: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 conside

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 accordingl

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"

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 now.

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

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 "weak" for backwards compatibility. G

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

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 in

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 manu

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 - fpc-devel@lists.freepascal.o

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 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 (h

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

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 (Unicod

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 an

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 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 ref-co

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 str

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 ... th

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

On 29 Oct 2014, at 15:09, hinsta...@yandex.ru wrote: With lists it's worse. If you store pointers to interface variables, they become invalid the moment you don't have any "managed" variables left in scope. Same is true for refcounted objects: if you store them in good old TObjectList, i

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

On Wed, Oct 29, 2014 at 10:33 AM, wrote: > I believe that whoever came up with new strings overcomplicated it > Consider Java and C# : they do not store encoding in string variables > And NSFoundation (the foundation for Cocoa and iOS) strings do. But adding encoding was not about "what other l

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" : > On 10/29/2014 03:09 PM, hinsta...@yandex.ru wrote: >>  I believe you overcomplicate it > > No. We are going to run into

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 - fpc-devel@lists.f

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 ex

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 int

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 you

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 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. Pe

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 don't

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" mailto:drdiettri...@aol.com>>: > Something like ShortString and AnsiString? With the difference th

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 g

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 assign

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 w

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 projec

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

Sven Barth schrieb: Am 27.10.2014 23:41 schrieb "Boian Mitov" >: > > 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

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 21:00, schrieb Hans-Peter Diettrich: Sven Barth schrieb: Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich" mailto:drdiettri...@aol.com>>: > Something like ShortString and AnsiString? With the difference that Short- and AnsiString are assignable to eachot

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

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 ___ fpc-de

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. I

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

Am 27.10.2014 23:41 schrieb "Boian Mitov" : > > 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 cut 3/4 of

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

bject: Re: [fpc-devel] Proof of Concept ARC implementation Am 27.10.2014 21:01, schrieb Boian Mitov: But instead of (context sensitive) keywords you have another bunch of "magic" classes. That's not great either. Also I /hate/ the attribute syntax that Delphi introd

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

Am 27.10.2014 21:01, schrieb Boian Mitov: Hi Sven, Great work! I think it will be better if the weak is attribute as done in Delphi. Attributes eliminate the need for introducing new keywords, to the already crowded OP keywords space. Indeed week is a real attribute of a variable, and it makes

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

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

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

Am 27.10.2014 21:06, schrieb Marco van de Voort: - TObject and all descendants are reference counted (please no size and performance discussion here) No they are not. Of course they are not. That would be stupid. Sorry, I don't get what you're trying to say here. Would you please elaborate?

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

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

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

Am 27.10.2014 21:10, schrieb Boian Mitov: I second this. I would surely love to test drive it. I am also sure we will gather valuable experience from testing it. Then simply use my branch. That's what it's there for. This won't be in trunk for quite some time and the less people test it in the b

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

Am 27.10.2014 21:32, schrieb Boian Mitov: As for 2. this is example where attribute could have helped ;-) . Just another argument in favor of attributes vs. new keywords ;-) . No. It would not. Lazarus doesn't know attributes either. Despite that I /hate/ that attribute syntax. Regards, Sven _

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

: FPC developers' list Subject: Re: [fpc-devel] Proof of Concept ARC implementation In our previous episode, Boian Mitov said: Well... since attributes can be implemented in compiler extending library, And tell me again why directives couldn't? A switch or whatever trigger could

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

--- -Original Message- From: Florian Klämpfl Sent: Monday, October 27, 2014 2:19 PM To: FPC developers' list Subject: Re: [fpc-devel] Proof of Concept ARC implementation Am 27.10.2014 um 19:59 schrieb Sven Barth: No problem with all

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

In our previous episode, Boian Mitov said: > Well... since attributes can be implemented in compiler extending library, And tell me again why directives couldn't? A switch or whatever trigger could also plug additional directives into the parser. (and then I'm not even discussing the actual use o

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

Am 27.10.2014 um 19:59 schrieb Sven Barth: >> >> No problem with all that, interesting ideas even, but not with the current >> codebase and RTL. > Florian has written me an idea two weeks ago regarding the "backwards > compatibility" aspect (I won't > argue the performance impact one ;) ): > - TO

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

Mitov --- 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 C

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

Kostas Michalopoulos schrieb: On Mon, Oct 27, 2014 at 5:17 PM, Hans-Peter Diettrich 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 required operations Woul

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

Sven Barth schrieb: Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich" >: > 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 and ordinary cl

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 ca

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

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

Mitov --- 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 epis

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 m

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

list 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

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

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 (muc

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 descen

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

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" : > > Jonas Maebe schrieb: > > >> Additionally, as mentioned before, I still believe it's a very bad idea to be able to inherited from a regular clas

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 " >: > > 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 bo

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" : > > 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. Refere

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

Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich" : > > 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 >> classe

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

Am 27.10.2014 17:19 schrieb "Kostas Michalopoulos" : > > On Mon, Oct 27, 2014 at 11:50 AM, Marco van de Voort 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 use

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

On Mon, Oct 27, 2014 at 5:17 PM, Hans-Peter Diettrich 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 of performance

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 11:50 AM, Marco van de Voort 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 mentioned)

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

Am 27.10.2014 14:54 schrieb "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 2014092205. Oh, good to

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 11:47 schrieb "Kostas Michalopoulos" : > Is there any other such use of a keyword? 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 o

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

Am 27.10.2014 11:26 schrieb "Jonas Maebe" : > > > 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 thin

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

Am 27.10.2014 11:37 schrieb : > > 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 Then just checkout the branch I mentioned in my initial m

  1   2   >