- Code:
- Main.lua: http://pastebin.com/Urt5Chfb
- Person.lua: http://pastebin.com/hF5pBkn2
- Ship: http://pastebin.com/a9MfGDXe
- StreamingLines: http://pastebin.com/mcGtwdkw
Likes
Thanks for sharing. Will have to try it out soon.
Wish I could download code in the app.
I think this copy-and-paste code from pastebin or github can be done automatically by the app. Say an input to enter code URL, then Codea parse the page and take only the needed source code, then put it into a new file within a project. Will Apple reject such kind of feature?
Interesting point. I think Dylan was looking at doing something like that. I wonder if they would.
Gist actually has a HTTP API we can use, so I will probably implement it at some point. No guarantees it will get past Apple though.
The point is that hackers could use Codea to have access to “root privileges” throught an exploit, using code inside a lua program…isnt it?
Yes, you could set up sharing with a project containing some kind of exploit, and use it to jailbreak/infect/whatever. But you can do that now by copying + pasting the code in. They could block that too, but you could still type it out by hand.
Really, so long as code can’t be remotely sent and executed on the device, there’s no difference between the editor and sharing other than convenience.
Nope - the issue for apple isn’t hackers, in this case. (let’s not call them hackers - the “bad guys” who might write things attacking codea are sandboxes the same way we are - it is a very unlikely attack vector)
What apple is concerned about is having an app that in the end provides a viable replacement for the app store and their approval process (and/or that would allow flash in via a back door). They had a prohibition against interpreted code for a long time, largely unenforcable because in the end that’s how a lot of programs work. Now it’s against downloading interpreted code, but as we can see, cut-and-paste is apparently ok. Will a URL fetch be ok as well? A one-button fetch? Programmatic? At some point they may balk ( indeed, probably will!) - but it does seem they are loosening restrictions over time.
In the end, they already allow all of this in mobile safari with JavaScript, so it seems to me their restrictions are arbitrary and futile in the long run - once people are used to “use the app store to get programs” restricting our sort of shenanigans ends up counterproductive. But apple changes at their own pace.
Bortels is right. They fear an alternative appstore, but they can’t to anything to html5. So they lost the War anyway.
Hold on, alternative store? We’re just talking about sharing free programs for codea, not selling apps or anything. I can’t see any major issue there, what’s the difference between that and say a game that lets you share user generated levels?
Heh - it’s not what we plan, but it is one of the things Apple fears. Not just for the potential lost revenue, but for the possible disruption of the “walled garden”. Apple wants very much (and I support this wish) to have a place that your average joe can go drop a buck on a game an not have to worry about a virus or malware. That’s why they have such a tight review process (and it’s actually a lot looser now than it was in the past in many ways).
Codea gets around a ton of this by being sandboxed - we don’t have direct access to the Objective-C APIs that Codea calls. We ask Codea to draw a circle, and Codea asks the OS to do it. There are multiple layers that prevent our lua code from doing bad things (say, scraping someone’s address book and uploading it to a server). These protections are why Apple has approved Codea to begin with. Now, there’s a tug-of-war between us (who want Codea to let us do more things) and Apple (who have a vested interest in having apps do only the things necessary). I think we’ll “win” in the long run - but for the short term, we have to play games with how we can get code on the system, and that’s the price we pay for having Codea in the Apple store running on an out-of-the-box ipad. You could get around it all by jailbreaking - but then you only can play on jailbroken ipads, and frankly that’s a miniscule userbase, comparatively.
Why would Apple care about user-generated levels? Witness the following semi-NSFW Penny Arcade comic: http://www.penny-arcade.com/comic/2008/10/08
Apple doesn’t want to have to explain to a parent why little Joey is having his mind warped by… “inappropriate” user content in apps they got in the mostly-squeaky-clean App Store. It would be bad press, and bad for business. And - to be blunt - when Apple has to choose between Developers and almost anything else - Developers lose.
I think there is a tacit understanding between developers and Apple for certain types of apps. Apple’s stance seems to be: don’t make it obvious that your app shares code, and we’ll let you do it.
Our hope is to slowly include more and more sharing-type features over time.
The goal of Codea has always been to play with ideas. I think we can do that without bending Apple’s rules much, if at all.
Good to hear - I expect that the longer Codea exists without the world coming to an end, the looser Apple will get.
@SiENcE
… So they lost the War anyway …
This reminds me of the story of the ant that declared war on an elephant. The elephant didn’t notice. 
Thanks everyone for commenting , this is the very real power of community o-+ :-c
In case anyone wants to check this out easily, here’s a zip of it, including a fix to a no longer supported language feature (table.maxn).
It’s a flashback to long ago…
This looks great! It seems to work well so I’ll add this to WebRepo later.
@juaxix Now available from Codea Community Repository and available for download using WebRepo.