[Mac OS] React Native Build Error in MAC M1

Mac Os M1 Process 에서 React Native build 시 오류가 발생했을 때 제일 처음 Rosetta option 이 설정되어 있는지 확인한다.

Mac Os M1 Process 에서 React Native build 시 오류가 난다면.

    1. Terminal App 의 Rosetta option 을 Check 한다.
set Rosetta option in app info
set Rosetta option in app info
set Rosetta option in app info
set Rosetta option in app info
    1. iTerm App 의 Rosetta option 을 Check 한다.
set Rosetta option in app info
set Rosetta option in app info
set Rosetta option in app info
set Rosetta option in app info
    1. XCode App 의 Rosetta option 을 Check 한다.

하지만 XCode 에는 Rosetta option 이 없다.

set Rosetta option in app info
set Rosetta option in app info
 

모두 행복한 고수되십시오.

WooGong ))*
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

[Python] Python Virtual Environment Setting on Mac

MAC OS 에 파이썬 가상환경을 구성하는 방법

Python Virtual Environment Setting on Mac

MAC OS 에 파이썬 가상환경을 구성하는 방법

1. Homebrew 설치

먼저 Homebrew가 설치되어 있어야 합니다. Homebrew는 macOS에서 소프트웨어 패키지를 관리하기 위한 훌륭한 도구입니다. Homebrew가 설치되어 있지 않다면, 터미널을 열고 아래 명령어를 입력하여 Homebrew를 설치합니다:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

2. pyenv와 pyenv-virtualenv 설치

Homebrew를 사용하여 pyenv와 pyenv-virtualenv를 설치합니다. 터미널에서 다음 명령어를 실행합니다:

brew install pyenv
brew install pyenv-virtualenv

3. 쉘 환경 설정

pyenv와 pyenv-virtualenv를 사용할 수 있도록 쉘 환경을 설정합니다. 사용하는 쉘에 따라 설정 방법이 다릅니다. 대부분의 경우, ~/.bashrc, ~/.bash_profile, 또는 ~/.zshrc 파일을 수정합니다.

Bash를 사용하는 경우, ~/.bash_profile에 다음 내용을 추가합니다:

export PATH="$HOME/.pyenv/bin:$PATH"
eval "$(pyenv init --path)"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

Zsh를 사용하는 경우, ~/.zshrc에 다음 내용을 추가합니다:

export PATH="$HOME/.pyenv/bin:$PATH"
eval "$(pyenv init --path)"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

파일을 수정한 후, 쉘 설정을 다시 로드합니다:

source ~/.bash_profile  # Bash 사용자
source ~/.zshrc         # Zsh 사용자

4. Python 설치 가능 버전 확인

pyenv install --list
pyenv install –list

pyenv를 사용하여 설치할 수 있는 Python 버전들을 확인합니다. :

pyenv install --list

5. Python 버전 설치

pyenv install 3.12.3
pyenv install 3.12.3

pyenv를 사용하여 원하는 Python 버전을 설치합니다. 예를 들어 Python 3.12.3을 설치하려면 다음 명령어를 실행합니다:

pyenv install 3.12.3

pyenv versions
pyenv versions

설치된 Python 버전을 확인하려면 다음 명령어를 사용합니다:

pyenv versions

6. 가상환경 생성

pyenv virtualenv 3.12.3 myPython_test_env
pyenv virtualenv 3.12.3 myPython_test_env

pyenv-virtualenv를 사용하여 가상환경을 생성합니다. 예를 들어, myPython_test_env라는 이름의 가상환경을 Python 3.12.3 버전으로 생성하려면 다음 명령어를 실행합니다:

pyenv virtualenv 3.12.3 myPython_test_env

7. 가상환경 생성

Check environment
Check environment

생성 후 가상환경들을 확인해 봅니다.

8. 가상환경 활성화 및 비활성화

생성한 가상환경을 활성화하려면 다음 명령어를 실행합니다:

pyenv activate myPython_test_env

가상환경을 비활성화하려면 다음 명령어를 실행합니다:

pyenv deactivate

9. 가상환경 제거

더 이상 필요하지 않은 가상환경을 제거하려면 다음 명령어를 실행합니다:

pyenv virtualenv-delete myPython_test_env

이제 pyenv와 pyenv-virtualenv를 사용하여 Python 가상환경을 구성하는 방법을 살펴보았습니다.
이를 통해 프로젝트마다 독립적인 Python 환경을 설정하고 관리할 수 있겠죠?!

 

모두 행복한 고수되십시오.

WooGong ))*
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

출처: https://www.jumptovb.net/entry/Python-Python-Virtual-Environment-Setting-on-Mac [Jump To VB.NET:티스토리]

[.NET] The true face of .NET (1)

2009년의 글을 블로그 이사를 하면서 옮긴 글입니다.
개인적인 생각을 적은 내용으로 돌아보니 조금은 낯간지러운 글이네요.
틀린 부분이 있더라도 많은 부분 수정 없이 그 당시의 지식을 유지하겠습니다.  귀엽게 봐주십시오.

.NET 의 실체 (1)

