Normal view

Before yesterdayMain stream

The Eclectic Light Company
More updates: xattred, Precize and DelightEd. From xattrs to Rich Text
24 June 2025 at 14:30

More updates: xattred, Precize and DelightEd. From xattrs to Rich Text

By: hoakley

24 June 2025 at 14:30

Here are three more updates to some of my most popular apps, primarily for improved compatibility with macOS 26 Tahoe, but with improvements in their interface for other versions of macOS from Big Sur onwards.

xattred 1.6

This toolset for working with extended attributes (xattrs) has several improved window layouts, a couple of fixes in its code to cope with deprecations, and a new icon that should work far better with Tahoe, without compromising its appearance in older macOS.

xattred 1.6 is now available from here: xattred16
from its Product Page, and via its auto-update mechanism. If you’re still using it in Catalina or earlier, please disable its auto-update as detailed in its Help book, so you can remain with version 1.5 or earlier.

Precize 1.16

This provides a great deal of useful information about files, from their inode number, detailed size including that of extended attributes, and access to bookmarks and their analysis. I have tweaked its main window to improve its interface, rebuilt it, and provided it with a new app icon that should be an improvement on all versions of macOS from Big Sur onwards.

Precize 1.16 is now available from here: precize116
from its Product Page, and via its auto-update mechanism. If you’re still using it in Catalina or earlier, please disable its auto-update as detailed in its Help book to remain using your earlier version.

DelightEd 2.4

This text-only Rich Text editor was originally developed to work better with Dark mode, when it was introduced in Mojave. Since then I have used it to produce all the Rich Text I use in apps, ensuring it continues to work properly across both Light and Dark modes. It also has unusual features to support interlinear text. This version has had a few tweaks in its window layout, and has been rebuilt to make it fully compatible with Tahoe and features like Writing Tools, as well as gaining an updated app icon.

DelightEd 2.4 is now available from here: DelightEd24
from its Product Page, and via its auto-update mechanism. If you’re still using it in Catalina or earlier, please disable its auto-update as detailed in its Help book so you can remain with an earlier version.

In the works

I’m currently in the throes of producing a new version of my PDF reader Podofyllin, which I use daily. Unfortunately, this will remove its ability to view the code inside PDFs, as Apple appears to have disabled all the features it relied on to perform that, and they no longer work in Sequoia. However, it still has some unusual features, such as opening multiple views of the same PDF, and can’t edit or save any changes to the original file.

I have spent some time inside Viable, my macOS virtualiser, trying to get it to use the new ASIF disk image, but so far have been unable to get it to work. I will be pursuing that when I get the time.

Enjoy!

回调之 Node.js VS 串行之 Python

中原驿站

By: 胡中元

12 April 2018 at 18:46

Node 与 Python，都是脚本语言，有着类似的使用场景，所以在各个地方早已经互相 pk、比较过无数回了。虽然我知道编程语言之间的 VS 是一个很 low 的行为，因为他们必定是各有优势的。但今天我还是特别的想说说自己的心得体会。

Node 是我曾经特别喜欢，也是非常熟练的编程语言。Python 我还处于学习阶段，不敢说深入了解。

使用场景

如果要评论手机 App 开发，自然是有着一堆框架的 Node 胜出，而如果站在科学计算领域，那胜利者绝对是 Python。所以本文主要还是对简单的日常场景进行对比 ———— 代替 Shell 的那些操作、作为服务器中间件与数据库打交道等等。

Python 脚本

前几个周我写了数个 Python 脚本，这便是其中一个。将 NAS 中我收集的漂亮壁纸的分辨率、时间信息记录到 SQLite 数据库中，再定时从数据库中随机取出近期未使用过的壁纸，让桌面壁纸换一换。

Python 对于这种事情确实在行。另外我根据爬虫创建的翻墙规则 Shadowrocket-ADBlock-Rules 也是使用 Python 生成的，5 线程爬虫协同工作，代码清晰简洁。

Node 脚本

Node 上面提到的那些，相对而言更适合较大的项目。比如我开发的 XSYU-GMS 教务系统，就是一个前后端全栈 Javascript 项目。

