A common problem with Lua newbies is the setup of the Lua environment. As many other programming/scripting languages Lua allows you to load external libraries. To prevent you from having to type exact system paths, Lua uses so called library paths to automatically look them up.
For this purpose Lua has 2 environment variables, LUA_PATH and LUA_CPATH. The former is used for loading Lua libraries, the latter for C libraries. Despite the different targets, they both work the same. And if you are familiar with the regular system PATH variables, then you already know the concept. Continue reading
Today I lined up both lights to see how they compare. No suspense here; the Hue wins hands down (except if you require/own zwave technology…)
What are they?
These are so called ‘wireless’ RGBW light bulbs. They only require electric power to be connected, switching and dimming is done through remote controls and/or apps. The lights are RGBW capable (Red, Green, Blue, White) meaning they can do regular white light as well as coloured light. Continue reading
After a previous post on this topic, this is an update, as several changes have made Lua more Windows friendly; the LuaRocks package manager now is a first-class Windows citizen, and the core network library LuaSocket is available as a working package installable from LuaRocks
Lua itself is pretty barebones, so to make it usefull, you’ll be needing additional libraries. The libraries come in several flavors; pure Lua code, C/C++ code, or binaries (precompiled C/C++ libraries). The pure Lua libraries can be used anyway, but the C libraries tend to mostly be available as source code only, meaning you’d have to compile them. And to do that you need a compiler… Continue reading
Here’s some code that I’m pretty proud of, its a nifty piece of code that allows to store any kind of data in a simple textbased container. It uses a custom Base64 encoding to store integers, floats, strings, booleans or blobs in a text block and adds some CRC checks and even some repair capabilities.
In VBA you may occasionally want to store some settings outside of the document. The registry is one way, but I often try to keep it in INI files as automated documents get spread through email easily, but usually do not get ‘uninstalled’ hence the settings will never be cleaned up. I’d rather leave an orphaned file than polute the registry. Other advantages are that its easier to support because a user can email them, or its easier to edit by a user.