Re: Excessive open gui graphics files on Mavericks
On Apr 9, 2014, at 12:32 AM, John Joyce dangerwillrobinsondan...@gmail.com 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
I’d recommend cramfs as it is a real filesystem that is optimised to be expanded in-memory. On Apr 9, 2014, at 14:42, Charles Srstka cocoa...@charlessoft.com wrote: On Apr 9, 2014, at 12:32 AM, John Joyce dangerwillrobinsondan...@gmail.com 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 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 9, 2014, at 2:20 AM, Maxthon Chan xcvi...@me.com wrote: I’d recommend cramfs as it is a real filesystem that is optimised to be expanded in-memory. Not complicated enough. I'd recommend encrypting the whole thing with an AES-256 key which is encrypted using elliptical-curve cryptography, and stuff it into a disk image (NDIF, ADC compression) and compress that using zlib, LZMA, and the old PKZIP Implode algorithm. Then, encode the resulting bytes by finding the first offset at which each digit occurs in the decimal representation of pi, then encode the octal representation of those numbers in EBCDIC format, then compress it again and encode the resulting bytes as offsets into an Ogg Vorbis recording of the soundtrack to Star Trek V: The Final Frontier. Because why the hell not? 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
LOL I actually used cramfs once in a game carried the rules database. The rules are so complicated so I tried to make it smaller without sacrificing the efficiency of the game code. Ended up using cramfs for that. On Apr 9, 2014, at 15:49, Charles Srstka cocoa...@charlessoft.com wrote: On Apr 9, 2014, at 2:20 AM, Maxthon Chan xcvi...@me.com wrote: I’d recommend cramfs as it is a real filesystem that is optimised to be expanded in-memory. Not complicated enough. I'd recommend encrypting the whole thing with an AES-256 key which is encrypted using elliptical-curve cryptography, and stuff it into a disk image (NDIF, ADC compression) and compress that using zlib, LZMA, and the old PKZIP Implode algorithm. Then, encode the resulting bytes by finding the first offset at which each digit occurs in the decimal representation of pi, then encode the octal representation of those numbers in EBCDIC format, then compress it again and encode the resulting bytes as offsets into an Ogg Vorbis recording of the soundtrack to Star Trek V: The Final Frontier. Because why the hell not? Charles 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 09 Apr 2014, at 07:22, dangerwillrobinsondan...@gmail.com wrote: Base64 encode images into one file. It could even be an SQLite db file. I’d recommend against base64-encoding possibly large binary data like image files. base64 makes it balloon in size. It’s fine for storing small binary bits like bookmark data (i.e. aliases) or NSDates in an Info.plist or XML file, but if there are enough images to cause running out of file descriptors, they are enough images that the overhead of base64-decoding will be relevant. I worked on a project where we used to store a (comparatively small, ~700x500 pixels) preview of a JPEG file in a plist file as NSData. Even then we realized that decoding of this data was a big bottleneck for load times when showing a list of all these previews. We eventually switched to a separate image file and had a large benefit. Later when the previews needed to become larger, this saved our bacon. Given most common image formats these days are compressed already, anything beyond a tarball probably hurts more than it helps. Now admittedly, we also gained the ability to not have to load the image file just because we needed some other key from the plist, but just moving the data from a hard disk over the bus can be a bottleneck, not even mentioning having to process each byte (and thus copying it again). Especially since that’s just to get the raw JPEG data, which is then decompressed and thus “copied” again. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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
cramps features decompression in-memory in place and to avoid copying data you can put uncompressed TIFF in it. cramfs decompresses into NSData objects in-place and can be taken up directly by NSImage/UIImage/CGImage/CIImage object. cramfs variant that is based on zlib makes that image a equivalent of PNG format. On Apr 9, 2014, at 17:29, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 09 Apr 2014, at 07:22, dangerwillrobinsondan...@gmail.com wrote: Base64 encode images into one file. It could even be an SQLite db file. I’d recommend against base64-encoding possibly large binary data like image files. base64 makes it balloon in size. It’s fine for storing small binary bits like bookmark data (i.e. aliases) or NSDates in an Info.plist or XML file, but if there are enough images to cause running out of file descriptors, they are enough images that the overhead of base64-decoding will be relevant. I worked on a project where we used to store a (comparatively small, ~700x500 pixels) preview of a JPEG file in a plist file as NSData. Even then we realized that decoding of this data was a big bottleneck for load times when showing a list of all these previews. We eventually switched to a separate image file and had a large benefit. Later when the previews needed to become larger, this saved our bacon. Given most common image formats these days are compressed already, anything beyond a tarball probably hurts more than it helps. Now admittedly, we also gained the ability to not have to load the image file just because we needed some other key from the plist, but just moving the data from a hard disk over the bus can be a bottleneck, not even mentioning having to process each byte (and thus copying it again). Especially since that’s just to get the raw JPEG data, which is then decompressed and thus “copied” again. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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
Memoryleak in SpriteKit?
Hi,
in trying to find the source of a memory leak I think to have in my project, I
ended up creating a plain SpriteKit project from template and did the following:
- (IBAction)test:(id)sender
{
if (self.skView.scene.children.count0){
[self.skView.scene removeAllChildren];
} else {
for (int i=0;i2000;i++){
[self.skView.scene addChild:[SKNode node]];
}
}
}
This code is bound to a menu item method test. When looking at memory in Xcode
I would expect for it before adding any children to be identical to after
removing all children. But memory steadily increases. Is there something wrong
with my assumption or is there a leak in SpriteKit?
Thx
___
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 10:07 PM, Rick Mann rm...@latencyzero.com wrote: 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. You can always write some code to export the database to XML for such purposes. But for regular storage, SQLite, or even a binary-format flat file, is going to be a lot more efficient than XML. (Assuming you have a large data set.) —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 10:32 PM, John Joyce dangerwillrobinsondan...@gmail.com wrote: 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. I’m scratching my head trying to figure out whether this is satire or not (some of the replies obviously are.) Actually I kind of suspect this is the exact packaging used for Adobe apps: it would explain their immense size and lengthy installation procedures. —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: Memoryleak in SpriteKit?
On Apr 9, 2014, at 3:45 AM, Alexander Reichstadt l...@mac.com wrote: This code is bound to a menu item method test. When looking at memory in Xcode I would expect for it before adding any children to be identical to after removing all children. But memory steadily increases. Try using Instruments, since it has tools for actually measuring and tracking down memory leaks. For quickie checks, the ‘leaks’ tool is useful too. Frankly, I don’t even know what that memory-usage graph in Xcode’s debugger pane is showing. I’ve found that “memory usage” is a slippery concept in a modern OS, and unless you know exactly what you’re looking at, it’s easy to draw the wrong conclusions. (Obvious example: people looking at VMSIZE and thinking their app is using a gigabyte of RAM.) —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: Bindings for dynamically populated menu
On Mon, 7 Apr 2014 07:01:19 -0700, Jerry Krinock said: Cocoa Bindings are useful to magically keep visible user interface elements in sync with data, although the magic comes with some pain, sometimes quite considerable. But menus only appear when the user clicks on them and disappear when the mouse goes up. Therefore it is natural to update menus, with menuNeedsUpdate:, when clicked, and there is no need to update them when they are not visible. Conclusion: Using Cocoa Bindings on menus is all pain for no gain. A menu's selection is always visible, and I've found bindings on popup menus can be useful to deal with the selection. If the object represented by the popup's selection is deleted (by some other piece of UI) then the popup's selection can be updated automagically with bindings. But certainly the minute you want separators or other dynamic content, binding become less useful. 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: Memoryleak in SpriteKit?
On 9 Apr 2014, at 9:58 AM, Jens Alfke j...@mooseyard.com wrote: Frankly, I don’t even know what that memory-usage graph in Xcode’s debugger pane is showing. I’ve found that “memory usage” is a slippery concept in a modern OS, and unless you know exactly what you’re looking at, it’s easy to draw the wrong conclusions. (Obvious example: people looking at VMSIZE and thinking their app is using a gigabyte of RAM.) My memory (h’m) is that it’s RPRIV. Not a great measure, but it’s supposed to be lightweight, and anything more accurate is a _lot_ heavier. It’s a canary for runaways, not a precise gauge of ebb-and-flow. — F -- Xcode 5 Start to Finish — not so bad. Gone to press this week. ___ 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
@unionOfObjects and direct KVC in NSArray
Say I have an array of Person object with a name property. Is there a difference between : namesArray = [personsArray valueForKeyPath:@@unionOfObjects.name]; and namesArray = [personsArray valueForKeyPath:@name]; On a small test I can just see that the concrete NSArray class returned are not the same but is there something special ? Frédéric ___ 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 9, 2014, at 07:49 , Jens Alfke j...@mooseyard.com wrote: You can always write some code to export the database to XML for such purposes. But for regular storage, SQLite, or even a binary-format flat file, is going to be a lot more efficient than XML. (Assuming you have a large data set.) Oh, I absolutely agree (which is why in my original post I said I abhor text formats). But for the purposes of source control, it has to be the main file, not some export, that's text. Ideally, my app would have a domain-specific diff tool built-in, allowing for a nice binary file, but that's a lot of work! ;-) -- 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
NSButton/NSBox interaction
I have a dialog which has an NSBox. Inside the NSBox are two (separate, but conceptually linked) sets of radio buttons. These are just NSButtons with radio style---I haven't (at least intentionally) embedded them into an NSMatrix. However, when I select one of the buttons from one set, it resets all others in both sets to off so somehow it's automatically interpreting all the buttons inside the box as a single collection even though that's not my intention. However, I can't see anything in the description of either NSButton or NSBox that seems to cover this behavior so I can override it. Can someone explain what's happening, please? Thanks, Tom Doan Estima ___ 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 4:20 PM, Jens Alfke j...@mooseyard.com wrote: 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. Even if you haven't worked with it before, it'll still probably wind up being more efficient to use it―as long as you're not completely new to Cocoa and your specific use case isn't fighting the framework. I've often seen rolling one's own object graph management and persistence result in gradually redoing all of the work that went into Core Data. Turns out Core Data has the design it does for a reason… -- Chris ___ 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: NSButton/NSBox interaction
On 10 Apr 2014, at 7:06 am, Tom Doan t...@estima.com wrote: have a dialog which has an NSBox. Inside the NSBox are two (separate, but conceptually linked) sets of radio buttons. These are just NSButtons with radio style---I haven't (at least intentionally) embedded them into an NSMatrix. However, when I select one of the buttons from one set, it resets all others in both sets to off so somehow it's automatically interpreting all the buttons inside the box as a single collection even though that's not my intention. However, I can't see anything in the description of either NSButton or NSBox that seems to cover this behavior so I can override it. Can someone explain what's happening, please? I'm not exactly certain of the mechanism, but I think radio buttons interact as a set through the agency of their immediate superview, so if several buttons share it, they are assumed to be part of the same set. So you can embed the separate sets into container views or NSMatrix, and they'll work as you want. You mention NOT putting them into a NSMatrix for some reason - what reason? That's the usual way to set up radios, though it comes with the added restriction that the buttons have to be laid out on a regular grid. But embedding them in a custom view that draws nothing should also work, and that has no such limitation. --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
button cell highlight/state/type
Hi all, Does anyone have a handy guide or pointer to the relevant docs which show all the various meanings of highlight, state, appearance and button type. There are so many combinations, and the class reference doesn't really explain it very well (or at all). Some buttons appear to care about the highlight state, others about the 'state', depending on type and what appearance is in use. All seems a bit arbitrary. I'm creating a custom button cell that has to work in a variety of situations, and so far it's hard to avoid a mix-up between different types due to the conflation of the highlight and the state. --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: button cell highlight/state/type
(Sent from the road) On Apr 9, 2014, at 10:17 PM, Graham Cox graham@bigpond.com wrote: Hi all, Does anyone have a handy guide or pointer to the relevant docs which show all the various meanings of highlight, state, appearance and button type. There are so many combinations, and the class reference doesn't really explain it very well (or at all). Some buttons appear to care about the highlight state, others about the 'state', depending on type and what appearance is in use. All seems a bit arbitrary. Try my button tester: https://github.com/kylesluder/ButtonTester I'm creating a custom button cell that has to work in a variety of situations, and so far it's hard to avoid a mix-up between different types due to the conflation of the highlight and the state. Highlight refers to “mouse is currently depressed.” --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
