[카테고리:] 계산

nonparaeff 패키지를 처음 작성했던 게 아마 포닥을 하고 있을 때였던 것 같다.
혼자 쓰다가 CRAN에 업로드를 하고자 매뉴얼도 작성해서 Kurt에게 메일로 submission을 하면 Kurt가 CRAN으로 업로드를 하는 시스템이었는데, 이제는 자동 submission 시스템으로 바뀌어서 무척 편해졌다.
DEA 책을 쓰면서 자잘한 함수들을 몇개 더 만들고, 버그도 수정해 가면서 2013년에 0.5.8 버전을 만들고 그 이후는 귀찮아서 업데이트를 하지 않았다.

그 동안에 Kurt가 패키지 업데이트가 필요하다는 메일을 자꾸 보내왔다.
NAMESPACE를 작성해서 패키지를 수정하라는 것이었는데, NAMESPACE가 뭔지를 모르니 무시를 하곤 했다.
내가 패키지를 만들던 시절에는 매뉴얼에 NAMESPACE에 대한 내용이 없었거나 내가 귀찮아서 안 읽었거나, 둘 중의 하나인데.. 아무튼 NAMESPACE에 대해서 시간을 내서 공부하기가 싫었다.

저번주에는 Kurt에게서 최후 통첩이 날아왔다. Compind 패키지와 의존성 문제가 생기는 문제를 해결하지 않고 NAMESPACE를 작성하지 않으면 패키지를 CRAN에서 내리겠다는 내용이었다. 내 nonparaeff에 의존하는 패키지가 있다는게 살짝 기쁘기도 했지만, 어쨋든 매뉴얼을 새로 읽고 뭔가를 고쳐야 한다는 압박감과 귀찮음이 동시에 밀려오기도 했다.

할 수 없이 저번주부터 다시 R Packages라는 책을 띄엄띄엄 읽어가면서 고칠 부분을 조금씩 손을 봤다. Writing R Extensions 매뉴얼보다 더 친절하게 쓰여 있어서 읽기가 무척 수월하기도 했고, 무엇보다 이런 유용한 정보를 Wikibooks로 뿌려서 저자에게 고마운 마음이 들었다.

---

R 버전이 올라가면서 DESCRIPTION 파일의 i) Depends 항목을 될 수 있으면 쓰지 말아야 하며 Imports와 Suggests 항목이 그 역할을 대신하고, ii) NAMESPACE 파일에서 다른 패키지에서 꼭 필요한 함수들만 불러오는 방식으로 정책이 바뀌었다는 것을 드디어 알아냈다.

DESCRIPTION 파일에서 Authors@R 항목이 신설되었고 Author와 Maintainer 항목은 쓰지 않을 것을 권고하고 있으나, 실상 Author와 Maintainer 항목을 쓰지 않으면 에러가 발생했다.
Authors@R 항목으로 쓰려고 했지만 어쩔 수 없이 Author와 Maintainer 항목을 구분해서 작성했다.
예전에는 Author에 한명만 기록을 할 수 있었던 것 같은데, 이제는 여러명을 comma로 구분해서 쉽게 넣을 수 있게 되었다.

중간에 한글로 커멘트를 달아놓은 ar.dual.dea()함수는 뭔가 더 작업을 해야 할 것 같은데, 그 작업을 하기 귀찮아서 아예 패키지에서 삭제해버렸다.

CRAN에 submission을 하면 NOTE들을 해결하라고 몇번 빠꾸를 먹다가, 어제는 제대로 submission을 한 것 같아서 Francesco Vidoli에게 제대로 submission을 했다는 메일을 보내고 퇴근을 했다.
그러나 운전 중에 reverse dependency 문제가 발생했다는 메일을 받았다.
이런 것까지 내가 신경을 써야 할 필요가 있을까 짜증이 밀려왔지만, reverse dependency 문제를 보고하는 시스템이 있어야 패키지 작성자들이 제대로 패키지를 작성하게 된다는 결론에 이르러서 얼른 문제를 해결하겠다고 마음을 또 먹었다.

---

Compind 패키지의 NAMESPACE 파일을 살펴보니, ar.dual.dea() 함수를 사용하고 있어서 reverse dependency 문제가 발생한 것이었다. "소스코드를 다 뜯어볼 필요없이 NAMESPACE 파일만 보면 여러 문제가 해결되네. 이래서 NAMESPACE 파일이 필요한 거구나"라고 혼잣말을 하면서 R 개발자들에게 찬사를 보냈다. "역시 똑똑한 사람들은 설계를 잘 해"

