서버 파이프가 터미널에 있는 이유를 완벽하게 이해합니다. 중재를 위해 터미널을 통합하는 하나의 작업에 대해서만 (다른 모든 것은 변명 일뿐입니다). 그러나 이것은 우리의 범위에 속하지 않습니다.
프로세서 간 교환을 정말로 원하는 사람은 다채널 파이프 서버를 간단히 구현할 수 있습니다. 하지만 시장에서 팔 수는 없지만 이것이 추구하는 목표입니다.
당신은 만 잘못되었습니다.
차익 거래, 복사기, 믹서(이는 시장에서 구입한 여러 Expert Advisors를 실행하여 헤지 포즈를 만드는 경우입니다), ...
바로 지금, 주에게는 GA가 필요했습니다. 하지만 프로그래머의 환상이 무엇을 만들어내는지는 결코 알 수 없습니다.
내 말은, 이것이 새로운 기회로 무엇을 할 수 있는지 예측하는 것은 매우 어렵습니다.
그리고 실제로 (우선순위가 아닌 것처럼) 예측할 필요가 없습니다. 사람들은 필요로 하고,
보안을 확인했다면 기회를 주지 않겠습니까?
모든 확장이 적용된 언어의 장점이라는 것을 완벽하게 이해합니다.
추신
나는 미래에 이해할 수 없는 결정으로 인해 창을 깨는 것을 이해하지만 솔루션에는 이미 "파일"이 있습니다.
그들은 "나사를 때리기" 하나만으로 만족하지 않고 나머지는 모두 점검하고 다시 점검합니다.
문제는 자전거의 발명에 있는 것이 아니라 이미 존재하는 것에 보다 유기적인 솔루션을 제공하는 것입니다.
추신
다음은 가상 파일을 사용하는 또 다른 옵션입니다. 버튼 인터페이스 대신 비트맵 인터페이스를 만들고(둥근 버튼이 있는) 활발하고 멋진 인터페이스를 만들고 이 모든 것을 OpenCL에서 즉석에서 계산합니다. 그래서 적어도 차트에서 TV 뉴스를 방송할 수 있습니다. OpenCL이 어떻게 작동하는지에 대한 예가 있습니다. 한 달 동안 실행하고 나사에 어떤 일이 일어날지 직접 확인하십시오.
자, 그것은 바로 나쁜 숫자였습니다. 메모리에 있는 파일을 요청합니다. 이론적으로 매핑보다 구현하기가 훨씬 쉽고 효율적입니다.
MQL: 보안 대 기능
레나트 , 2013.04.25 15:57
파일을 사용할 필요가 없도록 파이프를 만들었습니다.
효과적인 양방향 의사 소통이 없습니다. 파이프가 작동하지 않습니다. 모두가 이미 이것을 이해했을 것입니다... 메모리에 파일이 있습니까?
그리고 또 다른 질문 - 파이프를 통해 타사 리소스로부터 정보를 받는 코드를 시장에 출시하는 것이 불가능하다는 것을 알고 있습니까?
파일을 사용할 필요가 없도록 파이프를 만들었습니다.
서버 파이프가 터미널에 있는 이유를 완벽하게 이해합니다. 중재를 위해 터미널을 통합하는 하나의 작업에 대해서만 (다른 모든 것은 변명 일뿐입니다). 그러나 이것은 우리의 범위에 속하지 않습니다.
프로세서 간 교환을 정말로 원하는 사람은 다채널 파이프 서버를 간단히 구현할 수 있습니다. 하지만 시장에서 팔 수는 없지만 이것이 추구하는 목표입니다.
당신은 만 잘못되었습니다.
차익 거래, 복사기, 믹서(이는 시장에서 구입한 여러 Expert Advisors를 실행하여 헤지 포즈를 만드는 경우입니다), ...
바로 지금, 주에게는 GA가 필요했습니다. 하지만 프로그래머의 환상이 무엇을 만들어내는지는 결코 알 수 없습니다.
내 말은, 이것이 새로운 기회로 무엇을 할 수 있는지 예측하는 것은 매우 어렵습니다.
그리고 실제로 (우선순위가 아닌 것처럼) 예측할 필요가 없습니다. 사람들은 필요로 하고,
보안을 확인했다면 기회를 주지 않겠습니까?
모든 확장이 적용된 언어의 장점이라는 것을 완벽하게 이해합니다.
추신
나는 미래에 이해할 수 없는 결정으로 인해 창을 깨는 것을 이해하지만 솔루션에는 이미 "파일"이 있습니다.
그들은 "나사를 때리기" 하나만으로 만족하지 않고 나머지는 모두 점검하고 다시 점검합니다.
문제는 자전거의 발명에 있는 것이 아니라 이미 존재하는 것에 보다 유기적인 솔루션을 제공하는 것입니다.
추신
다음은 가상 파일을 사용하는 또 다른 옵션입니다. 버튼 인터페이스 대신 비트맵 인터페이스를 만들고(둥근 버튼이 있는) 활발하고 멋진 인터페이스를 만들고 이 모든 것을 OpenCL에서 즉석에서 계산합니다. 그래서 적어도 차트에서 TV 뉴스를 방송할 수 있습니다. OpenCL이 어떻게 작동하는지에 대한 예가 있습니다. 한 달 동안 실행하고 나사에 어떤 일이 일어날지 직접 확인하십시오.
파일을 사용할 필요가 없도록 파이프를 만들었습니다.
서버 파이프가 터미널에 있는 이유를 완벽하게 이해합니다. 중재를 위해 터미널을 통합 하는 유일한 작업(다른 모든 것은 핑계일 뿐입니다) . 그러나 이것은 우리의 범위에 속하지 않습니다.
프로세서 간 교환을 정말로 원하는 사람은 다채널 파이프 서버를 간단히 구현할 수 있습니다. 하지만 시장에서 팔 수는 없지만 이것이 추구하는 목표입니다.
그러나 한 터미널의 샌드박스 내에서는 어떻습니까? 그리고 순수하게 MQL5의 프레임워크 내에서 dll 없이?
제가 알기로는 단말의 전문가와 테스터의 전문가가 다른 프로세스이기 때문에 메모리 공간에서 단말의 전문가와 테스터의 전문가가 분리되어 있다는 점입니다. 용어와 테스터의 바로 이러한 분리가 그러한 "틈새"의 출현으로 이어진 것 같습니다.
그러나 한 터미널의 샌드박스 내에서는 어떻습니까? 그리고 순수하게 MQL5의 프레임워크 내에서 dll 없이?
제가 알기로는 단말의 전문가와 테스터의 전문가가 다른 프로세스이기 때문에 메모리 공간에서 단말의 전문가와 테스터의 전문가가 분리되어 있다는 점입니다. 용어와 테스터의 바로 이러한 분리가 그러한 "틈새"의 출현으로 이어진 것 같습니다.
테스터의 전문가(물리적으로 다른 컴퓨터 또는 클라우드에서도)는 프레임을 사용 하여 터미널 의 전문가에게 데이터를 보낼 수 있습니다 . 즉, 사실은 심연이 없다.
응. 응. (왼쪽 위 눈꺼풀이 미세 진동 모드로 전환됨)
그리고 다시? 실행 시작 시 처리해야 하는 에이전트에 대한 정보(그에게만 해당)를 가져와 실행이 끝날 때 결과를 다시 보내야 합니다.
응. 응. (왼쪽 위 눈꺼풀이 미세 진동 모드로 전환됨)
그리고 다시? 실행 시작 시 처리해야 하는 에이전트에 대한 정보(그에게만 해당)를 가져와 실행이 끝날 때 결과를 다시 보내야 합니다.
응. 응. (왼쪽 위 눈꺼풀이 미세 진동 모드로 전환됨)
그리고 다시? 실행 시작 시 처리해야 하는 에이전트에 대한 정보(그에게만 해당)를 가져와 실행이 끝날 때 결과를 다시 보내야 합니다.
이것은 어렵고 비용이 많이 듭니다(특히 클라우드에서). 가능하지만.
우리가 할 때까지.
간단히 말해서 표준 테스터가 설정하지 않은 에이전트 입력 매개변수를 제공합니다.
이것은 어렵고 비용이 많이 듭니다(특히 클라우드에서). 가능하지만.
우리가 할 때까지.
참고로 MQL5 Cloud Network 서버는 정기적으로 하루에 약 5TB, 때로는 10Tb의 트래픽을 생성합니다.
각 에이전트에 도달하는 보장과 함께 이 네트워크에 무제한 사용자 지정 트래픽이 허용되면 네트워크가 매우 좋지 않을 것입니다.