最新

嘿，HN！我在婚礼后创建了这个工具，因为我有5000张照片需要整理。 关键见解：大部分照片整理的时间都花在审查近似重复的照片上。专业摄影师通常会连续拍摄，因此你会得到同一时刻的10张以上的照片。 PicPick利用CLIP嵌入技术对视觉上相似的照片进行聚类，然后添加人脸识别功能，以保持组内的一致性（这样你就不会因为“新娘与父母”和“新娘与朋友”看起来相似而混淆）。 技术栈： - 使用CLIP进行语义相似性分析（不仅仅是感知哈希） - 使用face_recognition（dlib）进行人脸检测 - 在组合特征上进行DBSCAN聚类 - 使用FastAPI和原生JS构建用户界面 - 使用SQLite存储所有数据 这项技术将我的审查集从5000张减少到了大约1000个聚类，我在几个小时内将其过滤到300张用于相册，而不是几天。 聚类参数是可调的——对于重复较多的专业拍摄可以设置得更紧凑，对于休闲照片则可以放宽一些。 欢迎反馈！特别是在以下方面： 1. 更好的聚类算法（目前使用的是基于CLIP嵌入 + 时间戳 + 人脸向量的DBSCAN） 2. 快速审查的用户界面改进 3. 处理没有人脸的照片（风景、食物等） 该工具完全离线工作，无需云上传。

嗨，HN， 我一直在开发一种名为XXML的实验性编程语言。这个项目源于我在系统语言中遇到的一些挫折： - 拥有强所有权的语言往往避免运行时反射。 - 具有丰富反射的语言通常依赖于垃圾回收（GC）或放弃内存保证。 - 编译时代码生成通常需要一个单独的宏语言。 我想探索这些权衡是否真的必要。 XXML的目标 XXML是一种静态类型的本地语言，具有以下特点： - 使用显式的所有权和借用（不使用垃圾回收器） - 在遵循所有权规则的同时支持运行时反射 - 允许使用普通语言结构进行编译时代码生成，而不是宏 - 编译为LLVM IR并生成本地二进制文件 反射API受到限制，因此不安全的所有权操作在编译时会被拒绝。我们的目标不是“无论如何都要动态”，而是在不失去安全性的前提下进行自省。 目前的应用场景 我正在探索的一些具体用例： - 为本地应用程序提供安全的插件/模块系统 - 自动生成序列化（例如，JSON/RPC），无需宏 - 可以推理用户类型的调试和检查工具 - 受益于结构化语法的声明式领域（UI/布局/资产图） 这不是 这是一个早期阶段的项目，绝对还不适合生产使用： - 生态系统非常有限 - 语言仍在不断发展 - 文档和工具尚不完整 我特别希望得到那些在以下领域有经验的人的反馈： - 编译器 - 语言运行时 - 具有大量序列化或插件边界的系统 代码 GitHub 仓库： [https://github.com/ThatSoulyGuy/XXMLCompiler](https://github.com/ThatSoulyGuy/XXMLCompiler) 或 [https://xxml-language.com](https://xxml-language.com) 我特别希望得到关于以下方面的批评： - 所有权模型 - 反射安全边界 - 这个设计的根本缺陷 感谢阅读 — 欢迎提出问题。