집에서는 컴퓨터를 켜기가 싫어서 Vidoli에게 '내일 출근을 해서 롤백하겠다'고 메일을 보냈지만, 이 아저씨는 냉큼 ar.dual.dea()함수를 사용하지 않게끔 Compind 패키지를 재작성해서 submission을 한 것 같다.

오늘 출근을 하고 ar.dual.dea() 함수를 다시 집어넣고, DESCRIPTION 파일과 NAMESPACE 파일들을 손보고 다시 submission을 했다.

이번에는 에러가 발생하지 말기를 바라면서 이 글을 작성하고 있다.

Mac을 2007년부터인가 쓴 것 같은데,
항상 불편했던게 한영전환과 한글입력이었다.

윈도우를 쓸 때부터 한영전환은 shift+space로 사용하고 있었는데,
Mac은 OS 버전이 메이저 업데이트 될 때마다 shift+space로 설정하는 방법이 달랐다.

이번 Monterey 에서는 한영 전환을 시도하면 화면 중간에 다음과 같은 보기 싫은 작은 투명 윈도우가 생기기도 하고, 한영 전환 딜레이가 생기기도 하며, 항상 첫글자는 전환되기 전의 언어가 입력이 된다.

그래서 한영 변환을 해서 한 템포 쉬고, 한 글자를 친 다음에 backspace로 그 글자를 제거한 후에 원래 입력하고 싶었던 문자들을 쳐 넣고는 했다.
Monterey로 처음 업데이트하고 나서 무척 당황스러웠지만, 며칠 쓰고 나니 그렇게 적응이 되어갔다.

그저께 갑자기 첫글자가 내 맘대로 입력이 안 되는 상황이 짜증이 났다.
아마 그 동안 짜증이 났던 것이 쌓여 있다가 한꺼번에 터져나온 것일 수도 있다.

그래서 구글링을 통해서 구름입력기의 존재를 알게 되고 설치를 했다.

곰곰이 생각해보니, 2007년엔가 한영 전환이 힘들어서 바람입력기를 썼던 기억이 났다.
그래서 한 때는 한영전환 및 한글 입력에 어려움을 겪지 않았던 적도 있었던 것 같다.
그러다가 바람입력기가 언제부터 관리되지 않았고, 나는 OS 기본 입력기에 재정착을 하게 된 것 같다.
사실 너무 오래 전 일이라 기억도 잘 나지 않지만, 바람입력기를 사용했던 적은 있었다.

구름입력기를 써보니 무척 편하다.

1. 구름입력기 1.12.0 버전을 설치한 후에
2. 시스템 환경설정 -> Input sources 에서 Han 2set을 추가해주고,
3. 시스템 환경설정 -> Shortcuts -> Input Sources에서 'Select the previous input source'의 단축기를 Ctrl+Shift+Space로 설정하고 체크한다. 혹시나 umlaut 등을 입력할 일이 있을까봐... 아직 구름입력기에서 umlaut를 입력하는 방법은 모르기 때문에...
4. 메뉴바에서 Input Source를 구름입력기로 선택한 다음,
5. 구름입력기 환경설정에 들어가서, '한글/로마자 바꾸기 단축키'를 Shift+Space로 설정한다. 혹시나 싶어서 '오른쪽 키로 언어 전환'을 Command 키로도 설정해 놓았다.

구름입력기가 다 좋은데, WordPress의 WP Githuber MD랑은 궁합이 잘 안 맞는 것 같다. WP Githuber MD에서 한 글자가 완성되기 전에 그 글자는 제대로 보이지 않는다.

2022년 4월 24일 추가

Silicon Mac의 iTerm2에서 shift+space 입력할 때 space가 하나 추가되는 버그가 있는 것 같아서, 연구실 Mac에서는 기본 한글 입력기로 다시 돌아가서 쓰고 있다.

plist 파일을 수정해서 select next input source in input menu에서 Shift+Space로 만들었더니, 이제는 예전과 같은 문제가 발생하지 않아서 그냥 기본입력기를 쓰련다.

Intel Mac의 iTerm2에서는 별 문제 없이 구름입력기가 작동해서 구름입력기를 사용중이다.

