Are there issues with a single large file for a project?

“I’m going to try that argument anyway” - LOL, you’re a brave man. If this is the one that tips the balance, I’ll know the world’s gone mad.

Obfuscation is a whole 'nother kettle of fish. Opaque, in this regard, is one of the criteria that goes with 'executable code" in my mind. If I gave you a random binary and said “go ahead, run this - it’s safe”, there’s no feasable way to check that it’s not a trojan (yes, you could disassemble, and so on - feasable meaning “doable in a reasonable time, all the time” here). But - if I pass you code, especially typical codea code - it’s not unreasonable for you to look at it and discern what it does, and certainly not unreasonable for the community at large to look. You could obfuscate, but that is probably counter-productive in the long run - it screams “beware” to a normal user, and it screams “crack me!” to a bored hack type.

Point being - there’s a transparency to Codea projects that doesn’t exist with a normal “install and execute binary” model. The user explicitly, by choice, grabs the package, sends it to Codea, and chooses to run it - and if any of that doesn’t happen, it doesn’t go. And at any point, anyone can stop the process and inspect.

And as pointed out - the sole difference between grabbing a .codea file and cutting/pasting is ease-of-use; the actual difference in technical effect is zero. It may backfire to point that out, but if they outlaw your cutting and pasting, a ton of other apps (including all of those GLSL guys) are in the same boat. I could SEE the hubbub when they try to add “no cutting and pasting of program code” to the App store rules…

We could treat this as an “in app purchase” thing and just say we are having a (permanent) sale and all dlc is free…

Apple has no problem with TLL doing downloadable code - because all of the code TLL would offer has to be vetted the same way codea proper is.

Apple has problems with your code. Yours. And mine. We might be bad guys out to replace Apple’s app store with our own, or trying to swindle their customers, or write code that Apple has promised someone or other wouldn’t be in the App store (say a tethering app, or simply something that uses too much bandwidth, no really). Apple will willingly prevent us from doing what we want, what might be good for the community or our friends (like “sharing” - not piracy, simply sharing our own code) on the off chance what you want to do is something they don’t like.

Like all Digital Rights Management - and this is a DRM issue, for certain - it’s about control of what end users do with what they bought and paid for, and is for the benefit of Apple and it’s partners (the cell carriers and “content providers”) - not yours or mine. Indeed - the people screwed worst by DRM are the legitimate end users, people doing none of these things - because the bad guys (and a whole bunch of good guys) simply bypass the DRM.

True Story: bought a few “Strawberry Shortcake” DVDs for my daughter some years back - she was (and is) a big fan. There was one, though, that she didnt like - confused, I looked into why. Turns out the beginning of the DVD had an (unskippable) anti-piracy ad, one that showed a robber and guns and a back alley at night - something some idiot thought might discourage a teenager from “stealing that disc” - except Gracie was 3, this was Strawberry Shortcake, and it scared her. Now - daddy saved the day by ripping the disk - bypassing the DRM, of course - and removing the crap at the beginning. Point is - if you have ever downloaded a movie, you’ll be aware that the distributors do exactly the same - pirates are rarely if ever inconvenienced by DRM. I serves to punish only legitimate users.

(pop quiz: do you think this made me buy more strawberry shortcake DVDs? Do you think the anti-piracy ad at the beginning was effective, whatsoever? Compare and contrast the experience of a legitimate DVD buyer with someone who paid nothing and torrented it)

So you can see why I have little patience or appetite for playing Apples little games. Stupid part is, Apple stumbled - accidentally, I might add - on the real solution to piracy; reasonably priced software (including music) easily obtainable from a trusted source. I love the walled garden when it benefits the end user, and most of the time it does - the problem is when an end user is also a developer, Apple feels free to dump on them - and that needs to stop, or they’ll pay in the long run with an exodus of talent and power users. The only reason it hasn’t happened yet is the poor quality of the competition - at some point one of Apple’s competitors will understand, “click”, and the decline of Apple will begin, unless they change their ways. Very Dickens, but there you go.

I wait with anticipation for the Apple competitor - I was hoping for google, but they seem to have brain damage, they think what they want is what real people want - who makes a tablet similar to the iPad, but where the SOLE criteria for inclusion in their walled garden is quality - someone who provides a store customers can trust (the current android store isn’t it) and doesn’t apply silly restrictions on inclusion other than solid, stable, “fair” code (ie no Trojans or “angriest brids 3”) will attract both end users and quality developers. The flip side is that the walled garden can not be the sole means of adding software - allow end users to side load home brew or third party apps with proper warnings. Piracy will Not be an issue when the walled garden apps are reasonably priced, and people like me won’t feel the need to “pwn” the system to do what we reasonably expect to do with our own hardware.

TL;DR - Tom rants at 12:30 am on the iPad about DRM - turns out he’s “against”.

I blame the drugs (I have a bad ear/sinus infection - the meds have knocked me silly, silly enough to type all that on a soft keyboard with one finger.)

