@AoEiuV020JP 我在想驱动人生到底和 360 有什么 PY 交易。为什么会自动在后台安装 360 。
而且这些 dll 的签名全部是 360 的，这些文件全部无法删除，用工具也无法扫描到究竟被谁打开了。但是删除，Windows 总是提示被壁纸打开。
---- ------------- ------ ----
d---- 2024/2/28 17:19 photoCache
d---- 2024/2/28 17:18 res
d---- 2024/2/28 18:28 sehelper
d---- 2024/2/28 17:42 wd
d---- 2024/2/28 17:18 web
-a--- 2023/2/6 18:29 988224 360Base.dll
-a--- 2023/2/6 18:30 1448448 360NetBase.dll
-a--- 2023/2/6 18:30 175872 CrashReport.dll
-a--- 2024/2/19 17:12 421608 LocalServer.exe
-a--- 2024/2/19 17:11 1656040 Wallpaper.exe

TSLint/ESLint 选择一个，制定一下团队的编码规范(选取最大公约数)，提交到公司仓库跑一个 pipeline 做一个代码规范检测不久好了嘛。
我们目前前端规范是: 全部使用单引号或者`, 尽量避免"。

论文最坑，考两次，没有准备论文，全是挂在论文上，写死太累了。工作后写作的机会太少了。

坐标深圳，200 块，太抠了。

+1

请将问题描述清楚。

骑自行车，网球，乒乓球，羽毛球，感觉就没有球类运动是我无法坚持的，主要是没时间。有时间一天可以从早打到晚。

ikbc s300 mini 目前在用，不过 ikbc 的键盘如果你用习惯了，其它键盘都会用不习惯。ikbc w20 做工太粗糙了。

买过三块，给我的感觉就是不值，我不喜欢任何戴在手上的东西，唯一需要的就是跑步的时候，用手表连接 AirPods 打电话+听歌，这个是强需求，其它情况下都是吃灰。

@whileFalse
主要是就这一个仓库有问题，奇了怪了。

@111qqz 抱歉，我无法复现你的问题，我使用 A100 80GB 的，除了显卡驱动版本和你的不一致，其它都一致(包版本，cuda, cudatookit)，得到的结果如下：
显卡驱动是：NVIDIA-SMI 545.23.06 Driver Version: 545.23.06 CUDA Version: 12.3

输出张量: [[0.23729031]
[0.84413356]
[0.5424989 ]
[0.24236819]
[0.12169194]
[0.5741631 ]
[0.5093746 ]
[0.40847313]
[0.32745278]
[0.31726775]]

@111qqz 好的，我明天来看看。

@iseki 懒得和看不懂的人解释，go 选择在栈上常用的值类型中存储指针这种设计，并将其用在了内置的几大核心类型中，这个设计对于任何不是从 C 语言学过来的人理解其行为都是晦涩的，虽然是为了降低 GC 的负担，但我不认为这个设计是值得，这个设计导致 go 中很多基础的 API 看上去就非常丑陋，你说的 x=append(x, blah) 只是一个典型案例。go 的 goroutine 和接口组合都是很好的设计，降低了心智负担。但 slice 的底层模式导致的指针的无孔不入，对于我这个写惯了 js/java/c#/python 的人来说，是非常不喜欢的，明显破坏了编程语言的简洁和清晰度。

@Features explain 完全不能用来统计行数量，高频更新下返回的数据属于基本不可用垃圾数据。如果需要精确的分页。而且有复杂的查询，我的使用经验是 2000W+后就需要分表（如果是机械硬盘 500w ，有高频写入就需要分表了).
如果数据库是只读的(包括软删除）模式，使用自增 id 是一个解。其它模式我也没找到好办法再 mysql 中实现靠谱的分页。

@111qqz 最近搞到了 A100 显卡，你能发给详细的 conda list 信息给我妈，还有 nvcc 的版本和你显卡的驱动版本出来。
或者你现在找到原因 了嘛?

go 中很多基本的值类型都不是纯粹的值(凡是存储了指针成员的值类型都是如此)。
这导致在 Go 中很多时候需要思考指针，会造成一定的心智负担，复制一个带有指针的值类型对象会导致新值和原来的值底层能够同时访问访问指针指向的对象。
slice 的切片操作本质上是共享了底层的指针成员，然后修改了长度字段，我个人是不喜欢这种设计的(算是为了性能做的妥协).
如果值类型是不可变类型(即它的全部字段成员在初始化后就不再可变),那这种心智负担就会降低(string 类型就是如此)。

python 的包管理已经没救了。一路涌过来，发现没有任何一个包管理工具是靠谱，稳定的。conda 的依赖解析甚至是一个 NP-Hard 搜索问题，以后只会越来越慢。我现在都是 conda-lock 锁定所有版本，在不同操作系统上锁定一份，单最近发现 conda-lock 生成初始化锁定文件动辄都是几个小时。这个 python 的版本控制从在 python 推翻 2 的时候，就应该重置，现在这样，只会越来越难用。