1.3.7 beta

W00t!

I am converting over some of my old socket stuff (never delete anything!) - I’ll let you know how that goes.

any chance of getting mime (specifically, mime.unb64 and mime.b64)? I think I have code somewhere to do it, but better if it’s built-in. (Ditto for URLencode/decode, probably, but that’s just thinking ahead)

I am having rotation issues with my ipad, noticed the Network docs run off the right when you’re in portrait mode. (Doh! rebooted, tried in landscape, still cut off)

If you do not provide a fail function, I assume it fails silently?

Seeing a weird problem with text() and WIDTH.

I’m in landscape mode - WIDTH is returning 768 (with the console, makes sense).

but “text(“Hello”, 0, HEIGHT/2)” comes out under the console - “0” for text is still apparently the far left of the screen under the console. Adding 350 seems to put it in the right place.

Same issue in portrait, but the console is thinner so 350 isn’t the right offset.

ohhh this is htttp.get is a big one!

Yup. Working beautifully, btw.

Of possible interest: http://lua-users.org/wiki/JsonModules

(I started writing a cool “show me recent #Codea twitter posts, all floaty across the screen”, and it’s all coming back as JSON, which is fine, but we need to parse it…)

Hmmm.

Push notification. It would be handy. Ideally in a way such that the push notification would let you touch it, open up codea, and autorun a project. Just thinking out loud. The type of game I want to make in the long run is scheduled (ie. turns run every day at noon, for example), so notification isn’t important. But for other turn-based stuff (Hero Academy is the model there) it would be darn handy. (I plan on faking it with either email or SMS messaging, both of which are doable server-side).

After messing with it for a while, http.get stopped calling either return function. Other apps (safari anyway) continued to work. Had to kill and restart codea to make it work again. Trying to reproduce.

Thanks for all the feedback, @Bortels — It’s really helpful!

Interesting about the text bug — the view doesn’t even extend under the console so I’m not too sure what’s happening there.

Push notification is very tricky and might be against Apple’s rules. As the service is provided on a per-app basis. It would probably have some server requirements on our part.

The last one sounds like a state bug with the HTTP request framework, will look into it.

Mime may make another appearance. Note, though, that we will be handling PNG and JPG decoding transparently so you won’t have to.

E.g.

http.get( "http://twolivesleft.com/Codea/logo.png", 
          function( img, s, r )
              -- Here img is actually an image() type
          end )

Good on the handling of PNG and JPG automatically. I was gonna say “GIF too”, but meh - it’s easy enough to convert, really, and technically PNG is superior.

In this particular case, I was grabbing font data (sockets were a looong time ago!) for the Atari font; the base 64 isn’t a killer, it’s not that hard to implement. The rest of mime isn’t as exciting.

The workaround for push for us end-users is to grab a free texting app - many of them support receiving a push notification via email (you email to the company who pushes to the app).

Been waiting for this for a while - my brain keeps jumping from “ooh, do this” and “ooh, do that” with http.get. I may do the twitter thing - it’s pretty straightforward, and might make a good demo of using this (and maybe of JSON, although I might just fake it for this case) in a non-trivial application. Unless I get distracted :slight_smile:

Feeling stupid right now.

After some research, this seems to be the “best” json encode/decode out there - http://chiselapp.com/user/dhkolf/repository/dkjson/home - best meaning “pure lua, reasonable license, well documented”. Your best may vary.

One thing I like about it from a traditional sense is it doesn’t pollute the global namespace - you do ‘json = require(“dkjson”)’ and now use the json object to access it.

But - we don’t “require” in Codea. I’d normally make this into a class and have you instance it, but it feels… inelegant? Point being - there’s got to be an idiom to say “treat this tab like a file and require it”. It’s maybe automatic - but I need that object it references.

I’m sure I’m just missing something stupid. And - if I’m not - we need some way to do just this. There’s lots of good libraries out there we can and should be using, and to have to wrap them up is not viable long-run. One of the core strengths of Codea is underneath, it’s bog-standard Lua - so there must be some way to do standard lua things.

Server side, I’m looking at a simple node.js front-end to redis for what I’m working on - I’ll share details as soon as I have a working proof-of-concept. The idea is that the Codea app can poll state of objects via http.get (ships, planets, etc), post changes (orders), and a server-side engine (probably in perl) will periodically update them (daily).

That sounds pretty cool (the space simulation).

That JSON module looks really nice, thanks for finding it! “Require” wouldn’t be necessary if we were to include it by default. I don’t think there’s any harm in having a global json library for parsing assistance.

Including the json library I found (or another good one) is an excellent idea.

But - my question/suggestion still stands - is there a good way with Codea now to do the functional equivalent of “require” with a tab, without wrapping it up as a class? And - if there’s not - adding one would make a ton of good stuff more easily accessible.

If it’s a tab it will just be loaded straight into the Lua interpreter — so a “require” is not necessary. I think I’m missing the point, require() works with code, but you want something for data files?

The json library is written with the intent in normal Lua that you invoke it with:

json = require("dkjson.lua")

This gives you a json object that you can use to json.decode() and so on.

What I’m wanting to do is drop a “required” file into a tab, then simulate the “require” call, such that I end up with an object that’s the result of the require() call. I just haven’t dived deeply enough into Lua’s guts to know what that actually entails, or if it’s even feasable to use a Codea tab in that manner. I can always wrap the whole thing up in a Class, but it’s inelegant - it is desirable to be able to grab code off the net and use it in the manner it’s intended to be invoked in (ie. require() returning an object).

The end goal being making it easier for a desktop Lua user to go to Codea - I want to be able to say “If you have a chunk of code that you’d normally use with require() - here’s what to do in the Codea environment”, and ideally NOT have it be “modify the code by wrapping it up in a class”.

In the case of the json library, the require() is the mechanism by which an object is created that acts as a “handle” for that library’s invocation. If I just drop it in a tab, that object isn’t created.

So - I’m trying to make an authentication mechanism that will be reasonably secure without https (because http.get() doesn’t support SSL - right?)

And I’m having problems without some sort of secure hashing function (I plan to implement basic APOP).

Any chance we could add an MD5 library? Most of the variants I find out there are coded in C for speed. It won’t slow me down to not have one, but the game will be trivially hackable by anyone sniffing it (maybe I’m paranoid…)

I typed this yesterday, but stupidly forgot to press “Post Comment”

All “require” does is set the variable to the result of evaluating the specified Lua file.

For example, you’ll notice the JSON library is formed as follows:

local json = { some table }

-- Lots of implementation

return json

So “require” is similar to just evaluating a chunk of Lua code (in a file or string) as a function.

I’ll have to ask @Dylan about whether http.get supports SSL. I’ll think about MD5, or maybe just adding SSL support to http.get instead.

SSL support would be nearly as good for my particular use-case, and FAR better for many others. (I can fake my way around it missing - but there are other cases where that can’t happen).

So the take-away is that instead of “require”, drop the library in a tab and look for the return and simply make that global? Ok. I guess that makes sense. I’ll give it a shot. (I’ve since abandoned json because my needs are way simpler, but it’s still gonna be handy).

I’m coding my server-side tonight, or that’s the plan - but I’m also going to pick up my new iPad, so we’ll see what wins. :slight_smile:

@Dylan tells me it should support https, let me know if you have any issues with it.

For require you could add the following lines to the library:

At the start:

function createJSONParser()

At the end:

end

Then you can do:

json = createJSONParser()

Require is more sensible, but doesn’t really work with concept of tabs — as they are loaded automatically.

I’ll give both a shot - restoring my old ipad to my new one now.

If you have a new iPad you will need to register the device with TestFlight — then the next build of Codea will be compatible (I will need to add your device ID to the provisioning profile).