So - just starting a new thread to get this in one place:
Synopsis: You can’t import .codea files in some versions of Codea (older ones, or the Apple-crippled one). TLL is working on a real solution via the Apple appeals process, but until then - what do you do?
I have a utility that will unpack a .codea file into it’s files. I posted it in the past, but I’m working on a friendlier version (web based) that requires no shell knowledge and nothing installed on your end. Here’s a sample results page:
Comments? Right now, this is the best general-purpose workaround I have, but if you see ways it can be improved - I’m all ears. There’s going to be an associated file upload place where you can put your .codea files and get this sort of page, bookmarkable, as a response.
I’m also working on a script for jailbreakers where I can simply download a .codea file on the PC, double-click it - and now it’s magically on the iPad (you might have to kill/restart Codea).
Probably worth recording here methods of getting code onto the iPad as well (once it has been decoded from its codea format, if need be).
For linux users, libimobiledevice from git (probably not in any distribution) works just fine and can mount the Codea file directory as read-write. Then files can be copied to and from with impunity. In particular, this method does not require jailbreaking.
If you use windows or a mac, the iExplorer program at http://www.macroplant.com/iexplorer/ is free, and works fairly well, and also doesn’t require jailbreaking. The access is tethered, meaning you need to be plugged into the ipad for it to work. (the libimobiledevice Andrew mentions above is also a tethered solution).
In all cases of moving files (rather than cutting/pasting), you’ll need the contents of the .codea file broken out and local.
Nat, thanks for that. It’s very close to what I do. I spotted a couple of improvements on what I do, and for some reason I don’t have to use sudo so I’ll take a look to see what it is that means that I don’t have to.
(Actually, here’s a first guess. Is your user account in the fuse group?)
But most of all, I want to know what the GrumpyPigs project is!
The next step is upload. Tomorrow (well - later today, it’s 1:30 am here) probably. Good opportunity to update my web upload mojo, there are nicer ways today than the old file uploader dialog box (maybe a drag and drop thingamabob, just for fun).
I’m also going to make a newer decoder available shortly - the final version I’m using on the site itself. It creates both the html pages you can see on the site, but also a .zip version that we can share that should be a bit more friendly for the archaeologists trying to figure out this stuff (probably ME) 20 years from now.
I’m counting on this for a new version of Spritely. I’ve got a pop-up menu for copy vs. rename, a bug fix on the keyboard (didn’t notice until yesterday that if you typed between keys the keyboard was “transparent” and was passing touches on to other elements), and a simple “undo” function that at least allows you to recover when you do an “oops, I didn’t meant to press clear.”
But the code sprawls across enough classes that without projects, it’ll be a pain. Oh, and I guess I’ll need to pull the images that were stored in project data and put them in code, so the code will just get bigger and sloppier.
Man, I hope Apple sees reason on allowing projects to return.
So - two things (both mainly questions aimed at TLL):
@Simeon - you might also simply use the “code is speech” argument. It’s fairly well established, at least in the US, that computer source code, which is what we’re dealing with, is a form of speech - and Apple is a US company. Now - they’re private, so they can restrict what they want in their walled garden - but the .codea files don’t exist in their garden, by definition. What Apple is doing here is preventing their end-users from engaging in free speech among themselves - they are practicing censorship, of a most egregious sort, because they are banning an entire class of communication based on what they think someone might say. (it’s also ineffective - we’ll say it, just elsewhere) This is what China and Syria do, and sadly this is what SOPA is trying to do (if it passes, it will surely be struck down as unconstitutional, but until it’s harmed many…)
There has been some talk about tab folding - is it the case that I could, for example, take the Spritely many-tab source code and just paste it all into a single “Main” tab and expect it to work? If so - I can do that in the .codea extractor, so an end-user should have at most one cut/paste operation to import any project? (I’m ignoring possible file size limits - I wonder how big the cut buffer is…)
Mark, maybe it’s time to get serious about versioning. If you make changes, perhaps you could indicate which files have changed so that we only have to download those ones.
I did start versioning the individual classes with Spritely 0.80 – and updated the versions properly in 0.90… but since then I kind of lost track as I was fiddling here and there.
I think I’m declaring the whole mess 1.0 on the next release, then I’ll try to be good from that point forward.
Not that it’s there now on the latest, but versioning individual classes won’t help much when .codea imports are monolithic. If we kept versioning, than an update merge might make sense.
Something I’d like to see - if line 1 of Main is “-- something” - something is a short description to display below the icon in the main Codea view. And - give us a setContext() way to set the icon, please.
You can go there, upload codea files. They’ll get magically decoded (once per minute), and both a .zip of the archive and a nice html file that’s safari mobile copy/paste friendly will be created. So - if you have 1.2.7 and can’t eat up a tasty .codea file - you can go here for the next best thing, for now.
Will this clobber my bandwidth? Perhaps. But I’ll leave it up for the time being, and we’ll see what happens.
This is a “least common denominator” solution - once it works and seems to be stable for the community, I (and others, no doubt) will begin to work on local .codea importers - idea being, I’m jailbroken, so I should just be able to download a .codea file, double-click on it, and have it magically show up on my ipad.
Apple forcing the removal of .codea import does not actually stop us from importing .codea files - it just makes it inconvenient for everyone, and forces us to work around their rules, making the competion more attractive by comparison. At some point, working around their rules will become the norm for most users - that’ll be interesting. As a general point for Apple to consider, making unenforceable rules is almost always a bad idea.
PS. The page is almost all open source stuff, and the part I wrote I release CC0 - I’ll make an archive of the workings available later on, for anyone who wants to host their own decoder, in case I get crushed under the load. (If you have a codea file you want to decode - check the results page first to see if it isn’t already there!)
