Re: Excessive open gui graphics files on Mavericks

2014-04-08 Thread Charles Srstka
On Apr 9, 2014, at 12:32 AM, John Joyce  
wrote:

> Sure. Core Data would work just as well as binary blobs.
> Base64 would work in plists / xml / keyed archives / yaml / json whatever.
> Serializing a dictionary or custom object would make it really simple and 
> easy to manage.

This is true. Also: just reading the individual files with NSData would work 
just as well as any of those.

> As a text file, you could compress the heck out of it if needed to reduce 
> file size for app distribution.

Which would surely make a world of difference, given that these are *image 
files* and thus probably already compressed.

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: Excessive open gui graphics files on Mavericks

2014-04-08 Thread John Joyce

On Apr 9, 2014, at 2:28 PM, ChanMaxthon  wrote:

> The SQLite DB thing is just like a tar archive, and if you dare to you can 
> even include a cramfs driver in your code and consolidate all your resources 
> into one optionally encrypted cramfs image. Every file archiving method that 
> allows in-memory expansion works, and my personal recommendation is tar and 
> cramfs, since the first is very common and easily handled, and the latter is 
> a proper file system that is designed to be expanded in memory (mostly used 
> as initramfs for Linux)
> 
> Sent from my iPad

Sure. Core Data would work just as well as binary blobs.
Base64 would work in plists / xml / keyed archives / yaml / json whatever.
Serializing a dictionary or custom object would make it really simple and easy 
to manage.
As a text file, you could compress the heck out of it if needed to reduce file 
size for app distribution.
Decompress it at first launch into the app’s Application Support folder.
___

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: Excessive open gui graphics files on Mavericks

2014-04-08 Thread ChanMaxthon
The SQLite DB thing is just like a tar archive, and if you dare to you can even 
include a cramfs driver in your code and consolidate all your resources into 
one optionally encrypted cramfs image. Every file archiving method that allows 
in-memory expansion works, and my personal recommendation is tar and cramfs, 
since the first is very common and easily handled, and the latter is a proper 
file system that is designed to be expanded in memory (mostly used as initramfs 
for Linux)

Sent from my iPad

> On Apr 9, 2014, at 1:22 PM, dangerwillrobinsondan...@gmail.com wrote:
> 
> 
> 
>> On 2014/04/09, at 13:28, Jens Alfke  wrote:
>> 
>> 
>>> On Apr 8, 2014, at 8:57 PM, Maxthon Chan  wrote:
>>> 
>>> You can avoidd this by consolidating all your resource files into one big 
>>> archive file that is expanded in-memory into NSData files. I still vaguely 
>>> remember a library that parses tar file into a dictionary of NSData 
>>> objects. You can use that library to consolidate all your resources into 
>>> one single tarball.
>> 
>> I don’t think that has anything to do with this. If you want to avoid 
>> +imageNamed:, it’s easy to load individual image files as data, as I said, 
>> without having to change anything about the way the resources are stored on 
>> disk.
>> 
>> —jens
> 
> It might be good to know if any of the file descriptors are pointing to the 
> same files. 
> From the lsof snippet the files are in your bundle so look at how your code 
> is loading resources. If you have duplicate descriptors you want to find a 
> way to load lazily, load once and let go if the descriptor when not in use. 
> Here's one way. 
> If you have tons of images, borrow a page from Sprite Kit, use an image 
> atlas. One descriptor, many positional images.
> It's just an image with subimages at known positions. Then you can reuse the 
> same image and just draw the parts you need where you need them. 
> 
> Other similar alternatives. 
> Base64 encode images into one file. It could even be an SQLite db file. 
> Fetch the encoded images  you need and decode. 
> 

___

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: Excessive open gui graphics files on Mavericks

2014-04-08 Thread dangerwillrobinsondanger


> On 2014/04/09, at 13:28, Jens Alfke  wrote:
> 
> 
>> On Apr 8, 2014, at 8:57 PM, Maxthon Chan  wrote:
>> 
>> You can avoidd this by consolidating all your resource files into one big 
>> archive file that is expanded in-memory into NSData files. I still vaguely 
>> remember a library that parses tar file into a dictionary of NSData objects. 
>> You can use that library to consolidate all your resources into one single 
>> tarball.
> 
> I don’t think that has anything to do with this. If you want to avoid 
> +imageNamed:, it’s easy to load individual image files as data, as I said, 
> without having to change anything about the way the resources are stored on 
> disk.
> 
> ―jens

It might be good to know if any of the file descriptors are pointing to the 
same files. 
From the lsof snippet the files are in your bundle so look at how your code is 
loading resources. If you have duplicate descriptors you want to find a way to 
load lazily, load once and let go if the descriptor when not in use. 
Here's one way. 
If you have tons of images, borrow a page from Sprite Kit, use an image atlas. 
One descriptor, many positional images.
It's just an image with subimages at known positions. Then you can reuse the 
same image and just draw the parts you need where you need them. 

Other similar alternatives. 
Base64 encode images into one file. It could even be an SQLite db file. 
Fetch the encoded images  you need and decode. 


___

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: Opinion: Core Data or roll my own?

2014-04-08 Thread Rick Mann

On Apr 8, 2014, at 18:09 , Graham Cox  wrote:

