Ok - what’s the .codea file? not a zip. The unix ‘file’ command just says ‘data’. I can see the plaintext of the files in there. But - not a tarball, either.
IS A PUZZLEMENT!
Can we document the format? Forget email - I’ll make a perl script to pack things up and (I’m told) we can just open them from Safari. That’s not ideal for code sharing, but it’s like 90% of the way there, ya know?
There’s a part of me that wants to reverse-engineer it - and a bigger part that’s fat, old, and lazy. 
It’s an NSFileWrapper serialized to an NSData object. It should be trivial to write a Mac OS X app to unpack it, other platforms would require some thought.
(The NSFileWrapper is constructed as a directory wrapper over the project’s directory)
Ewww. That’s not pretty. Generally, nobody documents serialization specs… Ok, I’ll put on my reverse-engineers hat… (I like OS X, but I don’t want to be tied to OS X…)
It would be great if it could be created automatically on other platforms with a command line app so at one could, for example, build a .codea file on Linux from a Git repo and publish to a website.
Could be sticking our heads above the parapet a bit though, w.r.t. Apple’s app-store rules.
You had me worried that the filesystem storage method had changed!
Yes, figuring out the format would be nice. It doesn’t look all that complicated on first sight since, as Bortels says, the actual files are plain.
I managed to get a directory, and I expect with a bit more effort I could hackishly make an extractor, in a very dirty ugly manner.
But - I couldn’t re-pack them, and that’s what I want.
The format, fwiw, appears to be “rtfd”, a Rich-Text-Format directory, developed to allow RTF stuff with attachments; so far as I can tell, except for NeXT and OS X, the format is abandoned in the rest of the world, and I can’t find a good resource talking about the format of the data file. Still looking.
GNUstep has the same API but I believe the serialisation is different.
Cocotron? Yep, Cocotron has that class. No idea if it uses the same format, but Cocotron aims to be 100% Mac OS X API compatible.
Interesting, will have to have a play with Cocotron.
I’ve looked at Cocotron and it does not implement initWithSerializedRepresentation for NSFileWrapper, so it probably won’t help.
Wikipedia says the following:
RTFD files can be "opened" on Windows using WinZip 8.1 as well as WinRar 3.7.1
Can anyone using Windows try this on a .codea file and let me know if it works?
I can now successfully decode the entire .codea file, for some definition of “successfully decode” - there’s some “Junk DNA” in there that I don’t understand, but which appears to be irrelevant to the content we’re interested in (it may be version numbers, or indexing, or directory information - or who knows). I’ll share the code once I remove some of the debugging cruft littering it.
Making a .codea file from scratch may (or may not) be a much bigger chore.
That was fast, Bortels! I like your comments.
I’m thinking about simply transitioning the Codea format to a standard zip format in the future – especially when custom sprite packs are finished. It would retain the .codea extension but be a simple zip file. More cross platform friendly.
That would be much more pleasant. I really like the new ability to load in a program from Safari without cut-and-paste, but having the raw code available without having to go via Codea is also nice since then one can just look “How did X do that?”. So making it easy to back and forth without the iPad will be useful.
Agreed - some standard format (zip is probably it) would go a long way. Being able to tear apart a Codea archive, manipulate things, and build new ones on the fly in a nice cross-platform manner would be tremendously powerful.
While I’m at it - when you import a Codea archive, it would be nice if you were given the option to Merge or Replace when the name is the same - it would be handy, for example, to be able to grab a Font (or controllers, or whatever) archive, and simply have it merge into an existing project. Library management, good library management, is a problem to solve early rather than wait too long…
True, I’m going to be adding the tagging system for projects first, though. Then I’ll look at a replace option (merge is probably too complex and time consuming to tackle).
Even a tab-wise merge would suffice - I’m not looking for code-merging so much as an easy way to add a library. If i can publish a “Font.codea” that contains a single class file (no main.lua - hmm, I wonder if i can delete the main() tab) - and it merged in tabs that don’t exist (and perhaps gave an option to rename tabs that did), then adding a library to a project would be as easy as clicking on a URL.
This may have been mentioned before…
Is the following ability acceptable and need added to the tracker…
Ability to copy “tabs” from one project to another. User holds down a “tab” (where delete and rename appears today) a newoption to “copy to” is available. Some type of project list is displayed with the ability to select multiple projects. Naming conflicts receive auto renaming. Maybe an overwrite option. Maybe a list option that reduces the list to only projects that have a similar named “tab”.
@Ipda41001 my plan is to do this the opposite way: press the plus button in a project, and you can select a file from a different project.