Re: your ear/sinus infection…

I hope you feel better soon Tom!

Re: your rant…

(Rage against the machine, while natural and without blame, is not always the best outlet for a surplus of creative energy…)

I hope I feel better soon too. :slight_smile:

Re. the “fight the good fight” thing - I agree. I just wish I had the option. I’d much rather be writing code. My take on this whole thing is that without reasonable code sharing by it’s end-users, Codea is crippled. I like Codea, and I think it’s worth fighting to keep Apple from ruining a good thing. Or, since code sharing is removed, to convince Apple do undo it’s crimes against Codea and it’s end-users.

If it’s any consolation, I wasn’t going to code at midnight :slight_smile:

I had hoped to have my .codea decoder - a more constructive, I hope, use of my time - done by now, but I’ve run into a bug where there are some issues decoding some things (extra “nulls” show up, which breaks the web display - it somehow makes chrome, at least, think it’s unicode, with hilarious but deadly results). I have a quick and dirty workaround, but I want to make sure it won’t break other things. So - I set it aside until I can look at it with an awake and non-groggy mind (ie. tomorrow I hope).

iPad2, 64gb. At 900 lines and more on any certain tab I start to/experience lag tabbing between, or working in any one tab. So just FYI. I would stay around 500ish to be safe… Lots and lots of examples/snips can fit in that space btw :wink:

In the longest files I’ve written (usually fonts) the response gets very slow. With over 2000 lines I had to abandon attempts to use block indent, because it wandered off to never-return land.

Okay, I’ve found an upper limit. Just over 5000 lines. Crashes Codea when I try to view it.

Hmm I’ll start testing with huge files like that. I don’t know if I can make it fast, but hopefully not crash.

This particular file will become obsolete when you get the text rendering stuff out. It’s one of the TeX Gyre fonts at 128pt.

When a Programm is over 500 lines long, my codea doesnt crash, but it does strange things… Things like: when i touch the enter button, it makes 3 new lines, or it deletes more characters then i deleted… But i can live with it, my programm is growing :slight_smile:

I get some slow effects on iPad1 around 300. I usually use this as an indication that I’m over engineering something. I count it as a feature :slight_smile:

Supreme excellence consists of breaking the enemy’s resistance without fighting. -Sun Zu

Thinking on it further maybe a change of tactics is in order.

If we had a method of publishing our apps in the app store on with the planned open source engine, Apple could run “Made on the IPad for the IPad, safely(or whatever)…” They would then be more amiable to it as an SDK and not an app competitor. What are the options for developing on Droid for Droid? Are they any good? Are they safe?

You know that is a great idea. Though they may take more credit than they deserve (the iPad and ios 5) and may sort of shun TLL.

When TLL releases the open source backend, you’ll be able to pony up $99 a year to submit apps to their app store. The money isn’t poorly spent - they need to vette the apps, and they do advertise, and they handle payment processing, which is a nightmare for small indies to deal with (I did it in the past).

But - I’m not paying Apple a c-note a year to share, sorry. I have a job that pays the bills, I write code and share it because I’m that kind of person. If, in the end, Apple chooses to not let me share here…

https://www.youtube.com/watch?v=OYecfV3ubP8

Not that I’m a hot chick. Just sayin.

The one thing Apple preventing .codea imports will not do is prevent .codea imports. We will recognize the damage, and route around it.

I think it says volumes that the best arguments to Apple about loosening their restrictive policy on code sharing are their own commercials.

Here’s my suggestion to the code sharing issue:

TAR is a very simple format. It’s very much like MIME attachments in email. There’s a text header describing the first segment, which is a file, followed by the text content of the first segment, until the next header describing the next segment in the archive, followed by text for the next segment, etc, rinse, lather, repeat.

Without download or install of code, cut and paste is our only vector. So to export out a project, send it all as a TAR in an email. Or save it all as a TAR in the clipboard, which the user can paste onto an email or on pastie or gist or posterous, whatever. To import, copy and paste the TAR into a new project, and process the TAR segments into separate tabs. If pasted into an existing project, append the pasted content onto any existing tabs matching the name of the TAR segments.

And as an added bonus, TAR gives you base64 encoded binary payloads of images, sounds, fonts.

I hope that made sense. I’m not sure I did a good job explaining myself.

It’s the import part that apple’s rejecting. We have (had) .codea, which is in reality a rich text format directory. Apple won’t change their policy if we change the format the files are saved in. (Me, I voted for a zip file).

but - see the “importing .codea files workaround” thread…

I don’t like repeating myself, but click here to se my opinion.

I like the import from clipboard option, but it (and my decoding page) are just lame stopgaps. We need to be able to click on a file and import a project without shenanigans.

The tar export to tar sounds great. Apple has only disallowed direct import of code at this time, cut/paste is still there.

An import of non-lua from tar would be allowed like images and project data. Now there are ways to sneak code in without. Most people would consider those methods not,worth the effort.