블로그 이미지
ssun++

카테고리

[전체] (73)
Android (7)
JavaScript (9)
CI (5)
Language (14)
ETC (38)
Total322,318
Today10
Yesterday16
[시작]
py파일에 대한 Python 문법 체크 과정입니다.


[Backgrounds]
PEP (Python Enhancement Proposals)
http://www.python.org/dev/peps/
정보의 전달을 목적으로 하거나 새로운 기능/프로세스/환경 등을 기술한 문서입니다.
문법에 대해서는 PEP 8번 문서에 기술되어 있습니다.

PEP 8 -- Style Guide for Python Code
http://www.python.org/dev/peps/pep-0008/

check-webkit-style 스크립트에서는 (README 파일에 따르면)
PEP 8 문서에 기반하여 문법 체크하는 모듈을 웹에서 다운로드하여 사용합니다.


[Sequence Diagram]



[끝]
pep8 모듈 까보기 전에 우선 pep8 가이드 부터 숙지해야 할 것 같습니다.
Posted by ssun++

댓글을 달아 주세요

[시작]
스크립트 실행시의 argument들을 object로 만드는 과정입니다.


[optparse.OptionParser]
add_option()
arguments 파싱에 대한 규칙(?)을 정할 수 있습니다.

parse_args()
option에 따라 파싱한 object와 arguments list를 반환합니다.


[Sequence Diagram]
 


[끝]
다음은 SVN, Git 관련 클래스는 건너뛰고 StyleProcessor 생성하는 쪽을 보겠습니다.
Posted by ssun++

댓글을 달아 주세요

[시작]
verbose(-v) 옵션에 따른 logger 관련 처리를 살펴봅니다.


[logging 모듈]
Level
Logger와 Handler는 아래와 같은 level을 가질 수 있습니다.

DEBUG < INFO < WARNING < ERROR < CRITIACL

Handler와 Logger중 높은 level을 따르며, 해당 level 이상의 메시지만 처리합니다.
default level은 NOTSET (모든 메시지 처리), root logger는 WARNING입니다.


[요약]
verbose
DEBUG = handler: NOTSET + logger: DEBUG
: 찍을 수 있는 건 다 찍는다고 볼 수 있습니다.
 

normal
error_handler - > WARNING = handler: WARNING + logger: INFO
non_error_handler -> WARNING 이하의 level에 대해서 Filter 처리
: WARNING 이상은 출력, 아래는 filter 옵션과 관련 있을 것 같습니다.


[Sequence Diagram]



[끝] 
다음은 StyleProcessor 생성하는 과정에 대해서 확인해 보겠습니다.
Posted by ssun++

댓글을 달아 주세요

[시작]
Tools/Scripts 디렉토리에 있는 check-webkit-style 스크립트의 seq diagram 입니다.
이 스크립트를 실행하여 WebKit의 코딩 스타일을 준수하고 있는지 확인할 수 있습니다.


[Sequence Diagram]
 


[끝]
logging 모듈, Checker들에 대한 분석이 필요할 것 같습니다.
Posted by ssun++

댓글을 달아 주세요

[Hudson] 새 작업 만들기

CI / 2011.10.29 21:31
[시작]
목표는 우분투에서 Hudson을 사용한 WebKit 빌드(QT) 환경을 만드는 것입니다.


[작업 만들기]
1. Hudson Dashboard에서 '새 작업'을 선택합니다.


2. 작업명을 입력하고 프로젝트 유형을 선택합니다.


3. 소스 코드 설정을 합니다.
Subversion, CVS, Git 설정이 가능합니다.
Subversion의 경우 Check-out Strategy를 정할 수 있습니다. (update/revert 후 update/지우고 다시 받기 등등)


4. 빌드 규칙을 설정합니다.
Build Periodically : 무조건 정해진 시간에 빌드
Poll SCM : 정해진 시간에 repository에 변경 사항이 있는 경우 빌드
스케줄은 "분 초 시 일 월"로 구성되며 아래 경우는 매일 12시에 빌드하게 됩니다.
 


5. 빌드 방법을 설정합니다.
Windows batch command / Shell Script 등을 입력할 수 있습니다.
 


6. 저 아래로 내려가서 Save합니다.


[끝]
빌드가 끝나면 어떤 결과가 나오는지 봅시다.
Posted by ssun++

댓글을 달아 주세요

[시작]
외부 리소스 만으로는 기능을 다 할 수 없기 때문에 WebCore와 연동이 필요합니다.

[Agent들]
WebCore에는 Inspector의 개별 기능을 담당하는 agent들이 있습니다.
agent는 InspectorXXXAgent라는 이름을 가지며 기능단위로 분리되어 있습니다.
(예. InspectorDOMAgent, InspectorConsoleAgent 등등)

[Message 던지기]
Inspector는 실제로는 WebKit 외부의 html 페이지입니다.
WebCore와의 연동을 위한 연결 고리가 필요하며, InspectorFrontendHost가 그 역할을 합니다.
(inspector.js의 WebInspector는 js에서 정의한 object이며 WebKit의 WebInspector와는 무관)

WebCore/inspector/InspectorFrontendHost.idl 파일을 통해
<빌드경로>/obj/DerivedSources/JSInspectorFrontendHost.cpp가 생성됩니다.
이는 외부에서 InspectorFrontendHost라는 object를 사용할 수 있다는 뜻이며,
실제 함수 호출은 InspectorFrontendHost.cpp의 함수들을 호출합니다.

WebCore로 던질 수 있는 message는 JSON 형태이며 InspectorBackendStub.js에 정의되어 있습니다.
InspectorFrontendHost.prototype.sendMessageToBackend() 메소드를 통해 WebCore로 전달됩니다.
여차저차 하여 InspectorBackendDispatcher에서 message를 파싱하고
message에 해당하는 agent를 찾아 필요한 함수를 호출하게 됩니다.

대략적인 구조는 아래와 같습니다 (파란색은 외부 js, 오렌지색은 WebCore).
 

[끝]
쓸 얘기는 다 쓴 것 같은데 급하게 정리한 느낌이 나네요 :p
아무튼 Inspector 얘기는 마무리. 
Posted by ssun++

댓글을 달아 주세요

[시작]
Inspector의 리소스 사용에 대해 알아봅니다. (windows 포팅 기준)


[Inspector]
크롬에는 "Developer Tools"라는 이름으로 들어가 있는 기능입니다.
(오른 클릭 -> 요소 검사 or 단축키 F12)

 
출력되는 내용은 html, js, css로 구성되어있으며 WebCore와 연동됩니다.


[리소스 복사]
원본 리소스는 아래의 파일들입니다.

  • WebCore/inspector/front-end/모든 파일
  • <빌드 경로>/obj/WebCore/DerivedSources/InspectorBackendStub.js
  • WebCore/English.lproj/localizedStrings.js
  • WebCore/English.lproj/Localizable.strings 


copyWebCoreResourceFiles.cmd 실행시 아래 경로로 복사됩니다.
(WebCoreGenerated 프로젝트)

  • <빌드경로>/bin/WebKit.resources/inspector 
  • <빌드경로>/bin/WebKit.resources/en.lproj 

 
 

[리소스 사용]
WebKit1
WebInspectorClient::openInspectorFrontend() 함수 수행 중 위 경로에 대한 URL을 만듭니다.

WebKit2
WebInspectorProxy::inspectorPageURL() 함수에서 위 경로에 대한 URL을 반환합니다.

inspector 페이지의 URL에 대한 view를 생성하면 inspector가 출력됩니다.

[끝]
다음은 Inspector와 WebCore 연동되는 부분을 보겠습니다.
Posted by ssun++

댓글을 달아 주세요

[시작]
웹킷 내부에서 지원(Latin1, UTF8, UTF16)하지 않는 인코딩에 대해서
ICU에서 컨버터를 가져와서 디코드하는 과정입니다.

[ICU를 사용한 디코드]
ICU를 사용하여 텍스트를 유니코드로 변환합니다.


[끝]
컨버팅 과정 끝입니다.
Posted by ssun++

댓글을 달아 주세요

[시작]
웹킷 내부 지원(Latin1, UTF8, UTF16)하지 않는 인코딩에 대해서
ICU 데이터를 가져와서 map에 저장하는 과정입니다.

[Map의 확장]
처음에는 웹킷 내부 지원 인코딩에 대한 정보만을 map에 저장합니다.
원하는 인코딩 정보를 찾지못하는 경우 ICU 데이터를 매핑하여 map을 확장합니다.
 

확장한 map에서 인코딩 정보를 찾으면 ICU에서 컨버터를 가져와서 사용하고,
확장 후에도 인코딩 정보를 찾지 못하면 디폴트 인코딩으로 디코드합니다.

[끝]
ICU 소스 내부로 들어가지 않는 선에서는 map 확장도 복잡할게 없네요.
다음은 TextCodecICU가 ICU에서 컨버터 데이터 가져오는 과정을 보겠습니다. 
Posted by ssun++

댓글을 달아 주세요

[시작]
주로 텍스트 디코딩 시에 사용되는 과정입니다.
오픈소스인 ICU를 사용합니다.


[기본]
ICU의 개념을 보면, 컨버팅하는 'converter'가 있고 컨버터는 복수의 'alias'를 가집니다.
아래 그림은 'windows-949-2000' 컨버터에 대한 예입니다.
 

'alias'로 인코딩된 텍스트를 디코딩하는 경우 해당하는 'converter'의 이름을 찾고,
icudt40l.dll이나 icudt40l.dat파일에서 컨버터 데이터를 읽어옵니다. (숫자는 버전에 따라)

기본적인 인코딩(Latin1, UTF8, UTF16)은 웹킷 자체에서 처리하기 때문에,
관리하는 방식은 유사하게 가져가지만 ICU 데이터를 사용하지는 않습니다.


[컨버전 데이터 관리]
웹킷에서는 위의 개념을 적용하기 위해서 2개의 맵을 가지고 있습니다.
하나는 alias와 converter name을 맵핑,
나머지는 converter name과 TextCodecFactory를 맵핑합니다.

alias에 해당하는 TextCodec을 위와같이 찾을 수 있고,
생성된 TextCodec이 TextCodecICU인 경우에는 converter 데이터를 ICU에서 가져옵니다.


[예외 처리]
처음에는 웹킷에서 처리할 수 있는 데이터만 map에 올려놓습니다.

최초 데이터에서 alias에 알맞은 name을 찾지 못하는 경우 ICU의 데이터를 등록하여 찾습니다.

최종적으로 못찾는 경우에는 디폴트 인코딩(Preference)으로 처리하며, 렌더링이 깨질 수 있습니다.


[끝]
대략적인 텍스트 컨버전 과정을 살펴보았습니다.
다음에는 ICU 데이터를 사용하는 과정에 대해서 좀 더 살펴볼 수 있을 것 같습니다. 

ps. 그림에서 textEncodingMap이 아니고 textEncodingNameMap이네요. 
Posted by ssun++

댓글을 달아 주세요

최근에 달린 댓글

최근에 받은 트랙백

글 보관함