News for hackers. Stuff that matters.

girvel

Re:Writing by hand is good for your brain on Thursday July 23, 2026 @12:12PM (#49023992)
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.
Re:In Emacs, Everything Looks Like a Service on Friday July 10, 2026 @08:14AM (#48858846)
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
Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @04:13PM (#42892079)
For example, you want to keep a set of objects -- then the objects themselves would be keys, and values would be true/nil. Or there is a good example in one of ldump's recent issues: https://github.com/girvel/ldump/issues/44, where the loaded packages are stored in a table as keys to easily detect external module usage.
Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @04:10PM (#42892045)
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.
Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @10:02AM (#42888346)
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.
Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @09:54AM (#42888263)
LOVE2D is a great gamedev framework, I can not recommend it enough. It is so pleasant to work with.
Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @09:47AM (#42888183)
I actually thought the comment was about ldump implementation: it uses %q to serialize strings, and it may not be a reliable way.
Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @09:45AM (#42888175)
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
Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @09:43AM (#42888147)
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.
Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @06:55AM (#42886786)
Oh wow, didn't expect to meet the author, thank you!
Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @06:17AM (#42886639)
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`.
Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @06:13AM (#42886622)
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.

Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @06:03AM (#42886567)
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.
Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @05:56AM (#42886523)
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.

Re:Show HN: Ldump – serialize any Lua data on Friday January 31, 2025 @05:34AM (#42886425)
Damn, it really would

Show HN: Ldump – serialize any Lua data

https://github.com/girvel/ldump

Some time ago, I was implementing saves for my LOVE2D game. I wanted to do a full dump of the game state -- which included closures (AI), complex graphs, sets with tables as keys and also fundamentally non-serializable data (coroutines and userdata), that require user-defined serialization/deserialization logic. I went through every Lua serialization library -- none covered all data...

( Read More... | 41 comments | 50 points | on HN )