hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
아멜-마르두크 통치
아멜-마르두크의 통치 기간 동안 현존하는 쐐기 문자 자료는 매우 적으며, 따라서 그의 업적에 대해서는 거의 알려진 바가 없다. 네부카드네자르의 정당한 후계자임에도 불구하고, 아멜-마르두크는 왕으로서의 짧은 재임 기간과 후대 자료에서의 부정적인 묘사로 미루어 볼 때, 통치 초기부터 반대에 부딪혔던 것으로 보인다. 후기 헬레니즘 문명 시대의 바빌론 작가이자 천문학자인 베로수스는 아멜-마르두크가 "변덕스럽게 통치하고 법률을 경시했다"고 기록했으며, 쐐기 문자 선전 문헌은 그가 가족을 소홀히 했고, 관리들이 그의 명령을 따르기를 거부했으며, 그가 오로지 마르두크 숭배에만 몰두했다고 기록하고 있다. 아멜-마르두크에 대한 반대가 그의 아버지에 대한 이전 음모 시도 때문인지, 왕실 내 다른 파벌 간의 긴장 때문인지(그가 장남이 아니었음을 고려할 때), 아니면 왕으로서의 잘못된 관리 때문인지는 확실하지 않다. 아멜-마르두크의 직계 가족, 즉 그의 아내와 잠재적인 자녀에 대해서는 거의 알려져 있지 않다. 아멜-마르두크의 아들은 알려져 있지 않지만, 적어도 인두라는 딸이 한 명 있었다. 예라흐미엘 연대기는 아멜-마르두크에게 레고사르, 레부저 두크, 나브하르라는 세 아들이 있었다고 기술하고 있지만, 저자가 아멜-마르두크의 후계자들을 그의 아들들로 혼동한 것으로 보인다(각각 네리그리사르, 라바시-마르두크, 나보니두스).
아멜-마르두크 통치
그의 비문 중 하나는 그가 바빌론의 에사길라와 보르시파의 에지다를 개조했음을 시사한다. 이들 신전에서 실제로 작업이 이루어졌음을 확인하는 구체적인 고고학적 또는 문헌적 증거는 없다. 바빌론에 있는 일부 벽돌과 포장석에는 그의 이름이 새겨져 있는데, 이는 그의 짧은 재임 기간 동안 바빌론에서 일부 건축 작업이 완료되었음을 나타낸다.
아멜-마르두크 통치
성경에 따르면 아멜-마르두크는 유다의 왕 여호야긴을 바빌론 감옥에서 37년간의 투옥 끝에 해방시켰는데, 이는 아멜-마르두크에게 귀속된 유일한 구체적인 정치적 행위이다. 이러한 관대한 행위는 즉위식에서 흔히 볼 수 있으며, 이 경우에는 바빌론의 새해 축제와 관련되었을 수도 있지만, 여호야긴이 풀려난 구체적인 이유는 알려져 있지 않다. 제안된 이유로는 바빌로니아에 포로로 잡혀온 유대인들의 호감을 얻기 위함이거나, 아멜-마르두크와 여호야긴이 감옥에 있는 동안 친구가 되었을 수도 있다는 것이다. 후대 유대인 전통은 여호야긴의 석방이 유다 왕국을 멸망시킨 네부카드네자르의 정책에 대한 의도적인 역전이라고 보았다. 그러나 아멜-마르두크가 유다를 재건하려 했다는 어떤 징후도 없다. 그럼에도 불구하고, 아멜-마르두크가 티레의 잡힌 왕 바알레셀을 석방하고 그의 왕좌를 돌려주었기 때문에, 아멜-마르두크와 동시대에 살았던 유대인들은 여호야긴의 석방이 유다 재건의 첫 단계이기를 희망했을 가능성이 높다. 여호야긴의 석방은 열왕기하 25:27–30과 예라흐미엘 연대기에 기록되어 있으며, 두 자료 모두 아멜-마르두크를 에윌-므로닥으로 언급하고 있다. 예라흐미엘 연대기는 여호야긴의 석방을 다음과 같이 서술한다.
유다 왕 여호야긴이 사로잡혀 간 지 서른일곱 해 곧 바빌론 왕 에윌-므로닥이 즉위한 첫 해 열두째 달 스물다섯째 날에 그가 여호야긴을 옥에서 내놓아 그의 머리를 들게 하고. 그에게 친절히 말하고 바빌론에 자기와 함께 있는 다른 왕들의 자리보다 더 높은 자리를 주었다.
아멜-마르두크 폐위와 사망
아멜-마르두크의 통치는 기원전 560년 8월에 갑작스럽게 끝났다. 왕이 된 지 불과 2년 만에, 그의 매부인 네리그리사르에게 폐위되고 살해당했으며, 네리그리사르는 이후 왕위를 주장했다. 아멜-마르두크 통치 시기의 마지막 문서는 기원전 560년 8월 7일 바빌론에서 작성된 계약서이다. 4일 후, 네리그리사르 통치 시기로 날짜가 기재된 문서들이 바빌론과 우루크에서 발견되었다. 수도에서 그에게 귀속된 경제 활동이 증가한 것으로 미루어 볼 때, 네리그리사르는 찬탈 당시 바빌론에 있었다. 아멜-마르두크와 네리그리사르 간의 갈등은 다른 형태의 경쟁보다는 가족 내부의 불화 때문이었을 가능성이 높다. 네리그리사르는 네부카드네자르의 딸 중 한 명인 카샤야와 결혼했다. 카샤야는 아멜-마르두크와 다른 아들들보다 네부카드네자르 통치 초기(네부카드네자르 5년차, 기원전 600/599년)에 훨씬 일찍 기록되어 있으며, 그녀가 그들보다 나이가 많았을 가능성이 있다. 비록 카샤야에 대한 가장 초기의 언급과 아들들에 대한 언급 사이의 간격이 우연의 일치일 수도 있지만, 이는 또한 많은 아들들이 두 번째 결혼의 소생임을 나타내는 것으로 해석될 수도 있다. 따라서 네리그리사르의 찬탈은 네부카드네자르의 딸들, 특히 카샤야가 대표하는 더 오래되고 부유하며 영향력 있는 왕실 분파와, 덜 확고하고 어리지만 더 정당한 네부카드네자르의 아들들이 대표하는 분파 간의 내분으로 인한 것이었을 가능성이 있다.
아멜-마르두크 칭호
바빌론 다리 기둥에서 발견된 그의 비문 중 하나에 따르면, 아멜-마르두크의 칭호는 다음과 같다: "아멜-마르두크, 바빌론의 왕, 에사길라와 에지다를 개축한 자, 바빌론 왕 네부카드네자르의 아들."
아멜-마르두크의 비문이 거의 알려져 있지 않기 때문에, 그의 칭호에 대한 더 정교한 형태는 알려져 있지 않다. 그는 다른 신바빌로니아 왕들이 사용했던 '수메르와 아카드의 왕'이라는 칭호도 사용했을 수 있다.
아멜-마르두크 각주
Abraham, Kathleen (2012). 〈A Unique Bilingual and Biliteral Artifact from the Time of Nebuchadnezzar II in the Moussaieff Private Collection〉.   Lubetski, Meir; Lubetski, Edith. 《New Inscriptions and Seals Relating to the Biblical World》. Society of Biblical Literature. ISBN 978-1589835566.
아멜-마르두크 각주
Albertz, Rainer (2018). 〈The Exilic Period as an Urgent Case for a Historical Reconstruction without the Biblical Text: the Neo-Babylonian Royal Inscriptions as a 'Primary Source'〉.   Grabbe, Lester L. 《Even God Cannot Change the Past: Reflections on Seventeen Years of the European Seminar in Historical Methodology》. Bloomsbury Publishing. ISBN 978-0567680563.
아멜-마르두크 각주
Sack, Ronald H. (1978). 《Nergal-šarra-uṣur, King of Babylon as seen in the Cuneiform, Greek, Latin and Hebrew Sources》. 《Zeitschrift für Assyriologie und Vorderasiatische Archäologie》 68. 129–149쪽. doi:10.1515/zava.1978.68.1.129. S2CID 161101482.
Weiershäuser, Frauke; Novotny, Jamie (2020). 《The Royal Inscriptions of Amēl-Marduk (561–560 BC), Neriglissar (559–556 BC), and Nabonidus (555–539 BC), Kings of Babylon》 (PDF). Eisenbrauns. ISBN 978-1646021079.
Weisberg, David B. (1976). 《Review: Amēl-Marduk 562-560 B. C. A Study Based on Cuneiform, Old Testament, Greek, Latin and Rabbinical Sources By Ronald Herbert Sack》. 《Journal of Near Eastern Studies》 35. 67–69쪽. doi:10.1086/372466.
Wiseman, Donald J. (2003) [1991]. 〈Babylonia 605–539 B.C.〉.   Boardman, John; Edwards, I. E. S.; Hammond, N. G. L.; Sollberger, E.; Walker, C. B. F. 《The Cambridge Ancient History: III Part 2: The Assyrian and Babylonian Empires and Other States of the Near East, from the Eighth to the Sixth Centuries B.C.》 2판. Cambridge University Press. ISBN 0-521-22717-8.
익명 파이프
컴퓨터 과학에서 익명 파이프(anonymous pipe)는 단방향 프로세스 간 통신(IPC)에 사용될 수 있는 단방향 선입 선출 통신 채널이다. 구현은 종종 운영체제의 파일 입출력 서브시스템에 통합된다. 일반적으로 부모 프로그램이 익명 파이프를 열고, 파이프의 다른 끝을 상속하는 새 프로세스를 생성하거나, 여러 개의 새 프로세스를 생성하여 파이프라인으로 배열한다.
전이중 (양방향) 통신은 일반적으로 두 개의 익명 파이프를 필요로 한다.
파이프라인은 유닉스 및 도스를 비롯한 대부분의 인기 있는 운영체제에서 지원되며, 많은 셸에서 "|" 문자를 사용하여 생성된다.
익명 파이프 유닉스
파이프라인은 많은 전통적인 유닉스 애플리케이션의 중요한 부분이며, 대부분의 유닉스 계열 운영체제에 잘 통합되어 지원된다. 파이프는 pipe 시스템 호출을 사용하여 생성되며, 이는 새 파이프를 생성하고 파이프의 읽기 및 쓰기 끝을 참조하는 한 쌍의 파일 서술자를 반환한다. 많은 전통적인 유닉스 프로그램은 파이프와 함께 작동하도록 필터로 설계되었다.
익명 파이프 마이크로소프트 윈도우
윈도우 API의 다른 많은 장치 IO 및 IPC 기능과 마찬가지로, 익명 파이프는 IO 기능에 특정한 API 함수를 사용하여 생성 및 구성된다. 이 경우 CreatePipe는 파이프의 읽기 및 쓰기 끝에 대한 별도의 핸들을 가진 익명 파이프를 생성하는 데 사용된다. 파이프에 대한 읽기 및 쓰기 IO 작업은 표준 IO 기능 API 함수 ReadFile 및 WriteFile로 수행된다.
마이크로소프트 윈도우에서 익명 파이프에 대한 읽기 및 쓰기는 항상 블로킹된다. 즉, 빈 파이프에서 읽기는 최소한 한 바이트를 사용할 수 있거나 파이프의 쓰기 핸들이 닫힌 결과로 파일 끝이 수신될 때까지 호출 스레드가 기다리게 한다. 마찬가지로, 가득 찬 파이프에 대한 쓰기는 기록되는 데이터를 저장할 공간이 생길 때까지 호출 스레드가 기다리게 한다. 읽기는 요청된 바이트 수보다 적은 수의 바이트로 반환될 수 있다 (짧은 읽기라고도 함).
새 프로세스는 생성 프로세스에서 익명 파이프에 대한 핸들을 상속할 수 있다.
파이프 (소프트웨어)
소프트웨어 공학에서 파이프라인은 각 요소의 출력이 다음 요소의 입력이 되도록 배열된 처리 요소(프로세스, 스레드, 코루틴, 함수 등)의 체인으로 구성된다. 이 개념은 물리적인 파이프라인과 유사하다. 일반적으로 연속적인 요소들 사이에 어느 정도의 버퍼링이 제공된다. 이러한 파이프라인에서 흐르는 정보는 종종 스트림 형태의 레코드, 바이트 또는 비트이며, 파이프라인의 요소는 필터라고 불릴 수 있다. 이것은 또한 디자인 패턴인 파이프 및 필터라고도 불리는데, 이는 모놀리식이다. 이 방식의 장점은 단순성과 저비용이며, 단점은 유연성, 내결함성 및 확장성이 부족하다는 점이다. 요소를 파이프라인으로 연결하는 것은 함수 합성과 유사하다.
파이프 (소프트웨어)
좁은 의미에서 파이프라인은 선형적이고 단방향이지만, 때로는 더 일반적인 흐름에도 이 용어가 적용된다. 예를 들어, 주로 단방향 파이프라인은 되돌림 채널 또는 백채널이라고 알려진 다른 방향으로의 통신을 가질 수 있으며, 어휘 분석기 핵에서처럼 파이프라인은 완전히 양방향일 수도 있다. 단방향 트리와 유향 비순환 그래프 토폴로지를 가진 흐름은 선형 파이프라인과 유사하게 동작한다. 이러한 흐름에서 순환이 없으면 단순해지므로 느슨하게 "파이프라인"이라고 불릴 수 있다.
파이프 (소프트웨어) 구현
파이프라인은 종종 다중작업 OS에서 모든 요소를 프로세스로 동시에 실행하고, 각 프로세스의 데이터 읽기 요청을 업스트림 프로세스가 작성한 데이터로 자동 처리하는 방식으로 구현된다. 이를 다중 프로세스 파이프라인이라고 부를 수 있다. 이런 식으로 스케줄러는 CPU 유휴 시간을 최소화하기 위해 프로세스 간에 CPU를 자연스럽게 전환할 것이다. 다른 일반적인 모델에서는 요소를 경량 스레드 또는 코루틴으로 구현하여 프로세스와 관련된 OS 오버헤드를 줄인다. OS에 따라 스레드는 OS 또는 스레드 관리자에 의해 직접 스케줄링될 수 있다. 코루틴은 항상 어떤 형태의 코루틴 관리자에 의해 스케줄링된다.
파이프 (소프트웨어) 구현
읽기 및 쓰기 요청은 일반적으로 블로킹 작업이다. 이는 소스 프로세스의 실행이 쓰기 시에 모든 데이터를 대상 프로세스에 쓸 수 있을 때까지 일시 중단됨을 의미한다. 마찬가지로 대상 프로세스의 실행은 읽기 시에 요청된 데이터 중 일부라도 소스 프로세스에서 얻을 수 있을 때까지 일시 중단된다. 이로 인해 교착 상태가 발생할 수 없는데, 양쪽 프로세스가 서로 응답하기를 무한정 기다리는 상황은 적어도 하나의 프로세스가 곧 운영 체제에 의해 요청이 처리되어 실행을 계속할 것이기 때문이다.
파이프 (소프트웨어) 구현
성능을 위해 파이프를 구현하는 대부분의 운영체제는 파이프 버퍼를 사용하며, 이를 통해 소스 프로세스가 대상 프로세스가 현재 받으려는 또는 받을 수 있는 것보다 더 많은 데이터를 제공할 수 있다. 대부분의 유닉스 및 유닉스 계열 운영체제에서는 "buffer"라는 특수 명령이 제공되는데, 이는 잠재적으로 훨씬 크고 구성 가능한 파이프 버퍼를 구현한다. 이 명령은 대상 프로세스가 소스 프로세스보다 훨씬 느리지만, 소스 프로세스가 가능한 한 빨리 작업을 완료하기를 원할 때 유용할 수 있다. 예를 들어, 소스 프로세스가 CD에서 오디오 트랙을 읽는 명령으로 구성되고 대상 프로세스가 파형 오디오 데이터를 MP3와 같은 형식으로 압축하는 명령으로 구성되는 경우이다. 이 경우 전체 트랙을 파이프 버퍼에 버퍼링하면 CD 드라이브가 더 빨리 스핀다운되고, 인코딩 프로세스가 완료되기 전에 사용자가 CD를 드라이브에서 제거할 수 있게 된다.
이러한 버퍼 명령은 데이터 읽기 및 쓰기를 위한 시스템 호출을 사용하여 구현할 수 있다. 낭비적인 바쁜 대기는 poll 또는 select 또는 멀티스레딩과 같은 기능을 사용하여 피할 수 있다.
파이프라인 소프트웨어 시스템의 주목할 만한 예시로는 다음이 있다:
파이프 (소프트웨어) VM/CMS 및 z/OS
CMS 파이프라인은 파이프라인 아이디어를 VM/CMS 및 z/OS 시스템으로 포팅한 것이다. 이 시스템은 유닉스 셸보다 훨씬 복잡한 파이프라인 구조를 지원하며, 단계가 여러 입력 스트림을 받아 여러 출력 스트림을 생성할 수 있다. (이러한 기능은 유닉스 커널에서 지원되지만, 복잡한 구문과 블로킹 모드를 유발하여 이를 사용하는 프로그램은 거의 없지만, 일부 셸은 임의의 파일 서술자 할당을 통해 이를 지원한다.)
IBM 메인프레임 운영 체제의 기존 애플리케이션 프로그램에는 리디렉션이나 파이핑을 허용하는 표준 입출력 스트림이 없다. 외부 프로그램으로 프로세스를 생성하는 대신 CMS 파이프라인은 200개 이상의 내장 프로그램을 동시에 실행하는 경량 디스패처를 특징으로 하며, 이 프로그램들은 일반적인 UNIX 유틸리티를 구현하고 장치 및 운영 체제 서비스와 인터페이스한다. 내장 프로그램 외에도 CMS 파이프라인은 파이프라인에서 사용할 수 있는 입력 및 출력 스트림을 가진 사용자 작성 REXX 프로그램을 허용하는 프레임워크를 정의한다.
파이프 (소프트웨어) VM/CMS 및 z/OS
IBM 메인프레임의 데이터는 일반적으로 레코드 지향 파일 시스템에 존재하며 연결된 I/O 장치는 스트림 모드 대신 레코드 모드로 작동한다. 결과적으로 CMS 파이프라인의 데이터는 레코드 모드로 처리된다. 텍스트 파일의 경우 레코드는 한 줄의 텍스트를 담는다. 일반적으로 CMS 파이프라인은 데이터를 버퍼링하지 않고 잠금 단계 방식으로 한 프로그램에서 다음 프로그램으로 데이터 레코드를 전달한다. 이는 상호 연결된 파이프라인 네트워크를 통한 데이터의 확정적 흐름을 보장한다.
파이프 (소프트웨어) 객체 파이프라인
바이트 스트림 기반 파이프라인 외에도 객체 파이프라인도 존재한다. 객체 파이프라인에서 처리 요소는 텍스트 대신 객체를 출력한다. 파워셸은 파워셸 런타임 내에서 함수 간에 .NET 객체를 전송하는 내부 객체 파이프라인을 포함한다. 림보 프로그래밍 언어에 있는 채널은 이러한 은유의 또 다른 예시이다.
파이프 (소프트웨어) GUI의 파이프라인
RISC OS 및 ROX 데스크톱과 같은 그래픽 환경도 파이프라인을 사용한다. 사용자에게 프로그램이 데이터를 어디에 쓸지 지정하도록 파일 관리자를 포함하는 저장 대화 상자를 제공하는 대신, RISC OS 및 ROX는 아이콘 (및 이름을 지정하는 필드)을 포함하는 저장 대화 상자를 제공한다. 대상은 아이콘을 드래그 앤 드롭하여 지정된다. 사용자는 아이콘을 이미 저장된 파일이 놓일 수 있는 모든 곳, 즉 다른 프로그램의 아이콘 위에도 놓을 수 있다. 아이콘이 프로그램의 아이콘 위에 놓이면 프로그램이 로드되고, 그렇지 않으면 저장되었을 내용은 새 프로그램의 표준 입력 스트림으로 전달된다.
파이프 (소프트웨어) GUI의 파이프라인
예를 들어, 월드 와이드 웹을 탐색하는 사용자는 압축된 .gz 이미지를 발견하여 편집하고 다시 업로드하고 싶을 수 있다. GUI 파이프라인을 사용하면 해당 링크를 압축 해제 프로그램으로 드래그하고, 추출된 콘텐츠를 나타내는 아이콘을 이미지 편집기로 드래그한 다음 편집하고, 다른 이름으로 저장 대화 상자를 열어 아이콘을 업로드 소프트웨어로 드래그할 수 있다.
개념적으로 이 방법은 기존 저장 대화 상자와 함께 사용될 수 있지만, 사용자 프로그램이 파일 시스템에서 명확하고 쉽게 접근할 수 있는 위치를 가져야 한다. 그러나 종종 그렇지 않으므로 GUI 파이프라인은 드물다.
파이프 (소프트웨어) 기타 고려사항
"파이프라인"이라는 이름은 물리적인 배관과의 대략적인 비유에서 비롯되었다. 파이프라인은 일반적으로 물이 파이프에서 흐르듯이 정보가 한 방향으로만 흐르도록 허용한다.
파이프와 필터는 바이트 스트림을 데이터 객체로 사용하는 함수형 프로그래밍의 한 형태로 볼 수 있다. 더 구체적으로, 모나드의 특정 형태로 볼 수 있다.
파이프라인 개념은 코쿤 웹 개발 프레임워크나 XProc (W3C 표준) 구현에서도 핵심적인 역할을 하며, 이를 통해 소스 스트림을 최종 표시 전에 수정할 수 있다.
이 패턴은 텍스트 스트림을 프로그램의 입력 및 출력으로 사용하는 것을 장려한다. 이러한 텍스트 의존성은 텍스트 프로그램에 대한 그래픽 셸을 만들 때 고려되어야 한다.
성경 외 자료에서 확인된 성경 인물 목록
이들은 동시대 자료에서 명확하게 확인된 성경 인물이다. 고대이기는 하지만 동시대 문서가 아닌 곳에서 언급된 성경 인물은 이 목록에서 제외되었다. 즉, 여호아스 비문과 바룩 벤 네리야의 인장과 같이 진위 여부가 불확실한 유물에서 확인되거나, 다윗과 발람은 이 목록에서 제거되었다.
성경 외 자료에서 확인된 성경 인물 목록 구약 성경
성서고고학에서 '이스라엘'이라는 이름이 처음 언급된 것은 기원전 13세기로 거슬러 올라가지만 기원전 9세기 이전 이스라엘 민족에 대한 동시대 정보는 극히 드물다. 이후 몇 세기 동안, 대부분 도장과 인장으로 된 소수의 히브리어 현지 문헌들이 성경 인물들을 언급한다. 하지만 바빌론, 아시리아, 이집트와 같은 이웃 왕국의 왕실 비문에서 더 광범위한 정보를 얻을 수 있다.
성경 외 자료에서 확인된 성경 인물 목록 제2경전
제2경전은 기원전 8세기에서 2세기 사이의 사건을 묘사하지만, 제2경전에 언급된 역사적으로 식별 가능한 인물들은 대부분 셀레우코스 제국의 일부였던 유대에서 마카베오 전쟁 (기원전 167-160년) 시기에 살았다. 통치자들의 이름이 새겨진 주화가 널리 사용되었으며, 그 중 많은 주화에는 셀레우코스 시대의 연도가 새겨져 있어 정확한 연대 측정이 가능했다.
직접적인 정보는 또한 그리스 역사가 폴리비오스 (기원전 200년경 – 118년경)의 역사에서 얻을 수 있는데, 그의 역사는 마카베오서와 같은 시기를 다루며, 그리스 및 바빌론 비문에서도 얻을 수 있다. 플라비우스 요세푸스 또한 그의 유대 고대사 12권에서 마카베오 전쟁을 상세히 논하지만, 마카베오서 1권의 그리스어 버전이 요세푸스의 주요 자료 중 하나였기 때문에, 고대사는 일부 학자들에게 진정한 독립적 확인이라기보다는 순환 참조로 간주된다.
성경 외 자료에서 확인된 성경 인물 목록 신약성경
단연코 서기 1세기 유대 역사에 대한 가장 중요하고 상세한 자료는 유대 역사가 플라비우스 요세푸스 (37년경 – 100년경)의 저작이다. 이 책들은 신약성경에 나오는 많은 저명한 정치 인물들을 언급하며, 기독교 출현의 역사적 배경을 이해하는 데 결정적이다. 요세푸스는 또한 예수와 세례자 요한의 처형을 언급하지만, 그는 둘 중 누구의 동시대인도 아니었다. 요세푸스 외에 일부 신약성경 인물에 대한 정보는 타키투스와 수에토니우스와 같은 로마 역사가들과 고대 주화 및 비문에서 나온다.
성경 외 자료에서 확인된 성경 인물 목록 잠정적으로 확인된 인물
다음은 이름과 자격이 일치하는 동시대 자료에서 잠정적이지만 가능성이 있는 확인이 발견된 성경 인물들이다. 그러나 이름의 우연한 일치 가능성을 배제할 수는 없다.
바알리스 암몬 왕은 예레미야 40:14에 언급된다. 1984년, 요르단 텔 엘-우메이리에서 기원전 600년경으로 추정되는 암몬 인장이 발굴되었는데, 이 인장에는 "바알리샤의 종 밀코모르의 것"이라고 새겨져 있다. '바알리샤'가 성경의 바알리스와 동일할 가능성이 높지만, 그 이름의 암몬 왕이 한 명뿐이었는지는 현재로서는 알려져 있지 않다.
성경 외 자료에서 확인된 성경 인물 목록 잠정적으로 확인된 인물
이사야, 2018년 2월 고고학자 에일랏 마자르는 그녀와 그녀의 팀이 예루살렘 성전산 남쪽 오펠 발굴지에서 "[~에게 속함] 이사야 nvy"(재구성하여 "[선지자] 이사야에게 속함"으로 읽을 수 있음)라고 쓰인 작은 인장 흔적을 발견했다고 발표했다. 이 작은 인장은 2015년에 같은 팀이 "[유다 왕 히즈키야]에게 속함"이라는 문구가 새겨진 온전한 인장을 발견한 곳에서 "불과 10피트 떨어진" 곳에서 발견되었다. 고대 히브리 문자로 새겨진 "이사야"라는 이름은 분명하지만, 인장 왼쪽 아래 부분의 손상으로 인해 "선지자"라는 단어나 일반적인 히브리어 이름 "나비"를 확인할 수 없어서, 이 인장이 정말 선지자 이사야의 것인지에 대한 의구심을 남긴다.
성경 외 자료에서 확인된 성경 인물 목록 잠정적으로 확인된 인물
아히카르, 틀:토빗와 아람어 아히카르 이야기에 언급된 현자.:148 우루크 (와르카)에서 기원전 2세기로 거슬러 올라가는 후기 바빌론 쐐기 문자 석판에 에사르하돈(기원전 7세기) 시대의 아람어 현자 아후아카르가 언급되어 있다.:148–150 센나케립과 에사르하돈 시대의 쐐기 문자 본문에도 아히-야카르라는 이름의 한 명 이상의 인물에 대한 언급이 있지만, 이 인물(또는 인물들)을 현자 아히카르와 동일시하는 것은 불확실하다.:144–145
코린토스의 에라스토: 1929년 코린토 극장 북동쪽 포장된 지역 근처에서 에라스토를 언급하는 비문이 발견되었는데, 1세기 중반으로 거슬러 올라가며 "에라스토는 그의 조영관직에 대한 보답으로 자신의 비용으로 포장했다"고 쓰여 있다. 일부 신약성경 학자들은 이 조영관 에라스토를 로마서에 언급된 에라스토와 동일시했지만, 다른 학자들은 이를 반박한다.
리사니아스는 루가(3:1)에 따르면 기원후 28년경 아빌라의 분봉왕이었다. 요세푸스는 기원전 36년에 처형된 아빌라의 리사니아스만을 언급하기 때문에 일부 학자들은 이를 루가의 오류로 간주했다. 그러나 아빌라에서 발견된 한 비문은 기원후 14-29년으로 잠정적으로 추정되며, 이후 리사니아스라는 분봉왕의 존재를 기록하는 것으로 보인다.
튜다. 튜다에 대한 유일한 언급은 연대기적 문제를 제기한다. 사도행전에서 가마리엘은 산헤드린의 일원으로서 튜다를 언급하며 사도들을 변호한다(사도행전 5:36–8). 문제는 여기서 튜다의 봉기가 갈릴래아의 유다의 봉기보다 앞서 일어났다고 하는데, 갈릴래아의 유다의 봉기는 과세 시기 (기원후 6-7년경)로 거슬러 올라간다는 것이다. 반면 요세푸스는 튜다가 45세 또는 46세였다고 말하는데, 이는 가마리엘이 말하는 시점보다 한참 뒤이며, 갈릴래아의 유다의 봉기보다도 한참 뒤이다.
2MASS J00084563+2350186
2MASS J00084521+2350184은 NGC 8의 동반성이며, K형 주계열성이다.
Mmap
컴퓨팅에서 mmap(2) OR 메모리 매칭 파일는 POSIX를 준수하는 유닉스 시스템 호출로, 파일이나 장치를 메모리에 매핑한다. 이는 메모리 맵 파일 I/O 방식이다. 파일 내용이 디스크에서 즉시 읽히지 않고 초기에는 물리적 RAM을 전혀 사용하지 않으므로 요구 페이징을 구현한다. 디스크에서 실제 읽기는 특정 위치에 접근한 후 느긋한 방식으로 수행된다. 매핑이 더 이상 필요하지 않으면 munmap(2)를 사용하여 포인터를 언매핑해야 한다. 예를 들어, 매핑된 영역을 실행 가능으로 표시하는 것과 같은 보호 정보는 mprotect(2)를 사용하여 관리할 수 있으며, madvise(2)를 사용하여 특별한 처리를 적용할 수 있다.
리눅스, macOS 및 BSD에서는 mmap이 여러 유형의 매핑을 생성할 수 있다. 다른 운영체제는 이들 중 일부만 지원할 수 있다. 예를 들어, 전역 VFS 또는 I/O 캐시가 없는 운영체제에서는 공유 매핑이 실용적이지 않을 수 있다.
Mmap 역사
메모리 맵 파일의 원래 설계는 TOPS-20 운영체제에서 나왔다. mmap 및 관련 시스템 호출은 유닉스 BSD 버전의 일부로 설계되었다. 이들의 API는 4.2BSD 시스템 매뉴얼에 이미 기술되었지만, 해당 릴리스나 4.3BSD에서는 구현되지 않았다. 그러나 썬 마이크로시스템즈는 썬OS 운영체제의 4.0 릴리스에서 이 API를 구현했다. 캘리포니아 대학교 버클리의 BSD 개발자들은 썬에 그 구현을 기부해 달라고 요청했지만 성공하지 못했다. 대신 4.3BSD-Reno는 Mach의 가상 메모리 시스템을 기반으로 한 구현과 함께 출시되었다.
Mmap 파일 백업 및 익명
파일 백업 매핑은 프로세스의 가상 메모리 영역을 파일에 매핑한다. 즉, 해당 메모리 영역을 읽으면 파일이 읽힌다. 이것이 기본 매핑 유형이다.
익명 매핑은 어떤 파일에도 백업되지 않은 프로세스의 가상 메모리 영역을 MAP_ANONYMOUS/MAP_ANON 플래그를 통해 사용할 수 있도록 매핑한다. 내용은 0으로 초기화된다. 이러한 측면에서 익명 매핑은 malloc과 유사하며, 특정 할당, 특히 큰 할당을 위해 일부 malloc 구현에서 사용된다.
Mmap 메모리 가시성
매핑이 공유(MAP_SHARED 플래그가 설정됨)되면, 프로세스가 fork(2) 시스템 호출을 사용하여 포크될 때 보존된다. 따라서 한 프로세스에서 매핑된 영역에 대한 쓰기는 관련된 모든(부모, 자식 또는 형제) 프로세스에서 즉시 볼 수 있다. 매핑이 공유되고 파일로 백업된 경우(MAP_ANONYMOUS가 아님) 기본 파일 매체는 msync(2) 시스템 호출로 전달된 후에만 쓰기가 보장된다. 반면, 매핑이 사적(MAP_PRIVATE 플래그가 설정됨)인 경우 변경 사항은 다른 프로세스에 표시되지 않으며 파일에도 기록되지 않는다.
기본 파일을 읽거나 쓰는 프로세스는 파일을 매핑한 다른 프로세스와 항상 동일한 데이터를 보지는 않는다. 파일의 세그먼트가 RAM으로 복사되고 주기적으로 디스크로 플러시되기 때문이다. msync(2) 호출을 통해 동기화를 강제할 수 있다.
Mmap 메모리 가시성
파일에 mmap을 사용하면 동일한 파일에 접근하는 애플리케이션의 메모리 오버헤드를 크게 줄일 수 있다. 각 애플리케이션이 파일에 접근하기 위해 파일을 로드하는 대신, 파일이 포함하는 메모리 영역을 공유할 수 있다. 이는 mmap(2)이 때때로 프로세스 간 통신 (IPC)에 사용된다는 것을 의미한다. 최신 운영체제에서는 mmap(2)이 일반적으로 System V IPC 공유 메모리 기능보다 선호된다.
System V 공유 메모리(shmem)와 메모리 맵 I/O(mmap)의 주요 차이점은 System V 공유 메모리가 영구적이라는 것이다. 프로세스에 의해 명시적으로 제거되지 않는 한, 메모리에 유지되며 시스템이 종료될 때까지 계속 사용할 수 있다. mmap된 메모리는 애플리케이션 실행 간에 영구적이지 않다(파일로 백업되지 않은 경우).
Mmap 데이터베이스 구현에서의 사용
mmap 시스템 호출은 버퍼 풀 구현의 대안으로 다양한 데이터베이스 구현에서 사용되었지만, 이는 버퍼 풀을 통해서만 현실적으로 해결할 수 있는 다른 문제들을 야기했다.
2MASS J00084521+2350184
2MASS J00084521+2350184은 NGC 8의 주성이며, K형 주계열성이다.
애플 이벤트
애플 이벤트(Apple event)는 Mac OS의 메시지 기반 프로세스 간 통신 메커니즘으로, 시스템 7에서 처음 등장한 이래 모든 맥 OS의 역사 버전과 macOS에서 지원되고 있다. 애플 이벤트는 "문서 열기" 또는 "파일 인쇄"와 같은 "고수준" 이벤트를 설명하는 반면, 초기 OS는 "클릭" 및 "키 누르기"와 같은 훨씬 더 기본적인 이벤트를 지원했다. 애플 이벤트는 맥 OS 스크립트 시스템인 오픈 스크립팅 아키텍처의 기반을 형성하며 (주요 언어는 애플스크립트이다).
시작점은 AEDesc라고 불리는 동적 타입의 확장 가능한 디스크립터 형식으로, 데이터 타입과 타입에 종속적인 데이터 블록을 지정하는 OSType 코드에 불과하다. 예를 들어, OSType 코드 inte는 데이터가 빅 엔디언 형식의 4바이트 부호 있는 정수임을 나타낸다.
애플 이벤트
다양한 공통 단순 타입에 대한 미리 정의된 타입 코드 외에도 두 가지 미리 정의된 구조화된 디스크립터 타입이 있다: 데이터 타입 reco(레코드)를 가진 AERecord와 타입 list(목록 또는 배열)를 가진 AEList이다. 이들의 내부 구조는 재귀적으로 중첩된 AEDesc를 포함하며, AERecord는 각 요소를 고유한 레코드 필드 ID(OSType)와 연결한다. 애플 이벤트 관리자는 이러한 구조를 구성하고, 그 내용을 추출하며, 그들이 보유한 내용의 타입을 쿼리하는 API 호출을 제공한다.
애플 이벤트 관리자는 또한 AEDesc를 한 데이터 타입에서 다른 데이터 타입으로 변환하는 강제 변환도 지원한다. 예를 들어 정수와 실수 타입 간의 표준 강제 변환 외에도, 애플리케이션은 사용자 정의 데이터 타입 간의 변환을 처리하는 자체 강제 변환 핸들러 콜백을 설치할 수 있다.
애플 이벤트
적절한 애플 이벤트는 이벤트 목적에 따라 필드가 달라지는 AERecord이다. 또한 애플 이벤트 관리자가 미리 정의한 세트의 속성(이제 이벤트의 매개변수라고 불리는 레코드 필드와는 별개)을 갖는다. 이는 이벤트가 수행해야 할 작업(이벤트 클래스 및 이벤트 ID를 통해), 이벤트가 전송될 대상 주소(로컬 또는 원격 시스템의 프로세스일 수 있음), 그리고 이를 처리하기 위한 다양한 기타 옵션을 지정한다. 원격 시스템은 처음에는 애플토크를 통해 연결되어야 했지만, 맥 OS 9는 TCP/IP를 통한 연결 옵션을 추가했다.
애플 이벤트를 대상 프로세스로 보낸 후, 보내는 프로세스는 애플 이벤트에 대한 응답을 받도록 선택할 수 있다. 여기에는 원래 이벤트의 처리와 관련하여 대상에서 반환된 다양한 정보, 즉 성공/실패를 나타내는 오류 코드, 원래 이벤트에서 요청된 정보 및 기타 적절한 정보가 포함될 수 있다.
애플 이벤트는 애플이벤트 오브젝트 모델의 기반이며, 이는 다시 OSA 및 애플스크립트의 기반이 된다. 2016년 기준으로 애플 이벤트 관리자 API의 공식 구현은 C 및 C++를 포함한 파생 언어에서 사용할 수 있다. 공식 바인딩은 코코아 API를 통해 오브젝티브-C 및 스위프트에서도 제공된다. 펄, UserTalk, 루비, 파이썬을 포함한 다른 언어에서도 (제한적이지만) 비공식 바인딩이 존재한다.
애플 이벤트 오브젝트 모델
애플이벤트 오브젝트 모델(AppleEvent Object Model, AEOM)은 애플 이벤트 위에 구축된 프로토콜 세트로, 맥 OS의 역사 및 macOS에서 실행되는 애플리케이션들이 서로의 기능을 제어할 수 있게 했다. AEOM의 일부를 구현한 애플리케이션은 애플스크립트를 통해 제어될 수 있었기 때문에 스크립트 가능하다고 불렸다. 안타깝게도, 스크립트 가능성 지원은 맥 OS의 역사 내내 일관성이 없고 파편화되어 있었다.
AEOM은 어떤 애플리케이션이든 내부 객체를 게시할 수 있는 구문 계층을 제공하여, 해당 객체들을 표준화된 방식으로 조작할 수 있게 했다. ToolTalk와 같은 다른 유사한 개념들과 달리, 명사와 동사 사이에는 명확하고 직교적인 구분이 있었다. 따라서 "문서 닫기"와 "창 닫기"에 대한 별도의 명령을 제공하는 대신, "문서" 또는 "창" 객체, 또는 애플리케이션이 게시한 다른 객체에 대한 참조를 받을 수 있는 단일 "닫기" 동사가 있었다.
애플 이벤트 오브젝트 모델
애플리케이션이 AEOM 지원을 통해 제공하는 객체들은 계층 구조로 배열되었다. 최상위에는 null 객체 디스크립터를 통해 참조되는 애플리케이션 자체가 있었다. 다른 객체들은 (재귀적으로) 부모 객체를 지정하고, 해당 부모의 자식임을 식별하는 다른 정보와 함께 AERecord에 모두 수집되어 참조되었다. 부모는 자식들을 열거하거나 특정 클래스의 자식들을 열거할 수 있는 반복자를 제공하여, 애플리케이션이 요소 집합을 다룰 수 있게 했다. 이 시스템은 일반적으로 XML에서 사용되는 문서 객체 모델과 유사했지만, 접근 패턴에는 약간의 차이가 있었다.
각 객체는 요소와 속성을 가질 수 있었다. 요소는 생성되거나 삭제될 수 있는 다른 객체였고, 속성은 생성되거나 삭제될 수는 없지만 조회하거나 변경할 수 있는 값을 가졌다. 예를 들어, 애플리케이션은 현재 열린 문서의 내용을 보여주는 창을 나타내는 하나 이상의 창 요소를 가질 수 있었다. 이 창들은 제목, 위치 및 크기와 같은 속성을 가질 수 있었다.
애플 이벤트 오브젝트 모델
애플리케이션은 객체에 대해 사용자 정의 동사를 정의할 수 있었다. AEOM은 또한 (기대했던 대로) 애플리케이션이 일관된 방식으로 구현할 표준 동사(예: 열기, 닫기, 요소 생성, 삭제, 데이터 설정, 데이터 가져오기)를 지정했다. 각 동사는 특정 유형 및 클래스의 애플이벤트로 정의되었으며, 특정 유형의 특정 매개변수가 존재할 것으로 예상되었다. 예를 들어, "데이터 가져오기" 이벤트는 속성 값을 얻기 위한 표준 수단이었다. 본질적으로 하나의 매개변수(쿼리할 속성을 식별하는 객체 디스크립터)를 가졌다. 해당 속성의 값은 회신 이벤트로 반환되었다. "데이터 설정" 이벤트는 두 개의 매개변수(설정할 속성의 객체 디스크립터와 속성의 새 값)를 가졌다. 회신 이벤트는 성공 상태 또는 실패 오류 코드만 반환할 것으로 예상되었다.
애플 이벤트 오브젝트 모델
전체 애플 이벤트 아키텍처는 4바이트 OSType 코드를 사용하여 모든 것을 식별하며, 영어(또는 다른 언어)의 실제 단어나 구를 피한다. 대신, 내부 애플 이벤트 코드와 외부 자연어 설명 간의 대응 관계는 aete(AppleEvent Terminology Extension) 리소스를 통해 지정된다. 여기서 "확장"은 애플스크립트 자체에 내장된 표준 용어를 의미한다. 애플리케이션은 애플스크립트 자체의 원래 다국어 설계에 따라 여러 언어에 대한 여러 'aete' 리소스를 제공할 수 있다.
예를 들어, 가상의 그리기 애플리케이션을 제어하는 다음 애플스크립트 시퀀스를 고려해 보자.
이것은 실제로 대상 애플리케이션으로 두 개의 애플이벤트를 전송하는 것을 포함한다 (그리고 해당 회신을 수신한다): 첫째, "Old Drawing"이라는 이름으로 식별되는 창의 배경색 속성을 검색하기 위해 get-data 이벤트가 전송된다; 그런 다음 반환된 값을 "New Drawing"이라는 이름의 창의 배경색 속성으로 적용하기 위해 set-data 이벤트가 전송된다.
애플 이벤트 오브젝트 모델
이러한 종류의 접근 패턴이 일반적이었기 때문에, 애플스크립트는 비주얼 베이직 또는 파스칼에서 발견되는 with 문과 유사한 방식으로 명명된 객체로 컨텍스트를 전환하는 tell 문을 널리 사용했다. tell 다음부터 해당 end tell까지의 모든 명령은 기본 객체인 현재 애플리케이션 대신 tell에 명명된 객체로 전송되었다.
객체 디스크립터를 통해 다양한 방식으로 객체를 식별할 수 있었다. 가장 흥미로운 방법은 where-절(애플스크립트 용어로는 필터 표현식으로 번역됨)을 사용하는 것이었다. 예를 들어, 애플스크립트 1.0 SDK는 Scriptable Text Editor라는 예제 애플리케이션의 소스 코드를 제공했는데, 이 애플리케이션은 다음과 같은 스크립트에 응답했다.
오늘날에도 SQL 외의 범용 스크립트 언어에서 이러한 종류의 강력한 기능을 찾기는 드물다.
애플 이벤트 오브젝트 모델
맥 OS의 역사에서 AEOM을 지원하는 것은 어려운 과정이었다. 애플리케이션 개발자는 객체를 식별하고 수동으로 코드를 작성하여 객체를 주소 지정할 수 있도록 해야 했다. 이는 일반적으로 특정 유형의 "다음" 객체를 반환하는 코드 형태로 이루어져 애플스크립트가 객체들을 반복할 수 있도록 했다. 그러나 OS 자체에 객체 모델이 없었기 때문에 이 작업은 전적으로 개발자의 몫이었고, 많은 개발자가 이를 구현하지 않았다. 이상하게도, 애플 자체의 애플리케이션 프레임워크인 MacApp조차도 GUI 객체를 제외하고는 이러한 모델을 제공하지 않아, 개발자가 데이터 자체를 나타내는 객체를 스크립팅하는 대부분의 작업을 다시 해야 했다. 주로 이러한 이유로 애플스크립트 지원은 그리 널리 퍼지지 않았다.
애플 이벤트 오브젝트 모델
애플은 다양한 객체 "스위트"를 도입하여 이 문제를 해결하려고 시도했는데, 이는 다양한 유형의 애플리케이션에서 지원될 것으로 예상되는 표준 객체와 동사를 나타냈다. 예를 들어, 모든 애플리케이션은 "코어 스위트"를 지원해야 했고, 텍스트를 편집하는 애플리케이션은 "텍스트 스위트"를 지원해야 했다. 적절한 스위트 집합을 선택함으로써 개발자는 적어도 객체를 노출하는 방법에 대한 계획 작업을 줄일 수 있었다. 그러나 이러한 객체는 일반적으로 시스템 자체의 일부가 아니었기 때문에 (심하게 제한된 TextEdit 편집기를 제외하고), 실제 구현은 개발자에게 맡겨졌다.
이전에는 오픈스텝으로 알려진 시스템인 코코아에서 개발된 애플리케이션은 다른 모든 애플리케이션에서 쿼리할 수 있는 풍부한 객체 런타임을 제공한다. 이는 AEOM 구현을 상당히 쉽게 만들어 평균 애플리케이션에서 필요한 코드 양을 극적으로 줄여준다. 또한 대부분의 코코아 애플리케이션은 주로 코코아 표준 객체로 구성되며, 이 모든 객체는 상당히 광범위한 스크립트 가능성을 제공하도록 업그레이드되었다. 이는 MacApp에서와 같이 GUI 객체뿐만 아니라 텍스트, 테이블 및 다양한 목록 객체를 포함한 내부 데이터 객체에도 적용된다. 텍스트 파일은 내부 "객체 유사" 이름을 사람이 읽을 수 있는 버전으로 매핑하는 데 사용되며, 대부분의 경우 이 파일을 생성하는 것만으로도 대부분의 프로그램에 상당히 많은 스크립트 가능성을 추가할 수 있다.
코코아 애플리케이션은 AEOM 기반이 아니며, 애플이 원래 정의한 표준 객체와 미묘하게 다른 객체를 사용하는 경우가 많지만, 코코아 앱은 일반적으로 "클래식" 앱보다 훨씬 더 스크립트 가능성이 높다. 사실, 어느 정도 스크립트 불가능한 코코아 애플리케이션을 찾는 것은 드문 일이다.
애플 이벤트 스크립팅 브리지
스크립팅 브리지는 애플스크립트와 같은 중간 스크립팅 언어를 사용하지 않고도 애플리케이션들이 서로 통신할 수 있게 해주는 macOS 프레임워크이다. 스크립팅 브리지는 애플스크립트와 마찬가지로 애플리케이션 간 통신을 위해 애플 이벤트를 사용한다.
스크립팅 브리지는 일반적으로 오브젝티브-C에서 사용되지만, MacRuby 및 PyObjC와 같은 오브젝티브-C 브리지를 통해 다른 프로그래밍 언어에서도 사용할 수 있다.
애플 이벤트 더 읽어보기
Cook, William R. (2006년 9월 29일), 〈AppleScript〉 (PDF), 《Proceedings of the third ACM SIGPLAN conference on History of programming languages》, University of Texas at Austin, 1–1–1–21쪽, CiteSeerX 10.1.1.76.6993, doi:10.1145/1238844.1238845, ISBN 9781595937667, S2CID 220938191, 2009년 5월 9일에 확인함 . 특히 2.3절 “애플 이벤트”(9–13페이지)를 참조하지만, 애플 이벤트의 역사와 중요성은 이 논문의 다른 곳에서도 논의된다.
라미 자피
라미 자피(영어: Rami Jaffee, 1969년 3월 11일 ~ )는 미국의 음악가이다. 그는 2005년에 투어 및 세션 멤버로 처음 참여한 록 밴드 푸 파이터스의 키보디스트이다. 그는 밴드의 스튜디오 앨범 7개에 기여했으며, 2017년에 정식 멤버로 합류했다.
푸 파이터스에 합류하기 전, 재피는 1990년부터 2005년까지, 그리고 2012년부터 2013년까지 더 월플라워스의 멤버였다. 그는 피트 욘, 스톤 사워, 조셉 아서, 코히드 앤 캠브리아를 포함한 많은 아티스트들과 함께 작업했다.
라미 자피 어린 시절
자피는 1969년 3월 11일 로스앤젤레스에서 러시아 아슈케나지 유대인 아버지와 모로코 세파르디 유대인 어머니 사이에서 태어났다. 13세 때 키보드를 구매한 후 곧 지역 밴드에서 연주를 시작했다. 페어팩스 고등학교를 졸업한 후에도 계속해서 다양한 밴드에서 연주하고 녹음 스튜디오에서 세션 작업을 했다.
라미 자피 경력
1989년경, 제이콥 딜런과 그의 친구 토비 밀러는 애플스(the Apples)라는 그룹을 결성하여 LA 지역의 여러 클럽에서 연주했다. 새벽 2시 이후 캔터스 델리에서 줄을 서 기다리던 재피는 애플스가 오르간 연주자와 피아니스트를 원한다는 소식을 듣고 딜런과 밀러가 캔터스에 붙어있는 키비츠 룸(Kibitz Room) 바에 있다고 들었다. 그들은 만났고, 딜런과 밀러는 재피에게 자동차 스테레오에서 데모 테이프를 들려주었고, 재피는 즉시 그룹에 합류했다. 몇 주 후, 그들은 이름을 월플라워스로 바꾸고 버진 레코드와 계약했다. 1992년에 그들은 첫 앨범 The Wallflowers를 발매했다. 월플라워스는 1992년과 1993년 초에 미국과 캐나다 전역을 투어했다. 그들은 크래커, 스핀 닥터스, 10,000 매니악스의 오프닝 액트로 활동했으며, 자신들의 단독 공연을 시작했다.
라미 자피 경력
버진은 앨범 판매 부진으로 월플라워스에 대한 흥미를 잃은 것으로 보였다. 밴드의 두 명의 친숙한 레이블 대표가 레이블을 떠난 후, 음반사는 밴드의 지시와 반대로 딜런의 이름을 판매 포인트로 사용하려고 했다. 1993년 중반, 레이블은 밴드의 계약을 해지했다. 다른 레이블은 밴드와 계약하는 데 관심이 없었고, 재피는 엘 베즈와 함께 공연을 하고 더 많은 세션 작업을 하면서 시간을 보냈다. 그는 월플라워스에 대한 관심을 유지하며 나중에 이렇게 말했다. "나는 이 노래들을 믿고, 아무도 더 이상 이런 노래, 즉 해먼드 오르간과 나를 위한 공간이 있는 노래를 쓰지 않기 때문에 나는 끝까지 여기에 있을 것이다."
라미 자피 경력
월플라워스는 1994년 인터스코프 레코드와 계약했다. 밴드의 다음 앨범을 프로듀싱하던 T 본 버넷과 작업하면서, 재피는 프로듀서인 폴 폭스, 맷 하이드, 릭 나이거의 세션 음악가로 자주 불려갔다. 이 때문에 1996년에는 리키 리 존스, 더 후커스, 레아 안드레오네, 초크 팜의 앨범에 이름을 올렸다. 동시에 월플라워스는 두 번째 앨범인 Bringing Down the Horse를 발매하여 쿼드러플 플래티넘을 기록했다. 밴드는 앨범을 지원하기 위해 투어를 했지만, 1997년에 재피와 그의 아내가 딸을 낳았고, 그는 두 달 동안 가족과 함께하기 위해 투어를 떠났다. 같은 해, 그는 에버클리어, 그랜트 리 버팔로, 리치 샘보라, 메이시 그레이, 제레미 토백, 조 헨리, 멀리사 에더리지, 램지 미드우드, 가스 브룩스와 세션 작업을 했다.
라미 자피 경력
월플라워스는 1998년 영화 고질라에 수록된 "Heroes"로 그래미 후보에 올랐다. 2000년 말, 밴드는 Breach를 발매했다. 밴드는 1년 동안 자신들의 투어를 주도했지만, 톰 페티 앤 더 하트브레이커스, 더 후, 존 멜런캠프의 오프닝 공연도 했다. 이어서 월플라워스는 Red Letter Days를 발매하고 2002년부터 2003년까지 다시 투어했다. 새로운 드러머와 함께 밴드는 2005년 5월 24일 다섯 번째 앨범인 Rebel, Sweetheart를 발매했다. 월플라워스는 앨범 홍보를 위해 투어를 했지만, 재피는 밴드와 의견이 맞지 않아 세 날짜를 남겨두고 투어를 중단했다.
2005년에 재피는 푸 파이터스와 협력하기 시작했다. 그는 2017년에 정식 멤버가 되었다.
재피는 더 프랜 드레셔 쇼의 하우스 밴드를 이끌었으며, 2010년 기준으로 샌퍼낸도밸리에 있는 포노제닉 스튜디오(Fonogenic Studios)라는 녹음 스튜디오를 공동 소유했다.
2012년과 2013년에 재피는 데이브 그롤이 결성한 슈퍼그룹인 사운드 시티 플레이어스의 멤버였다. 이 그룹은 그롤의 2013년 다큐멘터리 사운드 시티에 출연하는 것 외에도 2013년에 제한된 수의 투어 공연을 했다. 사운드 시티 플레이어스는 그롤, 재피, 스티비 닉스, 알랭 요한센, 폴 매카트니, 릭 스프링필드, 조시 호미, 트렌트 레즈너, 크리스 노보셀릭 등을 포함한 여러 아티스트들로 구성되어 있었다.
2012년에 재피는 오랜 공백기를 마치고 돌아온 월플라워스에 다시 합류했다. 그들은 2012년에 앨범 Glad All Over를 발매하고 그 해와 2013년에 이를 지원하는 투어를 했다. 그 후 재피는 다시 밴드를 떠났다.
시라오카 티머시
시라오카 티머시(일본어: 白岡 ティモシィ (しらおか ティモシィ), 1996년 9월 8일 ~ )는 일본의 축구 선수이다.
시라오카 티머시 구단 경력
이와키 FC, 홋카이도 도카치 스카이 어스, 오키나와 SV에서 활동했다.
시라오카 티머시 국가대표팀 경력
그는 2013년 FIFA U-17 월드컵에 참가할 일본 U-17 국가대표팀에 발탁되었으며, 2경기에 출전했다.
스즈키 도쿠마
스즈키 도쿠마(일본어: 鈴木 徳真 (すずき とくま), 1997년 3월 12일 ~ )는 일본의 축구 선수이다.
스즈키 도쿠마 구단 경력
2019년 J2리그의 도쿠시마 보르티스에 입단하였다. 2020년 J2리그 우승으로 J1리그로 승격하였다. 2021년 세레소 오사카로 이적했다. 2024년 감바 오사카로 이적했다.
스즈키 도쿠마 국가대표팀 경력
그는 2013년 FIFA U-17 월드컵에 참가할 일본 U-17 국가대표팀에 발탁되었으며, 2경기에 출전했다.
엘로쿠티오
엘로쿠티오(Elocutio, 그리스어: lexis 또는 phrasis) 또는 표현술은 서양 고전 수사학에서 방식 장치와 수사법을 숙달하는 것을 의미하는 라틴어 용어이다. 엘로쿠티오 또는 문체는 연설 및 글쓰기의 기술과 전달과 관련된 고전 수사학의 다섯 가지 카논 중 세 번째이다. (나머지는 인벤티오, 디스포시티오, 메모리아, 프로눈티아티오이다.)
엘로쿠티오 어원
엘로쿠티오라는 단어는 "말하다"를 의미하는 라틴어 loquor에서 유래했다. 엘로쿠티오는 일반적으로 수사학적 문체를 의미한다. 비슷한 용어로는 능변과 엘로쿠션(elocution)이 있다.
엘로쿠티오 요소
웅변가나 작가는 특정 담론에 대한 문체를 개발할 때 여러 가지를 결정해야 했다.
첫째, 문체 수준이 있었다. 평이한(attenuata 또는 subtile), 중간(mediocris 또는 robusta), 또는 높은(florida 또는 gravis) 수준이다. 작가들은 기본 문체를 주제와 청중에 맞추도록 지시받았다. 예를 들어, 마르쿠스 파비우스 퀸틸리아누스는 그의 인스티투티오 오라토리아(Institutio Oratoria)에서 평이한 문체는 지시에 적합하고, 중간 문체는 감동적인 웅변에, 높은 문체는 매력적인 담론에 적합하다고 보았다. 오늘날 엘로쿠션과 수사학은 마지막 문체와 관련되어 있지만, 수사학자들에게 각 문체는 수사학에서 유용했다.
고대 저자들은 좋은 문체를 달성하는 데 필요한 네 가지 요소가 정확성, 명료성, 적합성, 그리고 장식이라는 데 동의했다.
때때로 "순수성"으로 번역되는 정확성은 웅변가가 현재 통용되는 단어를 사용하고, 작성하는 언어의 문법 규칙을 준수해야 함을 의미했다. 정확성 규칙은 전통 문법에서 파생된 문법 및 용례 표준이다.