该进程未tauri://localhost
文心一言被deepseek干免费了
MacOS 升级
MacOS从14 升级到15。
xcode需要从15升级到16； xcode升级后，xcode已经不能支持iOS12的开发了。
上一次升级MacOS 13 -> 14的时候，xcode也是被迫升级的，xcode从14升级到15之后，我的appcode（2022）就已经抱怨xcode版本太高了，让我降回去使用，然后就一直没使用appcode
各版本xcode支持的最低iOS系统版本：
Xcode各版本支持的系统版本如下：12
- Xcode 13：支持iOS 9及更高版本、tvOS 9及更高版本以及watchOS 2及更高版本的设备上调试。Xcode 13需要运行macOS 11.3或更高版本的Mac。
- Xcode 14：支持iOS 11.0到iOS 16.2.99的系统版本。如果项目需要支持iOS 9，可以通过修改SDKSettings.plist文件来实现适配。
- Xcode 15：支持iOS 12到iOS 17的系统版本。从2024年4月29日起，上传到App Store Connect的App必须是使用Xcode 15构建的。
- Xcode 16.1：支持iOS 18.1、iPadOS 18.1、Apple tvOS 18.1、watchOS 11.1和macOS Sequoia 15.1。Xcode 16.1需要在macOS Sonoma 14.5或更高版本的Mac上运行。
系统支持的最低版本要求：
- iOS：Xcode 13支持iOS 9，而Xcode 14及以上版本最低支持iOS 11。从2024年4月29日起，上传到App Store的App必须使用Xcode 15构建，支持iOS 12及以上的系统版本。
这些信息可以帮助开发者选择合适的Xcode版本和系统版本进行开发和测试，确保应用兼容性和顺利提交到App Store。
目前（2024年）xcode 15还是主流，还能构建iOS12系统上的APP，这些系统上的APP还能继续升级。
当苹果官方要求最低xcode版本为16的时候，就不可能构建出来支持iOS12系统的APP了，换言之，因为iPhone 5s的系统版本最高支持到iOS12，所以，iPhone 5s上的APP就不可能继续升级了。
小学数学问题
问题：
对于一组数字，在不改变原有数字顺序的情况下，删除 m 个数字，使得剩下的 n – m 个数字组成的数最大。
思路：
- 维护一个栈:
- 使用一个栈来存储当前选择的数字。
- 当遇到一个新的数字时，比较它与栈顶元素。如果新数字更大，并且可以删除栈顶元素（即 m > 0），则弹出栈顶元素。
- 处理剩余数字:
- 如果在遍历完所有数字后，还有剩余的删除次数 m，继续从栈中弹出元素直到 m 减少到 0。
- 构建结果:
- 最终栈中的元素即为保留的最大数。
AI编码实现：（这个实现运行结果不对）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
package main import ( "fmt" "strconv" ) func removeKdigits(num string, k int) string { var stack []byte for i := 0; i < len(num); i++ { digit := num[i] // 如果栈顶元素小于当前元素，并且可以删除栈顶元素 for k > 0 && len(stack) > 0 && stack[len(stack)-1] < digit { stack = stack[:len(stack)-1] // 弹出栈顶元素 k-- } stack = append(stack, digit) } // 如果还有剩余的删除次数，继续从栈中弹出元素 for k > 0 { stack = stack[:len(stack)-1] k-- } // 构建结果字符串，并去掉前导零 result := bytes.TrimLeft(stack, "0") if len(result) == 0 { return "0" } return string(result) } func main() { num := "27886483" m := 3 result := removeKdigits(num, m) fmt.Printf("删除 %d 个数字后，最大的数是: %s\n", m, result) } |
- 初始化栈:
- 使用一个切片 stack 来模拟栈的行为。
- 遍历输入字符串:
- 对于每个字符（数字），检查是否可以删除栈顶元素以使结果更大。
- 如果可以删除栈顶元素，则弹出栈顶元素，并减少剩余的删除次数 k。
- 将当前字符压入栈中。
- 处理剩余的删除次数:
- 在遍历完所有字符后，如果还有剩余的删除次数 k，继续从栈中弹出元素直到 k 减少到 0。
- 构建结果字符串:
- 使用 bytes.TrimLeft 去掉结果字符串中的前导零。
- 如果结果为空，则返回 “0”。
对于输入 num = “27886483” 和 m = 3，程序的输出将是：
|
1 |
删除 3 个数字后，最大的数是: 8883 |
这个结果确保了在不改变原有数字顺序的情况下，删除 3 个数字得到的最大可能的数。
补充：
stack[len(stack)-1] < digit 的这个逻辑 AI生成的时候是错的，写的是 stack[len(stack)-1] > digit； 手动修改后算法可用
由上面逻辑来看，真心不是小学生能够完成的。
bc命令占用CPU 100%
因为bc命令的没有了：
因为bc是在goland中的terminal中启动的，但是goland意外死掉了，所以，bc就没有tty了，所以bc不断的循环读取标准输入，每次都是快速失败，所以，bc占用CPU 100%
golang tcp keepalive
缘起： grpc-client 连接 grpc-server后，空闲连接的情况下，server端会每隔15s向client发送一个keepalive数据包； 从grpc-server的配置中没有找到这个15s的配置，有的只是一个2小时发送一次的应用层的ping包。为啥呢？
分析：
- 该数据包可能是系统自己发送的，查看一下sysctl -a|grep tcp |grep keepalive 如下：
按照这个配置，应该是75s一次才对，和实际的15s不符；难道不是系统发出来的？
- kill -19 PID后，发现间隔15s的数据包依然发送，说明肯定是系统发出来的
- 由于MacOS上的netstat 无法查看连接的Timer信息，于是使用Linux进行测试，发现keepalive的timer果然是从15s递减至0后就会发送该数据包（这里还发现当时间小于10s时，ss显示的时间单位是错的，把s写成了ms）。
- 一定是golang设置了一个和系统默认值不一样的keepalive； 那么是在什么时候设置的呢？从server端的Accept看起吧，发现Listen的时候有一个无法自定义的ListenerConfig，这里面有
@ net/dialog.go
Listen的时候，KeepAlive是0值，但是在newTcpConn的时候，检测如果是0值，就参考下面的默认值。
@ net/tcpsock.go
其实，在grpc/server.go 的grpc.Server.Serve()方法中已经特别说明了这个事情（而且仅就此问题做了说明）：
xdebug 的几种模式
容器的1号进程果然不一般
现象：
- 你无法kill掉容器的1号进程，包括kill -11 kill -6 ，包括 kill -9，因为内核对于进程空间的1号进程是特殊对待的，不会安装默认信号处理程序。
- 如果你的进程是容器中的1号进程，那么在进程崩溃的时候，是不会有coredump文件产生的。
Hi folks,
I have looked into this issue and I want to share the results of my investigation, which turned out to be quite intriguing.The contained application has PID 1, which means that the Linux kernel treats it as a standalone init process for this namespace. The Linux kernel handles signals differently for the init process than it does for other processes. Signal handlers are not automatically registered for this process, meaning that signals will not take effect by default.
Since the contained application does not have user-defined signal handlers and the kernel does not register the default ones, the SIGABRT signal sent by the abort function is not handled at all.
In this situation, abort tries to kill the application by executing a forbidden asm instruction “HLT”. As a result, the CPU sets the GPF interruption and the kernel kills the contained application withSIGSEGV, which leads to the exit code 139. Docker just sets its exit code accordingly.The easiest way to make the contained application to have the default signal handlers is to run docker with the flag –init.
For an expanded explanation on how signals are handled in a docker container, I have provided a detailed answer with visual examples in my article.
Perhaps we should expand the description in https://github.com/docker/cli/blob/v20.10.2/docs/reference/run.md#foreground and/or link to that post. Currently it mentions;
Note
A process running as PID 1 inside a container is treated specially by Linux:
it ignores any signal with the default action. As a result, the process will
not terminate onSIGINTorSIGTERMunless it is coded to do so.Contributions welcome if someone is interested.
参考：
How signals are handled in a docker container | Dmitry Danilov (ddanilov.me)
Exit codes in docker when a program aborts | Dmitry Danilov (ddanilov.me)
递归
A loop within loops, Seeking the base case to find, Endless paths unwind.
— create by openai