Re: NSFileWrapper

On Sun, Jun 5, 2016, at 01:14 AM, Chris Ridd wrote: > > > On 4 Jun 2016, at 23:02, Daryle Walker wrote: > > > >> On Jun 4, 2016, at 12:18 PM, Peter Hudson wrote: > >> > >> Hi Mike > >> > >> You're right - I want the behaviour of a package. Do you happen to know > >> how I can achieve it? I

Re: NSFileWrapper

> On 6 Jun 2016, at 4:31 AM, Jens Alfke wrote: > > So I guess NSFileWrapper’s not popular on the AppKit team either :) Seems a pity, as in some cases it’s handy to pass around something that mirrors the structure of a chunk of disk storage. If it loaded its content lazily it wouldn’t have thi

Re: NSFileWrapper

> On Jun 4, 2016, at 11:52 PM, Charles Srstka wrote: > > Every time I’ve ever tried to use NSFileWrapper, I’ve always ended up having > to switch to something else because of the memory issue that Jens mentions. > Never really understood the point of that class. I was going to say that "AFAIK

Re: NSFileWrapper

> On Jun 5, 2016, at 1:27 AM, Graham Cox wrote: > > >> On 5 Jun 2016, at 8:02 AM, Daryle Walker wrote: >> >> You have to come up with a new extension. For instance, if you’re already >> using “.xyz” for you single-file format, you could use “.xyz-pkg” for your >> package format. > > > You

Re: NSFileWrapper

Hi All Many thanks to everyone who has contributed to this thread on NSFileWrapper. I have enough insight now to do some work to see what works. Again, thanks to everybody ! Peter ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do no

Re: NSFileWrapper

> On 5 Jun 2016, at 8:02 AM, Daryle Walker wrote: > > You have to come up with a new extension. For instance, if you’re already > using “.xyz” for you single-file format, you could use “.xyz-pkg” for your > package format. You can use the same extension and leave it to your app to figure ou

Re: NSFileWrapper

> On 4 Jun 2016, at 23:02, Daryle Walker wrote: > >> On Jun 4, 2016, at 12:18 PM, Peter Hudson wrote: >> >> Hi Mike >> >> You're right - I want the behaviour of a package. Do you happen to know how >> I can achieve it? I had presumed it might be some mix of flag setting at >> system level

Re: NSFileWrapper

lah > Sent: Saturday, 4 June 2016 17:12 > To: Peter Hudson > Cc: cocoa-dev@lists.apple.com List > Subject: Re: NSFileWrapper > > It sounds like you want your file format to be what is known as a “package”. > It’s a directory, but is (mostly) presented as a single file. > &g

Re: NSFileWrapper

On Jun 4, 2016, at 14:10 , Markus Spoettl wrote: > > you have complete control over what individual file you read and when That’s fine for documents where it’s helpful not to have to read files only to write them out unchanged on a save. It doesn’t really help when you need to read large amoun

Re: NSFileWrapper

On 04/06/16 18:42, Jens Alfke wrote: I wouldn’t recommend NSFileWrapper for large files, because it reads all of a file into memory. I find this comment to be very misleading. Part of the reason why packages are so great (apart from being supported by NSDocument/AppKit as a method to store do

Re: NSFileWrapper

Jens Thanks for these notes - extremely helpful. I think I will kick off with Realm and see where I get too. Peter > On 4 Jun 2016, at 20:36, Jens Alfke wrote: > > >> On Jun 4, 2016, at 9:51 AM, Peter Hudson > > wrote: >> >> “If your app’s performance is sufferi

Re: NSFileWrapper

> On Jun 4, 2016, at 9:51 AM, Peter Hudson wrote: > > “If your app’s performance is suffering because of large files, then use > streams instead, and try to only read the part of the file that’s necessary.” > Could you point me at some material about this technique ? It sounds very > interest

Re: NSFileWrapper

Hi Jens “If your app’s performance is suffering because of large files, then use streams instead, and try to only read the part of the file that’s necessary.” Could you point me at some material about this technique ? It sounds very interesting. I will check out the database approach as well.

Re: NSFileWrapper

> On Jun 4, 2016, at 9:18 AM, Peter Hudson wrote: > > You're right - I want the behaviour of a package. Do you happen to know how I > can achieve it? I had presumed it might be some mix of flag setting at > system level. If for example i set the extension on an NSFileWrapper to > .bundle

Re: NSFileWrapper

t how to ‎get an icon of my choosing associated with it.  Peter   Original Message   From: Mike Abdullah Sent: Saturday, 4 June 2016 17:12 To: Peter Hudson Cc: cocoa-dev@lists.apple.com List Subject: Re: NSFileWrapper It sounds like you want your file format to be what is known as a “package”. I

Re: NSFileWrapper

It sounds like you want your file format to be what is known as a “package”. It’s a directory, but is (mostly) presented as a single file. NSFileWrapper is an API for working with files, it does not directly control whether something is a package or not. It just happens to be the most convenien

Re: NSFileWrapper serializedRepresentation

On Apr 4, 2016, at 17:41 , Gerriet M. Denkmann wrote: > > What are the alternatives? What I had in mind is that you would construct a composite NSData object that contained the results of compressing each file’s content as sub-components. By compressing this yourself, you could (for example) c

Re: NSFileWrapper serializedRepresentation

> On 5 Apr 2016, at 08:30, Jens Alfke wrote: > > >> On Apr 4, 2016, at 9:59 AM, Gerriet M. Denkmann wrote: >> >> Both the Simulator and the OS X App compress the same folder (which resides >> on OS X). > > OK, but the raw data size is significantly different, so they must be zipping > diff

Re: NSFileWrapper serializedRepresentation

> On 5 Apr 2016, at 11:30 AM, Gerriet M. Denkmann wrote: > > >> On 5 Apr 2016, at 08:17, Graham Cox wrote: >> >>> On 5 Apr 2016, at 10:41 AM, Gerriet M. Denkmann >>> wrote: >>> >>> What are the alternatives? >> >> file paths or NSURL? > > Not really. If I send file paths or NSURLs (point

Re: NSFileWrapper serializedRepresentation

> On Apr 4, 2016, at 9:59 AM, Gerriet M. Denkmann wrote: > > Both the Simulator and the OS X App compress the same folder (which resides > on OS X). OK, but the raw data size is significantly different, so they must be zipping different data. I don’t know why that would be; maybe the file pat

Re: NSFileWrapper serializedRepresentation

> On 5 Apr 2016, at 08:17, Graham Cox wrote: > >> On 5 Apr 2016, at 10:41 AM, Gerriet M. Denkmann wrote: >> >> What are the alternatives? > > file paths or NSURL? Not really. If I send file paths or NSURLs (pointing to files on OS X) to my iOS Devices, these would not be very useful. I real

Re: NSFileWrapper serializedRepresentation

> On 5 Apr 2016, at 10:41 AM, Gerriet M. Denkmann wrote: > > What are the alternatives? file paths or NSURL? —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Con

Re: NSFileWrapper serializedRepresentation

> On 5 Apr 2016, at 00:35, Quincey Morris > wrote: > > On Apr 4, 2016, at 09:59 , Gerriet M. Denkmann wrote: >> >> Both the Simulator and the OS X App compress the same folder (which resides >> on OS X). > Incidentally, the OS X documentation for NSFileContentsPboardType, > serializedRepre

Re: NSFileWrapper serializedRepresentation

On Apr 4, 2016, at 09:59 , Gerriet M. Denkmann wrote: > > Both the Simulator and the OS X App compress the same folder (which resides > on OS X). You can’t really use a convenience API such as ‘serializedRepresentation’ and then complain it doesn’t optimize for your specific use case. Concise

Re: NSFileWrapper serializedRepresentation

> On 4 Apr 2016, at 23:49, Jens Alfke wrote: > > >> On Apr 4, 2016, at 1:18 AM, Gerriet M. Denkmann wrote: >> >> When I do this in OS X 10.11.4 dataRaw = 30380898, dataCompressed = 5638680 >> ( 18.6 %) >> But in the iOS Simulator 9.3.1: dataRaw = 28206422, dataCompressed = 4282602 >> ( 15.2

Re: NSFileWrapper serializedRepresentation

> On Apr 4, 2016, at 1:18 AM, Gerriet M. Denkmann wrote: > > When I do this in OS X 10.11.4 dataRaw = 30380898, dataCompressed = 5638680 ( > 18.6 %) > But in the iOS Simulator 9.3.1: dataRaw = 28206422, dataCompressed = 4282602 > ( 15.2 %) > > That is OS X (10.11.4) makes an 8 % bigger FileWr

Re: NSFileWrapper - is this really so bad?

Perhaps just a little too OCD; however, if one is sending a message like count to a large number of containers using nil (Null) can be considerably more efficient then passing an empty shared instance. The Objective-C pattern when sending a message to a nil object pointer avoids the overhead of

Re: NSFileWrapper - is this really so bad?

> On Oct 27, 2015, at 7:08 PM, Graham Cox wrote: > >> On 28 Oct 2015, at 10:53 AM, Alex Kac > > wrote: >> >> Have you tried simply passing in a blank dictionary? Is that OK? > > > Yes, that works OK. It’s at least a simple way to shut the warning up, though >

Re: NSFileWrapper - is this really so bad?

> On 28 Oct 2015, at 10:53 AM, Alex Kac wrote: > > Have you tried simply passing in a blank dictionary? Is that OK? Yes, that works OK. It’s at least a simple way to shut the warning up, though strikes me as unnecessary and inefficient, FWIW. —G. __

Re: NSFileWrapper - is this really so bad?

On Oct 27, 2015, at 16:24 , Graham Cox wrote: > > NSFileWrapper* fw = [[NSFileWrapper alloc] > initDirectoryWithFileWrappers:nil]; //<— Null passed to a callee > that requires a non-null argument It’s not necessarily so much about null vs non-null. A side effect of the API aud

Re: NSFileWrapper - is this really so bad?

> On 28 Oct 2015, at 10:24 AM, Graham Cox wrote: > > due to the addition of the NON_NULL qualifier Actually, I should amend that: it doesn’t have ANY qualifier, so that appears by default to mean that it’s NOT nullable. I’m still getting used to this additional syntax. —G. __

Re: NSFileWrapper - is this really so bad?

> On Oct 27, 2015, at 4:24 PM, Graham Cox wrote: > > In XCode 7, I’m getting a new warning when compiling some code that uses > NSFileWrapper, due to the addition of the NON_NULL qualifier: > > Null passed to a callee that requires a non-null argument > > The code is: > > NSFileWrapper

Re: NSFileWrapper - is this really so bad?

> On Oct 27, 2015, at 16:24 , Graham Cox wrote: > > In XCode 7, I’m getting a new warning when compiling some code that uses > NSFileWrapper, due to the addition of the NON_NULL qualifier: > > Null passed to a callee that requires a non-null argument > > The code is: > > NSFileWrapper*

Re: NSFileWrapper and plist

On Sep 13, 2013, at 6:46 PM, Trygve Inda wrote: > I have an NSDictionary that contains objects that support NSCopying. I can > use writeToFile:atomically: and it saves a nice plist file that I can read > cleanly. > > If I use NSFileWrapper however (for my document-based app), I need to use a > ke

Re: NSFileWrapper NSKeyedArchiver and Mutability

On 25/06/2013, at 8:53 AM, Trygve Inda wrote: > NSMutableDictionary* myMutDict = [[NSMutableDictionary alloc] init]; > NSData* myMutData = [NSKeyedArchiver archivedDataWithRootObject:myMutDict]; > > If I unarchive this, I was under the impression that it would return an > immutable object. Arc

Re: NSFileWrapper Role

As an added advantage on top of that it can avoid loading existing files into memory until needed. This is particularly handy when writing document packages as those files can be written quickly as hard links, rather than loading into memory and writing out afresh. Sent from my iPad On 25 Feb

Re: NSFileWrapper Role

On 25/02/2012, at 2:47 PM, -Sergei G- wrote: > I don't quite get the role of NSFileWrapper. It appears to provide a subset > of NSFileManager functionality. Some of the Apple samples use NSFileWrapper > to implement bundle support, but it is not clear if that's a requirement or > just a choic

Re: NSFileWrapper serializedRepresentation bloat?

Not sure its related, but I have noticed that using Finder nowadays to create an alias of a plain folder results in a 1MB alias file. Seems its also stashing away a copy of the plain folder icon. (Actually it is stashing two copies, one in the resource fork for compatibility and one in the data

Re: NSFileWrapper serializedRepresentation bloat?

Problem ID: 8840391 _murat On Jan 8, 2011, at 7:55 PM, Ken Ferry wrote: > Hi, > > That's what I see too. From inspecting the serialized rep, it looks like > it's icon data. > > Since at least in my test case the folders did not have custom icons, it > seems like one could do better. Could

Re: NSFileWrapper serializedRepresentation bloat?

Hi, That's what I see too. From inspecting the serialized rep, it looks like it's icon data. Since at least in my test case the folders did not have custom icons, it seems like one could do better. Could you file a bug please? -Ken Cocoa Frameworks On Sat, Jan 8, 2011 at 5:16 PM, mlist0...@gm