其实这是一个计划的三天适应性休息，不过因为一些事情没有完成延长了一天。期间我看了 N 集的三大民工漫之一 — 《火影忍者 疾风传》

（不过，看起来坏习惯还是依然存在嘛。还是不擅于管理时间，唉。
而且虽然没有上线，前两天也是有熬夜到 12 点左右的，这么说，只是比写代码讲 XXXX 的时候好一点点。 🤪

[In reply to ...]
啊，对不起，现在基本了解了；Python 的确提供了很多方便的列表操作语法

list[0] 这是最简单的 list.at(0) 解索引
list[0:10] 这是依据 slice 取 subsequence

list[0:-1:2] 就是 list.take(Range(from=0, to=list.length-1, step=2))

Python 因为比较『灵活』所以索引有两种：
+ 0..lastIndex, 数学里的 (0, size]
+ -1..-size, 代表 (size-1, -size]

比如，

xs=[1,2,3]; ys=[2,4,6]

Python 里可以用 List comprehension 定义 ys
ys = [x *2 for x in xs]

索引:

xs[-1] #=> 3
xs[-3] #=> 1

子序列:

xs[0:1] #=> [1,2]

加上 Range with step 后可以按『步』跳着复制

xs[0:-1:2] #=> [1,3]

list[:] 实际上是 list.subsequence(range(0, list.size-1))
list[::-1] 实际上是 list.subsequence(range(list.size-1, 0, -1))

以 -1 为步长复制的话，就是这个颠倒序的结果

啊，可惜我现在还是 2G 的说（马上

2019 年了，温习一下：4GB 在电脑上绝对称不上大内存，8GB 都称不上大内存。最近想要购买笔记本电脑的朋友们，尤其是高中毕业准备走进大学的朋友们，如果对自己专业软件所需的硬件配置不清楚，请咨询自己专业的学长学姐们。

#TT #PLT ... Typescript 渐进类型果然爽炸，Type notation 就可以讨论 value level 的事情，随便创建类型集合，甚至可以是 ("+" | "-")[] 这种...

累死我了 #TypeScript

#Java #Syntax

https://t.me/drakeets/1650 #bin #Telegram

啊，Telegram 最近支持的 Channel Preview 功能使得我不需要什么『内奸』帐号就可以 preview 某 Channel 的内容了
突然想解释一下这个，因为也比较简单嘛。

二进制计数法是一种位置计数法，它用于在机器中存储一定范围的数字（数位计数法）
因为其和数字电路的优异对应性，被广泛采用于现代电子计算机内。

保存整数值，其核心就是记录状态，把状态『编号』对应上数值。
10 进制里，一个数位有 10 种状态；10 位累积起来组合就有 10^{10} — 100 种，换到二进制里也是一样。

二进制无法和日常生活使用的十进制直接对应，但是可以和 16 进制以 4 bit <=> 0x0~0xF （4 位二进制对应 1 位十六进制）为单元直接对应

具体的二进制机器数运算比较复杂，这里不讨论（一部分是通过高层不可见的移位器、乘法器做到的，但算法抽象也是存在的）

0xF，15，如果不能保存 sign （符号）的话是 4 个 『二进制位』（bit）组合的极限了。
0xFF (255) 则是 8 bits 储存状态的极限了

0xFFFF_FFFF 数一下有几个 F: 8 个，就是说，对应 8*4=32 位的二进制数值

那么为什么不能？我们知道 Kotlin 是安全的，安全有时候也意味着应该尽可能避免溢出(overflow)整数值。
计算机是基础数学的实践，当然应该首先为性能考虑 — 不要想直接让处理器 ALU(Arithematic Logic Unit) 实现无限长度精度的数值，太慢了。

那 4 bits 最大能储存到 0xF 个状态（以二元状态混合叠加成 N 元状态就是我们计数的方式，0x1_0 = 2×2×2×2 = 16）可是到了这个地步，满了，记不下数了怎么办？
回滚(rollback)到最小值或者溢出(overflow)，这是很多机器给出的方式，当然也有程序员自己考虑溢出情况的方式 （比如 GCC 的 __builtin_sadd_overflow）

— 所以为什么，不能 (0xFFFF_FFFF as Int)

