도와 주세요.:루아 디버깅

WP: 루아 (talk) 도와 주세요. 하기 위해서 자원. 참조 매뉴얼

이 도움말 페이지의 도움말:Lua 디버깅은 오류를 제거하거나 성능을 향상시키기 위해 Lua 스크립트를 작성하고 소스 코드를 디버깅하는 문제를 설명합니다.Lua는 "반 컴파일된" 해석 언어이기 때문에 "스크립트 오류" 메시지를 볼 때 런타임에서만 발견되는 모든 일반적인 구문 오류에 대해 사전 스크리닝하지 않으며 철자가 잘못된 변수도 탐지하지 않습니다.또한 편집 미리보기를 통해 대화식으로 실행할 수 있는 wp:template와 달리 Lua 스크립트는 다음과 같은 템플릿을 사용하는 다른 페이지의 show-preview(또는 미리보기 실행)를 통해 테스트해야 합니다.#invoke편집 중인 Lua 모듈.일반적으로 한 번에 하나씩 작은 변경을 하고 show-preview를 실행한 후 저장하여 나중에 여러 번 변경한 후에 심각한 오류가 발생할 경우에 대비하여 복원할 버전을 확보합니다.참고: 작업 복사본을 모듈 수정본에 저장하는 대신 오프라인 텍스트 파일에 저장할 수 있습니다.

사전 컴파일되거나 반 컴파일된 다른 언어는 구문 오류 또는 정의되지 않은 변수 이름이 탐지된 줄 번호 또는 코드 구문을 정확히 지정할 수 있지만, 이 처리를 수행하려면 추가 시간이 필요할 수 있습니다.대신 Lua 스크립트에 대한 어휘 분석 도구를 사용하여 Lua 소스 코드에서 철자가 틀린 변수나 논리 오류를 더 잘 감지하고 정확하게 파악할 수 있습니다.

Lua 모듈에 대한 라이브 변경 사항은 편집 중에 템플릿/모듈을 사용하는 페이지의 "미리 보기 표시"를 위해 템플릿/모듈에 대한 새 미리 보기 옵션을 사용하여 실행 미리 보기로 테스트할 수 있습니다.그렇지 않으면 Lua 모듈을 대화형으로 실행하여 결과를 확인할 수 없습니다. 이 기능은 마크업 기반 템플릿에서만 사용할 수 있습니다.대신, Lua 모듈은 일반적으로 편집, 저장 및 실행(호출 템플릿에 의해)되어 편집-저장 중에 구문 오류가 세미컴파일에 의해 발견될 수 있는지 확인합니다.실행 미리보기는 단순한 구문 오류를 보고하지 않지만 모듈을 라이브로 편집한 다음 호출자 페이지의 "미리보기 표시"를 선택하여 결과를 보거나 실행 미리보기 중에 "스크립트 오류"가 발생한 경우 편집 내용을 실제로 저장하기 전에 여러 번 확인할 수 있습니다.그러나 편집 내용을 저장하면 일부 반컴파일 메시지를 볼 수 있으므로 쇼 미리보기 중에 보고되지 않는 "그럼" 중복과 같은 간단한 구문 오류를 확인할 수 있습니다.

Lua 모듈이 다른 페이지에서 실행될 때 "스크립트 오류" 메시지를 트리거하는 이유는 여러 가지가 있을 수 있습니다.오류 텍스트를 클릭하면 Lua에서 생성한 실제 오류 메시지가 포함된 팝업이 표시됩니다. 이 팝업은 검색 엔진에서 메시지의 의미와 일반적인 해결 방법에 대한 자세한 설명과 오류를 실제로 트리거한 코드 부분을 확인하는 데 도움이 되는 스택 추적을 찾을 수 있습니다.

그러나 일부 오류는 다른 오류보다 더 일반적입니다.

• 빈 문자열의 연결이 잘못되었습니다. my_str = my_str .. "xx"문자열 연결 작업 내에서 사용할 경우 'my_str'이라는 문자열은 0이 아니어야 합니다.
• "가 아닌 "+"에 의한 연결이 잘못되었습니다.연산자: my_str = my_str + "z"연결 연산자는 이중 점 "."이며 더하기 기호 "+"를 사용하려고 하면 편집-저장 사전 컴파일 중에 통과할 수 있지만 Lua 스크립트의 해당 부분이 실행되면 "스크립트 오류"를 누릅니다.
• 잘못된 함수 이름: len = string.long(my_str)문자열 길이 연산자는 해시 마크 '#'입니다(다음과 같이).#my_str), 또는 '함수를 사용합니다.string.len(my_str)알 수 없는 기능을 사용하려고 합니다.'string.long(my_str)편집-저장의 사전 컴파일 중에는 성공적으로 통과되지만 Lua 스크립트의 해당 부분이 실행되면 "스크립트 오류"에 도달합니다.

"스크립트 오류"의 다른 원인은 여러 가지가 있지만 항상 해당 시점에서 프로그램을 중지할 수 있는 설정되지 않은 초기화되지 않은 변수가 있을 가능성을 찾습니다.

한 번에 너무 많은 오류가 발생하는 것을 방지하기 위해 일반적인 전략은 한 번에 "작은 변경"을 수행하고 show-preview를 실행한 후 테스트된 버전을 저장하여 나중에 여러 번 변경한 후에 심각한 오류가 발생할 경우에 대비하여 복원할 안정적인 버전을 확보하는 것입니다.참고: 각 작업 복사본을 Wikipedia 모듈 수정본에 저장하는 대신 오프라인 텍스트 파일 집합에 저장할 수 있습니다. 각 파일은 특정 버전 이름(및 내부 주석)을 사용합니다.

단순 검토

모듈의 단일 지점에서 변수 값을 보려면 다음과 같이 하십시오.

코드를 수정하여 변수 값을 확인하는 방법

그error()함수는 모듈의 임의의 지점에서 변수의 값을 표시하는 데 사용될 수 있습니다.변수의 값을 알기 위해var코드의 특정 지점에 라인을 추가합니다.error(var)그 시점에서

변수가 테이블인 경우(변수를 호출합니다.)tab),mw.dumpObject(tab)표를 표시하는 데 사용할 수 있습니다.변수에 내포된 표가 없는 경우table.concat(tab, ',')의 매개 변수로도 사용할 수 있습니다.error()함수, 즉.error(table.concat(tab, ',')).

코드를 변경하지 않고 변수 값을 확인하는 방법

함수에서 반환되는 변수와 값을 얻기 위해(두 경우 모두 로컬이 아님) "디버그 콘솔"을 사용할 수 있습니다."디버그 콘솔"은 편집 모드일 때 모듈 페이지 아래에 나타납니다.그리고나서mw.log,mw.logObject,그리고.=사용할 수 있습니다.다음 예제에서 유용성을 살펴보겠습니다.

현지의 p = {} p.안녕하세요. = '안녕하세요' 기능. p.석회질의(번호)    돌아가다 번호 끝. 기능. p.합_곱(번호)    돌아가다 번호 + 번호, 번호 * 번호 끝. 기능. p.마운트 테이블(번호)    돌아가다 {번호, 번호+1} 끝. 돌아가다 p 

"디버그 콘솔"에 대한 요청:

테이블#1 { :4, :5, } 

모듈에서 사용해 보십시오.루아 디버깅의 예.디버그 콘솔은 요청을 저장하지 않으며, 각 모듈 수정 시 요청을 다시 복사하거나 다시 작성해야 합니다.

여러 지점의 흐름 및 변수 값 검토

모듈의 기능:SimpleDebug는 위에서 언급한 경우와 같은 경우 또는 더 복잡한 경우에 사용할 수 있습니다.

• 변수 또는 함수에 의해 반환된 값(또는 값)이 로컬인 경우.
• 프로그램 흐름이 레이블을 지정할 지점을 통과하는지 확인합니다.
• 루프에서 반환되는 값의 수를 제한하거나 값 등록을 활성화하는 조건을 설정합니다.