> 
> On 9 Apr 2014, at 8:13 am, Rick Mann  wrote:
> 
>> As I write this, I realize that I can't just keep a whole document in 
>> memory; the library (which would be a collection of separate files on disk, 
>> but presented as a unified collection of content in the UI) could be very 
>> large and I'd rather not load in the whole thing. Nevertheless, I think 
>> that's doable.
> 
> 
> I have no comment regarding Core Data, but just a general comment regarding 
> this remark.
> 
> This sounds very much like what I do in both our vector apps to present a 
> collection of library items. These run to thousands of items in multiple 
> libraries, organised into sets called categories, presented through a single 
> UI which allows the user to organise them and use them. We don't load the 
> whole collection into memory, though we do have an in-memory representation 
> of that collection which tracks the location of the original file and an 
> image (and other metadata) representing the item. The UI shows that image 
> which is loaded lazily and on a secondary thread, so the UI remains 
> responsive even when scrolling through thousands of items.
> 
> If the user wants to incorporate a library item into their document, then the 
> "real" item is loaded at the point of use, and occupies memory from then on.
> 
> Point is: we've never run into memory or performance issues with this. I 
> guess at some point stuff could well get paged out but we don't do anything 
> to prevent that. In practice, I've rarely noticed delays caused by that 
> occurring, and typically it's been because of another foreground app needing 
> to page its stuff in. In many cases I would imagine that the image we load (a 
> pdf) is actually larger than the real data - but even then it's still not a 
> practical problem. So far we've seen no scalability issues  up to the order 
> of tens of thousands of items - how large is your library likely to be? 
> 10,000 different vector objects is actually a pretty large number. Again, in 
> practice the way this is used is that a user often filters that down to a 
> small set of items they need for a project (they can build their own 
> categories, collections and "smart" sets based on predicates) - an entire 
> collection can be overwhelming - and stuff that's never browsed never even 
> loads the image and metadata, so the reality of the in-memory copy is that 
> it's actually a small subset of what out there on disk almost all of the 
> time. So yes, it's doable - we've done it and it works fine. Unless your 
> needs are significantly larger than this, I wouldn't sweat the memory 
> requirements at this stage.
> 
> Our scheme doesn't use Core Data. It probably could, but I've never been 
> totally sold on it personally.

Thanks for that data point, Graham. My app is very similar in this regard to 
yours, and that's exactly how I was thinking of treating it.

On Apr 8, 2014, at 17:31 , BareFeetWare  wrote:

> One option is to use SQLite. I've been putting together an open source 
> "BFWQuery" library to hopefully simplify the whole thing, by letting you 
> treat a database query just like an array of dictionaries. It uses FMDB 
> (thanks Gus).

Well, if I were to do this, one of the reasons would be to create a text 
representation that could be easily diffed. I took a look at Core Data's XML 
format, and while necessarily verbose, it would work pretty well, until the 
schema changed.

-- 
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: Excessive open gui graphics files on Mavericks

2014-04-08 Thread Jens Alfke

On Apr 8, 2014, at 8:57 PM, Maxthon Chan  wrote:

> You can avoidd this by consolidating all your resource files into one big 
> archive file that is expanded in-memory into NSData files. I still vaguely 
> remember a library that parses tar file into a dictionary of NSData objects. 
> You can use that library to consolidate all your resources into one single 
> tarball.

I don’t think that has anything to do with this. If you want to avoid 
+imageNamed:, it’s easy to load individual image files as data, as I said, 
without having to change anything about the way the resources are stored on 
disk.

—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: Excessive open gui graphics files on Mavericks

2014-04-08 Thread Maxthon Chan
You can avoidd this by consolidating all your resource files into one big 
archive file that is expanded in-memory into NSData files. I still vaguely 
remember a library that parses tar file into a dictionary of NSData objects. 
You can use that library to consolidate all your resources into one single 
tarball.

On Apr 9, 2014, at 11:26, Greg Parker  wrote:

> On Apr 8, 2014, at 12:13 PM, Michael Domino 
>  wrote:
>> Some of my customers running on Mavericks are having problems with "too many 
>> open files" errors. Raising the limit does solve the problem, but I've 
>> noticed that on 10.6, at idle, my app opens about 47 files, none of them gui 
>> graphics files. On Mavericks, the very same build of the app opens 102 files 
>> and keeps them open for the duration of the process existence.
> 
> Dumb solution: raise the open file limit. 
> 
> The default limit for an application double-clicked in the Finder is 256 
> descriptors. You can raise it by calling setrlimit() with the RLIMIT_NOFILE 
> option. Setting it to something like 512 or 1024 during your app's launch 
> should help your customers out while you figure out if there is excessive 
> descriptor use in your app or in the OS. 
> 
> If your customers start hitting the higher limit then you know you have a 
> more serious problem to resolve. There is a system-wide limit (around 20K 
> IIRC) so you can't just raise it forever.
> 
> 
> -- 
> Greg Parker gpar...@apple.com Runtime Wrangler
> 
> 
> 
> ___
> 
> 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/xcvista%40me.com
> 
> This email sent to xcvi...@me.com



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: Excessive open gui graphics files on Mavericks

