GCE 行么..

我就在vps上跑alpine啊

在vps上的docker里（

#build #sysadmin http://spek.cc/

Spek 简易频谱分析仪的老版本

编译时需要修改以下代码：

src/spek-audio.cc

get_frame_defaults 改成 av_frame_unref

avcodec_alloc_frame 改成 av_frame_alloc
avcodec_free_frame 改成 av_frame_free

编译代码：

aclocal; autoconf; automake --add-missing
CXXFLAGS=-fPIC ./configure --with-wx-config=wx-config-2.0

#project 决定做一个扒谱的集成环境，以分步填写时值和音高为特色

应该可以快速前进后退 5 秒、暂停继续、增加减缓播放速度、音量调节，人声消除和剥离处理

支持自定义音色，机制尚待研究

应该使用钢琴卷轴，允许调整编辑类似 LMMS

首先跟曲子弹键盘弄出音高序列，然后跟曲子按键盘确认音符时值即可完成扒谱

应该可以导出 MIDI

自动音高检测算法之类的待定

UI 准备下次设计

类似的 Android 应用都有，可惜不知道...

ref. https://github.com/qtau-devgroup/editor

钢琴窗控件

ref. https://github.com/audacity/audacity/blob/dc603341ee62c0c40d50d4a088466e814faa2cd6/plug-ins/vocalrediso.ny

https://manual.audacityteam.org/man/vocal_reduction_and_isolation.html

这是人声消除和隔离算法，如果暂时看不懂就直接用 Nyquist 插件

这个设计我早上起床的时候考虑了一下，就界面看比较像 SynthesizerV 和 歌词滚动姬的结合

不过考虑到设计起来工程量比较大，最重要的是我又没时间，第一次就上中型的很吃力（比如上次，只是个小 Qt 应用就花了 6 个小时左右... 虽然有 4 个小时是在熟悉工作流程和解决交叉编译）
又重新设计了个小的，不过有点简陋的意思，最后我就没考虑这个

最后的最后我决定将这个功能作为对 LMMS 的扩展实现，因为很方便...
设计特性大概包括 录制音高序列（录制中可以按键回滚已经录制的一个音高也可以随便删改序列）、时间轴比例缩放（后期处理功能、用于支持播放器降低播放速度）、添加扒谱用背景音乐（和录制时间同步，允许调速，时间轴可以随便前进后退和撤销上一次音高放置）、编辑录制音高和调整下一音高指针，和使用既定音高序列录制（作为对普通录制的功能扩展）。

工作流程大概就是先录制音高，录制好了跟背景音乐打音高时间轴，打错了也没关系可以撤销最后的音高时轴放置回退重来，最后可以选择比例缩放解决播放速度降低的问题

，下周见。

个人感觉现在工程能力的缺失主要是不能在这些自己设计的流程做太好的计算，
还有我没学过打字所以有点慢的问题
我对理论的理解能力还是有的，不管是前端还是后端

考虑到这些流程设计什么的其实设计完基本清单可以用伪代码先描述好了，
专门花时间学习目标平台的知识，然后尝试把伪代码（算法或是结构，哪怕是 SQL、HTML、Cypher 这种非高级语言）映射到实际实现
大概就可以设计起来不那么慢了...

#Life #Tech #Dev #Android #Coolapk #Lua #Kotlin #Java #China #Statement

...刚才本来已经准备收拾书包去学校的，可是准备从自己十几本 IT/CS 的书里选出几个要带的书时
一直总是担心买到的书可能会丢掉，所以就拿我妈的手机想查查之前买过什么书（我发过 Gist）

华为的内置浏览器好像屏蔽了 Gist.GitHub.com，虽然没有说无法访问或者 404 什么的但是加载不出来，等了很久，没有响应，进度条一直满的但是页面就没渲染出来
不知道是不是压根就没有下载主 HTML 数据。就是想让用户知难而退的。

打算找另外的浏览器的时候又翻到了 launcher 的下一个 page，这页有酷市场（现在已经更名酷安）和一个木函（Androlua 应用），以及我当时根本没写出来的“树”工具箱（Beanshell 应用，虽然没有大佬包装，我那时根本不能算是大佬）。

我内心突然产生了一种想打开木函看一看的念头和一种复杂的，不想打开这类应用的情绪。
我最终还是逼迫自己打开了木函看看... 为什么我不想打开呢... 我知道其实我有点羡慕一个木函，嫉妒到不至于。

