[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

--
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 email to luvit+un...@googlegroups.com.
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.

> 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

[Tim Caswell]

On Thu, Feb 25, 2016 at 1:34 PM, Mateusz Czaplinski <czap...@gmail.com> wrote:

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.

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.

 

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.

 

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.

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.

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)

 

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

Thanks!