shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
성경에 따르면 아멜-마르두크는 유다의 왕 여호야긴을 바빌론 감옥에서 37년간의 투옥 끝에 해방시켰는데, 이는 아멜-마르두크에게 귀속된 유일한 구체적인 정치적 행위이다. 이러한 관대한 행위는 즉위식에서 흔히 볼 수 있으며, 이 경우에는 바빌론의 새해 축제와 관련되었을 수도 있지만, 여호야긴이 풀려난 구체적인 이유는 알려져 있지 않다. 제안된 이유로는 바빌로니아에 포로로 잡혀온 유대인들의 호감을 얻기 위함이거나, 아멜-마르두크와 여호야긴이 감옥에 있는 동안 친구가 되었을 수도 있다는 것이다. 후대 유대인 전통은 여호야긴의 석방이 유다 왕국을 멸망시킨 네부카드네자르의 정책에 대한 의도적인 역전이라고 보았다. 그러나 아멜-마르두크가 유다를 재건하려 했다는 어떤 징후도 없다. 그럼에도 불구하고, 아멜-마르두크가 티레의 잡힌 왕 바알레셀을 석방하고 그의 왕좌를 돌려주었기 때문에, 아멜-마르두크와 동시대에 살았던 유대인들은 여호야긴의 석방이 유다 재건의 첫 단계이기를 희망했을 가능성이 높다. 여호야긴의 석방은 열왕기하 25:27–30과 예라흐미엘 연대기에 기록되어 있으며, 두 자료 모두 아멜-마르두크를 에윌-므로닥으로 언급하고 있다. 예라흐미엘 연대기는 여호야긴의 석방을 다음과 같이 서술한다.
폐위와 사망.
아멜-마르두크의 통치는 기원전 560년 8월에 갑작스럽게 끝났다. 왕이 된 지 불과 2년 만에, 그의 매부인 네리그리사르에게 폐위되고 살해당했으며, 네리그리사르는 이후 왕위를 주장했다. 아멜-마르두크 통치 시기의 마지막 문서는 기원전 560년 8월 7일 바빌론에서 작성된 계약서이다. 4일 후, 네리그리사르 통치 시기로 날짜가 기재된 문서들이 바빌론과 우루크에서 발견되었다. 수도에서 그에게 귀속된 경제 활동이 증가한 것으로 미루어 볼 때, 네리그리사르는 찬탈 당시 바빌론에 있었다. 아멜-마르두크와 네리그리사르 간의 갈등은 다른 형태의 경쟁보다는 가족 내부의 불화 때문이었을 가능성이 높다. 네리그리사르는 네부카드네자르의 딸 중 한 명인 카샤야와 결혼했다. 카샤야는 아멜-마르두크와 다른 아들들보다 네부카드네자르 통치 초기(네부카드네자르 5년차, 기원전 600/599년)에 훨씬 일찍 기록되어 있으며, 그녀가 그들보다 나이가 많았을 가능성이 있다. 비록 카샤야에 대한 가장 초기의 언급과 아들들에 대한 언급 사이의 간격이 우연의 일치일 수도 있지만, 이는 또한 많은 아들들이 두 번째 결혼의 소생임을 나타내는 것으로 해석될 수도 있다. 따라서 네리그리사르의 찬탈은 네부카드네자르의 딸들, 특히 카샤야가 대표하는 더 오래되고 부유하며 영향력 있는 왕실 분파와, 덜 확고하고 어리지만 더 정당한 네부카드네자르의 아들들이 대표하는 분파 간의 내분으로 인한 것이었을 가능성이 있다.
바빌론 다리 기둥에서 발견된 그의 비문 중 하나에 따르면, 아멜-마르두크의 칭호는 다음과 같다: "아멜-마르두크, 바빌론의 왕, 에사길라와 에지다를 개축한 자, 바빌론 왕 네부카드네자르의 아들."
아멜-마르두크의 비문이 거의 알려져 있지 않기 때문에, 그의 칭호에 대한 더 정교한 형태는 알려져 있지 않다. 그는 다른 신바빌로니아 왕들이 사용했던 '수메르와 아카드의 왕'이라는 칭호도 사용했을 수 있다.
컴퓨터 과학에서 익명 파이프(anonymous pipe)는 단방향 프로세스 간 통신(IPC)에 사용될 수 있는 단방향 선입 선출 통신 채널이다. 구현은 종종 운영체제의 파일 입출력 서브시스템에 통합된다. 일반적으로 부모 프로그램이 익명 파이프를 열고, 파이프의 다른 끝을 상속하는 새 프로세스를 생성하거나, 여러 개의 새 프로세스를 생성하여 파이프라인으로 배열한다.
전이중 (양방향) 통신은 일반적으로 두 개의 익명 파이프를 필요로 한다.
파이프라인은 유닉스 및 도스를 비롯한 대부분의 인기 있는 운영체제에서 지원되며, 많은 셸에서 "codice_1" 문자를 사용하여 생성된다.
파이프라인은 많은 전통적인 유닉스 애플리케이션의 중요한 부분이며, 대부분의 유닉스 계열 운영체제에 잘 통합되어 지원된다. 파이프는 codice_2 시스템 호출을 사용하여 생성되며, 이는 새 파이프를 생성하고 파이프의 읽기 및 쓰기 끝을 참조하는 한 쌍의 파일 서술자를 반환한다. 많은 전통적인 유닉스 프로그램은 파이프와 함께 작동하도록 필터로 설계되었다.
윈도우 API의 다른 많은 장치 IO 및 IPC 기능과 마찬가지로, 익명 파이프는 IO 기능에 특정한 API 함수를 사용하여 생성 및 구성된다. 이 경우 codice_3는 파이프의 읽기 및 쓰기 끝에 대한 별도의 핸들을 가진 익명 파이프를 생성하는 데 사용된다. 파이프에 대한 읽기 및 쓰기 IO 작업은 표준 IO 기능 API 함수 codice_4 및 codice_5로 수행된다.
마이크로소프트 윈도우에서 익명 파이프에 대한 읽기 및 쓰기는 항상 블로킹된다. 즉, 빈 파이프에서 읽기는 최소한 한 바이트를 사용할 수 있거나 파이프의 쓰기 핸들이 닫힌 결과로 파일 끝이 수신될 때까지 호출 스레드가 기다리게 한다. 마찬가지로, 가득 찬 파이프에 대한 쓰기는 기록되는 데이터를 저장할 공간이 생길 때까지 호출 스레드가 기다리게 한다. 읽기는 요청된 바이트 수보다 적은 수의 바이트로 반환될 수 있다 (짧은 읽기라고도 함).
새 프로세스는 생성 프로세스에서 익명 파이프에 대한 핸들을 상속할 수 있다.
소프트웨어 공학에서 파이프라인은 각 요소의 출력이 다음 요소의 입력이 되도록 배열된 처리 요소(프로세스, 스레드, 코루틴, 함수 등)의 체인으로 구성된다. 이 개념은 물리적인 파이프라인과 유사하다. 일반적으로 연속적인 요소들 사이에 어느 정도의 버퍼링이 제공된다. 이러한 파이프라인에서 흐르는 정보는 종종 스트림 형태의 레코드, 바이트 또는 비트이며, 파이프라인의 요소는 필터라고 불릴 수 있다. 이것은 또한 디자인 패턴인 파이프 및 필터라고도 불리는데, 이는 모놀리식이다. 이 방식의 장점은 단순성과 저비용이며, 단점은 유연성, 내결함성 및 확장성이 부족하다는 점이다. 요소를 파이프라인으로 연결하는 것은 함수 합성과 유사하다.
좁은 의미에서 파이프라인은 선형적이고 단방향이지만, 때로는 더 일반적인 흐름에도 이 용어가 적용된다. 예를 들어, 주로 단방향 파이프라인은 되돌림 채널 또는 백채널이라고 알려진 다른 방향으로의 통신을 가질 수 있으며, 어휘 분석기 핵에서처럼 파이프라인은 완전히 양방향일 수도 있다. 단방향 트리와 유향 비순환 그래프 토폴로지를 가진 흐름은 선형 파이프라인과 유사하게 동작한다. 이러한 흐름에서 순환이 없으면 단순해지므로 느슨하게 "파이프라인"이라고 불릴 수 있다.
파이프라인은 종종 다중작업 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 프로그램을 허용하는 프레임워크를 정의한다.
IBM 메인프레임의 데이터는 일반적으로 레코드 지향 파일 시스템에 존재하며 연결된 I/O 장치는 스트림 모드 대신 레코드 모드로 작동한다. 결과적으로 CMS 파이프라인의 데이터는 레코드 모드로 처리된다. 텍스트 파일의 경우 레코드는 한 줄의 텍스트를 담는다. 일반적으로 CMS 파이프라인은 데이터를 버퍼링하지 않고 잠금 단계 방식으로 한 프로그램에서 다음 프로그램으로 데이터 레코드를 전달한다. 이는 상호 연결된 파이프라인 네트워크를 통한 데이터의 확정적 흐름을 보장한다.
객체 파이프라인.
바이트 스트림 기반 파이프라인 외에도 객체 파이프라인도 존재한다. 객체 파이프라인에서 처리 요소는 텍스트 대신 객체를 출력한다. 파워셸은 파워셸 런타임 내에서 함수 간에 .NET 객체를 전송하는 내부 객체 파이프라인을 포함한다. 림보 프로그래밍 언어에 있는 채널은 이러한 은유의 또 다른 예시이다.
GUI의 파이프라인.
RISC OS 및 ROX 데스크톱과 같은 그래픽 환경도 파이프라인을 사용한다. 사용자에게 프로그램이 데이터를 어디에 쓸지 지정하도록 파일 관리자를 포함하는 저장 대화 상자를 제공하는 대신, RISC OS 및 ROX는 아이콘 (및 이름을 지정하는 필드)을 포함하는 저장 대화 상자를 제공한다. 대상은 아이콘을 드래그 앤 드롭하여 지정된다. 사용자는 아이콘을 이미 저장된 파일이 놓일 수 있는 모든 곳, 즉 다른 프로그램의 아이콘 위에도 놓을 수 있다. 아이콘이 프로그램의 아이콘 위에 놓이면 프로그램이 로드되고, 그렇지 않으면 저장되었을 내용은 새 프로그램의 표준 입력 스트림으로 전달된다.
예를 들어, 월드 와이드 웹을 탐색하는 사용자는 압축된 .gz 이미지를 발견하여 편집하고 다시 업로드하고 싶을 수 있다. GUI 파이프라인을 사용하면 해당 링크를 압축 해제 프로그램으로 드래그하고, 추출된 콘텐츠를 나타내는 아이콘을 이미지 편집기로 드래그한 다음 편집하고, 다른 이름으로 저장 대화 상자를 열어 아이콘을 업로드 소프트웨어로 드래그할 수 있다.
개념적으로 이 방법은 기존 저장 대화 상자와 함께 사용될 수 있지만, 사용자 프로그램이 파일 시스템에서 명확하고 쉽게 접근할 수 있는 위치를 가져야 한다. 그러나 종종 그렇지 않으므로 GUI 파이프라인은 드물다.
기타 고려사항.
"파이프라인"이라는 이름은 물리적인 배관과의 대략적인 비유에서 비롯되었다. 파이프라인은 일반적으로 물이 파이프에서 흐르듯이 정보가 한 방향으로만 흐르도록 허용한다.
파이프와 필터는 바이트 스트림을 데이터 객체로 사용하는 함수형 프로그래밍의 한 형태로 볼 수 있다. 더 구체적으로, 모나드의 특정 형태로 볼 수 있다.
파이프라인 개념은 코쿤 웹 개발 프레임워크나 XProc (W3C 표준) 구현에서도 핵심적인 역할을 하며, 이를 통해 소스 스트림을 최종 표시 전에 수정할 수 있다.
이 패턴은 텍스트 스트림을 프로그램의 입력 및 출력으로 사용하는 것을 장려한다. 이러한 텍스트 의존성은 텍스트 프로그램에 대한 그래픽 셸을 만들 때 고려되어야 한다.
이들은 동시대 자료에서 명확하게 확인된 성경 인물이다. 고대이기는 하지만 동시대 문서가 아닌 곳에서 언급된 성경 인물은 이 목록에서 제외되었다. 즉, 여호아스 비문과 바룩 벤 네리야의 인장과 같이 진위 여부가 불확실한 유물에서 확인되거나, 다윗과 발람은 이 목록에서 제거되었다.
구약 성경.
성서고고학에서 '이스라엘'이라는 이름이 처음 언급된 것은 기원전 13세기로 거슬러 올라가지만 기원전 9세기 이전 이스라엘 민족에 대한 동시대 정보는 극히 드물다. 이후 몇 세기 동안, 대부분 도장과 인장으로 된 소수의 히브리어 현지 문헌들이 성경 인물들을 언급한다. 하지만 바빌론, 아시리아, 이집트와 같은 이웃 왕국의 왕실 비문에서 더 광범위한 정보를 얻을 수 있다.
제2경전.
제2경전은 기원전 8세기에서 2세기 사이의 사건을 묘사하지만, 제2경전에 언급된 역사적으로 식별 가능한 인물들은 대부분 셀레우코스 제국의 일부였던 유대에서 마카베오 전쟁 (기원전 167-160년) 시기에 살았다. 통치자들의 이름이 새겨진 주화가 널리 사용되었으며, 그 중 많은 주화에는 셀레우코스 시대의 연도가 새겨져 있어 정확한 연대 측정이 가능했다.
직접적인 정보는 또한 그리스 역사가 폴리비오스 (기원전 200년경 – 118년경)의 역사에서 얻을 수 있는데, 그의 역사는 마카베오서와 같은 시기를 다루며, 그리스 및 바빌론 비문에서도 얻을 수 있다. 플라비우스 요세푸스 또한 그의 유대 고대사 12권에서 마카베오 전쟁을 상세히 논하지만, 마카베오서 1권의 그리스어 버전이 요세푸스의 주요 자료 중 하나였기 때문에, 고대사는 일부 학자들에게 진정한 독립적 확인이라기보다는 순환 참조로 간주된다.
단연코 서기 1세기 유대 역사에 대한 가장 중요하고 상세한 자료는 유대 역사가 플라비우스 요세푸스 (37년경 – 100년경)의 저작이다. 이 책들은 신약성경에 나오는 많은 저명한 정치 인물들을 언급하며, 기독교 출현의 역사적 배경을 이해하는 데 결정적이다. 요세푸스는 또한 예수와 세례자 요한의 처형을 언급하지만, 그는 둘 중 누구의 동시대인도 아니었다. 요세푸스 외에 일부 신약성경 인물에 대한 정보는 타키투스와 수에토니우스와 같은 로마 역사가들과 고대 주화 및 비문에서 나온다.
잠정적으로 확인된 인물.
다음은 이름과 자격이 일치하는 동시대 자료에서 잠정적이지만 가능성이 있는 확인이 발견된 성경 인물들이다. 그러나 이름의 우연한 일치 가능성을 배제할 수는 없다.
2MASS J00084521+2350184은 NGC 8의 동반성이며, K형 주계열성이다.
컴퓨팅에서 codice_1는 POSIX를 준수하는 유닉스 시스템 호출로, 파일이나 장치를 메모리에 매핑한다. 이는 메모리 맵 파일 I/O 방식이다. 파일 내용이 디스크에서 즉시 읽히지 않고 초기에는 물리적 RAM을 전혀 사용하지 않으므로 요구 페이징을 구현한다. 디스크에서 실제 읽기는 특정 위치에 접근한 후 느긋한 방식으로 수행된다. 매핑이 더 이상 필요하지 않으면 codice_2를 사용하여 포인터를 언매핑해야 한다. 예를 들어, 매핑된 영역을 실행 가능으로 표시하는 것과 같은 보호 정보는 codice_3를 사용하여 관리할 수 있으며, codice_4를 사용하여 특별한 처리를 적용할 수 있다.
리눅스, macOS 및 BSD에서는 codice_5이 여러 유형의 매핑을 생성할 수 있다. 다른 운영체제는 이들 중 일부만 지원할 수 있다. 예를 들어, 전역 VFS 또는 I/O 캐시가 없는 운영체제에서는 공유 매핑이 실용적이지 않을 수 있다.
메모리 맵 파일의 원래 설계는 TOPS-20 운영체제에서 나왔다. codice_5 및 관련 시스템 호출은 유닉스 BSD 버전의 일부로 설계되었다. 이들의 API는 4.2BSD 시스템 매뉴얼에 이미 기술되었지만, 해당 릴리스나 4.3BSD에서는 구현되지 않았다. 그러나 썬 마이크로시스템즈는 썬OS 운영체제의 4.0 릴리스에서 이 API를 구현했다. 캘리포니아 대학교 버클리의 BSD 개발자들은 썬에 그 구현을 기부해 달라고 요청했지만 성공하지 못했다. 대신 4.3BSD-Reno는 Mach의 가상 메모리 시스템을 기반으로 한 구현과 함께 출시되었다.
파일 백업 및 익명.
파일 백업 매핑은 프로세스의 가상 메모리 영역을 파일에 매핑한다. 즉, 해당 메모리 영역을 읽으면 파일이 읽힌다. 이것이 기본 매핑 유형이다.
익명 매핑은 어떤 파일에도 백업되지 않은 프로세스의 가상 메모리 영역을 codice_7/codice_8 플래그를 통해 사용할 수 있도록 매핑한다. 내용은 0으로 초기화된다. 이러한 측면에서 익명 매핑은 malloc과 유사하며, 특정 할당, 특히 큰 할당을 위해 일부 malloc 구현에서 사용된다.
메모리 가시성.
매핑이 공유(codice_9 플래그가 설정됨)되면, 프로세스가 codice_10 시스템 호출을 사용하여 포크될 때 보존된다. 따라서 한 프로세스에서 매핑된 영역에 대한 쓰기는 관련된 모든(부모, 자식 또는 형제) 프로세스에서 즉시 볼 수 있다. 매핑이 공유되고 파일로 백업된 경우(codice_7가 아님) 기본 파일 매체는 codice_12 시스템 호출로 전달된 후에만 쓰기가 보장된다. 반면, 매핑이 사적(codice_13 플래그가 설정됨)인 경우 변경 사항은 다른 프로세스에 표시되지 않으며 파일에도 기록되지 않는다.
기본 파일을 읽거나 쓰는 프로세스는 파일을 매핑한 다른 프로세스와 항상 동일한 데이터를 보지는 않는다. 파일의 세그먼트가 RAM으로 복사되고 주기적으로 디스크로 플러시되기 때문이다. codice_12 호출을 통해 동기화를 강제할 수 있다.
파일에 mmap을 사용하면 동일한 파일에 접근하는 애플리케이션의 메모리 오버헤드를 크게 줄일 수 있다. 각 애플리케이션이 파일에 접근하기 위해 파일을 로드하는 대신, 파일이 포함하는 메모리 영역을 공유할 수 있다. 이는 mmap(2)이 때때로 프로세스 간 통신 (IPC)에 사용된다는 것을 의미한다. 최신 운영체제에서는 mmap(2)이 일반적으로 System V IPC 공유 메모리 기능보다 선호된다.
System V 공유 메모리(shmem)와 메모리 맵 I/O(mmap)의 주요 차이점은 System V 공유 메모리가 영구적이라는 것이다. 프로세스에 의해 명시적으로 제거되지 않는 한, 메모리에 유지되며 시스템이 종료될 때까지 계속 사용할 수 있다. mmap된 메모리는 애플리케이션 실행 간에 영구적이지 않다(파일로 백업되지 않은 경우).
C 프로그래밍 언어에서의 사용 예시.
/* This example shows how an mmap of /dev/zero is equivalent to
using anonymous memory (MAP_ANON) not connected to any file.
N.B. MAP_ANONYMOUS or MAP_ANON are supported by most UNIX
versions, removing the original purpose of /dev/zero.
/* Does not work on OS X or macOS, where you can't mmap over /dev/zero */
const char str1[] = "string 1";
const char str2[] = "string 2";
pid_t parpid = getpid(), childpid;
int fd = -1;
char *anon, *zero;
if ((fd = open("/dev/zero", O_RDWR, 0)) == -1)
err(1, "open");
anon = (char*)mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_ANON|MAP_SHARED, -1, 0);
zero = (char*)mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if (anon == MAP_FAILED || zero == MAP_FAILED)
errx(1, "either mmap");
strcpy(anon, str1);
strcpy(zero, str1);
printf("PID %d:\tanonymous %s, zero-backed %s\n", parpid, anon, zero);
switch ((childpid = fork())) {
case -1:
err(1, "fork");
/* NOTREACHED */
childpid = getpid();
printf("PID %d:\tanonymous %s, zero-backed %s\n", childpid, anon, zero);
sleep(3);
munmap(anon, 4096);
munmap(zero, 4096);
close(fd);
sleep(2);
strcpy(anon, str2);
strcpy(zero, str2);
샘플 출력:
데이터베이스 구현에서의 사용.
mmap 시스템 호출은 버퍼 풀 구현의 대안으로 다양한 데이터베이스 구현에서 사용되었지만, 이는 버퍼 풀을 통해서만 현실적으로 해결할 수 있는 다른 문제들을 야기했다.
2MASS J00084521+2350184은 NGC 8의 주성이며, K형 주계열성이다.
애플 이벤트(Apple event)는 Mac OS의 메시지 기반 프로세스 간 통신 메커니즘으로, 시스템 7에서 처음 등장한 이래 모든 맥 OS의 역사 버전과 macOS에서 지원되고 있다. 애플 이벤트는 "문서 열기" 또는 "파일 인쇄"와 같은 "고수준" 이벤트를 설명하는 반면, 초기 OS는 "클릭" 및 "키 누르기"와 같은 훨씬 더 기본적인 이벤트를 지원했다. 애플 이벤트는 맥 OS 스크립트 시스템인 오픈 스크립팅 아키텍처의 기반을 형성하며 (주요 언어는 애플스크립트이다).
시작점은 AEDesc라고 불리는 동적 타입의 확장 가능한 디스크립터 형식으로, 데이터 타입과 타입에 종속적인 데이터 블록을 지정하는 OSType 코드에 불과하다. 예를 들어, OSType 코드 codice_1는 데이터가 빅 엔디언 형식의 4바이트 부호 있는 정수임을 나타낸다.
다양한 공통 단순 타입에 대한 미리 정의된 타입 코드 외에도 두 가지 미리 정의된 구조화된 디스크립터 타입이 있다: 데이터 타입 codice_2(레코드)를 가진 AERecord와 타입 codice_3(목록 또는 배열)를 가진 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' 리소스를 제공할 수 있다.
예를 들어, 가상의 그리기 애플리케이션을 제어하는 다음 애플스크립트 시퀀스를 고려해 보자.
tell application "ScriptableDraw"
set background color of window "New Drawing" to background color of window "Old Drawing"
이것은 실제로 대상 애플리케이션으로 두 개의 애플이벤트를 전송하는 것을 포함한다 (그리고 해당 회신을 수신한다): 첫째, "Old Drawing"이라는 이름으로 식별되는 창의 배경색 속성을 검색하기 위해 get-data 이벤트가 전송된다; 그런 다음 반환된 값을 "New Drawing"이라는 이름의 창의 배경색 속성으로 적용하기 위해 set-data 이벤트가 전송된다.
이러한 종류의 접근 패턴이 일반적이었기 때문에, 애플스크립트는 비주얼 베이직 또는 파스칼에서 발견되는 codice_4 문과 유사한 방식으로 명명된 객체로 컨텍스트를 전환하는 codice_5 문을 널리 사용했다. codice_5 다음부터 해당 codice_7까지의 모든 명령은 기본 객체인 현재 애플리케이션 대신 codice_5에 명명된 객체로 전송되었다.
객체 디스크립터를 통해 다양한 방식으로 객체를 식별할 수 있었다. 가장 흥미로운 방법은 where-절(애플스크립트 용어로는 필터 표현식으로 번역됨)을 사용하는 것이었다. 예를 들어, 애플스크립트 1.0 SDK는 Scriptable Text Editor라는 예제 애플리케이션의 소스 코드를 제공했는데, 이 애플리케이션은 다음과 같은 스크립트에 응답했다.
tell application "Scriptable Text Editor"
tell window "Example Document"
set text style of every word whose length &gt; 7 to bold
오늘날에도 SQL 외의 범용 스크립트 언어에서 이러한 종류의 강력한 기능을 찾기는 드물다.
맥 OS의 역사에서 AEOM을 지원하는 것은 어려운 과정이었다. 애플리케이션 개발자는 객체를 식별하고 수동으로 코드를 작성하여 객체를 주소 지정할 수 있도록 해야 했다. 이는 일반적으로 특정 유형의 "다음" 객체를 반환하는 코드 형태로 이루어져 애플스크립트가 객체들을 반복할 수 있도록 했다. 그러나 OS 자체에 객체 모델이 없었기 때문에 이 작업은 전적으로 개발자의 몫이었고, 많은 개발자가 이를 구현하지 않았다. 이상하게도, 애플 자체의 애플리케이션 프레임워크인 MacApp조차도 GUI 객체를 제외하고는 이러한 모델을 제공하지 않아, 개발자가 데이터 자체를 나타내는 객체를 스크립팅하는 대부분의 작업을 다시 해야 했다. 주로 이러한 이유로 애플스크립트 지원은 그리 널리 퍼지지 않았다.
애플은 다양한 객체 "스위트"를 도입하여 이 문제를 해결하려고 시도했는데, 이는 다양한 유형의 애플리케이션에서 지원될 것으로 예상되는 표준 객체와 동사를 나타냈다. 예를 들어, 모든 애플리케이션은 "코어 스위트"를 지원해야 했고, 텍스트를 편집하는 애플리케이션은 "텍스트 스위트"를 지원해야 했다. 적절한 스위트 집합을 선택함으로써 개발자는 적어도 객체를 노출하는 방법에 대한 계획 작업을 줄일 수 있었다. 그러나 이러한 객체는 일반적으로 시스템 자체의 일부가 아니었기 때문에 (심하게 제한된 TextEdit 편집기를 제외하고), 실제 구현은 개발자에게 맡겨졌다.
이전에는 오픈스텝으로 알려진 시스템인 코코아에서 개발된 애플리케이션은 다른 모든 애플리케이션에서 쿼리할 수 있는 풍부한 객체 런타임을 제공한다. 이는 AEOM 구현을 상당히 쉽게 만들어 평균 애플리케이션에서 필요한 코드 양을 극적으로 줄여준다. 또한 대부분의 코코아 애플리케이션은 주로 코코아 표준 객체로 구성되며, 이 모든 객체는 상당히 광범위한 스크립트 가능성을 제공하도록 업그레이드되었다. 이는 MacApp에서와 같이 GUI 객체뿐만 아니라 텍스트, 테이블 및 다양한 목록 객체를 포함한 내부 데이터 객체에도 적용된다. 텍스트 파일은 내부 "객체 유사" 이름을 사람이 읽을 수 있는 버전으로 매핑하는 데 사용되며, 대부분의 경우 이 파일을 생성하는 것만으로도 대부분의 프로그램에 상당히 많은 스크립트 가능성을 추가할 수 있다.
코코아 애플리케이션은 AEOM 기반이 아니며, 애플이 원래 정의한 표준 객체와 미묘하게 다른 객체를 사용하는 경우가 많지만, 코코아 앱은 일반적으로 "클래식" 앱보다 훨씬 더 스크립트 가능성이 높다. 사실, 어느 정도 스크립트 불가능한 코코아 애플리케이션을 찾는 것은 드문 일이다.
스크립팅 브리지.
스크립팅 브리지는 애플스크립트와 같은 중간 스크립팅 언어를 사용하지 않고도 애플리케이션들이 서로 통신할 수 있게 해주는 macOS 프레임워크이다. 스크립팅 브리지는 애플스크립트와 마찬가지로 애플리케이션 간 통신을 위해 애플 이벤트를 사용한다.
스크립팅 브리지는 일반적으로 오브젝티브-C에서 사용되지만, MacRuby 및 PyObjC와 같은 오브젝티브-C 브리지를 통해 다른 프로그래밍 언어에서도 사용할 수 있다.
라미 자피(, 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에서 활동했다.
스즈키 도쿠마(, 1997년 3월 12일 ~ )는 일본의 축구 선수이다.
2019년 J2리그의 도쿠시마 보르티스에 입단하였다. 2020년 J2리그 우승으로 J1리그로 승격하였다. 2021년 세레소 오사카로 이적했다. 2024년 감바 오사카로 이적했다.
엘로쿠티오(Elocutio, 그리스어: lexis 또는 phrasis) 또는 표현술은 서양 고전 수사학에서 방식 장치와 수사법을 숙달하는 것을 의미하는 라틴어 용어이다. 엘로쿠티오 또는 문체는 연설 및 글쓰기의 기술과 전달과 관련된 고전 수사학의 다섯 가지 카논 중 세 번째이다. (나머지는 인벤티오, 디스포시티오, 메모리아, 프로눈티아티오이다.)
엘로쿠티오라는 단어는 "말하다"를 의미하는 라틴어 에서 유래했다. 엘로쿠티오는 일반적으로 수사학적 문체를 의미한다. 비슷한 용어로는 능변과 엘로쿠션(elocution)이 있다.
웅변가나 작가는 특정 담론에 대한 문체를 개발할 때 여러 가지를 결정해야 했다.
문체 수준.
첫째, 문체 수준이 있었다. 평이한(attenuata 또는 subtile), 중간(mediocris 또는 robusta), 또는 높은(florida 또는 gravis) 수준이다. 작가들은 기본 문체를 주제와 청중에 맞추도록 지시받았다. 예를 들어, 마르쿠스 파비우스 퀸틸리아누스는 그의 인스티투티오 오라토리아(Institutio Oratoria)에서 평이한 문체는 지시에 적합하고, 중간 문체는 감동적인 웅변에, 높은 문체는 매력적인 담론에 적합하다고 보았다. 오늘날 엘로쿠션과 수사학은 마지막 문체와 관련되어 있지만, 수사학자들에게 각 문체는 수사학에서 유용했다.
문체의 미덕.
고대 저자들은 좋은 문체를 달성하는 데 필요한 네 가지 요소가 정확성, 명료성, 적합성, 그리고 장식이라는 데 동의했다.
때때로 "순수성"으로 번역되는 정확성은 웅변가가 현재 통용되는 단어를 사용하고, 작성하는 언어의 문법 규칙을 준수해야 함을 의미했다. 정확성 규칙은 전통 문법에서 파생된 문법 및 용례 표준이다.
명료성과 관련하여 대부분의 고대 교사들은 명료성이란 웅변가가 일상적인 의미로 단어를 사용해야 함을 의미한다고 생각했다. 명료성의 목표는 창문을 통해 빛처럼 의미가 "빛나게" 하는 것이었다.
적합성은 아마도 주어진 상황에 적절한 것을 말하거나 행하는 것을 의미하는 그리스 수사학 개념 to prepon에서 파생되었을 것이다. 고대 교사들은 카이로스에 대한 면밀한 주의가 적절한 문체를 결정하는 데 도움이 될 것이라고 가르쳤다.
문체의 탁월함 중 마지막이자 가장 중요한 것은 장식인데, 이는 언어의 비범하거나 특이한 사용으로 정의된다.
문체 수사법.
장식은 크게 세 가지 범주로 나뉘었다: 언어 수사법, 사고 수사법, 그리고 수사적 전의. 언어 수사법은 언어의 모든 기교적인 패턴 또는 배열이다. 사고 수사법은 아이디어, 감정, 개념, 그리고 일반적인 논증 패턴에서 벗어나는 사고 수사법의 기교적인 표현이다. 수사적 전의는 하나의 용어를 다른 용어로 기교적으로 대체하는 것이다.
수사법에 많은 관심이 집중되었는데, 이는 다양한 유형과 하위 유형으로 분류되었다. 한 르네상스 작가인 헨리 피첨 (1546년생)은 184가지의 다른 수사법을 열거했지만, 이는 르네상스 시대에 시작된 문체에 대한 과도한 강조의 표현이라고 주장할 수 있다.
또한 엘로쿠티오에 중요한 것은 현재 일반적으로 문법적인 것으로 간주될 주제들이었다: 구두점과 접속사의 올바른 사용; 문장에서 단어의 바람직한 순서 (영어와 달리 많은 언어는 단어 간의 관계를 설정하는 데 단어 순서에 덜 의존하므로 단어 순서의 선택은 기능보다 형식에 더 중점을 둘 수 있음); 그리고 문장의 길이.
프론눈티아티오(Pronuntiatio) 또는 연기술은 서양 고전 수사학에서 연설을 전달하는 훈련이었다. 이것은 연설을 만들고 전달하는 데 관련된 고전 수사학의 다섯 가지 규범(나머지는 인벤티오, 디스포시티오, 엘로쿠티오, 메모리아) 중 하나이다. 문학에서 고대 프론눈티아티오의 동등어는 서사시의 낭송이다 (아리스토텔레스 시학 26.2.).
연설 암기를 다루는 규범인 메모리아와 마찬가지로, 프론눈티아티오는 고전 수사학 문헌에서 광범위하게 다뤄지지 않았다. 글이 수사학의 초점이 되면서 그 중요성은 더욱 감소했지만, 18세기 이후 길버트 오스틴과 같은 사람들의 작품에서 다시 더 많은 관심을 받았다.
수사학자들은 웅변을 전달할 때 목소리와 몸짓(행동) 사용에 대한 지침을 제시했다. 목소리의 적절한 조절(음량과 음높이), 그리고 말의 구절, 속도, 강조에 대한 지시가 있었다. 또한 웅변의 신체적 측면, 즉 자세, 몸짓, 태도, 얼굴 표정도 다루어졌다. 연설가들이 연설을 암기하고 전달을 연습할 수 있게 하는 엑세르키타티오(또는 연습 운동)의 개념도 있었다.
다음은 마르쿠스 파비우스 퀸틸리아누스의 《웅변술 교육》에서 수사학자들이 제공한 조언의 유형을 보여주는 예시이다:
웅변의 내용, 구조, 스타일은 (그리고 계속해서) 웅변의 가장 중요한 요소이지만, 효과적인 전달은 설득력을 높이고, 서투른 전달은 의도된 효과를 크게 저해한다.
전달은 시대의 기술을 기반으로 한다.
키케로 시대에는 전달이 주로 말하기였다. 문어가 발달하면서 글쓰기 전달이 발달했고, 이제 전달은 말하기와 글쓰기 모두를 포함한다. 기술은 글쓰기 전달과 구두 전달의 일부 구분을 없앴다.
읽기가 더 보편화될 때까지 문어 담화는 중요하지 않았다. 고대인들은 구두점을 사용하지 않았기 때문에 그들의 글은 스크립티오 콘티누아(scriptio continua)라고 불리는 길고 연속된 단어들의 흐름으로 구성되었다.
편집 과정에서 현대 수사학자들은 정확성 규칙, 서식, 발표라는 세 단계를 거쳐야 한다.
작가는 연설가보다 더 많은 문제에 직면하는데, 이는 철자, 구두점, 문법에 유의해야 하기 때문이다.
구두점은 문어 담화에서 유용하다. 왜냐하면 구두점은 생각의 끝을 표시하고 독자가 잠시 멈춰 정보를 처리할 수 있게 해주기 때문이다.
시각 수사학은 이미지와 단어가 이미지로서 어떻게 기능하는지에 초점을 맞춘다.
시각적 시연의 전달은 청중의 머릿속에 심상을 만들어내기 위해 단어를 사용하는 것이다. 텍스트 발표는 작가가 텍스트의 외양에 기초하여 독자가 텍스트를 실제로 읽기 전에 독자의 주의를 사로잡을 수 있도록 한다. 워드 프로세서의 발명은 작가가 텍스트의 외양을 향상시키고 특정 단어나 생각에 강조를 주기 위해 효과를 사용할 수 있도록 했다.
전달은 글이나 구어뿐만 아니라 사진, 그림 또는 영화도 지칭한다.
오가와 히로키(, 1997년 2월 23일 ~ )는 일본의 축구 선수이다.
《Metal Health》는 미국의 헤비 메탈 밴드 콰이어트 라이엇의 세 번째 스튜디오 음반으로, 1983년 2월 28일에 발매되었다. 이 음반에서는 슬레이드의 곡을 커버한 〈Cum On Feel the Noize〉와 타이틀곡 〈Metal Health〉 두 곡이 히트 싱글로 나왔다. 이 음반은 밴드의 첫 전 세계 동시 발매 음반으로, 이전 두 장의 음반은 일본에서만 발매되었다.
《Metal Health》는 빌보드 200 차트에서 1983년 11월에 폴리스의 《Synchronicity》를 제치고 헤비 메탈 음반으로는 최초로 1위를 차지하였다. 상업적인 성공 덕분에 이 음반은 이후 몇 년간 글램 메탈 장르의 폭발적인 인기를 여는 촉매제 역할을 했다고 평가받는다. 전 세계적으로 1,000만 장 이상 판매되었으며, 미국 내에서는 600만 장 이상이 판매되어 미국 음반 산업 협회로부터 6회 플래티넘 인증을 받았다.
밴드는 녹음 초기 단계에서 베이시스트 척 라이트와 결별했으며, 그의 대체자 게리 밴 다이크는 작업에 적합하지 않았다. 보컬리스트 케빈 듀브로우는 밴드의 전 베이시스트 루디 사르조에게 〈Thunderbird〉 녹음에 참여해줄 것을 요청했다. 이 곡은 1982년 비행기 사고로 사망한 밴드 창립자 랜디 로즈를 기리는 헌정곡이다. 듀브로우는 로즈가 살아 있을 때 이 곡을 쓰기 시작했지만, 기타리스트 사망 후에야 완성되었다. 이 협력은 매우 결실을 맺었고, 사르조는 여러 곡을 밴드와 함께 녹음했으며 결국 오지 오스본 자리를 떠나 콰이어트 라이엇에 정식 멤버로 복귀하게 되었다.
음반 홍보를 위해 콰이어트 라이엇은 미국에서 블랙 사바스의 Born Again Tour의 오프닝 무대를 맡았다. 또한 오지 오스본과 주다스 프리스트 같은 유명 아티스트들과 함께 1983년 US 페스티벌 출연도 성사시켰다. 콰이어트 라이엇의 US 페스티벌 공연 직전, 사르조는 몇 달 전에 자신을 떠나 콰이어트 라이엇으로 복귀한 베이시스트에 대한 앙금이 남아 있던 술에 취한 오스본에게 백스테이지에서 얼굴을 맞았다.
밴드가 이후에 《Metal Health》의 상업적 성공을 재현하지 못하면서, 콰이어트 라이엇은 때때로 "원 히트 원더"로 불리기도 한다. 그러나 이는 정확하지 않은 표현이다. 밴드는 빌보드 핫 100 차트에서 두 곡이 톱 40에 진입했으며, 이후 발매한 음반도 미국 음반 산업 협회로부터 100만 장 이상의 판매를 기록해 플래티넘 인증을 받았다. 타이틀곡은 VH1의 '역사상 가장 위대한 메탈 송 40선'에서 35위에 랭크되었다. 〈Slick Black Cadillac〉은 밴드가 1978년에 발표한 음반 《Quiet Riot II》에 수록된 곡을 재녹음한 것이다.
커버 아트는 스탠 와츠가 디자인했으며, 그는 이전에 두비 브라더스의 《Best of The Doobies Volume II》 (1981년), 블랙 사바스의 《Live Evil》 (1982년), 마틴 브릴리의 《One Night with a Stranger》 (1983년) 커버와 영화 《하울링》 (1981년) 포스터를 디자인한 바 있다. 프랭키 바날리는 콰이어트 라이엇이 밴드의 상징을 만들고자 했으며, 루디 사르조가 알렉상드르 뒤마의 소설 《철가면 남자》 (1847년)와 유사한 콘셉트를 제안했다고 밝혔다. 많은 이들이 가면을 쓴 커버 모델이 케빈 듀브로우라고 생각했으나, 실제로는 와츠 자신이었고, 그의 아내가 찍은 사진을 와츠가 에어브러시로 처리해 "극적이고 강한 대비 효과"를 냈다. 이 가면은 매우 인기를 끌어 듀브로우가 밴드의 다음 음반인 1984년작 《Condition Critical》 커버에서 비슷한 가면을 착용했다.
와타나베 료마(, 1996년 10월 2일 ~ )는 일본의 축구 선수이다.
2018년 J2리그의 알비렉스 니가타에 입단하였다. 2020년 몬테디오 야마가타로 이적했다. 2021년 J1리그의 FC 도쿄로 이적했다. 2024년 우라와 레즈로 이적했다.
그는 2013년 FIFA U-17 월드컵에 참가할 일본 U-17 국가대표팀에 발탁되었으며, 2경기에 출전, 3득점을 넣었다.