Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
C
cpython
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Deploy
Releases
Container registry
Model registry
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
OpenVMS
Python
cpython
Commits
0cf168468206
Commit
0cf168468206
authored
4 years ago
by
Skip Montanaro
Browse files
Options
Downloads
Patches
Plain Diff
bpo-43494: Make some minor changes to lnotab notes (GH-24861)
This cleanup makes no substantive changes.
parent
4b103c4240a7
No related branches found
No related tags found
No related merge requests found
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
Objects/lnotab_notes.txt
+6
-6
6 additions, 6 deletions
Objects/lnotab_notes.txt
with
6 additions
and
6 deletions
Objects/lnotab_notes.txt
+
6
−
6
View file @
0cf16846
...
...
@@ -3,7 +3,7 @@
Conceptually, the line number table consists of a sequence of triples:
start-offset (inclusive), end-offset (exclusive), line-number.
Note that not
e
all byte codes have a line number so we need handle `None` for the line-number.
Note that not all byte codes have a line number so we need handle `None` for the line-number.
However, storing the above sequence directly would be very inefficient as we would need 12 bytes per entry.
...
...
@@ -7,8 +7,8 @@
However, storing the above sequence directly would be very inefficient as we would need 12 bytes per entry.
First
of all, we can
note that the end of one entry is the same as the start of the next, so we can overlap entries.
Second
ly we also note that
we don't really need arbitrary access to the sequence, so we can store deltas.
First
,
note that the end of one entry is the same as the start of the next, so we can overlap entries.
Second
,
we don't really need arbitrary access to the sequence, so we can store deltas.
We just need to store (end - start, line delta) pairs. The start offset of the first entry is always zero.
...
...
@@ -12,7 +12,7 @@
We just need to store (end - start, line delta) pairs. The start offset of the first entry is always zero.
Third
ly
, most deltas are small, so we can use a single byte for each value, as long we allow several entries for the same line.
Third, most deltas are small, so we can use a single byte for each value, as long we allow several entries for the same line.
Consider the following table
Start End Line
...
...
@@ -36,8 +36,8 @@
Note that the end - start value is always positive.
Finally in order
,
to fit into a single byte we need to convert start deltas to the range 0 <= delta <= 254,
Finally
,
in order to fit into a single byte we need to convert start deltas to the range 0 <= delta <= 254,
and line deltas to the range -127 <= delta <= 127.
A line delta of -128 is used to indicate no line number.
A start delta of 255 is used as a sentinel to mark the end of the table.
Also note that a delta of zero indicates that there are no bytecodes in the given range,
...
...
@@ -40,8 +40,8 @@
and line deltas to the range -127 <= delta <= 127.
A line delta of -128 is used to indicate no line number.
A start delta of 255 is used as a sentinel to mark the end of the table.
Also note that a delta of zero indicates that there are no bytecodes in the given range,
which means can use an invalid
ate
line number for that range.
which means
we
can use an invalid line number for that range.
Final form:
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment