

this change:

$ git diff

diff --git a/Makefile b/Makefile

index 66c83f6..76e447f 100644

--- a/Makefile

+++ b/Makefile

@@ -80,14 +80,18 @@ ${LUADIR}/src/libluajit.a:

mv deps/luajit/src/Makefile2 deps/luajit/src/Makefile

# By default luajit builds a dll on Windows. Override this.

if [ "${PLATFORM}" == "windows" ]; then \

- sed -e "s/#BUILDMODE= static/BUILDMODE= static/" -i deps/luajit/src/M

- sed -e "s/BUILDMODE= mixed/#BUILDMODE= mixed/" -i deps/luajit/src/Mak

+ $(MAKE) -C ${LUADIR} BUILDMODE=static ; \

+ else \

+ $(MAKE) -C ${LUADIR} ;\

fi

- $(MAKE) -C ${LUADIR}



${UVDIR}/uv.a:

git submodule update --init ${UVDIR}

- $(MAKE) -C ${UVDIR} uv.a

+ if [ "${PLATFORM}" == "windows" ]; then \

+ $(MAKE) -C ${UVDIR} uv.a uname_S=MINGW ; \

+ else \

+ $(MAKE) -C ${UVDIR} uv.a ; \

+ fi



${HTTPDIR}/http_parser.o:

git submodule update --init ${HTTPDIR}

diff --git a/deps/luajit b/deps/luajit

--- a/deps/luajit

+++ b/deps/luajit

@@ -1 +1 @@

-Subproject commit e162d8cef0d1d62e3c43c23a6b28ebed68fdf7a0

+Subproject commit e162d8cef0d1d62e3c43c23a6b28ebed68fdf7a0-dirty



SW@WXT410 /D/Work/Sources/luvit (ports)

$



makefile is okay, why use gyp? gyp requires Python, it's big.





2011/12/2 Tim Caswell <

> Yes, it will build on windows and osx. I'm still working on getting

> the build flags right. Bert has it working somewhat with mingw and

> his patch is in the ports branch.

> Eventually luvit will use gyp the same as nodejs, libuv, and http_parser.

>

> On Thu, Dec 1, 2011 at 9:40 PM, Xavier Wang <

>> 2011/12/1 Tim Caswell <

>>> I've been holding off announcing my project on this list for some time

>>> since it's not 1.0 yet, but now I realise that won't happen any time

>>> soon.

>>>

>>> I'm proud to announce my latest hack, Luvit

>>> <

>>> is basically luajit2 + libuv (the event loop library behind nodejs).

>>> It compiles as a single executable just like nodejs and can run .lua

>>> files. What makes it different from the stock luajit distribution is

>>> it has several built-in modules added and some slightly different

>>> semantics.

>>>

>>> If you're familiar with nodejs, it's quite similar. If not, the basic

>>> idea is you have a single threaded event loop that never blocks on I/O

>>> wait. This enables you to write high-performance network programs

>>> using a simple callback based programming style. Since lua, the

>>> language has native co-routines, you can also use those instead of

>>> callbacks if that's your preference. Luvit supports both.

>>>

>>> I changed some lua semantics slightly to make modules make sense. For

>>> example, require search paths work like in node. This means that you

>>> can do relative requires to the file that's doing the requiring.

>>> There is no user-modifiable search path, and normal requires search

>>> for bundled modules starting at the caller and going up the filesystem

>>> tree. (./modules, ../modules, ../../modules, etc) All modules (binary

>>> included) must return a table that is their value. Modules are not to

>>> pollute the global environment by putting stuff there. Also the lua

>>> io module is disabled since it is not compatible with the non-blocking

>>> architecture.

>>>

>>> Enough of the incompatibilities, now for the abilities!

>>>

>>> - HTTP server and client

>>> - TCP server and client

>>> - All sorts of filesystem operations

>>> - Some UDP support

>>> - PIPE streams

>>> - TTY streams

>>> - Timers and intervale

>>> - Robust and portable module system that encourages sane dependencies

>>>

>>> To write a simple http hello-world server, you simply have to write

>>> the following lua script:

>>>

>>> local HTTP = require("http")

>>> local Utils = require("utils")

>>>

>>> HTTP.create_server("0.0.0.0", 8080, function (req, res)

>>> local body = Utils.dump({req=req,headers=req.headers}) .. "

"

>>> res:write_head(200, {

>>> ["Content-Type"] = "text/plain",

>>> ["Content-Length"] = #body

>>> })

>>> res:finish(body)

>>> end)

>>>

>>> print("Server listening at

>>>

>>> This is the response given when hitting with curl:

>>>

>>> <

>>>

>>> Notice that we're not running as a CGI script to apache or anything

>>> like that. The lua script *is* the http server. You get your

>>> callback called every time an http request is made to the server. See

>>> more examples in the github repo

>>> <

>>>

>>> I won't waste everyone's time describing the type of system I'm trying

>>> to build. It's explained well in this recent blog post about node

>>>

>>>

>>> Luvit has a nice colorized repo that is imho much easier to use than

>>> the stock one in lua. Return values are automatically shown

>>> (including nil values). The p() function is like print, but pretty

>>> prints data as seen in this debug dump of an http server.

>>> <

>>>

>>> Luvit is complete enough for many classes of applications. It's not

>>> as finished as I'd like and since it's just a hobby I haven't had much

>>> time to work on it in the last month. I encourage people to play with

>>> it and see if they like it. If there is interest then I can make time

>>> to continue working on it.

>>>

>>> -Tim Caswell

>>>

>>>

>>>

>>>

>>>

>>

>> Hi Tim,

>>

>> My question is, does luvit can build on Windows? On Windows libuv use

>> a complete different way to implement callback (use iocp on Windows

>> other than epoll on Linux), so libuv will have no libev on Windows, I

>> just get this link error:

>>

>> build/lenv.o:lenv.c:(.text+0x221): undefined reference to `setenv'

>> build/lenv.o:lenv.c:(.text+0x270): undefined reference to `unsetenv'

>> build/luv.o:luv.c:(.text+0x4): undefined reference to `ev_default_loop_ptr'

>> build/luv.o:luv.c:(.text+0x31): undefined reference to `ev_run'

>> build/luv.o:luv.c:(.text+0x4b): undefined reference to `ev_break'

>> build/luv.o:luv.c:(.text+0x5f): undefined reference to `ev_default_loop'

>> build/luv.o:luv.c:(.text+0x67): undefined reference to `ev_loop_destroy'

>> build/luv.o:luv.c:(.text+0x7b): undefined reference to `ev_default_loop'

>> build/luv.o:luv.c:(.text+0x83): undefined reference to `ev_loop_fork'

>> build/luv.o:luv.c:(.text+0x96): undefined reference to `ev_iteration'

>> build/luv.o:luv.c:(.text+0xa9): undefined reference to `ev_depth'

>> build/luv.o:luv.c:(.text+0xbc): undefined reference to `ev_verify'

>> collect2: ld returned 1 exit status

>> make: *** [build/luvit] Error 1

>>

>> the first two means MinGW on Windows missing setenv/unsetenv function,

>> and others are ev functions.

>>

>> Does luvit planed to support Windows?

>>

>>

> > Yes, it will build on windows and osx. I'm still working on getting> the build flags right. Bert has it working somewhat with mingw and> his patch is in the ports branch. http://twitpic.com/7mr1zn > Eventually luvit will use gyp the same as nodejs, libuv, and http_parser.> On Thu, Dec 1, 2011 at 9:40 PM, Xavier Wang < [hidden email] > wrote:>> 2011/12/1 Tim Caswell < [hidden email] >:>>> I've been holding off announcing my project on this list for some time>>> since it's not 1.0 yet, but now I realise that won't happen any time>>> soon.>>>>>> I'm proud to announce my latest hack, Luvit>>> < https://github.com/luvit/luvit >. As described in the subject, this>>> is basically luajit2 + libuv (the event loop library behind nodejs).>>> It compiles as a single executable just like nodejs and can run .lua>>> files. What makes it different from the stock luajit distribution is>>> it has several built-in modules added and some slightly different>>> semantics.>>>>>> If you're familiar with nodejs, it's quite similar. If not, the basic>>> idea is you have a single threaded event loop that never blocks on I/O>>> wait. This enables you to write high-performance network programs>>> using a simple callback based programming style. Since lua, the>>> language has native co-routines, you can also use those instead of>>> callbacks if that's your preference. Luvit supports both.>>>>>> I changed some lua semantics slightly to make modules make sense. For>>> example, require search paths work like in node. This means that you>>> can do relative requires to the file that's doing the requiring.>>> There is no user-modifiable search path, and normal requires search>>> for bundled modules starting at the caller and going up the filesystem>>> tree. (./modules, ../modules, ../../modules, etc) All modules (binary>>> included) must return a table that is their value. Modules are not to>>> pollute the global environment by putting stuff there. Also the lua>>> io module is disabled since it is not compatible with the non-blocking>>> architecture.>>>>>> Enough of the incompatibilities, now for the abilities!>>>>>> - HTTP server and client>>> - TCP server and client>>> - All sorts of filesystem operations>>> - Some UDP support>>> - PIPE streams>>> - TTY streams>>> - Timers and intervale>>> - Robust and portable module system that encourages sane dependencies>>>>>> To write a simple http hello-world server, you simply have to write>>> the following lua script:>>>>>> local HTTP = require("http")>>> local Utils = require("utils")>>>>>> HTTP.create_server("0.0.0.0", 8080, function (req, res)>>> local body = Utils.dump({req=req,headers=req.headers}) .. "

">>> res:write_head(200, {>>> ["Content-Type"] = "text/plain",>>> ["Content-Length"] = #body>>> })>>> res:finish(body)>>> end)>>>>>> print("Server listening at http://localhost:8080/ ")>>>>>> This is the response given when hitting with curl:>>>>>> < http://creationix.com/luvitresponse.png >>>>>> Notice that we're not running as a CGI script to apache or anything>>> like that. The lua script *is* the http server. You get your>>> callback called every time an http request is made to the server. See>>> more examples in the github repo>>> < https://github.com/luvit/luvit/tree/master/examples >>>>>> I won't waste everyone's time describing the type of system I'm trying>>> to build. It's explained well in this recent blog post about node>>> http://substack.net/posts/b96642 >>>>>> Luvit has a nice colorized repo that is imho much easier to use than>>> the stock one in lua. Return values are automatically shown>>> (including nil values). The p() function is like print, but pretty>>> prints data as seen in this debug dump of an http server.>>> < http://creationix.com/luvit2.png >>>>>> Luvit is complete enough for many classes of applications. It's not>>> as finished as I'd like and since it's just a hobby I haven't had much>>> time to work on it in the last month. I encourage people to play with>>> it and see if they like it. If there is interest then I can make time>>> to continue working on it.>>>>>> -Tim Caswell>>>>>> http://howtonode.org/ >>> http://github.com/creationix >>> http://twitter.com/creationix >>>>>>> Hi Tim,>>>> My question is, does luvit can build on Windows? On Windows libuv use>> a complete different way to implement callback (use iocp on Windows>> other than epoll on Linux), so libuv will have no libev on Windows, I>> just get this link error:>>>> build/lenv.o:lenv.c:(.text+0x221): undefined reference to `setenv'>> build/lenv.o:lenv.c:(.text+0x270): undefined reference to `unsetenv'>> build/luv.o:luv.c:(.text+0x4): undefined reference to `ev_default_loop_ptr'>> build/luv.o:luv.c:(.text+0x31): undefined reference to `ev_run'>> build/luv.o:luv.c:(.text+0x4b): undefined reference to `ev_break'>> build/luv.o:luv.c:(.text+0x5f): undefined reference to `ev_default_loop'>> build/luv.o:luv.c:(.text+0x67): undefined reference to `ev_loop_destroy'>> build/luv.o:luv.c:(.text+0x7b): undefined reference to `ev_default_loop'>> build/luv.o:luv.c:(.text+0x83): undefined reference to `ev_loop_fork'>> build/luv.o:luv.c:(.text+0x96): undefined reference to `ev_iteration'>> build/luv.o:luv.c:(.text+0xa9): undefined reference to `ev_depth'>> build/luv.o:luv.c:(.text+0xbc): undefined reference to `ev_verify'>> collect2: ld returned 1 exit status>> make: *** [build/luvit] Error 1>>>> the first two means MinGW on Windows missing setenv/unsetenv function,>> and others are ev functions.>>>> Does luvit planed to support Windows?>>>>

I just build luvit successfully on Window, on ports branch, and withthis change:$ git diffdiff --git a/Makefile b/Makefileindex 66c83f6..76e447f 100644--- a/Makefile+++ b/Makefile@@ -80,14 +80,18 @@ ${LUADIR}/src/libluajit.a:mv deps/luajit/src/Makefile2 deps/luajit/src/Makefile# By default luajit builds a dll on Windows. Override this.if [ "${PLATFORM}" == "windows" ]; then \- sed -e "s/#BUILDMODE= static/BUILDMODE= static/" -i deps/luajit/src/M- sed -e "s/BUILDMODE= mixed/#BUILDMODE= mixed/" -i deps/luajit/src/Mak+ $(MAKE) -C ${LUADIR} BUILDMODE=static ; \+ else \+ $(MAKE) -C ${LUADIR} ;\fi- $(MAKE) -C ${LUADIR}${UVDIR}/uv.a:git submodule update --init ${UVDIR}- $(MAKE) -C ${UVDIR} uv.a+ if [ "${PLATFORM}" == "windows" ]; then \+ $(MAKE) -C ${UVDIR} uv.a uname_S=MINGW ; \+ else \+ $(MAKE) -C ${UVDIR} uv.a ; \+ fi${HTTPDIR}/http_parser.o:git submodule update --init ${HTTPDIR}diff --git a/deps/luajit b/deps/luajit--- a/deps/luajit+++ b/deps/luajit@@ -1 +1 @@-Subproject commit e162d8cef0d1d62e3c43c23a6b28ebed68fdf7a0+Subproject commit e162d8cef0d1d62e3c43c23a6b28ebed68fdf7a0-dirtySW@WXT410 /D/Work/Sources/luvit (ports)makefile is okay, why use gyp? gyp requires Python, it's big.2011/12/2 Tim Caswell < [hidden email] >: