글

라벨이 CSI인 게시물 표시

Linux의 clear와 Mac의 clear는 다르다

-
최근 CSI Sequence에 대한 글을 열심히 쓰고 있지만, 우리가 직접 CSI Sequence를 직접 사용할 일은 거의 없다. 하지만 알게 모르게 사용하는 CSI sequence가 있다. 바로 화면을 지우는 데 사용되는 clear 라는 명령어다. clear 는 기본적으로 두 가지 종류의 CSI sequence를 사용한다. 하나는 CUrsor Position(a.k.a CUP; CSI H )다. 이것을 이용해 커서를 화면의 시작으로 돌린다. clear 를 하고 나면, 최상단 왼쪽으로 커서가 움직이는 것은 CUP 덕분이다. 두 번째 CSI sequence는 Erase in Display(a.k.a. ED; CSI 2 J )다. 이를 이용해 화면 전체를 지운다. 여기까지는 Linux와 Mac이 공유하는 동작이다. 하지만 이후 동작에서 Linux의 clear 와 Mac의 clear 는 다르게 동작한다. 간단하게 말하면 Linux의 clear 는 스크롤 버퍼를 지우고, Mac의 clear 는 지우지 않는다. 이는 Linux의 clear는 앞의 두 시퀀스에 이어 CSI 3 J 를 출력하기 때문이다. CSI 3 J 는 xterm 이 도입한 Escape Sequence의 확장으로 스크롤 버퍼에 저장된 라인을 지우는 시퀀스다. 2011년 레드 햇 진영에서 E3라고 이름붙인 뒤 로 터미널 에뮬레이터에서는 E3 확장이라고 부르기도 한다. Mac의 clear 는 이 시퀀스를 출력하지 않기 때문에 스크롤 버퍼를 남겨둔다. 이런 차이가 발생한 것은 생각보다 오래된 일은 아니다. 원래 대부분의 터미널 에뮬레이터들은 E3 확장을 비롯한 xterm 확장들을 이해하지 못했다. 당연히 이 시절에는 Linux에서 사용되던 clear 커맨드도 E3를 사용하지 않았기 때문에 스크롤 버퍼는 지우지 않았다. 하지만 시간이 지나며 점점 xterm 확장은 다른 터미널 에뮬레이터로 전해져오며 E3도 구현되기 시작했다. 2007년 PuTTY , 2011년 Red Hat , 2014년 Gnome
댓글 쓰기
Read more »

[CSI Sequence] 화면 지우기

-
오늘은 지난 글 에 이어서 CSI Sequence를 이용해 화면을 지우는 방법을 알아보도록 하겠다. CSI Sequence에는 화면을 지우는 시퀀스가 2개 있다. 첫 번째는 EL이라고 불리는 Erase in Line 시퀀스다. CSI # K 로 구성된 시퀀스로 이름 그대로 줄을 지우는 데 사용되는데, # 을 주지 않으면 기본값은 0으로 처리되며, 값을 준다면 0, 1, 2 총 세개중 하나를 줘야 한다. 이외의 값이 오는 경우 시퀀스 자체가 무시된다. 예를 들어 0x311b5b334b32 즉, 1^[3K2 같은 값을 출력하면 ^[3K 는 무시되고 화면에 12 만 출력된다. 0, 1, 2의 동작은 정리하면 다음과 같다. 0 커서부터 줄 끝까지 지운다. 1 줄 시작부터 커서까지 지운다. 2 커서의 위치와 상관 없이 줄 전체를 지운다. 주의할 점은 EL 시퀀스는 커서의 위치를 옮기지 않는다는 것이다. 즉, 지금 쓴 줄을 지우고 새로운 줄을 쓰고 싶으면, EL 시퀀스와 캐리지 리턴 (\r)을 같이 사용해줘야 한다. 두 번째는 ED라고 불리는 Erase in Display 시퀀스다. CSI # J 로 구성된 시퀀스로 이름 그대로 화면을 지우는 데, EL과 마찬가지로 # 의 값에 따라 화면의 어디를 지울지를 결정한다. 0 커서를 기준으로 화면 끝까지 지운다. 1 화면 시작부터 커서까지 지운다. 2 커서의 위치와 상관 없이 화면 전체를 지운다. 3 스크롤 버퍼에 저장된 라인을 지운다, 기본적으로 EL과 같은 느낌이다. 기본값이 0인 것도 같고, 커서의 위치를 옮기지 않는 것도 같고, 정해진 값 이외의 값이 들어오면 무시하는 것도 같다. 단 하나의 차이는 EL에 없는 3이 추가된 것이다. 이 시퀀스는 스크롤 버퍼에 저장된 값을 지우는 시퀀스다. 원래 VT100 시절에 있던 시퀀스는 아니다. 그 시절 터미널에는 스크롤이라는 개념이 없었다. 이 시퀀스는 X 윈도우 시스템 과
댓글 쓰기
Read more »

