Very nice site.
Bortels, what does it do with the data file btw? Just ignores them? How about having data.plist in the zip file at least? (sorry about that i havent played with it yet, still hanging on to 1.2.5 until i export everything)
Right now, it just ignores them - there’s no way to add them in to Codea by hand, so there’s not much we can do with it.
Hmm - that’ll be where the private project persistent data is located, isn’t it. That binds things a bit.
I can put it into the .zip file that’s also created, or simply add it to the files displayed - but without a way to get it into the project on the ipad - not much use.
Let me ponder…
I guess I could make a “data loader” that populates persistent data, and have it take the relevant content from Info.plist and load it - to make proper use of it, the project author would basically have to check if their content was in persistent storage, then call “reload_plist()” or such if it isn’t nil. Does that make sense?
Yes - this is fixable, perhaps.
I was thinking i’d use the zip file to upload to the ipad with iexplorer
You idea is interesting too, afterall the current storage is all text.
Well - I can certainly expose the plist file - I’ll do that shortly. Yes - that will help those not doing copy and paste.
And… done. The Info.plist shows up in the zip, as well as visible in the html if someone wants it.
And I think I have a cunning plan. I… nope, it won’t work.
@Simeon, we need to be able to create tabs programatically. Please. Pretty Please.
(If it’s not obvious, the idea is to make a “loader” that has all of the tabs, plus the persistent data, in it - copy/paste the single loader in, run it, it creates all of the other tabs, populates the persistent data, then… hmm, how could it replace itself… more pondering to do…)
-- pseudo-code for the win
loader=true
loader-Main = "the Main tab, encoded (prolly base 64)"
loader-Other = "A tab named Other, same deal"
loader-Whatever = "Whatever tab..."
function setup()
if loader then
-- we make the tab, decode "loader-tabname to it"
end
-- now swap out the original main tab (yes, this could be weird)
renametab("Main", "loader")
renametab("Main-new", "Main")
removetab("loader")
end
Just thinking out loud. Apple can prevent you from importing code, but they can’t prevent you from doing things that make it easier for us. 
Interesting thought. Might as well allow programmatic creation of projects, too. I’ll look at how we can do it.
That would be even better - you just grab and cut and paste, and the temporary project you just did recreates the whole project.
Heck - I can see uses for that aside from restoring projects…
Um… I like the idea, but it could crash the iPad and fill up Codea’s catch if it was put in a loop. Just my though.
Nah - only if the loader got too big, and even then it should only make you need to restart codea. Plus, Simeon and crew are looking at the big file issues.
What if we set up like the file server (on apps like file app, quickoffice, etc) that transfers wirelessly over an http://(ip address here)? It would allow for easy transfer to commuters for projects and maybe be a loophole, for we would be downloading the projects to our computer an not the iPad itself. Though we would still be executing them there…
Apple isn’t going to allow us to directly put code onto the ipad for Codea, not unless appeals work, not without actually using paste, and I’m surprised they allow that. None of the other tricky ways to get code there are likely to be approved.
Point being, we have the appeals process, or we have to learn to live with copy/paste, and then work around the issue. And - work around we can. It’s just ugly, and stupid.
Update: I am now also copying over the uploaded .codea file to the results directory for reference. So - it’s a bit of a one-stop shop for grabbing .codea packages too, which is nice.
Code Authors: I’d recommend, in addition to what you’re already doing, you make a nice versioned copy of your .codea file, and upload it. Inside the main, as the first chunk, I’d suggest putting your name, home website if any, and any licensing you want to include. If you keep it to a nice 7ish lines, it should display nicely in the top of the file copy box.
If someone wants it, I’m happy to search uploaded codea files for some special tag that means “please don’t put this up or allow it to be decoded, bortels, you busybody!”, and remove those from processing… I suggest a single line with “-- NO DISTRIBUTION”. Reasonable?
I am also thinking it might be wise to simply reject uploads that are already there, to prevent vandalism. Not that I think we’ll see it, but this is a case where someone can upload stuff at will - better to prevent it now than correct it later. I’m not too worried about spammers, because they’d have to figure out how to export a valid .codea file, but meh.
I’ve taken the liberty to grab and decode some of the projects I’ve been using and admire, mainly to confirm there aren’t more bugs lurking in my decoder. So - some of you may see your projects already there. I’d really like to see the others that have been posted here, if only to confirm they decode ok as well.
FWIW - turns out there’s a Data.plist with the local persistent data. The problem of how to get that data into a cut-and-pasteable form remains. Or rather - it’s easy to find, and select - and there’s no good way to paste it in because we don’t have editor access to the .plist files.
TLL - maybe that’s the easy solution. Just let us edit Data.plist as well as the lua files. Yes, it’s XML and it’s ugly, but it’s not that bad. And it’d be easy to fix issues - just kill the tab.
Just looked at my ones. A couple of things strike me:
- The script should ignore files that aren’t
.plistor.lua. I see a few.lua~in my projects that I’d not realised where there. There’s no real danger in having these in there as Codea just ignores them, but a user who didn’t know that might go to the bother of trying to cut-and-paste them without realising that they shouldn’t (or couldn’t). - As I’ve upgraded, I can no longer generate the
.codeafiles. In particular, I can’t go back and insert any key fields such as author or original url. I’m not so bothered about the attribution, but I do update my projects from time to time so it would have been useful to have a “Get the most up to date version from …”. I know that you’ve just used these to test the idea, but if you are going to harvest.codeafiles en masse (which is absolutely fine by me as far as mine are concerned) then a link to where you got it from would be nice.
-
ok - I’ll have to swap the logic a bit, the script currently does “all but…” and I’ll need to make it do “none but…”. No worries.
-
That’s cool - but the “where I got it from” is “somebody uploaded it” - I don’t force people to provide a source, they may not know. So - how do we let authors who have upgraded and can’t make .codea files update? Nasty question - there’s a lot of “junk dna” in the .codea files, I can’t make one, without just using the ipad and Codea. Let me ponder this today - we’ll either find a way for non-.codea-generating authors to make a .codea file (probably by uploading a .zip of the project), or… dunno. Something. I mean - aside from this, if you update your projects in general, you still have a stale .codea file on your site, right? I was hoping to avoid making them, but we may have no choice.
I’m not clear as to your goals for this project. Is it to host all (publicly available) Codea code? Or is it just as a way for people who have upgraded to import .codea files? If the latter, then there’s no reason for making new codea files for you to extract the data again from! Yes, I have stale codea files on my site but as I update projects then I’ll delete them because the project will be the newer one. Or I might say “If you haven’t upgraded to 1.2.7 then you can get an old version as a .codea file”.
Incidentally, I’d be more than happy for someone to have a central place where we can get codea code from. I’ll continue hosting my stuff on my website, but I’ve no issues with someone harvesting them. As I say there, anything that originated with me is in the public domain (or CC0). It’s just that to be as useful as possible, it’s good to have links back to my website from my code so that people know where to get the latest version (should they want to! I’m under no illusions as to the popularity of my code).
The goal is to have a way for a user to get to .codea file contents without having to install something local (like perl). A web interface does that.
An immediate sub-goal was to throw a bunch of .codea projects at it, to make sure they all decode properly, to vette my decoder; there is no better proof of correctness than to confirm it’s actually working on as many known files as I can find. (If I had a good spec for the file format, yes, I could do unit testing and be more sure - but I don’t.)
I am also of the belief that there will be more than a few people who refuse to downgrade to 1.2.7 and lose the ability to import .codea files - So it’s nice to have new, fresh .codea files around for those users as well. (Ha! Won’t downgrade??? Well, too bad - you get to cut and paste anyway if you want the latest stuff…) It would be awesome to be able to upload a .zip file, and have it made available in the same manner, including as a one-click install .codea file for those who have yet to downgrade.
This assumes, of course, that it can even work - if you use a 1.2.7 feature, it would break even if imported as a .codea file. Caveat etc etc.
The Uber-goal is to demonstrate in a concrete manner that Apple removing code import via .codea files doesn’t actually accomplish their “no importing code” goal; it simply makes the user experience suck more, and the blame for that is solely at their feet. I hope that at some point someone there raises their head out of the sand and says “Uh, guys - Gruber is saying we suck. On the Internet. No, really - Gruber. Yes, that Gruber. I know he likes our stuff - maybe we’re doing the wrong thing here after all?”
I can dream.
PS. My intent is to take the whole site, once I’m sure it’s mainly stable, make a nice zip file, and make it available for anyone who wants it, so the whole world isn’t dependent on my home DSL. It depends on apache, php, and perl - all of which are stock on any ubuntu installation. It could be made to run with little difficulty on other platforms, including cloud (it’s got options for google’s cloud). I’ll probably post it later today, barring fires.
The decoder will now only include .lua and .plist files, so people going directly to the directory via various means won’t have their .git and .lua~ and so on included in the output here.
The last line in the FAQ on the decodea site has a link to a copy of the entire site. It’s less than 400k, including all of the .codea files I’ve put in so far. Just for the record. If you grab it and see a giant security hole staring me in the face - let me know.
Hail Eris… Nice