我真的搞不懂，为什么这一群人要把 XML 解析器通通做成 Pull Parser 的形式，通过 XXXHandler Callbacks 来提供结构解析接口
都说『Pull Parser 性能是最高的』
可是我就不明白啊，有时候要这性能有毛用啊！
为啥我要为了剔除标签这种弱智的小问题，去专门写个 handler 去弄？？？
如果想要直观，就不能自己先建好了文档树提着来见？性能真的有必要让你『不提供』这种解析方式吗？
为啥 Python Regex 连个粘滞功能都没有？这真的很脑残
还不如 Perl 了，这么多年了标准库辣鸡，还是没有变啊，这都能叫『脚本语言』？
可是我就不明白啊，有时候要这性能有毛用啊！
为啥我要为了剔除标签这种弱智的小问题，去专门写个 handler 去弄？？？
如果想要直观，就不能自己先建好了文档树提着来见？性能真的有必要让你『不提供』这种解析方式吗？
为啥 Python Regex 连个粘滞功能都没有？这真的很脑残
还不如 Perl 了，这么多年了标准库辣鸡，还是没有变啊，这都能叫『脚本语言』？
Forwarded from Rachel 碎碎念 (IFTTT)
Twitter
清凌渡
从这个角度就很容易理解了
def trimMarks(m):
output = str()
waitClose = False
if len(m) == 0: return output
for i in range(0, len(m)):
char = m[i]
if char == '<': waitClose = True
if waitClose:
if char == '>': waitClose = False
else: output += char
return output
... 我只好手写了，手生... 居然还写了一段时间...
duangsuse::Echo
规范大概是这样： Code 是一个文本图层，包含程式码，目前仅仅创建 VFS 不需要关心其内容 Trace 是一个文本图层，包含变量的追踪 要提供一个 GUI，展示变量列表 List(Label, Textfield) 『同步』操作：利用正则表达式解析所有键值对 (k = v) /(\w+)\s*=\s*(.+)$/ 更新列表 『更新』操作：替换原文本为更新值后的文本 Visual 是可视化图层组，包含所有需要可视化的图层 这些图层的名字做固定处理即可得到相应数据指针的名字 Vals 是不变…
要提供这样的插件接口适配器：
class GimpAccess:
def init(self, gimp = gimp, pdb = gimp.pdb):
def message(self, text):
def layer_root(self):
def layer_is_group(self, layer):
def layer_get_children(self, layer):
def layer_hide(self, layer):
def layer_show(self, layer):
def get_text_layer_marks(self, layer):
def set_text_layer_marks(self, layer):
class VisualGimpAbstraction (GimpAccess):
def layer_get_by_name(name): # private
def layer_get_by_path(path):
def check_layers(): # private
def codeLayer():
def traceLayer():
def visualLayers():
def codePointerLayer():
def pointerLayerOf(layer):
def valLayerOf(name):
class VisualHelper (VisualGimpAbstraction):
def traceMap():
class Helpers: pass
def _trimMarks(m):
Helpers.trimMarkups = _trimMarkUps
class GimpAccess:
def init(self, gimp = gimp, pdb = gimp.pdb):
def message(self, text):
def layer_root(self):
def layer_is_group(self, layer):
def layer_get_children(self, layer):
def layer_hide(self, layer):
def layer_show(self, layer):
def get_text_layer_marks(self, layer):
def set_text_layer_marks(self, layer):
class VisualGimpAbstraction (GimpAccess):
def layer_get_by_name(name): # private
def layer_get_by_path(path):
def check_layers(): # private
def codeLayer():
def traceLayer():
def visualLayers():
def codePointerLayer():
def pointerLayerOf(layer):
def valLayerOf(name):
class VisualHelper (VisualGimpAbstraction):
def traceMap():
class Helpers: pass
def _trimMarks(m):
Helpers.trimMarkups = _trimMarkUps
GimpApi.py
8.2 KB
#Python 程序现在使用的 GimpApi 辅助库可以使用了。除了往常的功能外，还提供了 join stream(generator)、Xml Builder 的功能。如果需要，以后还会写 Xml Parser
GimpApi.py
9.5 KB
更新的 GIMP 脚本编写辅助库
duangsuse::Echo
GimpApi.py
下一步可能是支持 GIMP 的导入导出和画布操作功能
可以让 Python 用 GIMP 画画，这样就有更多可能
可以让 Python 用 GIMP 画画，这样就有更多可能
duangsuse::Echo
规范大概是这样： Code 是一个文本图层，包含程式码，目前仅仅创建 VFS 不需要关心其内容 Trace 是一个文本图层，包含变量的追踪 要提供一个 GUI，展示变量列表 List(Label, Textfield) 『同步』操作：利用正则表达式解析所有键值对 (k = v) /(\w+)\s*=\s*(.+)$/ 更新列表 『更新』操作：替换原文本为更新值后的文本 Visual 是可视化图层组，包含所有需要可视化的图层 这些图层的名字做固定处理即可得到相应数据指针的名字 Vals 是不变…
现在大概差：
GUI 的一个 Listbox(Label, Text) 组件正在使用 Listbox 实现
这个列表的功能大概就是『做一帧程序步骤的时候，把变更的变量修改一下，然后就点一下更新就可以同步到程序视图』
Trace 的更新和同步按钮已经加上了，解析和 dump 也已经完成
GUI 的一个 Listbox(Label, Text) 组件正在使用 Listbox 实现
这个列表的功能大概就是『做一帧程序步骤的时候，把变更的变量修改一下，然后就点一下更新就可以同步到程序视图』
Trace 的更新和同步按钮已经加上了，解析和 dump 也已经完成
Trace 驱动所有的 Visual 箭头指向Vals 是不变量的图层组，其中每个图层都对照了一个 Visual 里的图层，映射方式是 ("v" + x)
每个 Pointers 项目都对照到了 Visual 里的图层或 Code，映射方式是 ("p" + x.lower() + "s")
更新箭头在加提供一个『更新箭头』操作，根据指定的『Trace 层』变量名自动显示 Trace 层变量指向（数组下标，从 0 起始）并且隐藏前一个箭头的显示（上次设置的箭头）上移下移/重置 Code 指针也在进行中
duangsuse::Echo
https://github.com/duangsuse/GimpVisual #GitHub #Python #project
https://github.com/duangsuse/GimpVisual/blob/master/Markup.py
从中抽提出来了 MarkupBuilder，还比较好玩，现在已经支持写带缩进的文档了：
<head>
<title>Hello World</title>
</head>
<body>
<text>
<b>String</b>
<a id="str">|sg.</a>
</text>
</body>
</html>
不使用缩进也可以：
<html><head><title>Hello World</title></head><body><text><b>String</b><a id="str">|sg.</a></text></body></html>
Util.py 里没有二进制处理的函数或者 Maybe, Either, Ap, Functor 什么的，不是很好.... 希望早点写完
从中抽提出来了 MarkupBuilder，还比较好玩，现在已经支持写带缩进的文档了：
from Markup import MarkupBuilder<html>
def test():
m = MarkupBuilder(2)
m > 'html'
m > 'head'
m > 'title'
m < 'Hello World'
m <= 2
m > 'body'
m > 'text'
with m.tag("b"):
m < 'String'
m >= ['a', {'id': 'str'}]
m < '|sg.'
m <= 4
return m
mark = test()
print(mark.make())
<head>
<title>Hello World</title>
</head>
<body>
<text>
<b>String</b>
<a id="str">|sg.</a>
</text>
</body>
</html>
不使用缩进也可以：
<html><head><title>Hello World</title></head><body><text><b>String</b><a id="str">|sg.</a></text></body></html>
Util.py 里没有二进制处理的函数或者 Maybe, Either, Ap, Functor 什么的，不是很好.... 希望早点写完
GitHub
duangsuse/GimpVisual
🐺 Alogrithm visualization with Gimp Python script. Contribute to duangsuse/GimpVisual development by creating an account on GitHub.
duangsuse::Echo
https://github.com/duangsuse/GimpVisual/blob/master/Markup.py 从中抽提出来了 MarkupBuilder，还比较好玩，现在已经支持写带缩进的文档了： from Markup import MarkupBuilder def test(): m = MarkupBuilder(2) m > 'html' m > 'head' m > 'title' m < 'Hello World' m <=…
Python 和 Lua 一样，都太灵活了，连类定义方法分派都是那么的... 动态
而且奇怪....
不过习惯了
而且奇怪....
不过习惯了
duangsuse::Echo
Python 和 Lua 一样，都太灵活了，连类定义方法分派都是那么的... 动态 而且奇怪.... 不过习惯了
最终导致，一但新增限制，就会造成麻烦。
duangsuse::Echo
https://github.com/duangsuse/GimpVisual/blob/master/Markup.py 从中抽提出来了 MarkupBuilder，还比较好玩，现在已经支持写带缩进的文档了： from Markup import MarkupBuilder def test(): m = MarkupBuilder(2) m > 'html' m > 'head' m > 'title' m < 'Hello World' m <=…
使用 GIMP 的 Python REPL 开发插件在多线程上好像有很严重的问题，不可能直接这么做了
之前一直把开发用的 Tcl/Tk 主事件循环放在 main 上
然而，回来发现这么做导致 gimp 不能即使更新后面的图片显示....
我又单独给 gui 开个线程放事件循环，可是据观察发现那个线程的性能已经低到了可怕的程度... 一个 Tk 按钮要花费 5 秒以上才能被初始化...
之前一直把开发用的 Tcl/Tk 主事件循环放在 main 上
然而，回来发现这么做导致 gimp 不能即使更新后面的图片显示....
我又单独给 gui 开个线程放事件循环，可是据观察发现那个线程的性能已经低到了可怕的程度... 一个 Tk 按钮要花费 5 秒以上才能被初始化...