tag:blogger.com,1999:blog-57549338775048063842024-03-09T19:11:06.848+09:00슭의 개발 블로그Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.comBlogger184125tag:blogger.com,1999:blog-5754933877504806384.post-76953050870484109192023-04-27T22:46:00.003+09:002023-04-29T10:07:05.024+09:00 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이 공유하는 동작이다. Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-28408446170673817622023-04-16T23:59:00.012+09:002023-04-29T10:07:38.685+09:00[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
Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-72319972597511448102023-03-25T00:06:00.001+09:002023-04-29T10:48:51.594+09:00[CSI Sequence] 커서 옮기기
CodeAbbrName
CSI # ACUUCUrsor Up
CSI # BCUDCUrsor Down
CSI # CCUFCUrsor Forward
CSI # DCUBCUrsor Backward
CSI # ECNLCUrsor Next Line
CSI # FCPLCUrsor Previous Line
CSI # ICHTCursor Horizontal forward Tabulation
CSI # ZCBTCursor Backward Tabulation
CSI # GCHACursor Horizontal Absolute
CSI # ; # HCUPCUrsor Position
오늘은 지난 글에 이어 이번 글에서는 CSI Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-78215742784671400132023-03-24T19:19:00.008+09:002023-05-05T00:32:42.227+09:00CSI 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를 시작으로 @,Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-57445521819051650582023-03-22T00:30:00.005+09:002023-05-05T00:32:37.388+09:00텍스트 애플리케이션에서 Carriage Return 사용하기Unix를 비롯한 대부분의 시스템은 LF(\n, 0x0A)를 개행 문자로 사용하기 때문에 CR(\r, 0x0D)을 사용하는 경우가 거의 없다. 텍스트 애플리케이션에서 진행표시줄을 만드는 것이 진행표시줄을 만드는 것이 현대 컴퓨터에서 CR을 사용하는 거의 유일한 경우라고 볼 수 있다. CR을 사용하면 터미널에서 진행표시줄을 간단하게 구현할 수 있다.
위의 코드는 #과 ' '(공백 문자)로 진행표시줄을 그린다. 편의를 위해 진행표시줄의 길이는 20개로 고정했고, 전달받은 진행도에 따라 5%마다 #을 하나씩 더 그리는 방식으로 구현했다. 이런 식으로 CR을 이용해 진행표시줄을 그리는 경우 주의할 점은 세가지 있다.
첫번째 주의할 점은 진행표시줄을 stdout이 아닌 stderr에 그려야 한다는 것이다Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-59328083133680992842023-03-20T20:38:00.003+09:002023-04-29T10:51:36.335+09:00터미널 출력 제어를 위한 termios 구조체 이해하기지난 글에서 설명했듯이 OS X, 리눅스를 포함한 Unix를 이어받은 운영 체제는 LF(line feed, 0x0A, \n)를 개행 문자, 즉 커서를 다음 줄의 시작으로 옮기는 문자로 이용한다. 하지만 표준에 정의 된 LF의 동작은 커서를 다음 줄로 내리는 것일 뿐, 커서를 줄의 처음으로 이동하지 않는다. 파일을 항상 운영 체제에 종속적인 애플리케이션을 통해서만 접근한다면 표준과 다른 동작은 문제되지 않는다. 하지만 파일과 입출력의 구분이 없는 유닉스 계열에서 파일과 프로세스의 입출력이 상호작용할 때 이 차이는 문제될 수 있다.
이 차이를 다루기 위해서 터미널은 출력에 적절한 가공을 하여 출력한다. 이를 제어하기 위한 플래그가 POSIX.1 표준이 정의 하는 termios 구조체의 c_oflag다. Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-20173078583072756872023-03-19T10:54:00.007+09:002023-04-29T10:52:10.403+09:00LF, CR 그리고 CRLF개행 문자는 멀티 플랫폼에서 작업하는 사람들을 귀찮게 하는 것 중 하나다. Mac OS, Windows, Linux는 모두 다른 문자를 개행 문자로 사용한다. 심지어 Mac OS는 과거 버전과 최신 버전에서의 동작이 또 다르다. 이번 글에서는 시스템별로 다른 개행 문자를 사용하는 원인을 살펴볼 것이다.
ISO 6429 표준에 따르면 LF(line feed, \n)는 커서를 현재 행을 유지하면서 다음 줄로 옮기고, CR(carriage return, \r)는 커서를 현재 라인의 처음으로 옮긴다. 우리가 원하는 개행 문자의 동작을 위해서는 CR과 LF를 함께 써야 한다. 이런 구분은 라인을 바꾸는 동작과, 커서를 처음으로 옮기는 동작이 구분된 초기 프린터나 타자기의 동작을 모방했기 때문이다.
A
B
즉Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-64326610251828358672023-03-16T12:40:00.002+09:002023-04-29T10:52:52.849+09:00escape codes의 이해escape code의 ISO 6429에서 정의된 정확한 명칭은 control function이다. control function을 표현하는 코드 혹은 시퀀스를 흔히 escape code라고 말한다. ISO 6429가 정의하는 컨트롤 코드는 모양에 따라 C0 코드와 C1 코드로 나누어진다.
C0 코드는 ASCII Table에서 non-printing 문자에 해당하는 코드이다. 아마 Escape Codes 중 개발자들에게 가장 익숙한 코드일 것이다. 라인 피드(\n), 캐리지 리턴(\r), 탭(\t), 널 문자(\0) 등이 여기에 해당한다.
C1 코드는 0x80에서 0x9F 사이 32개의 1바이트 값으로 표현되는 코드다. C0와 다르게 C1 코드는 ASCII에 정의된 값이 아니다. ASCII만 지원하는 Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-80448919091824849272023-03-08T00:42:00.004+09:002023-04-29T10:53:12.196+09:00Escape Codes의 역사개발을 위해 컴퓨터에 리눅스를 설치할 때 반드시 설치하는 프로그램이 있다. sl이라는 프로그램이다. 이게 무슨 프로그램이냐면 커맨드 창에서 sl을 치면 기차를 보여주는 프로그램이다. 실용성 있는 프로그램은 아니고, 터미널에서 많이 사용되는 ls 명령어의 오타를 냈을 때 화면에 기차를 보여줘 생각할 시간을 주는 프로그램이다. 이를 통해 오타를 낼 정도로 마음이 급한 상황에서 다른 실수를 하지 않고 조금은 침착해지라는 의미에서 항상 설치한다.
출처: https://github.com/mtoyoda/sl
터미널은 실행한 프로그램이 내보내는 두 출력 stdout과 stderr를 받아 화면에 보여주는 프로그램이다. stdout과 stderr은 순차적인 출력이다. 보통의 출력은 왼쪽 위에서 오른쪽 아래로 흘러간다Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com1tag:blogger.com,1999:blog-5754933877504806384.post-58347272604693303352021-08-02T02:19:00.007+09:002023-05-30T23:17:12.749+09:00[Rust] 반복자에게 할 일 더해주기 - Iterator adapters다른 Iterator(a.k.a 반복자)를 받아 새로운 반복자를 반환하는 함수를 iterator adapter라고 부른다. adapter라는 이름은 GoF의 디자인 패턴 중 하나인 adapter pattern에서 온 말이라고 한다. 그런데 실제로는 adapter pattern보다는 decorator pattern에 해당하기 때문에 이름을 신경쓰면 용도를 헷갈릴 수 있다. 그러니 이름에 대해서는 크게 신경 쓰지 않는 것이 좋다. 이름에 대한 불평은 그만하고 iterator adapter가 무엇을 하는가?
iterator adapter는 반복자가 순회하면서 할 일을 더해준다. 무슨 말인지는 실제 구현체를 보면 쉽게 이해할 수 있을 것이다. map 함수는 대표적인 adapter다. 함수형 언어를 써본 Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-73394738878178425092021-06-11T16:04:00.005+09:002023-05-05T00:05:32.820+09:00[Python] cache 데코레이터로 최적화하기최적화는 귀찮다. 눈에 띄는 실수를 한 게 아니면 어떻게 고쳐야 할지 감이 오지도 않고, 대부분의 최적화는 가독성을 떨어뜨리기 때문에 버그가 발생할 확률이 늘어난다. 하지만 어떤 최적화 테크닉은 코드를 크게 수정하지 않고 큰 성능 향상을 가져온다. 메모이제이션이 그 대표적인 예제다. 계산이 무겁거나, 디스크의 값을 읽거나, 네트워크 통신처럼 근본적으로 시간이 오래 걸리는 일은 그 실행 결과를 저장했다 재사용하는 것만으로 큰 성능향상을 가지고 온다.
파이썬은 메모이제이션을 쉽게 적용할 수 있는 데코레이터를 제공한다. functools 모듈의 lru_cache 데코레이터가 이것이다. 이 데코레이터를 붙이면 함수의 실행 결과를 캐싱해준다. 캐시의 크기는 maxsize로 지정할 수 있다. 저장할 실행 값이 이Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com1tag:blogger.com,1999:blog-5754933877504806384.post-79576263916867267012020-06-12T02:33:00.005+09:002023-05-04T23:56:29.476+09:00Rust의 반복문Java나 C++ 같은 언어에서는 조건 반복문과 for-each 반복문에 같은 for 키워드를 사용한다. 하지만, Rust는 조건 반복문에는 while 키워드을 for-each 반복문에는 for 키워드를 사용한다.
Rust는 여기에 하나의 반복문을 더 제공한다. loop 반복문이다. 이는 while true라고 쓰는 것과 같이 같은 코드를 무한히 실행한다. 실제로 무한 반복이 필요한 경우에도 사용되고, 반복문의 조건을 하나의 표현식으로 서술하기 힘들어 break문으로 뺄 때에도 사용된다.
하지만 loop가 while true와 완전히 같은 코드는 아니다. loop는 while문과 다르게 그 자체로 값을 가진다. break문 뒤에 값을 적으면 이 값이 반복문 전체의 값이 된다. 그렇다면 다른 반복문은 Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com2tag:blogger.com,1999:blog-5754933877504806384.post-29496704276429645412020-06-04T02:24:00.010+09:002023-05-05T00:00:54.451+09:00조건 반복문과 for-each 반복문프로그램에서 반복문은 크게 두 가지로 나눌 수 있다. 하나는 특정 조건을 만족할 때까지 같은 코드를 반복하는 것이다. 포트란으로부터 시작해서 C를 거쳐 대부분의 프로그래밍 언어들은 기본적으로 이런 형태의 반복문을 제공한다. 예를 들면 C의 while 문이나 for 문이 그렇다. 이것들은 주어진 조건이 성립하는 동안 정해진 코드를 실행한다.
혹은 특정 범위의 모든 값에 대해 같은 코드를 실행하기도 한다. 이런 반복문은 C++에서는 range-based for loop, C#과 Java는 foreach 문, JavaScript는 for ... of 문으로 부르는 등 다양한 이름으로 불린다. 이런 종류의 반복문을 부르는 이름은 언어마다 다르지만, 편의를 위해 이 글에서는 이것을 for-each 문으로, Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-65324259018854454832019-12-28T03:04:00.003+09:002023-05-04T23:51:33.795+09:00[Rust] 함수의 lifetime parameter는 언제 써야 하고 언제 생략할 수 있나요?누군가가 나에게 러스트가 다른 언어와 다른 가장 큰 차이가 뭐냐고 묻는다면, 라이프타임이라고 대답할 것이다. 그래서 러스트를 처음 배우는 사람들이 러스트의 적응하는데 가장 어려운 부분도 이것이라고 생각한다. 특히 함수의 경우 라이프타임을 표기하는 파라미터는 생략이 가능해서 이 생략 규칙에 익숙하지 않은 사람은 함수가 의미하는 것을 이해하지 못하기도 한다.
일단 함수를 정의할 때는 크게 신경 쓰지 않아도 된다. 러스트는 분석 도구가 매우 잘 만들어져 있다. 지금까지 나온 어떤 언어보다 잘 돼 있다고 말하고 싶을 정도다. 어떤 라이프타임을 생략할 수 있는지 확실치 않은 경우는 모든 레퍼런스에 파라미터를 적어주고 clippy를 사용하면 어떤 파라미터가 필요 없는지 친절하게 알려준다. 이에 따라 코드를 다듬으면Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-66632761737429000062019-10-21T03:21:00.004+09:002023-05-05T00:35:08.431+09:00일정 예상은 왜 실패할까?모든 일에서 데드라인을 지키는 것은 중요하다. 마감을 지키는 것은 일의 기본이다. 특히 팀으로 작업하는 일에서는 더더욱 그렇다. 소프트웨어 개발의 많은 일은 파이프라인 형식으로 진행되기 때문에, 내가 약속한 일정을 못 맞추면, 내 일만 뒤로 밀리는 것이 아니라 협업 중인 다른 사람의 일정에까지 영향을 주는 경우가 많다.
하지만 일정을 맞추는 것은 어렵다. 그게 뭐가 어렵냐고 생각할 수 있는데 정말 어렵다. 언제나 이번만큼은 예외라고 생각하지만, 언제나 일정은 틀어진다. 심지어 예상보다 오래 걸릴 것이라는 경험을 바탕으로 계산보다 일정을 길게 잡아도 여전히 마감을 못 지킨다. 이런 현상을 호프스태터의 법칙이라고 부른다. 그렇다면 호프스테터의 법칙은 왜 생길까?
일정 예측이 틀리는 이유를 알아보기 전에 Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com1tag:blogger.com,1999:blog-5754933877504806384.post-85887175853273511012019-07-14T23:58:00.005+09:002023-05-05T00:33:06.544+09:00[TypeScript] Promise.all에는 인자 개수 제한이 없다트위터에서 이상한 글을 봤다. TypeScript가 선언한 Promise.all이 iterable을 받지 않고 인자 개수 제한이 있다는 것이다. 근데 그럴 리가. TypeScript쯤 되는 프로젝트에서 무언가가 스펙과 다른 것으로 보인다면, 코드를 잘못 이해했을 확률이 높다. 코드를 다시 확인해보자.
당연히 iterable을 인자로 받는 Promise.all 선언도 있다. 다만, 이 선언이 es2015.promise.d.ts가 아닌 es2015.iterable.d.ts에 있을 뿐이다. 타입스크립트 컴파일러 옵션 중 --lib 으로 사용할 라이브러리를 지정할 수 있다. 대부분 es2015, es2018 같은 식으로 버전을 지정하여 포함하는 것이 일반적이라 잘 알려지지 않았지만, es2015.symbol로 Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com1tag:blogger.com,1999:blog-5754933877504806384.post-35641425523817387852019-05-12T22:02:00.004+09:002023-04-29T12:36:57.582+09:00[Rust] 타입 변환하기Rust에서 타입 변환은 특별한 것이 아니다. 그저 단순히 하나의 값을 소유권을 받아 다른 타입의 값을 반환하는 함수다. 따라서 자신이 원하는 이름으로 아무 함수나 만들면 된다. 하지만 가독성을 위해 as_, to_, into_를 prefix로 사용하는 method를 만들거나, from_가 prefix로 붙는 생성자를 만들어 converting constructor처럼 만들어 사용한다.
From
타입 변환을 보다 일반적으로 구현하고 싶으면 From 트레잇을 구현하면 된다. 예를 들어 A라는 타입을 B라는 타입으로 변환하고 싶을 때는, B 타입에 From<A>를 구현하는 것이다. From 트레잇은 from이라는 associated function을 제공하기 때문에 A타입의 변수 a를 B타입으로 Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com3tag:blogger.com,1999:blog-5754933877504806384.post-89515182113421548572019-04-14T18:10:00.004+09:002023-04-29T12:37:51.380+09:00Garbage collection과 memory leakGarbage collection(a.k.a. GC)은 프로그램이 더 이상 접근할 수 없는 메모리를 자동으로 해제시켜 주는 기술을 의미한다. John McCarthy가 Lisp에 처음 구현한 이후 많은 언어가 사용하여 현대 프로그래머 중에 모르는 사람이 없다고 해도 좋을 정도로 널리 알려진 개념이다. 근데 이 GC에 대해서 사람들이 자주 착각하는 것이 있다. GC를 사용하는 이유가 memory leak을 잡아주기 위해서라고 생각하는 것이다. 만약 이렇게 생각했다면 GC에 대해 큰 착각을 하는 것이다.
GC는 memory leak을 막지 못한다. 사실 튜링 완전한 언어에서 memory leak을 막아주는 방법은 세상에 존재할 수 없다. 이것을 설명하기 위해서는 우선 memory leak이 무엇인지 알아야 Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-38390550992116036322019-04-06T23:58:00.003+09:002023-04-30T20:17:43.628+09:00managed language와 unmanaged language?얼마 전 우연히 이런 글을 보게 됐다. 프로그래밍 언어를 managed language와 unmanaged language로 구분한 것인데 그 기준을 garbage collection(a.k.a. GC)을 하는가 아닌가로 잡았다. 난생처음 들어보는 기준이었다. 인생이 힘들어서 노느라 바쁜 사이 뭔가 새로운 논문이 나왔나 하고 찾아봤다.
역시나 이런 경우 대부분 그렇듯이 다른 나라에서는 안 쓰이고 다른 나라에서는 안 쓰이고 우리나라에서 작성된 블로그만 보였다. 그 블로그들이 공통으로 언급하는 것으로 보아 어떤 사람이 유튜브에서 처음 사용한 것 같다. 사실 다른 나라에서는 안 쓰이는 기준이라는 건 별로 중요하지 않다. 그보다 중요한 건 이 managed language라는 것이 잘못 붙여진 이름이라는 것이다Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com5tag:blogger.com,1999:blog-5754933877504806384.post-81172546113138118902018-12-27T02:33:00.003+09:002023-05-05T00:32:14.596+09:00read-writers lock - 공유 자원 접근하기Multithreaded programming에서 공유 자원에 접근할 때는 동시에 두 개 이상의 스레드가 자원을 변경시키지 않기 위해서 mutex를 사용한다. Mutex를 사용하면 공유자원에 접근하는 스레드를 한 개로 제한하기 때문에 안전하지만, 어떤 경우는 비효율적이다. 예를 들어 여러 스레드가 공유 자원에 동시에 접근해야 하지만 그중 일부 스레드만 값을 변경하는 경우는 어떨까?
이런 경우 값을 읽기만 하는 스레드는 동시에 접근해도 상관없다. 하지만 어떤 스레드가 값을 변경하고 있으면, 다른 스레드는 공유 자원에 접근해서는 안 된다. 반대로 다른 스레드가 공유 자원에 접근하고 있는 중에는 값을 변경하는 스레드는 접근해서는 안 된다.
이때 사용하는 것이 shared-exclusive lock이라고도 Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com1tag:blogger.com,1999:blog-5754933877504806384.post-91921329845809177142018-11-20T19:10:00.001+09:002023-04-29T12:40:48.455+09:00Rust 읽을거리아무 글도 안 쓴지 벌써 삼 개월이 지났다. 아무래도 너무 오래 논거 같아서 뭐라도 써야 할 것 같다. 사실 쓰고 싶은 주제는 많다. 하지만 대부분 주제가 쓰는 데 시간이 걸릴 주제라서 귀찮고, 이번에는 간단하게 Rust를 배우는데 읽기 좋은 자료들을 정리해보도록 하겠다.
Rust는 배우기 어려운 언어로 소문나 있지만, 그런 만큼 Rust 개발 커뮤니티에서 공식적으로 제공하는 문서가 많이 있다. 그중에서 입문자가 읽기 가장 좋은 문서는 RBE라고 불리는 Rust by Example다. RBE는 자세한 설명보다는 실제 코드를 어떻게 짜야 하는지를 보여준다.
RBE를 읽었으면 Rust를 배우기 위해서 Rust Book이라고 불리는 Rust Programming Language를 반드시 읽어야 한다. Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-48171829839550684572018-08-15T20:47:00.004+09:002023-05-05T00:35:47.752+09:00Chromium OS 설치 후기3줄 요약
Chromium OS에서 PlayStore 실행시키는 거 보고 반함
집에서 놀던 노트북에 설치함
포맷
거의 2주 정도 삽질을 했다. 시작은 우연히 보게 된 위의 영상 때문이었다.
Chrome OS의 고질적인 문제인 쓸만한 앱이 없다는 문제를 해결하기 위해 ChromeOS에서 안드로이드 앱을 실행할 수 있게 했다는 것이다.
안 그래도 개발용 데스크톱을 새로 장만하면서, 전에 사용하던 리눅스 노트북의 용도가 단순 인터넷 서핑 정도가 됐기 때문에 망설임 없이 노트북을 포맷하고 Chrome OS의 오픈소스 버전인 Chromium OS를 설치했다.
Chromium OS를 설치하면서 기대했던 것은 대략 다음과 같다.
Play Store를 이용해서 노트북으로 안드로이드 게임 플레이하기
어차피 Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com15tag:blogger.com,1999:blog-5754933877504806384.post-89015773504292691742018-08-09T19:28:00.002+09:002023-05-04T23:47:00.004+09:00[Rust] _는 bind하지 않는다Rust는 RAII idiom을 사용하는 언어로, 객체가 소멸하는 시점에 따라 코드의 의미가 달라진다. 예를 들어 아래 코드를 보자.
이 코드는 Service의 객체를 생성하고 종료하기를 기다리는 코드다.
이 코드는 문법적으로는 아무 문제가 없다.
하지만 종료할 때까지 Service가 어떤 동작을 수행하기를 원했다면 이는 틀린 코드다.
Service 객체는 아무 변수에도 bind 되지 않았기 때문에 이 객체는 두 번째 줄에 있는 문장이 끝나면 소멸한다.
Service 객체가 wait_for_exit이 수행될 때까지 살아있기를 원한다면, 아래와 같이 변경해야 한다.
위의 코드에서 Service의 객체는 변수 service에 bind 된다.
따라서 두 번째 라인이 끝나도 소멸하지 않고 Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com3tag:blogger.com,1999:blog-5754933877504806384.post-14877250924324668732018-06-15T16:55:00.002+09:002023-04-29T12:43:26.558+09:00Skewed Merkle Tree지난번 글에서 설명했듯이 이더리움은 Modified Merkle Patricia Trie를 4가지 용도로 사용한다. 이 중 State Trie와 Storage Trie는 변경되는 데이터를 효율적으로 저장하고 검증하기 위해서 사용된다. 하지만 Transaction Trie와 Receipts Trie는 변경되는 데이터가 대상이 아니다. 이 두 trie는 하나의 블록에서 사용된 트랜잭션과 그에 의해 생성된 receipt의 검증을 위해서만 사용되는 휘발성 데이터다.
이더리움이 두 가지 목적을 위해 같은 데이터 구조를 사용하는 이유는 같은 구현을 공유하기 위해서였다. 하지만 목적이 다르기 때문에 Transaction Trie나 Receipts Trie를 생성하는데 최적화된 코드는 State Trie나 Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0tag:blogger.com,1999:blog-5754933877504806384.post-90637100308595707392018-06-03T02:48:00.003+09:002023-05-05T00:36:08.954+09:002018년 22번재 주 - P2P Network이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.
지난주에 이어 이번 주는 P2P를 주제로 발표했다. 이번에도 발표자료를 만들면서 참고한 자료를 공유하도록 하겠다.
Chord: a scalable peer-to-peer lookup protocol for internet applications
Tapestry: A Resilient Global-scale Overlay for Service Seulgi Kimhttp://www.blogger.com/profile/13356157795179922345noreply@blogger.com0