看到这个数的时候，可能觉得它反射了底层二进制存储的状况吧（其实也未必尽然，只是抽象层次不同而已，比如还存在有 byte order 的情况）。
其实还差一点：这只是语言对于 literate integer 字面量（当然是常量）的表示语法糖而已，它缺了一点：数值的表示方式，是有符号(signed)还是无符号(unsigned)

Kotlin multiplatfrom 里是有 kotlin.UInt 无符号 32-bit integer 的，这种类型是包含 0xFFFF_FFFF 这个值的

可问题在于，kotlin.Int 是要有一位来记录数值符号的，这导致 32-bit 的状态叠加得留一位，来给余下的 31 位指定其符号是正 (+) 是负 (-)

对应到 LLVM 里，i1 类型就只有符号部分 (+) (-)，它只有两个状态，所以被当作同样二态的 boolean 用，i1 的真值只能是 +0 或者 -0

结果，0xFFFF_FFFF 实际上就溢出了，因为表示它至少需要 32 个二进制位，而 kotlin.Int 只能表示 31 位的正/负数而已。
32-bit 最大值 2^{32} 是 4294967296 — 16 进制 0x100000000

试试把这个值的 succ (后继数)转换到 kotlin.Int: (0x100000000+1) as Int, 你会得到

java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer

而真正的 Integer.MAX_VALUE 是 2^{32}-1 （去掉一个 "0" 状态） 0x7F_FF_FF_FF (2147483647)

数值类型宽度自动提升(widen)，或者如果你写成常量的形式进行常量折叠(constant folding)，Kotlin 编译器，已经自动选择了 Long 64-bit 的数值类型来表示溢出的数值了。

— 所以为什么 Java 里就可以？魔法 Java

因为 Java 支持数值类型可以随便溢出啊，应该说是被自动推导得比较有风格吧。至少在语义上是对的，No implicit conversations、representable using 32-bits。你 explicit 地声明它是 int 的，你为溢出负责。

class Wrong32Bit {
public static void main(String... args) {
int x = (int) 0xFF_FF_FF_FF;
System.out.println(x);
}
}

你会得到一个 (-1)
Kotlin 里就是 type error

得了吧，白活了，睡觉

明天就回老家喽~

#Android 第一次听到辅助服务（无障碍服务, Accessiblity service）会导致手机变卡... 不过想想也是有道理的，那么多数据要跨 ring 级别传输呢

—
Ring 级别：计算机系统底层分级权限控制
类似的就是操作系统内核支持的进程访问权限控制呢。

其实这里的误会大概是我开始根本没有考虑 type checker 感受导致的，过几天我会做个总结。

我是搜索 flatMap keyword 看到这里的。搜索是原因是我在某个地方看到了 RxJava 的 flatMap operator

#Kotlin 咳咳，其实如果 @UseExperimental 支持的话，大家可以用 @file:UseExperimental 哦。
这也是 Kotlin 的一个改进（不是语法糖^1），Java 里 Annotation 是不能加在 File 上的，File 本身不是可见的语法元素。
—
^1 语法糖：对某种语法表述的惯用性简写，e.g. C++ 的 std::string abcs("abcdefg..."); 就是 std::string abcs = std::string("abcdefg..."); 的惯用法

#Java #Android 现在来告诉你们（虽然一直以来都对我自己来说不好...）
所谓『越复杂越容易堆砌，越简单越难于设计』究竟是什么。

我本身没有多少工程经验，记忆力也比较差，但是不知道为什么，就是看不得重复冗余的代码... 真的，哪怕有一点正常的重复我都不能忍... 😵
我本身不擅长重构和程序变换，程序分析也够呛，但总是喜欢尽一切可能地抽提程序逻辑，甚至到了使用面向对象多态和继承特性的地步（当然我一般更喜欢函数式的说...）。

文章（我知道一些工程派可能非常不屑，因为我实际上没有几个拿得出手的应用、理论上也没有太大收获，我还没有造出自己的解析器框架却好像说了很多自己『自以为高大上其实是欺负人骗人』的话。这也是我自己一直的感觉）
里，提到了一些 #Haskell 代码，不过虽然 Haskell 的链表是惰性求值的（对于工程派来说，它就可以实现 Stream）我依然不怎么理解那种代码呢

