simple and fast Lua templating engine

gg.lafon · 2013-12-23T23:15:38+00:00

Yes, in npm you must bump the version in the package.json, but in rocks you have to do that and rename the file. It's a small thing but it's annoying and if...

simple and fast Lua templating engine

gg.lafon

Hello,

can you give me some advices for choosing a simple and fast Lua templating engine commonly used.

When I say simple, I just wanna do very basic things: ability to do loops for building arrays, to display some blocks with conditions and to manage headers and footers in order to harmonize each page.

Currently a part of my website is under PHP-FPM with XCACHE, it's fast but it's very memory consuming with several connected users so I would like to remove PHP in order to use only Openresty to save some memory, to be easier to administer and to stay as fast as PHP or faster to serve requests.

Jérôme

luis.gasca

Give lustache a try

On 23/12/2013, at 16:15, jerome lafon <gg....@gmail.com> wrote:

Hello,

can you give me some advices for choosing a simple and fast Lua templating engine commonly used.
When I say simple, I just wanna do very basic things: ability to do loops for building arrays, to display some blocks with conditions and to manage headers and footers in order to harmonize each page.

Currently a part of my website is under PHP-FPM with XCACHE, it's fast but it's very memory consuming with several connected users so I would like to remove PHP in order to use only Openresty to save some memory, to be easier to administer and to stay as fast as PHP or faster to serve requests.

Jérôme

.

gg.lafon

OK I will.

Thank you.

Any other advices?

Jerome

Le lundi 23 décembre 2013 16:48:20 UTC+1, Luis Gasca a écrit :

Give lustache a try

On 23/12/2013, at 16:15, jerome lafon <gg.l...@gmail.com> wrote:

Hello,

can you give me some advices for choosing a simple and fast Lua templating engine commonly used.
When I say simple, I just wanna do very basic things: ability to do loops for building arrays, to display some blocks with conditions and to manage headers and footers in order to harmonize each page.

Currently a part of my website is under PHP-FPM with XCACHE, it's fast but it's very memory consuming with several connected users so I would like to remove PHP in order to use only Openresty to save some memory, to be easier to administer and to stay as fast as PHP or faster to serve requests.

Jérôme

.

leafot

Here's one that I wrote, based on erb: https://github.com/leafo/etlua

On Mon, Dec 23, 2013 at 9:03 AM, jerome lafon <gg....@gmail.com> wrote:

OK I will.

Thank you.

Any other advices?

Jerome

Le lundi 23 décembre 2013 16:48:20 UTC+1, Luis Gasca a écrit :
Give lustache a try

On 23/12/2013, at 16:15, jerome lafon <gg.l...@gmail.com> wrote:

Hello,

can you give me some advices for choosing a simple and fast Lua templating engine commonly used.
When I say simple, I just wanna do very basic things: ability to do loops for building arrays, to display some blocks with conditions and to manage headers and footers in order to harmonize each page.

Currently a part of my website is under PHP-FPM with XCACHE, it's fast but it's very memory consuming with several connected users so I would like to remove PHP in order to use only Openresty to save some memory, to be easier to administer and to stay as fast as PHP or faster to serve requests.

Jérôme

.
agentzh
Hello!

On Mon, Dec 23, 2013 at 10:23 AM, leaf corcoran wrote:
> Here's one that I wrote, based on erb: https://github.com/leafo/etlua
>

It seems to me that we can improve the performance of the existing
compiler-style templating engines (a lot) with LuaJIT v2.1's new
table.create(narr, nrec) API and even the upcoming string.buffer API
in LuaJIT v2.1 :)

Best regards,
-agentzh
leafot

Yes, I've actually been meaning to try it out. The new string optimizations look great.

On Mon, Dec 23, 2013 at 9:03 PM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Mon, Dec 23, 2013 at 10:23 AM, leaf corcoran wrote:
> Here's one that I wrote, based on erb: https://github.com/leafo/etlua
>

It seems to me that we can improve the performance of the existing
compiler-style templating engines (a lot) with LuaJIT v2.1's new
table.create(narr, nrec) API and even the upcoming string.buffer API
in LuaJIT v2.1 :)

Best regards,
-agentzh

.

gg.lafon

It sounds great.

When do you manage to improve your template engine with the possible optimizations in LuaJIT 2.1?
It could be a nice Father Christmas gift! :D

Jérôme

Le mardi 24 décembre 2013 06:28:40 UTC+1, leaf corcoran a écrit :
Yes, I've actually been meaning to try it out. The new string optimizations look great.

On Mon, Dec 23, 2013 at 9:03 PM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Mon, Dec 23, 2013 at 10:23 AM, leaf corcoran wrote:
> Here's one that I wrote, based on erb: https://github.com/leafo/etlua
>

It seems to me that we can improve the performance of the existing
compiler-style templating engines (a lot) with LuaJIT v2.1's new
table.create(narr, nrec) API and even the upcoming string.buffer API
in LuaJIT v2.1 :)

Best regards,
-agentzh

.

agentzh

Hello!

On Mon, Dec 23, 2013 at 9:28 PM, leaf corcoran wrote:
> Yes, I've actually been meaning to try it out. The new string optimizations
> look great.
>

Nice!

And I'm also thinking about maybe we could also recycle the Lua tables
for string concatenations with LuaJIT v2.1's new table.clear() API.
The table sizes for a particular template file and invocation point
should often be similar :) Then we may save the GC overhead in the
table completely ;)

Best regards,
-agentzh

mingodad

I personally found https://github.com/LuaDist/mixlua to be the most simple choice we can use anything lua can do with it.

On Monday, December 23, 2013 3:15:38 PM UTC, jerome lafon wrote:

Hello,

can you give me some advices for choosing a simple and fast Lua templating engine commonly used.
When I say simple, I just wanna do very basic things: ability to do loops for building arrays, to display some blocks with conditions and to manage headers and footers in order to harmonize each page.

Currently a part of my website is under PHP-FPM with XCACHE, it's fast but it's very memory consuming with several connected users so I would like to remove PHP in order to use only Openresty to save some memory, to be easier to administer and to stay as fast as PHP or faster to serve requests.

Jérôme

amnon.david

lua works fine but luajit segfaults on this (at least on OS/X).

On Wednesday, December 25, 2013 11:57:36 PM UTC+2, ming...@gmail.com wrote:

I personally found https://github.com/LuaDist/mixlua to be the most simple choice we can use anything lua can do with it.

On Monday, December 23, 2013 3:15:38 PM UTC, jerome lafon wrote:
Hello,

can you give me some advices for choosing a simple and fast Lua templating engine commonly used.
When I say simple, I just wanna do very basic things: ability to do loops for building arrays, to display some blocks with conditions and to manage headers and footers in order to harmonize each page.

Currently a part of my website is under PHP-FPM with XCACHE, it's fast but it's very memory consuming with several connected users so I would like to remove PHP in order to use only Openresty to save some memory, to be easier to administer and to stay as fast as PHP or faster to serve requests.

Jérôme

mingodad

If you look at a fork of mixLua you can see two commits to it, probably the last one can be a solution to your segfault :

Added '\r' carriage return for the list of chars that need be escaped

On Tuesday, February 18, 2014 6:15:59 PM UTC, Amnon David wrote:

lua works fine but luajit segfaults on this (at least on OS/X).

On Wednesday, December 25, 2013 11:57:36 PM UTC+2, ming...@gmail.com wrote:
I personally found https://github.com/LuaDist/mixlua to be the most simple choice we can use anything lua can do with it.

On Monday, December 23, 2013 3:15:38 PM UTC, jerome lafon wrote:
Hello,

can you give me some advices for choosing a simple and fast Lua templating engine commonly used.
When I say simple, I just wanna do very basic things: ability to do loops for building arrays, to display some blocks with conditions and to manage headers and footers in order to harmonize each page.

Currently a part of my website is under PHP-FPM with XCACHE, it's fast but it's very memory consuming with several connected users so I would like to remove PHP in order to use only Openresty to save some memory, to be easier to administer and to stay as fast as PHP or faster to serve requests.

Jérôme

agentzh

Hello!

On Tue, Feb 18, 2014 at 10:15 AM, Amnon David wrote:
> lua works fine but luajit segfaults on this (at least on OS/X).
>

Will you paste the full backtrace for this segfault by gdb? Ensure
your LuaJIT build has the debuginfo enabled (via the "CCDEBUG=-g"
argument for "make").

Also, what exact version of LuaJIT are you using? Will you provide a
minimal but still complete example that can reproduce the segfault
reliably?

I'd be very interested to trace this down if it is a bug in LuaJIT :)

Thanks!
-agentzh

amnon.david

Here’s the entire process:

__________________________________________________________________

$ git clone https://github.com/LuaDist/mixlua.git

Cloning into 'mixlua'...

remote: Reusing existing pack: 50, done.

remote: Total 50 (delta 0), reused 0 (delta 0)

Unpacking objects: 100% (50/50), done.

Checking connectivity... done

$ cd mixlua

$ cmake .

-- The C compiler identification is Clang 5.0.0

-- Check for working C compiler: /usr/bin/cc

-- Check for working C compiler: /usr/bin/cc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

DIST_NAME: mixlua

DIST_VERSION: 0.2.7

DIST_LICENSE: MIT/X11

DIST_AUTHOR: Thomas Lavergne

DIST_MAINTAINER: Peter Drahoš

DIST_URL: http://oniros.org/projects.html

DIST_DESC: A preprocessor for files including embedded Lua code

DIST_DEPENDS:

-- Found Lua: /usr/local/lib/liblua.dylib (found version "5.1.5")

-- Configuring done

-- Generating done

-- Build files have been written to: /Users/amnondavid/devDownloads/mixlua

$ make

Scanning dependencies of target mixlua

[100%] Building C object CMakeFiles/mixlua.dir/mixlua.c.o

Linking C shared module mixlua.so

[100%] Built target mixlua

$ lua test.lua

[general]

name = Example 1

width = 1024

height = 768

[window1]

name = Win 1

level = 3

[window2]

name = Win 2

level = 1

[window3]

name = Win 3

level = 5

[window4]

name = Win 4

level = 4

<?xml version="1.0">

<name> Example 1</name>

</general>

</window>

</window>

</window>

</window>

</config>

$ luajit -v

$ luajit test.lua

Segmentation fault: 11

$ gdb luajit

GNU gdb (GDB) 7.6.2

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-apple-darwin13.0.0".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /Users/amnondavid/devDownloads/mixlua1/LuaJIT-2.0.2/src/luajit...done.

(gdb) run

Starting program: /Users/amnondavid/devDownloads/mixlua1/LuaJIT-2.0.2/src/luajit

JIT: ON CMOV SSE2 SSE3 SSE4.1 fold cse dce fwd dse narrow loop abc sink fuse

> dofile("test.lua")

Program received signal SIGSEGV, Segmentation fault.

0x00000000000685a2 in ?? ()

(gdb) where

#0 0x00000000000685a2 in ?? ()

#1 0x00000000000650e0 in ?? ()

#2 0x0000000000000002 in ?? ()

#3 0x00007fff5fbff750 in ?? ()

#4 0x0000000000076ee2 in ?? ()

#5 0x00000000000650e0 in ?? ()

#6 0x0000000000000002 in ?? ()

#7 0x0000000000000000 in ?? ()

(gdb)

__________________________________________________________________

Something seems to have really messed up the stack. However, I’ve found this:

http://stackoverflow.com/questions/13359821/luajit2-0-0-segmentation-fault-11

which references to: http://luajit.org/install.html that mentions:

"If you're building a 64 bit application on OSX which links directly or indirectly against LuaJIT, you need to link your main executable with these flags:

-pagezero_size 10000 -image_base 100000000

Also, it's recommended to rebase all (self-compiled) shared libraries which are loaded at runtime on OSX/x64 (e.g. C extension modules for Lua). See: man rebase"

So perhaps it is related to the above.

-Amnon

On Feb 18, 2014, at 9:21 PM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Tue, Feb 18, 2014 at 10:15 AM, Amnon David wrote:
lua works fine but luajit segfaults on this (at least on OS/X).

Will you paste the full backtrace for this segfault by gdb? Ensure
your LuaJIT build has the debuginfo enabled (via the "CCDEBUG=-g"
argument for "make").

Also, what exact version of LuaJIT are you using? Will you provide a
minimal but still complete example that can reproduce the segfault
reliably?

I'd be very interested to trace this down if it is a bug in LuaJIT :)

Thanks!
-agentzh.

agentzh

Hello!

On Tue, Feb 18, 2014 at 1:45 PM, Amnon David wrote:
> Here’s the entire process:
[...]
>
> $ luajit test.lua
> Segmentation fault: 11
>

Hmm. I cannot reproduce the crash on my Linux x86_64. Will try out my
macbook when I go back home.

> $ gdb luajit
>
[...]
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000000685a2 in ?? ()
> (gdb) where
> #0  0x00000000000685a2 in ?? ()
> #1  0x00000000000650e0 in ?? ()
> #2  0x0000000000000002 in ?? ()

Hmm, this backtrace is not meaningful. Maybe you're just on compiled
Lua code which lacks unwinding info.

Can you reproduce the issue with the latest LuaJIT v2.1 branch? If
you're using the latest LuaJIT v2.1, you can also use my gdb extension
commands below to get more information (like LuaJIT VM state, and Lua
land backtraces) about the crash:

    https://github.com/agentzh/nginx-gdb-utils

Regards,
-agentzh

amnon.david

Still occurs in luajit 2.1:

$ export PYTHONPATH=/Users/amnondavid/devDownloads/nginx-gdb-utils

$ gdb ./luajit-2.0/src/luajit

...

(gdb) source ../nginx-gdb-utils/luajit21.py

(gdb) run

Starting program: /Users/amnondavid/devDownloads/mixlua1/./luajit-2.0/src/luajit

JIT: ON SSE2 SSE3 SSE4.1 fold cse dce fwd dse narrow loop abc sink fuse

> dofile "test.lua"

Program received signal SIGSEGV, Segmentation fault.

0x00000000000685a2 in ?? ()

(gdb) lvmst

current VM state: C code (from interpreted Lua code)

(gdb) lbt

Python Exception <type 'exceptions.NameError'> global name 're' is not defined:

Error occurred in Python command: global name 're' is not defined

(gdb)

Not sure why I'm getting the Python exception at the end - maybe a path thing. Will try and look into it a bit later.

On Wed, Feb 19, 2014 at 12:20 AM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Tue, Feb 18, 2014 at 1:45 PM, Amnon David wrote:
> Here’s the entire process:

[...]

>
> $ luajit test.lua
> Segmentation fault: 11
>

Hmm. I cannot reproduce the crash on my Linux x86_64. Will try out my
macbook when I go back home.

> $ gdb luajit
>
[...]

> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000000685a2 in ?? ()
> (gdb) where
> #0 0x00000000000685a2 in ?? ()
> #1 0x00000000000650e0 in ?? ()
> #2 0x0000000000000002 in ?? ()

Hmm, this backtrace is not meaningful. Maybe you're just on compiled
Lua code which lacks unwinding info.

Can you reproduce the issue with the latest LuaJIT v2.1 branch? If
you're using the latest LuaJIT v2.1, you can also use my gdb extension
commands below to get more information (like LuaJIT VM state, and Lua
land backtraces) about the crash:

https://github.com/agentzh/nginx-gdb-utils

Regards,

-agentzh.

agentzh

Hello!

On Tue, Feb 18, 2014 at 9:28 PM, Amnon David wrote:
> (gdb) lvmst
> current VM state: C code (from interpreted Lua code)

Looks like it crashes in CFunction calls, very likely in mixlua's own
C code. This might be the reason why you did not get proper C
backtrace: your mixlua build does not have debuginfo enabled. Could
you try enabling debuginfo in your mixlua build?

> (gdb) lbt
> Python Exception <type 'exceptions.NameError'> global name 're' is not
> defined:
> Error occurred in Python command: global name 're' is not defined

This one is weird. I've attempted a fix for this in nginx-gdb-utils's
git master. Please try it out.

Also, put the line

    set python print-stack full

into your ~/.gdbinit file or just run it in your gdb session, such
that we can get complete Python backtrace for any Python errors in
gdb.

BTW, it is also a good idea to run the test under valgrind memcheck :)

Regards,
-agentzh

amnon.david

Looks like it crashes in CFunction calls, very likely in mixlua's own
C code. This might be the reason why you did not get proper C
backtrace: your mixlua build does not have debuginfo enabled. Could
you try enabling debuginfo in your mixlua build?

I've made sure to compile mixlua.so with debug information but unfortunately this does not seem to make any difference in the cryptic gdb stack trace dump.

This one is weird. I've attempted a fix for this in nginx-gdb-utils's
git master. Please try it out.

Adding 'import re' indeed fixed the issue - thanks.

Now I get:

> dofile "test.lua"

Program received signal SIGSEGV, Segmentation fault.

0x00000000000685a2 in ?? ()

(gdb) lvmst

current VM state: C code (from interpreted Lua code)

(gdb) lbt

C:0x63d20

C:lj_cf_package_require

@test.lua:3

builtin#25

=stdin:1

C:pmain

(gdb)

which doesn't really add much information since I already knew that the crash occurs when attempting to invoke the require("mixlua") call in test.lua

BTW, it is also a good idea to run the test under valgrind memcheck :)

$valgrind --tool=memcheck luajit-2.0/src/luajit
bad executable (__PAGEZERO is not 4 GB)
valgrind: luajit-2.0/src/luajit: cannot execute binary file

looking this up brings up: http://lua-users.org/lists/lua-l/2011-04/msg00682.html, which strengthens my suspicion that this is an OS/X related issue.

-Amnon

aapo.talvensaari

What do you guys think about Tor Hveem's tirtemplate.lua:
http://hveem.no/about

That is extracted from Tir (http://tir.mongrel2.org/). Doesn't look too bad to me.

Regards

Aapo

aapo.talvensaari

On Thursday, February 20, 2014 6:42:51 PM UTC+2, Aapo Talvensaari wrote:

What do you guys think about Tor Hveem's tirtemplate.lua:
http://hveem.no/about

The source is here:

https://github.com/torhve/LuaWeb/blob/master/tirtemplate.lua

And here is a nice example:

https://github.com/torhve/LuaWeb/blob/master/blog.html

That is called from here:

https://github.com/torhve/LuaWeb/blob/master/index.lua#L199

amnon.david

Looks nice. Judging by the setfenv call though, it is targeted for Lua 5.1 but that can be worked on

There are also other candidates I was looking at such as:

http://lua-users.org/wiki/SimpleLuaPreprocessor

http://lua-users.org/wiki/SlightlyLessSimpleLuaPreprocessor

On Thu, Feb 20, 2014 at 6:53 PM, Aapo Talvensaari <aapo.ta...@gmail.com> wrote:

On Thursday, February 20, 2014 6:42:51 PM UTC+2, Aapo Talvensaari wrote:
What do you guys think about Tor Hveem's tirtemplate.lua:
http://hveem.no/about

The source is here:
https://github.com/torhve/LuaWeb/blob/master/tirtemplate.lua

And here is a nice example:
https://github.com/torhve/LuaWeb/blob/master/blog.html

That is called from here:
https://github.com/torhve/LuaWeb/blob/master/index.lua#L199

.