> I’m not sure if this fits Daffodil’s needs but it could be interesting.
BinEd is Java, we need something in JavaScript. > Here's an older paper about an innovative hex editor: There are interesting concepts in there. Some of them, the lenses for example, are similar to things we have been discussing here. On Thu, Nov 4, 2021 at 3:58 PM Dave Fisher <w...@apache.org> wrote: > There’s a guy with hex editor trying to see if he can make it into a > community. > > https://lists.apache.org/thread/5cbcmfw08002p5ttgyd43kt4vq4c17o8 > > https://bined.exbin.org/ > > I’m not sure if this fits Daffodil’s needs but it could be interesting. > > Regards, > Dave > > > On Nov 4, 2021, at 12:51 PM, Larry Barber <larry.bar...@nteligen.com> > wrote: > > > > Here's an older paper about an innovative hex editor: > > > > Abstract > > The analysis of binary data remains a challenge, especially for large or > potentially inconsistent files. Traditionally, hex editors only make > limited use of semantic information available to the user. We present an > editor that supports user-supplied semantic data definitions. This semantic > information is used throughout the program to realize semantic data > visualization and data exploration capabilities not present in similar > systems. Visualization and human-computer interaction techniques are > applied. We show that this makes recognizing the structure of unknown or > inconsistent data much more effective. Our approach demonstrates concepts > that can be applied to the visual analysis of raw data in general. > > > > > https://www.researchgate.net/publication/220836091_Vide_An_editor_for_the_visual_exploration_of_raw_data > > > > -----Original Message----- > > From: Mike Beckerle <mbecke...@apache.org> > > Sent: Monday, November 1, 2021 10:31 PM > > To: dev@daffodil.apache.org > > Subject: Re: Hex editor operations > > > > This is a good list. > > > > One thing I think is important is that often one is dealing with hex > data, but one needs to consider bit fields that do not respect byte > boundaries. > > > > I suggest we need a way to expand a single byte into a small > presentation of 8 bits, allowing editing of just those 8 bits individually, > is of value as part of a hex-editor. Perhaps that is what you meant by > Mask/Set operations? I think switching to a full-fledged all 1's and 0's > display mode is only for entirely non-byte-oriented data. Anything > byte-oriented people users will want to use hex, and occasionally if they > need to flip bits, a way for them to expand a byte or small run of bytes to > 1's and 0's, but then collapse back to hex is likely very helpful. > > > > But I also suggest creating a minimal hex editor version first, then we > get experience with it. > > > > Any little paper scribble exercises we find ourselves having to do on > the side of using the editor, those are good candidates for things the UI > should directly support. > > > > E.g. I have written things down on paper or in a text editor like: > > > > BF.32.A5.AC.(01|10 1101.101|1 0001) > > > > In a real UI these distinctions could be done quite differently. > > But the distinctions I'm making are dots separating bytes, pipes > separating bit fields of length 2, 9, and 5 respectively, and parentheses > indicating bytes expanded out to a bits region for display, e.g., so that > 01 for 2 bits isn't confused with hex 01 8 bits, and here I have each > nibble of 4 bits space-separated. > > > > Ultimately, we need a graphical means providing: > > (a) a way of escaping from hex to bits for just a small region of the > data where you care about the partial byte fields. > > (b) a way of setting off bit fields from each other, that doesn't > entirely lose the separation of hex digits. > > > > Then if say, that right-most bit field value is incorrect, you should be > able to set editing focus on a bit and flip it. > > > > I would add to the "parse until this byte", or "start from this byte" to > enable narrowing at both the start and end - parse just these bytes (in an > identified region by start and end). The use case I have in mind for this > is sort of like unit testing. You narrow the data to just one part, then > you specify to parse it not with the root element of the DFDL schema, but > with a sub-element that you want to test. > > > > On Mon, Nov 1, 2021 at 6:19 AM John Wass <jwa...@gmail.com> wrote: > > > >> Some thoughts on ways the hex editor would interact with an input > >> stream and the debugger. I visualize this using a context sensitive > >> menu in the hex editor as an entrypoint, where these are some of the > >> operations that could be offered. > >> > >> 1. Add/Delete/Mask/Set > >> * Individual bytes > >> * Blocks of bytes > >> 2. Copy/Paste bytes > >> * Use system clipboard for interoperability 3. Find/Replace bytes > >> * In a selection > >> * Across entire file > >> 4. Set breakpoints on bytes > >> * Stops execution at related point in schema > >> * Would require custom additions to DAP backend 5. Set run options > >> on bytes > >> * Debug-to this byte (and break) > >> * Start from this byte (skipping previous) > >> > >> The idea with breakpoints and run operations is that they would behave > >> as a normal breakpoint in code would. I don't know if this is > >> functionality for the first pass of the editor, but it is definitely > >> something to keep in mind while designing that first pass. > >> > >> What other operations could be supported? > >> > >
