- Wed Mar 18, 2015 7:19 am
#12168
Ok, my previous post was intended to be a part of flashmode optimization script but here it'll be also nice 
- Wed Mar 18, 2015 7:33 am
#12169
Where could I find clen function?
Code: Select all
PANIC: unprotected error in call to Lua API (cannot open http_clen.lc)Where could I find clen function?
- Wed Mar 18, 2015 9:31 am
#12184
I can include the .lc files in the distribution if bootstrapping is the only reason to convert it to C.
Let's look at the pros and cons of converting to C.
Pros:
Smaller overall code size
Hardware function loading from flash
Loaded functions go in iram instead of heap?
More efficient string handling (no hashing or interns sticking around)
Slightly faster to execute machine code than bytecode
May be able to manipulate network buffer directly rather than copying into additional strings
Cons:
Impossible to add features (gzip, websocket, etc.) without reflash
More complex code to manage
Current callback patterns are not efficient for multiple dynamic pages (need to hold a reference to every function it might call)
flashMod not a good fit for a C module (it's mostly just a wrapper around string.dump and loadfile)
What would a C version of this look like?
Well, using the standard callback method, you would create an httpd instead of a TCP server, and it would have on "get", "post", "header", and "data" callbacks, and it would still be up to the app to route those requests to the right place, making the C portion responsible for little more than parsing, and still requiring memory management like flashMod on the lua side.
Another implementation might be to get closer to what we have today - a convention-based server. If it gets a request for a file with a dot, it uses that extension to look up the mime type and serves the file as static content. If there is no dot, it starts looking for a set of flash functions, then a compiled .lc module, and finally a .lua file. I'm not sure where .pht parsing, compiling, and execution fit.
In short, a C version would be considerably more complex. If I can solve the memory problems and it is reasonably fast, I will stick to the lua version for now.
Let's look at the pros and cons of converting to C.
Pros:
Smaller overall code size
Hardware function loading from flash
Loaded functions go in iram instead of heap?
More efficient string handling (no hashing or interns sticking around)
Slightly faster to execute machine code than bytecode
May be able to manipulate network buffer directly rather than copying into additional strings
Cons:
Impossible to add features (gzip, websocket, etc.) without reflash
More complex code to manage
Current callback patterns are not efficient for multiple dynamic pages (need to hold a reference to every function it might call)
flashMod not a good fit for a C module (it's mostly just a wrapper around string.dump and loadfile)
What would a C version of this look like?
Well, using the standard callback method, you would create an httpd instead of a TCP server, and it would have on "get", "post", "header", and "data" callbacks, and it would still be up to the app to route those requests to the right place, making the C portion responsible for little more than parsing, and still requiring memory management like flashMod on the lua side.
Another implementation might be to get closer to what we have today - a convention-based server. If it gets a request for a file with a dot, it uses that extension to look up the mime type and serves the file as static content. If there is no dot, it starts looking for a set of flash functions, then a compiled .lc module, and finally a .lua file. I'm not sure where .pht parsing, compiling, and execution fit.
In short, a C version would be considerably more complex. If I can solve the memory problems and it is reasonably fast, I will stick to the lua version for now.
- Wed Mar 18, 2015 11:34 am
#12193
Sounds like windows ... make sure to save files without BOM. Was mentioned in this thread before.
StefanL38 wrote:I tried two scripts attached to posts here with zero success.
with init.lua I got only an errormessage
dofile("init.lua")
init.lua:1: unexpected symbol near 'ï'
But I even can't find the character 'ï' inside the file(
Sounds like windows ... make sure to save files without BOM. Was mentioned in this thread before.
