2009년 5월 29일 금요일

haskell, happstack 에서 Text.Html 통해서 한글 출력

  마이너 언어를 배울때 가장 골때리는게 한글문제다. 역시나 haskell 도
  마찬가지라 한글이 엮이면 좀 난감해 지는데 뭐 포터블한 한글파일명
  처리는 바라지도 않지만 그래도 리눅스상에서 한글을 뿌리는건
  가능해야겠지. 어쨌거나 기본 모듈인 Html.Text 로 간단히 한글을
  포함하는 html 을 만들어 보고 이놈을 Happstack 을 통해서 뿌려봤다.

  먼저 Text.Html 은 html 을 뽑아낼 함수덩어리들을 유지하다가
  renderHtml 등으로 실행을 하면 String 타입의 html 을 돌려주는 놈이라고
  보면 된다. haskell 의 String 타입은 아주 엿같다고 생각하기 때문에
  이런 동작이 그다지 맘에 들진 않지만.. 뭐 어쨌거나 String 으로만
  뽑아주게 되어있다.

  Happstack 은.. 뭐 결국 응답으로 쓸수있는 타입이 ToMessage 란
  타입클래스의 인스턴스여야 하는데 결론적으로 toMessage 라는 함수에
  의해서 ByteString 으로 변환후 이걸 브라우저에 뿌려준다고 보면
  되겠다.

  마침 Html 이 ToMessage 의 인스턴스로 잡혀있어서 따로 렌더를 부르지
  않고 바로 Html 을 리턴해주면 알아서 적절히 풀어주게 되어있는데
  문제는! 이 인스턴스 구현 소스를 보면 알지만 renderHtml 한 결과물인
  String 을 Data.ByteString.Lazy.Char8.pack 을 통해서 바이트스트링으로
  바꾼다는거다. Char8 타입이 어떻게 돌지는 모르겠다만 유니코드를
  담고있는데 8 이란꼬릴 달고있는 타입을 적용했다는거 자체가 뭔가
  안좋다는게 느껴진다.

import qualified Data.ByteString.Char8 as B
import qualified Data.ByteString.Lazy.Char8 as L

instance ToMessage Html where
toContentType _ = B.pack "text/html"
toMessage = L.pack . renderHtml

  마침 얼마전에 봐둔 utf8-string 이란 패키지가 있었고 그쪽 문서를
  둘러보니 Data.ByteString.Lazy.UTF8 이란 모듈이 보였다.. 흠. 이런식의
  모듈간의 호환성을 이용한 라이브러리 구성은 정말 익숙해지질
  않는군.. 어쨌거나 저놈을 이용해서 바이트스트링으로 바꿔주니 한글이 잘
  보이더라.

import Happstack.Server
import Text.Html
import qualified Data.ByteString.Char8 as B
import qualified Data.ByteString.Lazy.UTF8 as U

main = simpleHTTP conf handler
conf = Conf 8080 Nothing
handler = return f

hello = header << thetitle << "안녕"
+++ body << "세상"

f = U.fromString $ renderHtml hello

instance ToMessage U.ByteString where
toContentType _ = B.pack "text/html"
toMessage = id

  음.. 사실 ToMessage Html 인스턴스를 유니코드먹인걸로 덮어쓰고
  싶었는데 방법을 잘 모르겠네. 기존 인스턴스를 무시하고 새인스턴스를
  정의한다거나 하는건 안되나? newtype 으로 새 타입을 만들어주는 삽질을
  해줘야 하는건가? import 시 적절히 저놈만 제외해줄수는 있나? 흠.






 

2009년 5월 19일 화요일

GetIt, windows 에서 apt-get 비스무리 흉내내기

http://puchisoft.com/GetIt/

아주 오래전 봐둔 링크가 갑자기 기억나서 깔아보려다가.. 이것저것 깔라는게 많아서 그냥 여기 적어두고 다시 덮어둘란다. 대강 보니까 여러 어플들을 깔아야 완전한 서비스가 되는 모양인데 나중에 왜 이런 꼴인지 읽어보자.

음 방금 깔아보니 다른 두 어플이 리파지토리를 관리하고 GetIt 이 그걸 제어하는 모양인데.. 이 두놈이 피같은 하드를 많이도 처먹네(파이썬으로 만들어서 exe 로 배포.. 후랄 젠장 이딴거 정말 짱난다. 물론 이게 개발자가 편하고, 나도 이런식으로 배포하는걸 먼저 고려하겠지만.. 하드가 이제 싸다느니 램은 이제 문제가 안된다느니 하는 소릴 하는거 보면 정말 욕나온다. 나도 그런개소리를 종종 해야 하지만...)

지워야 쓰것다.

나중에.. 사무실에서 윈도 쓰면 그때 다시 깔아보자.


추가.
가장 가벼운 windows-get 만이라도 깔아봤는데 지금 사이트가 죽은건가 되는게 없네. 다음에 다시 확인해보자.

추가.
음 위 프로젝트는 죽었네. 포럼 가보니 http://win-get.sourceforge.net 도 있던데 이건 일단 리파지토리가 살아있는건 확인을 했지만 이쪽 포럼도 전혀 관리가 안되고 있더라.

그냥 전부 잊어먹고 수작업하자.

추가.
http://win-get.ayalasoft.com/ 이쪽도 win-get 이네.. 돌려보진 않았지만 최근까지 업데이트가 되고있네.

추가.
http://code.google.com/p/qwinapt/ 이런놈도 있다. 어휴.. 이런게 찾으면 자꾸 나오네. 하지만 대세탄 어플은 없으니 뭘 써도 관리문제가 있고 또 apt-get 처럼 편한것도 아니다.


추가 2009/11/11
http://ninite.com/ 클리앙에서 봤는데, 흠 이런식의 모음도 괜찮아 보인다. 다음에 PC 세팅할때 고려해보자. 그때 이게 기억났으면 좋겠다.

2009년 5월 18일 월요일

현재 사용중인 dot emacs 파일

emacs 를 사용한 이후로 emacs 설정파일 묶음은 내 개발역사나 마찬가지다.
org 모드에 블로그보다 많은 정보를 들고 있고 이걸 .emacs 들과 함께 hg 로 버전관리중이니 뭐 그 이상이지...

오래전 위키에 올렸던 페이지가 어쩌다 오늘 내눈에 보이길래 지금 쓰는 dot emacs 파일을 올려봤다. 예전 위키에 적을때하고 다른점은.. 그때는 주로 윈도에서 놀았으나 지금은 거의 리눅스에서만 개발을 하고 있다는 점? 그리고 그때는 재미삼아 common lisp 을 주로 구경했는데 지금은 haskell 에 좀더 관심있다는 정도...

그때나 지금이나 허접한 개발자란건 변함이 없구만.

아래 소스를 올리긴 하는데 내가 워낙 게으른놈이라 코드가 정리가 전혀안됐다. 주석도 처음에 주절주절 적어둔거 그대로.. 심지어는 svn 쓰던 시절의 $Id$ 이것까지 남아있네. 이거 전부 정리해야 할 글인데.. 지금도 몇몇 코드들은 다픈 파일로 따로 뽑아낸 상태인데 언제 시간내서 싹 정리를 해야겠다.

펼쳐두기..


흠. 그나저나 예전에는 여러가지로 불편해서 남들 elisp 도 뒤져보고 내가 직접 만들어보는 삽질도 하고 했는데 요즘은 그야말로 불편한게 없어서 더이상 발전이 없네. 오랜만에 emacswiki 좀 구경가야겠다... 음 내일.. ㅎㅎ