블로그 CSS을 또 수정하고, 레이아웃도 좀 더 고쳤다. 간단하게 가볍게 보였으면 해서.

그런데 그간 고민해오던 것들이 있음:

1. (예전에) 귀찮아서 new-ping.pl-스크립트 같은거 짜놓고 자동 생성한 포스팅 제목으로 그대로 포스팅한 "Ping ….."-같은 제목의 포스팅들은 archives에서 봐도 뭐가 뭔지 구분이 안됨.
2. h1-같은 markdown/org-mode에서 export한 제목과 각 포스팅의 제목(이것도 h1-같은 태그인)이 눈에 딱 들게 구분이 되지 않았음.

https://github.com/ageldama/scripts-rofi-perl5

스크립트 많이 작성해서 자동화해서 쓰는데, 터미널 열거나 하기 귀찮고, 모두 한 디렉토리에 넣어두기도 정리가 안되는거 같아서 작성해서 몇 년 전부터 써왔다.

자동으로 최근 실행한 스크립트부터 표시하도록 히스토리를 저장해서 순위표시.¹

최근에 "터미널 내부에서 실행하기" 기능을 추가하고 좀 많이 다듬어서 릴리즈.

터미널 안에서 실행되어야 하는 스크립트인데, 그냥 창없이 실행되면 낭패이기 때문에², 과거 실행내역에 따라서, 터미널에서 실행하던 스크립트라면 다시 터미널에서 실행되도록 권해주기 기능도 추가.

나 같이 x윈도 환경을 커스터마이징해서 내게 맞춰서 쓰는 사람이나 좋아할거 같은 도구. ㅎㅎ

최근의 파이썬은 아주 오랬동안 multicore/parallelism을 지원하기 위해 걸림돌이었던 GIL에서 자유로워진 "no-GIL" 옵션이 베타 단계. ("free GIL" 혹은 "free threading"이라고도 부르는듯) https://blog.jetbrains.com/ko/pycharm/2025/08/faster-python-unlocking-the-python-global-interpreter-lock/

"no-GIL"이 분명히 중요한 변화이겠지만, 내겐 Python 3.14에 concurrent.interpreters 추가된 것이 더 흥미롭다.

이게 과연 Parallelism을 지원하기 위한 방식일까 하고 바로 알아차라기는 어렵지만 조금 생각해보면:

1. 새로운 프로세스를 만들지는 않는다 (multiprocessing 모듈)
2. 직접 같은 GIL을 공유하는 스레드를 만들지도 않는다 (threading 모듈)
3. 하지만, 같은 프로세스 안에서 다른 GIL을 사용하는, 파이썬 인터프리터를 만들고,
4. 다른 인터프리터와 적당한 정도로 IPC이 가능하고 (Queue 정도)
5. 다른 인터프리터가 실행했으면 하는 파이썬 코드를 전달 가능.

별거 아닌거 같지만 얻을 수 있는 이점은:

Emacs 설정을 모듈별로 분리해서 정리해서 사용한다.

다음처럼 init.el-파일에서 로딩함: 사용예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

  (ag-requires
   :tag-:*feats

   :compile  ;; ... 바이트컴파일
   'ag-feat-recentf                  ; dpkg=+
   'ag-feat-savehist                 ; dpkg=+
   'ag-feat-avy                      ; dpkg=elpa-avy

   :nocompile ;; ... 여기부터는 바이트컴파일X
   'ag-feat-rg                       ; dpkg=elpa-rg
   'ag-feat-c                        ; dpkg=+
   'ag-feat-perl5                    ; dpkg=+
   )

1. 자동으로 byte-compile해서 로딩속도 빨라지도록 매크로 짜놓았음:

   • https://github.com/ageldama/configs/blob/d7595e9f07599cbe56ee45a108d3898c5990a7bc/emacs/boot/ag-00-boot.el#L61-L95
2. 예전에 짜놓은거, 버그 고치고 다시 빠르게 로딩되도록 잘 써먹어서 기분 좋음.

의외로 단순한건데, 컴파일한 sbcl image에서 runtime에 unbound variable 컨디션을 발생시킬 수 있음.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

  (defmacro with-foo-bar (base-str (foo-var bar-var) &rest body)
    "BASE-STR에 foo, bar 문자열을 붙인 FOO-VAR, BAR-VAR 바인딩을 만들어,
  BODY을 해당 바인딩을 적용하여 실행"
    ;; NOTE let-대신 symbol-macrolet 사용해도 ok:
    `(let ((,foo-var (format nil "FOO:~a" ,base-str))
           (,bar-var (format nil "BAR:~a" ,base-str)))
       ,@body))

  ;;; 매크로 with-foo-bar 사용:
  (with-foo-bar "hello" (a b)
    (format t "~a // ~a~%" a b))
  ;; [OUTPUT] FOO:hello // BAR:hello

단순하게 코드가 커지면¹, defmacro-선언보다 해당매크로 호출이 컴파일러가 볼 때에 먼저 위치할 수 있는데, 그런 경우엔 좀 어이없지만, unbound variable 런타임 컨디션이 발생.