Codea 1.4 is alive

I’ve thought about the idea of setting up a website and then using the new functions to set up a code sharing app to allow people to just download and run. What stopped me was thinking about how Apple would respond to something like that.

@Deamos Good call. Apple does pay attention, and if they get wind that people are working around their terms they will pull Codea.

This has happened in the past.

So my advice to anyone thinking “Oh I could use `http.get() and then [some other command I will not name here] and bob is my uncle” to just keep that thought to yourself. Savvy? :wink:

Hi Guys,

Managed to get back into the site - couldnt access the pages since Saturday evening - either on a web browser or from Codea.

Had time to play with Codea and ran into the stability problems - but also noticed these two:

  1. Intermittently Codea switches into landscape mode and locks in that mode even if programmed otherwise. Have you added any intelegent code to select the best screen format for the application. I know I occasionally program object which slip off the page. Some of my apps are written to run only in portrait and they lock out into landscape???

  2. I linked onto my DropBox account and found where to store my sprites. So I transferred all my png files to it, 32 of them, then I linked in using sprite() from an app. Codea must download the sprites in a buffer so that you can select one. During the download there was a relatively loud noise coming from my ipad - almost melodic, this stopped when the ipad was fully synced. I had volume on my ipad at 0 and my PC volume was off. My ipad accesses the internet via a wireless link on a router. Have you any idea why the noise was generated and will I have that every time I access sprites in my application?

Re icons for my apps - @Inviso - haven’t tried out your suggestion - won’t that write the icons to my local picture storage on the pad?

I’ve looked at the example files with the system and can’t find anything that looks remotely iconish - are the icons stored in the codea file and does Bortels web app ignore them when the class() and sub files are unwrapped and then zipped before download.?

Can anyone tell me what the icon dimensions are then I can start making a few for my apps.

Thanks agin,

Bti_G

[-O<

Not sure if this is related to the crash fix that is coming with 1.4.1, but I am having intermittent crashing when destroying and creating edges. I’m trying to come up with code that reproduces the crash consistently, but that is proving to be difficult.

Test #9 of the Physics Lab example crashes on loading, though, which I believe is related to the problem I’m having.

I think it’s fair game to post your lua code online so we can do

s = http.get()
loadstring( s )

Thanks a lot for the new version. I will take a closer look in the next days.
But i have now the same issue with the sprite zoom inside Codea as with the runtime library (for a closer description with code, see my post at the end of the “runtime library”-thread): If i try to zoom a sprite with the sprite function in this kind:

sprite("sprite-name", pos.x, pos.y, width*2, height*2)

the sprite will have now the vanillia size – in the previous version, everything had working fine. I checked this on my retina ipad (don’t have codea on my iPad 2)

@ruilov when I said apple has pulled apps because someone posted in forums how to run external code, I wasn’t kidding. There have been multiple examples of it, but one that comes to mind was a Commodore 64 emulator bundled with some licensed roms that also had a hidden way to download basic programs from the net.

It is against the Apple Developer Agreement, and if TLL is lucky they will just have to take aware the loadstring() command. If they are unlucky, the whole app could go aware forever.

This is the last I am going to say on the matter, because the last thing we want is a big conversation that could get into the blogs and get Apple’s attention. None of us want that… right?

I have to agree. If it doesn’t stop it might not be a bad idea to enforce this as a rule and remove threads that mention it.

I’ll leave to TLL to decide what to do about it. They got to have been aware that someone would do it

function setup()
    local url = "https://raw.github.com/gist/2815108/47ef4a5fe5e1c6f585c7ecfaabae3532b6a55831/pacman"
    http.get(url,httpCB)
end

function httpCB(data,status,header)
    if status ~= 200 then
        print("failed to download code")
        return nil
    end
    
    local luacode = loadstring(data)
    luacode()
    setup()
end

Thanks for this great 1.4 version :slight_smile:
Two questions:
1- Is there a “What’s new in Codea 1.4” page somewhere?
2- Also is there something to manage layers out of the box in Codea or is this possibly planned for a future release?
Many thanks again for the good job :slight_smile:

@ruilov I have suggested to TLL a few times in the past that I’d be willing to lose loadstring() in favor of http.get() - perhaps your posting and apple may make that a reality, eh?

I would hope apple is more enlightened, but I’m not counting on it, and you probably shouldn’t either.

Please don’t start an arms race were doomed to lose.

@Bortels, yeah I’d rather not make assumptions about what apple will or will not like. I’d rather push the boundary and learn where the line is than live in fear. If apple doesn’t like the combination of http.get and loadstring they won’t be shy about saying so.

@ruilov Have you ever dealt with the Apple review process first hand? If you haven’t you need to take our word for it, Codea will lose. Dynamically loading code is a violation of the TOS. And Apple would be in their rights to pull Codea and never let it back in.

Please err on the side of caution. And TLL please delete all these messages…

TOS is an evolving beast. 2 years ago codea itself wouldn’t be allowed.

I’m ok if TLL deletes all this as well, but don’t think they have to.

Well I am glad you are willing to gamble with their app…

ha JockM, come on. I’m not gambling, I’m using it. It’s TLL that took the gamble, and I’m glad they did.

@ruilov Well even if it were just TLLs gamble, you still don’t need to poke the bear (in this case Apple). But you are doing the gamble because you are calling attention to it. Most users wouldn’t make the connection between those two commands. But if they have a template then they are more likely to use it.

Even if TLL deletes all these messages now the damage could aleady be done. Enough people have seen this thread to remember it, blog about, or otherwise call attention to it. If it picks up gets published somewhere a little more noticeable, Apple can catch wind of it. If they do there will be repercussions.

If I were in TLL’s place I would push though a 1.4.1 right now that disables loadstring(). Its the best chance they have to keep this from going out of control.

@JockM this has been discussed multiple times. Eg

http://twolivesleft.com/Codea/Talk/discussion/comment/4803

Honestly, while preventing this is important, I really could not go about loosing the loadstring() function. It would kill not only my Windowing manager, but also a few other projects I am working on. There needs to be some other way.

@Deamos the only other way would be for TLL to mark data loaded from http.get() so that it could not ever be used in loadstring()… no matter how much it is manipulated.

That is nontrivial to say the least, Getting rid of loadstring would be far simpler