Re: OS_OBJECT_USE_OBJC_RETAIN_RELEASE and xpc_release()
Update on email delays: Greg, sorry it took so long to reply this; I was waiting to see if your email would arrive. Although I have definitely been foiled by delays of several hours on this list for many months, it appears that the even-longer delays I saw last week were due to IEEE mail servers in New Jersey being hit by Hurricane Sandy. * * * On 2012 Nov 03, at 16:28, Greg Parker gpar...@apple.com wrote: If you build with the 10.8 SDK, and your deployment target is 10.8 or later, then dispatch objects and XPC objects become Objective-C objects. If you use ARC then they are ordinary ARC-managed objects and you do not retain and release them yourself. You can temporarily revert to the old behavior by defining OS_OBJECT_USE_OBJC=0. Yes, setting setting -DOS_OBJECT_USE_OBJC=0 in the Compiler Flags of the file calling xpc_release(), which is compiled with ARC, fixed the problem. Going forward the solution is to remove your manual retain/release calls and let ARC do the work. Are you saying that if a file is compiled with ARC, I should delete calls to xpc_release()? Read on… You might try re-running the ARC migrator on your ARC code and see if it catches them. The little project was written with ARC from the ground up. So I just ran Edit ▸ Convert to Objective-C ARC on it, and was told that No source file changes are necessary. The call to xpc_release() was not noticed. So, neither the xpc_release() documentation, nor the ARC migrator indicate that I should remove the call to xpc_release(). Are they both missing the boat? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: OS_OBJECT_USE_OBJC_RETAIN_RELEASE and xpc_release()
Le 8 nov. 2012 à 14:54, Jerry Krinock je...@ieee.org a écrit : Update on email delays: Greg, sorry it took so long to reply this; I was waiting to see if your email would arrive. Although I have definitely been foiled by delays of several hours on this list for many months, it appears that the even-longer delays I saw last week were due to IEEE mail servers in New Jersey being hit by Hurricane Sandy. * * * On 2012 Nov 03, at 16:28, Greg Parker gpar...@apple.com wrote: If you build with the 10.8 SDK, and your deployment target is 10.8 or later, then dispatch objects and XPC objects become Objective-C objects. If you use ARC then they are ordinary ARC-managed objects and you do not retain and release them yourself. You can temporarily revert to the old behavior by defining OS_OBJECT_USE_OBJC=0. Yes, setting setting -DOS_OBJECT_USE_OBJC=0 in the Compiler Flags of the file calling xpc_release(), which is compiled with ARC, fixed the problem. Going forward the solution is to remove your manual retain/release calls and let ARC do the work. Are you saying that if a file is compiled with ARC, I should delete calls to xpc_release()? Read on… You might try re-running the ARC migrator on your ARC code and see if it catches them. The little project was written with ARC from the ground up. So I just ran Edit ▸ Convert to Objective-C ARC on it, and was told that No source file changes are necessary. The call to xpc_release() was not noticed. So, neither the xpc_release() documentation, nor the ARC migrator indicate that I should remove the call to xpc_release(). Are they both missing the boat? Assuming you are targeting 10.8, yes you should remove all xpc_retain/release and dispatch_retain/release calls. -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSAttributedString mysteriously truncated too soon
I have a tall UILabel with numberOfLines 0 (meaning infinite). The problem
remains the same even if numberOfLines is some large finite number such as 20,
so that's not the source of the problem.
I am creating an attributed string like this:
NSString *s1 = @The Gettysburg Address, as given by A. Lincoln on a
certain occasion\n;
NSString *s2 = @Four score and seven years ago, our fathers brought forth
upon this continent a new nation, conceived in liberty, and dedicated to the
proposition that all men are created equal.;
NSString* title = s1;
NSMutableAttributedString* content = [[NSMutableAttributedString alloc]
initWithString:title
attributes:@{NSFontAttributeName:[UIFont fontWithName:@Arial-BoldMT size:15],
NSForegroundColorAttributeName:[UIColor colorWithRed:0.251 green:0.000
blue:0.502 alpha:1],
NSKernAttributeName:[NSNull null]}];
NSString* blurb = s2;
NSMutableAttributedString* content2 = [[NSMutableAttributedString alloc]
initWithString:blurb
attributes:@{NSFontAttributeName:[UIFont fontWithName:@Georgia size:14],
NSKernAttributeName:[NSNull null]}];
[content appendAttributedString:content2];
// additional code will go here
self.lab.attributedText = content;
It works fine; I see the title and the paragraph. Now, you see where it says
additional code will go here? In that spot, I add paragraph styles to my
attributed string, like this:
NSMutableParagraphStyle* para = [NSMutableParagraphStyle new];
para.headIndent = 10;
para.firstLineHeadIndent = 10;
para.paragraphSpacingBefore = 5;
para.tailIndent = -1;
para.lineBreakMode = NSLineBreakByWordWrapping;
[content addAttribute:NSParagraphStyleAttributeName value:para
range:NSMakeRange(0,title.length)];
para = [NSMutableParagraphStyle new];
para.headIndent = 10;
para.firstLineHeadIndent = 10;
para.tailIndent = -1;
para.lineBreakMode = NSLineBreakByTruncatingTail;
para.paragraphSpacing = 5;
[content addAttribute:NSParagraphStyleAttributeName value:para
range:NSMakeRange(title.length,1)];
NSStringDrawingContext* con = [NSStringDrawingContext new];
CGRect r = [content boundingRectWithSize:CGSizeMake(280,1)
options:NSStringDrawingUsesLineFragmentOrigin context:con];
NSLog(@%f, r.size.height);
The result (and this is the problem) is that the label truncates after the
**first line** of the second paragraph (Four score and seven years ago, our
fa…). Why? There's plenty of room in my label for more lines!
Moreover, I am trying to predict the height that my text will occupy. Right now
I'm just logging the result, as shown above. Without those paragraph styles, I
get 121, which looks right. With the paragraph styles, I get 53, which suggests
that the truncation is taking place here too!
Now, I know that I can fix the problem by changing NSLineBreakByTruncatingTail
to NSLineBreakByWordWrapping for the second paragraph. But I don't want to!
Because if in fact the text is too long for the height of the actual label, I
do want ellipses at the end!
So how can I get tail truncation **when the label is too short**, without
getting **unnecessary** truncation after the first line of the second paragraph?
Thx - m.
--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSAttributedString mysteriously truncated too soon
Out of curiosity, does it matter if you change this line:
[content addAttribute:NSParagraphStyleAttributeName value:para
range:NSMakeRange(title.length,1)];
to this?
[content addAttribute:NSParagraphStyleAttributeName value:para
range:NSMakeRange(title.length,blurb.length)];
I don't know that it would, it just stuck out at me as a little odd to only
add the paragraph style to one character.
On Thu, Nov 8, 2012 at 2:23 PM, Matt Neuburg m...@tidbits.com wrote:
I have a tall UILabel with numberOfLines 0 (meaning infinite). The problem
remains the same even if numberOfLines is some large finite number such as
20, so that's not the source of the problem.
I am creating an attributed string like this:
NSString *s1 = @The Gettysburg Address, as given by A. Lincoln on a
certain occasion\n;
NSString *s2 = @Four score and seven years ago, our fathers brought
forth upon this continent a new nation, conceived in liberty, and dedicated
to the proposition that all men are created equal.;
NSString* title = s1;
NSMutableAttributedString* content = [[NSMutableAttributedString alloc]
initWithString:title
attributes:@{NSFontAttributeName:[UIFont
fontWithName:@Arial-BoldMT size:15],
NSForegroundColorAttributeName:[UIColor colorWithRed:0.251 green:0.000
blue:0.502 alpha:1],
NSKernAttributeName:[NSNull
null]}];
NSString* blurb = s2;
NSMutableAttributedString* content2 = [[NSMutableAttributedString
alloc]
initWithString:blurb
attributes:@{NSFontAttributeName:[UIFont
fontWithName:@Georgia size:14],
NSKernAttributeName:[NSNull
null]}];
[content appendAttributedString:content2];
// additional code will go here
self.lab.attributedText = content;
It works fine; I see the title and the paragraph. Now, you see where it
says additional code will go here? In that spot, I add paragraph styles
to my attributed string, like this:
NSMutableParagraphStyle* para = [NSMutableParagraphStyle new];
para.headIndent = 10;
para.firstLineHeadIndent = 10;
para.paragraphSpacingBefore = 5;
para.tailIndent = -1;
para.lineBreakMode = NSLineBreakByWordWrapping;
[content addAttribute:NSParagraphStyleAttributeName value:para
range:NSMakeRange(0,title.length)];
para = [NSMutableParagraphStyle new];
para.headIndent = 10;
para.firstLineHeadIndent = 10;
para.tailIndent = -1;
para.lineBreakMode = NSLineBreakByTruncatingTail;
para.paragraphSpacing = 5;
[content addAttribute:NSParagraphStyleAttributeName value:para
range:NSMakeRange(title.length,1)];
NSStringDrawingContext* con = [NSStringDrawingContext new];
CGRect r = [content boundingRectWithSize:CGSizeMake(280,1)
options:NSStringDrawingUsesLineFragmentOrigin context:con];
NSLog(@%f, r.size.height);
The result (and this is the problem) is that the label truncates after the
**first line** of the second paragraph (Four score and seven years ago,
our fa…). Why? There's plenty of room in my label for more lines!
Moreover, I am trying to predict the height that my text will occupy.
Right now I'm just logging the result, as shown above. Without those
paragraph styles, I get 121, which looks right. With the paragraph styles,
I get 53, which suggests that the truncation is taking place here too!
Now, I know that I can fix the problem by changing
NSLineBreakByTruncatingTail to NSLineBreakByWordWrapping for the second
paragraph. But I don't want to! Because if in fact the text is too long for
the height of the actual label, I do want ellipses at the end!
So how can I get tail truncation **when the label is too short**, without
getting **unnecessary** truncation after the first line of the second
paragraph?
Thx - m.
--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/himself%40sfko.com
This email sent to hims...@sfko.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your
Re: NSAttributedString mysteriously truncated too soon
On Thu, Nov 8, 2012, at 03:42 PM, Sixten Otto wrote: Out of curiosity, does it matter if you change this line: [content addAttribute:NSParagraphStyleAttributeName value:para range:NSMakeRange(title.length,1)]; to this? [content addAttribute:NSParagraphStyleAttributeName value:para range:NSMakeRange(title.length,blurb.length)]; I don't know that it would, it just stuck out at me as a little odd to only add the paragraph style to one character. Alternatively, try calling -fixAttributesInRange: on your attributed string. On the Mac, NSTextStorage takes care of this automatically; you may need to do it manually on iOS. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSAttributedString mysteriously truncated too soon
On Nov 8, 2012, at 13:23 , Matt Neuburg m...@tidbits.com wrote: The result (and this is the problem) is that the label truncates after the **first line** of the second paragraph (Four score and seven years ago, our fa…). Why? There's plenty of room in my label for more lines! I believe it's just a quirk of the way the text system divides responsibility, which is in turn a consequence of the archeology of text capabilities. Paragraph styles let you specify *one* line (with truncation) or *multiple* lines (without truncation). There is a separate option that truncates the last line of a multiple-line paragraph (NSStringDrawingTruncatesLastVisibleLine), but AFAICT the only way to apply this option is via 'drawWithRect:options:context:' -- I don't think there's any way to specify the option as a string attribute. So, this text drawing style would require a custom view rather than a UILabel. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: OS_OBJECT_USE_OBJC_RETAIN_RELEASE and xpc_release()
On 2012 Nov 08, at 08:59, Jean-Daniel Dupas devli...@shadowlab.org wrote: Assuming you are targeting 10.8, yes you should remove all xpc_retain/release and dispatch_retain/release calls. Nope. Targeting 10.6+. So then I guess I should stick with the alternative of using xpc_release() and compiling with flag -DOS_OBJECT_USE_OBJC=0. I think I should file a bug that these conditions for using or not xpc_release() are not documented. I think the documentation should be in xpc.h and/or Transitioning to ARC Release Notes. Am I looking in the wrong place? Jerry ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: OS_OBJECT_USE_OBJC_RETAIN_RELEASE and xpc_release()
On Nov 8, 2012, at 5:40 PM, Jerry Krinock je...@ieee.org wrote: On 2012 Nov 08, at 08:59, Jean-Daniel Dupas devli...@shadowlab.org wrote: Assuming you are targeting 10.8, yes you should remove all xpc_retain/release and dispatch_retain/release calls. Nope. Targeting 10.6+. So then I guess I should stick with the alternative of using xpc_release() and compiling with flag -DOS_OBJECT_USE_OBJC=0. You should not need the extra compiler flag. Set your Deployment Target correctly and the headers will handle the rest. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: printing arrays
On 3 Nov 2012, at 22:42, Kyle Sluder k...@ksluder.com wrote:
On Nov 2, 2012, at 10:18 PM, Gerriet M. Denkmann gerr...@mdenkmann.de
wrote:
On 3 Nov 2012, at 00:35, Kyle Sluder k...@ksluder.com wrote:
If this is just for debugging purposes, you could swizzle -[NSArray
description] and -[NSDictionary description].
I tried a Category for NSArray like:
You must never use a category to replace an existing method implementation.
Swizzling is the only approach that will work.
About swizzling I found:
http://darkdust.net/writings/objective-c/method-swizzling and
http://www.cocoawithlove.com/2008/03/supersequent-implementation.html.
What to swizzle: The String Programming Guide says: %@ prints Objective-C
object, printed as the string returned by descriptionWithLocale: if available,
or description otherwise.
In my case: NSArray, NSSet, NSDictionary all have descriptionWithLocale: so
this had to be swizzled.
Easy way: just return [self debugDescription] which is readable.
Disadvantage: it does not print in a nice indented way like the original
descriptionWithLocale: does.
So I created for the 3 classes of concern:
- (NSString *)niceDescriptionIndented: (NSUInteger)indent
which prints nice and indented.
- (NSString *)niceDescriptionIndented: (NSUInteger)indent
{
NSMutableString *indenStr = [ NSMutableString string ];
for( NSUInteger i = 0; i indent; i++ ) [ indenStr appendString: @\t
];
NSMutableString *outStr = [ NSMutableString string ];
[ outStr appendFormat: @%@ (%lu), [self class], [self count] ];
[ outStr appendString: @\n ];
[ outStr appendString: indenStr ];
[ outStr appendString: @[ ];
[ outStr appendString: @\n ];
for( id item in self )
{
[ outStr appendString: indenStr ];
[ outStr appendString: @\t ];
if ( [ item respondsToSelector:
@selector(niceDescriptionIndented:) ] )
{
[ outStr appendString: [item niceDescriptionIndented:
indent + 1] ];
}
else
{
[ outStr appendString: [item description] ];
};
[ outStr appendString: @\n ];
};
[ outStr appendString: indenStr ];
[ outStr appendString: @] ];
return outStr;
}
The NSSet, NSDictionary methods are (almost) identical.
Kind regards (and thanks for pushing me in the right direction!)
Gerriet.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
