Strange Analyser Warning/Error
Hi,
Look at this code:
myUserInfo = [self.pUserIDDict objectForKey: theUserInfo.pUserID];
if (myUserInfo != nil)
{
LTWAssertAlways(@"myUserInfo - Dupe ID!!");
}
if (theUserInfo.pUserID != nil)
//Remove this Line for Warning
[self.pUserIDDict setObject: theUserInfo forKey: theUserInfo.pUserID];
//Warning on this line!
}
I get a warning saying that Key argument for setObjectForKey cannot be nil? I
am wondering why it suddenly started moaning about this here and not other
places were it is used and could be nil, like this:
myUserInfo = [self.pUserIDDict objectForKey: theUserInfo.pUserID];
This is the only place I’ve seen this warning and I’m using keys that could be
nil in lots of places (without any problems as I obviously make sure that I
don’t pass a nil…..
All the Best
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
Re: Strange Analyser Warning/Error
> On Feb 8, 2016, at 7:15 AM, Dave wrote:
>
> Look at this code:
>
> myUserInfo = [self.pUserIDDict objectForKey: theUserInfo.pUserID];
> if (myUserInfo != nil)
> {
> LTWAssertAlways(@"myUserInfo - Dupe ID!!");
> }
>
> if (theUserInfo.pUserID != nil)
> //Remove this Line for Warning
> [self.pUserIDDict setObject: theUserInfo forKey: theUserInfo.pUserID];
> //Warning on this line!
> }
>
>
> I get a warning saying that Key argument for setObjectForKey cannot be nil? I
> am wondering why it suddenly started moaning about this here and not other
> places were it is used and could be nil, like this:
>
> myUserInfo = [self.pUserIDDict objectForKey: theUserInfo.pUserID];
>
> This is the only place I’ve seen this warning and I’m using keys that could
> be nil in lots of places (without any problems as I obviously make sure that
> I don’t pass a nil…..
In the case where you do not see a warning, you are calling -[NSDictionary
objectForKey:] which accepts a nil key value (returning nil).
In the case where you do see a warning, you are calling -[NSMutableDictionary
setObject:forKey:] which does not accept a nil key value (nor a nil object
value) and will throw an exception if you attempt to do so at runtime.
___
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: Strange Analyser Warning/Error
> > In the case where you do not see a warning, you are calling -[NSDictionary > objectForKey:] which accepts a nil key value (returning nil). Ah, for some reason I thought that is was illegal to pass a nil key to objectForkey: Thanks 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
Re: Strange Analyser Warning/Error
On Feb 8, 2016, at 7:15 AM, Dave wrote:
>
> myUserInfo = [self.pUserIDDict objectForKey: theUserInfo.pUserID];
> if (myUserInfo != nil)
> {
> LTWAssertAlways(@"myUserInfo - Dupe ID!!");
> }
>
> if (theUserInfo.pUserID != nil)
> //Remove this Line for Warning
> [self.pUserIDDict setObject: theUserInfo forKey: theUserInfo.pUserID];
> //Warning on this line!
> }
>
>
> I get a warning saying that Key argument for setObjectForKey cannot be nil? I
> am wondering why it suddenly started moaning about this here and not other
> places were it is used and could be nil, like this:
>
> myUserInfo = [self.pUserIDDict objectForKey: theUserInfo.pUserID];
>
> This is the only place I’ve seen this warning and I’m using keys that could
> be nil in lots of places (without any problems as I obviously make sure that
> I don’t pass a nil…..
I suspect that you haven't shown us the whole code.
The analyzer does not necessarily check every possible variable or property as
to whether it could be nil in each code path. That's because programs can be
written such that that's never the case, but in a way that the analyzer can't
tell that, and to warn about every possible such situation would make the
analyzer useless due to too many false positives.
But, if your code _explicitly introduces_ the possibility that a value might be
nil, with a check for that, then the analyzer then does check whether it may be
nil in a place where it's not allowed. So, I suspect your code has a check
which explicitly introduces the possibility of theUserInfo being nil, making
the analyzer consider that.
If you are using an assert to document that theUserInfo is not nil, then: a)
your assert should boil down to a function which is annotated with
__attribute__((__noreturn__)); and b) you should make the assertion macro the
thing which tests the condition, rather than using an "if" statement combined
with an assert-always macro like shown in the above code. The reason for (b)
is that, if there's a compilation mode where the assert macros are disabled
(which I don't recommend), then you want the check of the condition to also go
away so the analyzer isn't confused.
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: Strange Analyser Warning/Error
On Feb 8, 2016, at 8:31 AM, Dave wrote: > >> >> In the case where you do not see a warning, you are calling -[NSDictionary >> objectForKey:] which accepts a nil key value (returning nil). > > Ah, for some reason I thought that is was illegal to pass a nil key to > objectForkey: It is illegal. Michael is incorrect. In general, when a method accepts an object pointer argument, it is illegal to pass nil unless it's specifically documented to be legal. 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: Strange Analyser Warning/Error
On Feb 8, 2016, at 10:01 AM, Ken Thomases wrote: >>> >>> In the case where you do not see a warning, you are calling -[NSDictionary >>> objectForKey:] which accepts a nil key value (returning nil). >> >> Ah, for some reason I thought that is was illegal to pass a nil key to >> objectForkey: > > It is illegal. Michael is incorrect. In general, when a method accepts an > object pointer argument, it is illegal to pass nil unless it's specifically > documented to be legal. The nil key pointer is a red herring. -[NSDictionary objectForKey:] can return nil if the dictionary doesn’t contain a value for the key. The analyser is correctly flagging that the code doesn’t handle this case. I suspect the reason that this started recently is that Apple recently started annotation the Cocoa headers as to what can and can’t accept/return nil in support of Swift. HTH, -Steve ___ 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: Strange Analyser Warning/Error
> On Feb 8, 2016, at 8:09 AM, Steve Sisak wrote: > > The nil key pointer is a red herring. -[NSDictionary objectForKey:] can > return nil if the dictionary doesn’t contain a value for the key. > > The analyser is correctly flagging that the code doesn’t handle this case. No, it isn’t, because that case doesn’t occur here. The value returned from -objectForKey (myUserInfo) is never used as a method parameter in that code snippet. I think you’re mixing it up with theUserInfo. I’ve been getting an increasing number of apparently nonsensical analyzer warnings (mostly in C++ code) in the past year or so (since Xcode 6?). They tend to be very complex, with up to a dozen steps going through multiple functions, but end up warning about something useless or impossible. Anyway, analyzer issues should be discussed on xcode-users… —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
CoreImage filters spam the log on El-Capitan?
Hello friends. Please pardon this short reprise, but I really need help - maybe someone can shed some light on my problem. I’m capturing video using AVFoundation APIs for preview only (OS-X app) following an old sample-code from Apple (AVRecorder). My view hierarchy is simple. An NSView (WantsLayer=YES) with a AVCaptureVideoPreviewLayer as sublayer. This worked for several years now. Recently I added modest CoreImage CIFilter (CISharpenLuminance) to the video preview like so: 1. I call setLayerUsesCoreImageFilters:YES on the NSView hosting the video capture. 2. I programmatically create and apply the filter to the AVCaptureVideoPreviewLayer. From that moment on - I see strange warnings in the console: "Fallingback to pbuffer. FBO status is 36054” for every captured video frame (30 a sec…). In other mailing list, someone claims the problem only happens with OS-X.11, and only with YUV pixel formats. He found the problem in another Apple sample code -AVGreenScreenPlayer. Unfortunately the video devices I use only provide YUV pixel formats, and my client Macs only run OS-X 10.11. Can someone tell me what is the source of this error line? what is FBO, and what has fallen-back? where is a documentation of the error, and is there a workaround the problem? Any hint will be greatly appreciated. Here’s my code with the new additions marked with // <— new code // Get our videoView and its CALayer, to draw video and other stuff on it. CALayer *videoViewLayer = [[delegate videoView] layer]; // here the delegate is an NSWindowController. NSRect bounds = [videoViewLayer bounds]; [[delegate videoView] setLayerUsesCoreImageFilters:YES]; // <— new code // Create and Add videoCapture layer to our videoView. AVCaptureVideoPreviewLayer *videoPreviewLayer = [[AVCaptureVideoPreviewLayer alloc] initWithSession:[self session]]; [videoPreviewLayer setBackgroundColor:CGColorGetConstantColor(kCGColorClear)]; [videoPreviewLayer setVideoGravity:AVLayerVideoGravityResize]; [videoPreviewLayer setFrame:bounds]; [videoPreviewLayer setAutoresizingMask:kCALayerWidthSizable | kCALayerHeightSizable]; CIFilter *sharpenLuminance = [CIFilter filterWithName:@"CISharpenLuminance"];// <— new code [sharpenLuminance setValue:@0.5 forKey:kCIInputSharpnessKey]; // <—new code [videoPreviewLayer setFilters:@[sharpenLuminance]]; // <— new code [videoViewLayer addSublayer:videoPreviewLayer]; ___ 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
CoreImage filters spam the log on El-Capitan?
Hello friends. Please pardon this short reprise, but I really need help - maybe someone can shed some light on my problem. I’m capturing video using AVFoundation APIs for preview only (OS-X app) following an old sample-code from Apple (AVRecorder). My view hierarchy is simple. An NSView (WantsLayer=YES) with a AVCaptureVideoPreviewLayer as sublayer. This worked for several years now. Recently I added modest CoreImage CIFilter (CISharpenLuminance) to the video preview like so: 1. I call setLayerUsesCoreImageFilters:YES on the NSView hosting the video capture. 2. I programmatically create and apply the filter to the AVCaptureVideoPreviewLayer. From that moment on - I see strange warnings in the console: "Fallingback to pbuffer. FBO status is 36054” for every captured video frame (30 a sec…). In other mailing list, someone claims the problem only happens with OS-X.11, and only with YUV pixel formats. He found the problem in another Apple sample code -AVGreenScreenPlayer. Unfortunately the video devices I use only provide YUV pixel formats, and my client Macs only run OS-X 10.11. Can someone tell me what is the source of this error line? what is FBO, and what has fallen-back? where is a documentation of the error, and is there a workaround the problem? Any hint will be greatly appreciated. Here’s my code with the new additions marked with // <— new code // Get our videoView and its CALayer, to draw video and other stuff on it. CALayer *videoViewLayer = [[delegate videoView] layer]; // here the delegate is an NSWindowController. NSRect bounds = [videoViewLayer bounds]; [[delegate videoView] setLayerUsesCoreImageFilters:YES]; // <— new code // Create and Add videoCapture layer to our videoView. AVCaptureVideoPreviewLayer *videoPreviewLayer = [[AVCaptureVideoPreviewLayer alloc] initWithSession:[self session]]; [videoPreviewLayer setBackgroundColor:CGColorGetConstantColor(kCGColorClear)]; [videoPreviewLayer setVideoGravity:AVLayerVideoGravityResize]; [videoPreviewLayer setFrame:bounds]; [videoPreviewLayer setAutoresizingMask:kCALayerWidthSizable | kCALayerHeightSizable]; CIFilter *sharpenLuminance = [CIFilter filterWithName:@"CISharpenLuminance"];// <— new code [sharpenLuminance setValue:@0.5 forKey:kCIInputSharpnessKey]; // <—new code [videoPreviewLayer setFilters:@[sharpenLuminance]]; // <— new code [videoViewLayer addSublayer:videoPreviewLayer]; ___ 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: CoreImage filters spam the log on El-Capitan?
On Feb 8, 2016, at 2:41 PM, Motti Shneor wrote: > > […] I see strange warnings in the console: "Fallingback to pbuffer. FBO > status is 36054” for every captured video frame (30 a sec…). > Can someone tell me what is the source of this error line? what is FBO, and > what has fallen-back? where is a documentation of the error, and is there a > workaround the problem? FBO is framebuffer object, a feature of OpenGL, which Core Image is using under the hood. The status is GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT. Due to the problem using an FBO, Core Image has switched (fallen back) to using a PBuffer (pixel buffer), an old, deprecated feature of OpenGL, instead. I'm afraid I don't know why using an FBO has failed. You might try the mac-opengl or quartz-dev mailing lists. You can also open a bug report with Apple and then open a developer technical support incident with them asking for a workaround for the bug. 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
Just a quick verification on a bad access cause.
iOS 9.x, Xcode 7.1.
I'm sitting in the middle of the debugger, looking at some code I inherited and
in a regular service, BLAM, EXC_BAD_ACCESS.
This code uses ivars that are named the same as the properties :/ and what I
noticed, we have this statement where the bad access is appearing:
if ( [myIVar respondsToSelector:@selector(someMethod)] {
EXC_BAD_ACCESS (code=1, address=0x143545358)
I did a po on myiVar and I get an address or 0x00014f05ee00
I'd expect that the bad access would be of the iVar, yet the addresses are
different. Is this a red herring?
Also, I'd prefer to use the property not the iVar as I've found these much
safer in the past for accessing internal objects without causing access issues.
Am I correct here?
This is a wonderful race condition that is hard to reproduce. I'd like to get
some professional opinions on my assumptions and approach before I leave the
debugger.
Thanks in advance for any pointers, dereferenced or not (humor intended).
Alex Zavatone
___
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
An API for Airplane mode on iOS?
On iOS, we're running into particular issues with one user who puts his device in Airplane mode overnight. I'm using reachability classes to determine if we can reach our web services IP and monitoring all reachability enums, but would be "really nice™" is if there is a published API to read the position of the Airplane Mode setting. All my sniffing around tells me that there is no formal API for this. Am I correct in assuming that this is true? Thanks in advance. Alex Zavatone ___ 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: An API for Airplane mode on iOS?
> On Feb 8, 2016, at 13:55, Alex Zavatone wrote: > > On iOS, we're running into particular issues with one user who puts his > device in Airplane mode overnight. > > I'm using reachability classes to determine if we can reach our web services > IP and monitoring all reachability enums, but would be "really nice™" is if > there is a published API to read the position of the Airplane Mode setting. > > All my sniffing around tells me that there is no formal API for this. Am I > correct in assuming that this is true? I don't believe that there is. That said, it probably wouldn't help in this case. You can easily turn on Airplane Mode and then turn on WiFi and/or Bluetooth (i.e. you can still have a working internet connection even if Airplane Mode is on). As always, it is recommended to test for specific functionality (i.e. use reachability in this case) rather than reading settings and trying to interpret what each of their possible permutations actually means. > Thanks in advance. > > Alex Zavatone > ___ > > 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/clarkcox3%40gmail.com > > This email sent to clarkc...@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: Just a quick verification on a bad access cause.
> On Feb 8, 2016, at 1:47 PM, Alex Zavatone wrote:
>
> if ( [myIVar respondsToSelector:@selector(someMethod)] {
> EXC_BAD_ACCESS (code=1, address=0x143545358)
> I did a po on myiVar and I get an address or 0x00014f05ee00
0x143545358 is probably the (bogus) class-info pointer it got from the object’s
‘isa’ pointer. So in this case the myIVar pointer itself isn’t itself obviously
bad, but it is pointing to garbage. Most likely it used to be a valid object
but was dealloced and the memory’s been reused for something else.
NSZombieEnabled is the obvious thing to try here. And/or the address sanitizer.
> Also, I'd prefer to use the property not the iVar as I've found these much
> safer in the past for accessing internal objects without causing access
> issues.
> Am I correct here?
I always use ivars because it’s much more efficient in code size and clock
cycles. The only case where using ivars directly can bite you is if either the
ivar or the property will be modified on another thread, since ARC’s inlined
setter code isn't thread-safe.
But I always prefix ivars with an underscore to make it obvious that they have
different scope from locals.
—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: An API for Airplane mode on iOS?
> On Feb 8, 2016, at 1:55 PM, Alex Zavatone wrote: > > I'm using reachability classes to determine if we can reach our web services > IP and monitoring all reachability enums, but would be "really nice™" is if > there is a published API to read the position of the Airplane Mode setting. Do you need to treat airplane mode differently than just turning off WiFi (and cellular, if the device has it), or simply being out of reach of a base station? Generally it’s enough to know that the host isn’t reachable, or that there are no available network interfaces. —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
Hierarchical split views and auto layout
I’m trying to implement rather complex UI, with a lot of views involved. The main window should contain one main view (module), which cannot be removed, and then users can add arbitrary number of additional specific views (modules) and arrange them on positions to their liking. Those additional views should also be resizable with user action, so I decided to use split views, which led to a view hierarchy with split views inside split views (inside split views…). The code use auto layout, thus NSSplitViewController and NSSplitViewItem instances. I’m having a problem which is probably related to assigning a particular holding priority values to particular split view items, in order to achieve desired resizing behaviour of involved views when window is resized and/or a particular split view divider dragged. Since it’s really hard to explain with words how UI looks and works (or should work) and what the problem is, I recorded a video (4:30 minutes) showing the issue. Please don’t mind a bit poor sound quality and my narrative skills. I gave my best to explain what’s happening. I’d be very thankful to anyone having the time to look at the video and try to figure out what could be the root of the problem. If after watching anyone has questions about implementation, code, etc, I’d be happy to provide more information. The link for the video: https://www.dropbox.com/s/1xbl5allc35b6l2/splitviews.mov?dl=0 One final note: in moments of desperation I considered implementing the whole UI without using auto layout and do all heavy work in split view’s delegate, but that would require major redesign and rewrite of current UI code that I quickly abandoned the idea. Thanks in advance, -- Dragan ___ 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: An API for Airplane mode on iOS?
According to the docs on Reachability (possibly lost in the mists of time...), Reachability isn't really designed to tell you whether your net access *will* succeed, but to give you reasons that your last access *failed.* Yes, I was surprised too, but after adding an initial access to prime the network state (HEAD request to a designated "always up" URL), we got most of the behavior we needed. > On Feb 8, 2016, at 1:55 PM, Alex Zavatone wrote: > > On iOS, we're running into particular issues with one user who puts his > device in Airplane mode overnight. > > I'm using reachability classes to determine if we can reach our web services > IP and monitoring all reachability enums, but would be "really nice™" is if > there is a published API to read the position of the Airplane Mode setting. > > All my sniffing around tells me that there is no formal API for this. Am I > correct in assuming that this is true? > > Thanks in advance. > > Alex Zavatone > ___ > > 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/glenn%40austinsoft.com > > This email sent to gl...@austinsoft.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: Hierarchical split views and auto layout
On Feb 8, 2016, at 15:07 , Dragan Milić wrote: > > I’d be very thankful to anyone having the time to look at the video and try > to figure out what could be the root of the problem. If after watching anyone > has questions about implementation, code, etc, I’d be happy to provide more > information. I’m really lousy at understanding autolayout, but I did finally go watch the video, and I think the problem is that your layout is ambiguous — though perhaps not in a way that autolayout thinks is worth complaining about. Your argument on how the more complex vertical split structure should work is hierarchical — you expect that the 2 parts of the outer split should resize proportionally, and then that the 2 parts of the inner split should resize proportionally *within the proportionate resizing already done*. This isn’t my understanding of how autolayout works. AFAIK, autolayout considers all constraints with priority 250 equally, regardless of where they come from. If that’s true, then vertical resizing sees 3 areas that can stretch vertically, all with priority 250. Since there are no other constraints on this, autolayout can do whatever it wants with the pieces, with the results you saw. I don’t think it’s obliged to “share” the pain equally between the candidate adjustments, although it may do so if it thinks that’s the best compromise. What happens if you decrease the holding priority by 1 for each level of nesting in your split views? It sorta seems to me that should do what you want. But, as I say, autolayout confounds me, and autolayout in split views confounds me even more, so … ___ 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: CoreImage filters spam the log on El-Capitan?
Thank you so much. You provided all the help I needed. I’ll follow all your suggestions, and have already opened a DTS with Apple’s own sample code as a demo of the problem. In past experience with them, If the issue is an Apple bug - they usually “refund” you a DTS incident. One curious thing though — weren’t apple coming off openGL and didn’t they claim Mac OS El-Capitan is all “Metal” now? B.T.W - for some strange reason my e-mails to the list appear twice — I don’t know who is duplicating them… > On 8 בפבר׳ 2016, at 10:55 אח׳, Ken Thomases wrote: > > On Feb 8, 2016, at 2:41 PM, Motti Shneor wrote: >> >> […] I see strange warnings in the console: "Fallingback to pbuffer. FBO >> status is 36054” for every captured video frame (30 a sec…). > >> Can someone tell me what is the source of this error line? what is FBO, and >> what has fallen-back? where is a documentation of the error, and is there a >> workaround the problem? > > FBO is framebuffer object, a feature of OpenGL, which Core Image is using > under the hood. The status is GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT. Due to > the problem using an FBO, Core Image has switched (fallen back) to using a > PBuffer (pixel buffer), an old, deprecated feature of OpenGL, instead. > > I'm afraid I don't know why using an FBO has failed. You might try the > mac-opengl or quartz-dev mailing lists. You can also open a bug report with > Apple and then open a developer technical support incident with them asking > for a workaround for the bug. > > 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: An API for Airplane mode on iOS?
> On Feb 8, 2016, at 9:45 PM, Glenn L. Austin wrote: > > According to the docs on Reachability (possibly lost in the mists of > time...), Reachability isn't really designed to tell you whether your net > access *will* succeed, but to give you reasons that your last access *failed.* It’s not that surprising. There’s no guarantee that any IP packet will make it across the network, and no way to tell whether a host really is reachable without actually sending a packet to it (and back.) So the only way Reachability could tell you an access *will* succeed would be if it were constantly pinging the server, which is obviously impractical. All Reachability tells you is whether there is an active network interface that can be used to route a packet one hop toward the desired host. —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
