봉봉주세요

Solaris 설치시 자동으로 mount 영역 나눠서 설치하긴 하지만, 각 영역의 크기가 실제로 사용하기엔 좀 안맞기 때문에 보통 사용자 설치를 하는 것으로 생각한다.

이 때, swap 영역의 크기도 설정해줘야 하는데...
주말에 swap 영역을 좀 작게 잡아서 어제 다시 설치해주는 삽질을 했다. (Oracle 설치시 문제가...)


oracle.com의 설치 매뉴얼을 보면 2.2 장에 Checking the Hardware Requirements라고 해서 필요한 swap 영역이 나와있다.

The system must meet the following minimum hardware requirements:

• At least 1024 MB of physical RAM

• The following table describes the relationship between installed RAM and the configured swap space requirement.

  RAM	Swap Space
  Between 1024 MB and 2048 MB	1.5 times the size of RAM
  Between 2049 MB and 8192 MB	Equal to the size of RAM
  More than 8192 MB	0.75 times the size of RAM

  
  

• 400 MB of disk space in the /tmp directory

• Between 1.5 GB and 3.5 GB of disk space for the Oracle software, depending on the installation type

• 1.2 GB of disk space for a preconfigured database that uses file system storage (optional)

  Note:

  The disk space requirement for databases that use Automatic Storage Management or raw device storage is described later in this chapter.

  Additional disk space, either on a file system or in an Automatic Storage Management disk group, is required for the flash recovery area if you choose to configure automated backups.

즉, 1GB ~ 2GB 사이의 RAM을 가지고 있으면 swap 영역의 크기는 RAM 크기의 1.5배를
2GB ~ 8GB 사이의 RAM을 가지고 있으면 swap 영역의 크기는 RAM 크기와 동일하게,
8GB 이상일 때는 0.75배의 크기로 설정해야 한다.


다음부터는 이런 실수는 하지 말아야지... 역시 아는게 힘이고 몸 덜 고생시키는 길이다!!!

Solaris DVD의 경우 썬의 다운로드 센터에서 파일을 다운로드 받으면 700MB 단위로 파일이 나눠져 있다.

이 파일의 병합 방법은 다음과 같다.

1) Unix / Linux

cat 명령어 사용
cat [file_a] [file_b] [file_c] ... > [target_file]

사용예)
cat sol-10-u3-ga-sparc-dvd-iso-a sol-10-u3-ga-sparc-dvd-iso-b sol-10-u3-ga-sparc-dvd-iso-c sol-10-u3-ga-sparc-dvd-iso-d sol-10-u3-ga-sparc-dvd-iso-e > sol-10-u3-ga-sparc-dvd.iso

2) Windows

copy 명령어 사용

copy /b [file_a] + [file_b] + [file_c] + ... [target_file]

사용예)
copy /b sol-10-u3-ga-sparc-dvd-iso-a + sol-10-u3-ga-sparc-dvd-iso-b + sol-10-u3-ga-sparc-dvd-iso-c + sol-10-u3-ga-sparc-dvd-iso-d + sol-10-u3-ga-sparc-dvd-iso-e sol-10-u3-ga-sparc-dvd.iso



참조 사이트 : http://www.sun.com/software/solaris/download_instruction.xml

예전에 UNIX, LINUX를 잘 모를때 대체 프로그램에서 왜 SIGBUS가 발생하는지 의문이었다. 무식하게도 예전엔 H/W 문제인줄 알았다.

몇일전 다른 PC에서 잘 돌던 프로그램이 Solaris SPARC 환경에서 계속 디진다. gdb로 왜 죽는지 찾아봤더니 SIGBUS 시그널에 의해서 디진단다. 원인은 프로그램에 있으면서도 몇일을 시스템 환경만 탓하고 있다가 정신을 차리고 자료를 찾아봤더니, 유효한 메모리 영역에서 잘못된 메모리 참조란다.

SIGSEGV는 잘못된 메모리를 참조하는 거고... 자료를 계속 찾다보니 SIGBUS 오류 나면 사람 피 말린다고 하더라 ㅡㅡ;; 나도 몇일간 그랬었고... 답답해서 ㅠ.ㅠ

암튼 원인은 다음과 같았다. 처음에는 구조체의 packing 문제인줄로만 알았는데 꼭 그런건 아니었고, 메모리에서 데이터를 패치하는데 문제가 있었던 것이다.

CPU에서 데이터를 패치할 때, 32bit냐 64bit냐에 따라서 다르고, OS에 따라서 다르다고 하는데 보통 32bit 환경에서는 4byte 단위로 데이터를 패치하는게 정석이라고 한다. 즉, 0~3, 4~7, 8~11 요런식으로 패치한다는 말씀.
여기서 중요한건 단순히 그냥 4byte가 아니고, 시작 주소가 4의 배수여야 한다는것... 즉, 동일하게 4byte를 가져오더라도 1~4 영역의 메모리에서 데이터를 fetch하면 SIGBUS 시그널이 발생할 수 있다.