나 자신이 보지 못했던 컴퓨터 환경에서 부터 지금까지.. 아직도 널리 퍼져있는 문제들이 어떤 것들이 있는 지부터 살펴보는 것이 좋을 듯 합니다.

      1. 사용자들의 요구 사항은 폭발적이다.
      2. 웹은 이질적이다.
      3. 서버 메모리에 아무리 돈을 쏟아부어도 메모리는 부족하다.
      4. 버전을 관리할 수가 없다.
      5. 보안… 좀 몰래 들여다보지 좀 마라.
      6. 지금까지 개발된 COM 은 어떻게 할 것인가? 상호운용 되어야 한다.

지금 생각나는 것은 이 정도 입니다. 아래 설명은 위 사항들에 대한 부연 설명입니다.
읽기 귀찮으신 분은 걍 넘어가셔도 됩니다.(나 같은 단무지-단순무식 같은 사람들은 이런 장문은 읽기 귀찮다. 그런데 또 쓰자니… 읽는 사람 생각 안하고 길게 쓰게 되더라… ^^;)

1. 사용자들의 요구사항은 폭발적이다.

기술 교과서에서 본 집채 만한 컴퓨터가 나오기 전부터 항상 요구 사항과 문제점은 발생했을 것이고, 그 요구 사항들과 문제점을 개선되기 위해서 Hardware와 Software 의 기술은 계속해서 발전을 거듭했습니다.
거대한 계산기에서 personal 컴퓨터로 발전을 하고 그런 하나의 단세포생물 아메바와 같던 개인의 desktop 은 서로 얽히고 설키며 Network 으로 연결되어 이젠 인터넷은 사람들의 생활 깊숙이 자리 잡았습니다.
desktop 뿐입니까? 우리 주위의 모든 기기들(휴대폰, 냉장고, 아파트마저도-기계는 아니지만…)은 모두 network 에 연결되어 사람들을 거미줄로 꽁꽁 묶어버리려 하고 있습니다. (컬럼쓰냐? ㅡㅡ;;;)
되지도 않는 말주변으로 이런 이야기를 하는 이유는 우리 생활이 점점 더 발전을 하면서 발생되는 사람들의 요구 사항들이 기하급수적으로 늘어나는 것을 이야기 하기 위해서 입니다.
사람들은 주위에 널려져 있는 network 을 사용하고 싶어할 것이고 모든 일을 network 을 통해서 쉽고 빠르게 해결하려 할 것입니다. 사용자들이 사용하는 그 많은 데이터들을 처리하기 위해 Hardware 또한 발전할 것이고 처리속도와 처리량은 기하급수적으로 늘어날 것입니다. 또 network 을 사용하면서 언제 어디서나 내가 원하는 곳에 연결할 수 있지만, 반대로 악의의 사용자에 의해 그 정보가 노출되기를 원하지는 않습니다. 이런 요구 사항은 기술의 발전을 낳고 개발자에겐 새로운 꼼수를 만들게 합니다. (고로 꼼수도 기술이다. 라고 말할 수 있을까? ㅋㅋㅋ)
정보를 처리하기 위해서 개발자들은 자신이 개발하는 데있어서 효율적인 언어를 선택해야 했고 다른 개발자들이 사용하는 언어를 폄하하기도 했습니다. (아직도 그렇지… java가 쵝오야! vb는 thread 기능을 사용할 수 없어! VB는 쥐나 개나 다해! ㅡㅡ; 내가 쥐, 개란 말인가? )
세상의 개발자들이 꼼수로 처리할 수 있는 정보의 양은 한정되어있었고 그런 꼼수를 줄이기 위한 여러가지 기술들이 나타나게 됩니다.

2. 웹은 이질적이다.

