date:20170617

Re: Unable to extract JPEG from PHAsset

2017-06-17 Thread David Duncan


> On Jun 16, 2017, at 7:31 AM, Glen Huang  wrote:
> 
> Hi,
> 
> I'm trying to extract the JPEG data from a PHAsset. I did it like this:
> 
>let fetchOptions = PHFetchOptions()
>fetchOptions.sortDescriptors = [NSSortDescriptor(key: 
> "creationDate", ascending: true)]
>let assets = PHAsset.fetchAssets(with: fetchOptions)
>jpg(for: assets[0])
> 
> where jpg(for:) is
> 
>func jpg(for asset: PHAsset) {
>let size = CGSize(width: 100, height: 100)
>PHImageManager.default().requestImage(for: asset, targetSize: size, 
> contentMode: .aspectFit, options: nil) { image, info in
>if let image = image {
>let jpg = UIImageJPEGRepresentation(image, 0.8)!
>}
>}
>}
> 
> It works in the simulator running iOS 11, but fails on iPhone 5S every time 
> with
> 
> fatal error: unexpectedly found nil while unwrapping an Optional value
> 
> And the thing caused that error was the bang after the 
> UIImageJPEGRepresentation function.
> 
> I'm using Xcode 9 beta, Swift 4, new build system, and the phone runs iOS 
> 10.3.2
> 
> Any idea why that happens and how I can extract the JPEG data from PHAsset? 

There is no obvious reason why this should fail, but the usual debugging things 
apply – what are the quality of image? (image.CGImage can still be nil, even if 
image is not). Does UIImageJPEGRepresentation() fail in any other situations? 
Can you reproduce this without using PHAsset?

> 
> Thank you.
> ___
> 
> 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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
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: Release mode bindings crash and release pools

2017-06-17 Thread Charles Srstka

> On Jun 17, 2017, at 3:11 PM, Jonathan Mitchell  wrote:
> 
>> On 17 Jun 2017, at 16:36, Charles Srstka > > wrote:
>> 
>>> On Jun 17, 2017, at 8:36 AM, Jonathan Mitchell >> > wrote:
>> 
>> 
>> Just tested it on 10.9; it works :-)
>> 
>> import Foundation
>> 
>> class C: NSObject {
>>@objc dynamic var foo = "Foo"
>> }
>> 
>> let c = C()
>> 
>> let observer = c.observe(\.foo) { obj, _ in
>>print("Foo changed: now it's \(obj.foo)")
>> }
>> 
>> c.foo = "Bar"
>> 
>> Running it on my Mavs VirtualBox VM, this outputs:
>> 
>> $ ./kvotest
>> Foo changed: now it's Bar
>> 
>> Charles
> 
> Thanks for taking the time to test that.
> I haven’t had time this week to take look at the new 10.13 APIs.
> 
> Will the above translate to Obj-C?

It’s in the Swift overlay, so no Obj-C, sorry.

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: Release mode bindings crash and release pools

2017-06-17 Thread Jonathan Mitchell


> On 17 Jun 2017, at 16:36, Charles Srstka  wrote:
> 
>> On Jun 17, 2017, at 8:36 AM, Jonathan Mitchell > > wrote:
> 
> 
> Just tested it on 10.9; it works :-)
> 
> import Foundation
> 
> class C: NSObject {
> @objc dynamic var foo = "Foo"
> }
> 
> let c = C()
> 
> let observer = c.observe(\.foo) { obj, _ in
> print("Foo changed: now it's \(obj.foo)")
> }
> 
> c.foo = "Bar"
> 
> Running it on my Mavs VirtualBox VM, this outputs:
> 
> $ ./kvotest
> Foo changed: now it's Bar
> 
> Charles

Thanks for taking the time to test that.
I haven’t had time this week to take look at the new 10.13 APIs.

Will the above translate to Obj-C?

J
___

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: Release mode bindings crash and release pools

2017-06-17 Thread Charles Srstka

> On Jun 17, 2017, at 8:36 AM, Jonathan Mitchell  wrote:
> 
>> On 17 Jun 2017, at 14:21, Charles Srstka > > wrote:
>> 
>>> On Jun 17, 2017, at 5:32 AM, Jonathan Mitchell >>  >> >> wrote:
>>> 
 On 16 Jun 2017, at 23:18, Quincey Morris 
 >>> >> wrote:
 
 On Jun 16, 2017, at 14:41 , Jonathan Mitchell >>>  >> wrote:
> 
> I sometimes use the default NSObject bind: to set up a simple one way 
> operation as you describe as opposed to a discrete observation.
 
 With macOS 10.13, the new block/closure-based KVO “addObserver” method is 
 probably an easier way, although you do have to remove it manually.
 
>>> The block/closure improvements are long overdue IMHO.
>>> 
>>> I use a home brewed approach using BPBlockValueTransformer : 
>>> NSValueTransformer with bindings that gives a lot more flexibility.
>>> A trivial example involving a closure would be:
>>> 
>>>   BPBlockValueTransformer *blockValueTransformer = [BPBlockValueTransformer 
>>> valueTransformerWithBlock:^id(NSNumber *value) {
>>>  strongify(self);
>>>  return ([value boolValue] || self.isFree)? @“Freedom for all" : 
>>> @“Freedom for no-one";
>>>   }];
>>>   [self.titleTextField bind:NSValueBinding toObject:self.repObjCon 
>>> withKeyPath:@"selection.isHidden" options:@{NSValueTransformerBindingOption 
>>> : blockValueTransformer}];
>>> 
>>> The downside is that you cannot establish the binding in the NIB.
>> 
>> It’s definitely overdue; I’ve been using a blocks-based wrapper around KVO 
>> for years. 
> Is that a publicly available wrapper?

No, sorry; I probably should have released it, but it's just something I’ve 
been keeping around for internal use. If it’s any consolation, it’s pretty much 
obsolete now thanks to the new built-in observation support. ;-)

It did have one nice feature that the built-in functionality doesn’t have, 
which was a method to catch exactly one change in a certain key path, and after 
that change occurred, it would automatically tear itself down. This was pretty 
handy for adding “completion handler” support to objects that only let you know 
they were finished by setting an observable “done” property. Maybe if I decide 
that feature’s still relevant, I’ll port it to the new Swift key path 
functionality, I dunno.

>> A couple of notes, though, re-reading the message this replied to. The new 
>> blocks-based API, ‘observe()’, is actually part of the Swift overlay, which 
>> means it works on older macOS versions, not just 10.13. Also, you don’t have 
>> to remove it manually, and that’s in fact one of its major features—it 
>> automatically deregisters itself whenever the observer falls out of scope. 
>> So as long as you make sure you don’t set up a retain cycle with captured 
>> values, you can just stash the observer in an ivar, and when your object 
>> gets deallocated, your observer will be unregistered. Much easier than what 
>> we had to do before.
> It would be good if I could get this to work all the way back to 10.9 (that’s 
> my deployment target).
> 
> Accurately managing observation and object lifetimes is such a big time sink 
> that any improvement is always welcome.

Just tested it on 10.9; it works :-)

import Foundation

class C: NSObject {
@objc dynamic var foo = "Foo"
}

let c = C()

let observer = c.observe(\.foo) { obj, _ in
print("Foo changed: now it's \(obj.foo)")
}

c.foo = "Bar"

Running it on my Mavs VirtualBox VM, this outputs:

$ ./kvotest
Foo changed: now it's Bar

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: Release mode bindings crash and release pools

2017-06-17 Thread Jonathan Mitchell


> On 17 Jun 2017, at 14:21, Charles Srstka  wrote:
> 
>> On Jun 17, 2017, at 5:32 AM, Jonathan Mitchell > > wrote:
>> 
>>> On 16 Jun 2017, at 23:18, Quincey Morris 
>>> >> > wrote:
>>> 
>>> On Jun 16, 2017, at 14:41 , Jonathan Mitchell >> > wrote:
 
 I sometimes use the default NSObject bind: to set up a simple one way 
 operation as you describe as opposed to a discrete observation.
>>> 
>>> With macOS 10.13, the new block/closure-based KVO “addObserver” method is 
>>> probably an easier way, although you do have to remove it manually.
>>> 
>> The block/closure improvements are long overdue IMHO.
>> 
>> I use a home brewed approach using BPBlockValueTransformer : 
>> NSValueTransformer with bindings that gives a lot more flexibility.
>> A trivial example involving a closure would be:
>> 
>>BPBlockValueTransformer *blockValueTransformer = [BPBlockValueTransformer 
>> valueTransformerWithBlock:^id(NSNumber *value) {
>>   strongify(self);
>>   return ([value boolValue] || self.isFree)? @“Freedom for all" : 
>> @“Freedom for no-one";
>>}];
>>[self.titleTextField bind:NSValueBinding toObject:self.repObjCon 
>> withKeyPath:@"selection.isHidden" options:@{NSValueTransformerBindingOption 
>> : blockValueTransformer}];
>> 
>> The downside is that you cannot establish the binding in the NIB.
> 
> It’s definitely overdue; I’ve been using a blocks-based wrapper around KVO 
> for years. 
Is that a publicly available wrapper?

> 
> A couple of notes, though, re-reading the message this replied to. The new 
> blocks-based API, ‘observe()’, is actually part of the Swift overlay, which 
> means it works on older macOS versions, not just 10.13. Also, you don’t have 
> to remove it manually, and that’s in fact one of its major features—it 
> automatically deregisters itself whenever the observer falls out of scope. So 
> as long as you make sure you don’t set up a retain cycle with captured 
> values, you can just stash the observer in an ivar, and when your object gets 
> deallocated, your observer will be unregistered. Much easier than what we had 
> to do before.
It would be good if I could get this to work all the way back to 10.9 (that’s 
my deployment target).

Accurately managing observation and object lifetimes is such a big time sink 
that any improvement is always welcome.

J
___

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: Release mode bindings crash and release pools

2017-06-17 Thread Charles Srstka

> On Jun 17, 2017, at 5:32 AM, Jonathan Mitchell  wrote:
> 
>> On 16 Jun 2017, at 23:18, Quincey Morris 
>> > > wrote:
>> 
>> On Jun 16, 2017, at 14:41 , Jonathan Mitchell > > wrote:
>>> 
>>> I sometimes use the default NSObject bind: to set up a simple one way 
>>> operation as you describe as opposed to a discrete observation.
>> 
>> With macOS 10.13, the new block/closure-based KVO “addObserver” method is 
>> probably an easier way, although you do have to remove it manually.
>> 
> The block/closure improvements are long overdue IMHO.
> 
> I use a home brewed approach using BPBlockValueTransformer : 
> NSValueTransformer with bindings that gives a lot more flexibility.
> A trivial example involving a closure would be:
> 
>BPBlockValueTransformer *blockValueTransformer = [BPBlockValueTransformer 
> valueTransformerWithBlock:^id(NSNumber *value) {
>   strongify(self);
>   return ([value boolValue] || self.isFree)? @“Freedom for all" : 
> @“Freedom for no-one";
>}];
>[self.titleTextField bind:NSValueBinding toObject:self.repObjCon 
> withKeyPath:@"selection.isHidden" options:@{NSValueTransformerBindingOption : 
> blockValueTransformer}];
> 
> The downside is that you cannot establish the binding in the NIB.

It’s definitely overdue; I’ve been using a blocks-based wrapper around KVO for 
years. 

A couple of notes, though, re-reading the message this replied to. The new 
blocks-based API, ‘observe()’, is actually part of the Swift overlay, which 
means it works on older macOS versions, not just 10.13. Also, you don’t have to 
remove it manually, and that’s in fact one of its major features—it 
automatically deregisters itself whenever the observer falls out of scope. So 
as long as you make sure you don’t set up a retain cycle with captured values, 
you can just stash the observer in an ivar, and when your object gets 
deallocated, your observer will be unregistered. Much easier than what we had 
to do before.

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: Release mode bindings crash and release pools

2017-06-17 Thread Jonathan Mitchell

> On 17 Jun 2017, at 01:54, Charles Srstka  wrote:
> 
>>  it’s preferred that bindings go either through an NSObjectController, an 
>> NSViewController, or something else that implements NSEditorRegistration.

I think that is a crucial aspect in all this.
I while back I configured bindings in contravention of the above and found 
myself literally re-inventing NSEditorRegistration (just to get everything to 
hang together) until the penny dropped.

In my case I route my object bindings through an NSObjectController hosted in 
my NSViewController subclass - I find the that the extra level of indirection 
gives flexibility.

The NSAutoUnbinder support is also crucial.
The public classes that implement it are:

NSViewController.
NSTableCellView
NSWindowController

J
___

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: Release mode bindings crash and release pools

2017-06-17 Thread Jonathan Mitchell

> On 16 Jun 2017, at 23:18, Quincey Morris 
>  wrote:
> 
> On Jun 16, 2017, at 14:41 , Jonathan Mitchell  wrote:
>> 
>> I sometimes use the default NSObject bind: to set up a simple one way 
>> operation as you describe as opposed to a discrete observation.
> 
> With macOS 10.13, the new block/closure-based KVO “addObserver” method is 
> probably an easier way, although you do have to remove it manually.
> 
The block/closure improvements are long overdue IMHO.

I use a home brewed approach using BPBlockValueTransformer : NSValueTransformer 
with bindings that gives a lot more flexibility.
A trivial example involving a closure would be:

BPBlockValueTransformer *blockValueTransformer = [BPBlockValueTransformer 
valueTransformerWithBlock:^id(NSNumber *value) {
   strongify(self);
   return ([value boolValue] || self.isFree)? @“Freedom for all" : 
@“Freedom for no-one";
}];
[self.titleTextField bind:NSValueBinding toObject:self.repObjCon 
withKeyPath:@"selection.isHidden" options:@{NSValueTransformerBindingOption : 
blockValueTransformer}];

The downside is that you cannot establish the binding in the NIB.
___

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: Deep linking from 1 tvOS app to another

2017-06-17 Thread Aandi Inston

> Actually don’t do the substitution by hand. Let NSString URL-encode it
for you. Otherwise your URL will break again when someone decides to type a
“/“ or “#”, etc. into your text field.

This is an interesting point. A / is actually legal in a URL but has
specific semantics, while space just isn't allowed. If the URL is a private
scheme where both ends are under your control and / is not used as a
separator, it might work.
Still, the easiest thing is to just use a supplied encode/decode. Consider
especially what might happen to non-roman characters (someone
copy-pastes naïve or café or smart quotes). I wouldn't know what to do with
these, but I bet the encoder does.

On 16 June 2017 at 20:15, Jens Alfke  wrote:

>
> > On Jun 16, 2017, at 8:00 AM, Eric E. Dolecki  wrote:
> >
> >let modified = supplied.replacingOccurrences(of: " ", with:
> "+")
>
> Don’t use “+”, use “%20”. The “+” is only valid in some contexts IIRC,
> like form values.
>
> Actually don’t do the substitution by hand. Let NSString URL-encode it for
> you. Otherwise your URL will break again when someone decides to type a “/“
> or “#”, etc. into your text field.
>
> —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/aandi%40quite.com
>
> This email sent to aa...@quite.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: APFS

2017-06-17 Thread Ken Thomases

On Jun 16, 2017, at 1:57 AM, Quincey Morris 
 wrote:
> 
> FWIW, the WWDC session on APFS is worth watching:
> 
>   https://developer.apple.com/videos/play/wwdc2017/715/ 
> 
> 
> because it relates to an inconclusive discussion we had recently about iOS 
> file names with normalization issues “breaking” existing apps.
> 
> If I understand it correctly, Apple has abandoned the ridiculous idea of 
> making iOS APFS normalization-sensitive (that is, of treating strings 
> differing only in normalization as different file names).

True, but it should be noted (as they point out in the session presentation) 
that normalization-insensitive is different than normalizing.  So, if you 
enumerate a directory's contents, the strings you get back for file names will 
be exactly as they were originally passed in to the APIs and not necessarily 
normalized.  That means, if you compare against some other string, you will 
have to do a normalization-insensitive compare to get the same "equality" test 
that the file system uses.  Mind you, you should basically never do that sort 
of comparison.  Always use the appropriate APIs to look up or compare file 
system entries.

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: Unable to extract JPEG from PHAsset

Re: Release mode bindings crash and release pools

Re: Release mode bindings crash and release pools

Re: Release mode bindings crash and release pools

Re: Release mode bindings crash and release pools

Re: Release mode bindings crash and release pools

Re: Release mode bindings crash and release pools

Re: Release mode bindings crash and release pools

Re: Deep linking from 1 tvOS app to another

Re: APFS

10 matches

Site Navigation

Mail list logo

Footer information