对于 web 中间件，例如监听 443 端口提供数据相关的 API 调用服务。Node 原生可作为一个守护进程保持运行，灵活维护一些常量（Python 也是这样，只是感觉工作量会更大一点），作为脚本语言的高维护性体现出来，并且 Node “以事务驱动单进程” 的特性在极限情况下可以实现超高的性能。

Node 成败均在回调

继续上文。虽说 Node “以事务驱动单进程” 的特性在极限情况下可以实现超高的性能。但是对于大多数情况下，Python 也是可以撑住的。低负载的情况下，Node 引以为傲的 “事务驱动” 就变成了可怕的 “回调地狱”，在性能提升不大的情况下，严重影响了开发效率，甚至是提高了程序复杂度所导致的出错率。

我曾经在用 Node 开发 RSS 爬虫时，认真思考每一步之间的相互依赖关系，哪些可以并行，哪些必须等待。然后精确地实现，代码看起来非常复杂。实际上的效率提升其实真不是很重要，全部都用串行实现，岂不一样可以达到目的。

毕竟，要最追求效率那我应该选择 C 甚至是汇编，既然选择了 Node 这样的脚本语言，那就是为了开发方便。实际上，计算机编程语言的发展，就是在不断地用运行效率换取开发效率。当然，不会因为开发效率彻底代替运行效率。

Promise 与 Async Function

这大概就是拯救 Node 回调地狱的存在吧，确实，程序写起来体验好太多了。但是…… 这又导致了 await 地狱…… >o<

下面是我今天的代码，功能从数据库中获取部分 Email 地址，给他们发送邮件。

(async function() {
    let maxTimeStr = new Date().toUTCString();

    ret = await sqlP(`select username from user WHERE 
        d=0 AND status=1 AND created_at line.username);


    for(addr of emailList) {
        try {
            await sendMailForTK(addr);
        }
        catch(e) {
            console.log('sendMail failed', addr, e);
            await sleep(61);
            contine;
        }

        // send Done
        sqlP('update user SET d=88 WHERE username="' + addr + '"');

        await sleep(6);
    }

    process.exit();
})();

/**
三步串行操作：
1. 从数据库取得邮箱地址
2. 发送邮件
3，将记录写回数据库
*/

代码中的 sqlP(), sleep(), sendMailForTK()，都是我自己封装的 Promise Object，虽然封装不是个麻烦事，但我有一种感觉 —— 以后几乎所有的 Node 开发，都要经历这一步了。同时必须要经过的一步那就是在调用的时候用上 await，这就是 await 地狱。

于是问题来了，既然我们 80% 需要的程序逻辑都是串行，那么把这 80% 的代码特殊处理还真是一键麻烦的没必要的事情。像 Python 那样默认为串行，在 20% 的时候再使用多线程，在我看来是一种更合适、更通用的模式。

事件驱动是 JS 的核心，所以 Node 自然以后也只能保持这种模式了。

对 Node 的总结

我认为，Node 的最佳使用场景仅限于需要其特点：”异步回调” 的时候，可以带来高性能。而其他时候，这只会带来麻烦。

当然，Node 超级给力的模块机制，以及与简单易学的 JS 搭配实现的 web 开发语言前后端同一等等，使得 JS 永远充满魅力。

Python 的缺点

就并行串行而言，Python 我更偏好，但是这门语言我还是有一些需要吐槽的地方。

1. 编程风格

对于初学的我来说，完全不能赞同 Python 那些语法就是 “优雅的编程”，而 C 风格的大括号、分号就有多难看。在 class 里面，最多只能一个空行，而不能 2 个。使用 Python 编程让我有种被限制的感觉（也许还是因为我不熟悉吧）

总之我认为 “非 C 风格编程” 是一个缺点。

2. 相比 Node 包管理机制更弱

这不是 Python 太差，而是 Node 太叼了。Node 只提供底层 API，提倡使用第三方包完成你的工作（这也是导致 JS 项目层出不穷的原因），而 Python 并没有这种提倡。