[CSI Sequence] 커서 옮기기

-
Code Abbr Name CSI # A CUU CUrsor Up CSI # B CUD CUrsor Down CSI # C CUF CUrsor Forward CSI # D CUB CUrsor Backward CSI # E CNL CUrsor Next Line CSI # F CPL CUrsor Previous Line CSI # I CHT Cursor Horizontal forward Tabulation CSI # Z CBT Cursor Backward Tabulation CSI # G CHA Cursor Horizontal Absolute CSI # ; # H CUP CUrsor Position 오늘은 지난 글에 이어 이번 글에서는 CSI sequence를 이용해 커서를 옮기는 방법에 대해 알아보겠다. 커서를 옮기는 CSI sequence의 종류는 위와 같이 정리할 수 있다. CUU, CUD, CUF, CUB 이들은 각각 CUrsor Up, CUrsor Down, CUrsor Forward, CUrsor Backward의 약자로 이름 그대로 커서를 위, 아래, 앞, 뒤로 이동한다. 인자로는 한 개의 숫자를 받고, 만약 인자가 생략되면 1로 취급된다. 즉, 0x1b[A 는 0x1b[1A 와 같은 의미이다. 이때 CUF나 CUB는 같은 줄 내에서만 움직이며 줄의 시작에서 CUB를 받아도 이전 줄로 움직이지 않고, 줄의 마지막에서 CUF를 받아도 다음 줄로 움직이지 않는다. 이런 동작을 원하면 각각 reverse auto-wrap 모드와 auto-wrap 모드를 켜야 하는데, 이 모드를 지원할지는 터미널별로 다르다. CNL, CPL 이들은 각각 Cursor Next Line, Cursor Previous Line을 의미하며, 커서를 다음 줄 혹은 윗줄로 옮긴다. CUU와 CUD는 커서의 column을 유지한 채 줄을 바꾼다면, CN
댓글 쓰기
Read more »

CSI Sequence의 구조