연구실 NAS에는 webdav를 이용해서 파일을 공유하고 있었으나, 무척 느렸다.
1MB 정도되는 작은 파일도 복사 시간이 한참 걸렸다.

그래서 오늘은 afp를 활성화했다.

584번 포트를 방화벽에서 열었는데, 별 일 없겠지.

이제는 집에서도 NAS에 원활하게 접속해서 작업을 할 수 있을 것 같다.

SELECT GROUP_CONCAT(CONCAT("'",COLUMN_NAME,"'"))
  FROM INFORMATION_SCHEMA.COLUMNS
 WHERE TABLE_NAME = 'tmp3'
 ORDER BY ordinal_position;
SELECT 'appln_id',
       'docdb_family_id',
       'filing_year',
       'appln_title',
       'GRANTED',
       'doc_std_name',
       'doc_std_name_id',
       'person_ctry_code',
       'applt_seq_nr',
       'invt_seq_nr',
       'earliest_filing_year',
       'priority',
       'person_address_id',
       'company_name',
       'firm_id',
       'person_state',
       'person_country',
       'person_lat',
       'person_lng',
       'clean_person_address',
       'country',
       'capital',
       'firm_id2',
       'hq_state',
       'hq_country',
       'hq_lat',
       'hq_lng',
       'hq_address'
 UNION ALL 
SELECT DISTINCT *
  FROM tmp3
 WHERE firm_id2 = 383
 ORDER BY earliest_filing_year,
          docdb_family_id,
          applt_seq_nr,
          invt_seq_nr
  INTO OUTFILE '/tmp/schott_solar.txt';

현도와 쓰는 논문의 데이터 분석을 거진 마치고 마지막 하나만 추가분석을 하면 되는 찰나에 갑자기 R을 업데이트하고 싶은 욕망이 들끓었다.

R-4.1.3으로 업데이트를 했고,
패키지들을 update.packages() 명령으로 업데이트했더니 역시나 패키지들이 제대로 작동하지 않는다.

그래서 /Library/Frameworks/R.framework 디렉토리를 통째로 지우고
R-4.1.3을 새로 설치하고
마음에 드는 패키지들만 우선 설치를 해 두었다.

다음 차례는 emacs 패키지들 업데이트.
init 파일 조금 손보고 패키지를 업데이트하고 난 후에 아무 생각없이 Homebrew를 통해서 emacs를 28.1로 업데이트했다.

그랬더니, 터미널에서 화면이 무지 깨지는 불상사가 발생.

다시 27.2로 돌아가려고 했지만 이미 homebrew repo에는 27.2 버전을 내린 상황...

소스코드를 갖고 컴파일을 하자니 의존성 문제 때문에 하루 이상은 걸릴 것 같고, 이리저리 서핑을 해보니brew extract 명령으로 설치가 가능한 것 같았다.

https://www.44bits.io/ko/post/install-specific-version-package-homebrew#%ED%8A%B9%EC%A0%95-%ED%8C%A8%ED%82%A4%EC%A7%80%EC%9D%98-%EA%B5%AC-%EB%B2%84%EC%A0%84%EC%9D%84-%EB%A0%88%EC%8B%9C%ED%94%BC-%ED%8C%8C%EC%9D%BC%EB%A1%9C%EB%B6%80%ED%84%B0-%EC%A7%81%EC%A0%91-%EC%84%A4%EC%B9%98%ED%95%98%EA%B8%B0

그러나 역시 제대로 설치가 되지 않아 구글링을 더 하다가, 다음 링크에서 emacs-27.2를 제대로 배포한다는 것을 알아냈다.
그러나 역시 daemon을 수도 없이 띄우는 버그가 있었다.
https://github.com/daviderestivo/homebrew-emacs-head

일이 바쁘니 우선은 28.1로 쓰다가, 조만간 28.2가 나오면 업데이트하거나 아니면 27.2로 다운그레이드를 제대로 하는 법을 알아봐야겠다.

다시 emacs-28.1을 사용해보니 화면이 깨지는 경우는 딱 한가지였는데, 한글 입력이 불완전한 경우였다(사실 이 경우는 무엇인지 제대로 파악을 못 했지만). 이 한글 입력을 제대로 다시 했을 때 화면이 깨지는 문제는 사라졌다.

그래서 다시 emacs-28.1을 잘 쓰고 있다.