Re: overlapping status bar
On 30 Nov 2013, at 00:42, Kyle Sluder wrote: >> On Nov 29, 2013, at 1:18 AM, "Gerriet M. Denkmann" >> wrote: >> >> The problem: the status bar is visible (as it should be) but it overlaps >> both view a and b, which looks ugly. >> Is there any way to tell these views to move down a little bit (using >> autolayout)? > > UIViewController.topLayoutGuide. in viewDidLoad of my ViewController I added: id topGuide = self.topLayoutGuide; NSLog(@"%s topGuide: %@, length: %g, preferHidden: %d",__FUNCTION__, topGuide, topGuide.length, self.prefersStatusBarHidden); which prints: topGuide: <_UILayoutGuide: 0x10f433230; frame = (0 0; 0 0); hidden = YES; layer = >, length: 0, preferHidden: 0 "hidden = YES" seems strange as I can clearly see the statusBar (the thing with Carrier, Clock and Battery on top). "length = 0" rimes with "hidden = YES" but not with reality. Not surprisingly, adding: NSLayoutConstraint *newOne =[ NSLayoutConstraintconstraintWithItem: topGuide attribute: NSLayoutAttributeBottom relatedBy: NSLayoutRelationEqual toItem: self.view attribute: NSLayoutAttributeTop multiplier: 1 constant: 0 ]; [ self.view addConstraint: newOne ]; has no effect at all. By the way: my ViewController is part of a UISplitViewController. The same view works very nicely when part of a UINavigationController. iOS 7.0.4 Kind regards, Gerriet. ___ 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: overlapping status bar
On 30 Nov 2013, at 00:42, Kyle Sluder wrote: >> On Nov 29, 2013, at 1:18 AM, "Gerriet M. Denkmann" >> wrote: >> >> The problem: the status bar is visible (as it should be) but it overlaps >> both view a and b, which looks ugly. >> Is there any way to tell these views to move down a little bit (using >> autolayout)? > > UIViewController.topLayoutGuide. The documentation says: "If bars should overlap the top [...] of a view, you can use Interface Builder to position the view relative to the bar by creating constraints [...] to the top of bottomLayoutGuide." Well, I can't. The view does not let me choose any constraints, and the things IN the view can only be positioned relative to the view (as expected). I guess I will try to do this programmatically. Kind regards, Gerriet. ___ 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: Fast hash of NSData?
On Nov 29, 2013, at 7:40 PM, Jens Alfke wrote: > Murmur is an excellent 32-bit hash function, but it’s not suitable for > Graham’s use case where a collision would result in data loss. FYI, murmur has continued to evolve, with some tweaks both for performance and for better distribution, *and* a 128-bit version. ___ 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: Fast hash of NSData?
If it is possible to compare the attributes of your file besides length, such as modified date, created date, inode, etc., then you might be able to further catch the cases where the length is the same but the data changed is large enough that you would rather delay any full-file access whether by full-byte compare or computing a hash. If you can rely on file attributes, then only if the significant ones change would I use the new file. Assuming we're talking about graphics files, I doubt Photoshop (as an example app) will allow a user to invert all colors, a task that could theoretically keep the same length, and then save that file, and then subverting the OS keep the same modification and creation date as before. If a user does that (since Photoshop would not, it would have to be deliberate), then they're purposely trying to fool your app—or they're OCD and/or trying to prevent a quantum entanglement with a parallel universe (or it's an installer that would fix time stamps for some esoteric reason). If you don't have access to any important file attributes, and your data is awfully big, you could try a preliminary compare of a random smaller set of blocks. On the other hand, since you already have local access to both files, you might compare the time it takes to do full-byte compares of memory mapped forms of the data against calculating the hash. Depending on vector functions, registers, and word-compare-size (128 bits at a time?) you might be able to more quickly ascertain equality. Hashes for large file equality are a whole lot more necessary when the latency of file access is orders of magnitude larger than local file access (consider across-network full-copying of files, something backup and sync products want to be fast at). -- Gary L. Wade (Sent from my iPhone) http://www.garywade.com/ > On Nov 29, 2013, at 1:49 PM, Kyle Sluder wrote: > > You also have another, damn-quick "hash key" that takes zero disk access to > compute: -[NSData length]. ___ 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: Preferences caching?
A quick lesson in avoiding “corrupt preferences” bugs… CODE: NSUserDefaults* ud = [NSUserDefaults standardUserDefaults] ; NSLog(@"safely: %@", [ud stringForKey:@“myDataObject"]) ; NSLog(@"unsafe: %@", [[ud objectForKey:@"myDataObject"] stringValue]) ; CONSOLE OUTPUT: safely: (null) -[__NSCFData stringValue]: unrecognized selector sent … ___ 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
SOLVED. Can't add bar button items to nav bar
Ugh, nevermind. Quitting and re-launching Xcode fixed it. I have an iPad storyboard with a straightforward uinavcontroller and uitableviewcontroller. I'm trying to drag a UIBarButtonItem to the nav bar, but it keeps creating a toolbar at the bottom and putting it there. iOS 7 view. If I drag it to the navigation item in the outline view, it adds it to the right side of the nav bar, but I can't add a second one (it just replaces the existing one). Any idea how to fix this? -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Can't add bar button items to nav bar
I have an iPad storyboard with a straightforward uinavcontroller and uitableviewcontroller. I'm trying to drag a UIBarButtonItem to the nav bar, but it keeps creating a toolbar at the bottom and putting it there. iOS 7 view. If I drag it to the navigation item in the outline view, it adds it to the right side of the nav bar, but I can't add a second one (it just replaces the existing one). Any idea how to fix this? -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Fast hash of NSData?
On Nov 29, 2013, at 6:26 PM, Scott Ribe wrote: > I recently (last week, no kidding) investigated this question, and went with > murmur hash. Murmur is an excellent 32-bit hash function, but it’s not suitable for Graham’s use case where a collision would result in data loss. >> In this scheme, if there is a hash collision, you lose user data. That >> should be a non-starter. You *must* do a full bytewise comparison in case of >> collision. > a 1 in 2^64, or 2^128, or 2^256 chance, so no, it is just fine. It’s worse than that, actually, because of what’s known as the “birthday paradox”[1]. In a group of 23 people, there’s a 50% chance that two of them have the same birthday. Similarly, as the number of objects you’re hashing grows, the chance of a collision grows much more rapidly, because it’s proportional to the number of _pairs_ of objects. Generally with a 160-bit hash function the odds of a collision for any reasonably-sized data set are negligible, as long as the hash function is reasonably random. (The trust in the randomness of SHA-1 is eroding, though.) —Jens [1] http://en.wikipedia.org/wiki/Birthday_paradox [2] http://en.wikipedia.org/wiki/Birthday_attack ___ 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: Fast hash of NSData?
On Nov 29, 2013, at 2:49 PM, Kyle Sluder wrote: > In this scheme, if there is a hash collision, you lose user data. That should > be a non-starter. You *must* do a full bytewise comparison in case of > collision. a 1 in 2^64, or 2^128, or 2^256 chance, so no, it is just fine. ___ 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: Fast hash of NSData?
On Nov 29, 2013, at 12:58 PM, Graham Cox wrote: > Another general question. > > Does anyone have a quick-and-dirty (but functional) way to hash NSData? I’m > currently using SHA-1 but it’s quite slow. All I need is a way to determine > whether one block of data is identical to another or not - but every bit > counts. It doesn’t need to be of crypto-standard, but SHA-1 was convenient. > Note that this can’t be the same as simply seeing whether one object is the > same as another - I really do need to know if two different objects hold the > same data bytes, and to derive a short, unique value that can be used as a > key. > > I’ve previously written my own quick-and-dirty hash that was basically a > weighted sum of the bytes, modulo some number, but it turned out to have > collisions more often than I expected, so SHA-1 was then used to fix that > problem. Now it’s causing quite a noticeable performance hit in some cases. I recently (last week, no kidding) investigated this question, and went with murmur hash. ___ 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: Fast hash of NSData?
> On Nov 29, 2013, at 2:19 PM, Graham Cox wrote: > > >> On 29 Nov 2013, at 10:49 pm, Kyle Sluder wrote: >> >> In this scheme, if there is a hash collision, you lose user data. That >> should be a non-starter. You *must* do a full bytewise comparison in case of >> collision. > > I wouldn’t say a non-starter. In practice, the odds of this are exceedingly > small *provided* the hash function is good. Much as a civil engineer would find it unconscionable to knowingly choose a bridge design that could not be guaranteed to support the design load, so too should a software engineer instinctively avoid any solution that they know has even a remote possibility of losing data under normal operation. Plus, since you're already keying by size, you can afford to use a faster but higher-collision hashing algorithm. --Kyle Sluder ___ 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: Fast hash of NSData?
> On Nov 29, 2013, at 3:35 PM, Graham Cox wrote: > > > On 29 Nov 2013, at 11:19 pm, Graham Cox wrote: > >>> You also have another, damn-quick "hash key" that takes zero disk access to >>> compute: -[NSData length]. >> >> Yep, that’s a great idea. > > > OK, I’ve implemented this much as your suggestion, and I’m also saving the > hash object along with the data so I can avoid recomputing it when the file > is imported. That’s not a good idea. If the file on disk changes out from under you, the cache no longer reflects the data. Reminiscent of the old adage: “There are only two hard problems in computer science: naming things, cache invalidation, and off-by-one errors.” If you really want to avoid computing hashes for all your embedded image data at load, you might consider deferring hash computation until absolutely necessary—that is, when inserting a file into a loaded document, only compute hashed for data objects which have the same length as the one you're in inserting. --Kyle Sluder ___ 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: Fast hash of NSData?
On 29 Nov 2013, at 11:19 pm, Graham Cox wrote: >> You also have another, damn-quick "hash key" that takes zero disk access to >> compute: -[NSData length]. > > Yep, that’s a great idea. OK, I’ve implemented this much as your suggestion, and I’m also saving the hash object along with the data so I can avoid recomputing it when the file is imported. The huge file I’m testing with now opens in 2/3rds of the time (2 seconds instead of 3). That’s now down from 11 minutes, so overall the optimisations are going quite well :) —Graham ___ 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: Fast hash of NSData?
On 29 Nov 2013, at 11:19 pm, Graham Cox wrote: > Good idea, though ideally it would only compute the actual hash lazily if it > got as far as needing to (i.e. when the length matched). I’ll give it a go. Hmm, of course that can’t be worthwhile if it’s used as a dictionary key, as it will always need to be computed. Still, it will be an improvement on what I have. —Graham ___ 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: Fast hash of NSData?
On 29 Nov 2013, at 10:49 pm, Kyle Sluder wrote: > In this scheme, if there is a hash collision, you lose user data. That should > be a non-starter. You *must* do a full bytewise comparison in case of > collision. I wouldn’t say a non-starter. In practice, the odds of this are exceedingly small *provided* the hash function is good. My original one was dreadful, so yes, we had some initial problems with images suddenly turning into different ones. Using SHA-1 we’ve never had that issue recur, though in theory it could. According to the discussion on Stack Exchange that Eric pointed out, the fnv1a has very good randomness, and using the 64-bit variant it should mean the odds against a collision should be huge. > You also have another, damn-quick "hash key" that takes zero disk access to > compute: -[NSData length]. Yep, that’s a great idea. > Use the size as a primary key, then a reasonably low-collision/low-complexity > hash algorithm as a secondary key. That seems like a reasonable compromise > between runtime efficiency and implementation simplicity. > > You could make the keys of your dictionary a custom object: Good idea, though ideally it would only compute the actual hash lazily if it got as far as needing to (i.e. when the length matched). I’ll give it a go. —Graham ___ 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: Fast hash of NSData?
> On Nov 29, 2013, at 12:56 PM, Graham Cox wrote:
>
> The situation is, my app allows users to include images, which I’d like to
> preserve in their original formats as far as possible. i.e. if they drag in a
> JPEG, then I track the JPEG data and ultimately that gets embedded in my
> file. If they drag the same image in more than once, I want to ensure that
> the same data is used for as many copies as they include. So I compare the
> image data with what I know about already, and if there’s a match, according
> to the hash, then I substitute the original data I know about already.
In this scheme, if there is a hash collision, you lose user data. That should
be a non-starter. You *must* do a full bytewise comparison in case of
collision.
> So the hash only needs to be computed whenever an object is added, so at that
> time the time to compute the hash is negligible. But it’s also computed for
> each image data read when opening the file, because even though each instance
> is unique, it still needs to be hashed and stored in case the user
> subsequently adds an image that matches one of these. It’s this that’s taking
> noticeable time, for files that have lots of different images in them.
You also have another, damn-quick "hash key" that takes zero disk access to
compute: -[NSData length].
Use the size as a primary key, then a reasonably low-collision/low-complexity
hash algorithm as a secondary key. That seems like a reasonable compromise
between runtime efficiency and implementation simplicity.
You could make the keys of your dictionary a custom object:
@interface ImageDataHashKey : NSObject
+ (instancetype)keyForData:(NSData *)data;
@property (readonly) NSUInteger size;
@end
@implementation ImageDataHashKey
{
NSUInteger _hash;
}
+ (instancetype)keyForData:(NSData *)data;
{
ImageDataHashKey *key = [[self alloc] init];
key->_hash = hashfunc(data);
}
- (NSUInteger)hash;
{
return (NSUInteger)_hash;
}
- (BOOL)isEqual:(id)other;
{
return [other isKindOfClass:[ImageDataHashKey class]] && self->_size ==
other->_size && self->_hash == other->_hash;
}
@end
//--
A further optimization might be to build your own cuckoo hash to avoid
collisions entirely.
--Kyle Sluder
___
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: Fast hash of NSData?
On 29 Nov 2013, at 9:36 pm, Kyle Sluder wrote: > Often, it's better to improve the data structure before trying a different > hash function. It's much easier to reason about how to improve a solution in > terms of algorithm analysis of your data structure rather than it is to > perform an empirical analysis of a specific hash function's > collision-to-speed tradeoffs. > > Long way of saying: what's the actual problem you're trying to solve? Maybe a > hash table is a poor fit. OK, there could well be a better way to do this. Before I get into it though, thanks to Eric and Robert for the pointers - substituting first fnv1a then djb2 for my hash, I cut the time down to 50% then 36% of the original respectively, so very worthwhile since this was the real time hog in a profile of opening a large file. The situation is, my app allows users to include images, which I’d like to preserve in their original formats as far as possible. i.e. if they drag in a JPEG, then I track the JPEG data and ultimately that gets embedded in my file. If they drag the same image in more than once, I want to ensure that the same data is used for as many copies as they include. So I compare the image data with what I know about already, and if there’s a match, according to the hash, then I substitute the original data I know about already. The object that manages this keeps a dictionary of known image data, keyed by the hash (as a string). In that way, I just compute the hash of the image data, and if it’s in the dictionary already, I return that copy, otherwise add it to the dictionary. So the hash only needs to be computed whenever an object is added, so at that time the time to compute the hash is negligible. But it’s also computed for each image data read when opening the file, because even though each instance is unique, it still needs to be hashed and stored in case the user subsequently adds an image that matches one of these. It’s this that’s taking noticeable time, for files that have lots of different images in them. An obvious different approach is not to embed the image data in my app’s file data, but to copy the image on disk to my file’s package and track it by name or URL. I do plan to do that at some point, but that’s a change that’s quite complex compared to just speeding up the existing design. —Graham ___ 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: Fast hash of NSData?
Hello,
If memory serves well, CRC-32 is quite fast. How large are the BLOBs you're
trying to compare? If they're not too large, the following may work for you:
#include
@implementation NSData (CRC32)
- (uint32_t)CRC32
{
uLong crc = crc32(0L, NULL, 0);
crc = crc32(crc, [self bytes], [self length]);
return crc;
}
@end
--Tito
On Nov 29, 2013, at 12:36 PM, Kyle Sluder wrote:
>> On Nov 29, 2013, at 11:58 AM, Graham Cox wrote:
>
>>
>> Another general question.
>>
>> Does anyone have a quick-and-dirty (but functional) way to hash NSData? I’m
>> currently using SHA-1 but it’s quite slow. All I need is a way to determine
>> whether one block of data is identical to another or not - but every bit
>> counts.
>
> Just for the sake of the list, though I'm certain you're aware of this
> yourself: you can't use a hash function to check for equality unless it is a
> perfect hash function. You can use it to reduce the number of comparisons per
> candidate, but you'll always wind up doing at least O(M+N) comparisons (where
> M is the size of your input and N is the length of your hash output).
>
> Often, it's better to improve the data structure before trying a different
> hash function. It's much easier to reason about how to improve a solution in
> terms of algorithm analysis of your data structure rather than it is to
> perform an empirical analysis of a specific hash function's
> collision-to-speed tradeoffs.
>
> Long way of saying: what's the actual problem you're trying to solve? Maybe a
> hash table is a poor fit.
>
> --Kyle Sluder
> ___
>
> 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/tciuro%40mac.com
>
> This email sent to tci...@mac.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: Fast hash of NSData?
> On Nov 29, 2013, at 11:58 AM, Graham Cox wrote: > > Another general question. > > Does anyone have a quick-and-dirty (but functional) way to hash NSData? I’m > currently using SHA-1 but it’s quite slow. All I need is a way to determine > whether one block of data is identical to another or not - but every bit > counts. Just for the sake of the list, though I'm certain you're aware of this yourself: you can't use a hash function to check for equality unless it is a perfect hash function. You can use it to reduce the number of comparisons per candidate, but you'll always wind up doing at least O(M+N) comparisons (where M is the size of your input and N is the length of your hash output). Often, it's better to improve the data structure before trying a different hash function. It's much easier to reason about how to improve a solution in terms of algorithm analysis of your data structure rather than it is to perform an empirical analysis of a specific hash function's collision-to-speed tradeoffs. Long way of saying: what's the actual problem you're trying to solve? Maybe a hash table is a poor fit. --Kyle Sluder ___ 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: Fast hash of NSData?
It's old, but try to start with these: https://code.google.com/p/xxhash/ Sent from my iPhone > On 29. 11. 2013, at 20:58, Graham Cox wrote: > > Another general question. > > Does anyone have a quick-and-dirty (but functional) way to hash NSData? I’m > currently using SHA-1 but it’s quite slow. All I need is a way to determine > whether one block of data is identical to another or not - but every bit > counts. It doesn’t need to be of crypto-standard, but SHA-1 was convenient. > Note that this can’t be the same as simply seeing whether one object is the > same as another - I really do need to know if two different objects hold the > same data bytes, and to derive a short, unique value that can be used as a > key. > > I’ve previously written my own quick-and-dirty hash that was basically a > weighted sum of the bytes, modulo some number, but it turned out to have > collisions more often than I expected, so SHA-1 was then used to fix that > problem. Now it’s causing quite a noticeable performance hit in some cases. > > —Graham > > > > ___ > > 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/robert%40tapmates.com > > This email sent to rob...@tapmates.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
Fast hash of NSData?
Another general question. Does anyone have a quick-and-dirty (but functional) way to hash NSData? I’m currently using SHA-1 but it’s quite slow. All I need is a way to determine whether one block of data is identical to another or not - but every bit counts. It doesn’t need to be of crypto-standard, but SHA-1 was convenient. Note that this can’t be the same as simply seeing whether one object is the same as another - I really do need to know if two different objects hold the same data bytes, and to derive a short, unique value that can be used as a key. I’ve previously written my own quick-and-dirty hash that was basically a weighted sum of the bytes, modulo some number, but it turned out to have collisions more often than I expected, so SHA-1 was then used to fix that problem. Now it’s causing quite a noticeable performance hit in some cases. —Graham ___ 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: overlapping status bar
> On Nov 29, 2013, at 1:18 AM, "Gerriet M. Denkmann" > wrote: > > The problem: the status bar is visible (as it should be) but it overlaps both > view a and b, which looks ugly. > Is there any way to tell these views to move down a little bit (using > autolayout)? UIViewController.topLayoutGuide. --Kyle Sluder ___ 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: MKMapView, screen grabs and other discussions
Thanks again, works perfectly for my needs. I guess that its existence indicates that you can use it freely, so the legality question is moot. —Graham On 29 Nov 2013, at 3:21 pm, Graham Cox wrote: > Aha! I hadn’t spotted that class. Looks very promising… I’ll check out the > videos also. > > cheers, Graham > > > On 29 Nov 2013, at 2:21 pm, Roland King wrote: > >> Does MKMapSnapshotter do what you want? There's a bunch of stuff about maps >> in OSX in the WWDC 2013 videos, I think I remember seeing that there. ___ 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: MKMapView, screen grabs and other discussions
Aha! I hadn’t spotted that class. Looks very promising… I’ll check out the videos also. cheers, Graham On 29 Nov 2013, at 2:21 pm, Roland King wrote: > Does MKMapSnapshotter do what you want? There's a bunch of stuff about maps > in OSX in the WWDC 2013 videos, I think I remember seeing that there. ___ 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: MKMapView, screen grabs and other discussions
Does MKMapSnapshotter do what you want? There's a bunch of stuff about maps in OSX in the WWDC 2013 videos, I think I remember seeing that there. On 29 Nov, 2013, at 9:14 pm, Graham Cox wrote: > Hi all, > > What I want to do is to use MapKit to get imagery of a particular region, > display it as a layer in an app, and allow the user to trace over it. > > MapKit makes this hard, probably deliberately. > > First, MKMapView is the only object available for displaying the map - there > is no lower-level object that will render map data into a view of your own. > This doesn’t fit very well with the existing architecture of my app - I > already have a view that renders the layered content, adding the map view as > a subview is not the same thing. It might be possible to make that work > though, assuming I can force it to be semi-transparent, and somehow route > mouse events around it to the enclosing view. > > Next, MKMapView deliberately prevents -dataWithPDFInRect: from returning > anything useful, so I can’t use that to capture the graphics by that route. > > So, I was wondering if a screenshot approach would be feasible. I can take a > screenshot of the map view and that works, but if I’m to make that work in > code, it would be nice if the screenshot could be done without having to make > an actual window visible and free of overlap from any other view/window. Does > that sound even remotely possible? > > In general, is using MapKit in such a way even allowed? It seems it could > well be highly legally encumbered anyway. Thoughts? > > —Graham > > > > ___ > > 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/rols%40rols.org > > This email sent to r...@rols.org ___ 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
MKMapView, screen grabs and other discussions
Hi all, What I want to do is to use MapKit to get imagery of a particular region, display it as a layer in an app, and allow the user to trace over it. MapKit makes this hard, probably deliberately. First, MKMapView is the only object available for displaying the map - there is no lower-level object that will render map data into a view of your own. This doesn’t fit very well with the existing architecture of my app - I already have a view that renders the layered content, adding the map view as a subview is not the same thing. It might be possible to make that work though, assuming I can force it to be semi-transparent, and somehow route mouse events around it to the enclosing view. Next, MKMapView deliberately prevents -dataWithPDFInRect: from returning anything useful, so I can’t use that to capture the graphics by that route. So, I was wondering if a screenshot approach would be feasible. I can take a screenshot of the map view and that works, but if I’m to make that work in code, it would be nice if the screenshot could be done without having to make an actual window visible and free of overlap from any other view/window. Does that sound even remotely possible? In general, is using MapKit in such a way even allowed? It seems it could well be highly legally encumbered anyway. Thoughts? —Graham ___ 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
overlapping status bar
On iPad 7.0.4: AViewController *a = ... BViewController *b = ... UISplitViewController *spv = [ [ UISplitViewController alloc ] init ]; spv.viewControllers = @[ a, b ]; spv.delegate = ...; self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]]; self.window.rootViewController = spv; self.window.tintColor = self.tintColour; [ self.window makeKeyAndVisible]; The problem: the status bar is visible (as it should be) but it overlaps both view a and b, which looks ugly. Is there any way to tell these views to move down a little bit (using autolayout)? Gerriet. ___ 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: Preferences caching?
Hmm…I’ve had cases where the preferences were corrupted (presumably by Apple, I was only using the APIs) and prevented the app from launching. In terms of overall problems I think this was second to “I lost my license, can you help me”. Marcel On Nov 27, 2013, at 19:38 , Alex Kac wrote: > While I agree that sometimes deleting a prefs file is useful, its not really > a good idea - never was. Its still asking the user to muck around app > internals. The fact that mavericks now caches really shouldn’t matter. > > I think if deleting your prefs file is a common case, or even somewhat > common, or used at all - then yes, its far more appropriate for you to have a > button. Asking the user to trawl through internal implementation details of > the system was never a good idea. > > So in this case, I think Apple is doing the right thing. ___ 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