2014-04-08 Thread Greg Parker
On Apr 8, 2014, at 12:13 PM, Michael Domino  
wrote:
> Some of my customers running on Mavericks are having problems with "too many 
> open files" errors. Raising the limit does solve the problem, but I've 
> noticed that on 10.6, at idle, my app opens about 47 files, none of them gui 
> graphics files. On Mavericks, the very same build of the app opens 102 files 
> and keeps them open for the duration of the process existence.

Dumb solution: raise the open file limit. 

The default limit for an application double-clicked in the Finder is 256 
descriptors. You can raise it by calling setrlimit() with the RLIMIT_NOFILE 
option. Setting it to something like 512 or 1024 during your app's launch 
should help your customers out while you figure out if there is excessive 
descriptor use in your app or in the OS. 

If your customers start hitting the higher limit then you know you have a more 
serious problem to resolve. There is a system-wide limit (around 20K IIRC) so 
you can't just raise it forever.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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: Excessive open gui graphics files on Mavericks

2014-04-08 Thread Quincey Morris
On Apr 8, 2014, at 16:15 , Jens Alfke  wrote:

> IIRC, the AppKit release notes for 10.9 (or 10.8?) talk about behavior 
> changes in +[NSImage imageNamed:]. Putting that together with what you’re 
> saying, it may be that it now memory-maps the image data instead of copying 
> it into heap space. That would be more memory efficient but has the side 
> effect of consuming a file descriptor.

What the release notes for 10.9 actually say is:

> "Prior to Mac OS 10.9 images loaded through +[NSImage imageNamed:] were 
> retained for the lifetime of the application. For applications linked on 10.9 
> and later this is no longer the case. Images loaded through +[NSImage 
> imageNamed:] will still be cached for a brief time.”

which suggests less caching, not more, though file descriptor usage could still 
be implicated.

The other thing is, in the past when I inadvertently used up all the file 
descriptors, the limit was about 8000 descriptors. If we’re talking about even 
a couple of hundred descriptors here, it seems likely that whatever’s using 
descriptors indiscriminately is elsewhere in the app. (Though of course 
avoiding the waste of a couple of hundred is worth doing too.)

___

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: Opinion: Core Data or roll my own?

2014-04-08 Thread Jens Alfke

On Apr 8, 2014, at 5:31 PM, BareFeetWare  
wrote:

> for (NSDictionary* rowDict in query.resultArray) {
>   NSLog(@"%@: (%@, %@)", rowDict[@"Name"], rowDict[@"Latitude"], 
> rowDict[@"Longitude"]);
> }
> 
> Or to just get row 3's value for Name:
> 
> query.resultArray[3][@"Name"];

Watch out: I have found this degree of abstraction to become a major 
performance bottleneck. It results in large numbers of object allocations and 
message-sends during query evaluation. Late in development of the first 
implementation of Safari RSS in OS X 10.4, I had to go through code like this 
and try various nasty tricks to cache and reuse objects, to try to speed it up 
enough, because it was too late to redesign the query APIs to be closer to the 
metal.

The query API in FMDB itself is more efficient, and I think clearer, although 
not perfect. In my current usage I make sure to only use the numeric-indexed 
accessors (i.e. get column 2 rather than column “Latitude”) because they’re 
much faster.

—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: Opinion: Core Data or roll my own?

2014-04-08 Thread Graham Cox

On 9 Apr 2014, at 8:13 am, Rick Mann  wrote:

> As I write this, I realize that I can't just keep a whole document in memory; 
> the library (which would be a collection of separate files on disk, but 
> presented as a unified collection of content in the UI) could be very large 
> and I'd rather not load in the whole thing. Nevertheless, I think that's 
> doable.


I have no comment regarding Core Data, but just a general comment regarding 
this remark.

This sounds very much like what I do in both our vector apps to present a 
collection of library items. These run to thousands of items in multiple 
libraries, organised into sets called categories, presented through a single UI 
which allows the user to organise them and use them. We don't load the whole 
collection into memory, though we do have an in-memory representation of that 
collection which tracks the location of the original file and an image (and 
other metadata) representing the item. The UI shows that image which is loaded 
lazily and on a secondary thread, so the UI remains responsive even when 
scrolling through thousands of items.

If the user wants to incorporate a library item into their document, then the 
"real" item is loaded at the point of use, and occupies memory from then on.

Point is: we've never run into memory or performance issues with this. I guess 
at some point stuff could well get paged out but we don't do anything to 
prevent that. In practice, I've rarely noticed delays caused by that occurring, 
and typically it's been because of another foreground app needing to page its 
stuff in. In many cases I would imagine that the image we load (a pdf) is 
actually larger than the real data - but even then it's still not a practical 
problem. So far we've seen no scalability issues  up to the order of tens of 
thousands of items - how large is your library likely to be? 10,000 different 
vector objects is actually a pretty large number. Again, in practice the way 
this is used is that a user often filters that down to a small set of items 
they need for a project (they can build their own categories, collections and 
"smart" sets based on predicates) - an entire collection can be overwhelming - 
and stuff that's never browsed never even loads the image and metadata, so the 
reality of the in-memory copy is that it's actually a small subset of what out 
there on disk almost all of the time. So yes, it's doable - we've done it and 
it works fine. Unless your needs are significantly larger than this, I wouldn't 
sweat the memory requirements at this stage.

Our scheme doesn't use Core Data. It probably could, but I've never been 
totally sold on it personally.

