Forwarded from Deleted Account
如果说返回一个闭包是 lambda lifting……
这里的 "lift" 是不是在 定义顺序上 将
这里的 "lift" 是不是在 定义顺序上 将
return lambda: 变成 def some_fun: ...def __call__: 的那种 "lift"？Forwarded from Deleted Account
https://www.minizinc.org/doc-2.4.2/en/predicates.html
Clearly, the intention of the modeller is that x=3, y=0 should be a solution. This requires the compiler to take care not to “lift” the constraint x=y*y out of the context of the function, because that would prevent it from finding any solution with x=3. You can verify that the set of solutions contains x=3, y=0 as well as the expected x=1, y=1, x=4, y=2 and x=9, y=3.
https://combinatorylogic.github.io/mbase-docs/lang0.html#lifting
Lambda lifting pass will turn all the nested lambda functions into toplevel definitions, capturing closure environments where necessary. We did the lexical scoping pass previously, and now all the names inside any given context are unique, which makes it easy to produce lists of externally defined variables used under each lambda context.
https://groups.google.com/forum/#!topic/golang-dev/JAgv8kBTgk4
Can I rely on finalizers on pointers to local variables? If so, should the documentation be updated? If not, is it reasonable to lift the restriction in general in the future? How?
https://github.com/latex3/latex3/issues/410
Presumably we have to wait for the lock to lift,
Clearly, the intention of the modeller is that x=3, y=0 should be a solution. This requires the compiler to take care not to “lift” the constraint x=y*y out of the context of the function, because that would prevent it from finding any solution with x=3. You can verify that the set of solutions contains x=3, y=0 as well as the expected x=1, y=1, x=4, y=2 and x=9, y=3.
https://combinatorylogic.github.io/mbase-docs/lang0.html#lifting
Lambda lifting pass will turn all the nested lambda functions into toplevel definitions, capturing closure environments where necessary. We did the lexical scoping pass previously, and now all the names inside any given context are unique, which makes it easy to produce lists of externally defined variables used under each lambda context.
https://groups.google.com/forum/#!topic/golang-dev/JAgv8kBTgk4
Can I rely on finalizers on pointers to local variables? If so, should the documentation be updated? If not, is it reasonable to lift the restriction in general in the future? How?
https://github.com/latex3/latex3/issues/410
Presumably we have to wait for the lock to lift,
Forwarded from Deleted Account
原来 Lambda lifting 和 anonymous subclass 是一个思想啊，给 lambda 一个更广的作用域
Lambda lifting pass will turn all the nested lambda functions into toplevel definitions
代码可以复用、captured external value 很容易进 lexical scope
Lambda lifting pass will turn all the nested lambda functions into toplevel definitions
代码可以复用、captured external value 很容易进 lexical scope
关于 ParserKt，已经知道 ConstantPattern 不是 OptionalPattern，但是不确定 OptionalPattern 是否属于 ConstantPatternKind
Forwarded from chopin1998
我有一个问题， 比如用adb打开 usb tethering， adb shell service call connectivity 34 i32 1 s16 text
这个命令里奇怪的数字， 在哪里可以查到意义？
这个命令里奇怪的数字， 在哪里可以查到意义？
Forwarded from Deleted Account
只有 34 是魔数，是你分词分错了
adb shell ${command}
service call ${name} ${args}
name=connectivity
args=(i32 1, s16 text)
这个 34 的含义是 IConnectivityManager.aidl 里 setUsbTethering 的 methodNo，具体 Duck.com 搜 "USB service connectivity 34"
i32 是 integer 32-bit，jint 整数的意思
s16 应该是 UTF-16 wchar_t 字符串的意思
顺便：第二个调用参数实际上没用可以删掉
adb shell ${command}
service call ${name} ${args}
name=connectivity
args=(i32 1, s16 text)
这个 34 的含义是 IConnectivityManager.aidl 里 setUsbTethering 的 methodNo，具体 Duck.com 搜 "USB service connectivity 34"
i32 是 integer 32-bit，jint 整数的意思
s16 应该是 UTF-16 wchar_t 字符串的意思
顺便：第二个调用参数实际上没用可以删掉
Forwarded from Node.js | Sleepy
Btw 這跟 security 沒有什麼關係，這只是一種編碼方式，標 #encoding 會更好。
Forwarded from Deleted Account
我的频道是有些重点标签的，不可能专门为 encoding 弄个标签，毕竟我不是学 密码学/信息学/信号处理 的。
既然和 security 能扯上关系，那就扯这个关系，反正 security 的东西也极少
既然和 security 能扯上关系，那就扯这个关系，反正 security 的东西也极少