경우에 따라 Lua 모듈은 오래된 작업일 수 있으며, 여러 가지 알려지지 않은 문제가 있는 다른 편집자들에 의해 수정될 수도 있습니다.Lua 모듈에는 수많은 논리 오류가 포함될 수 있으며, 모듈이 처음 개발되었을 때 모든 기능에 대해 제대로 테스트되지 않은 경우 철자가 틀린 변수도 포함될 수 있습니다."스크립트 오류" 메시지는 테스트 데이터가 Lua 코드의 잘못된 섹션을 트리거할 때만 발생합니다. 따라서 테스트되지 않은 모듈은 많은 숨겨진 버그를 포함할 수 있으며, 더 넓은 테스트 데이터가 소스 코드의 더 많은 영역을 활성화하거나 더 많은 내부 함수를 사용할 때만 나타납니다.

일반적이고 복잡한 문제는 새로운 기능을 위해 오래된 모듈을 확장하는 것이지만 확장된 기능이 추가될 때만 해결되지 않은 일부 버그가 어떻게 트리거되는지는 알지 못하는 것입니다.오류가 새로 추가된 Lua 스크립트에서가 아니라 새 코드가 Lua 스크립트의 다른 부분을 활성화할 때 이전 섹션에서 트리거(깜짝)되기를 조용히 기다리는 경우가 많습니다.숨겨진 버그는 기본값으로 처리되었던 정의되지 않은(또는 철자가 틀린) 변수 이름만큼 간단할 수 있지만, 새로 추가된 기능과 함께 사용될 때 새로운 코드가 실제로는 오래된 철자가 잘못된 변수가 다른 영역에 있는 것처럼 완전히 신비한 결과를 생성합니다.새 기능의 작동을 완전히 망쳐 놓았습니다.

오래된 버그를 처리하기 위한 전술은 코드 영역을 활성화하기 위해 특별한 추가 테스트 데이터를 실행하거나 새로운 Lua 스크립트가 추가될 수 있는 디버그 디스플레이 출력을 표시하여 영향을 받는 영역이 안전하게 작동하는지 확인한 후 너무 많은 새롭고 상세한 논리를 추가하는 것입니다.대부분의 경우, 오래된 소스 코드의 세부 사항을 검토할 수 있는 인내심 또는 정신적 기억력이 있는 경우 "교정은 테스트의 가장 빠른 형태입니다."에 유의하십시오.그러나 다른 전술은 특정 테스트 데이터 값을 예약하여 관련된 모든 데이터의 값을 화면에 덤프하는 디버그 디스플레이 코드를 트리거하거나 논리가 예상대로 다양한 함수 섹션으로 흐르도록 호출 트리 목록을 제공하는 것입니다.대부분의 경우 인간 메모리는 5-9 변수 이상의 세부 사항을 처리할 수 없으므로 디버깅 출력 명령문을 Lua 모듈에 쓰는 데 필요한 추가 시간에도 불구하고 디버그 디스플레이가 더 쉬운 옵션이 됩니다.일단 새로운 루아 스크립트가 광범위하게 추가되면 문제가 이전 루아 스크립트의 기존 버그가 아닌 "모든 새로운 것"에 의해 발생했는지 여부가 수수께끼 같은 추측 게임이 될 수 있기 때문에 천천히 진행하도록 주의하십시오.

영어 위키백과에는 템플릿 샌드박스 확장이 설치되어 있습니다.Lua 모듈을 글로벌 공간으로 이동하기 전에 개인(즉, 사용자 공간) 페이지에서 Lua 모듈을 개발하고 수정할 수 있는 "템플릿 샌드박스"와 "Critunto" 확장 사이에는 시너지 효과가 있습니다.

"Template Sandbox"를 사용하여 Lua 모듈 개발