--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: Opinion: Core Data or roll my own?

2014-04-08 Thread BareFeetWare
Hi Rick,

One option is to use SQLite. I've been putting together an open source 
"BFWQuery" library to hopefully simplify the whole thing, by letting you treat 
a database query just like an array of dictionaries. It uses FMDB (thanks Gus).

eg: query.resultArray[row][columnName]

Here is an example:

BFWDatabase* database = [[BFWDatabase alloc] initWithPath:[self databasePath]];
BFWQuery* query = [[BFWQuery alloc] initWithDatabase:database
 queryString:@"select Name, Latitude, 
Longitude from Country where Language = ? and Latitude > ? order by Name"
   arguments:@[@"English", @30.0]];
for (NSDictionary* rowDict in query.resultArray) {
NSLog(@"%@: (%@, %@)", rowDict[@"Name"], rowDict[@"Latitude"], 
rowDict[@"Longitude"]);
}

Or to just get row 3's value for Name:

query.resultArray[3][@"Name"];

That's all there is to it.

Behind the scenes, BFWQuery only retrieves rows from the database as requested, 
so it doesn't create an in memory array containing all of the results.

Since it's SQL, you can create your own relationships and efficient database 
schema, which should perform better than CoreData.

You can also change the data with method calls like:

[database updateTable:@"Country"
  rowDict:@{@"Name":@"Oz"}
whereDict:@{@"Name":@"Australia"}];

See:
https://bitbucket.org/barefeetware/bfwquery

Tom

Tom Brodhurst-Hill
BareFeetWare 👣

--
iPhone/iPad/iPod and Mac software development, specialising in databases
develo...@barefeetware.com
--
Follow us on Twitter: http://twitter.com/barefeetware/
Like us on Facebook: http://www.facebook.com/BareFeetWare

 
On 9 Apr 2014, at 8:13 am, Rick Mann  wrote:

> I'm generally a big fan of Core Data, but I'm developing a moderately 
> complicated CAD app with libraries and design documents and such, and 
> beginning to wonder if it would be easier to do if I weren't fighting Core 
> Data. I'm wondering what the tradeoffs might be.
> 
> If I were to dump Core Data, I'd keep the entire object graph in memory all 
> the time, writing it out completely each time. I'd probably write XML, or 
> some other text-based format (as much as I abhor text-based formats) because 
> of the ease in diffing changes and using it with source control.
> 
> As I write this, I realize that I can't just keep a whole document in memory; 
> the library (which would be a collection of separate files on disk, but 
> presented as a unified collection of content in the UI) could be very large 
> and I'd rather not load in the whole thing. Nevertheless, I think that's 
> doable.
> 
> I'd have to handle relationships myself, but all the data types become easier 
> to manage (I use a lot of C structs, well, really C++ structs).


___

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: Opinion: Core Data or roll my own?

2014-04-08 Thread edward taffel
that’s how i should do it. particularly, if you have complicated selections 
that me must be undone/redone you’ll find you have excellent control, as well.


On Apr 8, 2014, at 7:46 PM, Rick Mann  wrote:

> 
> On Apr 8, 2014, at 16:41 , edward taffel  wrote:
> 
>> moving history into your model will better facilitate portability [in case 
>> you’re thinking in this direction].
> 
> Is that how that works? The history ends up in my model?
> 
> -- 
> Rick
> 
> 
> 


___

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: Opinion: Core Data or roll my own?

2014-04-08 Thread Rick Mann

On Apr 8, 2014, at 16:41 , edward taffel  wrote:

> moving history into your model will better facilitate portability [in case 
> you’re thinking in this direction].

Is that how that works? The history ends up in my model?

-- 
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: Opinion: Core Data or roll my own?

2014-04-08 Thread edward taffel
using NSDocument w/ autosaves is a great way to go—lots of bang for your buck!
xml could open possibilities in terms of web potential.
moving history into your model will better facilitate portability [in case 
you’re thinking in this direction].

all good things for a cad app.

On Apr 8, 2014, at 6:24 PM, Rick Mann  wrote:

> Well, one of the issues is the data types. It's a bit clunky, but workable. 
> There's one type of entity I want to create, a "Properties" table that maps 
> strings to arbitrary value types. This would be trivial if I managed it 
> myself, but Core Data doesn't let me have an entity attribute of type id, 
> AFAIK. The other problem I'm facing, which is probably due to me 
> misunderstanding NSPersistentDocument, is that I want my Library document to 
> always autosave (in the sense that it programmatically saves after changes 
> like adding a new Part object, rather than presenting the user with a save 
> sheet). I haven't quite figured out how to do this. There are the saveToURL: 
> methods, but what URL? It was opened from a file, it should know that. I just 
> want to persist changes and clear the dirty state. Maybe I'd have the same 
> issues with a "regular" NSDocument.
> 
> The other thing (I meant to mention in the original email) is that I can't 
> take advantage of autosave and async file operations, etc.
> 
> BUT: Do I lose a lot of undo support? I've never tried to implement undo 
> without Core Data.
> 
> On Apr 8, 2014, at 15:15 , Mike Manzano  wrote:
> 
>> Depends. Why are you “fighting” Core Data?
>> 
>> Mike
>> 
>> 
>> 
>> On Apr 8, 2014, 3:13:12 PM, Rick Mann  wrote:
>> This may prove to be an unproductive question to pose, so I apologize in 
>> advance. 
>> 
>> I'm generally a big fan of Core Data, but I'm developing a moderately 
>> complicated CAD app with libraries and design documents and such, and 
>> beginning to wonder if it would be easier to do if I weren't fighting Core 
>> Data. I'm wondering what the tradeoffs might be. 
>> 
>> If I were to dump Core Data, I'd keep the entire object graph in memory all 
>> the time, writing it out completely each time. I'd probably write XML, or 
>> some other text-based format (as much as I abhor text-based formats) because 
>> of the ease in diffing changes and using it with source control. 
>> 
>> As I write this, I realize that I can't just keep a whole document in 
>> memory; the library (which would be a collection of separate files on disk, 
>> but presented as a unified collection of content in the UI) could be very 
>> large and I'd rather not load in the whole thing. Nevertheless, I think 
>> that's doable. 
>> 
>> I'd have to handle relationships myself, but all the data types become 
>> easier to manage (I use a lot of C structs, well, really C++ structs). 
>> 
>> Thoughts? Thanks! 
>> 
>> -- 
>> Rick 
>> 
>> 
>> 
>> - signature.asc, 211 bytes
>> ___
>> 
>> 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/mike%40instantvoodoomagic.com
>> 
>> This email sent to m...@instantvoodoomagic.com
> 
> 
> -- 
> Rick
> 
> 
> 
> ___
> 
> 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/etaffel%40me.com
> 
> This email sent to etaf...@me.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: Opinion: Core Data or roll my own?

2014-04-08 Thread Jens Alfke

On Apr 8, 2014, at 3:13 PM, Rick Mann  wrote:

> As I write this, I realize that I can't just keep a whole document in memory; 
> the library (which would be a collection of separate files on disk, but 
> presented as a unified collection of content in the UI) could be very large 
> and I'd rather not load in the whole thing. Nevertheless, I think that's 
> doable.

In my experience (and I’ve done this at least three times), creating an object 
model that can be “paged” in and out from disk is hard, and takes more 
development time than you think it will. It may not seem hard to get it mostly 
working, but you keep having to come back to it to fix bugs or handle edge 
cases. I’m not a big fan of Core Data, but if you’ve worked with it before I 
suspect you’ll find it more efficient to use it for this than to roll your own.

—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: Excessive open gui graphics files on Mavericks

2014-04-08 Thread Jens Alfke

On Apr 8, 2014, at 12:13 PM, Michael Domino  
wrote:

> The difference is the graphics files used by the gui. There are no .png files 
> opened on 10.6 while the app is at idle, but on Mavericks we have all of 
> these taking up file descriptors (partial lsof output below).

IIRC, the AppKit release notes for 10.9 (or 10.8?) talk about behavior changes 
in +[NSImage imageNamed:]. Putting that together with what you’re saying, it 
may be that it now memory-maps the image data instead of copying it into heap 
space. That would be more memory efficient but has the side effect of consuming 
a file descriptor.

> I don't directly open any of these files, and the only visible icons at the 
> time are the 15 main toolbar buttons.
> So is there a way to change this behavior and close these files?

I suspect you didn’t directly open the files, but called +[NSImage imageNamed:] 
and retained the NSImage object, which is now hanging onto a file descriptor.

If this is true, you may be able to get around it by either keeping fewer of 
these resource-based NSImages around, at least not ones that aren’t currently 
being displayed, or by loading them using a different API. For example you 
could load the data into an NSData and then create an NSImage from that.

Disclaimer: This is total speculation and quite possibly wrong. But it should 
at least give you some ideas for experiments or workarounds.

—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: Opinion: Core Data or roll my own?

2014-04-08 Thread Sean McBride
On Tue, 8 Apr 2014 15:47:21 -0700, Rick Mann said:

>Oh, maybe you're right; that would work if I just coded up my class's
>property as "id", wouldn't it? Don't know why I thought that wouldn't work.

For example, we have a class that represents a 4x4 matrix.  It conforms to 
NSCoding to serialize itself.  In the xcdatamodel, when we want to use one of 
these objects, we set the attribute type to 'transformable'.  As we also use 
mogenerator (which I strongly recommend), we set in the user info dictionary a 
key of 'attributeValueClassName' with value 'MyClassName', then mogenerator 
will make accessors with the right types too.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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: Opinion: Core Data or roll my own?

2014-04-08 Thread Rick Mann

On Apr 8, 2014, at 15:42 , Sean McBride  wrote:

> On Tue, 8 Apr 2014 15:24:19 -0700, Rick Mann said:
> 
>> but Core Data doesn't let me have an entity attribute of type id, AFAIK
> 
> Sure you can, that's what 'transformable' attributes are.  Your custom object 
> would need to be able to serialize/deserialize itself via NSCoding to be able 
> to persist itself though.

Oh, maybe you're right; that would work if I just coded up my class's property 
as "id", wouldn't it? Don't know why I thought that wouldn't work. That's what 
I get for working on this project after 10 hours of coding at my day job, I 
guess.



-- 
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: Opinion: Core Data or roll my own?

2014-04-08 Thread Sean McBride
On Tue, 8 Apr 2014 15:24:19 -0700, Rick Mann said:

