Hate: In love with C

[appleide]

Looks like it works exactly the same as C code that binds lua code to it. Programs the lua via stack. That should be fun.
I was thinking about doing pure computational stuff, e.g like recursively traversing a tree and calculate some value for each node based on its parent's value. Seems like it wouldn't be as 'easy' as I thought but I'm hoping it'll be faster to do this in lua.

This'll be cool.

[sauer2]

You're trying to make löve hybrid Lua and C?
That would be cool, if this works!

[Robin]

You're trying to make löve hybrid Lua and C?

Very cool indeed, however, I feel the proper term would be "hÿbrid".

[rude]

You mean of course: CÖPULATION.

But do not expect the full C standard library, as it might look like we're going to have to export functions one by one into the TCC context. In particular, I can see how we might not want FILE, fwrite and all that. Generally, allowing C code is a security risk, but screw that. Awesomeness always takes priority over security. Also, files can't #include another files unless we make our own "fake" preprocessor. Which I suppose is doable.

[sauer2]

Since C is rather not proper the same depending on compiler and platform and generation (e.g: sometimes stdio.h and sometimes stdlib.h), i don't think this matters, if there is a good documentation.

[Star Crunch]

Depending on what you want to do, this may also be worth a look:

http://luaforge.net/projects/alien/

[Chris016]

Another idea if you wanted to you could try something with Large C.
http://ubuntuforums.org/showthread.php?t=351973

That explains how you can do it. Ive tried it im sure it only works in linux. Its pretty cool you could program your own C macros too.

[rude]

This now actually works in the internal LÖVE build.

Code: Select all

-- main.lua
love.native.compile("leet.c")
love.native.relocate()
leet = love.native.getSymbol("leet")
print(leet()) -- 1337

Code: Select all

// leet.c
#define lua_State void

int leet(lua_State * L)
{
	lua_pushinteger(L, 1337);
	return 1;
}

However:

1. I'm not sure whether this "much" functionality is actually needed. We demand that only modules be used, and not expose getSymbol:

Code: Select all

-- main.lua
love.native.compile("leet.c") -- Compiled and relocated.
require("leet")
print(leet.test()) -- 1337

Code: Select all

// leet.c
int test(lua_State * L) {
	lua_pushinteger(L, 1337);
	return 1;
}

static const lua_Reg leet_lib [] {
	{ "test" , test },
	{0,0}
}

int luaopen_leet(lua_State * L) {
	return luaL_register(L, "leet", leet_lib);
}

2. Not sure whether to allow multiple compilation contexts, and if yes, how?

Code: Select all

-- One choice
c = love.native.newCompiler()
c:compile( files )

Code: Select all

-- Another choice
love.native.compile(file1, file2, ... fileN) -- One context. Relocated automatically.
love.native.compile(file1, file2, ... fileN) -- Another context. Relocated automatically.

I think the former is impossible due to garbage collection. There's no (acceptable) way of knowing when there are no more references to relevant functions in Lua. Our options are then either a) never deallocate, or b) give developers access to free the compilers manually. I frown upon a), but not nearly as much as I frown upon b).

Any thoughts?

[bartbes]

1 = good
2, take the second, I love these fast developments

btw, master thesis came out nice?

[osgeld]

i am so lost