focus/log email for working on bug[s] in tree iteration
1837 ET i am still happy to be spending time engaging this without
stimulating too many issues.
1837 i am remembering that the issue is happening between the 1st and
2nd leaf, and that i was curious about why i didn't see evidence of
ascending after the 1st leaf.
1838 maybe it is because the 1st "leaf" is in a larger node that gav
it sibling leaves, liek the 3 at the end of the 5-childed node. ...
however it still would be a direct data node then, not an index
1838 i'll step through it
1839 i set a breakpoint on the first leaf output, and it's doing its
thing. it isn't optimized. downloads chain bits over network.
1840 i finished typing, it finished before i did, it's printing it
1842 i replied to zeynep, a smidge funny email relation during finding reply
1843 so
- 75 stream_output_offset += length -> 100k
- 79 index_offset_in_stream += index_subsize -> 100k
advances 1 sibling
1845 ok i dumped the tree and it does indeed have a tree node to the
right of a data node. that doesn't seem correct to me.
(
[
[0, {'capture': {'ditem':
['4csX1gHqv5OK04kBmXJKIuLU6KWifFn_X9trt1raMho']}, 'min_block':
[995159, '-p20J8zfYeZn8jFYiV-X4I62ubge3RW-2pthuB_hN5LrKqA2L4tvX55fgwSoAatG'],
'api_block': 995559}, 0, 100000],
[1, {'ditem': ['LgV_rMSeKYUhrd4lxvxC4b6Ak2NI-ZhG931TyG-TDfI'],
'min_block': [995159,
'-p20J8zfYeZn8jFYiV-X4I62ubge3RW-2pthuB_hN5LrKqA2L4tvX55fgwSoAatG'],
'api_block': 995559}, 100000, 100000],
[0, {'capture': {'ditem':
['5dUdkX4EJUkhlpKNbQ8q_lrLA-HuEoMhBrrEeaAvT44']}, 'min_block':
[995159, '-p20J8zfYeZn8jFYiV-X4I62ubge3RW-2pthuB_hN5LrKqA2L4tvX55fgwSoAatG'],
'api_block': 995559}, 0, 100000]
],
0, 0, 300000
)
that seems weird to me
1848 engaging not sure whether to send or keep open
1849 seems like pressure to stop is happening. i guess keeping this
open, rather than sending, could maybe help me develop skills near
other coping strategies in my life, if am lucky, may be true
1850 i am actually having trouble moving forward. i guess i'll find
smaller, simpler nearby behaviors.
1850 here's a line of code:
header, stream, length =
self.dataitem(ditem, index['min_block'][-1])
yayy line of code.
1850 ok i remember i ran into an index that strangely had a 0 type to
the left of a 1 type. i guess that could mean a bug in the upload :/.
i'll see what happens for the rest of the iteration. 1851
1852
- adds the sibling to visited (hum this could make error too)
- descends into sibling
the sibling has a strange and similar tree to the first leaf. it has
data, then it has a tree node that is 0-sized. then it has data again.
total size:200k. not right.
i looked inside the second entry in the index, and it is the zero
leaf, the first index. so the size is 0 because it is only 100k long.
upload error.
i guess the upload error is more important than the iteration error.
latter kind of hinges on the former having already succeeded. so i'll
focus on the upload error. 1855 .
1856. hard to stay. maybe i can pretend to spam the list ;p
[can of ham] .
1857 maybe copy some of the code in again
visited.add(ditem)
header, stream, length =
self.dataitem(ditem, index['min_block'][-1])
1857 i'll spend some time poking at code bits.
if the upload is failnig, i think i uploaded from capture.py . i'll check there.
1858 maybe i could add asserts for the exceptionals in the uploader
and just run it
ohhhhhhhhhhhhhhhhhh i think i figured part of the issue out, maybe
the data may be more valid than i thought. forgetting what i figured out now :S
1900 i'll step through the sibling again
1902 ok ummmmm so the first leaf is normal. the second leaf adds an
empty reference onto the first leaf, an upload bug but the data may
still be consistent. so the second leaf has a 3-child root.
1904 the balancing is done based on leaf count ....
1903 i'm just going to stay here for a bit ... i'm also going to send
this because it gives me ease ... quite hard to stay on this, like the
idea of shrinking the task ...