>but Core Data doesn't let me have an entity attribute of type id, AFAIK

Sure you can, that's what 'transformable' attributes are.  Your custom object 
would need to be able to serialize/deserialize itself via NSCoding to be able 
to persist itself though.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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: Opinion: Core Data or roll my own?

2014-04-08 Thread Rick Mann
Well, one of the issues is the data types. It's a bit clunky, but workable. 
There's one type of entity I want to create, a "Properties" table that maps 
strings to arbitrary value types. This would be trivial if I managed it myself, 
but Core Data doesn't let me have an entity attribute of type id, AFAIK. The 
other problem I'm facing, which is probably due to me misunderstanding 
NSPersistentDocument, is that I want my Library document to always autosave (in 
the sense that it programmatically saves after changes like adding a new Part 
object, rather than presenting the user with a save sheet). I haven't quite 
figured out how to do this. There are the saveToURL: methods, but what URL? It 
was opened from a file, it should know that. I just want to persist changes and 
clear the dirty state. Maybe I'd have the same issues with a "regular" 
NSDocument.

The other thing (I meant to mention in the original email) is that I can't take 
advantage of autosave and async file operations, etc.

BUT: Do I lose a lot of undo support? I've never tried to implement undo 
without Core Data.

On Apr 8, 2014, at 15:15 , Mike Manzano  wrote:

> Depends. Why are you “fighting” Core Data?
> 
> Mike
> 
> 
> 
> On Apr 8, 2014, 3:13:12 PM, Rick Mann  wrote:
> This may prove to be an unproductive question to pose, so I apologize in 
> advance. 
> 
> I'm generally a big fan of Core Data, but I'm developing a moderately 
> complicated CAD app with libraries and design documents and such, and 
> beginning to wonder if it would be easier to do if I weren't fighting Core 
> Data. I'm wondering what the tradeoffs might be. 
> 
> If I were to dump Core Data, I'd keep the entire object graph in memory all 
> the time, writing it out completely each time. I'd probably write XML, or 
> some other text-based format (as much as I abhor text-based formats) because 
> of the ease in diffing changes and using it with source control. 
> 
> As I write this, I realize that I can't just keep a whole document in memory; 
> the library (which would be a collection of separate files on disk, but 
> presented as a unified collection of content in the UI) could be very large 
> and I'd rather not load in the whole thing. Nevertheless, I think that's 
> doable. 
> 
> I'd have to handle relationships myself, but all the data types become easier 
> to manage (I use a lot of C structs, well, really C++ structs). 
> 
> Thoughts? Thanks! 
> 
> -- 
> Rick 
> 
> 
> 
> - signature.asc, 211 bytes
> ___
> 
> 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/mike%40instantvoodoomagic.com
> 
> This email sent to m...@instantvoodoomagic.com


-- 
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: Opinion: Core Data or roll my own?

2014-04-08 Thread Mike Manzano
Depends. Why are you “fighting” Core Data?

Mike  



On Apr 8, 2014, 3:13:12 PM, Rick Mann  wrote: This may 
prove to be an unproductive question to pose, so I apologize in advance.

I'm generally a big fan of Core Data, but I'm developing a moderately 
complicated CAD app with libraries and design documents and such, and beginning 
to wonder if it would be easier to do if I weren't fighting Core Data. I'm 
wondering what the tradeoffs might be.

If I were to dump Core Data, I'd keep the entire object graph in memory all the 
time, writing it out completely each time. I'd probably write XML, or some 
other text-based format (as much as I abhor text-based formats) because of the 
ease in diffing changes and using it with source control.

As I write this, I realize that I can't just keep a whole document in memory; 
the library (which would be a collection of separate files on disk, but 
presented as a unified collection of content in the UI) could be very large and 
I'd rather not load in the whole thing. Nevertheless, I think that's doable.

I'd have to handle relationships myself, but all the data types become easier 
to manage (I use a lot of C structs, well, really C++ structs).

Thoughts? Thanks!

--
Rick



- signature.asc, 211 bytes ___

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/mike%40instantvoodoomagic.com

This email sent to m...@instantvoodoomagic.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

Opinion: Core Data or roll my own?

2014-04-08 Thread Rick Mann
This may prove to be an unproductive question to pose, so I apologize in 
advance.

I'm generally a big fan of Core Data, but I'm developing a moderately 
complicated CAD app with libraries and design documents and such, and beginning 
to wonder if it would be easier to do if I weren't fighting Core Data. I'm 
wondering what the tradeoffs might be.

If I were to dump Core Data, I'd keep the entire object graph in memory all the 
time, writing it out completely each time. I'd probably write XML, or some 
other text-based format (as much as I abhor text-based formats) because of the 
ease in diffing changes and using it with source control.

As I write this, I realize that I can't just keep a whole document in memory; 
the library (which would be a collection of separate files on disk, but 
presented as a unified collection of content in the UI) could be very large and 
I'd rather not load in the whole thing. Nevertheless, I think that's doable.

I'd have to handle relationships myself, but all the data types become easier 
to manage (I use a lot of C structs, well, really C++ structs).

Thoughts? Thanks!

-- 
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: Custom UITableViewCell parent is NIL

2014-04-08 Thread Michael de Haan