실용적인 예를 들어 보겠습니다.이 예에서는 사용자 이름이 "Lua Developer"라고 가정합니다.문자열 모듈에 대한 버그 수정 또는 향상된 기능을 테스트하려고 합니다.직접 할 수 없는 두 가지 이유가 있습니다. 이 모듈에는 수백만 개의 기사에 포함된 수백 개의 템플릿에서 사용되는 기능이 포함되어 있습니다.어떤 버그라도 위키백과에 큰 혼란을 초래할 것입니다.두 번째 이유는 이 모듈이 매우 중요하기 때문에 보호되고 있으며 "Lua Developer" 사용자에게 이 모듈을 수정하는 데 필요한 권한이 없습니다.

따라서 "샌드박스"의 첫 번째 단계는 모듈을 복사하는 것입니다.개인 페이지에 대한 문자열 사용자:Lua 현상액/샌드박스/모듈:끈.이제 우리 개발자는 모듈을 마음껏 편집할 수 있습니다.언제든지 스페셜을 열 수 있습니다.기본 "Sandbox 접두사"를 사용하는 템플릿 Sandbox는 "사용자:Lua Developer/샌드박스".즉, 샌드박스 페이지에서 페이지를 볼 때마다 파서가 템플릿 T 또는 모듈 M을 만날 때마다 "사용자:Lua 현상액/샌드박스/템플릿:T" 또는 "사용자:Lua 현상액/샌드박스/모듈:M"이 존재하며, 존재하는 경우 파서는 "실제" 모듈 및 템플릿 이름 공간 대신 구문 분석된 페이지에 대한 이름을 사용합니다."Sandbox 접두사"에 없는 템플릿 또는 모듈은 적절한 네임스페이스에서 파서에 의해 풀링됩니다.

템플릿 샌드박스에서 개발자는 모든 페이지를 볼 수 있으며 원시 위키 텍스트를 입력할 수 있으며 파서에게 "샌드박스 접두사"로 만든 가짜 템플릿과 모듈을 사용하여 구문 분석을 요청할 수 있습니다.

작은 주의사항:잘못된 경우

