JSL 4.0JSL의 새로운 기능 및 향후 개선 사항에 대해 논의하기 위해 스크립터스 클럽 플랫폼을 사용하는 것이 적절할까요? 이 플랫폼의 목적은 아이디어를 정리하고, 새로운 기능을 알리고, 향후 개선 사항을 홍보하는 것입니다.
판도를 바꾸는 요소들:
멋지고 유용한 새로운 기능:
있으면 좋은 것:
제목: JSL 4.0여러 사용자가 메인 게시물의 목록에 쓰기 권한을 얻을 수 있는지 모르겠습니다.
JMP19에서 가장 마음에 드는 개선 사항은 무엇인가요?
무엇이 빠졌나요?
어떤 접근 방식이 "게임 체인저"로 간주될 수 있을까?
제목: JSL 4.0안녕하세요, Hogi님. JMP19의 새로운 JSL 기능을 강조하는 JMP 요약본이 있나요? 아직 문서를 읽어보지는 않았고, 19.0.01과 이전 버전(17.2 및 18.2)을 비교해보며 테스트하는 중입니다.
추가 기능 빌더에서:
지난 10년 넘게 네트워크 드라이브에 저장된 사용자 지정 아이콘(jpg 등)이 대부분 포함된 애드인 툴바 몇 개를 개발했습니다. 제가 코딩하고 설정한 방식대로라면 JMP 창이 열릴 때마다 JMP가 툴바를 표시해야 했기 때문에 JMP가 해당 아이콘을 모두 가져왔습니다. 문제의 원인을 파악했을 때는 (최대 40개 정도의 스크립트가 있었습니다) JMP 창을 여는 데 몇 초가 걸렸습니다. 1년 후에는 새 스크립트를 가끔씩만 추가했기 때문에 이 문제는 매우 점진적으로 발생했습니다.
이제 JMP19에는 jsl 및 아이콘 파일을 추가 기능의 일부로 자동으로 포함하는 새로운 추가 기능 빌더가 있으므로 사용자가 이를 설치하면 jsl 및 아이콘 이미지가 로컬 홈 폴더로 복사되지만 JMP 사용자(19 이상)가 JMP 설치 시 서버 .jmpaddin 파일에 대한 업데이트를 '확인'하면 추가 기능이 업데이트되었음을 자동으로 감지할 수 있도록 설정했으며 JMP를 다시 시작할 때 업데이트를 설치하라는 메시지가 표시됩니다. 이 프로세스는 이전 방법과 약간 다르지만 완벽한 시기에 완벽한 수정이었습니다... 저는 지난 몇 달 동안 근본 원인을 발견했습니다. 그래서 저에게는 정말 도움이 되었지만 제 경우는 꽤 모호한 것 같습니다. 하지만 이 포럼에서는 그렇게 모호하지 않을 수도 있습니다. 수정을 도와준 JMP 지원팀과 개발자에게 감사드립니다.
감사해요,
마이크
제목: JSL 4.0내가 아는 한 릴리스 노트("모든 세부 정보 포함")는 없습니다.
일반적인 "개요": JMP 새로운 기능 및 릴리스 노트
보안 업데이트에 대한 정보가 있는 이 페이지: https://www.jmp.com/ko/company/trust-center
그래서 여기서 간략한 개요를 제공하는 것이 도움이 될 것이라고 생각했습니다.
모든 의견과 추가 기능에 대한 링크를 환영합니다.
제목: JSL 4.0애드인 -
JMP에 포함된 표준 "AddIn Builder" 외에도 다음을 사용할 수 있습니다(사용해야 함!!!).
추가 기능 관리자 @저스틴_칠튼 -> 이제 Marketplace를 통해: 추가 기능 관리자
https://community.jmp.com/t5/Learn-JMP-Events/Scripters-Club-Managing-Your-JMP-Add-Ins-with-Justin-Chilton/ev-p/887937
JMP19의 새로운 기능: JMP에 직접 포함된 업데이트 확인 기능입니다.
이전 버전에서는 AddIn Manager에서 UpdateCheck.jsl을 통해 비슷한 기능을 설정할 수 있었습니다.
누군가 두 접근 방식의 속도를 비교했나요?
예를 들어, UpdateCheck를 통해 40개의 AddIn 업데이트를 확인하는 것과 새로운 기능을 사용하는 것은 어떻게 다른가요?
새로운 기능은 파일 날짜를 비교하는 건가요? 아니면 일부 내용을 비교하는 건가요?
그런데: @mikedriscoll
흥미로운 개념인데, 이전 개념과 매우 유사합니다.
엔터프라이즈 애드인 관리 전략(2025-US-30MP-2576) @마이크D_앤더슨
제안된 개념의 중요한 차이점은 다음과 같습니다.
스크립트의 "현재" 버전(및 아이콘?)이 있는 폴더는 OneDrive/Sharepoint에 저장되며 동기화된 폴더를 통해 로컬 시스템에서 사용할 수 있습니다.
제목: JSL 4.0Justin이 원래 포함시킨 업데이트 내용을 기반으로 저만의 업데이트 스크립팅을 만들었고, 19의 새로운 메서드와 비교 테스트는 해보지 않았습니다. JMP 메서드는 업데이트된 파일의 소스 폴더를 참조하기 때문에 JMP 메서드를 사용하는 것이 더 빠를 수 있지만, Justin 메서드(적어도 제가 사용하는 메서드)는 메타데이터 마스터 파일의 위치에 따라 지연될 수 있습니다. JMP19에서 JMP가 추가 기능을 업데이트하라는 메시지를 몇 번 보낸 적이 있는데, 제가 이미 구현한 것만큼 빠르다는 느낌이 들었습니다.
19의 새로운 메서드는 기본적으로 특정 위치에서 새 파일을 찾고 빌드 날짜 메타데이터에 얽매이지 않는 것처럼 보입니다. 저는 이 접근 방식이 전반적으로 마음에 들지만, '소스 폴더'를 구성하는 요소에 대한 실질적인 제어 권한이 없습니다. 예를 들어, 다운로드 폴더에서 애드인을 드래그하여 가져올 때 업데이트 확인 여부를 묻는 메시지가 표시되면 다운로드 폴더가 확인할 소스로 나열됩니다. 또한, 애드인의 프로덕션 버전과 테스트 버전을 구분하지 않으며, 사용자가 업데이트를 확인했지만 다른 위치에서 설치된 테스트 버전인 경우 "소스" 폴더가 올바르지 않을 수 있습니다.
저는 여기에 이 작품들을 체계화할 수 있도록 허락해 달라고 요청했습니다(다른 소원 목록 항목에 대해 잠깐 이야기를 나눈 이후 주로 이 스레드를 위해 요청했습니다).
제목: JSL 4.0@네이선-클라크 JMP19의 추가 기능 빌더를 사용해 보니, 그런 것 같지는 않습니다. 아쉽게도 현재로서는 제 경험을 자세히 기록할 시간이 없지만, 제가 경험한 내용을 간략하게 설명드리겠습니다. 다만 전문가는 아닙니다. 제 목표는 JMP19 방식을 사용하여 기존 공유 드라이브 버전을 다른 영역에서 완벽하게 복제하는 것이었습니다.
파일->새로 만들기->추가 기능을 사용하여 추가 기능을 만듭니다.
스크립트/아이콘을 추가하여 추가 기능을 설정하세요. 제 경우에는 공유 드라이브에 스크립트/아이콘이 있습니다.
파일을 자동으로 업데이트하도록 설정하고(파일 포함 탭), JMP가 시작될 때 일반 탭에서 업데이트를 확인합니다.
'다른 이름으로 저장'을 클릭하여 접근 가능한 위치에 새 .jmpaddin 파일을 만드세요. 그대로 두면 다른 사용자가 해당 위치에서 설치하게 됩니다.
다른 JMP 사용자는 해당 위치에서 설치하고 해당 버전의 JMP에서 해당 위치를 확인하여 변경 사항을 감지합니다.
파일을 편집하려면 애드인 빌더/jmpaddin 파일을 열어 애드인 편집기를 표시하세요. 그런 다음 스크립트를 편집하세요. 그러면 애드인 빌더에 '저장' 버튼이 표시됩니다. 또는 '다른 이름으로 저장'을 사용하여 애드인을 동일한 이름으로 저장할 수도 있습니다. 업데이트된 스크립트 파일을 바로 끌어다 놓거나, jsl 파일을 편집하고 닫은 후 나중에 애드인 빌더를 열면 저장 옵션이 표시되지 않습니다. 이는 개발자에게 보고된 버그입니다.
이전 버전의 JMP를 사용하는 JMP 사용자는 .jmpaddin 파일을 다시 설치하여 애드인을 업데이트해야 합니다. JMP19 사용자는 같은 위치에 애드인을 설치한 경우 업데이트하라는 메시지가 표시됩니다. .jmpaddin 파일을 이메일로 보내면 어떻게 될지 모르겠습니다. 아마도 JMP가 나중에 업데이트를 어디에서 확인해야 할지 모를 것입니다.
제목: JSL 4.0@mikedriscoll 님 , 맞는 말씀입니다. 안타깝게도 JMP에서 애드인 생성을 구현해야 합니다. 애드인이 너무 많아서 구현하기 힘들고, 이제 GitHub에서 모두 관리하고 있는데, 이 메서드들은 확장성이 부족해서 addin.def 파일에 세부 사항을 정리해 달라고 요청했습니다.
JMP19가 애드인 관리 측면에서 상당한 진전을 이루고 있다고 생각하지만, 장기적으로는 다양한 사용자/조직이 애드인 관리를 통해 얻는 규모에 맞춰 더 많은 옵션이 마련되어야 합니다. JMP에서 몇 가지 업데이트를 적용하면 현재 사용 중인 애드인 업데이트 인프라 중 일부를 더 이상 사용하지 않을 수 있을 것 같습니다.
제목: JSL 4.0좋든 싫든, 클릭했을 때 반응속도가 이전 버전인 18보다 조금 느린 점은 아쉽습니다. 물론 PC 사양에 따라 다르겠지만, 반응속도에 확실한 차이가 있다고 생각합니다.
제목: JSL 4.0또한 JMP 19에서는 추가 기능과 관련하여 몇 가지 작업이 더 쉬워질 수 있을 것으로 봅니다.
저는 이런 방식으로 애드인을 개발하는 걸 가장 좋아합니다.
- 내 문서 폴더의 압축 해제된 폴더에서
- 설치하려면 JMP에서 .def 파일을 엽니다.
- 텍스트 편집기에서 .jmpcust 파일을 편집합니다(이것은 약간 까다롭지만 대부분의 변경 사항에 대해 이 작업을 수행하지 않아도 되므로 저에게는 완벽하게 작동합니다)
- 메뉴 항목은 이 폴더의 스크립트를 참조합니다.
- 이 폴더에서 스크립트를 직접 테스트/편집할 수 있습니다(.jmpaddin의 파일을 메뉴를 통해 복사하고 업데이트하는 것은 꽤 지루하고 불필요하며 오류가 발생하기 쉽기 때문에 이 기능이 매우 큰 장점이라고 생각합니다).
- 배포를 위해 추가 기능을 압축하여 다른 사용자를 위한 공유 위치로 옮기는 작은 PowerShell 스크립트가 있습니다(그리고 문제가 발생할 경우 롤백을 수행할 수 있도록 이전 버전의 복사본도 만듭니다).
제목: JSL 4.0네, 스크립터스 클럽에서 향후 개선 사항 등에 대해 논의하고 싶습니다. 즉, 이 주제가 클럽의 일부가 될 수는 있지만 유일한 주제가 되어서는 안 됩니다. 제안해 주셔서 감사합니다.
제목: JSL 4.0@호기 제가 위시 리스트 항목에서 제안했던 것처럼 더 나은 오류 처리 기능이 있다면 정말 좋을 것 같습니다. 오류 처리 기능은 적어도 17.1에서는 고유하지 않고 제대로 문서화되어 있지 않습니다. 현재 (그리고 아마도 18.2에서도) exception_msg()에서 두 가지 형태의 오류 메시지를 사용할 수 있는 것 같은데, 이 메시지들은 스크립팅 인덱스나 다른 문서 어디에도 문서화되어 있지 않습니다.
오류 메시지는 오류 처리 시 확인할 수 있도록 언어에 독립적이어야 하거나, 오류 루틴에서 확인할 수 있는 일종의 고유 오류 코드를 포함해야 합니다. 이는 다음과 같습니다.
try (
<SOME action="https://community.jmp.com/">
,
<BR /> // we have to check for the exact message in all languages to handle a specific error:
<BR /> If (error_msg()[1] == "File not found" || error_msg()[1] == "Datei wurde nicht gefunden", // better would it be to have a language independent code // If (error_code() == 93 or better: ...== error_code["FileNotFound"] print("File not found: ");
<DO something="" because="" file="" was="" not="" found="">
, ... ); );
</DO>
</SOME>
Open 함수는 현재 추가 인수와 함께 목록 항목으로 오류 메시지를 반환합니다.
try(
open ("table");
,
Show(exception_msg());
//
// Returns in german language setting
// exception_msg() = {"Tabelle kann nicht geöffnet werden"(1, 2, "Open", Open /*###*/("table"))};
//
// Returns in english
// exception_msg() = {"Cannot open table"(1, 2, "Open", Open /*###*/("table"))};
);
이러한 주장은 어디에도 기록되어 있지 않으며, 저는 아직 이를 발견하지 못했습니다.
제 생각에는 오류에 대한 모든 정보를 담고 있는 오류 객체(클래스 형식)를 반환하는 것이 좋을 것 같습니다. 예:
try(
<ACTION>
<BR /> ,
<BR /> if (exception() << code == exception.FILENOTFOUND,
<BR /> Print( exception() << message );
<BR /> ...
</ACTION>
throw 함수도 괜찮은데, exception_msg()에서 사용된 인수를 지원하지 않는 것 같습니다. 모든 인수 값을 오류 처리 루틴에 전달할 수 있다면 좋을 것 같습니다.
try(
throw("Error"(1,2));
,
Show (exception_msg());
// Arguments to the thrown "Error" are lost.
);
결론적으로 오류 처리가 더 개선될 수 있습니다. 오류 처리가 이렇게 개선되면 정말 감사하겠습니다.
제목: JSL 4.0링크: 오류 메시지 개선 및 문서화
감사합니다. "멋지고 도움이 되는 새로운 기능"으로 추가했습니다. 상위 10위에 진입하면 "게임 체인저"로 이동하겠습니다.
문서화 부분에는 포괄적인 스크립팅 인덱스 가 있습니다.
"10대" 아이디어에 따라, "멋지고/도움이 되는" 아이디어에서 "게임 체인저" 아이디어로 순위를 올렸습니다.
후보자가 더 있나요?
제목: JSL 4.0Col 집계를 얼마나 자주 사용하시나요? 복잡한 만약에() 표현식이 포함된 "제한된" 집계를 얼마나 자주 사용하시나요?
고유한 항목 수를 채워야 합니다.
그리고 투표: Col Median(및 기타): "어디" 옵션 추가