On Apr 8, 2014, at 6:16 AM, Steve Christensen  wrote:

> On Apr 7, 2014, at 9:32 PM, Michael de Haan  wrote:
> 
>> It still however leaves me puzzled as to why I cannot implement Swipe to 
>> delete. (the 2 usual suspects), ie 
>> 
>> -(BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath 
>> *)indexPath;
>> -(void)tableView:(UITableView *)tableView 
>> commitEditingStyle:(UITableViewCellEditingStyle)editingStyle 
>> forRowAtIndexPath:(NSIndexPath *)indexPath
>> 
>> are implemented.
> 
> I realize that this will come across as a “is it plugged in?” sort of 
> question, but have you put a breakpoint, or added a NSLog(), to each of those 
> methods to see if they’re actually being called? And if 
> -tableView:canEditRowAtIndexPath: is being called, are there any cases where 
> you return NO?



Turns out that the issue seems to revolve around the property of the  
UITableView  "allowsMultipleSelectionDuringEditing", which has to be "NO" for 
swipe-to-Delete and "YES" for batch deletions, each being exclusive of the 
other.

So, in the end, I set the appropriate value (YES) in the edit mode for batch 
deletions, then back to the baseline value ("NO") for swipe-to-delete.

Thank you all again.
___

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

Excessive open gui graphics files on Mavericks

2014-04-08 Thread Michael Domino
Hi all,

Some of my customers running on Mavericks are having problems with "too many 
open files" errors. Raising the limit does solve the problem, but I've noticed 
that on 10.6, at idle, my app opens about 47 files, none of them gui graphics 
files. On Mavericks, the very same build of the app opens 102 files and keeps 
them open for the duration of the process existence. The difference is the 
graphics files used by the gui. There are no .png files opened on 10.6 while 
the app is at idle, but on Mavericks we have all of these taking up file 
descriptors (partial lsof output below). I don't directly open any of these 
files, and the only visible icons at the time are the 15 main toolbar buttons.

So is there a way to change this behavior and close these files? This product 
is currently built using Xcode 3.2.6. Would upgrading to the latest Xcode have 
any effect?

Thanks,
Michael

lsof output:

COMMAND   PIDUSER   FD TYPE DEVICE  SIZE/OFFNODE NAME
Identity  275 michael  txt  REG1,1   546 2633476 
/Applications/Identity Finder.app/Contents/Resources/status_ssn.png
Identity  275 michael  txt  REG1,1   433 2633454 
/Applications/Identity Finder.app/Contents/Resources/status_credit-card.png
Identity  275 michael  txt  REG1,1   593 2633472 
/Applications/Identity Finder.app/Contents/Resources/status_password.png
Identity  275 michael  txt  REG1,1   577 2633450 
/Applications/Identity Finder.app/Contents/Resources/status_bank-acct.png
Identity  275 michael  txt  REG1,1   545 2633458 
/Applications/Identity Finder.app/Contents/Resources/status_drivers-license.png
Identity  275 michael  txt  REG1,1   537 2633452 
/Applications/Identity Finder.app/Contents/Resources/status_birthdate.png
...and many more...


___

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: To find if a file is fragmented

2014-04-08 Thread Ed Wynne
The information may be irrelevant and/or useless, but it is available for file 
systems that support it (HFS+ does). Although, I think it may require 
super-user privileges to query.

$ man fcntl
  …
 F_LOG2PHYS Get disk device information.  Currently this 
only includes the disk device address
that corresponds to the current 
file offset.

 F_LOG2PHYS_EXT Variant of F_LOG2PHYS that uses the passed in 
file offset and length.
  ...

-Ed

On Apr 8, 2014, at 11:48 AM, Maxthon Chan  wrote:

> Concerning if a file is fragmented is sort of useless, I think. Modern 
> filesystem APIs does not even expose details of that, and the only way I now 
> how to find out about that, is to roll your own HFS+ driver (or whatever 
> filesystem you are concerning) and access raw bock devices (e.g. /dev/disk0) 
> yourself. If that is the situation you may want to move your project to Linux 
> as there are 3rd party libraries designed to allow you access on that level, 
> with proper kernel support and using existing filesystem drivers, but that is 
> limited to Linux.
> 
> If you are regarding execution speed you should disregard. All your users who 
> is using a Mac that is less than one year old is very likely to be equipped 
> with solid state drive which have no seek time. Not too many Mac users I know 
> still hog onto a three-year-old MacBook Pro with spinning platters now. (I 
> was even mocked by my ex-colleagues that I quit before the company gave 
> everyone MacBook Pros with SSD in them)
> 
> On Apr 8, 2014, at 22:53, Fritz Anderson  wrote:
> 
>> On 8 Apr 2014, at 9:19 AM, Nick Rogers  wrote:
>> 
>>> I just need to know, if a file is fragmented or not. I don’t need the frags 
>>> details etc.
>>> Its for showing extended info about the selected file, like whether it is 
>>> fragmented or not.
>>> 
>>> Is it possible with out raw reading the volume (for its catalog file)?
>>> 
>>> I have also seen Carbon File Manager’s FSGetCatalogInfo() and fstat() and 
>>> they don’t return this info.
>> 
>> I agree that it’s an implementation detail of the filesystem, and in any 
>> event not a matter for a Cocoa discussion list.
>> 
>> In a modern file system, physical storage of files is either meaningless, or 
>> always (three-nines) fragmented, barring first write on a virgin disk.
>> 
>>  — F
>> 
>> 
>> ___
>> 
>> 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/xcvista%40me.com
>> 
>> This email sent to xcvi...@me.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/arwyn%40phasic.com
> 
> This email sent to ar...@phasic.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: To find if a file is fragmented