木函给我的感觉和各种别的应用都不一样，因为它的开发者可能就比我大一点，差不多也是高中（或者高职什么的）大概
而且界面布局和装饰构件交互动画设计的是真的漂亮，令人眼红。
大概这就是所谓的同辈压力。

进入界面就是两个圆形缩放 bezier 插值动画，每次色调都不一样的二元渐变背景加上零散规整的花印
，应用简介里 MBE 风格，大概就是这样了吧，有点半个阴阳师的设计风格，小清新。

返回键退出的 snackbar，不使用透明渐变动画进入退出，别有一番风味

随机半透明圆形层叠序列装饰的 navbar 显示每次都不一样的诗句，强化了设计风格
只有两个图标的 navigation button

推荐工具、工具收藏和快捷方式创建，最近使用、最近更新、未使用、工具箱 分类，完全为用户考虑的设计
使用高亮色强调特殊的工具，被推荐的工具 entry 都有图标附着之上

一种简单的单文本输入单文本输出类型界面，MD + MBE 风格，Floating Action Button 放置位置特殊别有一番风味

图片转文本，现在已经变成了文本蒙板图片，虽然我第一眼就看到了可行的算法逻辑，还是觉得莫名失落
文本处理，支持 Java 的正则表达式和 Lua 字符模式匹配，@Java() 这种简单的二义性区分词法，觉得设计真的... 自己还是太弱了
设备信息，虽然我也写过类似的... 这个稍微安慰一些
各种网络 API 绑定如翻译，界面排版美观
网络服务 HTML scarper，我觉得我可能是之前有看轻他们的意思，所以现在才会觉得羡慕 Android 应用开发者？
安装包清理什么的，才知道以前我以为菜的 Androlua 用户也有不菜的

总结起来，就是有基本系统管理的能力，Geeks 都有，怀恋以前玩机的时候
和程序设计语言标准库函数封装的能力
和网络 scarper、JSON HTTP API 访问的能力
和图像处理的能力、Canvas 能力、Android UI 布局能力、Andoid UI 动画能力
和文件系统处理能力、简易异步能力、找到后端大佬的能力
Android 扩展多媒体 API 处理能力、Lua inspection API 使用能力

我知道不都是自己一定会的，一定理解的，可能是网上能找到的，可能是花了很多时间的，并且也经常以此安慰自己，但还是羡慕一样的，即使按理说寒歌也算是朋友所以不应该羡慕的
我自己也很喜欢做这类小工具，比如我写过，目前也只写过 MinBase64，我自以为是设计独特的...
别的应用，什么文件管理器什么别的系统工具 utilities 是不会考虑的，应用的组合可能性太多了。和底层的万年不变完全不一样，况且，底层也有很多的，没十年学不完何况应用层

如果不是寒歌只有木函和 FusionApp 两个我看的上眼的应用（其他的那种我两天能写出来的那种），我还会更自卑一些。

到了酷安上，一大堆赞美扑面而来，却是那么刺眼，但在这评论中我却莫名其妙地问自己 — 你做得出酷安这样的平台吗？
使用酷安的 Android 开发者下载榜上徘行第二，第一是 Via 浏览器。别的开发者、团队、公司的应用很多都不能和酷友作品相提并论。
酷安的开发者一直都是双重优秀，或者至少是界面设计优秀的风向标。没有第二。

”渺小的身材，承载了无数 App 的智慧。” —《一加手机》
“你的手机上有哪些有意思的 App？”  知乎 25K 回答 —《知乎 @Alpha》
”App 界的瑞士军刀“ ——《ZEALER》

”拥有很多，不如有我。“ — 《一个木函 7.0》

....

其实嘛，感觉自己除了英文组句和偶尔的单词拼写、技术上系统安全网络安全、乐理 VFX 特效 3D、打字、异步并发问题、高等算法、高等系统/系统集群管理（是的，大部分服务的部署配置我会）、初等计算机网络、人工智能、高等数学、高等程序设计语言理论、嵌入式系统、中等游戏开发、企业级应用、横向复杂度很高的 GUI/TUI/CLI/PromptCLI 应用什么的外 还不错，够用。够用。

有时候会自己总结前端设计的最核心最核心的理论，觉得排版设计应该取决于交互，装饰可以来源于生活。（很突然啊）

大概是理上还是工上都够用的那种情况。

不过还是掩不住对应用层的羡慕，就是那种吃不到葡萄说葡萄垃圾太菜容易自我满足的感觉。

即使是理科做到怎么样的层次，设计出最好的编译器、编译器框架、独立设计各种各样的理论工具之类的
又怎么样呢？
只有应用层，那些开发给你们捧在掌心里的 Android/iOS 最火两大移动平台的应用，才能成为“网红”“年薪百万”的程序员吧...
或者说，开发前端框架才是正道吧...

做的东西不是拿来直接给终端用户实用的，就不会有一大群开心完整的活人，不热爱技术热爱生活的活人陪着你们插科打诨吧... 我还是想念曾经在酷安全水贴的时候的，大概
我不想老是做后端啊，我和他们不一样，我也是想和这些应用层开发者一样能成天写着自己要用的应用，要不然我也不会来这么热闹的 Telegram，可或许... 或许现在的热闹的确不是属于现在的我的...
可是没办法啊... 有些东西是和实践结合起来的，有些... 其实，我是真的没有时间做工程系的事情啊，或许，或许高中毕业了就可以吧。

即使是开发者大概也没有多少做到理解这种，这就是理科们肯定的孤独了，不像开发应用层的程序员。哪怕是那些程序员都无法理解他们...
写一堆被人看不见的代码，甚至不会被人直接使用，有什么意义呢... 还不如去做前端，写 HTML/CSS 然后用 JavaScript 之类的添加额外的逻辑，然后和别人争论 Chrome 好还是 Firefox 好...
Atom 和 VSCode 哪个好... 自己可能完全没有用过的 Emacs 和 Vim 哪个好... GNU/Linux 和 Windows NT 哪个好...

Servo/Gecko、SpiderMonkey 引擎和 Blink、Google v8 引擎的开发者们会为了你们的争论感到开心吗？
他们可能不觉得自己是一个世界的人... 永远的生活可能就几个人一个小组，因为，因为做这些的人太少了...

不如好好讨论 Android 应用开发什么的吧... 现在桌面、跨平台应用都有点沦陷了，一切都在指尖之中
Qt 算什么呢... 好吧，我现在就在用使用 Qt 的 KDE 和 Telegram Desktop Linux，但是，Qt 开始的确是很创新的窗体控件和跨平台应用框架啊，信号插槽、事件驱动编程...
曾经第一个提出笔记本电脑概念的人，大概能想到这一天吧。根本不需要等开机，一天都是开机的，像手表一样
如果以后再变化... 总是有各种各样未来的

”预测未来的最好方式就是去创造它！“ — Alan Kay

#Java #Haskell https://eta-lang.org/docs/user-guides/eta-user-guide/installation/gradle

https://github.com/typelead/eta
Eta 语言这个不错的

#engineering #backend #CG https://libgd.github.io/manuals/2.2.5/files/preamble-txt.html

#include <gd.h>

#include <stdio.h>

int main() {
  gdImagePtr im = gdImageCreate(64, 64);
  FILE *pngout = fopen("test.png", "wb");

  int black = gdImageColorAllocate(im, 0, 0, 0);
  int white = gdImageColorAllocate(im, 255, 255, 255);

  gdImageLine(im, 0, 0, 63, 63, white);

  gdImagePng(im, pngout);

  fclose(pngout);

  gdImageDestroy(im);

  return 0;
}

想弄个小程序，失败了... #Freetype #CG #C #Backend

结论：因为已经花费了一个小时，我觉得很累就算了...

现在改成仅仅使用 FreeType 画图然后 libGD2 输出即可

*... 的确是很累... 如果用 Java 和 Canvas 的话或许会简单一些？

图片 转 字符画 彩色 🔍 DuckDuckGo

暂时打算：

1. 一个图片蒙版文字的独立 CLI 程序，使用 FreeType 和图形库
2. MinBase64 Kotlin 翻译
3. Telegram 补丁
4. Haskell ftree 实现

关于这个字符画的问题，其实我说的所谓『蒙板字符画』
就是现在一些设计杂志封面上会使用的、以及 一个木函 现在支持的字符画模式

实际上没有真正弄出文本输出，过程类似于（抽象 PorterDuff 混成模式的）：

图层 1（dst）：自动折行的文本视图，无限重复『字符画文字』直到布满整个视图，视图大小和图层 0 一致，使用 SrcOver | DstIn 模式（只绘制图层 0 与图层 1 交汇的地方，置顶图层 0）
图层 0（src）：原图片

另一种模式是类似冰封博客上教的那种，利用颜色/灰度分析取平均什么的拿到总结的数据，然后实际上输出字符序列

还有一种是输出图片，不过不是无限重复字符画文字，而是基于像素视图灰度综合选取 ASCII 字符填上的，反正都差不多。

#PL https://github.com/qnnnnez/rs