-- zipWith 从来没有完全停机过，它只是挂起，因为 Haskell 的 [a] 关于它的 head/tail 惰性求值
fibs' :: [Int]
fibs' = 0 : 1 : zipWith (+) fibs' (drop 1 fibs')

相信看到它的你们也一样，我是完全蒙蔽的，我看过 zipWith 的定义，也在纸上模拟过，只是没有完全拿到『那个』直觉而已。

quickSort :: Ord a => [a] -> [a]
quickSort xs
|length xs <2 = xs
|otherwise = quickSort lts ++ eqs ++ quickSort gts
where
x = let mid' = (length xs `div` 2) in (xs !! mid')
lts = [ l | l <- xs, l < x ]
eqs = [ x'| x'<- xs, x' ==x]
gts = [ r | r <- xs, x < r ]

-- forall i. list[i] <= list[i+1]
-- forall x r in join2(list). x <= r
ordered xs
|length xs <2 = True
|otherwise = forall (zipWith (<=) xs (tail xs))
where forall = foldl (&&) True

prop_qsortOrdered inxs = ordered (quickSort inxs)
where _ = inxs :: [Int]

import Test.QuickCheck (quickCheck)
quickCheck prop_qsortOrdered -- OK, passed 100 tests.

这就是所谓『简单』的设计。看起来就是很简洁没几行字而且没有符合某种刻板的缩进格式，其实没有一定的积累，你写不出这种代码。
程序设计和抄改代码是有区别的。

哪怕是对于 Android Build 的 Buildscript 都去记住其中的名字和属性。到了什么都靠背、默写的阶段，才有能够写出无余赘代码程度的能力呢。
对于简单的顺序编程、单次异步回调、事件监听、流/协程、多线程处理、多任务，靠的都只有一个 — 对『程序本来应该做什么』的直觉

这也正是我在文章里说的，当然，写完我发现也是王垠说的。虽然我觉得提到他也没太大意义^1... 🙈
— 刚入门的程序员扣老师枚举出的语法，战战兢兢地拿那一堆惯用法组织自己的逻辑、加入实际项目的工程师扣刻板复制的项目管理、设计模式、代码风格，可是真正的程序设计大师只扣对编程的直觉和程序本身的灵魂，对他们来说已经没有入门者的条条框框、刻板的约束了，回归初心，他们看到的是程序所做的事情本身，是程序的灵魂；换十种兼容的语言和底层抽象去描述也不是问题，因为他们已经站得足够高，无须顾虑脚下低处的迷雾笼罩而可以自由地放飞视线，不识庐山真面目，只缘身在此山中。

刚才看到某频道（这里不说）的 Rx 代码后又忍不住想重写一下... 那就这么干吧

首先，Rx 里要一个流的 handler 就是：onNext((Item) -> *) onComplete() onError((Error) -> *)
当然你可以不处理错误，会 ES6 Promise 的同学会觉得这是一种『持续性发射』的 Promise。
至于状态转换、信号.... 呃（这也是我最近在构筑的直觉模型，所谓直觉，这里就是类似在脑中对模型进行可视化的骚操作而已）

一个 Promise 有三个状态：
pending(0), resolved, rejected
pending -> resolved
pending -> rejected

pending 是初始状态、可以状态转移到 resolved 和 rejected 抽象状态。
要在状态变迁时收到通知添加处理逻辑，对于
pending -> resolved 使用 then(_: Function<R>), 它可以嵌套（回调链条），本身是 Promise<E, R>，说起来这又涉及函数式编程范畴论（关于 flatMap）的一些工程应用了...
pending -> rejected 使用 catch(_: Function<E>)

一个流大概是有三个状态，可以类比：active, failed, finished
active 状态有一个信号(signal) nextItem 使用它监听：

onNext(Function<T> consumer): Stream<T>;

然后，对于一个 Stream，就有了『订阅者』（信号 dispatcher）和『监听者』（信号 handler）的角色，订阅者负责把『流』的更新事件交给『监听者』处理。
（以上内容是我猜的... 可能不准确甚至谬误）

首先 dispatcher 我们基本认为是 application scopend 或者至少是 page scoped，那么就应该先弄一个设置好 dispatcher 的 stream。

val foundItems: Single<List<Found>> = if (currentChapterFilter.checked) doSearch(in = Chapter) else doSearch(in = Book)

那么为了创建查找结果，就应该使用 singleOne 和 singleAll 流方法，我猜他们是通过逐个 item 收集到 T(one) 和 Stream<T>(all) 的

articleDao.singleOne(selectedArticleId) 就创建了一个流... 不过我们得为流设置 scheduler 和 observer... 可能，而且流上还可以加处理高阶函数 xs.map(adds(1))
所以抽提一下 single* 选择方法，它设置好一个（此模块的）流，给它指定 scheduler 和 observer

fun <T> itemStream(stm: Stream<T>): Stream<T> = stm.scheduleOn(ioScheduler).observeOn(Schedulers.single())

还有 map(eta) & join(mu) 的 flatMap (一知半解中，因为范畴论很难懂)
接受一个返回 Fct<T> 的函数，然后把所有 map 完了 join() 起来成为 Fct<T> (rather than Fct<Fct<T>>)

这样。原来的查找代码可以这么写。

val firstone = itemStream(articleDao.singleOne(selectedArticleId)).map { it.first }
val allpassed = itemStream(articleDao.singleAll(selectedFolderId))
  .toFlowable().flatMap(Flowable::fromIterable then articleToFoundsMapper)...

此刻还都是 folders -> articles 的形式（flatMap join 了所有文件夹子树）（关键在于这个『都』，一般都是这么干的，尽可能保证数据结构一致）
然后进行 Item -> Found 变换(then · 函数 compose)

然后 allpassed 还 flatMap(Flowable::fromIterable) 的形式... 其实这个逻辑本身应该被抽提为 joinAll(), 欸算了

toList

, collect(Collectors.toList()) 我就不想说了
其实看你们工程的时候在用，我也觉得 java.util.stream.Collectors 只应该有 toList 静态字段，而不是方法，看起来怪怪的。本来只应该是一个处理过程却好像要什么专门的计算才能得到它...

...
最后，调用链写的老长，该不会是忘了类似 builder pattern 之类的东西出现到底是为了什么吧。是我看任何冗余都不顺眼么...

val add1 = SumBuilder(1)
println(add1.plus(2).plus(-1).sum())

关键在于 add1 这个『对象』（操作和数据共同的封装）的复用啊！！！
—
^1 这里不该和王垠的雷同观点扯上关系，这只是想要暗示什么。请参看原文章正文内容。

推荐一篇文章 Schedulers in RxJava
这里面 Rx 的 Stream 其实叫 Observer...

Scheduler 就是 worker pool. 也蛮符合直觉的

val sched = Schedulers.immediate() // newThread()
sched.createWorker().let {
it.schedule {
println("Immediately")
}
it.unsubscribe()
}

对 Android 来说也有 android.os.Looper



val sched = Handler(Looper.getMainLooper())

sched.post {
println("Work executed")
}

#reveng 啊，说起来 drakeet 又开始在纯纯写作的代码保护上下工夫了... 100% 胜率退役么...

不知道他有没有应对动态调试的情况... 机器代码也会被逆向分析的情况、月读运行时内存的情况、不过，显然我现在不能也没时间去看了。

我不是密码学爱好者，但我很清楚，程序映像是被动地『被』解释的、用户看到的是解释器依照它看得懂的程序做到的、解释器是你控制的。
程序是 Ring 3 的，它看不到很多东西。而你是 root，你操纵一切。

让代码完全被保护就像使水不湿、信息不被复制一样，是做不到的，只能尽可能提升成本。
『向左看的同时又像右看』么，可是现实世界里不存在影分身这种东西啊。

『破解』爱好者们啊，这一点狭隘的视角、孱弱的直觉模拟、程序设计都做不到的程度，也能自称『神』么。
连计算机科学的基础，PLT，程序设计语言理论、操作系统都不了解的话，又怎么能称得上是破解者。

说起来，其实集成电路 circuit 和嵌入式的设计反“破解”还更为令人骄傲一点，各种 MCU 的厂家都做了很好的代码保护，物理上反破解。

其实这又有什么的，不如自己好好继续看自己的程序分析... 可是我最近又咸鱼了... 自己开发反编译器么
LLVM 编译器也要来一个哦

非常不负责任地 Archive 了 @drakeets 的 public 内容，因为 channel preview 可以让未登录用户查看 public 的信息，而我的帐号反而被屏蔽没有 view 权限。preview 功能实际上导致了可能的权限逆转。