weak_ptr

me too. Legacy mode manjaro linux x64 VS Code 1.15.0 vscode-rust 0.4.2 extension config ```json "rust.rustup": { "toolchain": "stable-x86_64-unknown-linux-gnu", "nightlyToolchain": "nightly-x86_64-unknown-linux-gnu" }, "rust.mode": "legacy", "rust.rustLangSrcPath": "/usr/src/rust/src", "rust.racerPath": "/home/uniq/.cargo/bin/racer", "rust.rustfmtPath": "/home/uniq/.cargo/bin/rustfmt",...

被风控了？ 个人遇到过QQ客户端本身存在偶尔消息发不出去的情况，消息内容也没有明显违规

第 7 条是考虑把 mpg123 换成 libmad 或者 gstreamer 之类的吗？

https://github.com/darknessomi/musicbox/blob/5aadfb6f9ea7b5414a9a0acd9487f5be03183a7b/NEMbox/api.py#L393 试试加入 `custom_cookie={"os": "pc"}` 自己测了下，修改前返回 code=250 当前登录失败，请稍后再试 修改后正常，在 cookies.save 报错 https://github.com/darknessomi/musicbox/blob/5aadfb6f9ea7b5414a9a0acd9487f5be03183a7b/NEMbox/api.py#L346 这里应该是 py3 兼容的问题，改成 `rest={}` 恢复正常

用api.NetEase还是不能登录，提示cheating。这个bug是一直没修复吗？ 这里是我的临时补丁。 ```python import logging import random import arrow from NEMbox.api import NetEase from hashlib import md5 from homepage.config import config BOX = NetEase() _logger = logging.getLogger('netease') def _timestamp(): return...

NetEase类的login api 设计也很奇怪，passwd参数必须是md5().hexdigest()但也没注释说明

正在用nonebot（个人娱乐用途），很感谢大佬的付出。 使用中遇到了一些细节，刷github的时候看到了这条issue，来抱怨一下 (*^_^*)，想到哪里说到哪里，见谅。 1. nl_processors 很多的话会影响效率，换成ac自动机可以快一点，现成的库[pyahocorasick](https://pypi.org/project/pyahocorasick/)。这个倒不是很重要。 https://github.com/richardchien/nonebot/blob/7d96bacbb9b979f3e7ae4a33d371863df5933d86/nonebot/natural_language.py#L131-L136 2. log 不方便配置，使用`coloredlogs.install`或`logging.basicConfig`、`dictConfig`都不能影响到这个logger。  3. 要求一个`config`模块不是很合理，这个主要是考虑不能简单地用`json.dumps(config)`或`pickle`保存配置/加载配置，平白多了很多代码要写。 4. 关于部署的问题，主要是发图、收图方面，我预期是可以分别部署酷Q和nonebot到两台机器上的，但发图要求把图片放在酷Q的data/image里，导致不能分开部署。这个能由cqhttp提供支持吗？调用方式类似于这样： ```python msg=Message() msg.append(MessageSegment.image(url)) # url 可以是本地文件路径、网址 ``` 如果部署在不同机器上的话，传入本地文件路径时，把图片上传到cqhttp，cqhttp保存到酷q的data/image下，再发送整条消息。传网址时同理，cqhttp先把图片下载到酷Q的data/image下。 这个应该算是cqhttp的问题，这里姑且一提。 关于nonebot未来的发展 > 我希望它可以被用于任何聊天机器人的场景，无论是闲聊对话、信息查询、推送通知、消息转发、游戏等。 目前我自己使用体验上来看，确实是【命令】重于【对话】，这方面的改进恕我暂时只想到封装一个`on_message`，和`on_command`、`on_natural_language`平级的玩意儿。 > 最近想到...