0438
bumping into this:
Found a swap file by the name ".mix_indices.py.swp"
owned by: ubuntu dated: Sat Aug 13 04:37:48 2022
file name: ~ubuntu/src/flat_tree/mix_indices.py
modified: YES
user name: ubuntu host name: ubuntu
process ID: 30926 (STILL RUNNING)
While opening file "mix_indices.py"
dated: Fri Aug 12 13:05:50 2022
guess i'll poke through my open tmux panes.
my tmux thingy crashed a couple days ago, and wouldn't recover despite
caching its state, crashing whenever it launched until i rest it, and
i only have a couple tmux windows open now
current window, #1:
>>>
────────────────────────────────────────────────────────────────────────────────
ubuntu@ubuntu:~/.local/lib/python3.9/site-packages/pimux $
────────────────────────────────────────────────────────────────────────────────
>>>
────────────────────────────────────────────────────────────────────────────────
be careful not to end up with two different instances of the same
file when making changes. Quit, or continue with caution.
(2) An edit session for this file crashed.
If this is the case, use ":recover" or "vim -r mix_indices.py"
to recover the changes (see ":help recovery").
If you did this already, delete the swap file ".mix_indices.py.swp"
to avoid this message.
Swap file ".mix_indices.py.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (A)bort:
Swap file ".mix_indices.py.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (A)bort:
Swap file ".mix_indices.py.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (A)bort:
────────────────────────────────────────────────────────────────────────────────
- subregion of index 147,1-8 98%
[1] 0:bash- 1:vim* "ubuntu" 04:39 15-Aug-22
and here's window 0:
assert spliced_out_start == self.size # until testing
truncation appends
assert spliced_out_stop == self.size
running_size = 0
running_leaf_count = 0
#leaf_count_of_partial_index_at_end_tmp = 0
#proposed_leaf_count = self.leaf_count -
leaf_count_of_partial_index_at_end_tmp
#new_node_leaf_count = self.leaf_count # + 1
new_leaf_count = self.leaf_count
new_size = self.size
20,5 28%
────────────────────────────────────────────────────────────────────────────────
ubuntu@ubuntu:~/src/intellect/garden-of-the-misunderstood $
────────────────────────────────────────────────────────────────────────────────
pip' command.
ubuntu@ubuntu:~/.vim/bundle/vim_codex $
────────────────────────────────────────────────────────────────────────────────
he indices. 51,91 Bot
[1] 0:bash* 1:vim- "ubuntu" 04:39 15-Aug-22
looks like window 0 is indeed open to that file.
0439
0440
noting a sad thing here.
i started using pyminiaudio to record audio, but:
- it didn't install on my system without patches
- it segfaulted when it started recording
i opened an issue for the first item, and the maintainer was addressed
it in reasonable time and published a new release.
in the meantime, i had used recording code written in C instead,
calling the cross-platform miniaudio backend directly.
i didn't tell the maintainer about issue #2. at first it was because i
hadn't gotten a reply for #1 and i didn't want to burden them, but by
the time i had made the C code, it seemed so much better to make the C
code that i didn't want to encourage people to write this app in
python. i'm a little confused around it, but the segfault actually
helped me write faster code that got closer to the general purpose
backend. bugfixes i make now will help more people, because i'm using
the underlying library directly.
[0442ish]
it's confusing. we need more people working on community stuff. i'm
not sure what to think of it all. but it makes sense to move the whole
program into being a compiled language, because it's realtime, and it
can be hard to think of when there has been so much python culture.
0443.
0445 celebrating recognition that flat_tree and log are overlapping
projects that share means and possibly ends. integration rather than
dissociation. 0445 .
0447
i'm in ~/src/flat_tree
$ python3
...
>>> import test
...
[(9, 0, 35, 9), (9, 35, 47, 18), (3, 82, 8, 21), (1, 90, 4, 22), (1,
94, 7, 23), (-1, 0, 4, b'y~\xfat')]
>>>
0447
>>> test.stored_indices[9]
[(3, 0, 17, 3), (3, 17, 8, 6), (1, 25, 3, 7), (1, 28, 6, 8), (-1, 0,
1, b'\x95')]
>>> test.stored_indices[3]
[(1, 0, 5, 1), (1, 5, 8, 2), (-1, 0, 4, b'\xb5\x1d\xa0\x1f')]
>>> test.stored_indices[1]
[(0, 0, 0, 0), (-1, 0, 5, b'\xe7\x19\x14(\xeb')]
>>> test.stored_indices[2]
[(1, 0, 5, 1), (-1, 0, 8, b'\xfb\xc4\xf3d\x11\xc5|d')]
it looks like this data structure doesn't have the bug where
zero-lengthed branches are inserted prior to appends. it does
wastefully include an empty branch at the start, but that is much less
impactful.
0449 man my arms are all shaky and stuff and i have to just ignore it
to the dissociated behavior modeling ;S ;p :|
0450 k not sure what's next so i'll copy code back and forth to build
some cognition around the topic
>>> test.stored_indices[2]
[(1, 0, 5, 1), (-1, 0, 8, b'\xfb\xc4\xf3d\x11\xc5|d')]
ubuntu@ubuntu:~/src/flat_tree $ ls -l
total 16
-rw-rw-r-- 1 ubuntu ubuntu 1242 Aug 12 13:04 append_indices.py
-rw-rw-r-- 1 ubuntu ubuntu 2777 Aug 15 04:46 mix_indices.py
0450
considering:
- flat_tree needs more work
- flat_tree is technically usable now
i'll add methods to mix_indices to output just enough tree for
accessing the data, without the leaf count and stuff, i suppose
each node has a type, too.
type representations are different. :S 0451 . this one represents type
with a negative leaf count on leaves.
it would be more compact i suppose to differentiate based on the
locator, but i guess i'll include type somehow.
it would probably make sense to add a method to traverse the tree too
maybe i'll make a wrapper class so i can keep the theory part easier
to work with.
0452
0453 second guessing this choice pretty strongly, happens a lot, never
sure when to include for sure
0453
# indexes a balanced tree of past indices
# every write, publish a .copy() paired with data, then pass the
locator to .append() to index it
class append_indices(list):
0454
i think my wrapper class made sense. maybe it causes an issue later,
but i don't understand that well.
0456
0457
from . import mix_indices
class append_tree:
def __init__(self, degree = 2):
self.obj = mix_indices.append_tree(degree)
def append(self, last_snap_locator, added_size, added_data_locator):
self.obj.append(last_snap_locator, added_size, added_data_locator)
def snap(self):
0457
working on it without fully/really understanding, just trying to make
it easier to work on.
big pattern !
0458
