API Changes

loop:run method now takes an optional param mode, which defauls to RUN_DEFAULT and can be:

• RUN_ONCE
• RUN_DEFAULT
• RUN_NOWAIT

Implementation

• Use recent libuv and c-ares as external submodule.
• Signal handling changed to new uv_signal_ API.

Issues

This is no new issue, but the Signals registered are never unregistered. Thus there is a memory leek. Since the ev_signals are now part of uv_signal_, they are automatically registered. For the moment they are uv_unref ed to let the loop exit.

The idea of releasing a new major version of luvit with breaking changes to fix outstanding issues or to address some of its shortcomings comes up occasionally. We recently chatted again about this in Discord. I think it would be good to have a place here for people to share any thoughts on the subject.

I will share my ideas in an independent post below this one. Please do not hesitate to share your own. Thanks.

json.stringify({}) return an empty array instead of an emtpy table:

test-json.lua:

local JSON = require ("json")
print(JSON.stringify({}))

Output:

$ luvit test-json.lua
[]

Node.js returns an empty array for:

console.log(JSON.stringify({}))

Output:

$ node test-json.js
{}

Looking at json.lua https://github.com/luvit/luvit/blob/master/deps/json.lua#L308 sets isa as true and n as 0. The test in the next line fails, because valmeta = getmetable({}) is false.

What can we do about it?

I noticed in the documentation it shows that threads accept a second argument. I looked at the source and noticed it has no limit on arguments.

The second argument should also be allowed to pass arguments to the function, to allow something like this:

local function test(arg1,arg2)
    return arg`1 + arg2
end

thread.start(function_name, arg1, arg2)

Of course the first portion of this issue is a must for me as I require that arguments be passed to the function. Either arguments, a table with arguments, or a metatable to allow for custom environments for the function in the thread to allow further customization would be amazing.

Also a great possibility is that the thread, if taking too long or stalls completely, gives the ability to be terminated. This is especially great for what I plan on using luvit for.

Building Luvit with the latest released version of Luvi (2.9.1) has some issues that need to be resolved. This is not a complete list, just some things I'm aware of:

• [x] test-crypto.lua:42: bad argument #1 to 'export' (only accept 'pem','der' or none). Seems to be related to lua-openssl binding/updated openssl version.
• [x] [Windows only?] test-process.lua: Missing 1 expected call for both child process no stdin and child process (no stdin, no stderr, stdout) with close
• [x] https://github.com/luvit/luvit/pull/944#issuecomment-469864902 and subsequent comments
• [x] (perhaps related to above) [Linux only?] test-process.lua: 1 unclosed handle in invalid command and Missing 1 expected call in invalid command verify exit callback
• [x] [Windows only?] test-tls-remote.lua:33: assertion failed! (err = ssl); err comes from local ret, err = self.ssl:handshake() in tls/common.lua:364. Similar failures in other tls tests
• [x] test-process-exec.lua from #1075

All the broken stuff seems to be related to either libuv spawn or openssl.

Changes between Luvi 2.7.6 and 2.9.1:

• luvi: https://github.com/luvit/luvi/compare/v2.7.6...v2.9.1
• luv v1.9.1-1 -> v1.25.0-0: https://github.com/luvit/luv/compare/1.9.1-1...1.25.0-0
• openssl 1.0.2h -> 1.1.0i
• lua-openssl 6e96296 -> 0.7.4: https://github.com/zhaozg/lua-openssl/compare/6e96296ba41f893a3821528cc46d0c406374df51...0.7.4

https://github.com/websockets/ws is a WebSocket client and server for Node.js

const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', function connection(ws) {
  ws.on('message', function incoming(message) {
    console.log('received: %s', message);
  });

  ws.send('something');
});

Broadcast example

const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 8080 });

// Broadcast to all.
wss.broadcast = function broadcast(data) {
  wss.clients.forEach(function each(client) {
    if (client.readyState === WebSocket.OPEN) {
      client.send(data);
    }
  });
};

wss.on('connection', function connection(ws) {
  ws.on('message', function incoming(data) {
    // Broadcast to everyone else.
    wss.clients.forEach(function each(client) {
      if (client !== ws && client.readyState === WebSocket.OPEN) {
        client.send(data);
      }
    });
  });
});

Since commit 7cab2d9a6d673915a3d4ff0b4956d05fa8c75b5c the test signal usr1,usr2,hup fails on my Arch Linux system:

# Starting Test: signal usr1,usr2,hup
  /home/joerg/Development/git/luvit/tests/libs/tap.lua:83: Missing 3 expected calls
  stack traceback:
  	[C]: in function 'error'
  	/home/joerg/Development/git/luvit/tests/libs/tap.lua:83: in function </home/joerg/Development/git/luvit/tests/libs/tap.lua:64>
  	[C]: in function 'xpcall'
  	/home/joerg/Development/git/luvit/tests/libs/tap.lua:64: in function 'run'
  	/home/joerg/Development/git/luvit/tests/libs/tap.lua:165: in function </home/joerg/Development/git/luvit/tests/libs/tap.lua:142>
  	/home/joerg/Development/git/luvit/tests/test-process.lua:6: in function 'fn'
  	[string "bundle:deps/require.lua"]:310: in function 'require'
  	/home/joerg/Development/git/luvit/main.lua:118: in function 'main'
  	/home/joerg/Development/git/luvit/init.lua:49: in function </home/joerg/Development/git/luvit/init.lua:47>
  	[C]: in function 'xpcall'
  	/home/joerg/Development/git/luvit/init.lua:47: in function 'fn'
  	[string "bundle:deps/require.lua"]:310: in function <[string "bundle:deps/require.lua"]:266>
not ok 3 signal usr1,usr2,hup

Edit: Tested with lates luvi:

$ luvi --version
luvi v2.11.0
rex: 8.37 2015-04-28
libuv: 1.34.2
ssl: OpenSSL 1.1.1d  10 Sep 2019, lua-openssl 0.7.7

$ cd luvit
$ luvi . -- tests/test-process.lua

There's the test code

local Emitter = require('core').Emitter
local i= 0
local Client = Emitter:extend()
function Client:initialize()
  self:on('Method1', function ()
            print('Method1 -- '..i)
            i = i + 1
  end)
end
function Client:start()
while true do
  self:emit('Method1')
end -- END while
end
local x = Client:new()
x:start()

and output stucked like this:

Method1 -- 0
Method1 -- 1
Method1 -- 2
Method1 -- 3
...
Method1 -- 954
Method1 -- 955
Method1 -- 956
Metho

It's stuck the last line. I test this because my server been stucked when I want print some log .

Is someone can help?

Hello, I'm here today to report an issue that has been happening to a lot of users so many times and I don't find a solution to it.

Using coro-http module, depends on what sites (all of them are HTTPS) we receive that error above, "Peer Aborted the SSL Handshake". As it is obvious, we switched to https module to see if this could fix it, but sadly, it didn't.

I don't bring any actual code example because it is just a simple GET request. This is the url i've been having problems with:

https://elosuite.com/loader_files/db.php

Seems like a luvit problem.

Hi, I am new to lua & luvit. Please help with the below issue. The main execution sequence does not wait for getVersion() to complete.

--global variable. version = nil print('Before fn call') getVersion() if(version == '1.2') then --do something else -- do something else end print('version=' .. version) print('Done')

local function getVersion() print('Inside getVersion') .... .... local req = http.request(options, function (res) print("Inside request") res:on('data', function (data) ---get the version and assign to global variable version. print('version:' .. version) end) print('After the execution') end) req:done() end

Below is the console output when I run the same.

Before fn call Inside getVersion version=nil Done Inside request version:1.2 After the execution

I want to make sure the getVersion fn is completed before continuing with the main thread. I tried a method fiber.wait(fn()), but did not workout. Is this the right method, or do we have any other way to get it done.

Any help regarding the same is much appreciated.

Thanks & regards, Joe

Adds luvit/http-header package containing:

• headerMeta (moved from http)
• newHeaders() (returns a new table with headerMeta as its metatable)
• toHeaders(tbl) (converts a table of header values into a table with headerMeta as its metatable)
• combineHeaders(...) (converts and combines tables into a single table with headerMeta as its metatable)
• getHeaders(tbl) (extracts headers from the array-like portion of tbl into a new table with headerMeta as its metatable)

See the comments in http-header.lua for slightly more info on each function.

Rationale:

http.headerMeta can be useful outside of the Luvit http package. For example, it (along with the added utility functions) could be used with coro-http like so:

local http = require('coro-http')
local httpHeader = require('http-header')

local headers = httpHeader.newHeaders()
headers['accept'] = 'application/json'

local res, body = http.request('GET', 'https://lit.luvit.io', headers)

local resHeaders = httpHeader.getHeaders(res)
assert(resHeaders['content-type'] == 'application/json')

Notes

• Let me know if you'd like any changes to the name of the package, the names of the functions, and/or any of the comments--I definitely think they can be improved.

Some synchronous functions in fs do not check for errors properly, e.g consider this portion of fs.readdirSync

function fs.readdirSync(path)
  local req = uv.fs_scandir(path)
  local files = {}
  local i = 1
  while true do
    local ent = uv.fs_scandir_next(req)

It did not consider the possibility of uv.fs_scandir returning a nil, err and ends up passing nil to the next uv call instead of propagating the error to the user.

This leads to confusing errors like the following when a filepath does not exist:

> fs.readdirSync("aksnsjwjsjs")
[string "bundle:/deps/fs.lua"]:205: bad argument #1 to 'fs_scandir_next' (uv_req expected, got nil)
stack traceback:
        [C]: in function 'fs_scandir_next'
        [string "bundle:/deps/fs.lua"]:205: in function <[string "bundle:/deps/fs.lua"]:200>
        [C]: in function 'xpcall'
        [string "bundle:/deps/repl.lua"]:97: in function 'evaluateLine'
        [string "bundle:/deps/repl.lua"]:189: in function <[string "bundle:/deps/repl.lua"]:187>
>

It should instead report the error as an ENOENT from our side instead of a stacktrace coming from luvit's source.

Okay, so, on the website's "install" page, it states that to download luvit, you run: curl -L https://github.com/luvit/lit/raw/master/get-lit.sh | sh upon doing this, it does its thing for a moment, and then i get hit with "curl: (22) The requested URL returned error: 404". I am a command line newbie, so go easy on me.

also, i tried to install luvit via homebrew - idk if that's recommended or not - but it returned a whole buncha errors.

I'm curious if there's any interest in supporting unix domain sockets as well as network sockets. It could look something like

http.createServer(function(req, res)
...
end):listen("/tmp/luvit.socket")

There's an advantage in being easier to use with a server like nginx to forward requests, is less likely to conflict, can't be accessed on a network, which has fewer security problems and quirks, and is more descriptive and memorable than a random TCP socket number. On unix-like systems TCP/domain sockets just end up as file descriptors with all the standard system calls, so theoretically it should be really easy to implement, and it's standard lib stuff so no bloat

This is supported by Node and Express already in this exact same way

Starts a UNIX socket and listens for connections on the given path. This method is identical to Node’s http.Server.listen().

var express = require('express')
var app = express()
app.listen('/tmp/sock')

When using a structure as following: src/ main.lua

Then running luvit on src/main.lua where we create a module for "Test" using the generator, any following require just causes an infinite loop to occur.
Example main.lua:

local generator = require('require')   
local myRequire, myModule = generator("Test")   
myRequire("file1")

Looking into it, it seems that require.lua:190 tries to step up one level in the directory-hierarchy, while base path is an empty string, which results in the same empty path string.

-- Otherwise, keep going higher   
base = pathJoin(base, "..")

I guess this case should be accounted for explicitly

I'm opening this issue as a reminder to myself to write some sort of table or list that shows past luvit versions and their corresponding luvi/luv/luajit versions. Just as a matter of record keeping. I don't know where to put it. I guess a simple markdown file would do. Maybe it can be put somewhere on the website later.