xmlvm-developers

[xmlvm-dev] ARC

[Panayotis K. <pan...@pa...>]

Hello all!

When digging the iOS 5 documentation, I found this:

https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniPhoneOS/Articles/iOS5.html#//apple_ref/doc/uid/TP30915195-SW4

I believe this is very interesting and XMLVM should consider implementing it :)
It seems that more or less it does what we already do.
If we can indeed get rid of the many retain/release methods and let the compiler decide about it, it would be a great benefit for this project.

Re: [xmlvm-dev] ARC

[Arno P. <ar...@pu...>]

I cannot read this document because I have to agree to new terms and
condition of the iOS developer program and I don't want to just
blindly click on "I agree". Does anyone happen to know what these new
terms are?

Coming back to the reference counting problem. This is already solved
with the C backend since we have a fully fledged garbage collector.
Except in some isolated parts of the wrapper library, there are no
more retain/releases in the generated code.

Arno

On Jun 8, 2011, at 6:49 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:

> Hello all!
>
> When digging the iOS 5 documentation, I found this:
>
> https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniPhoneOS/Articles/iOS5.html#//apple_ref/doc/uid/TP30915195-SW4
>
> I believe this is very interesting and XMLVM should consider implementing it :)
> It seems that more or less it does what we already do.
> If we can indeed get rid of the many retain/release methods and let the compiler decide about it, it would be a great benefit for this project.
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers

Re: [xmlvm-dev] ARC

[Panayotis K. <pan...@pa...>]

On Jun 8, 2011, at 6:51 PM, Arno Puder wrote:

> I cannot read this document because I have to agree to new terms and
> condition of the iOS developer program and I don't want to just
> blindly click on "I agree". Does anyone happen to know what these new
> terms are?
> 
> Coming back to the reference counting problem. This is already solved
> with the C backend since we have a fully fledged garbage collector.
> Except in some isolated parts of the wrapper library, there are no
> more retain/releases in the generated code.
> 
> Arno


Even though, I believe that since this is recommended by Apple, I would suggest to follow their guidelines.

Moreover, although I already know that the ObjC backend is not actively developed in favor of the C backend, I believe it worths it to support the ARC and I could start working with it.

Re: [xmlvm-dev] ARC

[Arno P. <ar...@pu...>]

I don't know yet what ARC is but just to note that we are in
compliance with Apples guidelines. If ARC should make reference
counting more efficient, then that is nice for the Objective-C
backend, however, it is irrelevant for the C backend since we use a
garbage collector.

Arno

On Jun 8, 2011, at 10:23 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:

>
> On Jun 8, 2011, at 6:51 PM, Arno Puder wrote:
>
>> I cannot read this document because I have to agree to new terms and
>> condition of the iOS developer program and I don't want to just
>> blindly click on "I agree". Does anyone happen to know what these new
>> terms are?
>>
>> Coming back to the reference counting problem. This is already solved
>> with the C backend since we have a fully fledged garbage collector.
>> Except in some isolated parts of the wrapper library, there are no
>> more retain/releases in the generated code.
>>
>> Arno
>
>
> Even though, I believe that since this is recommended by Apple, I would suggest to follow their guidelines.
>
> Moreover, although I already know that the ObjC backend is not actively developed in favor of the C backend, I believe it worths it to support the ARC and I could start working with it.
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers

Re: [xmlvm-dev] ARC

[Paul P. <bay...@gm...>]

Panayotis,

As I understand it, once the C backend supports everything the Obj-C backend
does, the Obj-C backend will not be updated anymore.  That may mean a branch
is tagged & it's removed from trunk or it just remains in trunk unchanged,
but either way it's living stagnant.  So I'm not going to stop you, but I'm
curious why you would want to invest that time in the Obj-C backend.

Paul


On Wed, Jun 8, 2011 at 1:03 PM, Arno Puder <ar...@pu...> wrote:

> I don't know yet what ARC is but just to note that we are in
> compliance with Apples guidelines. If ARC should make reference
> counting more efficient, then that is nice for the Objective-C
> backend, however, it is irrelevant for the C backend since we use a
> garbage collector.
>
> Arno
>
> On Jun 8, 2011, at 10:23 AM, Panayotis Katsaloulis
> <pan...@pa...> wrote:
>
> >
> > On Jun 8, 2011, at 6:51 PM, Arno Puder wrote:
> >
> >> I cannot read this document because I have to agree to new terms and
> >> condition of the iOS developer program and I don't want to just
> >> blindly click on "I agree". Does anyone happen to know what these new
> >> terms are?
> >>
> >> Coming back to the reference counting problem. This is already solved
> >> with the C backend since we have a fully fledged garbage collector.
> >> Except in some isolated parts of the wrapper library, there are no
> >> more retain/releases in the generated code.
> >>
> >> Arno
> >
> >
> > Even though, I believe that since this is recommended by Apple, I would
> suggest to follow their guidelines.
> >
> > Moreover, although I already know that the ObjC backend is not actively
> developed in favor of the C backend, I believe it worths it to support the
> ARC and I could start working with it.
> >
> ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Xmlvm-developers mailing list
> > Xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>

Re: [xmlvm-dev] ARC

[Panayotis K. <pan...@pa...>]

On Jun 8, 2011, at 9:03 PM, Arno Puder wrote:

> I don't know yet what ARC is but just to note that we are in
> compliance with Apples guidelines. If ARC should make reference
> counting more efficient, then that is nice for the Objective-C
> backend, however, it is irrelevant for the C backend since we use a
> garbage collector.
> 
> Arno


From my understanding, it automates the procedure of retain and release/autorelease
Practically you don't need to (or probably you should not) use retain/release any more.
The compiler takes care of that and automatically adds this code for you.
Indeed a GC is a more elegant solution of course.