lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 02/24/2014 08:33 PM, Andrew Starks wrote:
On Mon, Feb 24, 2014 at 4:14 PM, Sean Conner <> wrote:
   The scheduler I have is simple:  I'm either waiting for an event, or I'm
not.  As such, I have two lists, one of a list of coroutine waiting for an
event, and a list of coroutines that are ready to run (because their events
have arrived).  Simple round-robin scheduling.  I found no need for anything
more complicated than that. [3]

Sean, I would love to see that code! The description of your scheduler fits Lumen pretty well.

I thought I should follow up with more than "Lumen looks nice!"...
Sometimes parts are a bit... out of sorts, but this is to be expected
with something that is under development.

Yes, indeed... Some parts are just experiments or proof on concepts done for the cool factor and are clearly subpar quality wise.

It is based on SierraWirelsse's luasched[1].

I might clarify this, because "based on" is a overloaded term. What happened is that I stumbled upon a presentation by Fabien Fleutot from Lua Workshop 2011, where they presented Sierra's M2M platform idea. There where three slides where they presented the scheduler, with the API outline and code snippets. I liked the API idea very much [1] (sched.signal & sched.wait), so I attempted to implement such an API in pure Lua (Sierra's scheduler was/is a modified Lua VM with some C modules). The first test.lua script was derived from the example in the presentation, and still is. When luasched was published, I discovered that my interpretation of the API was wrong[2] Anyway, I simplified the API a bit further.

Summing up, the scheduler itself has no luasched code, nor does depend on it, nor is API compatible, nor is a valid replacement :)

I borrowed code from ancillary bits (like the logging module) and tools (like the telnet server). Those are probably the ugliest parts, because it was sort of a hatchet job, done when still had no users, nor a good idea on how it will be used.

On the uses, I can point to a toyish data flow language (data flow is modelled as signals)[3].

Also, there is a grad student project using Lumen to write a rather cool IDE for educative robotics: they use Lumen's webserver to serve a html5 application that allows to draw a program with blocks (scrath/turtleart like), which is then translated to Lua and feed back to Lumen as a task. They have it running on a RPi, replacing a XO laptop on our educational robot Butiá [4].