unsubscribe
unsubscribe
- Subject: unsubscribe
- From: Ben Kazez <email@hidden>
- Date: Tue, 27 May 2014 15:45:59 +0200
On May 27, 2014, at 3:41 PM, email@hidden wrote:
> Send Cocoa-dev mailing list submissions to
> email@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.apple.com/mailman/listinfo/cocoa-dev
> or, via email, send a message with subject or body 'help' to
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cocoa-dev digest..."
>
>
> Today's Topics:
>
> 1. Mutating NSLayoutConstraint -constant at run time
> (Jonathan Mitchell)
> 2. Re: EXC_BAD_ACCESS in NSData (Jens Alfke)
> 3. Re: EXC_BAD_ACCESS in NSData (Graham Cox)
> 4. Re: EXC_BAD_ACCESS in NSData (Jens Alfke)
> 5. Re: EXC_BAD_ACCESS in NSData (Uli Kusterer)
> 6. Re: EXC_BAD_ACCESS in NSData (Graham Cox)
> 7. Re: EXC_BAD_ACCESS in NSData (Charles Srstka)
> 8. Re: Understanding ARC (Jamie Ojomoh)
> 9. AVFoundation video not playing in root mode (Navneet Kumar)
> 10. Re: AVFoundation video not playing in root mode (Kyle Sluder)
> 11. Re: NSPopover + Bindings + Validation = Weirdness (Keary Suska)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 26 May 2014 21:41:14 +0100
> From: Jonathan Mitchell <email@hidden>
> To: "email@hidden" <email@hidden>
> Subject: Mutating NSLayoutConstraint -constant at run time
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> So:
>
> 1. I have a NSView V within a view hierarchy.
> 2. V holds a layout constraint C that offsets a subview S from the bottom edge of V.
> 3. At runtime I mutate -constant on constraint C.
>
> The question is should the view hierarchy automatically recalculate its layout in response to changing the constant on C?
>
> In practice I find that I have to call -layoutSubtreeIfNeeded on a superview of V.
> I do not have to call -setNeedsLayout:YES
>
> Note:
>
> My actual implementation is more complex than the above.
> V exists with an NSStackView subclass, so there are a lot of constraints at play.
> However, if I can clarify the above it will help my thinking.
>
>
> Jonathan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 26 May 2014 15:06:25 -0700
> From: Jens Alfke <email@hidden>
> To: Pax <email@hidden>
> Cc: Mailing Lists <email@hidden>
> Subject: Re: EXC_BAD_ACCESS in NSData
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
>
> On May 26, 2014, at 6:02 AM, Pax <email@hidden> wrote:
>
>> When this gets run, I get EXC_BAD_ACCESS code = 2 here. I'm demonstrably reading less data than the file contains, and I've been able to read through the file successfully up to this point. Please could someone suggest to me what might be going wrong here?
>
> Use the debugger to look at the values of the relevant variables, especially dataSize.
> Since the result is a crash instead of an exception, the NSRange you create is valid; so I assume it’s just larger than your buffer so the copy runs off the end into unmapped address space.
>
> Also, what exactly is the type of ‘bytes’? If it’s a pointer to a malloced buffer, you shouldn’t be passing its address, rather its value, otherwise you’re going to copy into the stack and blow up.
>
> —Jens
>
> ------------------------------
>
> Message: 3
> Date: Tue, 27 May 2014 09:20:13 +1000
> From: Graham Cox <email@hidden>
> To: Roland King <email@hidden>
> Cc: Cocoa Cocoa-Dev <email@hidden>
> Subject: Re: EXC_BAD_ACCESS in NSData
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
> On 27 May 2014, at 12:54 am, Roland King <email@hidden> wrote:
>
>> datasize = *((unsigned int*)bytes);
>>
>> is a bit closer to what you might want but is endian-unaware.
>
> That's just as wrong - you are using the first few bytes of the data as the length, which it certainly isn't (except for possibly a very few special cases that just so happen to have the length as the first field of the data).
>
> --Graham
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 26 May 2014 17:13:48 -0700
> From: Jens Alfke <email@hidden>
> To: Graham Cox <email@hidden>
> Cc: Cocoa Cocoa-Dev <email@hidden>
> Subject: Re: EXC_BAD_ACCESS in NSData
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
>
> On May 26, 2014, at 4:20 PM, Graham Cox <email@hidden> wrote:
>
>> That's just as wrong - you are using the first few bytes of the data as the length, which it certainly isn't (except for possibly a very few special cases that just so happen to have the length as the first field of the data).
>
> No, it’s extremely common to have a data format where a variable-length field is prefixed with its length. That looks like what this code is trying to read.
>
> The right way to do this would be something like:
> uint32_t length = *(uint32_t*)bytes;
> length = CFSwapInt32BigToHost(length);
> You need to be explicit about the size of integer in use (“int” has different sizes on different platforms) and you need to convert from the byte-order used in the file format (which is almost always big-endian.)
>
> —Jens
>
> ------------------------------
>
> Message: 5
> Date: Mon, 26 May 2014 17:43:12 -0700
> From: Uli Kusterer <email@hidden>
> To: Graham Cox <email@hidden>
> Cc: Cocoa Cocoa-Dev <email@hidden>
> Subject: Re: EXC_BAD_ACCESS in NSData
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
> On 26 May 2014, at 16:20, Graham Cox <email@hidden> wrote:
>> On 27 May 2014, at 12:54 am, Roland King <email@hidden> wrote:
>>> datasize = *((unsigned int*)bytes);
>>>
>>> is a bit closer to what you might want but is endian-unaware.
>>
>> That's just as wrong - you are using the first few bytes of the data as the length, which it certainly isn't (except for possibly a very few special cases that just so happen to have the length as the first field of the data).
>
> It’s not a general truth, true, but from what the OP mentioned, he’s sequentially reading stuff from his big NSData:
>
>> datasize = (unsigned int)bytes; //This is the length of the data indicated in the data structure from the capture.
>
> So there you need to correctly cast the start of the data into a pointer to the right size of int (in general, you’d use some stable type like uint32_t instead of unsigned int for portability, though), and then de-reference it to read.
>
> Regarding endian-swapping, that depends on the file format. If you wrote that file yourself, you don’t usually need to do any swapping.
>
> Cheers,
> -- Uli Kusterer
> “The Witnesses of TeachText are everywhere...”
> http://zathras.de
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 27 May 2014 10:48:54 +1000
> From: Graham Cox <email@hidden>
> To: Jens Alfke <email@hidden>
> Cc: Cocoa Cocoa-Dev <email@hidden>
> Subject: Re: EXC_BAD_ACCESS in NSData
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
>
> On 27 May 2014, at 10:13 am, Jens Alfke <email@hidden> wrote:
>
>> No, it’s extremely common to have a data format where a variable-length field is prefixed with its length. That looks like what this code is trying to read.
>
> Alright, but you have to know that. I was looking at the code from a general standpoint, where its format was unknown - just a blob of data. Also, just reading the bytes blindly doesn't take into account endianness, though you and Roland do mention that.
>
> What I prefer to do when parsing blobs of data like this is declare types that represent chunks of the format, such as a struct that matches the header (being careful about matching the padding used by the file) then cast or copy the data buffer, taking into account endianness, into that type. It makes the code a lot more readable, because you are not just reading from a arbitrary offset, but are using a named field.
>
> --Graham
>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 26 May 2014 22:28:48 -0500
> From: Charles Srstka <email@hidden>
> To: Uli Kusterer <email@hidden>
> Cc: Cocoa Cocoa-Dev <email@hidden>
> Subject: Re: EXC_BAD_ACCESS in NSData
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
> On May 26, 2014, at 7:43 PM, Uli Kusterer <email@hidden> wrote:
>
>> Regarding endian-swapping, that depends on the file format. If you wrote that file yourself, you don’t usually need to do any swapping.
>
> That's true. For example, back in the PowerPC days, we never had to endian-swap our file formats, because we knew that our file format was created on a Mac, and Macs always used big-endian, and it wasn't as if Apple was ever going to do anything crazy like switch to Intel or anything.
>
> Nowadays, of course, we can be assured that our code will always run on Intel processors, because *obviously* there's no reason your code would ever need to run on something like ARM.
>
> Hmm.
>
> Charles
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 27 May 2014 09:27:36 +0100
> From: Jamie Ojomoh <email@hidden>
> To: "email@hidden" <email@hidden>
> Subject: Re: Understanding ARC
> Message-ID:
> <CAPNKnDgvw7CdVhi5oc3a9FS12as1+1thtkeEe=email@hidden>
> Content-Type: text/plain; charset=UTF-8
>
>> YOU ARE OVERTHINKING THIS. Stop trying to figure out when things are
> getting released — that’s ARC’s job. Just write your code.
>
> That's what my dad said, but I though he just didn't know what the real
> answer was.
>
> Thank you for your helps.
>
>
> On Sun, May 25, 2014 at 5:46 PM, Jens Alfke <email@hidden> wrote:
>
>>
>> On May 25, 2014, at 2:07 AM, Jamie Ojomoh <email@hidden> wrote:
>>
>>> So if I use alloc/init then autoreleasepool doesn't work?
>>
>> No, I meant that the string hasn’t been autoreleased at all yet, so the
>> pool isn’t going to release it when it exits. The pool “works”, it’s just
>> not necessary.
>>
>>> Or don't I need autoreleasepool at all?
>>
>> You don’t need it. You only need an autorelease pool if
>> (a) You’re running a lengthy loop that allocates/autoreleases objects on
>> every iteration; wrapping the body in a pool, keeps those objects from
>> building up
>> (b) You’re implementing a C callback, i.e. from something like a CF or
>> Unix API.
>>
>>> Is there any difference in memory releasing / ARC between a class and a
>>> instance method?
>>
>> No. Those are totally unrelated concepts.
>>
>>> And why is it that memory automatically gets released properly when an
>>> application quits,
>>
>> It’s part of the job of an operating system to clean up resources left
>> behind by processes.
>>
>>> but when a class is released any memory that hasn't been
>>> freed or released properly hangs around forever? Is this not something
>>> that can be asked here?
>>
>> Classes don’t get released, objects do. I’m not quite sure what you’re
>> asking. Within a process, individual memory blocks have to be explicitly
>> freed. NSObject does this by keeping track of reference counts and freeing
>> the memory when the ref-count drops to zero. If an object isn’t released
>> enough times, it’ll stay around until the process quits.
>>
>> Releasing/freeing objects is kind of like cleaning up your room after
>> you’re done using things; you have to remember to put each thing away.
>> The process quitting is like your house getting bulldozed. Everything that
>> was in it is gone, there’s nothing left until a new house gets built.
>>
>> Anyway, YOU ARE OVERTHINKING THIS. Stop trying to figure out when things
>> are getting released — that’s ARC’s job. Just write your code.
>>
>> —Jens
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 27 May 2014 15:38:25 +0530
> From: Navneet Kumar <email@hidden>
> To: Cocoa-dev List List <email@hidden>
> Subject: AVFoundation video not playing in root mode
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
> Hi,
>
> The code I’m using is as follows: (it works well and videos plays when logged in as admin user, but doesn’t play when the app is run as root):
>
> In awakeFromNib:
> [[avPlayerView layer] setBackgroundColor:CGColorGetConstantColor(kCGColorClear)];
> // Create the AVPlayer, add rate and status observers
> avPlayer = [[AVPlayer alloc] init];// autorelease];
> // Create an asset with our URL, asychronously load its tracks, its duration, and whether it's playable or protected.
> // When that loading is complete, configure a player to play the asset.
> NSURL *fileURL = [[NSBundle mainBundle] URLForResource:@"progress-movie" withExtension:@"mov"];
> AVURLAsset *asset = [AVAsset assetWithURL:fileURL];
> NSArray *assetKeysToLoadAndTest = [NSArray arrayWithObjects:@"playable", @"hasProtectedContent", @"tracks", @"duration", nil];
> [asset loadValuesAsynchronouslyForKeys:assetKeysToLoadAndTest completionHandler:^(void) {
> // The asset invokes its completion handler on an arbitrary queue when loading is complete.
> // Because we want to access our AVPlayer in our ensuing set-up, we must dispatch our handler to the main queue.
> dispatch_async(dispatch_get_main_queue(), ^(void) {
> [self setUpPlaybackOfAsset:asset withKeys:assetKeysToLoadAndTest];
> });
> }];
>
> - (void)playVideo {
> [[NSNotificationCenter defaultCenter] addObserver:self
> selector:@selector(playerItemDidReachEnd:)
> name:AVPlayerItemDidPlayToEndTimeNotification
> object:[avPlayer currentItem]];
> avPlayer.actionAtItemEnd = AVPlayerActionAtItemEndNone;
> [avPlayer seekToTime:kCMTimeZero];
> [avPlayer play];
> }
>
> - (void)pauseVideo {
> [avPlayer pause];
> [[NSNotificationCenter defaultCenter] removeObserver:self name:AVPlayerItemDidPlayToEndTimeNotification object:[avPlayer currentItem]];
> }
>
> - (void)playerItemDidReachEnd:(NSNotification *)notification {
> AVPlayerItem *p = [notification object];
> [p seekToTime:kCMTimeZero];
> }
>
> - (void)setUpPlaybackOfAsset:(AVAsset *)asset withKeys:(NSArray *)keys
> {
> // Set up an AVPlayerLayer according to whether the asset contains video.
> if ([[asset tracksWithMediaType:AVMediaTypeVideo] count] != 0)
> {
> // Create an AVPlayerLayer and add it to the player view if there is video, but hide it until it's ready for display
> AVPlayerLayer *newPlayerLayer = [AVPlayerLayer playerLayerWithPlayer:avPlayer];
> [newPlayerLayer setFrame:[[avPlayerView layer] bounds]];
> [newPlayerLayer setAutoresizingMask:kCALayerWidthSizable | kCALayerHeightSizable];
> //[newPlayerLayer setHidden:YES];
> avPlayerLayer = newPlayerLayer;
> [avPlayerLayer retain];
> [[avPlayerView layer] addSublayer:newPlayerLayer];
> }
> // Create a new AVPlayerItem and make it our player's current item.
> AVPlayerItem *playerItem = [AVPlayerItem playerItemWithAsset:asset];
> [avPlayer replaceCurrentItemWithPlayerItem:playerItem];
> }
>
> Can it work when app is running as root?
> Please help.
>
>
> Best,
> Navneet
>
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 27 May 2014 09:29:52 -0400
> From: Kyle Sluder <email@hidden>
> To: Navneet Kumar <email@hidden>
> Cc: Cocoa-dev List List <email@hidden>
> Subject: Re: AVFoundation video not playing in root mode
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=utf-8
>
> On May 27, 2014, at 6:08 AM, Navneet Kumar <email@hidden> wrote:
>>
>> Hi,
>>
>> The code I’m using is as follows: (it works well and videos plays when logged in as admin user, but doesn’t play when the app is run as root):
>
> Please stop trying to run your application as root. If Apple wanted to support this configuration, they wouldn’t have made AppKit quit immediately if it detected it was running as setuid root. And they wouldn’t have told Uli that running apps as root is an untested configuration:
>
> http://www.cocoabuilder.com/archive/cocoa/280214-allow-only-root-admin-users-to-execute-the-cocoa-app.html
>
> --Kyle Sluder
>
>
>
> ------------------------------
>
> Message: 11
> Date: Tue, 27 May 2014 07:41:31 -0600
> From: Keary Suska <email@hidden>
> To: Jonathan Mitchell <email@hidden>
> Cc: "email@hidden" <email@hidden>
> Subject: Re: NSPopover + Bindings + Validation = Weirdness
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
> On May 26, 2014, at 8:10 AM, Jonathan Mitchell wrote:
>
>>
>> On 26 May 2014, at 14:50, Keary Suska <email@hidden> wrote:
>>
>>>
>>> The bug is triggered when trying to display a sheet on a popover window, so even if I capture error presentation I would still have to present a modal alert of some kind. I was hoping the API would do that for me gracefully, but I was apparently wrong. I could give it a try and see if it behaves better.
>>
>> Hmm.
>> You could try using another popover to present the error.
>>
>> Your existing app modal presentation might be the best way of dealing with this.
>
>
> For the record, it appears that the beep after the modal window is closed is "normal" API behavior. I am experiencing this behavior every time is show a validation error as modal (via always shows application modal). On top of that, the error recovery options do not function when displaying an application modal while editing an NSTextFieldCell in an NSTableView. I will file radar(s).
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
>
>
>
> ------------------------------
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins (at) lists.apple.com
>
> https://lists.apple.com/mailman/listinfo/cocoa-dev
>
>
> End of Cocoa-dev Digest, Vol 11, Issue 299
> ******************************************
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden