[newbie question] How to create basic simple luvi app?

[Mateusz Czapliński]

I want to start building an app based on the luvi runtime, but I'm having
trouble wrapping my head around how to reference (require) various
fragments of the luvi/luvit ecosystem...

Specifically, I want to write an app which (among others) uses a forked
repl.lua "module" (with some patches).

For starters, I've tried to do it as follows:
1. downloaded luvi-regular-Windows-amd64.exe (and renamed to luvi.exe);
2. downloaded
https://github.com/luvit/luvit/blob/58fce31c1fd0bbeb53506a8848ca364dbdfc02de/deps/repl.lua
and saved it as 'repl.lua';
3. tried to create 'main.lua' as below:

local uv = require('uv')
local bundle = require('luvi').bundle
local utils = require('utils')

-- (Based on https:
//github.com/luvit/luvi/blob/master/samples/repl.app/main.lua)
-- Register some local Lua scripts as libraries
bundle.register("repl", "repl.lua")

local c = utils.color
local greeting = "Welcome to " ..c('err').. 'shiny' ..c().. " repl!"
require('repl')(utils.stdin, utils.stdout, greeting).start("", function()end
)

-- This blocks
uv.run()


4. Tried running it with luvi.exe, but getting error as below:

C:\prog\shiny2>luvi .
[string "bundle:main.lua"]:3: module 'utils' not found:
no field package.preload['utils']
no file 'c:\luarocks\2.2\lua\utils.lua'
no file 'c:\luarocks\2.2\lua\utils\init.lua'
no file 'c:\luarocks\share\lua\5.1\utils.lua'
no file 'c:\luarocks\share\lua\5.1\utils\init.lua'
no file 'c:\luarocks\lib\lua\5.1\utils.dll'

5. How should I resolve this?
6. Also, I'm confused about e.g. module "timer": on
https://luvit.io/api/timer.html, it seems mentioned one should use `local
timer = require('timer')`; but this doesn't work in my main.lua; instead,
the "hello world" example on https://github.com/luvit/luvi (it worked for
me) uses `uv.new_timer(...)`, that I don't even know where it's
documented... ?

halp, plz? I haz stuck :/ and can't really theorize wat the fancy should I
try next anymore :/

TIA
/M.

[Tim Caswell]

Sorry for not seeing this post. I should fix my email filters somehow to
make luvit posts show out.

So this is actually an area of active development. I recently ported lit's
entire code base to not depend on the luvit require module and instead use
a custom lua loader to give luvit-style path resolution to lua's native
require function.

So when making your own luvi app from scratch, you have two options:

1. Make sure that `deps/require.lua` contains the luvit/require package.
Luvi will see this and automatically take over lua's require system.
2. Use luvit-loader.lua as lit does.

In a luvi app, bootstrapping luvit-loader is fairly simple:

https://github.com/luvit/lit/blob/master/main.lua#L19-L20

Just make sure that luvit-loader is in the path you tell it to be at.

https://github.com/luvit/lit/blob/master/luvit-loader.lua


With either path, you'll need all your dependencies installed to the `deps`
folder in your luvi app. This can be done easily enough using the lit tool.

lit install creationix/weblit

Running that command in your luvi app will download weblit and all it's
dependencies and install them to `deps/*`. Then both luvit style require
systems can find them.

If you go the luvit-loader route (And I suggest this for any new app), then
you can also freely mix in luarocks packages, though this is probably a bad
idea for luvi based apps since you intend to eventually deploy them as a
single binary and those deps won't be included.

Note that luvit-loader works great with plain lua or luajit apps as well.
I'm currently working on a new service for my work that runs entirely with
luajit using luv from luarocks and everything else from lit installed to
deps.

See
https://github.com/virgo-agent-toolkit/super-agent/blob/30d1ef5789282b32ccb2a9604e12026f7e15366e/api/main.lua

Post by Mateusz Czapliński
I want to start building an app based on the luvi runtime, but I'm having
trouble wrapping my head around how to reference (require) various
fragments of the luvi/luvit ecosystem...
Specifically, I want to write an app which (among others) uses a forked
repl.lua "module" (with some patches).
1. downloaded luvi-regular-Windows-amd64.exe (and renamed to luvi.exe);
2. downloaded
https://github.com/luvit/luvit/blob/58fce31c1fd0bbeb53506a8848ca364dbdfc02de/deps/repl.lua
and saved it as 'repl.lua';
local uv = require('uv')
local bundle = require('luvi').bundle
local utils = require('utils')
-- (Based on https://
github.com/luvit/luvi/blob/master/samples/repl.app/main.lua)
-- Register some local Lua scripts as libraries
bundle.register("repl", "repl.lua")
local c = utils.color
local greeting = "Welcome to " ..c('err').. 'shiny' ..c().. " repl!"
require('repl')(utils.stdin, utils.stdout, greeting).start("", function()
end)
-- This blocks
uv.run()
C:\prog\shiny2>luvi .
no field package.preload['utils']
no file 'c:\luarocks\2.2\lua\utils.lua'
no file 'c:\luarocks\2.2\lua\utils\init.lua'
no file 'c:\luarocks\share\lua\5.1\utils.lua'
no file 'c:\luarocks\share\lua\5.1\utils\init.lua'
no file 'c:\luarocks\lib\lua\5.1\utils.dll'
5. How should I resolve this?
6. Also, I'm confused about e.g. module "timer": on
https://luvit.io/api/timer.html, it seems mentioned one should use `local
timer = require('timer')`; but this doesn't work in my main.lua; instead,
the "hello world" example on https://github.com/luvit/luvi (it worked for
me) uses `uv.new_timer(...)`, that I don't even know where it's
documented... ?
halp, plz? I haz stuck :/ and can't really theorize wat the fancy should I
try next anymore :/
TIA
/M.
--
You received this message because you are subscribed to the Google Groups "luvit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Mateusz Czaplinski]

Hi Tim!

Thanks for the reply. In the meantime, I thought I could maybe try
using the "luvit" app for initial prototyping, assuming it would have
all the kinds of modules built-in. And after a few more tries, it
finally worked for me!

Unfortunately, after some more prototyping, I stumbled into two new problems:

1. Firstly, I had an issue with the REPL on Windows, specifically with
wrapping of lines. When a chunk in REPL exceeded terminal width, the
readline wrapper started positioning the cursor wrongly, and
duplicating the first Iine on each keypress. It's hard to describe,
much easier to see, but I didn't try to put effort into recording it
yet, not sure if you'd care enough a fix it?

Also, while researching it, I found that node.js struggled with a
similar issue on Windows - the root cause seems to be different
behavior of Windows console APIs vs. Linux terminal APIs w.r.t.
overflowing lines, and requires an explicit switch on OS. I wasn't
motivated enough to analyze the luvit's readIine-wrapping code to find
out how it works (without comments) and how to fix it. I'd be happy to
try recording a video showing the problem and to find the github issue
# in node.js if you'd be willing to try fixing it.

2. Secondly, I found out that luvit/node.js API doesn't seem to handle
http cookies automatically, which was a problem for me.

The two problems listed above, taken together, were annoying enough
for me, that I scratched my project for now, so I'm not exploring
luvit more at the time being. That said, having the REPL fixed would
be very nice for me. With cookies I can try fighting then.

As to packaging and LuaRocks... it's another story for me. So, I love
the general idea of LuaRocks, but unfortunately I find them annoying
to work with on Windows (I mean especially the installer). That's
actually one of the things which led me to luvit - where you seemed to
execute it in a more
user-friendly way with lit (at least in my eyes). So, if you'd maybe consider
making a lit-like client for LuaRocks, that's something I'd personally
love. But just saying; do whatever you like, I'm absolutely not one of
the guys with demands :)

As a side-effect of my experiment, I've created a build script for
luvit.exe and lit.exe, which to me seems simpler than the instructions
on github - see:
https://gist.github.com/akavel/3e048ce47374f878afb3
This one makes use of the luvi's "self contained binaries creation"
feature, which is the second (or maybe even first?) major feature that
made luvi attractive to me initially.

So, that's my current situation, plus some feedback I thought I could
give you, thinking it might potentially be interesting to you.

Best Regards,
/Mateusz.

Post by Tim Caswell
Sorry for not seeing this post. I should fix my email filters somehow to
make luvit posts show out.
So this is actually an area of active development. I recently ported lit's
entire code base to not depend on the luvit require module and instead use a
custom lua loader to give luvit-style path resolution to lua's native
require function.
1. Make sure that `deps/require.lua` contains the luvit/require package.
Luvi will see this and automatically take over lua's require system.
2. Use luvit-loader.lua as lit does.
https://github.com/luvit/lit/blob/master/main.lua#L19-L20
Just make sure that luvit-loader is in the path you tell it to be at.
https://github.com/luvit/lit/blob/master/luvit-loader.lua
With either path, you'll need all your dependencies installed to the `deps`
folder in your luvi app. This can be done easily enough using the lit tool.
lit install creationix/weblit
Running that command in your luvi app will download weblit and all it's
dependencies and install them to `deps/*`. Then both luvit style require
systems can find them.
If you go the luvit-loader route (And I suggest this for any new app), then
you can also freely mix in luarocks packages, though this is probably a bad
idea for luvi based apps since you intend to eventually deploy them as a
single binary and those deps won't be included.
Note that luvit-loader works great with plain lua or luajit apps as well.
I'm currently working on a new service for my work that runs entirely with
luajit using luv from luarocks and everything else from lit installed to
deps.
See
https://github.com/virgo-agent-toolkit/super-agent/blob/30d1ef5789282b32ccb2a9604e12026f7e15366e/api/main.lua

Post by Mateusz Czapliński
I want to start building an app based on the luvi runtime, but I'm having
trouble wrapping my head around how to reference (require) various fragments
of the luvi/luvit ecosystem...
Specifically, I want to write an app which (among others) uses a forked
repl.lua "module" (with some patches).
1. downloaded luvi-regular-Windows-amd64.exe (and renamed to luvi.exe);
2. downloaded
https://github.com/luvit/luvit/blob/58fce31c1fd0bbeb53506a8848ca364dbdfc02de/deps/repl.lua
and saved it as 'repl.lua';
local uv = require('uv')
local bundle = require('luvi').bundle
local utils = require('utils')
-- (Based on
https://github.com/luvit/luvi/blob/master/samples/repl.app/main.lua)
-- Register some local Lua scripts as libraries
bundle.register("repl", "repl.lua")
local c = utils.color
local greeting = "Welcome to " ..c('err').. 'shiny' ..c().. " repl!"
require('repl')(utils.stdin, utils.stdout, greeting).start("",
function()end)
-- This blocks
uv.run()
C:\prog\shiny2>luvi .
no field package.preload['utils']
no file 'c:\luarocks\2.2\lua\utils.lua'
no file 'c:\luarocks\2.2\lua\utils\init.lua'
no file 'c:\luarocks\share\lua\5.1\utils.lua'
no file 'c:\luarocks\share\lua\5.1\utils\init.lua'
no file 'c:\luarocks\lib\lua\5.1\utils.dll'
5. How should I resolve this?
6. Also, I'm confused about e.g. module "timer": on
https://luvit.io/api/timer.html, it seems mentioned one should use `local
timer = require('timer')`; but this doesn't work in my main.lua; instead,
the "hello world" example on https://github.com/luvit/luvi (it worked for
me) uses `uv.new_timer(...)`, that I don't even know where it's
documented... ?
halp, plz? I haz stuck :/ and can't really theorize wat the fancy should I
try next anymore :/
TIA
/M.
--
You received this message because you are subscribed to the Google Groups "luvit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the
Google Groups "luvit" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/luvit/WpJLGMVEYfQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[Tim Caswell]

Post by Mateusz Czaplinski
Hi Tim!
Thanks for the reply. In the meantime, I thought I could maybe try
using the "luvit" app for initial prototyping, assuming it would have
all the kinds of modules built-in. And after a few more tries, it
finally worked for me!
1. Firstly, I had an issue with the REPL on Windows, specifically with
wrapping of lines. When a chunk in REPL exceeded terminal width, the
readline wrapper started positioning the cursor wrongly, and
duplicating the first Iine on each keypress. It's hard to describe,
much easier to see, but I didn't try to put effort into recording it
yet, not sure if you'd care enough a fix it?
Also, while researching it, I found that node.js struggled with a
similar issue on Windows - the root cause seems to be different
behavior of Windows console APIs vs. Linux terminal APIs w.r.t.
overflowing lines, and requires an explicit switch on OS. I wasn't
motivated enough to analyze the luvit's readIine-wrapping code to find
out how it works (without comments) and how to fix it. I'd be happy to
try recording a video showing the problem and to find the github issue
# in node.js if you'd be willing to try fixing it.

Yes this is a known issue. It actually happens on unix too. The work
needed is simply more implementation in the readline module. I can go
through and add comments and mentor someone who has time to see what
features we're missing from node's repl implementation and add them here.

Post by Mateusz Czaplinski
2. Secondly, I found out that luvit/node.js API doesn't seem to handle
http cookies automatically, which was a problem for me.

Correct, node.js doesn't handle cookies either. Since the built-in modules
in luvit are a mirror of the node.js APIs, it preserves this non-goal.

That said, I don't think http should be in core at all for reasons just
like this. You have to draw the line somewhere and no matter where you
draw it, someone will feel it should be a little farther. Instead we
should just have one or more good HTTP libraries published to lit where
they can be maintained apart from luvit core. In the node.js ecosystem
most people use something like Mikeal's request library. I use the coro-*
flavor of libraries in my luvit apps though my http client in coro-http
doesn't have cookie handling yet (and weblit my http server framework
doesn't have them yet either.) It would be pretty easy to add basic cookie
handling to either I'd think.

Post by Mateusz Czaplinski
The two problems listed above, taken together, were annoying enough
for me, that I scratched my project for now, so I'm not exploring
luvit more at the time being. That said, having the REPL fixed would
be very nice for me. With cookies I can try fighting then.
As to packaging and LuaRocks... it's another story for me. So, I love
the general idea of LuaRocks, but unfortunately I find them annoying
to work with on Windows (I mean especially the installer). That's
actually one of the things which led me to luvit - where you seemed to
execute it in a more
user-friendly way with lit (at least in my eyes). So, if you'd maybe consider
making a lit-like client for LuaRocks, that's something I'd personally
love. But just saying; do whatever you like, I'm absolutely not one of
the guys with demands :)

This could probably be done. Just publish the client to lit and make sure
to include the luvi field in package.lua so it can be built as an app. I
don't know if I should be the one to implement and maintain this. I'm
already stretched so thin, I can't properly maintain all I've got already.
But yes, something that implements a subset of luarocks' features and is
installable through lit make would be neat.

Post by Mateusz Czaplinski
As a side-effect of my experiment, I've created a build script for
luvit.exe and lit.exe, which to me seems simpler than the instructions
https://gist.github.com/akavel/3e048ce47374f878afb3
This one makes use of the luvi's "self contained binaries creation"
feature, which is the second (or maybe even first?) major feature that
made luvi attractive to me initially.

Neat script, I have a couple suggestions:

- Make sure to do a recursive clone of the lit repository. It has at
least one dependency that's in a git submodule. Actually, it would be
better if you could somehow download the zip at
https://lit.luvit.io/packages/luvit/lit/latest.zip since that is the latest
published version with all dependencies included. I understand using
"bare" windows to download stuff is hard. Perhaps I could add something to
luvi to help this bootstrap since it has libuv and can easily download
stuff.

- Once you have lit, there is no reason to clone things, simply use the
make command. So for example, to build luvit, you would do:

lit make lit://luvit/luvit

And it will build `luvit.exe` in the current directory. (Though for luvit
in particular, you can simply do `lit update` and it will update luvit or
build it if it doesn't exist)

Post by Mateusz Czaplinski
So, that's my current situation, plus some feedback I thought I could
give you, thinking it might potentially be interesting to you.

Thanks!

Post by Mateusz Czaplinski
Best Regards,
/Mateusz.

Post by Tim Caswell
Sorry for not seeing this post. I should fix my email filters somehow to
make luvit posts show out.
So this is actually an area of active development. I recently ported

lit's

Post by Tim Caswell
entire code base to not depend on the luvit require module and instead

use a

Post by Tim Caswell
custom lua loader to give luvit-style path resolution to lua's native
require function.
1. Make sure that `deps/require.lua` contains the luvit/require package.
Luvi will see this and automatically take over lua's require system.
2. Use luvit-loader.lua as lit does.
https://github.com/luvit/lit/blob/master/main.lua#L19-L20
Just make sure that luvit-loader is in the path you tell it to be at.
https://github.com/luvit/lit/blob/master/luvit-loader.lua
With either path, you'll need all your dependencies installed to the

`deps`

Post by Tim Caswell
folder in your luvi app. This can be done easily enough using the lit

tool.

Post by Tim Caswell
lit install creationix/weblit
Running that command in your luvi app will download weblit and all it's
dependencies and install them to `deps/*`. Then both luvit style require
systems can find them.
If you go the luvit-loader route (And I suggest this for any new app),

then

Post by Tim Caswell
you can also freely mix in luarocks packages, though this is probably a

bad

Post by Tim Caswell
idea for luvi based apps since you intend to eventually deploy them as a
single binary and those deps won't be included.
Note that luvit-loader works great with plain lua or luajit apps as well.
I'm currently working on a new service for my work that runs entirely

with

Post by Tim Caswell
luajit using luv from luarocks and everything else from lit installed to
deps.
See

https://github.com/virgo-agent-toolkit/super-agent/blob/30d1ef5789282b32ccb2a9604e12026f7e15366e/api/main.lua

Post by Tim Caswell

Post by Mateusz Czapliński
I want to start building an app based on the luvi runtime, but I'm

having

Post by Tim Caswell

Post by Mateusz Czapliński
trouble wrapping my head around how to reference (require) various

fragments

Post by Tim Caswell

Post by Mateusz Czapliński
of the luvi/luvit ecosystem...
Specifically, I want to write an app which (among others) uses a forked
repl.lua "module" (with some patches).
1. downloaded luvi-regular-Windows-amd64.exe (and renamed to luvi.exe);
2. downloaded

https://github.com/luvit/luvit/blob/58fce31c1fd0bbeb53506a8848ca364dbdfc02de/deps/repl.lua

Post by Tim Caswell

Post by Mateusz Czapliński
and saved it as 'repl.lua';
local uv = require('uv')
local bundle = require('luvi').bundle
local utils = require('utils')
-- (Based on
https://github.com/luvit/luvi/blob/master/samples/repl.app/main.lua)
-- Register some local Lua scripts as libraries
bundle.register("repl", "repl.lua")
local c = utils.color
local greeting = "Welcome to " ..c('err').. 'shiny' ..c().. " repl!"
require('repl')(utils.stdin, utils.stdout, greeting).start("",
function()end)
-- This blocks
uv.run()
C:\prog\shiny2>luvi .
no field package.preload['utils']
no file 'c:\luarocks\2.2\lua\utils.lua'
no file 'c:\luarocks\2.2\lua\utils\init.lua'
no file 'c:\luarocks\share\lua\5.1\utils.lua'
no file 'c:\luarocks\share\lua\5.1\utils\init.lua'
no file 'c:\luarocks\lib\lua\5.1\utils.dll'
5. How should I resolve this?
6. Also, I'm confused about e.g. module "timer": on
https://luvit.io/api/timer.html, it seems mentioned one should use

`local

Post by Tim Caswell

Post by Mateusz Czapliński
timer = require('timer')`; but this doesn't work in my main.lua;

instead,

Post by Tim Caswell

Post by Mateusz Czapliński
the "hello world" example on https://github.com/luvit/luvi (it worked

for

Post by Tim Caswell

Post by Mateusz Czapliński
me) uses `uv.new_timer(...)`, that I don't even know where it's
documented... ?
halp, plz? I haz stuck :/ and can't really theorize wat the fancy

should I

Post by Tim Caswell

Post by Mateusz Czapliński
try next anymore :/
TIA
/M.
--
You received this message because you are subscribed to the Google

Groups

Post by Tim Caswell

Post by Mateusz Czapliński
"luvit" group.
To unsubscribe from this group and stop receiving emails from it, send

an

Post by Tim Caswell

Post by Mateusz Czapliński
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the
Google Groups "luvit" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/luvit/WpJLGMVEYfQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "luvit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.