그 중에 하나가 MS 에 의해 명명된 대표적인 기술 COM 입니다. (이미 알려진 기술을 멋진? 단어로 재 생산하지 않는가? 마치 자신이 탄생시킨 것처럼… 하긴 Windows 진영만을 이야기 한다면 그 말도 맞지 않을까?. ^^)
이제 COM을 사용하면 개발자들은 처음부터 개발할 필요가 없어졌습니다. 획기적이지 않습니까? third party 에서 만들어 놓은 컨트롤을 사다가 내가 작성한 logic 과 연결만 시키면 됩니다. 그 제품의 내부가 어떻게 구현되어있는지 알 필요도 없습니다.(우린 발생하는 버그에 제품을 욕하기도 한다… 어떤 때는 버그에 못견디고 인터넷을 뒤져 컨트롤을 만들어 버리곤 하지..ㅡㅡ;)
우리의 친구 visual Basic은 COM 의 상승세를 타고 무한히 발전하는 듯 보였습니다. (요놈만이라도 잘해보좌~~)
잔머리도 많이 줄어드는 듯 했습니다. (사실 많이 줄었다. ㅡㅡ)
하지만 이러한 환상적인 COM 도 문제점을 가지고 있었다.
두가지나 된다고 합니다. (완벽한 줄 알았던 넘인데…)
한가지는 COM은 각각이 떨어져 있는 클라이언트/서버에서 동작한다는 것(최소한 얼마라도…)과 COM 의 내부 구현을 공유하는 것이 아니라 인터페이스를 통해 서로 통신한다는 점입니다. 그렇기 때문에 COM 간의 통신을 위해서 특정 메카니즘을 구현하고 있어야 하고, COM 인터페이스는 구현하는 Language(VB, C++) 에 따라서도 다르다는 단점을 가지고 있습니다.
그래서 VB 로 제작된 COM을 C++에서 사용한다거나 C++로 만든 COM 혹은 JAVA 로 제작된 CORBA 를 사용하기 위해서는 별도의 Mapping? 을 통해서 그 차이점을 줄이기 위해 별도의 작업이 필요합니다.
이런 작업들로 더? 많은 작업들을 추가로 하고 있습니다 (배보다 배꼽이 크다면… ㅡㅡ; 포기하고 같은 언어로 하시죠 라고 말한다. ㅡㅡ)
우리 개발자들.. 특히 우리는 이 세상 많은 사용자들이 모두 windows 만 사용했으면 좋겠다고 생각할 것이다. (아니 windows 가 아니라 linux 라도 좋다. 제발 하나만 써다오.)
(위를 보니 너무 많이 썼다. 아래 내용은 아시는 내용이 많을테니… 양을 줄이련다. ㅡㅡ;)

3. 서버 메모리에 아무리 돈을 쏟아부어도 메모리는 부족하다.

우리 서버는 많은 사용자들이 요구하는 수많은 데이터를 처리하느라 늘 바쁩니다.
그런 서버에게 개발자는 친절히 메모리 할당과 해제를 친절히 능숙하게 해야 하는 기본적인 의무를 가지고 있음에도 불구하고… 잠시 음주 코딩으로, 졸음 코딩으로 의무를 다하지 못하는 상황이 간혹 발생합니다. 그로 인해 서버의 메모리 누수는 계속 발생하여 종래에는… “수고하셨습니다~~.” 서버를 다시 켜야 하며 이런 상황이 발생하지 않더라도 서버관리자는 추후에 발생할지도 모르는 서버의 살해 사건 방지를 위해 주기적으로 부팅시켜주는 일을 하고 있습니다.

4. 버전을 제대로 관리할 수가 없다.

우리가 프로그램을 제작을 하게 되면 배포 version 을 제작하는 그 순간부터 발생하는 버그를 수정하게 되고 곧 새로운 version 의 프로그램을 제작하여 Patch 하거나 새 제품을 출시하게 되는데 이 때 이전 버전의 제품과 호환을 될 수 있도록 또 하나의 작업을 합니다. 그리고 버전 관리를 위해 표준 메카니즘이 필요합니다.
(게다가 COM 의 문제점인 DLL Hell 도 한몫 거들고 있다.- version 이야기 하니까 갑자기 생각나네…)

5. 보안… 좀 몰래 들여다보지 좀 마라.

우리는 최근 인터넷을 통해서 많은 일을 하게 되었습니다. 업무를 보고, 인터넷 뱅킹을 통해 현금을 송금하고, 물건을 구입하고 게임도 하죠. 이때 보안은 필수적인 것이 될 것입다.
우리가 browser 를 통해 설치하는 ActiveX 컨트롤은 그 힘이 막강하여 한번 깔리게 되면 내 PC 를 내어주는 것이나 다름 없이 모든 권한들 가지고 내 PC를 제어?할 수 있습니다. 이 것은 사용자에게 편리하긴 하지만 그리 좋은 상황은 아닙니다. 그런 프로그램은 하는 역할에 합당한 권한이 주어져야 하기 때문이죠. 특정 파일에 접근하여 쓰지는 못하되 읽을 수만 있게 하도록 설정할 수 있는 방법이 필요합니다.

6. 지금까지 개발된 COM 은 어떻게 할 것인가? 상호 운용되어야 한다.

우리는 그 동안 환상적이었던(아직도 환상적이기는 한) COM을 많이도 만들었습니다. (내가 만든 것 또한 Test 프로그램을 포함해서 너무 많이 만들지 않았나? ^^;)
이런 COM 을 일시에, 한번에, 무자비하게 다 없애 버릴 수 있을까요?
함께 써야 합니다… 내가 만든 COM 을 사용할 수 있어야 합니다.
비싼 돈주고 산 third party control 들을 이젠 못쓰니 다른 버전으로, 또는 다른 제품으로 사달라고 하면 어떤 사장님이 좋아할까요? 계속 불평하는 당신 대신 기존에 산 third party control 을 쓸 수 있는 사람을 구할 수도 있지 않을까요? ^^;

지금까지 위에서 생각난대로 정리한 문제점 6가지 내용에 대해 긴 글을 정리해봤습니다.
다음은 위 문제점들을 해결하기 위해 나온 .NET 에 대한 이야기를 해보겠습니다.

 

행복한 고수되십시오.

WooGong ))*
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

출처: https://www.jumptovb.net/tag/.NET?page=9 [Jump To VB.NET:티스토리]