FSEventStreamCreate: BUG in libdispatch client: kevent[EVFILT_WRITE]
I am getting an error in the Console when shutting down a FSEvent monitor
I have verified that [self prefBundlePath] points to a valid directory (a
prefpane bundle).
BUG in libdispatch client: kevent[EVFILT_WRITE] delete: No such file or
directory - 0x2
-(void)addFileEventCallback
{
FSEventStreamContext fsStreamContext = {0, self, NULL, NULL, NULL};
fsStream = FSEventStreamCreate (kCFAllocatorDefault, FSEventCallback,
fsStreamContext, (CFArrayRef) [NSArray arrayWithObject:[self
prefBundlePath]], kFSEventStreamEventIdSinceNow, 3,
kFSEventStreamCreateFlagWatchRoot);
FSEventStreamScheduleWithRunLoop (fsStream, CFRunLoopGetCurrent(),
kCFRunLoopDefaultMode);
FSEventStreamStart (fsStream);
}
-(void)removeFileEventCallback
{
FSEventStreamStop (fsStream);
FSEventStreamUnscheduleFromRunLoop (fsStream, CFRunLoopGetCurrent(),
kCFRunLoopDefaultMode);
FSEventStreamInvalidate (fsStream);
FSEventStreamRelease (fsStream);
}
Ideas?
___
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: FSEventStreamCreate: BUG in libdispatch client: kevent[EVFILT_WRITE]
On Jan 17, 2015, at 2:27 PM, Trygve Inda cocoa...@xericdesign.com wrote:
I am getting an error in the Console when shutting down a FSEvent monitor
I have verified that [self prefBundlePath] points to a valid directory (a
prefpane bundle).
BUG in libdispatch client: kevent[EVFILT_WRITE] delete: No such file or
directory - 0x2
-(void)addFileEventCallback
{
FSEventStreamContext fsStreamContext = {0, self, NULL, NULL, NULL};
fsStream = FSEventStreamCreate (kCFAllocatorDefault, FSEventCallback,
fsStreamContext, (CFArrayRef) [NSArray arrayWithObject:[self
prefBundlePath]], kFSEventStreamEventIdSinceNow, 3,
kFSEventStreamCreateFlagWatchRoot);
FSEventStreamScheduleWithRunLoop (fsStream, CFRunLoopGetCurrent(),
kCFRunLoopDefaultMode);
FSEventStreamStart (fsStream);
}
-(void)removeFileEventCallback
{
FSEventStreamStop (fsStream);
FSEventStreamUnscheduleFromRunLoop (fsStream, CFRunLoopGetCurrent(),
kCFRunLoopDefaultMode);
FSEventStreamInvalidate (fsStream);
FSEventStreamRelease (fsStream);
}
Ideas?
Not so much a Cocoa question, but: are you sure that it's the FSEventStream
tear-down that's causing that log message?
Are both of the above methods being called on the same thread?
You could try removing the call to FSEventStreamUnscheduleFromRunLoop().
FSEventStreamInvalidate() unschedules it, too.
You say that the path being monitored references a valid directory. Is it the
same directory as it was when you set up the FSEventStream? That is, have you
moved or deleted the prefpane bundle that was there and created a new one in
its place? If it has changed, then it's a different inode and any
previously-opened file descriptor would not refer to the one at the path any
more.
Otherwise, can you reproduce it in a simple example program? If so, file a bug
report with Apple.
Regards,
Ken
___
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: drawRect runs twice, bounds are changed in between
On Jan 16, 2015, at 5:30 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 15 Jan 2015, at 07:58, Quincey Morris quinceymor...@rivergatesoftware.com wrote: Putting those two ideas together leads to a better approach. Create the bezier path once, relative to an arbitrary bounding rect — say 1000 x 1000. (But any rect would do.) When you need to draw the path, set the CTM of the context to scale 1000 x 1000 (the reference bounds) to the context’s width x height (the view bounds). Then just draw the original path and AppKit will scale the bezier path for you. That's not the be-all end-all, though. Scaling the CTM scales line widths and heights as well. So if you for example want to skew the path, you'd get lines that are wider than they are tall (kind of calligraphic). Also, changing the CTM means that mouse click coordinates will be in a different coordinate system then your drawing, so if you’re e.g. implementing a graphics editor, you'll have to manually translate the coordinates each time. A better idea might be to have a list of original objects and projected objects. The list of projected objects is generated by transforming the paths. Whenever your view's bounds change, you rebuild this list of projected objects from the originals (thus keeping rounding errors etc. to a minimum as they can't accumulate). The drawing code just draws this projected list. As I don't know where 'temp' comes from in N!K’s code, NSBezierPath* temp; is in the list of declarations. _path is created once, in -(id)initWithCoder:(NSCoder*)coder . _path is scaled to the new size and assigned to temp each time drawRect is called. Thus, there is no error buildup. this may be what's already happening, in which case I find that a better approach than mangling the CTM if your interest is in having a shape drawn crisply in a window. If you're instead looking to scale a drawing (whether vector or otherwise), where you want lines to be skewed, then Quincy.s approach is preferrable. -- Uli Nick ___ 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: FSEventStreamCreate: BUG in libdispatch client: kevent[EVFILT_WRITE]
On Jan 17, 2015, at 2:27 PM, Trygve Inda cocoa...@xericdesign.com wrote:
I am getting an error in the Console when shutting down a FSEvent monitor
I have verified that [self prefBundlePath] points to a valid directory (a
prefpane bundle).
BUG in libdispatch client: kevent[EVFILT_WRITE] delete: No such file or
directory - 0x2
Ideas?
Not so much a Cocoa question, but: are you sure that it's the FSEventStream
tear-down that's causing that log message?
Are both of the above methods being called on the same thread?
You could try removing the call to FSEventStreamUnscheduleFromRunLoop().
FSEventStreamInvalidate() unschedules it, too.
You say that the path being monitored references a valid directory. Is it the
same directory as it was when you set up the FSEventStream? That is, have you
moved or deleted the prefpane bundle that was there and created a new one in
its place? If it has changed, then it's a different inode and any
previously-opened file descriptor would not refer to the one at the path any
more.
Otherwise, can you reproduce it in a simple example program? If so, file a
bug report with Apple.
Regards,
Ken
This simple app does it too:
-(void)applicationDidFinishLaunching:(NSNotification*)notification
{
FSEventStreamReffsStream;
FSEventStreamContext fsStreamContext = {0, self, NULL, NULL, NULL};
fsStream = FSEventStreamCreate (kCFAllocatorDefault, FSMyEventCallback,
fsStreamContext, (CFArrayRef) [NSArray
arrayWithObject:@/Users/trygve/Library/PreferencePanes/MyPane.prefPane],
kFSEventStreamEventIdSinceNow, 3, kFSEventStreamCreateFlagWatchRoot);
FSEventStreamScheduleWithRunLoop (fsStream, CFRunLoopGetCurrent(),
kCFRunLoopDefaultMode);
FSEventStreamStart (fsStream);
FSEventStreamStop (fsStream);
FSEventStreamInvalidate (fsStream);
FSEventStreamRelease (fsStream);
}
void FSMyEventCallback (ConstFSEventStreamRef streamRef, void
*clientCallBackInfo, size_t numEvents, void *eventPaths, const
FSEventStreamEventFlags eventFlags[], const FSEventStreamEventId eventIds[])
{
int i = 1;
}
___
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: Directory navigated to by menu File Open
On 2015 Jan 16, at 21:34, Ken Thomases k...@codeweavers.com wrote:
How about, instead of calling through to super, you simply implement those
methods in the straightforward way by running the Open panel. For
-runModalOpenPanel:forTypes:, set the directoryURL as you want, set
allowedFileTypes with the types array that was passed in, and call -runModal
on the panel and return its result. For
-beginOpenPanel:forTypes:completionHandler:, set the same two properties and
then call -beginWithCompletionHandler: on the panel with the passed-in
completion handler.
The theory is that, if you call through to super, it will do the same thing
except it will set the directoryURL to whatever it thinks is best, replacing
the one you set in your override. So, just don't give it that opportunity.
Hello again, Ken. I think that the method -runModalOpenPanel:forTypes: is only
there for legacy purposes. The method that gets called in Yosemite is instead
-beginOpenPanel:forTypes:completionHandler:. So I performed the experiment you
have suggested here on that method instead.
The TextEdit Apple sample code already overrides this method, and this is where
I tried to -setDiretoryURL: the other day. However, it calls through to super.
To experiment as you suggested, I replaced TextEdit’s DocumentController.m
line 315, which calls to super…
[super beginOpenPanel:openPanel forTypes:types
completionHandler:^(NSInteger result) {
with three lines of code that instead run the open panel directly, giving it
the same completion handler, and, of course, set the directory URL…
[openPanel setDirectoryURL:[NSURL fileURLWithPath:@“/path/to/whatever]] ;
[openPanel setAllowedFileTypes:types] ;
[openPanel beginWithCompletionHandler:^(NSInteger result) {
I built, ran, and clicked in the menu: File Open. Result: It works as
expected. The dialog navigates to /path/to/whatever.
So, yes, this is another workaround that one should consider, with the warning
that I’ve not tested it fully. It is certainly more robust, but more
complicated than my first workaround, setting the NSNavLastRootDirectory in
NSUserDefaults.
___
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
