Re: GCD killed my performance
On Apr 24, 2014, at 22:49 , Jens Alfke j...@mooseyard.com wrote: It is, but most of it appears to be memory management _caused_ by GCD, since it goes away when I replace the dispatch calls with @synchronized. GCD is apparently causing a lot of blocks to get copied to the heap. Well, you know what you’re seeing in Instruments, but this characterization seems improbable. Ignoring the GCD-specific entries, if block copy was causing a large number of retains and releases (if that’s what you meant by “refcount bookkeeping”), I’d expect there to be a large number of block copies, too. If block copies (as I’d also expect) are much more time-consuming than the retains/releases, by comparison you’d barely notice the retain/release times in Instruments. If the retains/releases caused by block copies do dominate, that suggests the block copies are comparatively very cheap, which in turn suggests a horrible bug in block copies. With luck someone might jump in with a plausible answer, but this is starting to sound TSI-worthy. ___ 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: NSToolbarItem Action Not Passed to NSButton...
Okay, I just brushed up a bit on toolbars (wow, it's been a *very* long time).
How did you create the instance of RBSStopButtonToolbarItem in the nib? From
the docs, I learned that you can drag a view (in your case a button) from the
IB palette into the Allowed Toolbar Items area. This should create exactly
what you wanted: a view-based toolbar item containing an NSButton. Then you
could:
* Set the class of the toolbar item to your custom class.
* Set the button's image, alt image, and target in IB.
See
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Toolbars/Articles/ToolbarInIB.html#//apple_ref/doc/uid/TP40008136-SW3.
Also, aren't you getting lots of NSLog messages from your validate method?
Validation occurs with every mouse click and keypress, which means you're
assigning a brand new NSButton to _button over and over and over.
The stuff you're doing in validate would typically be done in awakeFromNib.
Check the documentation for awakeFromNib; it explains a lot about nib loading.
BUT it seems to me you don't need any code to create the button. You can do it
in IB.
What *should* go in the validate method is logic to enable or disable the
button as appropriate at any given time. So you'll still want
RBSStopButtonToolbarItem to have a button property, but you'll want to:
* Add IBOutlet to the property declaration.
* In IB, connect the toolbar item to the button.
* Implement -[RBSStopButtonToolbarItem validate] to enable the button if a
Stop operation makes sense, otherwise disable it.
--Andy
On Apr 25, 2014, at 1:23 AM, Peters, Brandon bap...@my.fsu.edu wrote:
I tried and nothing. The IBOutlet is on the NSToolbarItem custom class. Here
is my custom class:
@interface RBSStopButtonToolbarItem : NSToolbarItem
{
NSButton *_button;
}
@property (readwrite) NSButton *button;
@end
@implementation RBSStopButtonToolbarItem
@synthesize button = _button;
-(id)initWithItemIdentifier:(NSString *)itemIdentifier
{
self = [super initWithItemIdentifier:itemIdentifier];
if(self)
{
// set min and max size
[self setMinSize:NSMakeSize(32.0, 32.0)];
[self setMaxSize:NSMakeSize(32.0, 32.0)];
NSLog(@Self: %@, self);
}
return self;
}
-(void)validate
{
NSLog(@Validate called...);
// set the original and alternate images...names are opposite
_button = [[NSButton alloc] initWithFrame:NSMakeRect(0, 0, 32, 32)];
//[_button setFrameSize:NSMakeSize(32.0, 32.0)];
NSImage *image = [NSImage imageNamed:@StopButtonAlternateIcon];
[image setSize:NSMakeSize(32.0, 32.0)];
[_button setImage:image];
image = [NSImage imageNamed:@StopButtonIcon];
[image setSize:NSMakeSize(32.0, 32.0)];
[_button setAlternateImage:image];
// image position
[_button setImagePosition:NSImageOnly];
// set button type
[_button setButtonType:NSToggleButton];
// button is transparent
[_button setBordered:NO];
// set the toolbar item view to the button
[self setView:_button];
}
@end
The images will display, but the action does not seem to “connect”, even
though it is done in IB.
___
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: GCD killed my performance
Have you looked at the output from System Trace on both systems? I often find that to be informative. That might or might not be the way to tell, but have you considered that the very different CPU characteristics might mean that the actual timing and pattern of database commands is different on the iPhone, resulting in e.g. a different level of contention for the queues? Suppose dispatch_sync is fast on an empty queue but has additional overhead on a full queue - resulting in different performance on one platform to another? On 25 Apr 2014, at 04:42, cocoa-dev-requ...@lists.apple.com wrote: I’m writing an Objective-C API around a database library, and trying to add some optimizations. There’s a lot of room for parallelizing, since tasks like indexing involve a combination of I/O-bound and CPU-bound operations. As a first step, I made my API thread-safe by creating a dispatch queue and wrapping the C database calls in dispatch_sync blocks. Then I did some reorganization of the code so different parts run on different queues, allowing I/O and computation to run in parallel. On my MacBook Pro this gave me a nice speedup of 50% or more. But when I tested the code on my iPhone 5 today, I found performance had dropped by about a third. Profiling shows that most of the time is being spent in thread/queue management or Objective-C refcount bookkeeping. It looks as though adding GCD introduced a lot of CPU overhead, and the two cores on my iPhone aren’t enough to make up for that, while the eight cores in my MacBook Pro make it worthwhile. I tried backing out all the restructuring of my code, so there’s no actual parallelism going on, just the dispatch_sync calls. Predictably, performance is even worse; slightly more than half as fast as without them. So, I’m pretty disappointed. I know that dispatch queues aren’t free, but I wasn’t expecting them to be this expensive! I’m not doing anything silly like wrapping dispatch_sync around trivial calls. The APIs I’m using it on do things like reading and writing values from the persistent store. I was expecting the cost of thread-safety to be lost in the noise compared to that. ___ 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: ARC Retain Cycles
On 25 Apr 2014, at 04:45, Graham Cox graham@bigpond.com wrote:
On 25 Apr 2014, at 11:24 am, Dave d...@looktowindward.com wrote:
I always knew autorelease was bad news!
No it isn't, at least not inherently.
Inheriently it leads to data dependant methods/code and that is definitely bad
news.
But if you don't properly understand it then it can bite you. You've trodden
this path before, and I don't want to rehash all that, but you were wrong
then as well. If you spend a little time with manual memory management
thinking in terms of object ownership, the conventions and rules become
really obvious. Moving to ARC does not, I think, remove the need for the same
understanding. In some ways it makes it more critical.
I do understand, it wasn’t my lack of understanding that was the problem. It
was finding where autorelease was being used in the call chain and draining the
pool.
You cannot avoid autorelease - the frameworks must use it to be consistent
with the established rules, so even if you avoid it religiously in your own
code (and it is just dogma to do so) then you still have to deal with objects
returned by other code.
It’s not dogma! autorealease meant my App peaked at 150MB, whereas it needed 10
MB! Autorelease caused 140 MB of data to be useless held in memory for the
duration of the Thread for no good reason.
You can’t avoid autorelease, you need to do some work to undo it ASAP to stop
the memory building up too much. In this case the solution is to copy the data
into new objects and then drain the pool. Works a treat - you can’t avoid it
BUT you can undo it!
At the top my app looks like this:
-(void) loadDownloadList
{
UIImage*myImage;
for (………)
{
myImage = [self.pServerCommandAPI newRequest];
}
}
The call chain for this goes something like this:
myImage = [self.pCommandAPI newRequest];
TestloadDownloadList
Command API newRequest
ServerAPI newRequest
ServerAPI newSyncRequest
NetworkAPI newSyncRequest
iOS7 dataTaskWithURL: — Returns
Autoreleased Objects in Block Statement
The call to iOS 7 is new and is what was causing the problem, before it called
another Class that didn’t return autoreleased objects. Because all the method
names follow the “new” naming rule, this work wonderfully in non-ARC systems
and lets your App run with a very small memory footprint.
Converting to ARC doesn’t break this, the problem occurs as soon as you start
injecting autorelease object into the call chain. There are a couple of other
places like this where I have to undo the OS’s use of autorelease or my App
will have a muchos mas grande Peak Memory footprint.
The case in point is living proof that autorelease is bad news, 140 MB worth of
proof! If you can’t see it then that’s dogma!
Happy Friday
Dave
___
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
What is CoreData: Error: Unable to dynamically link Librarian.framework
Hi all, I've seen in some user's console output from my app the following line: CoreData: Error: Unable to dynamically link Librarian.framework Google gives only a handful of results. Anyone know what this log means? Thanks, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: Good idea/bad idea?
On Thu, 24 Apr 2014 14:45:58 -0700, Quincey Morris said: I still don't see how foo = [@Something fallbackIfNil:foo]; has any advantage over foo = foo ?: @Something; I don’t see how the latter has any advantage over your earlier suggestion [more or less]: if (!foo) foo = @“Something”; Admittedly, it takes two lines instead of one. OTOH, as I said in another recent thread, it seems to me that for a *reader* of the code, the latter form is far more accessible than code with the “?…:” operator, which tends to force the reader to figure out if the code is correct or not. The 'if form' is arguably better for testing too. Many code coverage tools are line-based, and with this form it's easier to see if your test cases cover going in the branch and not. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: Good idea/bad idea?
On Apr 25, 2014, at 10:22 AM, Sean McBride s...@rogue-research.com wrote: The 'if form' is arguably better for testing too. Many code coverage tools are line-based, and with this form it's easier to see if your test cases cover going in the branch and not. Sure, and similarly for plain old stepping through the code. Xcode steps over a whole ?: expression at once, and doesn't show you which branch it took. --Andy ___ 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: Good idea/bad idea?
On Apr 25, 2014, at 10:38 AM, Andy Lee wrote: On Apr 25, 2014, at 10:22 AM, Sean McBride s...@rogue-research.com wrote: The 'if form' is arguably better for testing too. Many code coverage tools are line-based, and with this form it's easier to see if your test cases cover going in the branch and not. Sure, and similarly for plain old stepping through the code. Xcode steps over a whole ?: expression at once, and doesn't show you which branch it took. --Andy That is an important stipulation for this approach. On the plus side, one little use case for this is to perform NSLogs in the case of a nil result, therein performing a lightweight debugging operation. It's actually the original request I got for this briefer approach. - Alex ___ 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: GCD killed my performance
On Apr 25, 2014, at 1:11 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: Have you looked at the output from System Trace on both systems? I often find that to be informative. OK, I tried this and it did turn out to be very informative :) even though I don’t know how to interpret any of the numbers. But just the pretty charts alone told the story: - With @synchronized there was very little activity in the System Calls or Scheduling tracks. - With GCD there was a whole ton of activity. I was surprised there’s this much of a difference, because there’s no actual concurrency in the code at this point! In the commit I’ve rolled back to, all I’ve done is taken my existing single-threaded code and wrapped the C calls with either @synchronized or dispatch_sync. My understanding is that while dispatch_sync is technically switching to a different dispatch queue, if there isn’t any contention it will just do some bookkeeping and run the block on the same thread’s stack. So in this case I wouldn’t expect there to be any actual thread switching going on; except there is. … So then I searched the project for “dispatch_async” and found that there was actually _one_ call to it, so my statement about “no actual concurrency” above was a lie. The block it runs doesn’t really need to be async; I was just running it that way because I didn’t need it to complete right away. I changed that call to dispatch_sync, and voila! Almost all the thread scheduling and system calls went away; the system trace now looks like the @synchronized one, and the benchmark times are now slightly better than @synchronized! I guess this makes sense: dispatch_sync is super cheap in the uncontended case, but if there’s a dispatch_async pending, then that one obviously has to run first, and it’s probably been scheduled onto another thread, so the dispatch_sync has to either queue onto that thread or at least do some more-expensive locking to wait for the other thread to finish the async call. I’m ending up at the opposite of the received wisdom, namely: * dispatch_sync is a lot cheaper than dispatch_async * only use dispatch_async if you really need to, or for an expensive operation, because it will slow down all your dispatch_sync calls I wish there were a big fat super-dense O’Reilly or Big Nerd Ranch book about GCD so I didn’t have to figure all this out on my own... —Jens ___ 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: GCD killed my performance
On Apr 25, 2014, at 8:08 AM, Jens Alfke j...@mooseyard.com wrote: I’m ending up at the opposite of the received wisdom, namely: * dispatch_sync is a lot cheaper than dispatch_async * only use dispatch_async if you really need to, or for an expensive operation, because it will slow down all your dispatch_sync calls Saying dispatch_async will slow down *all* dispatch_sync calls throws up red flags for me. In my mind there's still a possibility that You're Doing It Wrong. You haven't completely outlined exactly what you've been doing, so it's very hard to offer any solid advice. For example, you didn't mention which queues you're dispatching too, how often your syncs are happen relative to the async, which threads they're being dispatch from, what in particular is happening within them, didn't show any instrument traces… I don't doubt you've found something, but your conclusion doesn't paint the whole picture. And as a matter of fact, I think your first email shows this: On my MacBook Pro this gave me a nice speedup of 50% or more. If it was all down to async universally slowing down all dispatch_sync calls, then wouldn't you expect it to be slower there too? It seems to me you need a better theory as to why the change you made worked. But really, we're flying blind here. -- Seth Willits ___ 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
NSHelpManager
I'm trying to do something with help which I would have hoped would be straightforward, but it seems not be so. I have several applications which are both Windows and Mac. I have a help tool (Windows based) which generates a .chm file for Windows and a collection of .html files for the Mac. I've been able to successfully compile the latter into a Help book. I'm now trying to set this up so that if the user hits the help keys on a dialog, it opens up the help with the specific page for that dialog. I have a couple of problems/questions with this: 1. NSHelpManager does not seem to have a way to open up a page based upon the file name (just anchors and search strings), while the older Apple Help did. Am I missing something there? 2. Under Windows, if you hit the F1 key, WM_HELP messages are sent up the chain, so I just have to process that at the desired level. I was hoping that there would similarly be a showHelp in NSResponder, but it appears that showHelp always goes straight to the NSApplication. Is there any way to work get the type of behavior I need? Best regards, Tom Doan Estima ___ 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: NSHelpManager
On 2014 Apr 25, at 10:38, Tom Doan t...@estima.com wrote: 1. NSHelpManager does not seem to have a way to open up a page based upon the file name (just anchors and search strings), while the older Apple Help did. Am I missing something there? I don’t think so. All my pages begin with, an h1 or h2 etc., which have “id” attributes, which are good for anchors. user hits the help keys on a dialog … opens up the help with the specific page for that dialog 2. Under Windows, if you hit the F1 key, WM_HELP messages are sent up the chain, so I just have to process that at the desired level. I was hoping that there would similarly be a showHelp in NSResponder, but it appears that showHelp always goes straight to the NSApplication. Is there any way to work get the type of behavior I need? Don’t use -[NSApplication showHelp:]. Define your own action method that you implement in various classes (“levels”). Then wire your button’s target to this method in First Responder. By the way, although NSHelpManager is Cocoa, apple-help-author...@lists.apple.com is also a resource for this stuff. ___ 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
NSScroller revision?
i just noticed i’m not sure in which seed it occurred: NSScroller seems to have undergone some revision. i now get this message: CoreAnimation: warning, deleted thread with uncommitted CATransaction; created by: 0 QuartzCore 0x7fff96328ff6 _ZN2CA11Transaction4pushEv + 312 1 QuartzCore 0x7fff96328b29 _ZN2CA11Transaction15ensure_implicitEv + 273 2 QuartzCore 0x7fff963289c6 _ZN2CA11Transaction9set_valueEj12_CAValueTypePKv + 40 3 QuartzCore 0x7fff9632895a +[CATransaction setDisableActions:] + 38 4 AppKit 0x7fff94005985 -[NSScrollerImp _updateLayerGeometry] + 68 5 AppKit 0x7fff94004f52 -[NSScroller(NSInternal2) _replaceScrollerImp] + 401 6 AppKit 0x7fff94164647 -[NSScroller initWithFrame:] + 391 ... the message is logged about 10 seconds after launch, once for the vertical scroller only; the scroller looks behaves as expected. both scrollers are programmatically added (not in ib). does anyone have any idea what the issue is? ___ 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: NSScroller revision?
On Fri, Apr 25, 2014, at 12:20 PM, edward taffel wrote: i just noticed i’m not sure in which seed it occurred: NSScroller seems to have undergone some revision. i now get this message: CoreAnimation: warning, deleted thread with uncommitted CATransaction; created by: 0 QuartzCore 0x7fff96328ff6 _ZN2CA11Transaction4pushEv + 312 1 QuartzCore 0x7fff96328b29 _ZN2CA11Transaction15ensure_implicitEv + 273 2 QuartzCore 0x7fff963289c6 _ZN2CA11Transaction9set_valueEj12_CAValueTypePKv + 40 3 QuartzCore 0x7fff9632895a +[CATransaction setDisableActions:] + 38 4 AppKit 0x7fff94005985 -[NSScrollerImp _updateLayerGeometry] + 68 5 AppKit 0x7fff94004f52 -[NSScroller(NSInternal2) _replaceScrollerImp] + 401 6 AppKit 0x7fff94164647 -[NSScroller initWithFrame:] + 391 ... the message is logged about 10 seconds after launch, once for the vertical scroller only; the scroller looks behaves as expected. both scrollers are programmatically added (not in ib). does anyone have any idea what the issue is? Often times this happens if an instance of a layer-backed NSView (of which NSScroll is an example) is deallocated on a background thread. Ensure that the last reference to your views is always released from the main thread. --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: NSScroller revision?
On Apr 25, 2014, at 3:32 PM, Kyle Sluder k...@ksluder.com wrote: On Fri, Apr 25, 2014, at 12:20 PM, edward taffel wrote: i just noticed i’m not sure in which seed it occurred: NSScroller seems to have undergone some revision. i now get this message: CoreAnimation: warning, deleted thread with uncommitted CATransaction; created by: 0 QuartzCore 0x7fff96328ff6 _ZN2CA11Transaction4pushEv + 312 1 QuartzCore 0x7fff96328b29 _ZN2CA11Transaction15ensure_implicitEv + 273 2 QuartzCore 0x7fff963289c6 _ZN2CA11Transaction9set_valueEj12_CAValueTypePKv + 40 3 QuartzCore 0x7fff9632895a +[CATransaction setDisableActions:] + 38 4 AppKit 0x7fff94005985 -[NSScrollerImp _updateLayerGeometry] + 68 5 AppKit 0x7fff94004f52 -[NSScroller(NSInternal2) _replaceScrollerImp] + 401 6 AppKit 0x7fff94164647 -[NSScroller initWithFrame:] + 391 ... the message is logged about 10 seconds after launch, once for the vertical scroller only; the scroller looks behaves as expected. both scrollers are programmatically added (not in ib). does anyone have any idea what the issue is? Often times this happens if an instance of a layer-backed NSView (of which NSScroll is an example) is deallocated on a background thread. Ensure that the last reference to your views is always released from the main thread. --Kyle Sluder thanks kyle, if this were the case, i should expect to see the same report for both scrollers; as they are allocated released at the same code points, i don’t pass the references around. but, i’ll do some checking to be sure. ___ 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
Converting from RTF to HTML misses out image tags
I'm trying to convert from RTF to HTML like so:
NSAttributedString* rtfContent = [[NSAttributedString
alloc]initWithRTF:rtfData documentAttributes:nil];
NSData* htmlData = [rtfContent dataFromRange:NSMakeRange(0,
rtfContent.length)
documentAttributes:@{NSDocumentTypeDocumentAttribute:NSHTMLTextDocumentType}
error:nil];
NSString* htmlString = [[NSString alloc]initWithData:htmlData
encoding:NSUTF8StringEncoding];
It works - up to a point. The point at which it fails is that the image links
in the rtfData are missed out of the resultant htmlString:
RTF
{\*\htmltag84 a href=mailto:king.k...@empirestate.com;}\htmlrtf
{\field{\*\fldinst{HYPERLINK
mailto:king.k...@empirestate.com}}{\fldrslt\cf1\ul \htmlrtf0
king.k...@empirestate.com\htmlrtf }\htmlrtf0 \htmlrtf }\htmlrtf0
{\*\htmltag92 /a}
{\*\htmltag244 o:p}
{\*\htmltag252 /o:p}
{\*\htmltag92 /span}\htmlrtf }\htmlrtf0 \htmlrtf\par}\htmlrtf0
\htmlrtf \par
\htmlrtf0
{\*\htmltag72 /p}
{\*\htmltag64 p class=MsoNormal}\htmlrtf {\htmlrtf0
{\*\htmltag84 span style='font-size:10.0pt;color:#1F497D'}\htmlrtf {\htmlrtf0
{\*\htmltag244 o:p}
{\*\htmltag84 nbsp;}\htmlrtf \'a0\htmlrtf0
{\*\htmltag252 /o:p}
{\*\htmltag92 /span}\htmlrtf }\htmlrtf0 \htmlrtf\par}\htmlrtf0
\htmlrtf \par
\htmlrtf0
{\*\htmltag72 /p}
{\*\htmltag64 p class=MsoNormal}\htmlrtf {\htmlrtf0
{\*\htmltag84 span style='color:#1F497D'}\htmlrtf {\htmlrtf0
{\*\htmltag84 img border=0 width=224 height=51 id=_x_i1033
src=cid:image001.jpg@01CE8098.AD1C4B20 alt=LH_logo600r1idx}\htmlrtf
{\chbrdr\brdrsh LH_logo600r1idx}\htmlrtf0
HTML
p class=p3span class=s1a
href=mailto:king.k...@empirestate.com;king.k...@empirestate.com/a/span/p
p class=p2br/p
p class=p1 /p
p class=p2br/p
p class=p1LH_logo600r1idx/p
Does anyone have any idea how I can ensure that the generated HTML is complete?
Thanks for any help you can provide!
___
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: NSScroller revision?
On Fri, Apr 25, 2014, at 01:16 PM, edward taffel wrote: thanks kyle, if this were the case, i should expect to see the same report for both scrollers; Not necessarily. If they were both deallocated on the same background thread, then there's only one thread with a dangling CATransaction to complain about. as they are allocated released at the same code points, i don’t pass the references around. but, i’ll do some checking to be sure. One insidious possibility is a block submitted to a background queue via dispatch_async that captures a reference to some object that has a chain of pointers that winds up at a view. For example, NSDocument is a prime contender: it itself doesn't have any UI, but it owns its window controllers, which own their windows, which own their view hierarchies. If an NSDocument is deallocated on a background thread, the views might be deallocated on a background thread as well. --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: NSToolbarItem Action Not Passed to NSButton...
Andy, Thank you for the guidance! Clicking twice on the toolbar item in IB revealed the NSButton Attribute Inspector. However, now the images will not show despite being set in IB. I tried programmatically to set the images for the outlet NSButton and got error messages pertaining to “not ready yet”. On Apr 25, 2014, at 2:17 AM, Andy Lee ag...@mac.commailto:ag...@mac.com wrote: ___ 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: GCD killed my performance
Have you clicked the 'strategy' buttons at the top left of instruments, I for some reason can only do this after I've recorded a trace, not during? They are easily overlooked but show per-core or per-thread traces. They can be very useful finding places where everything blocks waiting for one piece of code to execute, or you ping madly from thread-to-thread, queue-to-queue. There are stack traces available at each event. It's a good tool for understanding how dispatch queues are being used and finding out whether your dispatch_sync really is staying on the same CPU or not. On 25 Apr, 2014, at 11:08 pm, Jens Alfke j...@mooseyard.com wrote: On Apr 25, 2014, at 1:11 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: Have you looked at the output from System Trace on both systems? I often find that to be informative. OK, I tried this and it did turn out to be very informative :) even though I don’t know how to interpret any of the numbers. But just the pretty charts alone told the story: - With @synchronized there was very little activity in the System Calls or Scheduling tracks. - With GCD there was a whole ton of activity. I was surprised there’s this much of a difference, because there’s no actual concurrency in the code at this point! In the commit I’ve rolled back to, all I’ve done is taken my existing single-threaded code and wrapped the C calls with either @synchronized or dispatch_sync. My understanding is that while dispatch_sync is technically switching to a different dispatch queue, if there isn’t any contention it will just do some bookkeeping and run the block on the same thread’s stack. So in this case I wouldn’t expect there to be any actual thread switching going on; except there is. … So then I searched the project for “dispatch_async” and found that there was actually _one_ call to it, so my statement about “no actual concurrency” above was a lie. The block it runs doesn’t really need to be async; I was just running it that way because I didn’t need it to complete right away. I changed that call to dispatch_sync, and voila! Almost all the thread scheduling and system calls went away; the system trace now looks like the @synchronized one, and the benchmark times are now slightly better than @synchronized! I guess this makes sense: dispatch_sync is super cheap in the uncontended case, but if there’s a dispatch_async pending, then that one obviously has to run first, and it’s probably been scheduled onto another thread, so the dispatch_sync has to either queue onto that thread or at least do some more-expensive locking to wait for the other thread to finish the async call. I’m ending up at the opposite of the received wisdom, namely: * dispatch_sync is a lot cheaper than dispatch_async * only use dispatch_async if you really need to, or for an expensive operation, because it will slow down all your dispatch_sync calls I wish there were a big fat super-dense O’Reilly or Big Nerd Ranch book about GCD so I didn’t have to figure all this out on my own... —Jens ___ 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/rols%40rols.org This email sent to r...@rols.org ___ 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: NSToolbarItem Action Not Passed to NSButton...
On Apr 25, 2014, at 5:52 PM, Peters, Brandon bap...@my.fsu.edu wrote: Thank you for the guidance! Clicking twice on the toolbar item in IB revealed the NSButton Attribute Inspector. However, now the images will not show despite being set in IB. I tried programmatically to set the images for the outlet NSButton and got error messages pertaining to “not ready yet”. I've been experimenting some more with creating toolbars in IB, and I've been having some frustrations but I *am* able to easily create an image button like you're trying to do. Did you remember to set the Position in IB? I mean the segmented control right under where you specify the Image and Alternate names. If that's not the problem, all I can think of is a long shot: check the min/max values for the size of the toolbar item (not the view, but the NSToolbarItem). They probably make sense, but it couldn't hurt to check. I assume you've read the Toolbar Programming Topics, but just in case: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Toolbars/Toolbars.html I've been reading it (okay, skimming it) and learning some things myself. Perhaps I should have mentioned that the last time I set up an NSToolbar there *was* no UI in IB... Out of curiosity -- why are you using a view-based toolbar item, when all it's doing is displaying an image that you could simply put into an image-based toolbar item? Bear in mind that if the user chooses the Text Only option for their toolbar, you'll now have a non-functioning toolbar item, whereas an image-based toolbar item will still work. Of course it would be nice to get your button working, if only as an exercise. I'm just wondering if it makes sense UI-wise. Anyway, I'm definitely seeing the wisdom of this now: On Apr 23, 2014, at 6:36 PM, Jerry Krinock je...@ieee.org wrote: [...] NSToolbar/Item are kind of crazy cats and customizing them is often found to be problematic. If possible, use the default NSToolbarItem and -setImage:. --Andy ___ 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: GCD killed my performance
On Apr 25, 2014, at 5:42 PM, Roland King r...@rols.org wrote: They can be very useful finding places where everything blocks waiting for one piece of code to execute, or you ping madly from thread-to-thread, queue-to-queue. Thanks, that sounds very useful. I’lll give it a try when I dive back into this. Today I got the GCD-enabled code almost back up to the performance it had on iOS before it was thread-safe and parallel. Still counts as a victory, because with more cores (as on my Mac) it’s a lot faster. Some of the speed came from not using dispatch_async for trivial blocks, some from fixing bugs in my code, some from allocating fewer objects… Slowly chipping away at it and making little gains one at a time. —Jens ___ 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
