mrjimenez
Problem when trying to Upload a XSVF
Hi !
I have uploaded the sketch to my Arduino nano, connected it to an ATF1504AS and tried to Upload a XSVF File to it with the Python scripts.
I enter this Command to Upload the file:
python xsvf -p /dev/ttyUSB0 FE3Test.xsvf
And here is the Error Message, that I get when trying to Upload the XSVF File:
snocksman@raspberrypi:~/JTAG/extras/python $ python xsvf -p /dev/ttyUSB0 FE3Test.xsvf
Traceback (most recent call last):
File "/home/snocksman/JTAG/extras/python/xsvf", line 57, in <module>
main()
File "/home/snocksman/JTAG/extras/python/xsvf", line 46, in main
u.upload_all_files(args.fileName)
File "/home/snocksman/JTAG/extras/python/Uploader.py", line 150, in upload_all_files
ok = self.upload_one_file(fd)
File "/home/snocksman/JTAG/extras/python/Uploader.py", line 144, in upload_one_file
line.translate(Uploader._translate_str))
TypeError: a bytes-like object is required, not 'str'
What can I do to get it running...?
Hey Walheimat, yes, I have thought about a feature like this many times. Footprints do indeed get very cluttered after a while, and you tend to accumulate a lot around the same area where you are focused at any given time. However, I had yet to think of a really performant way to fix the problem.
The trouble is, the log of gumshoe--entries are (currently) stored in a linear list, and not within the buffer itself until backtracking starts, and are removed after it ends. They also can't practically contain metadata about their line, because lines are subject to change as the buffer is edited. So the line must be computed dynamically from the position, and that can be a bit expensive because Emacs basically just iterates through and counts newlines when you get the line number. So to decide whether a new entry should be added at a given point based on proximity to other entries currently requires searching through that list, and for each entry calculating the line number, and seeing if it is on the current line, etc. It's nasty, like O(len(gumshoe--log) x len(buffer)), not something I want to compute a lot.
But since you have noticed as well, thinking about this again, it seems I should be able to make some optimizations to make this feasible. I could define an operation that iterates through the list and collects those on the same line and makes a decision about which to delete. That decision I expect, would pick the most recent entry on the same line, then the next youngest entry over the horizontal-distance away, or until we hit a newline. It's complicated, but could be run during a periodic cleanup, every few seconds, or after N commands. This doesn't seem too difficult to implement, but it remains to be seen how bad the performance will be.
Another possible fix might be somehow stacking footprints at the same location, and adding a superscript of some sort so it clears up that space at least visually. Then you don't lose any information. Though you still might have nearby entries on that line...
I'll just play around with things and see what shakes out...
Have you considered using point-marker instead of point in the structure? Not sure what all of the repercussions are, but the problem you describe could be mitigated. You would get a marker object instead of a buffer position that could point to different things in the course of editing. Would have to test if Emacs has some kind of limitations of loose markers flying around.
EDIT:
I added a PR to give you an example of what I mean (the code would need to be cleaned up). I gave this a quick run and this could maybe be viable?
Hey Walheimat, sorry for getting back so late. Thanks for putting that PR together. I had used markers in a previous iteration, but after looking into it again, I don't think I had really appreciated their features, specifically that they can be auto-advanced when text is inserted around them. That was certainly not happening in my version. I think your implementation was very reasonable. But when I started thinking back to the original problem, I wanted to basically be able to find high density clusters of entries within the buffer, so I needed something in the buffer itself to search for things by proximity. So since I am already using overlays for the footprints, I decided to start storing them persistently in the buffer, rather than deleting them after backtracking. It turns out, overlays have pretty much all the features of markers, in that they will auto-advance when text is inserted, plus all the other cool features of overlays. I was also able to store a reference to the container entry in the footprint, which lets me operate on them at the buffer level, then adjust entries accordingly.
The result here for this first pass, is I've decided to "cover" old entries within some radius, by setting gumshoe-cover-old-footprints-p to t(it is by default now), and gumshoe-footprint-radius, respectively. For now, the older footprints are still there, but they are not shown until you backtrack back to them. I will make a new version later that will just optionally remove those older entries completely, but I want to change the backlog container type first.