[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: [ANN] LuaCSP framework: Communicating Sequential Processes in Lua
- From: Alexey Baskakov <alexey_baskakov@...>
- Date: Tue, 15 Jan 2013 22:28:56 +0400
> Like I said, you can check out my fork on github (I'm not going to
> bother to submit a pull request unless you really want me to.) I've
> already got it compiling (manually with g++.)
Thanks, I'll check it out later!
> One thing which might be
> useful is using CMake since it can generate MVS solutions as well as
> Makefiles (or Ninja builds, which is becoming my preferred builder now.)
> Otherwise a plain Makefile is really good enough.
Yeah, cmake is mentioned in Development Roadmap section :)
> I guess the way I'd /like/ to use it would be two fold (depending on
> what I'm writing.) One would be the embedded route which is currently
> supported. The other would be more in pure Lua (or using C modules)
> being run from the standard Lua interpreter. Some things I'd like to be
> able to do:
> * Use channels and composition to make some code concurrent.
> * Write fundamental operations in plain Lua.
Yeah, fundamental operations in Lua are in my todo list. And I need them quite urgently.
It'll be like this:
OpLuaSleep = CspOperation:new()
function OpLuaSleep:Work( deltaTime )
self.seconds = self.seconds - deltaTime
if self.seconds > 0 then
return CspOperation.Yield
else
return CspOperation.Finish
end
end
function OpLuaSleep:Terminate()
end
function LUA_SLEEP( seconds )
local op = OpLuaSleep:new()
op.seconds = seconds
return op.DoInit()
end
Of course, you need some async API in plain Lua/C/C++ to wrap into fundamental operations...
> What I guess I'd like to be able to write is something like:
> http://pastebin.com/DQPZPPr9
In general, you should be able to pass any number of arguments of any type to CSP process (including non-CSP closures).
Since Swarm:go can't distinguish whether a closure is a process to start or an argument, it's more reasonable to use two anonymous
closures as in the doc.
Of course, there is a variant to organize API like this:
swm:go( p1, {arg1, arg2}, p2, {arg3, arg4} )
but I found this less convenient than extra anonymous closures (from my experience).
In fact, Swarm:go isn't the key feature and a bad practice (maybe). It just slightly simplifies the code at some cases.
It's provided for fun, as a show of respect to Google Go language :)
However, all the mentioned details are applicable to PAR as well.
BTW, I want to make ALT to act as 'select' in Go. I.e. to be able to wait not only on channel inputs but outputs too.
Alexey.