.-----.   .----.   .-----.  .-----.  
/ ,-.   \ /  ..  \ / ,-.   \/ ,-.   \ 
'-'  |  |.  /  \  .'-'  |  |'-'  |  | 
   .'  / |  |  '  |   .'  /    .'  /  
 .'  /__ '  \  /  ' .'  /__  .'  /__  
|       | \  `'  / |       ||       | 

=> /journal/ journal home
=> gemini://hedy.tilde.cafe/tinylog.gmi tinylog feed
=> mailto:hedy@tilde.cafe?subject=thoughts%20on%20hedy.flounder.online%2Fjournal%2F2022%2F reply via email

# December

## 28

### 14:21 Python operator precedence

()

• • (exponent)

+x, -x, ~x (unary plus, unary minus, bitwise NOT)

• , /, //, %

+, -

<<, >> (bitwise shift)

& (bitwise AND)

^ (bitwise XOR)

| (bitwise OR)

=> !=, >, >=, <, <=, is, is not, in, not in

not

and

or

## 23

### 15:35 bash - trim leading zeros

$ echo $((10#02))

2

=> https://stackoverflow.com/questions/11123717/removing-leading-zeros-before-passing-a-shell-variable-to-another-command

## 07

### 20:37 - vim window splits reference

I keep forgetting!

no splits - current window as [o]nly window
ctrl w o

swap windos
ctrl w x

split opened buffers (horz)
ctrl w s

split opened buffers (vert)
ctrl w v

go to split
ctrl w h/j/k/l

open new file as split
:sp 
:vsp 

### 20:40 Advent of Code

I attempted python solutions daily, with most ones having golf solutions.

Some have shell, golang, and lua solutions too.

=> https://github.com/hedyhli/adventofcode
=> https://tildegit/hedy/aoc
=> https://sr.ht/hedy/adventofcode

Currently up to:
2022: day 7 (ongoing!)
2020: day 9
2021: day 2

# November

## 10

### 21:06

My plant on astrobotany is still alive despite my idleness of 4+ months! Damn

### 20:43 Advent of Code revival, (n)vim macros

finishing up Advent of Code 2020

=> https://adventofcode.com/2020
=> https://sr.ht/~hedy/adventofcode/
=> https://github.com/hedyhli/adventofcode

Had to go through each puzzle page, copy its plain-text, paste it in a new file, then apply formatting manually.

There were a LOT of wrapping `code blocks` and **bold** around words. Had to make use of 5 macros (personal record!)

@a = i**Eli** # bold word

@b = i<Esc>Ei # code word

@c = i**2Wi** # 2 bold words

@d = i<Esc>Eli # code word that ends with a space

@i = i<Right> # single-char inline code

(Note I should probably write that code block in Vimscript syntax, can't remember at the moment...)

A lot of batch string parsing and validation in the first four days.


# September

## 18

### 08:13 Vim debug logs

Noting down things that had saved me so I (hopefully) don't have to search up stuff every time

=> https://stackoverflow.com/questions/3025615/is-there-a-vim-runtime-log

# August

## 31

### 15:55

Read this yesterday:

> Dictatorships are good at concealing the problems they create while democracy is good at advertising its defects.

Daily dose of Vsauce wonder

=> https://www.youtube.com/watch?v=VNqNnUJVcVs [YouTube] "Is Earth Actually Flat?"
=> https://www.youtube.com/watch?v=GDrBIKOR01c [YouTube] "Messages For The Future"

# May

## 13

### 18:36 TIL - diff unsaved changes in vim

:w !diff % -

## 08

### 18:06 journal meta

My script that parses this journal page and dumps out the content in tinylog format had hardcoded the year to 2021. Can't believe I'd only found out about this 5 months into 2022, anyways it's fixed now.

The CGI scripts that is supposed to run that ^ on demand and deploy any changes to my tinylog.gmi feed doesn't work still because CGI is run by a single user in gemserv. I'll think about how I can (safely) fix that soon.

## 07

### 15:00 spartan:// on lagrange 

Lagrange v1.13 supports spartan!

### 12:34 TIL - indexing substring and list elements in python

I always thought there were two list methods to find the index of an element in python - find and index. find would raise an IndexError when the item isn't found in the list, whereas index would return -1 in that same case.

Nope, that's completely wrong.

First, there's only .index for lists:

['a', 'b', 'c'].index('a')

0

And it raises a ValueError if the item isn't found:

['a', 'b', 'c'].index(404)

Traceback (most recent call last):

File "", line 1, in

ValueError: 404 is not in list

Method signature:

index(self, value, start=0, stop=9223372036854775807, /)

Return first index of value.

Raises ValueError if the value is not present.

Second, the "find vs. index" is for strings, not lists - both find and index methods exist for strings:

'abc'.index('a')

0

'abc'.find('a')

0

So what are the differences? Turns out my previous understanding of how find/index handles non-existent items had been mixed up. When attempting to index a substring that isn't actually in the string, index raises a ValueError, and find returns -1:

'abc'.index('z')

Traceback (most recent call last):

File "", line 1, in

ValueError: substring not found

'abc'.find('z')

-1

(Note that you can use either to search for "substrings" - i.e: `'abc'.index('bc')`)

Method signatures:

index(...)

S.index(sub[, start[, end]]) -> int

Return the lowest index in S where substring sub is found,

such that sub is contained within S[start:end].  Optional

arguments start and end are interpreted as in slice notation.

Raises ValueError when the substring is not found.

find(...)

S.find(sub[, start[, end]]) -> int

Return the lowest index in S where substring sub is found,

such that sub is contained within S[start:end].  Optional

arguments start and end are interpreted as in slice notation.

Return -1 on failure.

Just for fun, I also went ahead and tested out the performance of the two methods

$ python3 -m timeit "'abcdefghijklmnopqrstuvwxyz'.index('p')"

2000000 loops, best of 5: 131 nsec per loop

$ python3 -m timeit "'abcdefghijklmnopqrstuvwxyz'.find('p')"

2000000 loops, best of 5: 103 nsec per loop

For cases where the item isn't found:

$ python3 -m timeit -s "s='abcdefghijklmnopqrstuvwxyz'" \

  "try: s.index('Z')" \

  "except: pass"

1000000 loops, best of 5: 310 nsec per loop

$ python3 -m timeit -s "s='abcdefghijklmnopqrstuvwxyz'" \

  "try: s.find('Z')" \

  "except: pass"

2000000 loops, best of 5: 110 nsec per loop

python3 -m timeit -s "s='abcdefghijklmnopqrstuvwxyz'" \

  "if s.find('Z') == -1: pass"

2000000 loops, best of 5: 119 nsec per loop

Seems like .find() clearly wins on speed.

Here's an example of searching for the index of a substring in a string, then doing something with it:

$ python3 -m timeit -s "s = 'abcdefghijklmnopqrstuvwxyz'" \

  "if 'z' in s:" \

  "    index = s.find('z')" \

  "    print('do stuff with', index)" \

  "else:" \

  "    print('not found')"  |tail -n1

500000 loops, best of 5: 700 nsec per loop

$ python3 -m timeit -s "s = 'abcdefghijklmnopqrstuvwxyz'" \

  "if index := s.find('z') != -1:" \

  "    print('do stuff with', index)" \

  "else:" \

  "    print('not found')"  | tail -n1

500000 loops, best of 5: 686 nsec per loop

Interesting! The second method does seem more idiomatic and "clean", but can .find() truly beat python's native operator?

$ python3 -m timeit -s "s='abcdefghijklmnopqrstuvwxyz'" \

  "if 'Z' not in s: pass"

10000000 loops, best of 5: 31 nsec per loop

$ python3 -m timeit -s "s='abcdefghijklmnopqrstuvwxyz'" \

  "if 'xyz' not in s: pass"

5000000 loops, best of 5: 40.3 nsec per loop

$ python3 -m timeit -s "s='abcdefghijklmnopqrstuvwxyz'" \

  "if 'xyZ' not in s: pass"

5000000 loops, best of 5: 39.6 nsec per loop

$ python3 -m timeit -s "s='abcdefghijklmnopqrstuvwxyz'" \

  "if s.find('Z') == -1: pass"

2000000 loops, best of 5: 119 nsec per loop

$ python3 -m timeit -s "s='abcdefghijklmnopqrstuvwxyz'" \

  "if s.find('xyz') == -1: pass"

2000000 loops, best of 5: 137 nsec per loop

$ python3 -m timeit -s "s='abcdefghijklmnopqrstuvwxyz'" \

  "if s.find('xyZ') == -1: pass"

2000000 loops, best of 5: 140 nsec per loop