2014-04-08 Thread Maxthon Chan
Concerning if a file is fragmented is sort of useless, I think. Modern 
filesystem APIs does not even expose details of that, and the only way I now 
how to find out about that, is to roll your own HFS+ driver (or whatever 
filesystem you are concerning) and access raw bock devices (e.g. /dev/disk0) 
yourself. If that is the situation you may want to move your project to Linux 
as there are 3rd party libraries designed to allow you access on that level, 
with proper kernel support and using existing filesystem drivers, but that is 
limited to Linux.

If you are regarding execution speed you should disregard. All your users who 
is using a Mac that is less than one year old is very likely to be equipped 
with solid state drive which have no seek time. Not too many Mac users I know 
still hog onto a three-year-old MacBook Pro with spinning platters now. (I was 
even mocked by my ex-colleagues that I quit before the company gave everyone 
MacBook Pros with SSD in them)

On Apr 8, 2014, at 22:53, Fritz Anderson  wrote:

> On 8 Apr 2014, at 9:19 AM, Nick Rogers  wrote:
> 
>> I just need to know, if a file is fragmented or not. I don’t need the frags 
>> details etc.
>> Its for showing extended info about the selected file, like whether it is 
>> fragmented or not.
>> 
>> Is it possible with out raw reading the volume (for its catalog file)?
>> 
>> I have also seen Carbon File Manager’s FSGetCatalogInfo() and fstat() and 
>> they don’t return this info.
> 
> I agree that it’s an implementation detail of the filesystem, and in any 
> event not a matter for a Cocoa discussion list.
> 
> In a modern file system, physical storage of files is either meaningless, or 
> always (three-nines) fragmented, barring first write on a virgin disk.
> 
>   — F
> 
> 
> ___
> 
> 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/xcvista%40me.com
> 
> This email sent to xcvi...@me.com



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: To find if a file is fragmented

2014-04-08 Thread Fritz Anderson
On 8 Apr 2014, at 9:19 AM, Nick Rogers  wrote:

> I just need to know, if a file is fragmented or not. I don’t need the frags 
> details etc.
> Its for showing extended info about the selected file, like whether it is 
> fragmented or not.
> 
> Is it possible with out raw reading the volume (for its catalog file)?
> 
> I have also seen Carbon File Manager’s FSGetCatalogInfo() and fstat() and 
> they don’t return this info.

I agree that it’s an implementation detail of the filesystem, and in any event 
not a matter for a Cocoa discussion list.

In a modern file system, physical storage of files is either meaningless, or 
always (three-nines) fragmented, barring first write on a virgin disk.

— F


___

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: To find if a file is fragmented

2014-04-08 Thread Jens Alfke

On Apr 8, 2014, at 7:19 AM, Nick Rogers  wrote:

> I just need to know, if a file is fragmented or not. I don’t need the frags 
> details etc.
> Its for showing extended info about the selected file, like whether it is 
> fragmented or not.

That’s a weird idea IMHO — it seems like a much lower-level detail than what 
the file system’s APIs would expose, or what a user would care about. And what 
does “fragmented” mean exactly? Is a file fragmented if even one of its sectors 
is not exactly contiguous with the others? Does this even matter on SSDs, where 
seek time is a non-issue?

I’ve never heard of any API for this and I’d be very surprised if there were 
one, since this info really only matters to the filesystem itself and perhaps 
some specialized filesystem tools like fsck.

In any case, this is way outside scope for Cocoa-dev. I suggest you check 
whether there’s an Apple list that’s focused on filesystems.

—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

To find if a file is fragmented

2014-04-08 Thread Nick Rogers
Hi,

I just need to know, if a file is fragmented or not. I don’t need the frags 
details etc.
Its for showing extended info about the selected file, like whether it is 
fragmented or not.

Is it possible with out raw reading the volume (for its catalog file)?

I have also seen Carbon File Manager’s FSGetCatalogInfo() and fstat() and they 
don’t return this info.

Any help would be greatly appreciated.

Best,
Nick


___

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: Custom UITableViewCell parent is NIL

2014-04-08 Thread Steve Christensen
On Apr 7, 2014, at 9:32 PM, Michael de Haan  wrote:

> It still however leaves me puzzled as to why I cannot implement Swipe to 
> delete. (the 2 usual suspects), ie 
> 
> -(BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath 
> *)indexPath;
> -(void)tableView:(UITableView *)tableView 
> commitEditingStyle:(UITableViewCellEditingStyle)editingStyle 
> forRowAtIndexPath:(NSIndexPath *)indexPath
> 
> are implemented.

I realize that this will come across as a “is it plugged in?” sort of question, 
but have you put a breakpoint, or added a NSLog(), to each of those methods to 
see if they’re actually being called? And if -tableView:canEditRowAtIndexPath: 
is being called, are there any cases where you return NO?


___

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