그 이유는 즉, CPU는 위에 말한 것처럼 메모리에서 4byte 단위로 끊어서 데이터를 CPU에 적재하는데 1~4의 경우는 0~3, 4~7 영역에서 두번을 fetch하여 데이터를 적재해야하기 때문에 오류가 발생하는 것이란다.

암튼 2~3일간 머리 아팠던 것은 한시름 놨고... 이제 그런 구조들을 변경해야한다. 내가 지금 수정하고 있는 방법중 일부는 버퍼 내에서 레코드의 시작 주소를 4의 배수로 바꾸는 것과 버퍼에서 바로 데이터를 사용하지 않고, 임시 변수에 데이터를 복사한 후 사용하는 방법을 사용하고 있다.

야호~

아직은 어떻게 정리해야 할지를 몰라서 자세한 얘기는 나중에...

JavaScript를 Parsing하기 위해 mozilla에서 만든 SpiderMonkey라는 라이브러리를 받아서 테스트해보고 있는데 쉽지가 않다.

스크립트 실행은 성공적으로 됐는데, Context 객체를 Destroy할 때 생성한 object의 destructor가 2번이 호출되서 프로그램 오류가 발생한다. 주위에 이거 해본사람이 많으면 왜 잘못됐는지 알 수가 있을텐데... 주위에 아는 사람이 없어서 아주 미칠것 같다.

수행되는거 보고 이제 실마리가 잡히나 보다 하고 있었는데... OTL

우리가 아무렇지 않게 쓰는 웹 브라우저의 일부분인 JavaScript parsing이 이렇게 어려울 줄이야... 다시 한번 내 능력과 지식의 한계를 느끼게 된다.

버뜨... 좌절하지 말고 꼭 해내고 말테다!!

나만 몰랐었나 ㅠ.ㅠ

회사에서 일하다가 결과 데이터를 CSV 형태로 내려주는 부분을 추가하는데,
중간에 이상한 문자가 끼어있으면서 한 셀에 많은 데이터가 들어가 있는 것을 봤다.

