Despite ARC banned retain/release/autorelease functions, there are still
alternatives there in the form of C functions:
From CoreFoundation :
CFRetain() = retain
CFRelease() = release
CGBridgingRelease() = autorelease
From LLVM’s requirements to runtime for ARC to work, as prototyped in GNUstep’
On Oct 22, 2013, at 11:17 AM, Daniel Höpfl wrote:
> OK ... but as you say, the standard should contain the answer. Next try:
Well, there's some evolution there, and this new Objective-C feature which kind
of falls in between different versions of traditional C, ANSI C, C++.
--
Scott Ribe
scot
On Oct 21, 2013, at 10:14 PM, Jens Alfke wrote:
> As for autorelease: "This has come up once before for me, and I was able to
> work around it by making the cache-owner object call -autorelease instead of
> -release on the NSCache, to defer the call to the cache’s dealloc. But I’m
> now using A
I just finished installing it. It's 13A603, the same as the update to the GM
release a couple of days ago.
On Oct 22, 2013, at 3:21 PM, Jens Alfke wrote:
> Can someone who’s installed the public release of Mavericks reply with the
> build number (e.g. from the About This Mac panel)? I’m runnin
Timestamp only shows delivery time, even in the extended headers - which is a
general Apple mailing list complaint; sometimes it's seriously laggy.
On Oct 22, 2013, at 1:06 PM, Chris Hanson wrote:
> OS X Mavericks is available on the App Store now.
>
> -- Chris, cocoa-dev co-mod
> -- who woul
OS X Mavericks is available on the App Store now.
-- Chris, cocoa-dev co-mod
-- who would like to point out the timestamp when he posted the original
message
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin request
On Oct 22, 2013, at 5:36 AM, Darren Wheatley
wrote:
> Hi,
>
> Thanks for the reply.
>
> I tried the code sample you suggested but can't get it to work.
>
> When running the default highlighting is being layered on top of this custom
> highlighting (I can see part of the custom highlighting
13A603 is the last GM seed I downloaded…
On Oct 22, 2013, at 3:21 PM, Jens Alfke wrote:
> Can someone who’s installed the public release of Mavericks reply with the
> build number (e.g. from the About This Mac panel)? I’m running the GM seed,
> 13A598, and I’d like to make sure it’s the same
Can someone who’s installed the public release of Mavericks reply with the
build number (e.g. from the About This Mac panel)? I’m running the GM seed,
13A598, and I’d like to make sure it’s the same as the actual release. Thanks.
—Jens
___
Cocoa-dev m
Actually, it sounds like it's available from the app store now.
Jean
On Oct 22, 2013, at 20:56 , Chris Hanson wrote:
> Until OS X Mavericks becomes available to everyone via the App Store, it's
> still under NDA. Once it's available it can be discussed here, until then it
> can't.
>
> -- Ch
On Oct 22, 2013, at 1:56 PM, Chris Hanson wrote:
> Until OS X Mavericks becomes available to everyone via the App Store, it's
> still under NDA. Once it's available it can be discussed here, until then it
> can't.
Isn't it available on the App Store now? It's showing up for me:
https://itunes
If I do a search on the MAS, it lists it (I signed out first to verify):
https://itunes.apple.com/us/app/os-x-mavericks/id675248567?mt=12
On Tue, Oct 22, 2013 at 11:56 AM, Chris Hanson wrote:
> Until OS X Mavericks becomes available to everyone via the App Store, it's
> still under NDA. Once it
Until OS X Mavericks becomes available to everyone via the App Store, it's
still under NDA. Once it's available it can be discussed here, until then it
can't.
-- Chris, Cocoa-Dev co-mod
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Pleas
Both call points and end of scope, not counting bigger troublemakers like
fall-throughs and use of variables defined in a previous case, which is
strangely valid in C.
Sent from my iPhone
> On 2013年10月23日, at 1:14, Scott Ribe wrote:
>
>> On Oct 22, 2013, at 11:08 AM, ChanMaxthon wrote:
>>
>
Hi,
On 2013-10-22 17:50, Sean McBride wrote:
On Tue, 22 Oct 2013 10:31:01 +0200, Daniel Höpfl said:
Was the old (non-arc) code faulty (but the compiler did not notice
this)?
Why is the arc-version (with TRIGGER_ERROR defined) wrong?
It is wrong in the non-arc world, too. (ISO/IEC 9899:2011 A
On Oct 22, 2013, at 11:08 AM, ChanMaxthon wrote:
> ARC have more insertion points - beginning of scope retaining all passed-in
> arguments or used objects, call point creating objects, and end of scope
> (auto)releasing objects.
OK, and it's the ones at call points that cause problems in switc
ARC have more insertion points - beginning of scope retaining all passed-in
arguments or used objects, call point creating objects, and end of scope
(auto)releasing objects. A missed retain causes race issues, a missed
(auto)release leaks objects and an extra release makes dangling pointers,
po
On Oct 22, 2013, at 10:46 AM, Maxthon Chan wrote:
> As I said, either ARC or C++ objects with constructors and destructors
> requires compiler to insert code into the beginning and ending of the current
> scope
For C++, the constructor is inserted at the call point, not at the beginning of
th
Mavericks deeds can be implied from iOS 7, I think. :-P
On Oct 23, 2013, at 0:31, Kyle Sluder wrote:
> Mavericks is still under NDA. Can’t you all wait (most likely) a few hours?
> ;-)
>
> --Kyle Sluder
>
>> On Oct 22, 2013, at 9:25 AM, Todd Heberlein wrote:
>>
>>> On Oct 22, 2013, at 2:19
As I said, either ARC or C++ objects with constructors and destructors requires
compiler to insert code into the beginning and ending of the current scope (For
C++, it is calls to constructors and destructors; for Objective-C ARC, it is
ARC release/autorelease function calls.). As a rule of thum
On Oct 22, 2013, at 09:16, Scott Ribe wrote:
> On Oct 22, 2013, at 9:50 AM, Sean McBride wrote:
>
>> I don't think you can quote the Standard about 'goto' and just wave your
>> hands and say it applies to 'switch' also. :) The Standard's description
>> of 'switch' should contain the answer
On Oct 22, 2013, at 08:50, Sean McBride wrote:
> On Tue, 22 Oct 2013 10:31:01 +0200, Daniel Höpfl said:
>
>>> Was the old (non-arc) code faulty (but the compiler did not notice
>>> this)?
>>> Why is the arc-version (with TRIGGER_ERROR defined) wrong?
>>
>> It is wrong in the non-arc world, to
Mavericks is still under NDA. Can’t you all wait (most likely) a few hours? ;-)
--Kyle Sluder
> On Oct 22, 2013, at 9:25 AM, Todd Heberlein wrote:
>
>> On Oct 22, 2013, at 2:19 AM, Maxthon Chan wrote:
>>
>> Well you need Xcode and maybe the Command Line Tools package.
>
> Yes, when I install
On Oct 22, 2013, at 2:19 AM, Maxthon Chan wrote:
> Well you need Xcode and maybe the Command Line Tools package.
Yes, when I installed to Mavericks GM and put on the latest Xcode, a lot of my
man pages for C APIs went away. There is a discussion on this about 2 weeks ago
in the Xcode mailing l
On Oct 22, 2013, at 9:50 AM, Sean McBride wrote:
> I don't think you can quote the Standard about 'goto' and just wave your
> hands and say it applies to 'switch' also. :) The Standard's description of
> 'switch' should contain the answer
Switch is just a pile of goto, and I'm pretty sure th
On Tue, 22 Oct 2013 10:31:01 +0200, Daniel Höpfl said:
>> Was the old (non-arc) code faulty (but the compiler did not notice
>> this)?
>> Why is the arc-version (with TRIGGER_ERROR defined) wrong?
>
>It is wrong in the non-arc world, too. (ISO/IEC 9899:2011 AKA C11,
>6.8.6.1: "A goto statement s
Hi,
Thanks for the reply.
I tried the code sample you suggested but can't get it to work.
When running the default highlighting is being layered on top of this custom
highlighting (I can see part of the custom highlighting where the rects are not
quite overlapping). Do you know how I prevent t
Hi,
Thanks for the reply.
I tried the code sample you suggested but can't get it to work.
When running the default highlighting is being layered on top of this custom
highlighting (I can see part of the custom highlighting where the rects are not
quite overlapping). Do you know how I prevent t
In my document app I prompt users to save when switching views via:
NSDocument -canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo
I can call this once successfully after which I receive a sheet saying:
This document’s file has been changed by another application since you opened
or sav
Well you need Xcode and maybe the Command Line Tools package.
On Oct 22, 2013, at 16:56, li shunnian wrote:
> Dear list,
>
> After I updated to Mavericks GM, I can not use man command to find the
> manuals of the C api.
> Can anyone tell me how to solve this problem?
>
> Regards,
> Li Shunnia
Dear list,
After I updated to Mavericks GM, I can not use man command to find the manuals
of the C api.
Can anyone tell me how to solve this problem?
Regards,
Li Shunnian.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admi
Hi,
On 2013-10-22 10:06, ChanMaxthon wrote:
Compiler issue. All cases in a switch statement shares a same scope,
and ARC works by inserting code into beginning and end of scopes.
switch() statement jumps around, making code path very unpredictable,
confusing ARC.
It is a compiler issue. But as
Hi,
On 2013-10-22 09:41, Gerriet M. Denkmann wrote:
Converting to Arc (Xcode 5.0).
This works fine without Arc (regardless whether TRIGGER_ERROR is
defined or not):
NSMutableString *mus = [ NSMutableString string ];
NSString *word = @"abc";
switch( self.colourType )
{
case colour_link
On 22/10/2013, at 9:02 AM, "Gerriet M. Denkmann" wrote:
> (I still would like to know whether my code was faulty, or whether this is a
> compiler bug
Your code was faulty, at least according to the rules of C (which could be
argued about, but not fruitfully). If you insert temporary variable
Compiler issue. All cases in a switch statement shares a same scope, and ARC
works by inserting code into beginning and end of scopes. switch() statement
jumps around, making code path very unpredictable, confusing ARC.
Sent from my iPhone
> On 2013年10月22日, at 16:02, "Gerriet M. Denkmann" wrot
Giving a mini performance boost. NSInvocation is utterly slow (multiple memory
allocations asking for syscalls, and a chain of function calls including at
least two objc_msgSends to invoke a method.) but good for IMP caching
performSelector methods are slightly slower than direct calls since the
On 22 Oct 2013, at 14:48, ChanMaxthon wrote:
> Just put a set of braces after every case: and it should be okay. A set of
> braces here actually sets up a mini stack frame that makes ARC work.
>
非常感谢
Works perfectly now.
(I still would like to know whether my code was faulty, or whether this
This problem comes from C variable scopes regarding braces. For most cases it
is just fine but for switch() all cases are in the same scope, jumping around.
ARC inserts code at beginning and end of scopes (mini stack frames here) so if
a new ARC variable is defined in switch() it gets confused.
> I suggest against NSInvocation. I will just throw in a direct call to
> objc_msgSend.
Care to elaborate?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the modera
I suggest against NSInvocation. I will just throw in a direct call to
objc_msgSend.
Sent from my iPhone
On 2013年10月22日, at 15:33, Igor Elland wrote:
>> This certainly helps: at least I get a clean compile.
>> But telling the compiler about the type of selector to expect would be even
>> bette
Just put a set of braces after every case: and it should be okay. A set of
braces here actually sets up a mini stack frame that makes ARC work.
Sent from my iPhone
> On 2013年10月22日, at 15:41, "Gerriet M. Denkmann" wrote:
>
> Converting to Arc (Xcode 5.0).
>
> This works fine without Arc (rega
Converting to Arc (Xcode 5.0).
This works fine without Arc (regardless whether TRIGGER_ERROR is defined or
not):
NSMutableString *mus = [ NSMutableString string ];
NSString *word = @"abc";
switch( self.colourType )
{
case colour_link:
[ mus
> This certainly helps: at least I get a clean compile.
> But telling the compiler about the type of selector to expect would be even
> better.
> Can this be done?
You might want to look into using NSInvocation instead.
Best,
Elland
___
Cocoa-dev mail
On 22 Oct 2013, at 13:48, Gideon King wrote:
> You can tell it to ignore the warning like this:
>
> #pragma clang diagnostic push
> #pragma clang diagnostic ignored "-Warc-performSelector-leaks"
> NSNumber *status = [ self performSelector: aSelector withObject: a
> withObject: b ];
> #
44 matches
Mail list logo
