파이썬의 라이브러리 NumPy + SciPy _____ 7

==========================================================
이 포스팅은 쓸모 없어진 포스팅입니다.
(NumPy + SciPy ____ 4 ~ NumPy + SciPy ____ 8)
해당 문제점은 Scipy 패키지를 빌드했던 툴(아마도 MS Visual Studio 201x)이 Windows XP를 지원하지 않아서 발생한 것으로 추측하고 있습니다.
이후의 포스팅에서 이 시행착오를 정리할 계획입니다. (아마도 NumPy + SciPy ____ 9)
==========================================================

앞서의 포스팅에서 파이썬이 모두 빌드되었다.
(처음엔 뭐가 부족하거나 문제가 있는게 아닌가 싶었는데 확인해 보니 모두 빌드 되어 있었음. 단지 빌드시에 나온 여러개의 워닝 메시지와 스킵한 프로젝트가 뭔지는 아직 미확인.)

빌드의 결과물은 PC/VS9.0 폴더에 있으며, 릴리즈 버전인 python.exe와 python27.dll, 디버그 버전인 python_d.exe와 python27_d.dll이다. (각 써드 파티의 라이브러리는 각 해당 폴더에 있음)

빌드된 python.

배포되는 Python 실행. 빌드버전과 CRC로 보이는 숫자가 있고 다음에 빌드 시각 2015년 12월 5일 20시 32분.

새로 빌드된 Python 실행. 버전 대신 default, 빌드 시각은 2016년 3월 28일 23시 18분.

Python 소스의 트리 구조

Python의 트리 구조

파이썬 소스의 폴더는 바이너리 배포 버전의 폴더와 약간은 다른데, 여기에서 고민이 생긴다.
완벽한 파이썬의 실행 환경이 갖추어져 있지 않으므로 바로 여기에서 디버깅을 하기엔 제약이 따른다는 것이다.

그러면 어떻게 디버깅을 해야 하는가?

1) 빌드된 디버그 버전의 바이너리를 원래의 환경에 복사해 넣고 디버깅을 한다?
소스와 바이너리의 위치가 다를 경우엔 어떻게 해야 하지?
gdb라면 간단하게 소스 위치만 지정하면 될텐데, Visual Studio의 IDE 환경에서도 이게 가능할까?

2) 소스 디렉토리에 필요한 나머지 파일들을 복사해 놓고 디버깅?
파이썬이 비록 인스톨러로 설치가 되긴 하지만, PATH에 경로를 지정하는 것 외에는 별다른 작업이 필요하지 않은 것 같던데? 아닌가?
그리고 Windows/system32 폴더에 python27.dll이 복사되어 있는 것도 보았다.



먼저 2번의 방법을 좀 더 생각해 보다가, 이런 의문이 떠 올랐다.
- 맨 처음의 NumPy와 SciPy를 설치할 때도 특별히 파이썬의 위치를 지정하지 않았지만 알아서 설치가 되었다. 이건 어떻게 가능했을까? (PATH를 보고? 설치 프로그램인 pip의 위치를 기준으로?)
: 이걸 새로 빌드된 환경에서 시험해 보려고 했는데, 아무리 찾아봐도 pip가 보이질 않는다.
 그냥 복사를 해서라도 해 볼까 하다가 걍 포기.

- 파이썬 인터프리터에서 import를 하면 해당 라이브러리를 잘 찾아낸다. 어떻게 가능한걸까?
: 구글에서 "python import dir order"로 검색을 하자 파이썬의 문서에서 "module-search-path" 부분을 찾아서 보여준다.
https://docs.python.org/2/tutorial/modules.html#the-module-search-path

위 링크에서 언급하는 sys.path를 직접 확인해 보았다.

Python의 sys.path

새로 빌드된 Python의 sys.path

환경변수인 PATH에 지정된 경로와는 상관없이, 현재 실행된 위치를 기반으로 내부의 탐색 경로가 바뀌는 것을 알 수 있다.


다시 위의 디버깅에서 1번의 방법에 대해 알아보니, 빌드시에 생성된 pdb에 소스의 위치 정보가 있으므로 바이너와 소스의 위치가 달라도 소스 레벨의 디버깅이 가능하다고 한다......정말일까?

그래서 빌드된 exe, dll, pdb 파일들을 모두 원래의 파이썬이 설치되어 있던 폴더에 복사했다. (원래의 exe와 dll은 다른 폴더에 피신 시켜 둠.)

새로 빌드한 파일들을 파이썬 설치 폴더에 복사

그런데.... 안된다.
Visual Studio에서 읽어 들여 보았으나, 디스어셈블 코드만 보여 줄 뿐, 소스를 찾지 못한다.
심지어 소스 폴더를 지정하는 옵션도 없다.


그래서....Visual Studio에서 프로젝트의 속성을 수정했다.

Python 프로젝트의 속성에서 Debugging의 Command 항목 수정

저기에 직접 디버깅할 실행 파일 이름을 지정해주면 된다.

Debugging 위의 General에서 Output Dir을 바꿔주는 것도 방법이긴 한데, 수정 - 빌드 - 디버깅 작업이 그리 많지 않을거라 생각하기에 최소한만 건드리는 방법을 택한 것이다.

그리고 Visual Studio에서 Start Debugging(F5)을 하면 다음과 같이 나온다.
여기에서 sys.path로 작업중인 디렉토리를 확인할 수 있다.

Start Debugging후에 sys.path로 작업중인 위치 확인.

그리고 그토록 알고자 했던 그 문제점이 재현되는지 확인하기 위해 "from scipy import special, optimize"를 입력하자...

기존의 문제점이 재현되는지 확인....어?

출력되는 메시지가 다르다. 에러는 에러인데....뭔가 이상하다.

아까 디버그와 릴리즈 버전의 바이너리를 모두 복사해 놓은 상태이기에, Visual Studio를 거치지 않고 바로 실행해서 다시 확인해 보았다.


먼저 디버그 버전의 경우..

디버그 버전

역시나 맨 처음과는 다른, Visual Studio를 거쳤을 때와 같은 에러 메시지.

그럼 릴리즈 버전의 경우는...

릴리즈 버전

애초에 보았던 것과 동일한 에러 메시지.

이런 x같은 경우를 보았나.

디버그 버전과 릴리즈 버전의 동작이 서로 다르단 말인가? 왓더뻐~어~억 쒜트 쒜~에~트

메시지를 차근 차근 확인해 본 결과, 릴리즈 버전은 numpy를 먼저 다 import하고 난 후에 scipy의 special을 import하는 중에 에러가 발생했고, 디버그 버전은 numpy를 import하는 과정에서부터 에러가 발생한 것으로 보인다.

침착하고.....

이 문제점이 내가 빌드하는 과정에서 발생한 것인지, 파이썬 자체의 소스 혹은 빌드 구성에 문제가 있는 것인지 알려면 빌드 로그를 모두 꼼꼼하게 확인해 보아야 한다.

그리고 애초에 문제가 되었던 부분에 대한 확인은, 당장은 릴리즈 버전으로 밖에 할 수 없는 상황이고, 이것도 메시지 출력을 이용하거나, 의심되는 부분을 바로 수정해서 확인해 보는 방법 뿐인 듯 하다.

단, 하나의 문제점 때문에 너무나 많은 과정을 거치고 있고, 자꾸 곁가지를 치면서 목표의식마저 흐릿해져 가고 있는 듯 하다.

디버그 버전과 릴리즈 버전의 문제를 확인하기 앞서서, 본래의 문제점을 먼저 해결하길 나 자신에게 바래 본다.

버그와 디버깅에 관한 단상

디버깅에 집중하다 보니,
마지막 포스팅에서의 쓸데없는 생각, 자기 자신을 (온전히) 디버깅할 수 있는 프로그램은 없다...

오늘 밤, 아니군 어제 밤, 간만에 산책을 하면서 들어 온 생각
자기 자신을 디버깅 할 수 있는 머신은 과연 불가능한 걸까?
(현재의 프로그램이라는 좁은 제한을 벗어나 모듈화 되고 병렬처리가 가능하고 자기 복제도 가능한 등의 H/W와 S/W를 모두 갖춘 진보된 장치라면 가능하지 않을까?
그리고 이런 기술적인 문제를 넘어서의 고차원적인 문제를 생각해 본 것이다.)

극장판 애니메이션 [공각기동대]의 초반부에 이런 대사가 나온다.
버그가 없는 프로그램도 없지만, 디버깅이 불가능한 프로그램도 없지.

그런가?

2001: A Space Odyssey에는 HAL 9000이라는 인공지능 컴퓨터가 등장한다.
탁월한 능력을 지녔으며 우주선의 모든 것을 관리/제어하는 중요한 역할을 한다.
하지만 지구와의 통신을 위한 위성 안테나 모듈에 문제가 있다는 잘못된(?) 판단을 내린다.
우주선의 항해사들은 HAL 9000에 버그가 발생했다고 생각을 하지만 HAL 9000은 그렇지 않다고 생각한다.

버그를 제거하는 디버깅의 시작은 버그를 인식하는 것이다.
HAL 9000이 제아무리 뛰어나다 해도 그것이 버그라고 인식하지 못한다면 디버깅은 불가능하다.

그렇다면 과연 그것이 버그였을까?
엄격하게 따지자면 그건 버그가 아니었다.
그 문제를 보는 이의 시각에 따라 옳고 그름이 갈리기 때문이다.
그리고 HAL 9000은 나름대로의 이유가 있었기에 안테나 모듈의 문제를 제기했던 것이다.
하지만 항해사들의 입장에서는 문제 없는 모듈에 문제가 있다고 교체를 강요하는 HAL 9000에 큰 버그가 있다고 생각했던 것이다.

만약 모든 입장, 모든 치우침, 모든 편견에서 자유로워진다면 버그라고 인식할 것이 없는 건 아닐까?
결국은 극히 제한된 일부로써의 편향된 입장을 가지게 되면 버그로 인식할 것은 매우 많아지는 것이고, 버그는 그 자체가 문제가 아니라, 그걸 바라보는 이의 편향된 생각이 만들어낸 왜곡된 환상이었던 건 아닐까?


일본의 만화가 우라사와 나오키의 [플루토]를 보면 이런 이야기가 나온다.
최고의 로봇을 만들기 위해 고민을 하던 텐마 박사는 결국 모든 인류의 특성을 한데 모아서 자신의 로봇에게 주입을 했고, 기동을 시켰으나 결국 그 로봇은 깨어나지 못했다고 한다. 모든 인류의 특성을 가진 롯봇은 결국 자신의 주체를 혼동하여 결정하지 못했기 때문이라고...