위키백과는 페이지 이름 케이싱과 관련하여 약간의 변형이 있습니다. 페이지 이름의 첫 번째 문자를 대문자로 변환합니다. 입력 방법에 관계없이.또한 이를 보완하기 위해 템플릿(트랜스클리어된 경우)과 모듈(호출된 경우)의 첫 번째 문자를 대문자로 변환합니다.그러나 샌드박스에서 "첫 글자"가 더 이상 첫 글자가 아니기 때문에 특수 템플릿 샌드박스를 통해 보는 User: 네임스페이스에 저장된 모듈로 확장되지 않습니다.다음은 실제 예입니다. 실제 모듈의 경우 모듈:문자열, 미디어위키 소프트웨어는 당신이 사용할 수 있습니다.{{#invoke:String replace Hara I am a e}}"Here Iem"(사용해 보십시오)을 반환합니다.또한 사용할 수 있습니다.{{#invoke:string replace Hara I am a e}}동일한 결과를 얻는 방법:

그러나 개발자가 User라는 이름의 페이지를 만든 경우:Lua Developer/sandbox/Module:string. 파서가 "Module:"이라는 페이지를 찾기 때문에 이 모듈을 호출할 수 없습니다.샌드박스 접두사의 "Module:string"이 아닌 "String"이 아닌 "Module:String"으로 이름을 변환하지 않습니다.String"(페이지 이름의 첫 번째 문자만 변환하므로)을 찾을 수 없으므로 주 네임스페이스에서 모듈을 가져오거나(이러한 모듈이 있는 경우) 모듈이 존재하지 않는다고 불평합니다.

Module: 네임스페이스에 저장된 정상적인 사용 중인 모든 모듈에 대해 대/소문자가 올바르게 처리됩니다.

전략의 또 다른 문제로 디버그 디스플레이 섹션을 추가하는 것은 Lua가 빠른 속도로 수백 개의 if 조건을 처리할 수 있기 때문에 마크업 기반 템플릿 실행 속도와 마찬가지로 Lua 코드를 느리게 하지 않습니다.모든 Lua 변수에 대해 추가적인 if-문을 추가하더라도 마크업 템플릿 내에 유사한 if-식을 추가할 경우 템플릿 속도가 약 50% 느려지는 것에 비해 시간이 거의 걸리지 않습니다.Lua 모듈에 많은 디버그 디스플레이 섹션을 추가하거나 변수 값을 확인하여 일반적인 불량 데이터를 탐지할 수 있는 추가 if-문으로 여러 매개 변수 유효성 검사 테스트를 추가할 수 있습니다.

Lua 소프트웨어는 처음에 페이지를 포맷할 때 모든 Lua 코드의 결합된 작동을 위해 10초의 작은 제한 시간으로 구성되었습니다.이에 비해 마크업 기반 템플릿은 60초의 시간 제한(6배 더 높은 시간 제한)이 있으며 서버 속도가 느릴 때 마크업 기반 템플릿은 59초까지 완벽하게 포맷할 수 있지만 템플릿의 Lua 부분은 10초 제한에서 중지됩니다.오류 메시지는 다음과 같습니다.

Lua 'script error': "스크립트 실행에 할당된 시간이 만료되었습니다."

마크업 기반 템플릿과 달리 포맷된 페이지는 추가로 호출된 각 Lua 모듈에 대해 페이지 캐시 복사본에 저장할 텍스트로 "스크립트 오류"를 포함합니다.시간 초과 제한의 위험은 서버 지연 속도가 3-4배 느린 드문 기간 동안 발생하며, 사용 중인 서버에서 3초 Lua 작업이 12초 지속으로 느려질 수 있으므로 수천 명의 독자가 볼 수 있도록 "스크립트 오류"를 형식화된 페이지에 저장하도록 처리를 왜곡할 수 있습니다.

Lua가 갑자기 "너무 피곤해"하고 "스크립트 오류"를 결과 페이지에 저장함으로써 불평하기 시작하는 것처럼 전체적인 노력은 불안정하거나 신뢰할 수 없는 것처럼 보입니다. 여기서 형식화된 텍스트가 대신 예상되었을 것입니다.시간 초과 문제는 다소 드물며, 형식이 지정된 문서에 페이지 내부에 "스크립트 오류" 텍스트가 포함되어 있는 경우 페이지를 약간 편집하여 작은 변경을 수행하여 페이지를 새 Lua 실행으로 강제 교체합니다.

IDE

IDE를 통해 코드를 실행하면 텍스트 강조 기능을 사용하여 구문 오류를 빠르게 발견할 수 있습니다.Lua 텍스트 강조 플러그인을 설치할 수 있는 모든 IDE가 작동해야 합니다.이것은 메모장++(언어 메뉴에서 Lua를 선택한 경우)처럼 간단하거나 Visual Studio Code처럼 전체 기능을 사용할 수 있습니다.

스텝 디버거

단계 디버깅은 코드를 한 번에 한 줄씩 단계적으로 처리하고 변수 위에 마우스를 올려 실행 시 내용을 볼 수 있는 강력한 도구입니다.Lua 단계 디버깅을 쉽게 지원하는 IDE에는 ZeroBrane Studio 및 다양한 디버거 플러그인(Emmy Lua 또는 Lunalysis)이 포함된 IntelliJ IDEA가 있습니다.

레그엑스

Lua는 상위 ReGEx 도구에서 지원되지 않는 고유한 형식의 정규식을 사용합니다.Lua ReGEx를 확인하는 데 사용할 수 있는 도구 중 하나는 GitSpar입니다.TV의 루아 패턴.

아직도 어떻게 진행해야 할지 잘 모르겠으면 위키백과에 다음과 같은 메모를 남겨 주십시오.Lua가 디버깅 도움말을 요청합니다.

• 위키백과: 루아
• 템플릿:위키백과 도움말 페이지 - 다른 항목으로 연결되는 큰 탐색 상자