首页
实用链接
图床推荐
友链
关于
Search
1
彻底卸载Cloudflare Tunnel(解决 cloudflared service uninstall 报错问题)
483 阅读
2
从零开始注册Hugging Face账号到部署网页应用
102 阅读
3
Debian 11.2 搭建 Typecho 个人博客教程
90 阅读
4
紫电猫8.8元随身WIFI刷Debian系统教程
88 阅读
5
Linux配置frps与frpc的四种隧道并设置开机启动
87 阅读
默认分类
教程
随笔
软件开发
笔记
登录
/
注册
Search
标签搜索
Datawhale
AI+X
Fun-Transformer
#Datewhale组队学习
隧道
Debian
Transformer
教程
随身wifi
frp
frpc
frps
内网穿透
Linux
toml
我的世界
Minecraft
MySQL
单片机
OLED
Simuoss
累计撰写
20
篇文章
累计收到
12
条评论
首页
栏目
默认分类
教程
随笔
软件开发
笔记
页面
实用链接
图床推荐
友链
关于
搜索到
16
篇与
的结果
2025-09-21
[2025年5月最新] 如何为WSL配置代理 & 如何为Docker配置代理
配置本机WSL代理正常安装好WSL编辑C:\Users\<UserName>.wslconfig,写入以下内容:[wsl2] networkingMode=mirrored localhostForwarding=true autoProxy=true dnsTunneling=true编辑.bashrc,在末尾添加下列隧道配置export http_proxy="http://localhost:10809" export https_proxy="http://localhost:10809"应用更改source ~/.bashrc配置Docker代理正常安装Docker配置 Docker 守护进程 (Docker Daemon) 代理sudo mkdir -p /etc/systemd/system/docker.service.d sudo vi /etc/systemd/system/docker.service.d/http-proxy.conf写入以下内容[Service] Environment="HTTP_PROXY=http://localhost:10809/" Environment="HTTPS_PROXY=http://localhost:10809/"重启Docker服务sudo systemctl daemon-reload sudo systemctl restart docker大功告成!
2025年09月21日
6 阅读
0 评论
0 点赞
2025-09-21
Typecho 1.3.0+ 与 Joe 7.7.1 主题不兼容导致首页文章一直loading的解决方案
前言昨天迁移完博客站就睡了,今早发现博客站换上Joe主题后,首页文章列表竟然无法正常加载,一直显示loading如图:后台和控制台也没有任何报错文章列表无法加载,通常是数据库查询或Widget调用问题。怀疑是Typecho 1.3.0改了一些关键实现,于是开始Debug,发现如下:Typecho 1.3.0 的变化负责处理数据查询、模板渲染等功能的Widget系统经过重构数据库访问层从简单的静态调用升级为更现代的面向对象设计命名空间变化Typecho在1.3.0版本中引入了现代PHP的命名空间机制:旧版本: Typecho_Db::get()新版本: Typecho\Db::get()Widget类体系重构旧版本: Widget_Abstract_Contents新版本: Widget\Base\Contents 或 Widget\Contents\Post\Admin路由系统升级旧版本使用 Typecho_Router::post()新版本的路由注册机制发生了变化解决思路概览了解了问题在哪,就可以着手解决了。处理这个变动,只需要把类似$db = Typecho_Db::get();的语句改为$db = Typecho\Db::get();即可。为了保证前向兼容,可以这样写:/* 兼容Typecho 1.3.0+的数据库类 */ if (class_exists('Typecho\Db')) { $db = Typecho\Db::get(); } else { $db = Typecho_Db::get();修改步骤第一步:修复Widget类继承问题文件:widget.php问题: Joe主题的自定义Widget类继承了旧版本的类名// 原代码 class Widget_Contents_Hot extends Widget_Abstract_Contents修复: 添加版本检测和兼容性处理/* 兼容Typecho 1.3.0+版本检测 */ if (class_exists('Widget\Base\Contents')) { // 新版本基类 class Widget_Contents_Hot extends Widget\Base\Contents { // ... 实现代码 } } else { // 旧版本基类 class Widget_Contents_Hot extends Widget_Abstract_Contents { // ... 实现代码 } }同时修复了数据库排序常量:// 旧版本 ->order('table.contents.created', Typecho_Db::SORT_DESC) // 新版本兼容 ->order('table.contents.created', 'DESC')第二步:修复路由系统文件: core.php问题: 旧版本的路由注册方式在新版本中失效修复: 添加路由系统兼容代码/* 兼容Typecho 1.3.0+的路由系统 */ if (class_exists('Typecho\Router')) { // 新版本路由注册 if (method_exists('Typecho\Router', 'post')) { Typecho\Router::post('/joe/api', 'Joe_Action'); } } else { // 旧版本路由注册 Typecho_Router::post('/joe/api', 'Joe_Action'); }第三步:修复数据库调用修复的文件:functions.phpfunction.phproute.php问题: 所有直接调用 Typecho_Db::get() 的地方都会在新版本中报错修复策略: 在每个数据库调用前添加版本检测/* 兼容Typecho 1.3.0+的数据库类 */ if (class_exists('Typecho\Db')) { $db = Typecho\Db::get(); } else { $db = Typecho_Db::get(); }第四步:添加类别名映射文件: factory.php解决思路: 为了让旧代码能够无缝使用新类名,添加类别名映射:/* 兼容Typecho 1.3.0+的Widget Helper Form类 */ if (class_exists('Typecho\Widget\Helper\Form')) { class_alias('Typecho\Widget\Helper\Form', 'Typecho_Widget_Helper_Form'); } /* 兼容Typecho 1.3.0+的数据库类 */ if (class_exists('Typecho\Db')) { class_alias('Typecho\Db', 'Typecho_Db'); } /* 兼容Typecho 1.3.0+的Widget类 */ if (class_exists('Typecho\Widget')) { class_alias('Typecho\Widget', 'Typecho_Widget'); } /* 兼容Typecho 1.3.0+的Abstract Contents类 */ if (class_exists('Widget\Contents\Post\Admin')) { class_alias('Widget\Contents\Post\Admin', 'Widget_Abstract_Contents'); } elseif (class_exists('Widget\Base\Contents')) { class_alias('Widget\Base\Contents', 'Widget_Abstract_Contents'); }最终能用的版本如果你感觉手动修改有些麻烦,也可以直接使用我改好的版本:Joe7.7.1-typecho1.3.0-fix.zip
2025年09月21日
18 阅读
3 评论
0 点赞
2025-09-21
Typecho博客从本地部署到Docker部署(1.2.1->1.3.0)迁移成功,Congratulations!
前言24年8月,因为Wifi棒子断电重启后无法自动回连Wifi,博客站就迁移到了一块847工控板上。一开始一切运行正常,但到了25年初,工控板经常异常死机,死机时用手摸一下还会自动重启,怀疑是板子电气性能不佳,遂计划把博客站迁移到其他设备上。但是开始迁移时却被一些问题卡住了,届时正值找工作比较忙,于是就先作罢,博客站就此荒废了几个月的时间。这个周末和盒子里的847工控板大眼瞪小眼看了许久,决定把它收拾了,就有了本篇。预先准备我的博客数据库使用SQLite,所以至少应该保留类似66ba4f5eec6c5.db这样的数据库文件。文件的路径通常在typecho\usr下。如果你想保留之前的主题,还需要保留整个typecho\usr\themes文件夹运行博客的新机器上需要先装好docker,为了方便今后的数据迁移,我们使用docker部署使用Docker部署时,建议直接使用docker compose,方便后续维护。compose文件如下:services: typecho: image: joyqi/typecho:nightly-php7.4-apache container_name: typecho-server restart: always environment: - TYPECHO_SITE_URL=https://xxx.xxx ports: - 8634:80 volumes: - ./typecho:/app对比文档里的写法,我们去掉了头部过时的版本声明,修改了宿主机端口,并挂载出了整个/app(也就是Typecho应用程序根目录)。挂载出整个/app的好处有以下两点:如果你的域名使用https,就需要编辑config.inc.php;如果你想迁移主题包,还需要编辑typecho\usr\themes文件夹,那索性就都挂载出来。开始迁移将以上docker compose文件保存到你想放置Typecho的目录,文件名为docker-compose.yaml,然后同级运行命令:docker compose up -d # 如果你不是root,使用sudo docker compose up -d这时docker会从云端仓库把Typecho镜像拉下来,静待一段时间,直到命令行窗口显示:笔者近期家里没有合适的设备,就选择了Windows上使用Docker Desktop部署,之后买了新设备再迁移。在Linux上的回显也大同小异。此时,同目录的typecho文件夹下就是容器内部挂载出的/app目录了。进入typecho\usr,把之前的.db文件(通常类似66ba4f5eec6c5.db)复制过来,然后进入127.0.0.1:8634进行博客初始化。初始界面直接点击我准备好了,开始下一步即可。随后你会看到下面界面,这里按照之前博客的配置选,比如我之前是SQLite,就选SQLite。pdo驱动和原生驱动都可以正常运行,选哪个都行。数据库前缀一般没有人会改,如果你记不清了,可以上类似sqlite-viewer的网站查看,比如我这个db文件夹就是以typecho为前缀的:最下面的数据库文件路径,我们已经把原先的数据库文件放在了正确的地方,所以只要把这里的.db文件的名字改成我们之前名字就好。配置完成点确认开始安装,此时Typecho会提示安装程序检查到原有数据表已经存在,证明我们配对了。选择使用原有数据即可。不出意外的话,会出现如下界面。如果你也到了这里,恭喜你迁移基本成功!可以进入博客界面看看数据都在不在常见问题明明密码正确,但就是登录不进管理界面,点击登录总是被重新定向到登录页,原地tp问题解析:如果站点是通过HTTPS访问的(比如https://blog.simuoss.cn),但Typecho内部没有正确配置为使用安全连接,会导致登录后Session或Cookie处理异常,从而被重定向回登录页。解决方案:在Typecho根目录下的 config.inc.php 文件中,添加以下代码并保存:define('__TYPECHO_SECURE__', true);这行代码告诉Typecho当前环境是安全的(HTTPS),应该生成安全的Cookie。保存后,运行以下指令重启Typecho:docker compose restart # 如果你不是root,使用sudo docker compose restart此时重新登录,就能进管理后台了。进入后台后显示:[升级程序] 检测到新版本!但点升级后报500 SERVER ERROR或DATABASE QUERY ERROR此时先使用以下指令重启:docker compose restart # 如果你不是root,使用sudo docker compose restart如果还是报错,再看下面的解决方案。问题解析:在Docker容器中,Web服务器进程是以特定用户(通常是 www-data)身份运行的,但这个用户不一定有数据库的写入权限,所以升级修改数据库结构时就会失败。解决方案:使用下方命令进入typecho容器内部,并授予www-data用户所有权:docker exec -it typecho-server bash # 进入容器内部命令行。如果你不是root,使用sudo docker exec -it typecho-server bash chown -R www-data /app/usr/ # 将整个目录的所有者设置成`www-data`然后退出容器并重启服务:exit # 退出容器 docker compose restart # 如果你不是root,使用sudo docker compose restart重启后再点击完成升级按钮,即可安全升级到最新版本。如果不重启,直接点升级按钮,还是会报500 SERVER ERROR。这时候不用担心,重启后就可以正常进入管理后台了。如果你在进行这些操作之前已经点过完成升级按钮了,就需要在执行完上述流程之后,先删掉已经损坏的.db文件,重新复制来原先的.db文件,然后使用docker compose restart重启服务,重新进行升级流程。如何迁移主题?前文提到,只要把之前的typecho\usr\themes文件夹复制过来即可。复制来后重启服务,主题就回来了。docker compose restart # 如果你不是root,使用sudo docker compose restart参考链接:Typecho 登录返回 302 的解决方法致谢:阿里Qwen:Debug时帮我提供了很多思路
2025年09月21日
11 阅读
0 评论
0 点赞
2025-01-18
【2025.1 Datawhale AI+X 共学活动】Fun-Transformer —— Task2:Transformer
Datewhale组队学习Transformer结构概述1. Attention 机制1.1 引入Attention机制 Attention机制最初是为了改进基于Encoder-Decoder的神经机器翻译系统而提出的,解决了RNN/LSTM在处理长序列时的长程依赖问题。传统的Encoder-Decoder模型通过编码器生成一个固定长度的上下文向量,解码器基于该向量生成输出。然而,这种方法在处理长句子时效果不佳,因为编码器难以有效总结长序列信息。Bahdanau等人(2015)提出了Attention机制,允许模型在生成每个输出时动态关注输入序列的不同部分,从而更好地捕捉长距离依赖关系。1.2 Attention机制的工作原理 Attention机制的核心是“加权求和”。它通过以下步骤实现:分解输入:将输入序列分解为单个元素(如单词)。分配重要性:根据每个元素与当前任务的关联性,分配一个权重。加权求和:根据权重对输入元素进行加权求和,生成上下文向量。Attention机制的优势在于它能够动态地为输入序列中的不同部分分配不同的权重,从而更好地捕捉序列中的关键信息。1.3 全局注意力与局部注意力全局注意力:考虑所有输入元素的隐藏状态,计算复杂度较高,适合处理较短的序列。局部注意力:只考虑输入序列的一部分,减少了计算量,适合处理较长的序列。局部注意力通过预测对齐位置和定义注意力窗口来实现。2. Transformer模型2.1 Transformer模型架构 Transformer模型由编码器和解码器组成,每个编码器和解码器层包含自注意力机制和前馈网络。Transformer通过自注意力机制捕捉序列中的全局依赖关系,并通过位置编码引入序列的顺序信息。2.2 Transformer的工作流程 Transformer通过自注意力机制为每个输入元素生成多个注意力分数,从而捕捉序列中不同元素之间的关系。例如,在处理代词“it”时,模型可以通过自注意力机制确定“it”指代的具体对象。2.3 Transformer的发展历程 Transformer模型自2017年提出以来,迅速成为自然语言处理领域的主流模型。后续的BERT、GPT等模型基于Transformer架构,进一步推动了NLP技术的发展。2.4 Transformer对seq2seq模型的影响摒弃RNN结构:Transformer完全摒弃了RNN结构,使用自注意力机制处理序列数据,提高了并行计算能力。引入自注意力机制:自注意力机制允许模型在处理每个序列元素时考虑到序列中所有其他元素的信息,有效捕捉长距离依赖关系。位置编码:由于Transformer没有递归结构,位置编码被引入以保留序列的顺序信息。训练效率提升:Transformer的并行化处理显著提高了训练效率,能够处理更长的序列。2.5 迁移学习与预训练模型 Transformer的成功推动了预训练模型的发展,如BERT、GPT等。这些模型通过在大规模语料上进行预训练,然后在特定任务上进行微调,显著提升了NLP任务的性能。3. Transformer vs CNN vs RNN计算复杂度:Transformer的自注意力机制计算复杂度为O(n²d),RNN为O(nd²),CNN为O(knd²)。当序列长度n小于维度d时,Transformer的计算效率更高。并行操作数量:Transformer和CNN的并行度较高,而RNN由于序列依赖关系,难以并行化。最长计算路径:Transformer的最长计算路径为O(1),而RNN为O(n),CNN为O(n/k)。4. 输入嵌入与位置编码4.1 词嵌入(Word Embedding) 词嵌入通过将单词映射到低维向量空间,捕捉单词的语义信息。可以使用预训练的词嵌入(如Word2Vec、GloVe)或随机初始化的词嵌入。4.2 位置编码(Position Embedding) 由于Transformer没有递归结构,位置编码被引入以保留序列的顺序信息。位置编码通过正弦和余弦函数生成,能够捕捉序列中元素的相对位置关系。词向量生成过程总结词向量是将自然语言中的词语转化为计算机可理解的数值向量表示的过程。词向量的生成方法主要分为两类:基于统计的方法和基于神经网络的方法。以下是词向量生成过程的详细总结:一、引言词向量的核心目标是将自然语言中的词语转化为计算机可处理的数值向量。词向量的生成方法主要包括:独热编码(One-hot Encoding):稀疏表示,每个词用一个高维向量表示,向量中只有一个位置为1,其余为0。分布式表征(Distributed Representation):稠密表示,每个词用一个低维稠密向量表示,向量中的每个元素都是实数。分布式表征能够捕捉词语之间的语义关系。Word2Vec 是生成分布式表征词向量的主流方法之一,其他方法包括 LSA、PLSA、LDA 等。二、基于统计的词向量生成方法(一)词袋模型(Bag-of-Words, BoW)原理:将文本视为词的集合,忽略词序和语法结构。每个文本表示为一个向量,向量的每个元素对应词汇表中的一个词,值为该词在文本中出现的次数。构建过程:构建词汇表:统计语料库中所有不重复的词。对每个文本,统计词汇表中每个词的出现次数,生成向量。缺点:忽略词序和语义信息。向量维度高,计算成本大。(二)TF-IDF(词频-逆文档频率)原理:在词袋模型的基础上,引入词的重要性权重。TF(词频):词在文本中出现的频率。IDF(逆文档频率):词在整个语料库中的稀有程度。TF-IDF = TF × IDF。构建过程:计算每个词的 TF 和 IDF。将 TF 和 IDF 相乘,得到每个词的 TF-IDF 值。优点:能够体现词在文本中的重要性。缺点:仍然无法捕捉语义信息。对常见词(如“的”“是”)的权重可能过高。三、基于神经网络的词向量生成方法(一)Word2Vec原理:通过神经网络学习词的分布式表示。两种主要架构:CBOW(Continuous Bag-of-Words):根据上下文预测中心词。Skip-Gram:根据中心词预测上下文。训练过程:CBOW:输入:上下文词的 one-hot 编码。输出:预测中心词的概率分布。Skip-Gram:输入:中心词的 one-hot 编码。输出:预测上下文词的概率分布。通过反向传播算法优化模型参数。优点:能够捕捉词的语义信息。支持词向量的语义运算(如“国王 - 男人 + 女人 ≈ 女王”)。(二)GloVe(Global Vectors for Word Representation)原理:结合统计方法和神经网络方法,基于词的共现矩阵学习词向量。训练过程:构建词的共现矩阵。定义目标函数,最小化预测共现概率与实际共现概率的差异。通过优化算法(如随机梯度下降)更新词向量。优点:有效利用语料库的统计信息。训练速度快,适合大规模语料库。四、词向量的完整生成过程(一)数据收集与预处理阶段收集语料库:获取大量文本数据(如新闻、论文、社交媒体等)。文本清洗:去除噪声(如 HTML 标签、特殊字符)。分词:对中文等语言进行分词。构建词汇表:统计语料库中所有不重复的词,并为每个词分配唯一索引。(二)模型选择与架构设计阶段基于统计的模型:词袋模型(BoW):简单,忽略词序。TF-IDF:引入词的重要性权重。基于神经网络的模型:Word2Vec:CBOW 和 Skip-Gram 架构。GloVe:基于共现矩阵学习词向量。(三)模型训练阶段定义目标函数:最小化预测结果与真实标签之间的误差。选择优化算法:常用算法:随机梯度下降(SGD)、Adam 等。训练过程监督与调整:监控损失值,调整超参数(如学习率)。(四)词向量生成与评估阶段生成词向量:训练完成后,为词汇表中的每个词生成词向量。评估词向量质量:通过词向量之间的相似度评估语义关系。在下游任务(如文本分类、命名实体识别)中评估词向量的性能。欢迎各位大佬在评论区交流&批评指正!Datewhale组队学习参考链接Datawhale AI+X 共学活动 Fun-Transformer —— Task2:TransformerAttention Is All You Need
2025年01月18日
7 阅读
0 评论
0 点赞
2024-08-18
从零开始注册Hugging Face账号到部署网页应用
背景问题引入你是否遇到过这样的情形:开发好了自己的网页应用,但是苦于手头没有云服务器,或是有云服务器但是环境搭建起来太麻烦,最终导致无法给朋友们展示?那我就要向你推荐 Hugging Face 了!Hugging Face 简介Hugging Face 是一个以自然语言处理(NLP)为主的人工智能公司,提供开源工具和平台,旨在推动机器学习和 NLP 技术的发展。Hugging Face 有一个 Spaces 在线平台,用于创建和分享机器学习应用。用户可以构建、测试和展示自己的模型和应用程序,支持多种机器学习框架和库。Hugging Face 致力于简化和加速 NLP 技术的应用,推动开源和社区驱动的创新。注册与搭建注册并获取Access Tokens进入Hugging Face官网按正常流程进行注册注册完成后,先不要按照自动跳转的官方教程进行部署进入以下链接:获取Access Tokens点击左上角 Create new token 按钮,并选择 Write 权限,确定。 此时,一定要好好保存你的Access Tokens,这个私钥不会在远程服务器存储,如果忘记或者丢掉就只能重新获取一个了。使用 HuggingFace CLI 从本地创建远程网页应用在你开发当前应用时使用的python环境中下载 HuggingFace Hub:pip install huggingface_hub运行以下命令,使用CLI登录HugginFace账号:huggingface-cli login在其中粘贴你刚才获取的 Access Tokens。如果一切顺利,现在就已经登录上了。使用以下指令创建远程仓库:huggingface-cli repo create 你的仓库名 --type space --space-sdk {gradio} -y其中,--type space是说创建了一个space仓库,用来发布网页。--space-sdk {gradio} 是说该网页应用使用Gradio构建。如果你使用streamlit或其他构建,可以修改成你需要的({gradio,streamlit,docker,static},可以多选),也可以不写这一条,随后配置。创建成功后,找一个合适的目录,将仓库克隆至本地:git clone http://huggingface.co/spaces/你的名字/你的仓库名如果你是在 C:\WorkSpace 运行的该指令,那么仓库目录将会被下载到 C:\WorkSpace\你的仓库名。使用cd命令进入你的仓库,会发现当前目录一共有两个文件,分别是 READEME.md 和 .gitattributes。现在,你可以把你先前的项目文件目录复制进来了。不过要注意的是,项目的入口文件一定要是根目录下的 app.py,才能在上传时自动构建。你可能需要稍作修改。在上传至space之前,你还需要生成一份 requirements.txt 依赖文件。如果你还没有生成,推荐使用 pipreqs 工具自动生成。在工作目录下执行:pip install pipreqs pipreqs ./ # 在当前目录自动搜寻依赖,不需要指定入口文件现在,自动生成的requirements.txt应该已经在你的目录下了。在上传至space之前,推荐创建一份 .gitignore 文件,避免将目录下一些编译缓存或不必要的垃圾文件上传。一份 .gitignore 文件的示例如下:# all .DS_Store Thumbs.db *.log *.tmp *.swp *.swo *.bak # Python __pycache__/ *.pyc *.pyo *.pyd env/ venv/ *.env # Visual Studio Code .vscode/ # macOS .DS_Store # Windows Thumbs.db desktop.ini # Custom在一切都准备妥当后,使用以下git命令上传至space。上传之前一定要留意上传的文件中没有你的个人信息。git add * git commit -m "first commit" git push这时,打开 http://huggingface.co/spaces/你的名字/你的仓库名 ,应该就可以看到应用程序在构建了。如果出现在构建中报错,或过程中哪一步卡住,可以在评论区留言或直接邮件联系我,或查阅官方文档寻找解决方案。{lamp/}参考链接:HuggingFace 官方文档HuggingFace CLI 命令全面指南
2024年08月18日
102 阅读
0 评论
0 点赞
1
2
...
4