Closed SerinaNya closed 4 years ago
又是自造 handler, 操了.
停止自己自造 handler 这种愚蠢到爆炸的行为, broadcast control 十分强大, 具体的内容我会在今天晚上更新的文档里面说明, 就拿你这个例子
又是自造 handler, 操了.
停止自己自造 handler 这种愚蠢到爆炸的行为, broadcast control 十分强大, 具体的内容我会在今天晚上更新的文档里面说明, 就拿你这个例子
啊,那真是太棒了!i了i了
我知道你这个问题出在哪了, 这个问题我也在使用 atexit.register
时发生了.
你需要把那行愚蠢的 @bcc.receiver
去除, 然后在 __init__
里面写:
bcc.receiver("GroupMessage")(self.group_message_listener)
问题很jb简单, bcc.receiver 被执行时, 传入的是他妈的一个还没被 classy
的 function, 其中的 self
极有可能导致了 RequirementCrashed
错误.
求求你们别他妈自己造 Handler 了, 我马上出一个文档给你们说一下该如何使用 无头参数装饰器(Headless Decorator)
求求你们别他妈自己造 Handler 了, 我马上出一个文档给你们说一下该如何使用 无头参数装饰器(Headless Decorator)
那您是建议我用 无头参数装饰器?这个更适合是吗?
求求你们别他妈自己造 Handler 了, 我马上出一个文档给你们说一下该如何使用 无头参数装饰器(Headless Decorator)
那您是建议我用 无头参数装饰器?这个更适合是吗?
你这个是纯属瞎几把又乱造了一个 Broadcast.listeners
, 并且你这个也只是类似对 Listener 进行过滤, 使他在应有的地方启动, 这与我的设计中的无头参数装饰器是有一定的重合的, 并且如果你使用这个特性, 或许还可以通过后续更新中的, 命名空间(Namespace) 层面的无头参数装饰器更进一步的优化.
对于你后面这个 BotMessage
: 赶紧!去死啊啊啊啊啊(╯‵□′)╯︵┻━┻
对于你后面这个
BotMessage
: 赶紧!去死啊啊啊啊啊(╯‵□′)╯︵┻━┻
那我 BotMessage 要动吗
我只对你后面的这个自造 listener 集合批判, 两个设计都不够好, 但自造 listener 集合看起来已经成为一个非常广泛的现象了...我希望能改变这个怪现象
我只对你后面的这个自造 listener 集合批判, 两个设计都不够好, 但自造 listener 集合看起来已经成为一个非常广泛的现象了...我希望能改变这个怪现象
看起来还得继续增强文档 :thinking: 没有文档大家咋知道这么用嘛
我只对你后面的这个自造 listener 集合批判, 两个设计都不够好, 但自造 listener 集合看起来已经成为一个非常广泛的现象了...我希望能改变这个怪现象
看起来还得继续增强文档 🤔 没有文档大家咋知道这么用嘛
我也不知道该咋增强文档了, 但我有一点可以明确:
Broadcast Control
可以带来几乎无限的扩展性和特性.不如把一些愚蠢的操作列一下:
坐等你 commit 文档了((
已经出了一部分, 另外两个我明天写
判断 MessageChain 中是否有 command 可以用无头参数修饰器来解决,那么今天的文档中是否会说明如何监听具体 command 并执行相关业务代码呢?要知道,command 是 bot 的一个重要组成部分,大多数 bot 都有类似的功能,所以,我还是希望能讲一下这种情况应该怎样处理。
我知道你这个问题出在哪了, 这个问题我也在使用
atexit.register
时发生了.你需要把那行愚蠢的
@bcc.receiver
去除, 然后在__init__
里面写:bcc.receiver("GroupMessage")(self.group_message_listener)
问题很jb简单, bcc.receiver 被执行时, 传入的是他妈的一个还没被
classy
的 function, 其中的self
极有可能导致了RequirementCrashed
错误.
当我尝试这个临时的解决方案后,我发现在我发出 $test
后,bot 依然没有回应,控制台也没有任何响应
我上传了部分的源代码,由于 settings.py
含有敏感信息,暂时不便提供
判断 MessageChain 中是否有 command 可以用无头参数修饰器来解决,那么今天的文档中是否会说明如何监听具体 command 并执行相关业务代码呢?要知道,command 是 bot 的一个重要组成部分,大多数 bot 都有类似的功能,所以,我还是希望能讲一下这种情况应该怎样处理。
本来这里的处理是要由模块 graia-ptilopsis
通过构筑标识链解决的, 所以今天的文档中不会包含这个部分(当然, 不排除这个模块突然有想法导致今天内发版的可能)
判断 MessageChain 中是否有 command 可以用无头参数修饰器来解决,那么今天的文档中是否会说明如何监听具体 command 并执行相关业务代码呢?要知道,command 是 bot 的一个重要组成部分,大多数 bot 都有类似的功能,所以,我还是希望能讲一下这种情况应该怎样处理。
本来这里的处理是要由模块
graia-ptilopsis
通过构筑标识链解决的, 所以今天的文档中不会包含这个部分(当然, 不排除这个模块突然有想法导致今天内发版的可能)
哦好的,希望能尽快出来 :)
我试图在 GroupMessage 的监听器中加入自己写的命令处理器,可结果并不如人意,Graia 似乎并没有正确地调用
group_message_listener
方法(至少我在bot.py
中print('OK')
是失败的),请问这是框架的问题还是我的问题呢?如果问题在我,我该如何调整以达到目的?bot.py
main.py
botmessage.py