On May 27, 2014, at 3:41 PM, [email protected] wrote: > Send Cocoa-dev mailing list submissions to > [email protected] > > 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 protected] > > You can reach the person managing the list at > [email protected] > > 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 protected]> > To: "[email protected]" <[email protected]> > Subject: Mutating NSLayoutConstraint -constant at run time > Message-ID: <[email protected]> > 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 protected]> > To: Pax <[email protected]> > Cc: Mailing Lists <[email protected]> > Subject: Re: EXC_BAD_ACCESS in NSData > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252 > > > On May 26, 2014, at 6:02 AM, Pax <[email protected]> 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 protected]> > To: Roland King <[email protected]> > Cc: Cocoa Cocoa-Dev <[email protected]> > Subject: Re: EXC_BAD_ACCESS in NSData > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > On 27 May 2014, at 12:54 am, Roland King <[email protected]> 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 protected]> > To: Graham Cox <[email protected]> > Cc: Cocoa Cocoa-Dev <[email protected]> > Subject: Re: EXC_BAD_ACCESS in NSData > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252 > > > On May 26, 2014, at 4:20 PM, Graham Cox <[email protected]> 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 protected]> > To: Graham Cox <[email protected]> > Cc: Cocoa Cocoa-Dev <[email protected]> > Subject: Re: EXC_BAD_ACCESS in NSData > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252 > > On 26 May 2014, at 16:20, Graham Cox <[email protected]> wrote: >> On 27 May 2014, at 12:54 am, Roland King <[email protected]> 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 protected]> > To: Jens Alfke <[email protected]> > Cc: Cocoa Cocoa-Dev <[email protected]> > Subject: Re: EXC_BAD_ACCESS in NSData > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252 > > > On 27 May 2014, at 10:13 am, Jens Alfke <[email protected]> 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 protected]> > To: Uli Kusterer <[email protected]> > Cc: Cocoa Cocoa-Dev <[email protected]> > Subject: Re: EXC_BAD_ACCESS in NSData > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252 > > On May 26, 2014, at 7:43 PM, Uli Kusterer <[email protected]> > 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 protected]> > To: "[email protected]" <[email protected]> > Subject: Re: Understanding ARC > Message-ID: > <CAPNKnDgvw7CdVhi5oc3a9FS12as1+1thtkeEe=etrd4d5b3...@mail.gmail.com> > 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 protected]> wrote: > >> >> On May 25, 2014, at 2:07 AM, Jamie Ojomoh <[email protected]> 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 protected]> > To: Cocoa-dev List List <[email protected]> > Subject: AVFoundation video not playing in root mode > Message-ID: <[email protected]> > 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 protected]> > To: Navneet Kumar <[email protected]> > Cc: Cocoa-dev List List <[email protected]> > Subject: Re: AVFoundation video not playing in root mode > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > On May 27, 2014, at 6:08 AM, Navneet Kumar <[email protected]> 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 protected]> > To: Jonathan Mitchell <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: NSPopover + Bindings + Validation = Weirdness > Message-ID: <[email protected]> > 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 protected]> 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 protected]) > > 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 protected]) 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 [email protected]
