프로그래머의 길을 택한 후에는 요청과 함께 리소스를 소비하기 시작하는 사람이 바로 자신임을 이해해야 합니다. 값비싼 함수를 호출 한다고 해서 "자원 작업이 실제로 어떻게 작동합니까?"라는 질문을 끌 수 있다는 의미는 아닙니다.
여기 포럼에 전체 코드를 게시하는 것이 가장 좋습니다. 그러면 문제 지점이 즉시 드러날 것입니다. 여기에서 불가능한 경우 서비스 데스크에서 가능합니다(코드는 확인 후 삭제됨).
추신: 운영 체제에서 메모리가 충분하지 않다고 표시할 때 우리는 질문을 하지 않으며 이에 대해 Microsoft를 비난하지 않습니다.
그래도 예전에 자제했던 내용을 적어보겠습니다.
예, 후크 또는 사기꾼을 통해 제품 판매를 늘리고 이익을 늘리는 데 관심이 있는 기업이 있다는 것을 알고 있습니다. 예를 들어 카르텔이 있습니다. 그리고 소문에 따르면 오래 참는 OS를 느리게 하는 주기적 소프트웨어 치트로 유명한 Microsoft는(사실입니다) 하드웨어 거물과 거의 영구적으로 공모 상태에 있습니다. Unix 플랫폼이나 오래된 Windows에서 여전히 작동하는 오래되고 작동하는 제품을 대체하기 위해 새로운 값비싼 Windows 소비자용 제품을 빠르게 판매하고 있습니다.
그래서 내 요점이 무엇입니까? MQ가 나를 쇠바늘에 꿰고 마지막 속옷을 남기고 싶지 않다는 느낌을 주지 않았다는 사실에. MT4와 MT5는 특히 상대적으로 새로운 유비쿼터스 투박한 .NET Framework 애플리케이션을 배경으로 수년 동안 항상 적절한 인터페이스 응답성과 유용성을 제공했습니다. 따라서 이것으로 모든 것이 순서대로 이루어지며 앞으로 우리가 원하는 것입니다. 우리가 도덕적으로, 지적으로, 재정적으로 무엇을 준비하고 있는지 알 수 있도록 새로운 빌드에 대한 포괄적인 정보, 변경된 최소 요구 사항에 대한 정보 등을 수반하는 것이 중요합니다.
종속 개발자가 기본 개발자에 대한 비난과 관련하여 다른 모든 것에 대해: Microsoft는 대안 없이 업데이트를 강요하지 않습니다. 어떤 이유로 자동 업데이트를 비활성화할 수 없습니다. 하도록 하다...
누군가 잘못된 데이터를 보내고 있습니다. 그 전에는 0으로 나누기 때문에 에이전트가 조용히 충돌했습니다(당신은 눈치채지 못했을 뿐입니다). 이 0 으로 나누기 는 원칙적으로 존재하지 않아야 하기 때문에 해당 확인이 없었습니다. 이 사람은 공격자가 아닐 수 있으므로 서비스 데스크에서 그 사람의 지원을 기다리고 있습니다. 이 오류를 직접 재현할 수 없습니다.
Renat 은 일반적으로 32비트 버전의 문제가 남아 있었지만 처음으로 MT5의 x64 버전에서 코드를 테스트할 기회가 있었습니다. 그리고 등장한 것은...
32비트 버전의 터미널에서 발생하는 오류는 없었지만 그래픽 마크업의 불완전한 기본(즉, 수동으로 다른 시간 프레임으로 전환하기 전) 그리기 및 일부 개체의 앵커 포인트가 보조 표시기 그래픽 시리즈의 변위와 함께 극한값. 마지막 순간까지 나는 ServiceDesk에 대한 열렬한 연설을 준비하고 있었지만 수십 번의 터미널 실행 후(심지어 컴퓨터의 여러 번의 완전한 재부팅을 고려하더라도) 모든 것이 기적적으로 안정화되었습니다. 나는 이 모든 것의 논리를 알지 못하며 감히 짐작조차 할 수 없지만, 터미널이 이 10번의 다시 시작을 통해 "작동"하고 결국에는 OS에 "익숙해진" 것처럼 느껴집니다. 또는 터미널에 대한 표시기. 네, 신비롭게 들립니다. 논리적으로는 그렇지 않습니다. 유일한 "조정"은 기록의 완전한 다운로드, 사용된 시간 프레임의 캐싱, 터미널 옵션의 미세 수동 조정, 그리고... 모두. 그러나 이 모든 것은 첫 번째 출시에서 수행되었으며, 터미널의 후속 출시는 두 번째 출시와 상태가 다르지 않았습니다(마지막 기록의 작은 이력서와 차트에 뉴스 플래그를 추가하는 것은 관련이 없으므로 우리는 ' t 이것을 고려하십시오).
나는 약간의 당혹감에 빠져 있습니다. 나는 왜곡이 반쯤 갑자기 나타날 것이라고 믿습니다. 그런 다음 처리 할 것입니다. 그러나 이것은 곧이 아니라 현재로서는 계획된 코드 최적화입니다. 순전히 코드를 테스트하는 것이 흥미로울 경우 다시 길을 잃기 전에 알려주십시오.
Renat : "기적적으로 안정화됨"이라는 말은 전체 스토리가 펌핑된다는 것을 의미합니까? 따라서 이것은 예상됩니다. 기록은 필요에 따라 펌핑되며 시간이 걸릴 수 있습니다.
히스토리 카탈로그를 살펴보고 수백 메가바이트의 히스토리 데이터를 살펴보십시오.
반대의 경우도 마찬가지입니다. 개인의 시각적 통제 하에 처음 시작할 때 전체 히스토리를 다운로드하고 다운로드가 완료된 후 M1 에서 1994년 초로 출발하여 Home 키로 확인합니다. 그런 다음 자주 사용하는 시간 프레임과 다중 시간 프레임 표시기와 관련된 시간 프레임을 수동으로 건너뛰고 형성될 때까지 기다렸다가 터미널을 다시 시작합니다. 모든 것.
새로운 기록 데이터의 후속 작은 이력서는 근본적인 효과가 없습니다. 즉, 이론적으로 터미널은 첫 번째 실행이 끝날 때 기록이 완전히 로드된 후 또는 신뢰성을 위해 맨 처음에 "안정화된" 것으로 간주될 수 있습니다. 두 번째 실행의 경우 생성된 비 M1 시간 프레임. 그러나 이것은 이론적입니다. 어떤 이유로 든 열 번째 광고를 다시 시작할 때 모든 것이 나에게 안정되었습니다 (표시기의 올바른 작동에 대해 이야기하고 있습니다). 강조하지만 처음에는 메인 스토리가 이미 다운로드되었으며 후속 다운로드는 불가능해야합니다. 날씨를 원칙적으로 만들기 위해 ... 나는 반대 말을 할 수도 있습니다. 기록이 발사에서 발사까지 길어질수록 표시기가 그것을 삼키지 않고 일부 발사에서 충돌 할 위험이 높아지지만 실제로는 모든 것이 밝혀졌습니다. 반대의 경우: 더 멀리, 더 적절하게 작동했습니다).
이것은 터미널 또는 MT5 + OS 번들의 사용자 프로세스에 대해 일부 숨겨져 있고 분명하지 않은 부분이 있을 수 있음을 의미하며, 이는 즉시가 아니라 일부 n 번째 조정 후에 운영 환경에서 애플리케이션의 작동을 최적화합니다. 나는 컴파일과 관련하여 오랫동안 내 소스 코드를 수정하지 않았습니다. 새로 설치된 MT5 (이 연구에서 빌드가 항상 동일함)를 처음 시작할 때만 수정했습니다. 첫 출시 이후에는 조정이 없었습니다. 이 모든 미스터리한 상황은 시간이 지남에 따라 자주 호출되는 응용 프로그램을 가장 먼저 사용할 수 있게 된 Windows시작 메뉴 를 상기시켰습니다(OS는 통계를 수집했지만 이는 시간이 걸리고 동일한 프로그램에 대한 특정 수의 호출이 필요함). 또는 디스크에 있는 파일의 조각 모음을 통해 파일에 대한 액세스가 최적화되고 응용 프로그램이 더 빨리 시작됩니다. 이는 모두 동일한 오페라에서 나온 것입니다.
나는 당신이 MT5 에서 비슷한 것을 구현했다고 믿지 않습니다. 그렇지 않으면 스스로 보고했거나 포럼에서 이에 대한 질문으로 오래 전에 추월당했을 것입니다. 따라서 이 모든 것은 경험에 근거한 확인되지 않은 가설에 불과합니다.
프로그래머의 길을 택한 후에는 요청과 함께 리소스를 소비하기 시작하는 사람이 바로 자신임을 이해해야 합니다. 값비싼 함수를 호출 한다고 해서 "자원 작업이 실제로 어떻게 작동합니까?"라는 질문을 끌 수 있다는 의미는 아닙니다.
여기 포럼에 전체 코드를 게시하는 것이 가장 좋습니다. 그러면 문제 지점이 즉시 드러날 것입니다. 여기에서 불가능한 경우 서비스 데스크에서 가능합니다(코드는 확인 후 삭제됨).
추신: 운영 체제에서 메모리가 충분하지 않다고 표시할 때 우리는 질문을 하지 않으며 이에 대해 Microsoft를 비난하지 않습니다.
그래도 예전에 자제했던 내용을 적어보겠습니다.
예, 후크 또는 사기꾼을 통해 제품 판매를 늘리고 이익을 늘리는 데 관심이 있는 기업이 있다는 것을 알고 있습니다. 예를 들어 카르텔이 있습니다. 그리고 소문에 따르면 오래 참는 OS를 느리게 하는 주기적 소프트웨어 치트로 유명한 Microsoft는(사실입니다) 하드웨어 거물과 거의 영구적으로 공모 상태에 있습니다. Unix 플랫폼이나 오래된 Windows에서 여전히 작동하는 오래되고 작동하는 제품을 대체하기 위해 새로운 값비싼 Windows 소비자용 제품을 빠르게 판매하고 있습니다.
그래서 내 요점이 무엇입니까? MQ가 나를 쇠바늘에 꿰고 마지막 속옷을 남기고 싶지 않다는 느낌을 주지 않았다는 사실에. MT4와 MT5는 특히 상대적으로 새로운 유비쿼터스 투박한 .NET Framework 애플리케이션을 배경으로 수년 동안 항상 적절한 인터페이스 응답성과 유용성을 제공했습니다. 따라서 이것으로 모든 것이 순서대로 이루어지며 앞으로 우리가 원하는 것입니다. 우리가 도덕적으로, 지적으로, 재정적으로 무엇을 준비하고 있는지 알 수 있도록 새로운 빌드에 대한 포괄적인 정보, 변경된 최소 요구 사항에 대한 정보 등을 수반하는 것이 중요합니다.
종속 개발자가 기본 개발자에 대한 비난과 관련하여 다른 모든 것에 대해: Microsoft는 대안 없이 업데이트를 강요하지 않습니다. 어떤 이유로 자동 업데이트를 비활성화할 수 없습니다. 하도록 하다...
그래도 예전에 자제했던 내용을 적어보겠습니다.
서비스 데스크에서 애플리케이션을 만드는 데 5분도 채 걸리지 않습니다. 그리고 아마도 바로 다음 날 우리는 구체적인 답변을 받았을 것입니다.
그러나 Renat와 함께 사용자에 대한 Microsoft의 음모에 대해 논의하는 것을 선호합니다.
그 후에 정말 문제가 있다고 말하지 마십시오 ;)
최신 빌드에 대한 자동 업데이트 후 원격 에이전트가 떨어지기 시작했습니다.
누군가 잘못된 데이터를 보내고 있습니다. 그 전에는 0으로 나누기 때문에 에이전트가 조용히 충돌했습니다(당신은 눈치채지 못했을 뿐입니다). 이 0 으로 나누기 는 원칙적으로 존재하지 않아야 하기 때문에 해당 확인이 없었습니다. 이 사람은 공격자가 아닐 수 있으므로 서비스 데스크에서 그 사람의 지원을 기다리고 있습니다. 이 오류를 직접 재현할 수 없습니다.
UPD
나는 갑자기 로그 라인을 보았다
이는 에이전트가 실제로 원격 에이전트로 사용되었음을 나타냅니다. 즉, 문제의 원인을 알고 있습니다. 서비스 데스크와 통화하고 싶습니다
뭐
2012.12.19 21:33:50 Core 01 2004.04.02 20:15:00 0x0000000000000009에 접근 위반 쓰기
전략 백테스트 중에 발행됩니다.
뭐
2012.12.19 21:33:50 Core 01 2004.04.02 20:15:00 액세스 위반 0x0000000000000009에 쓰기
전략 백테스트 중에 발행됩니다.
서비스 데스크에 메시지를 보내는 동안 오류가 발생했습니다.
Renat 은 일반적으로 32비트 버전의 문제가 남아 있었지만 처음으로 MT5의 x64 버전에서 코드를 테스트할 기회가 있었습니다. 그리고 등장한 것은...
32비트 버전의 터미널에서 발생하는 오류는 없었지만 그래픽 마크업의 불완전한 기본(즉, 수동으로 다른 시간 프레임으로 전환하기 전) 그리기 및 일부 개체의 앵커 포인트가 보조 표시기 그래픽 시리즈의 변위와 함께 극한값. 마지막 순간까지 나는 ServiceDesk에 대한 열렬한 연설을 준비하고 있었지만 수십 번의 터미널 실행 후(심지어 컴퓨터의 여러 번의 완전한 재부팅을 고려하더라도) 모든 것이 기적적으로 안정화되었습니다. 나는 이 모든 것의 논리를 알지 못하며 감히 짐작조차 할 수 없지만, 터미널이 이 10번의 다시 시작을 통해 "작동"하고 결국에는 OS에 "익숙해진" 것처럼 느껴집니다. 또는 터미널에 대한 표시기. 네, 신비롭게 들립니다. 논리적으로는 그렇지 않습니다. 유일한 "조정"은 기록의 완전한 다운로드, 사용된 시간 프레임의 캐싱, 터미널 옵션의 미세 수동 조정, 그리고... 모두. 그러나 이 모든 것은 첫 번째 출시에서 수행되었으며, 터미널의 후속 출시는 두 번째 출시와 상태가 다르지 않았습니다(마지막 기록의 작은 이력서와 차트에 뉴스 플래그를 추가하는 것은 관련이 없으므로 우리는 ' t 이것을 고려하십시오).
나는 약간의 당혹감에 빠져 있습니다. 나는 왜곡이 반쯤 갑자기 나타날 것이라고 믿습니다. 그런 다음 처리 할 것입니다. 그러나 이것은 곧이 아니라 현재로서는 계획된 코드 최적화입니다. 순전히 코드를 테스트하는 것이 흥미로울 경우 다시 길을 잃기 전에 알려주십시오.
히스토리 카탈로그를 살펴보고 수백 메가바이트의 히스토리 데이터를 살펴보십시오.
"기적적으로 안정화됨"이라는 말은 전체 스토리가 펌핑된다는 것을 의미합니까? 따라서 이것은 예상됩니다. 기록은 필요에 따라 펌핑되며 시간이 걸릴 수 있습니다.
히스토리 카탈로그를 살펴보고 수백 메가바이트의 히스토리 데이터를 살펴보십시오.
반대의 경우도 마찬가지입니다. 개인의 시각적 통제 하에 처음 시작할 때 전체 히스토리를 다운로드하고 다운로드가 완료된 후 M1 에서 1994년 초로 출발하여 Home 키로 확인합니다. 그런 다음 자주 사용하는 시간 프레임과 다중 시간 프레임 표시기와 관련된 시간 프레임을 수동으로 건너뛰고 형성될 때까지 기다렸다가 터미널을 다시 시작합니다. 모든 것.
새로운 기록 데이터의 후속 작은 이력서는 근본적인 효과가 없습니다. 즉, 이론적으로 터미널은 첫 번째 실행이 끝날 때 기록이 완전히 로드된 후 또는 신뢰성을 위해 맨 처음에 "안정화된" 것으로 간주될 수 있습니다. 두 번째 실행의 경우 생성된 비 M1 시간 프레임. 그러나 이것은 이론적입니다. 어떤 이유로 든 열 번째 광고를 다시 시작할 때 모든 것이 나에게 안정되었습니다 (표시기의 올바른 작동에 대해 이야기하고 있습니다). 강조하지만 처음에는 메인 스토리가 이미 다운로드되었으며 후속 다운로드는 불가능해야합니다. 날씨를 원칙적으로 만들기 위해 ... 나는 반대 말을 할 수도 있습니다. 기록이 발사에서 발사까지 길어질수록 표시기가 그것을 삼키지 않고 일부 발사에서 충돌 할 위험이 높아지지만 실제로는 모든 것이 밝혀졌습니다. 반대의 경우: 더 멀리, 더 적절하게 작동했습니다).
이것은 터미널 또는 MT5 + OS 번들의 사용자 프로세스에 대해 일부 숨겨져 있고 분명하지 않은 부분이 있을 수 있음을 의미하며, 이는 즉시가 아니라 일부 n 번째 조정 후에 운영 환경에서 애플리케이션의 작동을 최적화합니다. 나는 컴파일과 관련하여 오랫동안 내 소스 코드를 수정하지 않았습니다. 새로 설치된 MT5 (이 연구에서 빌드가 항상 동일함)를 처음 시작할 때만 수정했습니다. 첫 출시 이후에는 조정이 없었습니다. 이 모든 미스터리한 상황은 시간이 지남에 따라 자주 호출되는 응용 프로그램을 가장 먼저 사용할 수 있게 된 Windows 시작 메뉴 를 상기시켰습니다(OS는 통계를 수집했지만 이는 시간이 걸리고 동일한 프로그램에 대한 특정 수의 호출이 필요함). 또는 디스크에 있는 파일의 조각 모음을 통해 파일에 대한 액세스가 최적화되고 응용 프로그램이 더 빨리 시작됩니다. 이는 모두 동일한 오페라에서 나온 것입니다.
나는 당신이 MT5 에서 비슷한 것을 구현했다고 믿지 않습니다. 그렇지 않으면 스스로 보고했거나 포럼에서 이에 대한 질문으로 오래 전에 추월당했을 것입니다. 따라서 이 모든 것은 경험에 근거한 확인되지 않은 가설에 불과합니다.