girvel

I like writing by hand, but I don’t agree with the logic that it’s good because it recruits more areas of the brain. The less effective the medium is, the more of the brain it will recruit; chiseling on a stone tablet is probably a more complex task and it probably gives a more broad stimulus to the brain, but it does not mean it’s such a good idea. I would personally prefer to use a text editor for effective writing and then crochet for fine motor skill.

I did not get this argument. Diagrams are nice, and I probably missed something in lisp code (not used to lisp syntax), but I see no argument that Emacs has more service-like interaction with other apps or its plugins than say vim or vscode. I agree that emacs is the most OS-like, but I would love if someone explained what exactly is the point in the article

This is fascinating. I wonder if this issue exists in Lua5.2+, where there is no jit and `load` is able to restrict used environment.

I looked into it, and Lua allows limiting the environment when `load`ing -- through `env` argument since 5.2 or through setfenv before. I will add a helper function to produce a minimal needed environment for safe loading and a documentation page about safety.

LOVE2D is a great gamedev framework, I can not recommend it enough. It is so pleasant to work with.

I actually thought the comment was about ldump implementation: it uses %q to serialize strings, and it may not be a reliable way.

It is intended to be used in cases where you need to store data on a disk or transfer it to another machine -- like in a video game save or a network data exchange

On my machine it produces an equivalent string, although differently formatted. It seems that ldump preserves all special characters (`"\a\b\f\n\r\t\v\\\"\'"`), although I will need to test in on all supported versions.

Oh wow, didn't expect to meet the author, thank you!

Thank you, it is really nice to hear. Though, I have to give credit to Lua's standard library -- the basic function serialization (without upvalues) is implemented there as `string.dump`.

This is an interesting thought. Currently, it is unsafe and intended to load only the files you trust. I should definitely include a warning into README.

Overall, it would be nice to make it safer. I don't think switching to non-Lua format would make it safer, because it is intended to serialize functions too, which can have arbitrary code even if everything else would be stored as data. Maybe it is possible to make a function like `ldump.safe_load` restricting `load`'s environment, so it wouldn't have access to debug/os/io modules.

Yep, that is correct. I think ldump is able to preserve all upvalues, even on edge cases such as "_ENV" and joined upvalues (multiple functions referencing one upvalue). A closure is basically an object with a single method and upvalues as fields -- serialization is straightforward. I think I got it covered, but I would be glad to hear ideas about where the serialization can be unstable.

The function (even a closure) would be fully recreated on deserialization, it is fully safe to save it to disk. It wouldn't preserve reference equality -- it would be a new function -- but the behaviour and the state (if using closures) would be equivalent.

I didn't include asserts in the linked case, because I thought it would be too verbose. You can see asserts in the test, that is linked below the example. Maybe it was the wrong call, I will think about including asserts into the example itself.

Damn, it really would