Re: RunLoop in Helper Tool
On 16 Sep 2013, at 01:10, Greg Parker gpar...@apple.com wrote: And of course every Cocoa app halts by calling exit(). NSApplicationMain() never returns. (I'm pretty sure it doesn't attempt to stop the main run loop, either.) It does go and close all documents and send NSApplicationWillTerminateNotification and ask the app delegate if it’s OK to quit though. So it’s a tad more graceful than just exit() alone. But yeah, NSApplicationMain doesn’t return, and that silly autorelease pool most people put in main() these days never gets released, just accumulating any objects that get autoreleased on the main thread without any other pool in place. All things to keep in mind. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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
Very strange Xpc magic
In a new app (not document based) I inserted:
#import ZipProtocol.h
// ZipProtocol.h:
@protocol ZipProtocol NSObject
- (void)command:(NSString *)command withReply: (void (^)( NSString
*answerString ))reply;
@end
#define MAGIC_BUG_REMOVAL // defined or not - makes a strange
difference
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
NSString *helperName = @something.very.silly;
NSXPCConnection *aCo = [[NSXPCConnection alloc]
initWithMachServiceName:helperName
options:0
];
if ( aCo == nil)// error
{
NSLog(@%s Error NSXPCConnection,__FUNCTION__);
return ;
};
#ifdef MAGIC_BUG_REMOVAL
NSLog(@%s will use magic - you will see
MAGIC_ERROR,__FUNCTION__);
#else
NSLog(@%s without magic - you will NOT see
MAGIC_ERROR,__FUNCTION__);
#endif
aCo.remoteObjectInterface = [ NSXPCInterface interfaceWithProtocol:
@protocol(ZipProtocol) ];
[ aCo resume];
// can do magic here
id ZipProtocol ree;
ree = [ aCo remoteObjectProxyWithErrorHandler: ^(NSError *err)
{
// if helperName is not running
(always the case) and
// MAGIC_BUG_REMOVAL is NOT
defined, then the next line will never print:
NSLog(@%s MAGIC_ERROR:
%@,__FUNCTION__, err);
}
];
if ( ree == nil)// error
{
NSLog(@%s Error remoteObjectProxy,__FUNCTION__);
return;
};
// can do magic here as well:
#ifdef MAGIC_BUG_REMOVAL
NSLog(@%s will use magic,__FUNCTION__);
#endif
[ ree command:@a command
withReply: ^( NSString *answerString )
{
NSLog(@%s the reply block %@,__FUNCTION__,
answerString );
[ aCo invalidate];
}
];
NSLog(@%s did send,__FUNCTION__);
}
The question: why does the fact whether MAGIC_BUG_REMOVAL is defined or not
makes any difference?
Seems not to depend on optimisation - same for Debug and Release builds.
Probably there is a very simple answer, but I just cannot see it.
10.8.5
The latest and still very secret Xcode.
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
Re: Window controllers and memory leaks
Thanks Kyle and Jerry. It feels a bit strange to be adding extra glue code to track otherwise-completely-autonomous windows (and controllers), but that has certainly done the trick. I found the static analyzer a bit odd to get used to - it sometimes gives purportedly very detailed explanations of its logic that actually seem to miss out the key non-obvious step (e.g. obscure code path accidentally returning nil from a constructor). Once I'd got the hang of it, though, it was a great tool. Cheers Jonny. ___ 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: Confusion about Image I/O export?
On 02 Sep 2013, at 18:42, Graham Cox graham@bigpond.com wrote: Maybe more education is needed but we thought we had explained all that. Maybe we need to display the calculated pixel sizes up front so the user doesn't get surprised by the outcome. I’d go with the latter. If a popular app or the system display stuff in one format, display it the same way. If you need to display this way, maybe go with: 16 bit 256 x 256 (128 x 128 @ 144dpi) or something like that, so users can get the information needed, but also know which value Finder gets its info from. IMO pixels are actually a good idea, because for bitmaps it indicates whether it has enough pixels to print (even if you may have to resize it a little) Whereas that’s harder to tell. I.e. if I know my paper is 5 inches wide and my printer is 300 dpi. I can tell that anything below 1500px width will look blocky at full width. Or for the web, you know what size it can be at most, stuff like that. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: NSTabView
I'm writing a signal processing program and I am trying to use a window to
display multiple NSViews of an oscilloscope, histograms, etc. I create the
NSTabViewItems programmatically. The window controller declares the following
properties:
@property(nonatomic, strong) IBOutlet NSWindow *analysis;
// the visualization window
@property(nonatomic, strong) IBOutlet NSTabView*myTabView;
// the host view
@property(nonatomic, strong) IBOutlet NSTabViewItem*scopeItem;
// the host view
@property(nonatomic, strong) IBOutlet NSTabViewItem*graphItem;
// the host view
@property(nonatomic, strong) IBOutlet NSTabViewItem*DSPItem;
// the host view
@property (nonatomic, strong) IBOutlet NSDrawer *scopeDrawer;
@property (nonatomic, strong) IBOutlet NSDrawer *graphFormatDrawer;
@property(nonatomic, strong) NSView*myCurrentView;
// the host view
@property(nonatomic, strong) NSViewController
*myCurrentViewController; // the current view controller
When I create the tab view items. I use in the window controller
-(void) awakeFromNib
{
[self setDelegate:self];
}
- (IBAction) viewScope:(id)sender
{
AppDelegate *appDelegate = [NSApp delegate];
if ([appDelegate oscilloscopeController] == nil){
[appDelegate setOscilloscopeController: [[OscilloscopeController
alloc]initWithNibName:@OscilloscopeController bundle:[NSBundle
bundleForClass:[OscilloscopeController class;
NSLog(@New Oscilloscope Controller Created by viewScope);
}
if ([appDelegate graphViewController] == nil) //Needed for
drawing grids, etc.
[appDelegate setGraphViewController: [[GraphViewController
alloc]initWithNibName:@GraphViewController bundle:[NSBundle
bundleForClass:[GraphViewController class;
if ([[appDelegate oscilloscopeController] oScopeView] == nil){
[[appDelegate oscilloscopeController] setOScopeView:[[OscilloscopeView
alloc] initWithFrame: [[[appDelegate graphicsWindowController] myTabView]
contentRect]]];
NSLog(@New Oscilloscope View Created by viewScope);}
if (!scopeItem){
[[appDelegate oscilloscopeController] initScopeSweep];
[[appDelegate graphicsWindowController] setScopeItem:
[(NSTabViewItem*)[NSTabViewItem alloc] initWithIdentifier:nil]];
appDelegate graphicsWindowController] scopeItem] view]
setAutoresizesSubviews:YES];
[[[appDelegate graphicsWindowController] scopeItem]
setLabel:@Oscilloscope];
appDelegate graphicsWindowController] scopeItem] view]
addSubview:(NSView*)[[appDelegate oscilloscopeController] oScopeView]];
[myTabView addTabViewItem:[[appDelegate graphicsWindowController]
scopeItem]];
}
[[[appDelegate graphicsWindowController]graphFormatDrawer] close];
[[[appDelegate graphicsWindowController]scopeDrawer] open];
[[appDelegate graphicsWindowController] setMyCurrentViewController:
[appDelegate oscilloscopeController]]; // keep track of the current view
controller
[[appDelegate graphicsWindowController] setMyCurrentView:
(NSView*) [[appDelegate oscilloscopeController] oScopeView]];
NSRect iRect = [[[appDelegate graphicsWindowController] myCurrentView]
bounds];
[[appDelegate oscilloscopeController] setDistOffset:(iRect.size.height/ 3)];
[[appDelegate oscilloscopeController] setProxOffset:((iRect.size.height /
3) * 2)];
NSApp delegate] graphicsWindowController] myCurrentView]
setNeedsDisplay:YES];
}
- (IBAction) viewGraph:(id)sender
{
AppDelegate *appDelegate = [NSApp delegate];
if ([appDelegate graphViewController] == nil)
[appDelegate setGraphViewController: [[GraphViewController
alloc]initWithNibName:@GraphViewController bundle:[NSBundle
bundleForClass:[GraphViewController class;
if ([[appDelegate graphViewController] graphicsView] == nil){
[[appDelegate graphViewController] setGraphicsView:[[GraphicsView
alloc] initWithFrame: [[[appDelegate graphicsWindowController] myTabView]
contentRect]]];
NSLog(@New Graphics View Created by viewGraph);}
if (![[appDelegate graphicsWindowController] graphItem]){
[[appDelegate graphicsWindowController] setGraphItem:
[(NSTabViewItem*)[NSTabViewItem alloc] initWithIdentifier:nil]];
appDelegate graphicsWindowController] graphItem] view]
setAutoresizesSubviews:YES];
[[[appDelegate graphicsWindowController] graphItem] setLabel:@Graph];
appDelegate graphicsWindowController] graphItem] view]
addSubview:(NSView*)[[appDelegate graphViewController] graphicsView]];
[myTabView addTabViewItem:[[appDelegate graphicsWindowController]
graphItem]];
}
[[[appDelegate graphicsWindowController]graphFormatDrawer] open];
UIView Center does not seem to change with orientation change
I am looking at at view that covers the entire iPhone screen. The app is also
required to only work in Landscape. I see that in viewWillAppear the bounds and
center of the view are in Portrait mode - this is fine. However, in
viewDidAppear the bounds of the view are in Landscape, but the center is
unchanged. This makes the center of the view incorrect, which make
transformations wrong and any calculations based on the center of the view
wrong.
Should the app force a new center on an orientation change?
Further I find that running this code:
- (void)viewDidAppear:(BOOL)animated
{
[self.view setFrame: CGRectMake(0, 0, self.view.bounds.size.width,
self.view.bounds.size.height)];
[self.view setBounds:storeView.frame];
NSLog(@viewDidAppear);
NSLog(@self.view.bounds: %@, [NSValue valueWithCGRect:self.view.bounds]);
NSLog(@self.view.frame: %@, [NSValue valueWithCGRect:self.view.frame]);
NSLog(@self.view.center: %@, [NSValue valueWithCGPoint:self.view.center]);
}
generates these logs:
viewWillAppear
self.view.bounds: NSRect: {{0, 0}, {320, 568}}
self.view.frame: NSRect: {{0, 0}, {320, 568}}
self.view.center: NSPoint: {160, 284}
viewDidAppear
self.view.bounds: NSRect: {{0, 0}, {568, 320}}
self.view.frame: NSRect: {{124, -124}, {320, 568}}
self.view.center: NSPoint: {284, 160}
Where does the {124, -124} come from?
Rich Collyer
___
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
Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
I'm hoping someone can suggest the correct way to deal with the following problem. For an image viewing app i display a file in the usual way in an NSDocument. setFileURL: is properly called by NSDocument's _initWithContentsOfURL:ofType:error:. I now want to display the next file in the folder, and move the old file to the Trash. To do this I do the necessary file reading tasks and call setFileURL: with the new file URL. I then move the old file to the trash (using NSFileManager 's trashItemAtURL:resultingItemURL:error: but using different methods gives the same result.) Prior to 10.7 this worked fine and gave the desired result. Under 10.8, shortly after I load the new file and call setFileURL: with the new file URL as described above, I see a presentedItemDidMoveToURL: call with the old file URL. From that point on, the document has the wrong URL associated with it. #0 0x000100014cf0 in -[ImageDoc setFileURL:] at /Volumes/Data/Documents/Projects/Ptah/ptah src 3.1.0/Source/ImageDoc.m:3669 #1 0x7fff84763b6f in __block_global_243 () #2 0x7fff842fa869 in -[NSDocument continueFileAccessUsingBlock:] () #3 0x7fff842fa432 in -[NSDocument _performFileAccessOnMainThread:usingBlock:] () #4 0x7fff842ff0d7 in -[NSDocument performAsynchronousFileAccessUsingBlock:] () #5 0x7fff84763b3d in __40-[NSDocument presentedItemDidMoveToURL:]_block_invoke_0 () #6 0x7fff832789cf in -[NSBlockOperation main] () #7 0x7fff8324e926 in -[__NSOperationInternal start] () #8 0x7fff832560f1 in __block_global_6 () #9 0x7fff8750bf01 in _dispatch_call_block_and_release () #10 0x7fff875080b6 in _dispatch_client_callout () #11 0x7fff8750d0c8 in _dispatch_main_queue_callback_4CF () #12 0x7fff8c4b4b4c in __CFRunLoopRun () #13 0x7fff8c4b40e2 in CFRunLoopRunSpecific () #14 0x7fff8b9e0eb4 in RunCurrentEventLoopInMode () #15 0x7fff8b9e0c52 in ReceiveNextEventCommon () #16 0x7fff8b9e0ae3 in BlockUntilNextEventMatchingListInMode () #17 0x7fff8442a533 in _DPSNextEvent () #18 0x7fff84429df2 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #19 0x7fff844211a3 in -[NSApplication run] () #20 0x7fff843c5bd6 in NSApplicationMain () #21 0x000100063f79 in main at /Volumes/Data/Documents/Projects/Ptah/ptah src 3.1.0/Source/App.m:136 #22 0x000120e4 in start () What is the proper way to prevent this behavior? Obviously simply calling setFileURL: with the new file URL does not fully establish the the document is now associated only with the new file, and that the old file should be forgotten and not associated in any way with the document. I'm not explicitly using NSFileCoordinator or NSFilePresenter. This is a non-sandboxed app. ___ 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: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
On 14 Sep 2013, at 21:14, Brian Clark ba-cl...@comcast.net wrote: I'm hoping someone can suggest the correct way to deal with the following problem. For an image viewing app i display a file in the usual way in an NSDocument. setFileURL: is properly called by NSDocument's _initWithContentsOfURL:ofType:error:. I now want to display the next file in the folder, and move the old file to the Trash. To do this I do the necessary file reading tasks and call setFileURL: with the new file URL. I then move the old file to the trash (using NSFileManager 's trashItemAtURL:resultingItemURL:error: but using different methods gives the same result.) What are the necessary file reading tasks? Rather than call -setFileURL: yourself, have you tried calling -revertToContentsOfURL:ofType:error: instead? The top of the class documentation briefly notes that it should always be used for re-reading documents. Prior to 10.7 this worked fine and gave the desired result. Under 10.8, shortly after I load the new file and call setFileURL: with the new file URL as described above, I see a presentedItemDidMoveToURL: call with the old file URL. From that point on, the document has the wrong URL associated with it. #00x000100014cf0 in -[ImageDoc setFileURL:] at /Volumes/Data/Documents/Projects/Ptah/ptah src 3.1.0/Source/ImageDoc.m:3669 #10x7fff84763b6f in __block_global_243 () #20x7fff842fa869 in -[NSDocument continueFileAccessUsingBlock:] () #30x7fff842fa432 in -[NSDocument _performFileAccessOnMainThread:usingBlock:] () #40x7fff842ff0d7 in -[NSDocument performAsynchronousFileAccessUsingBlock:] () #50x7fff84763b3d in __40-[NSDocument presentedItemDidMoveToURL:]_block_invoke_0 () #60x7fff832789cf in -[NSBlockOperation main] () #70x7fff8324e926 in -[__NSOperationInternal start] () #80x7fff832560f1 in __block_global_6 () #90x7fff8750bf01 in _dispatch_call_block_and_release () #10 0x7fff875080b6 in _dispatch_client_callout () #11 0x7fff8750d0c8 in _dispatch_main_queue_callback_4CF () #12 0x7fff8c4b4b4c in __CFRunLoopRun () #13 0x7fff8c4b40e2 in CFRunLoopRunSpecific () #14 0x7fff8b9e0eb4 in RunCurrentEventLoopInMode () #15 0x7fff8b9e0c52 in ReceiveNextEventCommon () #16 0x7fff8b9e0ae3 in BlockUntilNextEventMatchingListInMode () #17 0x7fff8442a533 in _DPSNextEvent () #18 0x7fff84429df2 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #19 0x7fff844211a3 in -[NSApplication run] () #20 0x7fff843c5bd6 in NSApplicationMain () #21 0x000100063f79 in main at /Volumes/Data/Documents/Projects/Ptah/ptah src 3.1.0/Source/App.m:136 #22 0x000120e4 in start () What is the proper way to prevent this behavior? Obviously simply calling setFileURL: with the new file URL does not fully establish the the document is now associated only with the new file, and that the old file should be forgotten and not associated in any way with the document. I'm not explicitly using NSFileCoordinator or NSFilePresenter. This is a non-sandboxed app. ___ 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/mabdullah%40karelia.com This email sent to mabdul...@karelia.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: RunLoop in Helper Tool
On Sep 16, 2013, at 9:12 , Uli Kusterer witness.of.teacht...@gmx.net wrote: On 16 Sep 2013, at 01:10, Greg Parker gpar...@apple.com wrote: And of course every Cocoa app halts by calling exit(). NSApplicationMain() never returns. (I'm pretty sure it doesn't attempt to stop the main run loop, either.) It does go and close all documents and send NSApplicationWillTerminateNotification and ask the app delegate if it’s OK to quit though. So it’s a tad more graceful than just exit() alone. Hmm…I don’t think Greg or anyone else said anything about calling exit() alone. For example: On Sep 15, 2013, at 16:30 , Marcel Weiher marcel.wei...@gmail.com wrote: Do all the cleanup you want to do and then exit(0) ? But yeah, NSApplicationMain doesn’t return, and that silly autorelease pool most people put in main() these days never gets released, just accumulating any objects that get autoreleased on the main thread without any other pool in place. Yes, hopefully it doesn’t get released. The reason to put it there was to avoid console messages of the form “object xyz autoreleased without a pool in place - just leaking”. Better to have them leak silently in a pool than with a console message, if they are indeed top-level objects that are supposed to stick around. Just testing it now on my Mac doesn’t show the message. Has it been removed/optionalized or are we now getting an automatic top-level pool? Marcel ___ 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
Progress for archiving/dearchiving
Hi all, If I wanted to add some sort of progress reporting to archiving and dearchiving, what's a good way to do it? The problem seems to me to know what the 'count' of things read from/written to the file is to set the progress max value. Since the delegate gets called for each object instantiated, that part of it isn't a problem, I can just bump a counter. Counting the objects rather than actual bytes is probably as fine-grained as I need to get. --Graham ___ 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: Progress for archiving/dearchiving
How about tracking the number of written objects when saving the document, then encoding an additional key containing the object count at the top level of the archive? This could then be retrieved before decoding the root object. A possible problem with this idea is that it might require the data for the root object to be read into memory before the count can be read. Maybe this wouldn't be a problem with a binary format --- I don't know enough about the implementation of NSKeyedArchiver/Unarchiver to be sure. On 16 September 2013 13:53, Graham Cox graham@bigpond.com wrote: Hi all, If I wanted to add some sort of progress reporting to archiving and dearchiving, what's a good way to do it? The problem seems to me to know what the 'count' of things read from/written to the file is to set the progress max value. Since the delegate gets called for each object instantiated, that part of it isn't a problem, I can just bump a counter. Counting the objects rather than actual bytes is probably as fine-grained as I need to get. --Graham ___ 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/devereux.chris%40gmail.com This email sent to devereux.ch...@gmail.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: UIView Center does not seem to change with orientation change
On Sep 13, 2013, at 1:27 PM, Rich Collyer iseecol...@rsqrdc.us wrote: I am looking at at view that covers the entire iPhone screen. The app is also required to only work in Landscape. I see that in viewWillAppear the bounds and center of the view are in Portrait mode - this is fine. However, in viewDidAppear the bounds of the view are in Landscape, but the center is unchanged. This makes the center of the view incorrect, which make transformations wrong and any calculations based on the center of the view wrong. Should the app force a new center on an orientation change? The center property of a view is in its superview’s coordinate system. What you describe sounds like the view is the view that is vended by the window’s root view controller, which has the unique property that to enable rotation it is transformed rather than resized. This can lead to some unexpected geometry if you are looking at the “wrong” thing. Basically what it comes down to is that a view (or the view controller which returns it as a its view) should not be looking at the geometry it has that is expressed in the parent coordinate system (frame, center, transform) and should not modify its own bounds, as these values are effectively “owned” by the view’s superview. In your case, the odd frame origin is likely due to your alternation of the view’s bounds, as setting bounds alters the frame (since frame is derived from center, bounds, and transform). -- David Duncan ___ 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: Very strange Xpc magic
On 16 Sep 2013, at 22:10, Charles Srstka cocoa...@charlessoft.com wrote:
On Sep 16, 2013, at 3:22 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
In a new app (not document based) I inserted:
#import ZipProtocol.h
// ZipProtocol.h:
@protocol ZipProtocol NSObject
- (void)command:(NSString *)command withReply: (void (^)( NSString
*answerString ))reply;
@end
#define MAGIC_BUG_REMOVAL// defined or not - makes a strange
difference
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
NSString *helperName = @something.very.silly;
NSXPCConnection *aCo = [[NSXPCConnection alloc]
initWithMachServiceName:helperName
options:0
];
if ( aCo == nil)// error
{
NSLog(@%s Error NSXPCConnection,__FUNCTION__);
return ;
};
#ifdef MAGIC_BUG_REMOVAL
NSLog(@%s will use magic - you will see
MAGIC_ERROR,__FUNCTION__);
#else
NSLog(@%s without magic - you will NOT see
MAGIC_ERROR,__FUNCTION__);
#endif
aCo.remoteObjectInterface = [ NSXPCInterface interfaceWithProtocol:
@protocol(ZipProtocol) ];
[ aCo resume];
// can do magic here
id ZipProtocol ree;
ree = [ aCo remoteObjectProxyWithErrorHandler: ^(NSError *err)
{
// if helperName is not running
(always the case) and
// MAGIC_BUG_REMOVAL is NOT
defined, then the next line will never print:
NSLog(@%s MAGIC_ERROR:
%@,__FUNCTION__, err);
}
];
if ( ree == nil)// error
{
NSLog(@%s Error remoteObjectProxy,__FUNCTION__);
return;
};
// can do magic here as well:
#ifdef MAGIC_BUG_REMOVAL
NSLog(@%s will use magic,__FUNCTION__);
#endif
[ ree command:@a command
withReply: ^( NSString *answerString )
{
NSLog(@%s the reply block %@,__FUNCTION__,
answerString );
[ aCo invalidate];
}
];
NSLog(@%s did send,__FUNCTION__);
}
The question: why does the fact whether MAGIC_BUG_REMOVAL is defined or not
makes any difference?
Seems not to depend on optimisation - same for Debug and Release builds.
Probably there is a very simple answer, but I just cannot see it.
What's the error that logs in your error handler?
If (and only if) MAGIC_BUG_REMOVAL is defined, I see:
Error Domain=NSCocoaErrorDomain Code=4099 Couldn’t communicate with a helper
application.
Makes sense, as there just is no helper application named:
something.very.silly.
Kind regards,
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
Re: Very strange Xpc magic
On Sep 16, 2013, at 3:22 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
ree = [ aCo remoteObjectProxyWithErrorHandler: ^(NSError *err)
{
// if helperName is not running
(always the case) and
// MAGIC_BUG_REMOVAL is NOT
defined, then the next line will never print:
NSLog(@%s MAGIC_ERROR:
%@,__FUNCTION__, err);
}
];
What is the error that gets logged here?
Charles
___
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: Very strange Xpc magic
On Sep 16, 2013, at 9:27 AM, Gerriet M. Denkmann wrote: On 16 Sep 2013, at 22:21, Charles Srstka cocoa...@charlessoft.com wrote: On Sep 16, 2013, at 10:16 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: If (and only if) MAGIC_BUG_REMOVAL is defined, I see: Error Domain=NSCocoaErrorDomain Code=4099 Couldn’t communicate with a helper application. Makes sense, as there just is no helper application named: something.very.silly. Make sure you've got the Mach service name for your helper registered in your helper's launchd plist. If it's set up correctly, your helper should automatically launch when the client app tries to communicate with its Mach service name. Maybe I was not very clear. The problem is NOT that the helper app does not start. There just is no helper app, there is nothing which has a MachService called something.very.silly. The problem is, that the error block, which prints MAGIC_ERROR, does only get called when there is an NSLog right in front of it. This makes no sense (to me). Unless I didn't understand, your original post indicated that the issue was with the macro define. Has this changed? If not, I would run the file manually through the preprocessor and examine the output. Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ 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: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
On Sep 16, 2013, at 4:38 AM, Mike Abdullah mabdul...@karelia.com wrote: On 14 Sep 2013, at 21:14, Brian Clark ba-cl...@comcast.net wrote: I'm hoping someone can suggest the correct way to deal with the following problem. For an image viewing app i display a file in the usual way in an NSDocument. setFileURL: is properly called by NSDocument's _initWithContentsOfURL:ofType:error:. I now want to display the next file in the folder, and move the old file to the Trash. To do this I do the necessary file reading tasks and call setFileURL: with the new file URL. I then move the old file to the trash (using NSFileManager 's trashItemAtURL:resultingItemURL:error: but using different methods gives the same result.) What are the necessary file reading tasks? Rather than call -setFileURL: yourself, have you tried calling -revertToContentsOfURL:ofType:error: instead? The top of the class documentation briefly notes that it should always be used for re-reading documents. The necessary tasks are readFromURL:ofType:error: and the other chores associated with setting up the document state for the different image file. Using -revertToContentsOfURL:ofType:error: instead does not work. After doing this NSDocument still seems to treat the old URL as the file's document, and I still get presentedItemDidMoveToURL: for the old file URL when it is moved to the Trash AFTER I-ve called revertToContentsOfURL:ofType:error:. While revertToContentsOfURL:ofType:error: may work correctly for the cases for which I guess it was intended (as described by the NSDocument Class Reference), it doesn't seem to work for this case, for reasons unknown. The best work-around I've found is to add a file reference URL to my NSDocument subclass, and set it in an override of setFileURL:. Then in an override of presentedItemDidMoveToURL: I test if the saved file reference URL is the same as the new URL, and do nothing if they're not the same file. That seems to work, but it's a bit of a hack, and I'd really like to understand if NSDocument is simply broken in this regard, or why setFileURL: does not work and what is the correct and reliable way to change the URL for an open document. ___ 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: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
On Sat, Sep 14, 2013, at 01:14 PM, Brian Clark wrote: I'm hoping someone can suggest the correct way to deal with the following problem. For an image viewing app i display a file in the usual way in an NSDocument. setFileURL: is properly called by NSDocument's _initWithContentsOfURL:ofType:error:. I now want to display the next file in the folder, and move the old file to the Trash. To do this I do the necessary file reading tasks and call setFileURL: with the new file URL. I then move the old file to the trash (using NSFileManager 's trashItemAtURL:resultingItemURL:error: but using different methods gives the same result.) Prior to 10.7 this worked fine and gave the desired result. Under 10.8, shortly after I load the new file and call setFileURL: with the new file URL as described above, I see a presentedItemDidMoveToURL: call with the old file URL. From that point on, the document has the wrong URL associated with it. Can you post your code for this? One thing that comes to mind: you need to serialize against the incoming file presenter notifications (delivered on the queue returned by -presentedItemOperationQueue). Otherwise there's no guarantee that the file coordination subsystem will have seen and confirmed your relinquishing of the old URL by the time you start dealing with the new one. Furthermore, the NSFilePresenter protocol doesn't give you a way to inform the system that the presentedItemURL of the presenter has changed. You should make sure that NSDocument is calling +removeFilePresenter: and +addFilePresenter: as part of its -setFIleURL: action. To be honest, I'm not even sure it's possible to do what you want to do. You might need to open up the next file as a new document. --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: Very strange Xpc magic
On Sep 16, 2013, at 10:27 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: Maybe I was not very clear. The problem is NOT that the helper app does not start. There just is no helper app, there is nothing which has a MachService called something.very.silly. The problem is, that the error block, which prints MAGIC_ERROR, does only get called when there is an NSLog right in front of it. This makes no sense (to me). I just tried your code on my machine, and whether the error logs or not seems fairly random. Whether or not your define is present, I sometimes get the error log and sometimes not, and repeatedly running the app (or putting the code in an IBAction instead of applicationDidFinishLaunching: and repeatedly pressing a button to invoke it) results in a different outcome each time. There might be a race condition in the framework or something. Have you filed a Radar report on this yet? Charles ___ 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
NSCollectionView item crashes when bound
Hey guys I'm really grinding with the NSCollectionView when its bound. I had a
running collection view but wanted to use bindings, I looks like it should
work, but it doesn't. This is written just in code not in IB.
Hope you guys can help :)
The problem is, the View is displayed correctly, but as soon as I try to bind a
property in the newItemForRepresentedObject method, it is trying to call
setChannelID (I can see it in the console outputting hello all the time, but
keeps stuck in the else part of the if statement. It never gets to make the if
true, always trying to set it. There is no output after the self.channelID =
chanID; command, there is just another hello. I think the ChannelView property
is not holding the data. The program crashes after 10 seconds trying to set the
value. It should be possible to do this, others have obviously bound in the
newItemForRepresentedObject.
Anyway, any help is appreciated this is the code:
ChannelView
#import Cocoa/Cocoa.h
@interface ChannelView : NSView
@property (readwrite, nonatomic, copy) NSString *channelName;
@property (readwrite, nonatomic, copy) NSNumber *channelID;
@property (readwrite) NSTextField *channelNameField;
@property (readwrite) NSTextField *deviceChannelField;
@end
@implementation ChannelView
- (id)initWithFrame:(NSRect)frame
{
self = [super initWithFrame:NSMakeRect(0, 0, 300, 500)];
if (self) {
// Initialization code here.
ColorView *test = [[ColorView alloc] initWithFrame:NSMakeRect(0, 0, 100,
100)];
self.channelNameField = [[NSTextField alloc] initWithFrame:NSMakeRect(0, 0,
100, 20)];
self.deviceChannelField = [[NSTextField alloc] initWithFrame:NSMakeRect(0,
50, 100, 20)];
[self addSubview:test];
[self addSubview:self.channelNameField];
[self addSubview:self.deviceChannelField];
}
return self;
}
-(id)initWithCoder:(NSCoder *)aDecoder
{
self = [super initWithCoder:aDecoder];
//add die teile
return self;
}
- (void)drawRect:(NSRect)dirtyRect
{
// Drawing code here.
}
// setters.
-(void)setChannelID:(NSNumber *)chanID
{
//NSLog(@hallo);
if (self.channelID == chanID) {
return;
NSLog(@da);
}
else {
NSLog(@hello); //just this in debug output
//self.channelID = [chanID copy];
NSLog(@no output);
self.channelID = chanID;
NSLog(@chanid %d current: %d, chanID.intValue, self.channelID.intValue);
//never shown in debug
[self.deviceChannelField setStringValue:[NSString
stringWithFormat:@%d,self.channelID.intValue]];
}
}
@end
The piece of my subclassed NSCollectionView
- (NSCollectionViewItem *)newItemForRepresentedObject:(ChannelsToMixes*)object
{
NSCollectionViewItem *item = [super newItemForRepresentedObject:object];
// ChannelView *view = (ChannelView *)[item view];
NSLog(@cahnnelid: %d,object.channelID.intValue);
// [view bind:@title toObject:object withKeyPath:@title options:nil];
[item.view bind:@channelID toObject:object withKeyPath:@channelID
options:nil];
//NSLog(@test);
//NSLog(@%@,object);
return item;
}
self.collectionView = [[ChannelCollectionView alloc]
initWithFrame:NSMakeRect(10, 0, width, self.splitview.frame.size.height)];
[self.collectionView setItemPrototype:[ChannelViewItemController new]];
[self.collectionView setMaxNumberOfRows:1];
[self.collectionView setAutoresizingMask:(NSViewMinXMargin | NSViewWidthSizable
| NSViewMaxXMargin | NSViewMinYMargin | NSViewHeightSizable|
NSViewMaxYMargin)];
[self.collectionView setAutoresizesSubviews:YES];
[self.collectionView bind:NSContentBinding toObject:self.channelController
withKeyPath:@arrangedObjects options:nil];
ChannelViewItemController:
@implementation ChannelViewItemController
-(void)loadView {
[self setView:[[ChannelView alloc] initWithFrame:NSZeroRect]];
}
@end
The actual value is passed to the setter method, but just not held by the
property I think, but why? Tried multiple properties, strong, readwrite atomic
or nonatmoic but thats not helping.
What is the thing to get the NSCollectionView set up with bindings?
Thanks
Benjamin
___
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: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
Re-using a single NSDocument instance to represent several different files is certainly atypical… But, I suspect the problem here is that you're not using File Coordination when reading in the contents of the new file. By not doing that, you're not giving File Coordination the hint that it needs to check back with your NSFilePresenter (the NSDocument) for its presentedItemURL. When you read in the contents of the new file you should: 1) Start a File Access with -performSynchronousFileAccessUsingBlock: or -performAsynchronousFileAccessUsingBlock 2) Create an NSFileCoordinator instance with the NSDocument as the NSFilePresenter passed in the initializer. 3) Using that NSFileCoordinator, take a coordinated read of the target file 4) Inside the coordinated read: read the contents of the new file (-revertToContentsOfURL:ofType:error: is probably the most correct here, as it will update -fileURL, -fileModificationDate, -fileType, change counts, and other internal state as necessary) After the coordinated read, NSFileCoordinator should re-invoke -presentedItemURL (which returns [self fileURL] by default), notice the URL has changed, and disassociate the NSFilePresenter state from the previous URL. This should prevent you from getting any unwanted NSFilePresenter messages. -KP On Sep 16, 2013, at 10:04 AM, Brian Clark ba-cl...@comcast.net wrote: On Sep 16, 2013, at 4:38 AM, Mike Abdullah mabdul...@karelia.com wrote: On 14 Sep 2013, at 21:14, Brian Clark ba-cl...@comcast.net wrote: I'm hoping someone can suggest the correct way to deal with the following problem. For an image viewing app i display a file in the usual way in an NSDocument. setFileURL: is properly called by NSDocument's _initWithContentsOfURL:ofType:error:. I now want to display the next file in the folder, and move the old file to the Trash. To do this I do the necessary file reading tasks and call setFileURL: with the new file URL. I then move the old file to the trash (using NSFileManager 's trashItemAtURL:resultingItemURL:error: but using different methods gives the same result.) What are the necessary file reading tasks? Rather than call -setFileURL: yourself, have you tried calling -revertToContentsOfURL:ofType:error: instead? The top of the class documentation briefly notes that it should always be used for re-reading documents. The necessary tasks are readFromURL:ofType:error: and the other chores associated with setting up the document state for the different image file. Using -revertToContentsOfURL:ofType:error: instead does not work. After doing this NSDocument still seems to treat the old URL as the file's document, and I still get presentedItemDidMoveToURL: for the old file URL when it is moved to the Trash AFTER I-ve called revertToContentsOfURL:ofType:error:. While revertToContentsOfURL:ofType:error: may work correctly for the cases for which I guess it was intended (as described by the NSDocument Class Reference), it doesn't seem to work for this case, for reasons unknown. The best work-around I've found is to add a file reference URL to my NSDocument subclass, and set it in an override of setFileURL:. Then in an override of presentedItemDidMoveToURL: I test if the saved file reference URL is the same as the new URL, and do nothing if they're not the same file. That seems to work, but it's a bit of a hack, and I'd really like to understand if NSDocument is simply broken in this regard, or why setFileURL: does not work and what is the correct and reliable way to change the URL for an open document. ___ 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/kperry%40apple.com This email sent to kpe...@apple.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: Progress for archiving/dearchiving
On 16/09/2013, at 8:08 PM, Jeffrey Oleander jgo...@yahoo.com wrote: Yes, of course, you can. But that is too late. You need to know the total, the max, before you display the progress bar Ah, true but in fact displaying progress when dearchiving is more important. Documents get saved in the background, so in some ways it doesn't matter how long they take, but when waiting for a very big file to open, there can be a noticeable delay (maybe 10-15 seconds) between the Open dialog going away and the document appearing - I want to give the user some feedback that something is happening. So I can accept a dearchiving-only solution based on a saved count. --Graham ___ 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: Progress for archiving/dearchiving
On 16/09/2013, at 6:51 PM, Jeffrey Oleander jgo...@yahoo.com wrote: I'll bite. If you want to know the total number of objects to be archived, then you need to count them, at some time or another. To count them, you need to walk the object tree before you start actually archiving... which may take a significant fraction of the time it takes to archive. I can count them as I archive, using the delegate. Then, you could make sure it's the first thing that is archived, and hence the first thing unarchived... after which you can display/update the progress bar. It can actually be the last thing archived, but the first thing unarchived (you can do that with keyed archiving). But it might also be something that can be stored in my info file rather than the archive itself. What I was sort of hoping was that there was a way to figure out from the archive how many objects there were without having to archive the number explicitly. For example, the root level of an archive is a dictionary, which has a count, but that's only the top level. Going more into the way archives are actually stored, maybe the $top array might be a more accurate count? Dunno, I guess I'll have to experiment. --Graham ___ 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: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
On Sep 16, 2013, at 12:24 PM, Kevin Perry kpe...@apple.com wrote: Re-using a single NSDocument instance to represent several different files is certainly atypical… True, and I don't know what other similar applications so, but for some applications that are viewers it makes sense to let the user move forwards and backwards through a folder to display the file using the same window rather than opening and closing a window for each file. IT's mre efficient and a more pleasant experience for the user. But, I suspect the problem here is that you're not using File Coordination when reading in the contents of the new file. By not doing that, you're not giving File Coordination the hint that it needs to check back with your NSFilePresenter (the NSDocument) for its presentedItemURL. When you read in the contents of the new file you should: 1) Start a File Access with -performSynchronousFileAccessUsingBlock: or -performAsynchronousFileAccessUsingBlock 2) Create an NSFileCoordinator instance with the NSDocument as the NSFilePresenter passed in the initializer. 3) Using that NSFileCoordinator, take a coordinated read of the target file 4) Inside the coordinated read: read the contents of the new file (-revertToContentsOfURL:ofType:error: is probably the most correct here, as it will update -fileURL, -fileModificationDate, -fileType, change counts, and other internal state as necessary) Thanks! That seems to have worked. It *is* necessary to use -revertToContentsOfURL:ofType:error: rather than -readFromURL:ofType:error:. And it's necessary as you suggested to do this inside a File Access with an NSFileCoordinator. Simply using -revertToContentsOfURL:ofType:error: without these doesn't work. Thanks for your help. ___ 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: Progress for archiving/dearchiving
Another angle worth looking at: Depending on the output format you're using with NSKeyedArchiver, your file might already contain an object count, even if the API doesn't expose it. According to the Cocotron source[1], the binary plist format actually does this. It won't correspond exactly to the number of objects encoded using NSCoding since it represents the number of plist objects, but may be close enough to give an indication of progress. [1]: http://cocotron.googlecode.com/svn/trunk/Foundation/NSPropertyList/NSPropertyListReader_binary1.m On 16 September 2013 18:25, Graham Cox graham@bigpond.com wrote: On 16/09/2013, at 6:51 PM, Jeffrey Oleander jgo...@yahoo.com wrote: I'll bite. If you want to know the total number of objects to be archived, then you need to count them, at some time or another. To count them, you need to walk the object tree before you start actually archiving... which may take a significant fraction of the time it takes to archive. I can count them as I archive, using the delegate. Then, you could make sure it's the first thing that is archived, and hence the first thing unarchived... after which you can display/update the progress bar. It can actually be the last thing archived, but the first thing unarchived (you can do that with keyed archiving). But it might also be something that can be stored in my info file rather than the archive itself. What I was sort of hoping was that there was a way to figure out from the archive how many objects there were without having to archive the number explicitly. For example, the root level of an archive is a dictionary, which has a count, but that's only the top level. Going more into the way archives are actually stored, maybe the $top array might be a more accurate count? Dunno, I guess I'll have to experiment. --Graham ___ 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/devereux.chris%40gmail.com This email sent to devereux.ch...@gmail.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: Very strange Xpc magic
On 16 Sep 2013, at 22:13, Charles Srstka cocoa...@charlessoft.com wrote:
On Sep 16, 2013, at 3:22 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
ree =[ aCo remoteObjectProxyWithErrorHandler: ^(NSError *err)
{
// if helperName is not running
(always the case) and
// MAGIC_BUG_REMOVAL is NOT
defined, then the next line will never print:
NSLog(@%s MAGIC_ERROR:
%@,__FUNCTION__, err);
}
];
What is the error that gets logged here?
2013-09-16 22:13:33.946 XpcTest[31422:303] __48-[T1aAppDelegate
applicationDidFinishLaunching:]_block_invoke MAGIC_ERROR: Error
Domain=NSCocoaErrorDomain Code=4099 Couldn’t communicate with a helper
application.
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
Re: Very strange Xpc magic
On Sep 16, 2013, at 10:16 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: If (and only if) MAGIC_BUG_REMOVAL is defined, I see: Error Domain=NSCocoaErrorDomain Code=4099 Couldn’t communicate with a helper application. Makes sense, as there just is no helper application named: something.very.silly. Make sure you've got the Mach service name for your helper registered in your helper's launchd plist. If it's set up correctly, your helper should automatically launch when the client app tries to communicate with its Mach service name. Charles ___ 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: Progress for archiving/dearchiving
On 16/09/2013, at 4:25 PM, Chris Devereux devereux.ch...@gmail.com wrote: How about tracking the number of written objects when saving the document, then encoding an additional key containing the object count at the top level of the archive? This could then be retrieved before decoding the root object. A possible problem with this idea is that it might require the data for the root object to be read into memory before the count can be read. Maybe this wouldn't be a problem with a binary format --- I don't know enough about the implementation of NSKeyedArchiver/Unarchiver to be sure. I was thinking along these lines but I was hoping to come up with something that would work for existing archives that don't have the extra info. I don't know how much lazy loading NSKeyedUnarchiver does - it might get read or mapped into memory anyway. Perhaps there's a fairly quick way to count the number of objects in it? My file format is actually a package that has an auxiliary plist independent of the archive, so I could store a value there which would avoid loading the archive just to get that number, but that would only be for archives I write in future. --Graham ___ 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: Very strange Xpc magic
On 16 Sep 2013, at 22:21, Charles Srstka cocoa...@charlessoft.com wrote: On Sep 16, 2013, at 10:16 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: If (and only if) MAGIC_BUG_REMOVAL is defined, I see: Error Domain=NSCocoaErrorDomain Code=4099 Couldn’t communicate with a helper application. Makes sense, as there just is no helper application named: something.very.silly. Make sure you've got the Mach service name for your helper registered in your helper's launchd plist. If it's set up correctly, your helper should automatically launch when the client app tries to communicate with its Mach service name. Maybe I was not very clear. The problem is NOT that the helper app does not start. There just is no helper app, there is nothing which has a MachService called something.very.silly. The problem is, that the error block, which prints MAGIC_ERROR, does only get called when there is an NSLog right in front of it. This makes no sense (to me). Kind regards, 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
Re: Very strange Xpc magic
On 16 Sep 2013, at 23:16, Charles Srstka cocoa...@charlessoft.com wrote: On Sep 16, 2013, at 10:27 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: Maybe I was not very clear. The problem is NOT that the helper app does not start. There just is no helper app, there is nothing which has a MachService called something.very.silly. The problem is, that the error block, which prints MAGIC_ERROR, does only get called when there is an NSLog right in front of it. This makes no sense (to me). I just tried your code on my machine, and whether the error logs or not seems fairly random. Whether or not your define is present, I sometimes get the error log and sometimes not, and repeatedly running the app (or putting the code in an IBAction instead of applicationDidFinishLaunching: and repeatedly pressing a button to invoke it) results in a different outcome each time. There might be a race condition in the framework or something. I also did some more testing. The magic does not lie in the NSLog() but in the elapsed time. On my machine the sending of a message to remoteObjectProxy must NOT be done earlier than ca. 180 μsec after [NSXPCConnection resume]. Without anything in between these are only 50 μsec apart. Not enough. NSLog() adds a sufficient delay of almost 250 μsec. But usleep(130) also does the trick. Code: #includemach/mach_time.h ... aCo.remoteObjectInterface = [ NSXPCInterface interfaceWithProtocol: @protocol(ZipProtocol) ]; [ aCo resume]; uint64_t machTime1 = mach_absolute_time(); id ree =[ aCo remoteObjectProxyWithErrorHandler: ^(NSError *err)... usleep(130); uint64_t machTime2 = mach_absolute_time(); [ ree command:... uint64_t elapsed = machTime2 - machTime1; double microSec = elapsed * 1e-3; Have you filed a Radar report on this yet? Not yet. Will do tomorrow. Kind regards, 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
Re: Very strange Xpc magic
On 16 Sep 2013, at 23:13, Keary Suska cocoa-...@esoteritech.com wrote: On Sep 16, 2013, at 9:27 AM, Gerriet M. Denkmann wrote: On 16 Sep 2013, at 22:21, Charles Srstka cocoa...@charlessoft.com wrote: On Sep 16, 2013, at 10:16 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: If (and only if) MAGIC_BUG_REMOVAL is defined, I see: Error Domain=NSCocoaErrorDomain Code=4099 Couldn’t communicate with a helper application. Makes sense, as there just is no helper application named: something.very.silly. Make sure you've got the Mach service name for your helper registered in your helper's launchd plist. If it's set up correctly, your helper should automatically launch when the client app tries to communicate with its Mach service name. Maybe I was not very clear. The problem is NOT that the helper app does not start. There just is no helper app, there is nothing which has a MachService called something.very.silly. The problem is, that the error block, which prints MAGIC_ERROR, does only get called when there is an NSLog right in front of it. This makes no sense (to me). Unless I didn't understand, your original post indicated that the issue was with the macro define. Has this changed? If not, I would run the file manually through the preprocessor and examine the output. As I just explained in some reply in this thread: if MAGIC_BUG_REMOVAL is defined, then some sufficient delay is added by printing NSLog(). Kind regards, 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
Re: Very strange Xpc magic
On Sep 16, 2013, at 11:33 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: I also did some more testing. The magic does not lie in the NSLog() but in the elapsed time. On my machine the sending of a message to remoteObjectProxy must NOT be done earlier than ca. 180 μsec after [NSXPCConnection resume]. Without anything in between these are only 50 μsec apart. Not enough. NSLog() adds a sufficient delay of almost 250 μsec. But usleep(130) also does the trick. Yep, sounds like a race condition for sure. Charles ___ 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: Progress for archiving/dearchiving
On 2013 Sep 16, at 08:53, Graham Cox wrote: If I wanted to add some sort of progress reporting to archiving and dearchiving, what's a good way to do it? The problem seems to me to know what the 'count' of things read from/written to the file is to set the progress max value. Since the delegate gets called for each object instantiated, that part of it isn't a problem, I can just bump a counter. Counting the objects rather than actual bytes is probably as fine-grained as I need to get. I'll bite. If you want to know the total number of objects to be archived, then you need to count them, at some time or another. To count them, you need to walk the object tree before you start actually archiving... which may take a significant fraction of the time it takes to archive. Then, you could make sure it's the first thing that is archived, and hence the first thing unarchived... after which you can display/update the progress bar. Yah, I know; ugly, but unavoidable as far as I know. ___ 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: Progress for archiving/dearchiving
On 17 Sep 2013, at 00:26, Graham Cox graham@bigpond.com wrote: What I was sort of hoping was that there was a way to figure out from the archive how many objects there were without having to archive the number explicitly. For example, the root level of an archive is a dictionary, which has a count, but that's only the top level. Going more into the way archives are actually stored, maybe the $top array might be a more accurate count? Dunno, I guess I'll have to experiment. Every archive has a $objects table at the end. The size of it is easily readable. (But doing so might break whenever Apple changes the format). Kind regards, 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
