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. Als
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
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
> 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 parse
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
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
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 si
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 f
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.
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:
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
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 examp
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 wil
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 usin
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
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
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 relea
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
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 seriali
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 itse
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
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 desig
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 Cor
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
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 o
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
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
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 it
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-le
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’
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 *)
31 matches
Mail list logo
