Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

Fingercomp

Members
  • Content Count

    118
  • Joined

  • Last visited

  • Days Won

    30

Fingercomp last won the day on March 8

Fingercomp had the most liked content!

2 Followers

About Fingercomp

  • Rank
    Leading Member

Profile Information

  • Gender
    Male

Contact Methods

  • GitHub
    Fingercomp
  • IRC
    fingercomp

Recent Profile Visitors

2205 profile views
  1. There was no IRC library for OpenComputers, so I've made one. Here's a demo bot that uses it: local com = require("component") local event = require("event") local thread = require("thread") local gpu = com.gpu local irc = require("irc") local events = irc.events local env = setmetatable({ irc = irc, events = events, }, {__index = _G}) local client = irc.builder() :connection { host = "irc.esper.net:6667", throttling = { maxDelay = 2, maxThroughput = 5, }, } :auth { nickname = "oc-finger-irc", username = "fingercomp", realname = "OpenComputers IRC client library", } :bot { channels = {"#oc-finger-irc"}, tracking = { users = true, modes = true, account = true, userInfo = true, }, } :execution { threaded = true, reconnect = true, catchErrors = true, } :subscribe(events.irc.command, events.priority.high, function(self, client, evt) gpu.setForeground(0x00ff00) print("→ " .. evt.rawLine) gpu.setForeground(0xffffff) end) :subscribe(events.irc.write, events.priority.normal, function(self, client, evt) gpu.setForeground(0x00dbff) print("← " .. evt.line:gsub("[\r\n]*$", "")) gpu.setForeground(0xffffff) end) :subscribe(events.irc.message, irc.events.priority.normal, function(self, client, evt) if evt.source.nickname == "fingercomp" then if evt.message == "::quit" then evt:reply("Quitting.") evt.client:stop(("%s told me to quit."):format(evt.source.nickname)) elseif evt.message == "::spam" then evt:reply("1") evt:reply("2") evt:reply("3") evt:reply("4") evt:reply("5") elseif evt.message == "::longmsg" then local msg = {} for i = 1, 256 do if i == 128 then table.insert(msg, tostring(i) .. " ") else table.insert(msg, tostring(i)) end end evt:reply(table.concat(msg)) elseif evt.message == "::error" then (nil).test() elseif evt.message:sub(1, #"::exec ") == "::exec " then local code = evt.message:sub(#"::exec " + 1) local chunk, reason = load("return " .. code, "=irc", "t", env) if not chunk then chunk, reason = load(code, "=irc", "t", env) end if not chunk then evt:reply(("\x0304Error:\x0f %s"):format(reason)) else local result = table.pack(xpcall(chunk, debug.traceback)) local success = table.remove(result, 1) result.n = result.n - 1 for i = 1, result.n, 1 do if type(result) ~= "string" and type(result) ~= "number" and type(result) ~= "boolean" and type(result) ~= "nil" then result[i] = tostring(result[i]) else result[i] = ("%q"):format(result[i]):gsub("\\\n", "\n") end end if not success then evt:reply(("\x0304Error:\x0f %s"):format(result[1]:match("^[^\n]*"))) io.stderr:write(("%s\r\n"):format(result[1])) elseif result.n > 0 then evt:reply(table.concat(result, " ", i, result.n)) else evt:reply("\x0309Success") end end end end end) :subscribe(events.irc.ctcpRequest, irc.events.priority.normal, function(self, client, evt) if evt.ctcpCommand == "TIME" then evt:reply(os.date("%F %T")) end end) :subscribe(events.client.error, irc.events.priority.top, function(self, client, evt) print("Caught: " .. evt.traceback) evt:cancel() end) :build() local t = thread.create(function() repeat local evt = event.pull("interrupted") until evt end) env.client = client client:run() thread.waitForAny({t, client.thread}) client:stop("Quitting.") os.exit() I don't want to brag about it too much, but I think the code is pretty. Features Threaded execution. A nice API. IRCv3.2 capability negotiation. Throttling to prevent the bot from triggering anti-flood mechanisms. Tracks channel members, modes, nick changes, account names, etc. Automatically reconnects if it's disconnected from the IRC server. Splits long messages over multiple lines. The event bus can use coroutines as message handlers. Links The GitLab repository: https://gitlab.com/cc-ru/irc-oc Documentation: https://gitlab.com/cc-ru/irc-oc/-/wikis/home Demo programs: https://gitlab.com/cc-ru/irc-oc/snippets
  2. TL;DR: set the resolution to 159×28. Displays automatically scale the content to fit the screen's inner area. If you decrease the resolution height, the display area will occupy more horizontal space. I'll assume that your screen is 8×3. The aspect ratio of the screen's inner area is (2 × (8×16 - 4.5)) : (3×16 - 4.5) = 494×87. The "- 4.5" terms are the screen borders, and the width is doubled because the cell width is half its height. If you set the resolution proportional to this ratio, it will fill the whole screen. Of course, you can't do this, as the maximum resolution is 160×50. So we have to compromise and choose the resolution that fits the screen the best. local function round(num) local integer, frac = math.modf(num) if frac >= 0.5 then integer = integer + 1 end return integer end local data = {} for w = 1, 160, 1 do local h = math.max(math.min(round(w * 87 / 494), 160 * 50 / w, 160), 1) local area = w * h local delta = (w / h) - 494 / 87 table.insert(data, {delta, area, ("%d×%d"):format(w, h)}) end table.sort(data, function(lhs, rhs) return lhs[1] < rhs[1] end) local f = io.open("./data", "w") for k, v in ipairs(data) do f:write(("%.6f %d %s\n"):format(v[1], v[2], v[3])) end f:close() The above code creates an array and fills it with 160 possible resolutions by choosing a width and calculating the height such that the aspect ratio is the closest to what we're trying to achieve (494:87). Then it writes the data to a file so that we can plot it. Here's what we get: Now it's clear that the best resolution is 159×28. Its aspect ratio differs from 494/87 by ~0.000411, which is really small. Let's go ahead and calculate the thickness of the black area. Let dw, dh be the dimensions of the display area, and iw, ih the dimensions of the inner area. dw/dh = 159/28; iw/ih = 494/87. 159/28 > 494/87, so the display area height is less than the screen's inner area height. Therefore, the width of the black area is dw = iw. The height equals 0.5 × (ih - dh) = 0.5 × (87/494 × iw - 28/159 × dw) = 0.5 × iw × (87/494 - 28/159) = 0.5 × 494/87 × ih × (87/494 - 28/159) = 1/27666 × ih. In other words, the height of the black area is 1/27666th of the whole inner area height, which is negligible.
  3. When I was writing that response, I didn't really know, well, how experienced you are at Lua programming. OOP in general, not in Lua, isn't really advanced. Many languages allow to write in object-oriented style. To name a few: Java, Python, C++. If you don't know what OOP is, writing a few programs in these languages can help to understand the subject. OOP in Lua is really complicated. It requires using of metatables -- and that is advanced. In library, the code may quickly become complicated and hard to maintain. Instead of messing with metatables, I prefer to use libraries that nicely hide all the mess. It's just me searching for the greatest library possible, and someone would need quite a lot of Lua experience to create a library I would be satisfied with. So if you don't want to rewrite the whole GUI library once again and want to keep it as it is, I am not going to stop you. If you can't do OOP, do what you can, or you can easily lose the motivation. Create the library you want, not I. Your current way is very beginner-friendly, so Lua beginners might use it, while I would stick to using some other library.
  4. This mod adds a new architecture. Use the same items and blocks you use to build a regular Lua computer. Before you insert the processor, shift-click while holding it, until something like "65C02 Thistle" is printed to the chat. Then you can insert it into the computer. I also think the mod adds an EEPROM, so don't forget to insert it.
  5. As an author of a few programs that heavily used different GUI libraries, I have found problems in your current library. The approach it going to work for really simple programs, but when someone uses it for bigger projects, it becomes really hard to use. Below are some of problems I've found. You wanted feedback, after all. Why not use OOP? So that GUI elements could be modified in some way by calling its method, like menu:addSeparator(). OOP is a really great choice when making GUI libraries. It's incredibly hard to add a custom element that would use your GUI system. Every program with GUI I've written needed some elements that were not provided by a GUI library I used. With proper OOP, it becomes a really easy thing. Without OOP or support for adding custom objects, it's often a pain. Your code exports some functions to the global environment. A user can accidentally override such functions and break the library. Use local whenever possible. Only export functions via the return statement. (Note, adding local when defining function in a table is a syntax error: local function tbl.func() end will not work.) GUIs quickly become more complex as more features are added. Using your library, it's hardly possible to change a button callback to another function. Ideally, it'd be something like button.callback = function() print("Now it does something else") end. You also can't switch a button to the pressed state, you can't add child objects (like a label on a frame in a container).
  6. It's better to use block symbols: ▁▂▃▄▅▆▇█ ▏ ▎ ▍ ▌ ▋ ▊ ▉ █ http://www.unicode.org/charts/PDF/U2580.pdf
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.