Readline is reasonable for a line editor, not for an ncurses app. > * hotkeys are reasonable if you use readline(1) tweak.1 (shows the default hotkeys, but not easy to parse as a quick reference)įor comparison in top, h works, ? also works, and pressing Ctrl-H shows a helpful message "Unknown command - try 'h' for help" ls (figure out what the man filename is) change directory to where I compiled tweak press h, Shift+H, ?, Ctrl-H, Ctrl-H+Ctrl-H, F1, :help (nope) These are the steps I went through to figure out the hotkeys: I can't think of any ncurses app that doesn't have in-app help. > * the manpage is pretty comprehensive ( ) As far as I understand, block allocators are not solved with btrees. Youu'd hve to keep track of those "unallocated" blocks on disk to enable re-use thus improve space efficiency. But the user is still editing the file and so some of these blocks that were flushed to disk are no longer valid. Suppose as you run out of memory you start flushing blocks to disk. However, this then starts to look like a block allocator problem. With that said, I wonder if the calculus changes if the file is so large that it won't fit in memory and thus, b-trees maybe somehow helpful in flushing data to disk. I don't see that being a use-case here and thought maybe I was missing something. My understand is that btrees are a multi-level index that reduces the number of blocks that need to be read from disk to manage an index. I'd probably just use a red-black, AVL, even binary tree with nodes either pointing to blocks on the file (ptr, length) or nodes containing new data in memory (ptr, length, data) with the invariant that no two nodes can ever have overlapping (ptr, length). I guess I don't see the benefit a b-tree adds here. Yes, a document can just be a (ptr, length). But error handling with mmap is miserable, so I think it is wise to avoid mmap even in 64 bit.
Hex fiend insert bytes 32 bit#
Hex Fiend does not use mmap because I wanted to support 4+GB files in 32 bit mode. By organizing the list as a b+tree, it's fast to find the slice at a given byte offset in the document. So there's no real dependence on the original file: a document may reference arbitrarily many files (until it's saved). The user may also open file2, copy part of it, and paste it at the end of the document. This splits the original slice at offset 75, so our new list is: Now the user scrolls to offset 75 and types 30 bytes. The b+tree is just an optimization on top of the list, and is not written to disk.įor example, say the user opens file1, which is 100 bytes. Great questions! A Hex Fiend document is represented in-memory as a list of slices of files and memory buffers. My tool can easily generate tags for any single block without knowing any special context or having any expensive-to-generate state - I just need a block number (i.e.
Hex fiend insert bytes series#
This would be easy to adapt to - Postgres relation files always consist of a series of 8KiB blocks/pages. That said, it would be great if I could adapt pg_hexedit to a hex editor that had some kind of "best of both worlds" support for tags - tags that can be generated lazily and on-demand, when a portion of the file needs to be drawn or redrawn. Writing a C program that uses the struct definitions from the server itself makes the complexity quite manageable - the tool is basically feature complete, even though I haven't spent a huge amount of time on it. But even if it did I might not want to use them the on-disk format of PostgreSQL is much more complicated than most file formats, and isn't supposed to be consumed by third party tools. WxHe圎ditor doesn't support declarative tags. I'm generating huge XML files, which is slow, but there are simple workarounds to get acceptable performance. I procedurally generate a description of each file in a shell script, and then open the file in wxHe圎ditor. What I'm doing is pretty grotty, but works surprisingly well in practice. I understand why you favor a declarative template format for describing files with tags - that probably scales really nicely. I've invested quite a lot of effort in it, and it would be nice to have support for multiple hex editors. I am the author of a tool that generates wxHe圎ditor tags and annotations for Postgres relation files - pg_hexedit:
0 kommentar(er)
