slow moving channel

[Anniepoo]

It'd be nice if yesbot watched the channel and kept track of the first thing a nick said after joining. If no one responds (says anything) within 1 minute or some such number, yesbot could say something like

Hey, just to let you know, this is a slow moving channel. Leave the window open for 30 minutes or so and somebody is likely to notice and come around.

or some such advice.

[Anniepoo]

this is yesbot

http://www.pathwayslms.com/swipltuts/ Hey there! I just wanted to let you know that you can use the "?tutorial" keyword. Pardon my interruption. so same voice rule would be Hey there! I just wanted to let you know, this is a slow moving channel. Leave the window open for 30 minutes or so and somebody is likely to notice and come around. Pardon my interruption.

[eazar001]

I see. Okay, seems like a cool idea. Should this be a notification, private message, or in channel public message?

[eazar001]

If no one responds (says anything) within 1 minute or some such number

Also, another issue to consider with repsect to the abovementioned: How shall we distinguish what are appropriate responses? Should it be a greeting and/or variants? How are we to determine if a response that is delivered in under a minute bears proper attention to the newly joining user? Also ... how do we handle regulars who just recently join and say hello, but don't get responded to right away?

[Anniepoo]

I wasn't going to try to parse, I was just going to assume people are in the channel and acti ve if there's anything said in that minute.

regulars - I suggest we keep a record of who we've greeted, and never do it again. when the bot starts up it takes the current list of people in the channel and considers them greeted. I don't expect the list to be that big. Persistency should handle it fine.

[eazar001]

I see. Okay that makes sense.

[eazar001]

Also, another dangerous thing I just envisioned:

1) 5 users log in at the same time. 2) 5 timer threads get invoked simultaneously timing a specific instance for each new joining user, potentially reiterating the message up to 5 times.

This can obviously be worked around, but it will get a little messy, and will require rolling some state management into the extension. This is not so trivial to implement. I think I may hold off on this until I correctly implement a working prototype of state.pl at the very least. Additionally, in the long run it will be more beneficial to wait, as more state-intensive extensions will be more easily constructed after getting functionality up in the state branch.

[Anniepoo]

every time you make the announcement kill all pending announcements. alternatively, update a global with the wall time. if it's beyond the time my thread started, just quietly die.

[eazar001]

There is no "pending", everything is asynchronous. This can be easily worked around by making it block everything else, but then everything will become noticeably slower ... particularly extensions that involve http operations.

[Anniepoo]

well, the delay implies some sort of thread or timer When the task wakes up, it knows it's start time, and compares with global time at wich an announement was made

[eazar001]

Right, this is pretty much what i'm doing in news.pl ... albeit it will take a little bit of effort duplication. Essentially I'm saying I don't want to rewrite this, without creating a better framework for these kinds of things, even though it's very possible to get it done without such a thing.

[eazar001]

@Anniepoo , I actually think that this is an issue better handled with plchatscript. This is much cleaner with conversational agents in my opinion. Whereas using my "traditional" method I have to create a timer thread to time responses, and then a timer to time when the last greeting was issued, we're looking at 2-3 timers here depending on frequency of visits. While future state.pl infrastructure could potentially come in handy, the more and more I think about it ... the more useful chatscript seems to be for even "simple" situations like this. I'll install it on the server later tonight, and maybe think about how I can integrate it. Correct me if If my intuition is wrong, it's just -- that's what it was telling me.

Again, this comes back to the same issue of envisioning multiple situations of unwanted spam and circumstantially irrational messages coming from the bot. Ironically, the concern here is being less "robotic". The extensions I wrote that involved minimal state (messages.pl and news.pl) had less potential for intrusive behavior. Hence I didn't think as much about those two.

Either way, it's my personal opinion that doing this without either:

a) Writing some sort of state infrastructure b) Utilizing your chat framework

... would be a mistake.

[eazar001]

Also another reason why I'm so hesitant is that I'm already running a few detached timers. I'm afraid that if I keep following my toxic pattern for future scripts, this will in turn start poisoning the entire system with floating independent timing threads that need to be managed (I've already halted completion of a few scripts/modules because of this sad realization).

That's why I'm being so stubborn about this and take a "better now than later" attitude towards this issue.

(Posted by accident in another issue, sorry)

[Anniepoo]

most of these are just that - timers - not really threads. Why don't you just use alarm?

http://www.swi-prolog.org/pldoc/man?section=time-and-alarm

[eazar001]

Alarm sounds reasonable. I'll give a look into using it for this when I get the next chance.

[eazar001]

Enhanced, by way of commit c0aa45b.

[Anniepoo]

You're right, an alternative architecture for all of yesbot would be

yesbot <--> chatscript <--> various services

chatscript has the notion of 'start of conversation', and could interact with a time check

[eazar001]

Yea, this is one instance where chatscript could have helped. However further thinking later on gave me the idea that this (among others) would also possibly be represented more accurately as a Finite State Machine. It's entirely possible one day that I integrate both chatscript and finite state machine architecture as a part of state.pl. Either way, I also want to keep the option open just to hack up simple scripts as well.

Perhaps chatscript might bear some semblance to finite state machines, but I would want to build one framework that preserves the specific semantics of chatscript itself. The other module would be transparently represented using FSM semantics, of course. Other mini-frameworks could be added if needed. Actually, FSM stuff might be better as a prolog pack, rather than direct integration into the bot itself. I have time to think about this later, I suppose. I'm in no hurry.