spellcheck-ko / hunspell-dict-ko Goto Github PK
View Code? Open in Web Editor NEWKorean spellchecking dictionary for Hunspell
Home Page: https://spellcheck-ko.github.io/
License: Other
Korean spellchecking dictionary for Hunspell
Home Page: https://spellcheck-ko.github.io/
License: Other
(http://code.google.com/p/spellcheck-ko/issues/detail?id=7)
인접한 키를 눌렀을 때 발생하는 오타를 찾는 용도, hunspell(4) 맨페이지 참고:
KEY characters_separated_by_vertical_line_optionally Hunspell searches and suggests words with one different charac- ter replaced by a neighbor KEY character. Not neighbor charac- ters in KEY string separated by vertical line characters. Sug- gested KEY parameters for QWERTY and Dvorak keyboard layouts: KEY qwertyuiop|asdfghjkl|zxcvbnm KEY pyfgcrl|aeouidhtns|qjkxbmwvz Using the first QWERTY layout, Hunspell suggests "nude" and "node" for "*nide". A character may have more neighbors, too: KEY qwertzuop|yxcvbnm|qaw|say|wse|dsx|sy|edr|fdc|dx|rft|gfv|fc|tgz|hgb|gv|zhu|jhn|hb|uji|kjm|jn|iko|lkm
한글 타이핑에서 이러한 오타는 비교적 적으므로 우선순위 낮음.
안녕하세요, 먼저 사전 업데이트에 늘 감사드립니다.
이전까지 저는 비교적 예전 버전의 사전을 사용하고 있었습니다. 구체적으로는 chromium 소스 트리에 포함되어 있는 bdic (https://chromium.googlesource.com/chromium/deps/hunspell_dictionaries/+/master/ko-3-0.bdic) 과 같은 버전의 사전을 사용하고 있던 중에, 근래 업데이트된 최근 버전 0.6.4를 시험하고 있는 중입니다.
최신 버전의 사전에서 몇몇 단어의 제시어를 가져올 때 이전 버전보다 확연할 정도로 속도 차이가 발생하는 것을 발견할 수 있었는데, 이를테면 한녕하세요
와 같은 단어의 제시어를 가져올 때 0.6.1버전의 경우 약 300-350ms가 걸리는 반면 최근 버전의 경우 평균 950ms정도가 걸리고 있습니다. (실제 수행 시간의 경우 시스템 환경에 따라 상이) 단순한 추측으로는 0.6.1버전 이후 dic / aff 모두 크기가 거의 두 배 가까이 커진 것과 관계가 있지 않을까 싶습니다만 정확한 원인은 찾을 수 없었습니다.
현재 저는 데스크탑 기반의 어플리케이션의 컨텍스트 메뉴에 제시어를 표시하고 있어 (아래와 같은 경우를 생각하시면 됩니다) 실행 시간의 증가는 다소 부담이 되는 상황입니다.
이 문제를 해결할 수 있는 방법이 있을지요?
감사합니다.
F7을 눌러서 맞춤법 검사기 창을 열면 극심한 프리징으로 정상적인 사용이 불가능합니다
부사: 되도록이면
현재 새로 추가한 단어 정보 파일이 많아서 크기도 커지고 처리 속도가 너무 느린 경우가 있다. 적절하게 합치는 것 고려해 볼 수 있다. yaml은 '---' 라인으로 여러 문서를 하나로 합쳐도 가능. 단 파일을 합칠 경우에
맞춤법 검사에 적합한 인코딩은 두벌식 키보드 스트로크이다. 두벌식 키보드를 사용해서 발생하는 오타 뿐만 아니라 자음이 종성에 붙는지 초성에 붙는지 헷갈리는 오타 패턴이 많이 발견된다. 연음법칙 때문이기도 하다.
문제는 이러한 인코딩은 hunspell의 ICONV/OCONV 테이블에서는 구현이 불가하다는 점이다. 이 기능에서는 테이블에서 일치하는 문자열을 replace하는 기능이 있을 뿐, 가장 긴 걸 매칭한다든가, 뒤의 시퀀스를 고려한다든가 하는 부분이 없다. 예를 들어 다음과 같은 테이블이 있으면 내부적으로 "ㄱㅏㄱㅏ"라는 시퀀스가 있으면 "각ㅏ"로 변환된다. (테이블 순서를 바꾼다면 반대로 "각"이 되야 할 경우에도 "가"로 변환될 것이다.)
OCONV ㄱㅏㄱ 각
OCONV ㄱㅏ 가
이상적인 해결 절차와 방식은 다음과 같다. 아직 애매함
hunspell 커맨드라인을 비롯한 몇몇 부분에서 OCONV 적용이 제대로 안 되는 버그도 문제.
한국어기초사전 정보를 보면 형용사 뒤에 오는 보조 용언과 동사 뒤에 오는 보조 용언이 구분되어 있다. ("일부" 형용사/동사 뒤에 오는 경우도) 이 정보를 활용해 보조 용언 붙은 형태를 줄여서 효율 높이는 방법 고안.
데비안 빌드 중에서
make -j4 "INSTALL=install --strip-program=true"
make[1]: Entering directory '/<<PKGBUILDDIR>>'
python3 make-aff-dic.py ko.aff ko.dic dict-ko-builtins.yaml dict-ko-data.yaml
python3 make-aff-dic.py ko.aff ko.dic dict-ko-builtins.yaml dict-ko-data.yaml
Progress: 중복 제거...
Status: 중복 제거 후 단어 수: 51149...
Progress: 보조용언 확장...
Progress: 플래그 계산...
Progress: dic 출력...
Progress: aff 출력...
Progress: 중복 제거...
Status: 중복 제거 후 단어 수: 51149...
Progress: 보조용언 확장...
Progress: 플래그 계산...
Progress: dic 출력...
Progress: aff 출력...
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
hunspell을 설치하고 사전을 ko.aff, ko.dic으로 업데이트한 상황입니다.
테스트로 틀린 문장부호 위치를 잡을 수 있나 확인해봤는데 잡을 수 없는 것 같습니다.
예를 들어 ""안녕하세요?" 같은 문장의 경우 앞에 따옴표가 연속적으로 붙어서 틀린문장인데
검출이 안되어 질문드립니다.
안녕하세요.
ubuntu 16.04 기반 elementary os loki에 spacemacs를 사용 중인 유저입니다.
우분투 리파지터리에서 hunspell 1.3.3 버전과 hunspell-dict-ko 0.5.6를 설치하여 사용하다가
오늘 이곳 깃헙 release의 ko-aff-dic-0.6.4.zip
을 내려받아
ko.aff와 ko.dic만 기존의 /usr/share/hunspell 내부의 데이터와 교체하여 사용해보았습니다.
이후 hunspell -D를 시도하니
error: line 22471: bad entry number 메시지가 중간에 뜹니다.
동작은 하는 것으로 보이는데 에러 메시지를 보게 되어 알려드립니다.
(http://code.google.com/p/spellcheck-ko/issues/detail?id=36)
문제점이 발생하는 상황을 설명해 주십시오.
어떤 동작이 문제입니까? 이 경우에 어떻게 동작하는 게
올바릅니까?
=> "누구에게나", "이렇게나", "너에게까지", "이렇게까지" 등은 모두 허용되어야 합니다.
사용하고 계시는 버전과 애플리케이션 소프트웨어의
버전 등 환경을 써 주십시오.
=> aff/dic data 0.5.5를 애플 OSX 10.8.2의 내장 맞춤법 검사기로 사용 중입니다.
기타 관련 정보가 있다면 써 주십시오.
어떤 부사어인지 좀 더 명확히 알아야 합니다. 모든 부사어는 아닌데요.
안녕하세요. 맞춤법 검사기에 관심을가지고 소스를 받아서 빌드를 했는데 아래와 같은 에러가 납니다.
python3 make-aff-dic.py ko.aff ko.dic dict-ko-builtins.xml dict-ko-galkwi.xml
Traceback (most recent call last):
File "make-aff-dic.py", line 277, in
dic.load_xml(open(filename))
File "make-aff-dic.py", line 109, in load_xml
from lxml import etree
ImportError: No module named 'lxml'
make: *** [ko.aff] Error 1
맥에서 Python3를 설치하고 실행했습니다.
(http://code.google.com/p/spellcheck-ko/issues/detail?id=21)
조사 '-뿐', 다른 조사와 성격이 좀 다름.
'~뿐이다' 처럼 명사 접미어처럼 쓰인다.
보조사로 '~하게뿐 아니라' 식으로도 쓰인다.
(http://code.google.com/p/spellcheck-ko/issues/detail?id=35)
판넬 -> 패널
지금 대치어 규칙은 불규칙 용언 등 문법 규칙에 대해 맞는 말을 찾는 규칙이라서 단어 하나하나의 경우는 열거하는 게 적합치 않습니다.
다른 방법을 찾아봐야 할 것 같습니다.
(http://code.google.com/p/spellcheck-ko/issues/detail?id=2)
공손 선어말어미 '-옵-' 활용 추가.
'-옵-'같은 경우 이 뒤에 자음으로 시작하는 광범위한 어미가 올 수 있어 현재
코드에 추가하기 간단하지 않다. 또 높임 선어말어미 뒤에도 붙는데 (-시옵), 높
임 선어말어미 앞에도 붙을 수 있기 때문에 (-옵시) 까다롭다.
(http://code.google.com/p/spellcheck-ko/issues/detail?id=20)
-지+않다 활용 추가
"않다" 뒤에 다시 활용이 들어가기 때문에 구현 어려움. 지금은 '잖아'만 따로 들어가 있어서 '잖다', '잖게' 따위의 활용은 불완전하다.
1만 단위 자릿수별 붙여쓰기를 위해 수사를 내부적으로 관리했는데 그러니까 갈퀴에 명사로 잘못 입력되거나 관형사로만 입력된 경우가 있다.
FOUND: 경 (001) (한국어기초사전 30460) -> 경 (갈퀴 Django 1581)
FOUND: 구 (005) (한국어기초사전 34882) -> 구 (갈퀴 Django 2962)
FOUND: 넷째 (002) (한국어기초사전 26821) -> 넷째 (갈퀴 Django 5355)
FOUND: 다섯째 (002) (한국어기초사전 26826) -> 다섯째 (갈퀴 Django 5914)
FOUND: 대여섯 (001) (한국어기초사전 87906) -> 대여섯 (갈퀴 Django 6489)
FOUND: 둘째 (002) (한국어기초사전 58108) -> 둘째 (갈퀴 Django 7452), 둘째 (갈퀴 Django 7453)
FOUND: 만 (006) (한국어기초사전 64558) -> 만 (갈퀴 Django 8416), 만 (갈퀴 Django 8417)
FOUND: 몇 (001) (한국어기초사전 66235) -> 몇 (갈퀴 Django 9142)
FOUND: 몇몇 (001) (한국어기초사전 62624) -> 몇몇 (갈퀴 Django 9143)
FOUND: 백 (002) (한국어기초사전 36019) -> 백 (갈퀴 Django 11119)
FOUND: 셋째 (002) (한국어기초사전 71132) -> 셋째 (갈퀴 Django 14954)
FOUND: 수만 (001) (한국어기초사전 64977) -> 수만 (갈퀴 Django 15518)
FOUND: 수백 (001) (한국어기초사전 65400) -> 수백 (갈퀴 Django 15536)
FOUND: 수십 (001) (한국어기초사전 65410) -> 수십 (갈퀴 Django 15619)
FOUND: 수억 (001) (한국어기초사전 64594) -> 수억 (갈퀴 Django 15626)
FOUND: 수천 (001) (한국어기초사전 64700) -> 수천 (갈퀴 Django 15716)
FOUND: 열 (001) (한국어기초사전 67805) -> 열 (갈퀴 Django 18860), 열 (갈퀴 Django 18861)
FOUND: 오 (003) (한국어기초사전 31635) -> 오 (갈퀴 Django 19201)
FOUND: 이 (008) (한국어기초사전 71125) -> 이 (갈퀴 Django 21087), 이 (갈퀴 Django 21088), 이 (갈퀴 Django 21089)
FOUND: 일 (005) (한국어기초사전 31523) -> 일 (갈퀴 Django 21614), 일 (갈퀴 Django 32157)
FOUND: 일고여덟 (001) (한국어기초사전 87907) -> 일고여덟 (갈퀴 Django 21632)
FOUND: 조 (006) (한국어기초사전 75237) -> 조 (갈퀴 Django 24009)
FOUND: 천 (002) (한국어기초사전 17167) -> 천 (갈퀴 Django 26111), 천 (갈퀴 Django 26112)
FOUND: 첫째 (002) (한국어기초사전 17310) -> 첫째 (갈퀴 Django 26286)
FOUND: 칠 (002) (한국어기초사전 71470) -> 칠 (갈퀴 Django 27224)
FOUND: 팔 (002) (한국어기초사전 31598) -> 팔 (갈퀴 Django 28658)
FOUND: 한둘 (한국어기초사전 72435) -> 한둘 (갈퀴 Django 29787)
total: 83
갈퀴 Django에서 수사와 겹치면서 명사로 맞춤법 검사 사전에 포함된 항목은 다음 2개.
FOUND: 일고여덟 (001) (한국어기초사전 87907) -> 일고여덟 (갈퀴 Django 21632)
FOUND: 한둘 (한국어기초사전 72435) -> 한둘 (갈퀴 Django 29787)
$ grep -l -r 'MPL 1.1/GPL 2.0/LGPL 2.1' data/entries|wc
1188 1189 54683
예를 들어 ㅂ불규칙은 학교문법에서는 불규칙이라고 부르기 때문에 일일이 입력하기는 하지만 "-ㅂ다"로 끝나는 경우는 다 해당된다. 이런 속성은 자동 처리하도록 한다.
단어 데이터 관리 방식이 지금까지 변화해 온 방식을 보면 다음과 같습니다.
현재 SMW 상태의 문제를 개선할 필요가 있습니다. 왜냐하면,
단순히 git에 들어간 자료 형태로 개편하는 안:
단 git에만 저장된 형태로 가면 한계는 다음과 같습니다.
github 내장 위키 등 여러가지 github 기능을 고려할 수 있습니다.
(http://code.google.com/p/spellcheck-ko/issues/detail?id=5)
명사의 종류에 따라 제약이 있는 조사를 구분.
대명사 이거/그거/저거 + 이 => 이게/그게/저게
0.3.0 대명사의 경우 구별할 수 있게 구현.
1의 경우 모든 명사의 유정명사/무정명사 구분이 필요. 작업량 많음.
2의 경우 현재 "가산명사" 속성 활용 가능.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859294
python3 make-aff-dic.py ko.aff ko.dic dict-ko-builtins.json dict-ko-galkwi.json
Traceback (most recent call last):
File "make-aff-dic.py", line 329, in <module>
dic.load_json(open(filename))
File "make-aff-dic.py", line 166, in load_json
d = json.load(infile)
File "/usr/lib/python3.5/json/__init__.py", line 265, in load
return loads(fp.read(),
File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xed in position 38: ordinal not in range(128)
Makefile:28: recipe for target 'ko.aff' failed
make[1]: *** [ko.aff] Error 1
make[1]: Leaving directory '«BUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
debian/rules:5: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
(http://code.google.com/p/spellcheck-ko/issues/detail?id=13)
What steps will reproduce the problem?
What is the expected output? What do you see instead?
"있다"가 우선순위가 더 높아보이는데 "잇다"가 먼저 등장한다.
연속된 글자가 아닌 경우에도 더 많은 글자가 대체된 쪽이 우선 순위가 높다.
예를 들어, "찾앗다"에 대해 "잦았다"가 "찾았다"보다 먼저 등장한다.
보조용언 붙여 쓰기를 위해 (https://www.korean.go.kr/front/page/pageView.do?page_id=P000075&mn_id=30) 확장하는 부분에 대해:
보조용언은 현재 20개, 보조용언이 붙는 어미는 3종류 (-어, -은, -을)
그러므로 모든 동사에 보조용언을 붙여서 확장하는 것보다 위 3 어미만 확장하고 합성어로 처리하는 게 크기나 성능면에서 더 낫다.
예제:
$ cat aux-using-compounds.aff
SET UTF-8
FULLSTRIP
SFX A Y 3
SFX A 오다 와 오다
SFX A 다 아 받다
SFX A 다 고 .
COMPOUNDMIN 1
COMPOUNDRULE 1
COMPOUNDRULE CB
$ cat aux-using-compounds.dic
4
받다/A
받아/C st:받다
오다/AB
와/C st:오다
$
아예 "받아"를 확장하지 않고 다음과 같이 특정 suffix에 대해서만 COMPOUNDRULE에 처리되게 만들고 싶지만, hunspell의 COMPOUNDRULE 기능에 한계가 있음. 이렇게 하면 동작하지 않음.
$ cat aux-using-compounds.aff
SET UTF-8
FULLSTRIP
SFX A Y 3
SFX A 오다 와/C 오다
SFX A 다 아/C 받다
SFX A 다 고 .
COMPOUNDMIN 1
COMPOUNDRULE 1
COMPOUNDRULE CB
$ cat aux-using-compounds.dic
2
받다/A
오다/AB
$
#40 관련, 남은 단어 1300여 단어의 대부분을 우리말샘 데이터로 대체.
(http://code.google.com/p/spellcheck-ko/issues/detail?id=37)
문제점이 발생하는 상황을 설명해 주십시오.
1.'실용주의'라고 붙여 쓸 경우 맞춤법 오류로 나옴 -> 합성어는 붙여 쓰는 것이 맞음
2.다른 모든 합성어의 체크의 문제로 보여짐.
어떤 동작이 문제입니까? 이 경우에 어떻게 동작하는 게
올바릅니까?
실용주의라고 썻을 경우 표준국어대사전[국립국어원]에 따라 합성어로 보고 붙여 써야 하는데
이러한 합성어를 붙여 쓴 것을 맞춤법 오류로 보고 빨간 줄이 쳐지고 있습니다.
사용하고 계시는 버전과 애플리케이션 소프트웨어의
버전 등 환경을 써 주십시오.
ko-aff-dic-0.5.6
MAC OS 10.9.1
기타 관련 정보가 있다면 써 주십시오.
일단은 사전에 있는 단어는 입력하는 게 정책이므로 예제로 드신 실용주의는 입력하면 해결될 것 같고요. 사전에 없는 일반적인 합성어에 대해서라면 이미 알고 있는 문제이고, 해결도 쉽지 않은 문제입니다. 붙여서 썼을 때 하나의 의미를 가져야 하기 때문에 규칙만 가지고는 어렵습니다.
모든 명사+명사를 폭넓게 허용할 수도 있는데 이러면 의미가 안 통하는 모든 단어를 붙여 써도 허용하는 문제가 생깁니다. 명사를 분류해서 어느 정도 규칙을 만들어 입력하면서 어느 정도는 개별 입력하는 정도가 실용적인 방법일 겁니다.
결국 마찬가지이기는 하지만, 파이썬 코드의 데이터를 단어 데이터로 바꿈으로써 장점이 있다.
전체 참고: 받침이 없거나 ‘ㄹ’ 받침으로 끝나는 명사 뒤에 붙여 쓴다.
(http://code.google.com/p/spellcheck-ko/issues/detail?id=12)
문제점이 발생하는 상황을 설명해 주십시오.
어떤 동작이 문제입니까? 이 경우에 어떻게 동작하는 게
올바릅니까?
수량, 단위를 나타내는 명사에 대해 허용. "한 개씩", "며칠씩", "하나씩", ...
사용하고 계시는 버전과 애플리케이션 소프트웨어의
버전 등 환경을 써 주십시오.
기타 관련 정보가 있다면 써 주십시오.
단위 명사, 수사, 그 외 수량을 나타내는 명사 (며칠 등) 따위를 사전 데이터에
서 구분해야 한다.
~째
"받은듯하다"는 되고 "받으신듯하다"은 안 되는 상황.
안 그래도 용량이 커지고 성능이 떨어지는 주범인 보조용언 확장에 선어말 어미 케이스까지 포함하기는 어렵고, COMPOUNDRULE로 제대로 동작할 수 있어야 한다.
「접사」
「1」((수나 양 또는 값을 나타내는 명사구 뒤에 붙어))‘그만한 수나 양을 가진 것’ 또는 ‘그만한 가치를 가진 것’의 뜻을 더하는 접미사.
¶ 한 뼘짜리/열 살짜리/오십 권짜리/방 두 개짜리/백 원짜리/얼마짜리.
「2」((몇몇 명사 뒤에 붙어))‘그런 차림을 한 사람’의 뜻을 더하는 접미사.
¶ 양복짜리/장옷짜리/창의짜리.
(http://code.google.com/p/spellcheck-ko/issues/detail?id=29)
특별한 상황입니다. 명사+서는 정상적임.
예; 둘이서, 셋이서, 여럿이서
제삼자 + 가, 는, 인, 등등.
Third party / person
표준국어대사전 사이트가 기존 우리말샘/한국어기초사전 기반이기는 하지만 몇 가지 차이점 등 때문에 사용하기에는 문제가 있다. 정리 목적
한국어에서 가산명사의 구분은 그리 엄격하지 않아서 '-들'을 붙이는데 비교적 자유롭다. 셀 수 없는 것도 시적 허용에 따라 허용하는 경우가 많고, 고유명사의 경우는 잘 그러지 않는다.
고유명사처럼 거의 안 붙이는 경우가 있어서 트레이드오프지만, 모두 '-들' 접미사를 허용하는 게 생산적인 방법으로 보인다.
문제는 현재 '-들'이 붙은 형태를 미리 생성해 놓고 있기 때문에 사전 사이즈가 2배 가까이까지 늘어날 가능성이 있다는 점. 미리 생성해 놓지 않고 suffix rule을 쓰면 그 뒤에 조사가 붙었을 경우 suffix를 2개까지만 허용하는 hunspell 제한에 걸릴 수 있고, compound를 쓰면 대치어 찾기가 제대로 되지 않는다.
Word does not match! Index: 13975 Expected: 김수한무거북이와두루미삼천갑자동방삭치치카포사리사리센타워리워리세브리캉무드셀라구름위허리케인에담벼락서생원에고양이고양이는바둑이바둑이는돌돌이 Actual: 김수한무거북이와두루미삼천갑자동방� ERROR converting, the dictionary does not check out OK.
qtwebengine 사전으로 변환을 시도하였으나, 위와 같은 오류로 인해 변환이 불가능 합니다.
관련 이슈:
wooorm/dictionaries#14
(http://code.google.com/p/spellcheck-ko/issues/detail?id=15)
사동의 의미를 부여하는 접미사 '-시키다', 피동의 의미를 부여하는 접미사 '-당
하다'는 사전에 별도로 나와 있지 않다. 사전에 없어도 별개의 단어로 기재하거
나 서술의 의미가 있는 명사에 대해서 표시를 해야 한다.
'-시키다'의 경우에는 서술을 나타내는 모든 명사에 가능하지만 '-당하다'는 피
동이 가능해야 하므로 타동사의 경우에만 가능하다.
"사과인듯하다" = 사과 + 이다 + 듯하다
모든 명사를 -일, -인이라고 확장하기는 힘들고, COMPOUNDRULE로 처리할 수밖에 없음.
(http://code.google.com/p/spellcheck-ko/issues/detail?id=26)
대치어: 자켓 -> 재킷, 팬더 -> 판다
모음 2개를 바꾸는 것보다 우선순위가 높은 다른 단어가 많기 때문인데, 모음 2개의 변화의 우선순위를 높이는 방법 고안해야 함. 외국어 표기로 많이 발생하는 케이스.
어미 활용 정보를 현재 suffixdata.py 파일에 일일이 기록하고 있는데, 길이도 길어지고 관리가 쉽지 않다. 단어 데이터로 분리해서 사용할 수 있도록 개편.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.