원인을 찾아보니 따옴표(") 때문이었다.

이를 해결하는 방법은,

" => "" 로 치환.

또 하나 셀 중간에 콤마(,)가 들어있는 경우 셀 데이터를 따옴표로 감싸주면 된다는 사실...


엑셀에서 환영합니다, 봉봉님 을 하나의 데이터로 취급하고 싶을 때 원본 데이터는
"환영합니다, 봉봉님"
으로 해주면 된다는 사실~


혹시나 나중에 또 까먹을까봐 기록해둠

어제 기존에 있는 소스를 c++ 코드로 리팩토링 작업을 하면서, 할당된 메모리 블록의 크기를 구할 수 있는 방법을 찾아봤었는데, 쉽지 않고나 ㅠ.ㅠ

VC에서는 _msize() 함수를 이용해서 메모리 블록의 크기를 구할 수 있는 방법을 알아냈지만, 다른 OS, 컴파일러에서는 그 방법이 너무나 다양해서 포기...

자료 찾다보니깐... wrapper 형태로 만들어서 사용하라고 나와있긴 하던데(근데, 실제로 C/C++ 컴파일러에서도 wrapper 형태로 사용한다는...) 그냥 나름대로 별 의미가 없지 않을까 싶어서, 그냥 일반 변수나 구조체의 메모리 할당은 malloc, realloc, free 함수를 사용하기로 나름 결정 . 뭐 어차피 블록 크기를 구하려고 했던 이유가 new, delete를 사용하는 realloc를 구현해보려고 했었으니까...

역시 크로스 플랫폼 프로그래밍은... 쉽지만은 않은...

1. 아스키 코드(ASCII)
주로 영어와 몇몇 기호를 표시하기 위해 씁니다. 코드값은 0x00 ~ 0x7F사이의 값을 가집니다.

2. ISO-8859-1 부터 ISO-8859-15
주로 유럽에서 쓰이는 언어들(독일어,프랑스어,터키어,그리스어,키릴어(러시아 등) 등등)을
표현하기 위해 쓰입니다. 0x00 ~ 0xFF까지의 값을 가지는데 0x00 ~ 0x7F는 아스키와 동일합니다.

3. 한글 완성형 코드(EUC-KR, UHC)
UHC는 M$ 확장 완성형이라고도 하고, 마이크로소프트사에서 EUC-KR을 기반으로 확장한 것입니다.
0x00 ~ 0x7F의 아스키도 포함합니다.
EUC-KR의 경우 0xA1A1 ~ 0xFEFE값을 가지며, 한글, 한자, 기호 등이 있고, 값에서 알 수 있듯이
2바이트가 하나의 문자를 표현합니다.
UHC는 여기서 첫바이트는 0x81 ~ 0xA0값도 사용하고, 두번째 바이트는 0x41 ~ 0x5A,
0x61 ~ 0x7A, 0x80 ~ 0xA0값도 사용합니다.

4. 한글 조합형 코드(JOHAB)
0x00 ~ 0x7F의 아스키를 포함합니다.
역시 두바이트가 하나의 문자를 표현하는데, 두바이트인 16비트를 가지고 첫비트는 무조건 1,
다음 2 ~ 6 비트가 초성, 7 ~ 11비트가 중성, 12 ~ 16비트가 종성을 나타냅니다.

5. 일본어 EUC-JP 코드
0x00 ~ 0x7F는 아스키
0xA1A1 ~ 0xFEFE는 일본어 글자인 히라가나, 카타카나, 한자, 그리스어, 키릴어 및 각종 기호 영역
0x8EA1 ~ 0x8EFE는 반각 카타카나 영역
0x8FA1A1 ~ 0x8FFEFE는 확장된 그리스어, 키릴어, 한자 등이 있는 영역입니다.
값에서 알 수 있듯이 한 문자를 표현하기 위해 3바이트를 쓰는 경우가 있습니다.

6. 일본어 SHIFT_JIS 코드
0x00 ~ 0x7F는 아스키
정확하게 값이 기억은 안나지만 0x8140부터 시작하는 두바이트로 된 코드들이 있는데
EUC-JP의 0xA1A1 ~ 0xFEFE에 해당하는 문자들이 있습니다.
0xA1 ~ 0xFE는 반각 카타카나 영역입니다.

7. 중국어 GB-2312(간체) 코드
0x00 ~ 0x7F는 아스키
0xA1A1 ~ 0xFEFE 사이에 수많은 한자들과 기호등등의 문자들이 있습니다.

8. 중국어 HZ(간체) 코드
GB-2312를 특정한 방식에 따라 인코딩한 것입니다.

9. 중국어 BIG-5(번체) 코드
0x00 ~ 0x7F는 아스키
두바이트가 한 문자가 되는 코드들이 있는데 이 코드는 변종이 많아서 정확한 값은 모르겠습니다.

10. 중국어 GBK(간체) 코드
마이크로소프트사에서 GB-2312를 기반으로 확장한 코드입니다.

11. 중국어 GB18030 코드
GBK를 포함합니다.
여기다가 한 문자를 표현하기 위해 4바이트까지 확장해서 씁니다.
유니코드에 포함된 모든 문자가 포함되어 있습니다.

12. 한글 ISO-2002-KR
EUC-KR을 특정한 방식에 따라 인코딩한 것입니다.

13. 일본어 ISO-2022-JP/ISO-2022-JP2
EUC-JP와 EUC-KR, GB-2312, ISO-8859-1, ISO-8859-7을 특정한 방식에 따라 인코딩한 것으로
ISO-2022-JP2는 ISO-2022-JP의 확장으로 보시면 됩니다.

14. 중국어 ISO-2022-CN/ISO_2022-CN-EXT
GB-2312, BIG-5에 포함하는 문자 및 기타 다른 여러 중국어 코드들을 특정한 방식에 따라
인코딩한 것입니다.
여기서 알 수 있겠지만 중국어 관련 코드는 위에서 소개한 것 말고도 엄청나게 많습니다.
심지어는 조선족을 위한 (한글) 코드까지 있는 것으로 알고 있습니다.

15. 유니코드
전 세계의 존재했거나, 존재하거나, 앞으로 생길지도 모르는 모든 문자를 지원하기 위해
만들어진 것으로 알고 있습니다. 각종 현대문자, 고대문자, 기호 등등을 포함하며
UTF-32, UTF-16, UTF-8, UTF-7등등의 인코딩 방식에 따라 인코딩되어 사용되고 있습니다.
유니코드에 대한 자세한 설명은 http://www.unicode.org에서 찾아 읽으시는게 좋을 듯합니다.
물론 국내에도 꽤나 괜찮은 문서들을 검색을 통해 찾아볼 수도 있을 겁니다.

아침에 갑자기 IIS 접속 로그를 봐야할 일이 생겨서 갑자기 만든 프로그램...

이미지 접속 로그 필터링, Client IP 필터링, Uri 필터링 밖에 없지만 로그가 많지 않은 곳에서는 나름 유용할지도 모르겠다는 생각에

그나저나 내 소스 공개하긴 처음이라... 무지 부끄럽소 허허허