这个玩意当时拿 C 也写了，想做成 #Android 应用的（谅我当时也不够了解对应安卓 API 反正用时查就行）

但是用 C 得手动管理 buffer ，这么简单的缓冲区控制，当时我实现了一半有 bug 好像就不行了，首先是不熟悉 TCP/UDP 的套接字(socket)通信，所以区间有效性、复用生存期什么的就没做好

当时是设计了应用域的 I/O 俩动态 realloc() buffer，写完我不知道类扫描器算法咋写了（显然不能缓冲区溢出也不能丟溢出的数据啊，就加了 MSG_PEEK flag），纯属底层细节太多导致的智商骤降（当时还以为 buffer 一次不能读完得拼接 recvfrom... 类似用 buffer 写的 OutputStream 就很麻烦，总而言之是 ensureSize 写错了没意识到大小是静态的），现在我就了解 SOCK_STREAM 的写法了。 (man socket.h)

C++11 Unicode 支持_Dablelv的博客专栏-CSDN博客
https://blog.csdn.net/k346k346/article/details/82016543

#cplusplus Unicode wchar/u16/u23 与 multibyte 转化（实际上就实现了 UTF8 字节序列到 int 码点的迭代），总结：
typedef codecvt<char16_t,char,mbstate_t> facet_t;
facet=use_facet<facet_t>(locale)
facet.out(mbstate, s0, s1, ps, ds0, ds1, pds)

#sysadmin #linux 这个
usbIP=ip route show 0.0.0.0/0 |awk '{print $3}'
usbTCP=12345
alias usbNc="ncat -i 1 ${usbIP} ${usbTCP} 2>/dev/null"
if [ "$1" = get ]; then
printf -|usbNc
echo
elif [ "$1" != '' ]; then
echo -n +echo "$1"|wc -c:"$1" |usbNc
fi

客户端脚本都写了🌚（附注：这里发不出反引号，等宽字部分就是被反引住 `` 的部分……
后来发现 nc -i 1s 及 2>/dev/null 的重定向可以一起去掉，明明不需要延时的（我脑抽了以为 stdin 重定向是等于启动新 nc 然后键入这些数据，不会EOF）

#tool #code #sysadmin #net 可惜不支持发文件🤔 当然这个也简单，本质上和发剪贴板没区别，只是剪贴板必须是字符串，文件的话不知如何保存好（可以开 intent）

Is there a compact equivalent to Python range() in C++/STL - Stack Overflow
https://stackoverflow.com/questions/13152252/is-there-a-compact-equivalent-to-python-range-in-c-stl

#cplusplus #Moha #mohu #code 重写 https://www.mohu.rocks/article/2085 ： https://pastebin.ubuntu.com/p/jRrhgFNV7h/

#Python #China #tech #plt #Low

不好意思有事我来打扰了。。。
https://t.me/dsuse/15301
请问一下这个对话发生在的群组是什么方便分享么（

#python #tech #pl #ce

鄙视链总感觉是在浪费时间。。我个人认为语言没那么重要，能完成想要的工作就行了

说真的感觉这个更友善。。

from itertools import islice
def zipWithNext(xs): return zip(xs, islice(xs, 1, None))

list(zipWithNext([1,2,3]))
==[(1, 2), (2, 3)]

#Python
关于 fibonacci 数列， #Haskell 里容易定义：
fibs = 1:1:(zipWith (+) fibs (drop 1 fibs))
这是基于 Haskell 的可复现(无副作用/纯)序列+惰性求值实现的，而 Python 里若用等价的 fibs = chain([1,1], map(operator.add, zip(fibs, islice(1,None)))) 不能成功——表达式组织出generator对象的关键在于 map(add, zip(xs, xs[1:])) 里 zip 的流视口，它肯定要引用靠 zip() 本身生成的数字。

再看 Haskell 的定义等式，其生成式缓存是全局的（当然实现法有很多种但），可以理解为 fibs, (drop 1 fibs) 持 length -2、-1 的索引（此时就没有“预支”流导致循环引用的问题）
fibs = [1,1]
def _fibs_gen(i,n):
fibz = islice(fibs,i,None)
fibz1 = islice(fibz,1,None)
fibs[i:i+n] = map(operator.add, zip(fibz,fibz1))
def gen(buf, op, n_chunk=5):
i0 = 0
while True:
op(i0, n_chunk)
i0 += n_chunk
yield* buf[i:i+n]

如果想写在一行内也可以，但需要 iself() 提供一个隐式上下文的流位置（才能引用自身 不然只能从流头开始），既然这样也就不得不使用 gen() 生成带视口的流了。
举个用例，当然索引的可变 boxed ref 弄 it=[i] 就行，关键在于让惰性流(其参数 lambda 的参数1)知道自己在对应 iself() 的什么位置就行。
fibs = iself(lambda fibs: chain([1,1], map(add, zip(fibs, drop(1,fibs)) )) )

Haskell GHC 可能没有这样简单，或许它是对 (drop 1 fibs) 进行了仅 1层 的惰性求值？这样性能很差，但写起来更有意思
（不对…… 理解错了， (drop1 fibs) 实际上不需要对「未求值的项」进行计算，它从一开始的 (1:1:) 就已经落后于序列尾2项了）
（所以说有些看起来了不得的东西原来只是太晦涩、不直接了吗……到底还是要缓存）

一般来说
fib 1 = 1
fib 2 = 1 -- (f 3) = (f 2)+(f 1)
fib n = (fib n-1)+(fib n-2) #Haskell #code

这是递推法，理论上无缓存性能很渣（当然真的函数式里 memo,cps 属于基础），而上面实现的 py 版则是动态规划（迫真）