篡改猴脚本可以在不同时机执行:
如果我们需要通过修改window对象来模拟一些特殊情况,就可能需要在页面加载的第一时间来设置window对象,就需要让篡改猴脚本第一时间执行,修改方式如下:
DevOps
篡改猴脚本可以在不同时机执行:
如果我们需要通过修改window对象来模拟一些特殊情况,就可能需要在页面加载的第一时间来设置window对象,就需要让篡改猴脚本第一时间执行,修改方式如下:
更新前:
更新后:
结论:
使用terminal时,快捷键很重要,如:
alt+b (backword): 光标左移一个单词
alt+f (forword): 光标右移一个单词
alt+. : 自动填充上个命令的最后一个单词
但是,默认情况下,可能这个不好使,需要设置 terminal.integrated.macOptionIsMeta ,选中复选框如下:
或者 ⌘ + shift + p 打开settings.json ,添加如下配置:
该进程未tauri://localhost
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 个数字组成的数最大。
思路:
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) } |
对于输入 num = “27886483” 和 m = 3,程序的输出将是:
1 |
删除 3 个数字后,最大的数是: 8883 |
这个结果确保了在不改变原有数字顺序的情况下,删除 3 个数字得到的最大可能的数。
补充:
stack[len(stack)-1] < digit 的这个逻辑 AI生成的时候是错的,写的是 stack[len(stack)-1] > digit; 手动修改后算法可用
由上面逻辑来看,真心不是小学生能够完成的。
因为bc命令的没有了:
因为bc是在goland中的terminal中启动的,但是goland意外死掉了,所以,bc就没有tty了,所以bc不断的循环读取标准输入,每次都是快速失败,所以,bc占用CPU 100%
缘起: 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()方法中已经特别说明了这个事情(而且仅就此问题做了说明):