Timbus
Async
Readme says:
It's currently in active development, but it is mostly stable until perl 6 implements either threads or async I/O so it can work correctly as a bot (timed events and things that block the runtime are not possible yet.)
That's from 2010. It seems like all of that stuff works quite well on MoarVM (or at least it is good enough!).
I need timed events…
Currently at work right now, but in short: It almost does work already. Perl6 has provided some absolutely excellent concurrency support. The only issue is that blocking the socket on a read prevents data being sent out of it.. For whatever reason.. But if the reader isn't blocking, your timed callbacks will work right now, without a problem (this has been tested). We should be able to work around send being blocked if we switch to an async socket for the connection and just have it poke the run loop.. Should be fairly easy.(?)
If you have larger requirements beyond a timer, let me know. We may need to work extra features into the core.
On Wed, 4 Nov 2015 17:41 Aleks-Daniel Jakimenko [email protected] wrote:
Readme says:
It's currently in active development, but it is mostly stable until perl 6 implements either threads or async I/O so it can work correctly as a bot (timed events and things that block the runtime are not possible yet.)
That's from 2010. It seems like all of that stuff works quite well on MoarVM (or at least good enough!).
I need timed events…
— Reply to this email directly or view it on GitHub https://github.com/TiMBuS/Net--IRC/issues/15.
Yeah, I've tried something like this:
class AsyncTest {
has $.delay = 5;
method said ($e) {
next if $e.what !~~ / asyncstart /; # type “asyncstart” to test it
start {
loop {
sleep $!delay;
say 'test';
$e.msg: 'hello'
}
}
}
}
But indeed, both $.conn.get and $.conn.sendln do block it, which kinda breaks the whole purpose.
It seems like $.lines should return a lazy list, I wonder if it is possible to use it as some kind of a feed…
My only requirement is quite simple. I'm doing something like a RSS notifier. On my side it simply reads a feed from time to time.
All I need is a way to tell Net::IRC::Bot to send a message without waiting for something to come from the server. That's it. The code above kinda does it, but I don't want to wait for the next PING request to appear…
Yeah. Switching to IO::Socket::Async (or whatever it is called) should magically fix everything there. I'll start on it tonight. Also: look into supply.interval or promise.in for your callbacks. They're really nice.
On Thu, 5 Nov 2015 11:41 Aleks-Daniel Jakimenko [email protected] wrote:
My only requirement is quite simple. I'm doing something like a RSS notifier. On my side it simply reads a feed from time to time.
All I need is a way to tell Net::IRC::Bot to send a message without waiting for something to come from the server. That's it. The code above kinda does it, but I don't want to wait for the next PING request to appear…
— Reply to this email directly or view it on GitHub https://github.com/TiMBuS/Net--IRC/issues/15#issuecomment-153916610.
I pushed a pretty basic attempt I wrote while in a semi-lucid state last night.. It seems to work when I connect to an echo server, but Unreal won't let me connect past a few lines. Not sure what the issue is..
Feel free to try it out. There's a fair chance that it works on more lax irc servers. The branch is named async-loop
Did you recompile? There were changes associated with \r\n handling which broke a lot of modules. Net::IRC::Bot included (at least in my case). I had to downgrade in order to make it work again. Not sure where the problem is.
I'll test it soon, I hope.
It works! That's it!
However, to print stuff, it seems like I need an Event object (which is the only thing that has a convenient .msg method). What would be the right way to do it then?
My ugly code above works though.
I assume you can just capture the event in the promise/supply callback. You can also access Bot.conn directly. If you need the connection passed to the module on bot creation, hmm. I'd hook 'connected' and go from there
Yeah but it feels like .msg thing should be in Bot, not in Event. Otherwise it does not make enough sense to me…
Yes and no. Msg is a specific way to privmsg someone and involves the context of the event it is encapsulated in. I guess we could move the core functionality to TextUtil or something. Maybe attach it to the irc-connection role?
Either way, you might want to just write out an example of the Api you envision using, and then I'll make it work.
It seems like the whole design of Net::IRC::Bot needs an overhaul. IMO things like https://github.com/TiMBuS/Net--IRC/issues/16 will keep popping up. I can't really recommend any particular change though, because the module should be overlooked as a whole.