Re: On NSIncrementalStore UUID Uniqueness

[Jens Alfke]

> On Jan 14, 2017, at 2:41 AM, Daryle Walker  wrote:
> 
>  I’m seemingly stuck since the data format doesn’t have a UUID field within 
> it and I can’t base a UUID off of a hash of the file since it would change 
> after each edit.

There’s really no way to store any custom metadata in the file? I assume it’s 
some sort of database-like file (since it can be used to store CoreData 
objects), so couldn’t you create an extra record and store a UUID in it?

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: On NSIncrementalStore UUID Uniqueness

[Alex Zavatone]

On Jan 11, 2017, at 12:16 PM, Jens Alfke wrote:

> 
>> On Jan 10, 2017, at 2:00 PM, Jean-Daniel  wrote:
>> 
>> UUID means Universally unique identifier and it must be unique: 
>> https://en.wikipedia.org/wiki/UUID 
>> > >
>> To generate an UUID, use a standard system function (CFUUID, NSUUID, 
>> libuuid, …)
> 
> This is not what I believe Daryle was asking, and it’s sent everyone off on a 
> tangent about what UUIDs are.
> 
> My interpretation of the original question: Is an NSIncrementalStore’s UUID 
> scoped to the specific database, or is it scoped to that _implementation_ of 
> the store? That is, is the UUID generated at runtime or at compile time?
> 
> I don’t know the answer; just hoping to get the discussion back on track :)
> 
> —Jens

Your conclusion seems to make the most sense.


___

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: On NSIncrementalStore UUID Uniqueness

[Jean-Daniel]

> Le 14 janv. 2017 à 11:41, Daryle Walker  a écrit :
> 
> 
>> On Jan 11, 2017, at 3:58 PM, Keary Suska  wrote:
>> 
>> 
>>> On Jan 11, 2017, at 11:16 AM, Jens Alfke  wrote:
>>> 
>>> 
 On Jan 10, 2017, at 2:00 PM, Jean-Daniel  wrote:
 
 UUID means Universally unique identifier and it must be unique: 
 https://en.wikipedia.org/wiki/UUID 
 >
 To generate an UUID, use a standard system function (CFUUID, NSUUID, 
 libuuid, …)
>>> 
>>> This is not what I believe Daryle was asking, and it’s sent everyone off on 
>>> a tangent about what UUIDs are.
>>> 
>>> My interpretation of the original question: Is an NSIncrementalStore’s UUID 
>>> scoped to the specific database, or is it scoped to that _implementation_ 
>>> of the store? That is, is the UUID generated at runtime or at compile time?
>>> 
>>> I don’t know the answer; just hoping to get the discussion back on track :)
>> 
>> The docs say:
>>  "A unique identifier for the store at the given URL. It must be 
>> uniquely and reproducibly derivable, such that multiple instances of your 
>> store return the same UUID”
>> 
>> My reading is that the store UUID would be unique to a specific database 
>> since it is only unique to the URL location of the store. I thin the docs 
>> use “instance” in a strictly OOP sense.
> 
> Yes, this is what my question is about. Could I grab a UUID from a 
> get-a-random-UUID site,

You don’t need a get a random UUID site to get an uuid. Open your terminal and 
type uuidgen.

> hard code it as a type-level property in Swift, and use it for every 
> instantiation (even for different files)? If this isn’t acceptable, I’m 
> seemingly stuck since the data format doesn’t have a UUID field within it and 
> I can’t base a UUID off of a hash of the file since it would change after 
> each edit.
> 
> Could I base the UUID off a hash of the URL? Maybe, but it wouldn’t survive 
> file moves. There are file references in macOS, which would be more stable, 
> but I read that there’s a bug in the URL class where it would degrade 
> file-reference URLs to standard-file URLs, so that’ll be problematic. Another 
> solution would to create bookmark data from a file URL and take a hash of 
> that. But are multiple bookmark data blocks of the same file URL consistent 
> enough for this idea to work?

Your storage should have metadata and contains the UUID. Each time you create a 
new database, you should generate a new UUID and store it in your storage 
metadata. 
If your storage don’t support that (that's unfortunate for a storage format 
that is supposed to support storing any type of data, as in practice you can 
always create a internal table to store them), maybe the best you can do is 
attach the metadata to the file directly using extended attributes for 
instance. Extended attribute may be lost by some operation, but it should be 
relatively stable as long as the file does not leave the machine.


___

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: On NSIncrementalStore UUID Uniqueness

[Daryle Walker]

> On Jan 11, 2017, at 3:58 PM, Keary Suska  wrote:
> 
> 
>> On Jan 11, 2017, at 11:16 AM, Jens Alfke  wrote:
>> 
>> 
>>> On Jan 10, 2017, at 2:00 PM, Jean-Daniel  wrote:
>>> 
>>> UUID means Universally unique identifier and it must be unique: 
>>> https://en.wikipedia.org/wiki/UUID 
>>> >> >
>>> To generate an UUID, use a standard system function (CFUUID, NSUUID, 
>>> libuuid, …)
>> 
>> This is not what I believe Daryle was asking, and it’s sent everyone off on 
>> a tangent about what UUIDs are.
>> 
>> My interpretation of the original question: Is an NSIncrementalStore’s UUID 
>> scoped to the specific database, or is it scoped to that _implementation_ of 
>> the store? That is, is the UUID generated at runtime or at compile time?
>> 
>> I don’t know the answer; just hoping to get the discussion back on track :)
> 
> The docs say:
>   "A unique identifier for the store at the given URL. It must be 
> uniquely and reproducibly derivable, such that multiple instances of your 
> store return the same UUID”
> 
> My reading is that the store UUID would be unique to a specific database 
> since it is only unique to the URL location of the store. I thin the docs use 
> “instance” in a strictly OOP sense.

Yes, this is what my question is about. Could I grab a UUID from a 
get-a-random-UUID site, hard code it as a type-level property in Swift, and use 
it for every instantiation (even for different files)? If this isn’t 
acceptable, I’m seemingly stuck since the data format doesn’t have a UUID field 
within it and I can’t base a UUID off of a hash of the file since it would 
change after each edit.

Could I base the UUID off a hash of the URL? Maybe, but it wouldn’t survive 
file moves. There are file references in macOS, which would be more stable, but 
I read that there’s a bug in the URL class where it would degrade 
file-reference URLs to standard-file URLs, so that’ll be problematic. Another 
solution would to create bookmark data from a file URL and take a hash of that. 
But are multiple bookmark data blocks of the same file URL consistent enough 
for this idea to work?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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: Retaining non-document windows

[Daryle Walker]

> On Jan 4, 2017, at 7:16 PM, Quincey Morris 
>  wrote:
> 
> On Jan 4, 2017, at 14:11 , Jean-Daniel  wrote:
>> 
>> When using storyboard, the only way to instantiate window is by getting a 
>> reference to the window controller (by using 
>> -instantiateControllerWithIdentifier:), so it should not be an issue.
> 
> The problem I was referring to is when the window [scene] is in the initial 
> controller. There’s no way (AFAIK) that you can statically set up a reference 
> to the WC in any combination of IB/code, and of course the storyboard 
> instantiation is not in your code.
> 
> Again AFAIK, you can get a reference to this WC from the window, and you can 
> get the [main] window from the NSApplication object, or from a view 
> controller’s view, but all of these things require you to defer getting the 
> reference until the objects are created and functional.
> 
> Or, you can subclass NSWindowController, and have the windowDidLoad override 
> add a controller reference to data structures somewhere.
> 
> But I think the old days when the template project provided a window 
> controller property on the app delegate for you are gone.
> 
> Of course, I’d be extremely happy to be wrong about this. (I assume the tea 
> leaves indicate that window controllers are on the way out, so don’t get too 
> used to them.)

Why would they go away, since they’re part of the document system (with 
NSDocument and NSDocumentController). The first thing I do with the default 
document-based project is to factor out the window (controller) code and 
storyboard out of the Document class and Main storyboard to separate files. 
Easier to handle early in case I add more code.

One big question I had was how to remove the window (controller) reference. I 
think there’s an NSNotification whenever a window closes; do I have to use that 
(or the equivalent window delegate method) to flag when to remove the pointer 
from my collection object (or set the single reference to NIL)?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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: What should we do if file-opening takes a long time?

[Daryle Walker]

> On Dec 31, 2016, at 9:03 PM, Charles Srstka  wrote:
> 
>> On Dec 31, 2016, at 7:35 PM, Graham Cox > > wrote:
>> 
>> NSProgress is thread safe and might be useful for this.
> 
> One thing to be careful about when using NSProgress with threads is not to 
> bind directly to it from your UI elements, since the updates will come in on 
> the same thread the changes were made on. Either register your observers 
> manually and call the main thread from 
> -observeValue:forKeyPath:ofObject:change:context:, or have your worker thread 
> call the main thread to update the NSProgress object.

[Just catching up on my e-mail now.]

Yeah, I just read that Cocoa Bindings is generally main-thread only, like the 
windows and views. I thought I could have a NSProgress subclass that takes a 
pointer to an existing progress object, KVO’s the heck out of all the remote 
object's attributes, then updates its own to match, but only posts from the 
main queue. The initializer would take the remote progress object, but it would 
also need the queue that the remote does its work on, so the local progress 
object can pass its cancel/pause/resume up to the remote object, right?

Would I have to KVO every attribute? Or is there a core list so I can use 
Progress’s included code to handle the rest? I’m also thinking of adding a 
Boolean flag to indicate completion. (You can’t use fraction-complete attribute 
since it’s floating-point.)

The “Progress” page has an “isOld” attribute that isn’t documented, also with 
some undocumented publish & subscribe API. Are those a mistake? Or an obsolete 
API (and we should use the documented members)?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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