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