Are viewports sufficient to handle setting breakpoints for use in a debugger? #186
scholarsmate
started this conversation in
Ideas
Replies: 1 comment 1 reply
-
If we need a concept of a floating viewport, we can add a fixed/floating property and a starting offset adjustment property, initialized to zero, to the viewports, so that when data is inserted before (to the left of) the starting offset of the viewport, we add the number of bytes inserted to this adjustment, or if bytes are removed, we subtract the number of bytes from this adjustment. We add this adjustment to the initial viewport offset to determine its current offset. If it's fixed, the adjustment is always 0, and if it's floating, the adjustment changes are made.
|
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
There is a need for Ωedit to provide some kind of facility for setting things like breakpoints at key positions in data. The core concept of Ωedit is tracking data movement (changes) from the start of a session to the end of session. Ωedit uses a concept of efficient, light-weight viewports to fire off callback events when things change. Viewports are fixed at a given span (defined using offset and capacity). As data changes within this fixed span, callbacks are fired so the calling application has an opportunity to react to the changes taking place within this span (typically to refresh a visual component with updated data). In other words, viewports are used to subscribe to data changes in a given fixed span. The viewport span can be as small as 1 byte, or as large as the whole file. If we implement a way to visit all the viewports created in a session, will this be sufficient to implement breakpoints for use in a debugger?
Beta Was this translation helpful? Give feedback.
All reactions