曾经在百度贴吧看到的邮电二进制序列化大佬... 现在居然也写 Sexp 语言解释器了...

二进制处理的算法我之前也写过，没有这位的那么高级那么实用，是解包一游戏的数据的。
而且也不如这个 C++ 的... 跨平台、内建序列化框架、C++ template 使用、各种图像纹理和波形、字体字形 glyph 解包打包什么的...

不过，我看（Sexp 解析器）的时候居然估计错了一个，真是该打... 太菜了...

https://github.com/qnnnnez/rs/blob/master/src/sexpr.rs#L53

我居然蠢到以为 self 里不保存扩号开闭堆叠状态的话肯定是不行的，然后一厢情愿地认为肯定是分配了新对象然后递归...
其实是单纯递归就可以了... 这次是我突然脑抽了一下，其实我还是知道的，之前我设计的 SubsequenceParser 就是属于上面那种脑残做法，而后来我设计的 HeapParser 其实就是递归下降解析，不过不把递归信息保存在栈上而是保存在堆上

伪代码（顺便教可能不了解解析器的你们如何手写解析器，当然是 parser combinator style 的 『广义』解析器）：

Peekable<char> input; // 可以理解为字符流 Stream<Character>，标准输入
char current_char; // 当前字符，方便在函数直接传递

/* 常量 */
char PAREN_OPEN = '(';
char PAREN_CLOS = ')';
char BLANK = ' '; // 要跳过的空格

/* 辅助函数 auxilary */
fn nextChar() { current_char = input.peek(); }
fn getChar() -> char { return current_char; }

nextChar(); // seek 到第一个 char（虽然此操作不真正是 seek）

/* 解析：无解析状态 */
fn lexToplevel() -> Vec<Sexp> {
  let mut result_vec = vec![];

  loop {
    match getChar() {
      PAREN_OPEN => result_vec.push(lexList()), // 如果是列表，则进入列表分词状态
      /* 不应该出现不对称的闭扩号，对应（有开有闭）的闭扩号应该在解析列表时已经跳过了，不应该在顶层出现 */
      PAREN_CLOS => panic!("Unmatched parenthesis: Shold NOT seen closing paren lexing toplevel"),
      BLANK => next, // skip blanks
      EOS => break,
      _ => result_vec.push(lexAtom())
    }
    nextChar();
  }
  return result_vec;
}

fn lexList() -> Vec<Sexp> {
  assert!(getChar() == PAREN_OPEN);
  nextChar(); // 跳过开始的 '(' 字符
  let mut ret = vec![];
  while (getChar() != PAREN_CLOS && getChar() != EOS) {
    ret.push(lexToplevel()); // 直到最后看到列表结束符 ')'，我们知道列表嵌套的问题已经在 lexToplevel() 里处理好了，所以不去管这个递归定义
    nextChar();
  }
  if (getChar() == EOS) panic!("Unclosed parnthesis till EOS");
  nextChar(); // 之前的状态应该是 getChar() == PAREN_CLOS，nextChar() 跳过这个闭扩号
  return ret
}
fn lexAtom() -> Atom { /* implementation omitted */ }

~~所以这里啊我们可以看到现在流行的一个解析组合子的逻辑结构，多么优美，一切状态可以通过递归组合传递，语言层面的支持，不像那些循环 state based lexer，一大堆 yystat、pushState 很难看~~

那么我们来看看它如何解析一些简单的小程序（虽然都是简单的东西，感到羞愧。）

()

首先 seek 到输入 (，lexToplevel 分派到 lexList，
while 循环直接没进（因为 ( 后面已经是 ) 了
nextChar 到 eos，返回 toplevel 后结束分词

()()

[()()]lexToplevel => [()()]lexList{[]}[()] |> {[]}[()]lexToplevel => lexList{[][]}() |> {[][]}lexToplevel

(()) 这个比较有意思，因为开始使用调用栈记录嵌套了
首先 ( 分派 lexList，lexList 再 lexToplevel，lexToplevel 看见第二个 ( 又调用 lexList
此时调用栈是这样的：

lexList $j = [ $k ]
lexToplevel $i = $j
lexList [ $i ]
lexToplevel (())

递归到这里（栈顶）实际上已经结束了，因为中间第二个 ( 后面直接就是 )，没有别的，然后递归回溯得到结果

$k = (none)
$j = []
$i = []
lexToplevel (()) = [[]]

(1 ())

lexToplevel (1 ()) =
lexList 1 () : [] =
lexAtom 1 : lexList () : [] =
1 : [] : [] = [1 []]

((1) 2222 hhhhh ())

lexToplevel ((1) 2222 hhhhh ()) =
 (in lexList) {(1) 2222 hhhhh ()} : [] =
  (in lexList) {{1 : []} 2222 hhhhh ()} : [] =
   (in lexAtom) {{#1 : []} 2222 hhhhh ()} : [] =
  (in lexAtom) {{#1 : []} #2222 hhhhh ()} : [] =
  (in lexAtom) {{#1 : []} #2222 #hhhhh ()} : [] =
  (in lexList) {{#1 : []} #2222 #hhhhh {[]}} : [] =

— 开始回溯归约 —
{{#1 : []} #2222 #hhhhh []} : []
{{#1 : []} #2222 hhhhh []} : []
{{#1 : []} 2222 hhhhh []} : []
{{1 : []} 2222 hhhhh []} : []
{[1] 2222 hhhhh []} : []
[[1] 2222 hhhhh []]

((()) 这个有意思的地方在于它会失败，因为没有闭扩号就 EOS 了，猜猜在哪里 EOS，那时调用栈是啥样（

比起 HeapParser 手动维护的数据结构，系统调用栈记录的可能更多，一个调用（call）没有返回（return）的时候，调用者（caller）处于尚没有完成执行的状态，等待被调用者（callee）求值完成
我比较奇怪就是单靠记录一个 level 和一个 heap 上的 list 可不可以就直接像 recursive descent method （递归下降解析法）一样直接能解析了，奇怪的是好像无法做到区分 () 和 ()()、() (1)、((1)) 这种嵌套一样
递归的确是比较好玩的，因为实际上，类似现在 Coroutines 和各种 CPS 一样，调用帧记录了返回地址，也即函数的 continuation，所以被挂起没有完成执行的函数实际上有足够的信息在恢复执行时规约到完整的 AST（因为我们实际上的确记录了要把项目插入在哪里（通过记录返回地址的函数调用完成））

递归之美。

看看 Rust 的 enum ADT（代数数据~~结构~~ 类型） 多么优雅（

#[derive(Debug)]
pub enum SExpr {
    Atom(SAtom),
    List(Vec<SExpr>),
    Quote(Box<SExpr>),
}

#[derive(Debug)]
pub enum SAtom {
    Symbol(String),
    Integer(i64),
    Bool(bool),
    Char(char),
}

总之呢... 不管怎么样的话自己工程能力都是欠佳的吧...
唉...

只能指望以后能有点长进就是了，现在也想不到什么严谨准确一点的方法能够加快这类模型的处理的...
结果是连文件树算法都不会写呢？

dfs... 怎么不应该会写，解析器嵌套二维文法处理的话如果不会就惨了...

C 语言上面的目前是考虑到一些过程式的逻辑和语言特性、库函数还不熟悉，尤其是 C 的各种函数库因为 API 封装不良好，又没有好的 IDE 智能感知推荐的话，设计起来比 OOP 们烧脑一些，比 Java EE 入门还耗时
C++ 又是特性一大把，各种语法设计太多了，学起来坡也是很陡
算法的话自然都是要花时间的，伪代码逻辑都需要时间，这个无所谓。
各种新的数据模型，比如 Glyph、Font face 什么的由于是新模型自然理解要花时间
比上 Android 的话其实 Android 某些新 GUI 控件学习也得花时间，控件布局模型基础也得花时间，都是必须的，不过因为做的多做的久的缘故就可以不那么多的学习新东西，不过 Android 的话有各种博客可以看，我自己看的是稍微麻烦一点的 C API 的英文文档和示例，这么看其实我平时失败是有缘由的（疯狂自我安慰）

不过现在好歹也有个 CRT （C 运行时）的底层视角，干什么也方便一些（疯···）
不过现在好歹弄完也会总结一下命名模式、生命周期、使用流程什么的了，起码不虚此行（疯···）
不过 JavaEE 那些是属于 DevOps、代码外的 XML 配置、运维什么的涉及得比较多，和编程能力无关（疯···）
不过我打字再快一点说不定就好很多（疯···）
不过我一些技巧性的模式性的东西肯定学得比别人快（疯···）
反正别人也没有这能力，那我不会也罢（...来，你说别人不会，你看看这个，它可以代表现在的一些你所认为『简单』的串行（单线程顺序模型）程序逻辑复杂度了〖考虑到某些框架、库使用的缘由〗）

另外，单单会做和做好还有区别啊... 不能一下子写出良好实践做到优化的话，比较不像是好程序员的样子。