Data Position not hex but int

[shanedell]

@arosien
When testing the debug event I am the extension to hit on custom event for daffodil.data however I am not getting the hex/html code string expected.

For example in the loaded scripts data I get this

          │                                        │
87654321  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789abcdef
00000000: ffd8 ffe0 0010 4a46 4946 0001 0101 0060  ����␀␐JFIF␀␁␁␁␀`
00000010: 0060 0000 ffe1 010c 4578 6966 0000 4d4d  ␀`␀␀��␁␌Exif␀␀MM

however this is what I am getting from the custom event {"bytePos1b":1,"type":"daffodil.data"}

I assume this deals with the assignment of bytePos1b to long that it only send me an number and nothing else, but I am not completely sure.

[arosien]

Sorry, this is a coordination issue that I perhaps didn't notify you about as well as I should have. In my comment on the infoset and data event, I wasn't sure what data to send in the event, and proposed sending only the data position information as an offset into the data file. To handle this event data, the extension would have to load the relevant data from the file itself, and render it as hex (or whatever).

I just realized that the hex view has a start & end position, so I need to dig into the thing that makes that view to find out what information it really represents, and return both endpoints instead of just one.

However, you were expecting the backend to deliver the content of the view in the event, so let's discuss that part. How much work would it be for the extension to generate the hex view itself? I thought that might be preferable, because you'd have more control, but perhaps not. For example, if you wanted to let the user see a hex view of the entire data file, we wouldn't want the backend generating an event that contains the entire data file.

We could defer the decision, and have the backend send both the "raw" data position window and (additionally) send the pre-rendered hex view (just a window, not the entire file).

What do you think? Push all the rendering to the extension, or provide a small hex window in the event like the above?

[shanedell]

So for my thinking I was thinking the backend was sending over the hex in the event then the extension mostly just displayed it. I am not sure how the extension could take the dataPosition and make it hex. If you are referring to the inforset, would it have to take the dataPosition grab the line from infoset file, turn it into hex and then display it? I am not sure how well that would work because the entire infoset would have to be sent right off the bat or the infoset file would have to be updated constantly to make sure it has up to the data position inside of the file for that to happen. If you are referring to the data file if the file is a jpg wouldn't take some special working around to get the file into lines of code so that dataPosition line can be grabbed and be converted into hex?

Thinking about that, are you able to just send the hex of the current data position from the debugger to the extension, should be the same as the way you are sending bytePos1b, then the extension renders it that way? So could you do something similar to how send the hex to the loaded source but send it via the event instead? I would think this might be a simpler solution than trying to have the extension getting the hex as it may not have the breakdown of the file.

Furthermore, I think easiest solution would be passing the hex like

          │                                        │
87654321  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789abcdef
00000000: ffd8 ffe0 0010 4a46 4946 0001 0101 0060  ����␀␐JFIF␀␁␁␁␀`
00000010: 0060 0000 ffe1 010c 4578 6966 0000 4d4d  ␀`␀␀��␁␌Exif␀␀MM

from the debugger to the extension then extension displays it, what do you think?

[kirkejohnson]

Thinking forward about this, we will want the view to be "smart enough" to change its rendering as needed -- from Hex, to Unicode, to whatever. (At least that's what believe the customer is expecting.)

This implies to me that the view has some bookkeeping of its own to do. I think it would have to read the input stream and have a mapping to the least addressable unit shared between it and the parser (I assume this is byte), get positional data from the parser in that unit, and then figure out in the current rendering where that position is and how to highlight it.

[arosien]

@kirkejohnson, yes that was my rationale: the backend sends the relevant data ranges, and the extension manages the view that displays that region (in whatever manner is appropriate). It pushes that rendering work to the extension, whereas the legacy debugger--the code that generated that hex view we see--had to do it itself.

It is true, however, that other extensions I've looked at don't do this, and push the rendering closer to the debugee. I don't think it's a great long-term solution, but it can get you progress more quickly if you already have rendering code there.

[kirkejohnson]

As long as both ends of the equation can agree, and remain in agreement, on how to measure the relative location. I have a feeling that could get tricky.

[shanedell]

Okay that makes sense, I am just unaware of how I can get the necessary data in the extension given the dataPosition. @arosien do you you have any ideas or know of anything about how to do this?

[arosien]

I really don't know enough about VSCode to answer this, sorry.

The way I was generally thinking about this is:

• Our extension needs to open a view to the debug session's data.
• The view needs to render the contents of the data; this is often mediated by plugins that are triggered by filename extension, or perhaps a view can be "told" what will render it. For example, we could bundle the https://github.com/microsoft/vscode-hexeditor plugin with our own, or fork it, for hex views.
• The debugee will notify the extension of updates to the current position, which need to be reflected in the data view. For example, moving the view's cursor to that position. We may add more positional data to the event, which could be rendered in the view as a selection or some other highlight.

[shanedell]

screen_rec_trim.copy.mp4

@arosien @jw3 @kirkejohnson How does this look? I apologize if the video is junky I just did a screen record not sure how well it looks to everyone else. To shorten the video I had to crop some stuff out.

Little clarification, on start of debug the entire hex of the data file is written to a file .data.hexdump, if you have the hexdump extension installed the hex looks a bit nicer. Once the debugger and extension are connected and the debugger sends over the data position for the first time the hex file is opened beside the schema file. As you step through when the debugger sends over the data position, the highlighted green text is automatically updated to that line of the data file, if it is lower than where the screen is currently, the extension should auto move you to where you can see the highlighted text, this gets a bit weird if you click the continue button. But once you click the red stop button the .data.hexdump file is closed and deleted.

[kirkejohnson]

WOW, it is working. I see it highlighting line by line in the hex. Is it doing a whole line because of this particular parse and input file, or is that the level of granularity available at this time?

[arosien]

@shanedell I think it looks great, just needs some indicator of the current byte. I'll close this issue and we can add one for updating the view in the vscode repo.