-
^[ [78G|/- ^[ [17;79H\_ ^[ [9;1H ^[ [1P ^[ [79G|( ^[ [11;79H/ ^[ [K 임베디드 프로그래밍을 해본적 있다면, 임베디드 장치의 시리얼 포트를 연결했을 때, 위와 같은 문자열이 전송돼는 것을 보았을 것이다. 여기서 ^[ 로 시작하는 문자열은 ESC ( \0x1b )를 나타내는 특수한 제어문자로, 이 정체불명의 문자열의 정체는 터미널을 제어하는 escape code를 의미한다. escape sequence 중에서 [로 시작하는 시퀀스를 control sequence 혹은 CSI sequence라고 부른다. control sequence를 시작하게 하는 ESC [ 를 CSI (Control Sequence Introducer라고 부르기 때문이다. CSI sequence는 CSI 를 시작으로 @ , ` , 혹은 알파뱃으로 끝나는 일련의 시퀀스로, CSI 와 마지막 문자 사이에 임의의 개수의 파라미터로 구성되는데, 이때 파라미터는 ASCII로 정의 된 0 ( 0x30 )- 9 ( 0x39 )로 표현되며, 파라미터 사이는 ; ( 0x59 )로 구분된다. 즉, 위의 예제에서 ^[ [78G 는 숫자 78을 파라미터로 받는 G로 끝나는 CSI sequence를 의미하고, ^[ [17;79H 는 숫자 17과 79를 파라미터로 받는 H로 끝나는 CSI sequence를 의미한다. 이번 글에서는 ESC(0x1b)로 시작하는 CSI sequence의 개념과 기본적인 구조에 대해 살펴보았다. CSI sequence는 터미널의 커서 위치, 색상, 속성 등을 제어한다. 이를 활용하여 터미널에서 다양한 동작을 수행하는 프로그램을 개발할 수 있다. 다음 글에서는 CSI sequence의 종류와 각각의 기능에 대해 자세히 설명해보겠다.
댓글 쓰기
Read more »

이 블로그의 인기 게시물

[C++] enum class - 안전하고 쓰기 쉬운 enum

-
C++ 03 까지의 enum 은 여러 가지 문제를 가지고 있었다. 그래서 그 문제들을 해결하기 위해 C++ 11은 enum class 라는 것을 새로 만들었다. 이제부터 기존의 enum 에 어떤 문제가 있었고, 이것을 enum class 에서 어떻게 해결하였는지 살펴볼 것이다. 우선 기존의 enum 은 전방 선언할 수 없었다. 그 이유는 enumerator에 어떤 값이 들어있을지 알 수 없으면 그 크기를 정할 수 없기 때문 이다. 하지만 enum class 는 underlying type을 명시하지 않으면 int 타입과 같은 크기의 변수로 선언되고, int 값 안에 들어가지 못할 값을 지정하면 컴파일 에러를 발생시킨다. 만약 int 를 벗어난 범위의 값을 사용하고 싶다면, underlying type을 명시해주어야 한다. 기존 enum 의 또 다른 문제는 enumerator의 이름의 범위가 한정되지 않는다는 것이다. 예를 들어 아래와 같은 코드를 보자. IO 함수의 결과와 Parse 함수의 결과를 enum 으로 표현해 보았다. 하지만 이 코드는 컴파일되지 않는다. IOResult 의 Error , Ok 가 ParseResult 의 Error , Ok 와 겹치기 때문이다. 이를 해결하기 위해서는 다음과 같이 enumerator의 이름을 다르게 하거나 아래와 같이 namespace 를 이용해야 했다. 하지만 enum class 는 enumerator의 이름이 enum class 안으로 한정되기 때문에 이런 복잡한 과정이 필요 없이 그저 enum class 를 선언하여 사용하면 된다. 무엇보다 기존 enum 의 가장 큰 문제는 정수형 변수로 암시적으로 변환되는 약 타입(weak type) 변수라는 것이다. 하지만 enum class 는 정수형 변수로 암시적 변환이 되지 않는다. enum class 를 정수형 변수처럼 사용하려고 하면 컴파일 에러를 발생시킨다. 만약 정수형 변수로 사용하고 싶으면 static_cast 를 이용해
Read more »

Log Aggregator 비교 - Scribe, Flume, Fluentd, logstash

-
https://docs.google.com/presentation/d/12A5RlMCVDN6tA_zUnLrZ0TN5v08gz2GhlRdzxy3T3mU/edit?usp=sharing 회사에서 최근에 Log aggregator system으로 무엇을 사용해야 할지 조사해본 자료다. 우선 log aggregator가 무엇인지 한 문장으로 설명하면, 여러 머신에서 쌓인 로그들을 한 번에 분석할 수 있도록 수집하여 주는 시스템을 말한다. 요새는 특히나 클라우드 시스템이 유행하면서 같은 일을 하는 시스템임에도 다른 머신에서 돌아가는 일이 많아지면서 필요성이 크게 증가하였다. 이번 조사로 알게 된 것들을 적어보도록 하겠다. Scribe 우선 scribe 는 Facebook에서 제작하고 사용하던 log aggregator system이다. scribe: https://www.cnblogs.com/brucewoo/archive/2011/12/13/2285482.html 다른 로그 수집 시스템들을 보면 알겠지만, Scribe는 다른 시스템보다 간단한 구조로 되어 있다. Scribe는 일종의 message queue와 message queue에 쌓인 message를 DB에 저장해 주거나, DB가 실패하였으면 local에 저장하였다가 DB가 복구되었을 때 다시 DB에 저장해 주는 것만을 책임진다. 다시 말하면, message queue에 실제로 메시지를 보내는 부분은 사용자가 직접 작성하여야 한다는 것이다. 흔히들 말하는 scribe의 장점은 성능이다. C++로 만든 만큼 다른 시스템들의 3~5배 정도의 성능을 보여준다는 것이다. 하지만 실제 scribe 사용자들은 무엇보다도 Facebook이 실제로 사용하였던 솔루션인 만큼 성능과 안정성에서 신뢰도가 있다는 것을 장점으로 뽑는다. 하지만 나는 scribe를 사용하는 것을 추천하지는 않는다. 일단 가장 큰 문제는 더이상 Facebook이 Scribe를 사용하지 않는다는 것이다. Facebook은 이미 Ja
Read more »

[Python] cache 데코레이터로 최적화하기

-
최적화는 귀찮다. 눈에 띄는 실수를 한 게 아니면 어떻게 고쳐야 할지 감이 오지도 않고, 대부분의 최적화는 가독성을 떨어뜨리기 때문에 버그가 발생할 확률이 늘어난다. 하지만 어떤 최적화 테크닉은 코드를 크게 수정하지 않고 큰 성능 향상을 가져온다. 메모이제이션 이 그 대표적인 예제다. 계산이 무겁거나, 디스크의 값을 읽거나, 네트워크 통신처럼 근본적으로 시간이 오래 걸리는 일은 그 실행 결과를 저장했다 재사용하는 것만으로 큰 성능향상을 가지고 온다. 파이썬은 메모이제이션을 쉽게 적용할 수 있는 데코레이터 를 제공한다. functools 모듈의 lru_cache 데코레이터 가 이것이다. 이 데코레이터를 붙이면 함수의 실행 결과를 캐싱해준다. 캐시의 크기는 maxsize 로 지정할 수 있다. 저장할 실행 값이 이 개수를 넘어가는 경우 LRU 알고리즘 에 따라 가장 오래전에 사용한 결과를 지우고 새 값을 캐싱한다. lru_cache 를 사용하면 쉽게 최적화할 수 있지만 아무 함수에나 사용할 수 있는 건 아니다. 함수의 인자를 캐시키로 사용하기 때문에 함수의 실행 결과가 함수의 인자 이외에 다른 요소에 의존적인 함수에는 사용하지 못한다. 즉, 랜덤 요소가 들어가거나 시간에 따라 결괏값이 변하는 함수에는 사용하면 안 된다. 결정성이 보장되는 함수에만 사용할 수 있다는 것은 모든 캐시의 공통적인 특성이다. 여기에 더해 파이썬이 제공하는 lru_cache 는 그 구현상의 문제로 한 가지 제약이 더 있다. 이 데코레이터는 값을 저장하기 위해 인자를 키로 가지는 dictionary 를 사용한다. 따라서 모든 인자가 hashable 타입이어야 한다. 다시 말해 mutable 하지 않은 dictionary, set, list 등을 인자로 받는 함수는 이 데코레이터를 사용해 캐싱할 수 없다. 이런 타입을 인자로 받던 함수는 그 인자를 frozenset 이나 tuple 같은 immutable 타입으로 변환해야 한다. 게다가 keyword argument 를
Read more »

[Web] SpeechSynthesis - TTS API

-
SpeechSynthesis 는 Web Speech API의 하나로 주어진 텍스트를 소리로 바꿔주는 TTS API이다. SpeechSynthesis 이전에도 TTS 서비스가 있었지만, 이들은 유료이거나 웹에서 사용하기 불편한 경우가 대부분이었는데 SpeechSynthesis 의 경우 브라우저에 내장되는 API이므로 무료로 쉽게 사용할 수 있다는 장점이 있다. 물론 Web Speech API 자체가 아직 draft 에 해당하기 때문에 브라우저가 지원해야만 사용 가능하다는 문제는 있지만, 2016년 8월 15일 현재 데스크탑에서는 크롬과 사파리, 안드로이드 기본 브라우저인 크롬, 아이폰의 기본 브라우저인 사파리에 지원하고, 파이어폭스는 9월에 지원할 예정이므로 대부분의 모던 브라우저에서는 사용할 수 있다. speechSynthesis 는 5개의 함수를 가지고 있다. 그중 4개는 speak , cancel , pause , resume 이다. 이를 이용해서 재생할 음성을 추가하거나 취소하거나 일시 정지할 수 있다. 이 중 speak 함수는 SpeechSynthesisUtterance 를 인자로 받는다. speak 함수를 호출했을 때, 이미 재생 중인 utterance 가 없고 speechSynthesis 가 pause 되어 있지 않으면, 요청된 utterance 는 즉시 재생된다. 하지만 이미 재생 중인 utterance 가 있거나 speechSynthesis 가 pause 되어 있다면, utterance 는 바로 재생되지 않고 queue에 저장되었다가 후에 재생된다. 따라서 실제로 언제 재생되는지는 utterance 의 콜백을 통해서만 알 수 있다. 이벤트의 종류에 따라서 onstart , onend , onerror , onpause , onresume 등의 콜백을 등록할 수 있다. 또한, SpeechSynthesisUtterance 는 6개의 속성을 가지고 있다. 첫 번째 속성은 text 로 읽을 텍스트를 지정한다. 객체를 생성할
Read more »

RAII는 무엇인가

-
RAII 는 C++에서 자주 쓰이는 idiom으로 자원의 안전한 사용을 위해 객체가 쓰이는 스코프를 벗어나면 자원을 해제해주는 기법이다. C++에서 heap에 할당된 자원은 명시적으로 해제하지 않으면 해제되지 않지만, stack에 할당된 자원은 자신의 scope가 끝나면 메모리가 해제되며 destructor가 불린다는 원리를 이용한 것이다. 원래는 exception 등으로 control flow가 예상치 못하게 변경될 때를 대비하기 위해서 쓰이던 기법이다. 아래의 예제를 보자. 첫 번째 코드는 위험하다. thisFunctionCanThrowException() 함수에서 exception을 발생시킨다면 resource를 해제하지 못한다. 두 번째 코드는 일단은 resource 를 해제하고 있다. 하지만 보기에 좋은 코드는 아니다. 그리고 유지하기도 어려워진다. 세 번째 코드는 RAII를 위해 c++ 11의 스마트 포인터인 unique_ptr 을 이용하는 방법이다. unique_ptr 은 소멸할 때 자신이 들고 있는 메모리를 해제시켜주기 때문에 함수 밖으로 나가면 resource 가 해제되는 것이 보장된다. 여기서 말하는 자원은 단순히 heap 메모리만을 말하는 것이 아니다. heap 메모리 이외에도 파일이나 database connection과 같은 것들도 전부 RAII를 이용해 안전하게 사용할 수 있다. 여기에 더 나아가서 특정 scope를 벗어나면 반드시 실행돼야 하는 코드들도 RAII를 이용해 처리할 수 있다. 즉, 다른 언어에서 finally 에 해당하는 구문을 RAII를 이용해서 처리할 수 있다. 실제로 C++의 아버지이자 RAII라는 용어를 처음 만든 Bjarne Stroustrub는 c++에 finally 를 집어넣지 않는 이유를 "RAII가 있는데 굳이 있을 필요가 없다." 라고 말하고 있다.
Read more »