New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose More Go Libraries #104
Comments
How about added the libs? |
Not a bad idea actually. But I wouldn't want all those things, maybe:
There's also a Using these libs would probably mean not grouping them under the "go" namespace but it may be worth sacrificing that point for time saved in development. Thoughts, @xyproto ? |
I think It's a great idea, as long as normal Lua code does not experience name collisions. |
This might be controversial, but I even think that exposing a graphics library like https://github.com/fogleman/fauxgl, for being able to render 3D graphics to a buffer, would be cool. |
Interesting, what use case were you thinking of there? Rendering 3D models from the server into jpegs to be served to display in the browser, I guess? |
@tooolbox Yes, or even as a way to write a 3D game and show a window with graphics locally, while also including a server. Multiplayer games often includes servers.... But this is just an idea, I haven't really thought this through. 🙂 |
Another good set of options is: https://github.com/Shopify/goluago
Add in the missing ones from gopher-lua-libs:
Perhaps anything directly wrapping Go libraries can be under the |
In the past couple days I've had to deal with some utf8 content, and discovered that Lua has no native support for utf8. Many of the most popular/commonly recommended solutions involve C libraries wrapped by Lua, which obviously won't work for Algernon.
Nevertheless, I have scoured the internet for pure-Lua utf8 libs and I almost have a working solution.
However, Go has pretty fantastic utf8/unicode handling. Actually, it has pretty fantastic a lot of things. We wouldn't necessarily want to blow away the standard Lua functionality because libraries will depend on them, but what about adding more Go libraries under the
go
namespace?Obviously the
strings
lib is top of mind for me at the moment but I wanted to pitch the general idea of exposing more Go libraries into Algernon and grouping them under thego
namespace.The text was updated successfully, but these errors were encountered: