The game never saw the light of day actually, and we was on the way
reimplementing libcramfs in BSD license.
On Apr 11, 2014, at 22:56, Fritz Anderson wrote:
> (The attribution chain is wrong, because I’m coming to this after the message
> that raised libcramfs.)
>
> It’s remarkably hard to g
(The attribution chain is wrong, because I’m coming to this after the message
that raised libcramfs.)
It’s remarkably hard to get an answer to this, so I may be talking through my
hat:
Does this involve linking libcramfs.a into the binary you distribute? Have you
published the source of your a
when all you have is a rocket launcher, every problem looks like rocket bait.
--
On 9 Apr, 2014, at 0:52, Maxthon Chan wrote:
> 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
> e
On Apr 8, 2014, at 10:32 PM, John Joyce
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
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 equival
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 bi
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 wrote:
> On Apr 9, 2014, at 2:20 AM, M
On Apr 9, 2014, at 2:20 AM, Maxthon Chan 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
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 wrote:
> 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 /
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 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 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
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
19 matches
Mail list logo
