• Alonso Hermosilla

    Sorry for pushing this thread, but I had a suggestion which would be quite handy if it was implemented on mgit.

    mgit compiling Lua code into a dynamic libraries.

    I believe there are several ways to implement this; pushing the Lua functions being exposed into some library, expose them as FFI callbacks, looking up for the functions on the global environment, etc. And having a automatic wrapper which tell what functions are allowed to be exported.

    The result may come into a slow implementation but at least there's the possibility to rely on being able to actually develop alternative dynamic libraries for software that doesn't support Lua or LuaJIT, which is much more simple than compiling code on some older low level programming languages (C/C++).

    posted in General Discussion read more
  • Alonso Hermosilla

    So I'm trying to create a simple button but I'm getting a error.

    Error: winapi/button.lua:175: non-zero expected, got zero
    stack traceback:
            [C]: in function 'error'
            winapi/util.lua:102: in function 'checknz'
            winapi/button.lua:175: in function 'Button_SetTextMargin'
            winapi/buttonclass.lua:52: in function <winapi/buttonclass.lua:48>
            winapi/vobject.lua:39: in function '__set_vproperty'
            winapi/vobject.lua:23: in function '__newindex'
            winapi/basewindowclass.lua:418: in function '__init'
            winapi/controlclass.lua:49: in function '__init'
            winapi/object.lua:32: in function 'Button'
            main.lua:14: in function 'load'
            [string "boot.lua"]:439: in function <[string "boot.lua"]:435>
            [C]: in function 'xpcall'

    This is the code I used.

    local winapi = require("winapi")
    function love.load()
        local Window = winapi.Window {
            title = "löve compiler",
            autoquit = true,
            visible = true,
            w = 500,
            h = 300,
        local Button = winapi.Button {
            text = "button",
            w = 300,
            h = 100,
            x = 50,
            y = 50,
            parent = Window

    posted in General Discussion read more
  • Alonso Hermosilla

    After checking: https://luapower.com/build-scripts
    I realized that I had followed very similar steps, but this time I decided to build liblua51.a by myself (The size of the file increased by few kilobytes). Apparently the problem persists.

    posted in General Discussion read more
  • Alonso Hermosilla

    Hello, I don't really know where I should be asking this but I only know this forum so I thought I could talk about it here.
    My problem is this: I managed to build LuaFFI (https://github.com/jmckaskill/luaffi), under MinGW (gcc 3.4.5).

    It certainly does load correctly, but for whatever reason the program crashes when lua_close is called on the state.

    The program doesn't have a Makefile for MinGW. I used this shell commands in order to compile it:
    gcc -c call.c
    gcc -c ctype.c
    gcc -c ffi.c
    gcc -c parser.c

    Afterwards I downloaded liblua5.1.a from LuaBinaries (the 32 bit MinGW distribution one). And installed it on MinGW/lib/

    I had all the object files compiled and the source code of Lua 5.1.4 stored in the "src" folder inside of the same folder as the sources of the LuaFFI module.

    I wasn't quite sure what the problem was with GetModuleHandleEx/GetModuleHandle (they weren't defined anywhere) so I had to remove them from ffi.c (I thought it not so important) and recompile ffi.c.

    Finally I used this to get the dll object.
    gcc -O -shared -o ffi.dll *.o -L src -llua5.1

    The program that is using ffi.dll, is using a unmodified version of Lua 5.1.4 (and it's a static library, compiled with MinGW too).

    • I don't think that the issue is related to the program itself because it is able to load any other modules as many times as it wants to without causing crashes.
    • I discard the option that another module using functions from ffi.dll could be causing the crash because I immediately closed the state after loading doing "require'ffi'".
    • However, I think that the garbage collector is messing up with the module (ffi.dll) and I'm not really sure about how I'm going to fix that.

    Any ideas? (Please think of me as a ignorant on this topic, I'm just a regular Lua coder)

    posted in General Discussion read more
  • Alonso Hermosilla

    I found this.

    But I saw no releases so I decided to post it here.

    posted in General Discussion read more
  • Alonso Hermosilla

    Text to Speech and vice-versa.

    posted in General Discussion read more
  • Alonso Hermosilla

    How about your own file system using FFI?

    posted in General Discussion read more
  • Alonso Hermosilla

    Hey, github isn't pushing the webhook anymore because of this.
    /home/cosmin/website/www/actions.lua:1100: attempt to call field 'exec' (a nil value) stack traceback: /home/cosmin/website/www/actions.lua:1100: in function 'handler' /home/cosmin/website/www/app.lua:167: in function </home/cosmin/website/www/app.lua:149> [C]: in function 'xpcall' /home/cosmin/website/nginx/../www/ngx.lua:20: in function 'try_call' /home/cosmin/website/nginx/../www/ngx.lua:27: in function </home/cosmin/website/nginx/../www/ngx.lua:1>
    Just saying.

    posted in General Discussion read more
  • Alonso Hermosilla

    Hey, out of curiosity how do you update the actual page on luapower.com? I was trying to design the documentation file but it doesn't seem to apply changes on the site (and it doesn't know when the last commit was), do you need a webhook or do you do that yourself manually?

    posted in General Discussion read more
  • Alonso Hermosilla

    It's fine, I'm taking all the notes you're giving to me since I'm not even a computer scientist. About the first point, I copied that select function from BlitzMax's wrapper, so I'm not sure if I should substract a unit, but you're probably right. About the "unsigned int", this is just for the timeout, apparently assigning a normal integer to math.huge returned negative values so I just turned it into a "unsigned int" rather than a "int", I would use Lua numbers but the values returned from socket.udp() and socket.tcp() are actually cdata objects so I needed to give them some class.

    posted in General Discussion read more
  • Alonso Hermosilla

    I merged the test files into bnet_test.lua, and removed the .gitignore file.

    One of the tests is interactive but it's actually easier to use the web browser to test it, I pointed that out on the script.

    posted in General Discussion read more
  • Alonso Hermosilla

    I changed bnet.md with the one you gave me and I'm now using the bit functions you told me (I added a slightly better description too),
    I added a WHAT file on /csrc/bnet/,
    Now instead of using the cdefs on bnet.lua, I added bnet_h.lua,
    I added my name on bnet.lua and the license,
    I tested four of the libraries from the original LuaSocket (the rest of them were using different ones I wasn't supposed to port like HTTP, FTP, SMTP, etc),

    About h_addr_list, I might change it later because the code is already functional and I might break something trying to change this (I don't expect to miss this important detail but if I do it now the stable version will probably stop being stable).

    posted in General Discussion read more
  • Alonso Hermosilla

    The tcp and udp parts of the library are now fully functional, at least for Windows. I did most of the things you told me to do, except some here.

    • in luapower all modules follow the lowercase_sometimes_with_underscores convention rather than CamelCase. Again, I don't mind it, but users would probably feel for the inconsistency.
      I considered that I should keep the actual functions that were written like this for backwards compatibility, I know some people that were using my library before. (Hence why it's called bnet, lol)

    • % 256 and / 256 are slow; consider replacing them with rshift(8), lshift(8) but that's not needed either, just use a cast if you want to write a whole int32 at a time (same with ServerIP calculation, you can just cast h_addr_list to an int32 and tonumber() it).
      I couldn't really get how to use those two functions, I'm not really used that much into the bit library, but at least bit.lshift replaced Shl well.

    However the rest of the library looks alike LuaSocket's api, I still need to finish the socket.dns.* api (which I couldn't understand very well from the original documentation), and finally I need to complete the documentation, which I guess I'm going to copy-paste from the functions I ported and the ones I made. (Yes, I'm very bad at explaining plus it would be good to keep the original documentation)

    With this progress, is there a possibility that this could appear on the site and the repo?

    posted in General Discussion read more
  • Alonso Hermosilla

    On the other hand I just remembered that TUDPStream is a ffi structure and that means it needs to work with cdata fields. I must have broken it again.

    posted in General Discussion read more
  • Alonso Hermosilla

    Wow this is mindblowing, especially the replacement to malloc. It might take me some time to replace all that but for now I just replaced whatever was easy to replace. If I want to allocate new memory I should use this...

    cbuf = rb.cbuffer{size = (The size of the buffer)}

    Edit: So I was expecting that this replacement would be correct, but it's pretty confusing.
    function TUDPStream:Read(Buffer, Size)

    local NewBuffer --, PrevBuffer
    local Size = math.min(Size, self.RecvSize)
    if Size > 0 then
        --ffi.copy(Buffer, self.RecvBuffer, Size)
        self.RecvBuffer:read(Buffer, 0, 0, Size) -- This would copy 'Size' bytes into the buffer
        if Size < self.RecvSize then
            NewBuffer = rb.cbuffer{size = self.RecvSize - Size} -- The bytes we read must be removed from the begining of the buffer
            self.RecvBuffer:read(NewBuffer, Size + 1, 0, self.RecvSize - Size)
            --PrevBuffer = ffi.string(self.RecvBuffer, self.RecvSize)
            --ffi.copy(NewBuffer, PrevBuffer:sub(Size + 1), self.RecvSize - Size)
            self.RecvBuffer = NewBuffer
            self.RecvSize = self.RecvSize - Size
            self.RecvBuffer = rb.cbuffer{size = 0}
            self.RecvSize = 0
    return Size


    I assumed I would no longer needed to run C.free. Code tags are weird :O

    Also, is zero the first index? If so, then I guess it's wrong to make the receive buffer start from "Size + 1"

    posted in General Discussion read more
  • Alonso Hermosilla

    Alright, I did the adjustments you said but I still need to write a decent documentation about it.

    About what is it, it's supposed to be originally a socket library for another programming language but I just tried to do the right ports from it into FFI because the API seemed a way too friendly. But I guess this port I'm doing right now will be LuaSocket-api compatible as much as BNet-api compatible.


    posted in General Discussion read more
  • Alonso Hermosilla

    Hello, I've been working for about a month or more in a plain FFI binding for sockets. (Which is partially functional because I haven't met much people using Linux that could test it), but your site is very noticeable and I think it's the only way for the people to find it, I'm going to maintain it myself, so I wanted to ask you for your permission to keep it on LuaPower github's repository. Is that possible?

    This is the actual code:

    posted in General Discussion read more
  • Alonso Hermosilla

    Hey there, I was wondering if there is any possibility to have LuaFFI libraries from LuaPower in case that we're running a Lua state which we're not able to control within it's source code (from another program that supports Lua coding for example, but not LuaJIT). If that was possible we might be able to run all the FFI bindings from LuaPower on those old programs that still used to run Lua (perhaps from Lua 5.1.4 which I belive that used to be the most used version of Lua in those days).

    Out-of-topic: I was using your zlib library in a program I'm developing but I couldn't find a license file, so I added a link to https://luapower.com/zlib. Is that okay?

    posted in General Discussion read more
Internal error.

Oops! Looks like something went wrong!