"One of the nice things about getting older is that you come to understand that you can integrate multiple aspects of your life together. When you're young, you think everything has to be binary, as that's exactly how you feel at that age".
- Min Jin Lee

scripts-rofi-perl5 릴리즈


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

/posts/2025-11nov/scripts-rofi-perl5-screenshot.png

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

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

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

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

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

Python 3.14 "no-GIL"보다 concurrent.interpreters, 그리고 Tcl 데자뷰


최근의 파이썬은 아주 오랬동안 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 elisp "requires"


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해서 로딩속도 빨라지도록 매크로 짜놓았음:

  2. 예전에 짜놓은거, 버그 고치고 다시 빠르게 로딩되도록 잘 써먹어서 기분 좋음.

[TIL] common-lisp defmacro와 forward-declaration


의외로 단순한건데, 컴파일한 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

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

[throttled-restart.tcl] throttling 적용하여 파일변경시 자동으로 프로세스 재시작하기와 Tcl 취향고백


코딩을 하다보면, 파일변경시에 자동으로 빌드, 서버재시작, 혹은 테스트케이스를 실행 되도록 하면 꽤 편리할 수 있다.

커먼리습 같은 경우엔 바로 실행중인 코드가 변경되는 방식이어서 신경 쓸게 별로 없고, Rails 같은 웹프레임웍은 자동으로 재시작하거나 변경된 코드를 다시 로딩해주기도 하고, PHP 계열도 웹브라우저를 refresh하면 자동적으로 새 코드으로 실행하게 된다.

다른 컴파일이 필요한 언어나, 파이썬, 펄 같은 언어들, 혹은 자동으로 코드에 반영되는 언어/프레임웍을 사용하더라도, 원하는 태스크(예: 테스트케이스 실행) 같은걸 걸어 놓으려면 커맨드라인에서 지정해두는게 낫다.