duangsuse::Echo
https://gist.github.com/Himself65/45b82f824f6185b29555a6da516b7337 #GitHub #zhihu 👍
const ZHIHU_URL = "https
function main() {
Http.GET(ZHIHU_URL).then(res => sendCheckStatusGist(res.time, res.statusCode == 200));
}
const ACCESS_TOKEN = process.environ["GITHUB_ACCESS"];
function sendCheckStatusGist(time, is_alive) {
GitHub.auth(ACCESS_TOKEN);
GitHub.Gist.send("Is Zhihu Died?", "知乎今天死了吗？", format(time, is_alive)).done();
}
function format(time, is_alive) {
let exim = is_alive? "还没死啊！" : "终于死了！";
return exim + time.format("yyyy-MM-dd hh:mm:ss");
} 其实最好是用 await/sync 协程写，更甜一些，好像 Haskell 的
do notation 啊。Forwarded from duangsuse Throws
休息完了，虽然我还是那么菜，接下来的时间里，我会完成 LiterateKt 剩下的任务，以及编写 AXML 文件读写器、Kotlin 的 relational 库。
然后可以继续我的 ParserKt 『博客』编写，以及最后对绝句程序设计语言翻译器的实现。
然后可以继续我的 ParserKt 『博客』编写，以及最后对绝句程序设计语言翻译器的实现。
关于 Literate Kotlin project 结构的设计。
Literate Kotlin 之前基于 literateBegin..literateEnd 且允许单层嵌套的设计，已经在 TypeScript 语言里作为小脚本完成实现，单独的命令行工具也会采用这样的单 markdown 结构。
LiterateKotlin 目前为了实用，先是按向 Gradle project 生成设计的，我们认为，Gradle 的 dependencies 是这样：
project(1) : sourceSet(N)
sourceSet(1): scope(1)-dependency(1)
比如下面这样：
而 GitHub 以及一般的规范是用 README.md，所以，项目的 entry file 算是 README 文件。
然后命令行很简单
Literate Kotlin 之前基于 literateBegin..literateEnd 且允许单层嵌套的设计，已经在 TypeScript 语言里作为小脚本完成实现，单独的命令行工具也会采用这样的单 markdown 结构。
LiterateKotlin 目前为了实用，先是按向 Gradle project 生成设计的，我们认为，Gradle 的 dependencies 是这样：
project(1) : sourceSet(N)
sourceSet(1): scope(1)-dependency(1)
比如下面这样：
sourceSets {
commonMain {
dependencies { implementation kotlin('stdlib-common') } }
/**/ 而 GitHub 以及一般的规范是用 README.md，所以，项目的 entry file 算是 README 文件。
## Literate Kotlin
`g:v:n`
+ [...](r1)
+ [...](r2)
+ ...
### Build Dependencies
```kotlin
package apples // (main, java)
package somepkg // (scope, sourceSet)
//...
```
+ `depkind something` (main, java)
+ ...
### Build Script每个单独的引用项目也应该有一个
> [settings.gradle](settings.gradle)
```xxx
//code here
```
## Literate Kotlin而单独的 markdown 文件开头（第一个
+ [...](file_reference)
+ [...](file_reference)
+ ...
<h1> 后，任何非 <h1> heading 前）则应该有```xxx来指定这个文件归属的位置，可以像上文 README 里那样带
package ...
```
// (scope, sourceSet)，如没默认按之前 README 的 map 起始部分来认。然后命令行很简单
kotlinlit -Tgradle -t gradleVersion=4.1 -d build -s .
duangsuse::Echo
关于 Literate Kotlin project 结构的设计。 Literate Kotlin 之前基于 literateBegin..literateEnd 且允许单层嵌套的设计，已经在 TypeScript 语言里作为小脚本完成实现，单独的命令行工具也会采用这样的单 markdown 结构。 LiterateKotlin 目前为了实用，先是按向 Gradle project 生成设计的，我们认为，Gradle 的 dependencies 是这样： project(1) : sourceSet(N)…
关于
关于从 (scope, sourceSet) 到文件路径的分配，统一是
a.b.c:1, a.b:0 找 a.b.c.somechild 这样的前缀 map 可以抽象成 PrefixMap<K, V> 然后在查找时线性地 Descending set + target.startsWith(this)，当然好一点的方法是用 trie 字典树，可能是没有最好。关于从 (scope, sourceSet) 到文件路径的分配，统一是
/src/$scope/$sourceSet/$pkgPath/mdName.$language，语言先只能是一种，默认是 Kotlin。简而言之，Lkt 的命令行工具就是在支持文章结构的前提下允许自动组织项目结构，利用诸如 package 这样的信息自动组织。
duangsuse::Echo
关于 Literate Kotlin project 结构的设计。 Literate Kotlin 之前基于 literateBegin..literateEnd 且允许单层嵌套的设计，已经在 TypeScript 语言里作为小脚本完成实现，单独的命令行工具也会采用这样的单 markdown 结构。 LiterateKotlin 目前为了实用，先是按向 Gradle project 生成设计的，我们认为，Gradle 的 dependencies 是这样： project(1) : sourceSet(N)…
从序列模式提取的角度看，
而
而
-Tgradle 指的 "gradle" 实际上是一种生成插件，我们可以用 interface 来规定一个插件要实现的东西。interface GenerateIntrinsic {
fun solvePath(src: CompileUnit): Path
fun generateProject(base: File)
}
data class CompileUnit(val scope: String, val sourceSet: String, val name: String) interface LiterateKtPlugin<CFG> {
val name: String
fun readConfig(entry: Feed<Line>): CFG
fun create(cfg: CFG, properties: Map<String, String>): GenerateIntrinsic
}从序列模式提取的角度看，
而
[...](file_reference) 的正则是复用的```xxx
package ...
``` 的解析器是复用的而
-Tgradle 指的 "gradle" 实际上是一种生成插件，我们可以用 interface 来规定一个插件要实现的东西。interface GeneratePlugin<CFG> {
fun readConfig(entry: Feed<Line>): CFG
fun solvePath(src: CompileUnit): Path
fun generateProject(base: File)
}
data class CompileUnit(val scope: String, val sourceSet: String, val name: String)