Yep - I’ll register, and post.
Ok - re-registered, waiting on your permission for testflight to install.
I have to actually make a new build of Codea for it to work on your iPad. So when the next build comes out it will be compatible.
Edit: Can I remove your old iPad from provisioning? Or will you still be using it?
Okeydokey. Gave the old iPad to the wife, doubt she will want to hack codea much 
so sure, nuke that one. I’ll work on my server side while waiting for the next build - plenty to do there…
Off topic but not worth a new thread.
Looking for stuff for the new iPad, a genius recommendation pointed me to “python for iOS” (I dislike python - any language that has syntactically-significant white space is damaged on launch)
Their first screenshot shows it doing a http get. so if apple gives you crap - prior art. Not that it’ll help.
There’s also a processing clone based on processing.js out there, I won’t try to type the name because it’s all “leet”.
I dislike python - any language that has syntactically-significant white space is damaged on launch
guess you’re not a TeX fan, then
I… I don’t know TeX. /hangs head in shame
Never had a need for what it offers - heck, I never needed to go beyond ASCII, truth be told. You should see my web pages. They are… Spartan.
I’m not sure it counts, though. TeX is largely formatting, yes? No?
The issue with significant white space is that it’s just to easy to screw up scope, unless you’re using an IDE, or it has been for me at least. Is it prettier? Perhaps - but pretty at the expense of robustness doesn’t strike me as a great trade. Besides - in vi, I’m addicted to jumping between matched sets of brackets, which you can’t do without brackets, oddly enough.
I have the same issues with coffescript. Prettier than JavaScript? Yes! Easier to write? Certainly! Subject to weird errors because I screwed up spacing somewhere? Yep.
Languages should save me from myself by design, not force me into an IDE to do it. My opinions.
I am contemplating http Cookie support.
It would help my pet project. That’s not a deciding factor, nor should it be.
But - it may be useful. Lots of sites can and do use cookies for authentication and session handling (both of which are why I’m looking at it).
Before I make the SSL error again - maybe it’s already built-in and I just don’t know about it? If it’s there, I’ll code the server side expecting it, and if it’s not - I need to decide if it’s worth implementing on the client side to make the server side easier, or if it’s better to implement something special server side.
If not, no monster biggie - it is straightforward enough (if not simple) to roll our own.
O. M. G.
You have NO IDEA what a relief it is to be able to just load a graphic without having to monkey with encoding it and cut and paste and whatnot.
Out of curiosity - does it decode based on the actual binary content, or mime type?
Anyway - working beautifully. It’s startling how small these icons I’ve been using are on the retina display. I have one ( http://home.bortels.us/images/fighter.png - and yes, that’s a nice alpha-blended shadow.) that I’ve been using as a test image for various things throughout the years, and on my computer it’s goodly-sized - a good 4 cm wide. On the retina display, it’s like maybe 1.5 cm (my home screen is an ancient Cinema Display. I don’t want to say what I paid for it, it’s grim. But - I’ve been using it for… 8 years? and it’s still nicer than what I use at work…)
Because I’m sharing - got sessions and authentication working on my server side, time to make a client in Codea. So I’ll be exercising SSL and post and that jazz. It’s gonna be fun.
Ok - trying https, just got back “SSL problem (possible causes include a bad/expired/self-signed certificate, clock set to wrong date”. Well - the server cert is self-signed, so that’s what that is. I had expected that might come up - is there a way to say “ignore the server cert validity” (ie. “curl -k”) or to give it a Cert Authority to use?
also - is there a way to set a timeout? It’s async, so I could simply watch the elapsedtime and punt, ignoring the result if it came back after timeout, but that’s… inelegant?
(BTW - async with callbacks is so the way to go, good call; it’s eliminated a ton of issues that I was running into back in the olden days with sockets and blocking calls)
Heh - when I try to print the image returned from a http.get - it tells me it’s a table.
but when I try to iterate pairs, it tells me it’s userdata.
I’m just trying to figure out how big it is so I can see if we’re keeping it compressed or uncompressed, in preparation for trying to marshall them out to local storage (which will be an issue if they’re an odd userdata type).
Or maybe I’m doing something wrong - I’m pooped.
I guess I could just try saving them off and loading them back, and see what happens.
so - now that I’ve got my precious graphics, it would be nice to be able to save them locally to avoid the lag in loading them (and the load on a server), and maybe to allow offline play, although my particular app will… well, I guess I could set it so you could play offline, or at least view the saved state…
So yeah - saving graphics. Not a showstopper, I can just load em.
Glad it’s working for you!
It’s based on the binary content. I believe it supports a pretty large range of image formats, too (all iOS supported formats).
I’ll have to speak to @Dylan about the certificate possibilities and timeout.
Yes — if we ever do a blocking-call version we will enforce a modal interface (i.e. progress bar + cancel button for the user). And the developer won’t have control over whether that appears during a blocking call.
Now that it’s so easy to pull images into Codea, I started my first little project that uses external resources. I’m porting Flixel’s FlxInvader example over to Codea. Images are loaded directly from FlxInvader’s Github repository
Current progress:
I am almost thinking for a modal “simple” image fetch, we’re better off doing it in user-land. It would mean that someone who wanted to could just tweak the class. On the whole, I think we’re better off with as much source as possible exposed - some sort of library management (or simple file I/o and require) seems more and more useful.
iOS huh? I wonder if svg will work. I’ll have to try.
I think something like an image loader may just fall out of our stuff - the need will be universal.
@frosty, I love the concept of simply hosting from github!
so, confirming gif and jpeg work, and svg does not.
Mind you, I didn’t expect svg to work, but I was an optimist
I was also happy to see it supports all the image() stuff, including .width and .height.
Can I set the .data for an image? the http.get does, clearly. I was to as well.
I’m still on caching an image locally - I like the concept of putting images up on github or imgur, but I want to avoid hammering them and hitting rate limiting. So - I want to save off loaded images to persistent storage.
I see if I have image “i”, I can do i.width and i.height, and the docs say i.data will have (if I read it correctly) the encoded jpeg/png (and I assume gif). That’s good - that will be the smallest practical representation. I can take that, b64 encode it, and save it to persistent storage.
Question is - can I load it back in? In other words, can I assign to image.data? and if I do, will it decode and display properly?
The answer appears to be “no” - but maybe I’m doing it wrong. Here’s the code chunk (this is my “on success” callback):
function success(body, result, headers)
s = body
ss = image(s.width, s.height)
ss.data = s.data
end
Note this doesn’t work. Indeed - ss isn’t even an image, it’s nil after the above fun.
Following through with a threat of wrapping the async up behind a nice modal interface:
ImageLoader = class()
function ImageLoader:init()
self.base = "http://github.com/bortels/planets/raw/master/images/"
self.loadimg = "Planet Cute:Brown Block"
self.loading = 0
self.imgs = {}
end
function ImageLoader:fetch(tag, name)
self.imgs[tag] = self.loadimg
http.get(self.base .. name, self:newsuccess(tag))
self.loading = self.loading + 1
end
function ImageLoader:newsuccess(tag)
return function(body, result, headers)
self.imgs[tag] = body
self.loading = self.loading - 1
end
end
Closures! /flex
I need to find a better built-in “loading” graphic.
Call with:
function setup()
iload = ImageLoader()
iload:fetch("f", "fighter.png")
end
function draw()
-- regular draw stuff here
sprite(iload.imgs["f"], 300, 300)
end
If you don’t want to view the “loading” graphic, you can check iload.loading and display a loading screen…
I am thinking we might allow modal loading of images through the following interface:
sprite( "http://url/to/image.png", x, y, w, h )
This will not render anything until the data at the URL is downloaded and cached. So images will pop-in some time after running. This might be okay for quick uses. Alternatively we could add a temporary loading image, but that won’t have the correct width and height until after download.
Add a placeholder image to that call, and an optional “ok it’s loaded” callback, and that would support most uses.
How would you handle an update? Would you (could you) send a “If-Modified-Since” header? Honor the “Expires” header (which would mean caching it along with the image)? Would you (could you) have a method to clear or expire (or examine!) the image cache? Ideally, you’d be able to show the image cache (perhaps for a given domain name) as a spritepack…
The code I have above is short enough that when someone says “I don’t understand how to do a http.get to get images”, they can just be pointed at that (or ideally at a demo project that handles image fetching in an asynchronous manner elegantly).
I’m working on the api for loading and saving images in and out of sprite packs. For now there is a Documents sprite pack, which lets you save and load images from the apps documents directory, which will also be exposed in iTunes file sharing. There is also the Project sprite pack, which saves and loads them inside the project itself.
The api is as follows:
-- load a from a sprite into an image
docImage = readImage("Documents:Image")
-- save an image back again
saveImage("Documents:someImage", someImage)
-- list all images for a sprite pack (returns an array with all the sprite names)
spriteList("Documents")
-- change project icon
saveImage("Project:Icon", image)
The built in sprite packs can be read from but not modified (they are read-only). The intention is to give users many avenues for getting sprites in and out of the app. I imagine that someone could write a simple piece of code to bootstap an app by downloading images into its project sprite pack to make it easier to share an asset rich project.
The sprite save/load API looks dandy!
And you hit it on the head in the last line - idea being when we made cosmetic changes in an app (for mine, adding new ship/race/planet graphics), it’s not a code change - we grab the new graphics, persist them, and move on.
This ability (http.get an image and persist) completely removes the ugly concept of cut/paste reams of encoded binary data for graphics. It’s awesome and long-anticipated.