From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Sep 8 09:21:05 2014 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id ED544357122; Mon, 8 Sep 2014 09:21:04 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 660 seconds by postgrey-1.34 at www5.open-std.org; Mon, 08 Sep 2014 09:21:02 CEST Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by www.open-std.org (Postfix) with ESMTP id 111A5356824 for ; Mon, 8 Sep 2014 09:21:00 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 08 Sep 2014 00:09:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="txt'?scan'208,217";a="382850659" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by FMSMGA003.fm.intel.com with ESMTP; 08 Sep 2014 00:04:56 -0700 Received: from orsmsx103.amr.corp.intel.com ([169.254.2.241]) by ORSMSX102.amr.corp.intel.com ([169.254.1.108]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 00:09:51 -0700 From: "Whitlock, Stan" To: WG5 Subject: J3/14-233 J3 Fortran interp letter ballot #31 - due 6-Oct-2014 Thread-Topic: J3/14-233 J3 Fortran interp letter ballot #31 - due 6-Oct-2014 Thread-Index: Ac/LM7mPOtTA/FX8TMqbuYvysZm4Xw== Date: Mon, 8 Sep 2014 07:09:50 +0000 Message-ID: <4AA982B1265F43408480F737BE12F4D35F92E4F5@ORSMSX103.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: multipart/mixed; boundary="_004_4AA982B1265F43408480F737BE12F4D35F92E4F5ORSMSX103amrcor_" MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk --_004_4AA982B1265F43408480F737BE12F4D35F92E4F5ORSMSX103amrcor_ Content-Type: multipart/alternative; boundary="_000_4AA982B1265F43408480F737BE12F4D35F92E4F5ORSMSX103amrcor_" --_000_4AA982B1265F43408480F737BE12F4D35F92E4F5ORSMSX103amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable = J3/14-233 To: J3 Members From: Stan Whitlock Subject: J3 Fortran interp letter ballot #31 - due 6-Oct-2014 Date: 8-Sep-2014 Enclosed in the next letter ballot on Fortran interpretations. The rules by which we operate say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 7 Fortran interpretations are currently "Passed by J3 meeting" after J3 meeting #204. This is the letter ballot phase to go from "Passed by J3 meeting" to "Passed by J3 letter ballot". The following Fortran interpretations are being balloted: Yes No Number Title --- --- F08/0108 ultimate components and coarrays --- --- F08/0109 LOCK_TYPE and unlimited polymorphic --- --- F08/0110 Interdependence of specifier values in input/output statements --- --- F08/0111 Undefinition --- --- F08/0112 STAT=3D and ERRMSG=3D in ALLOCATE and DEALLOCATE --- --- F08/0113 Specifiers in image control statements --- --- F08/0114 Can LOCK_TYPE components have the POINTER attribute? The text of these interpretations is attached. Each interpretation starts with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail message} with any comments to j3@j3-fortran.org by 11:59:59PM, PDT, Monday, 6-Oct-2014, in order to be counted. Thanks /Stan ------------------------------------------------------------------------ NUMBER: F08/0108 TITLE: ultimate components and coarrays KEYWORD: ultimate components, coarrays DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTIONS: 1. Is the declaration of V permitted: type :: one real, allocatable :: C[:] end type one type :: two type(one), allocatable :: A end type two type(two), pointer :: V(:) 2. Is the declaration of X permitted: type :: three real :: C end type three type :: four type(three), allocatable :: A[:] end type four type(four) :: X ANSWERS: 1. Type two is not conforming, because the entity A has a coarray ultimate component and C525 requires such an entity to be a nonpointer nonallocatable scalar. Therefore the declaration of V is not permitted. 2. X satisfies C525, so declaration of X is permitted. X has an ultimate (allocatable) coarray component (A[:]), and therefore acording to C526 must be a dummy argument or have the ALLOCATABLE or SAVE attribute. EDITS: None. SUBMITTED BY: Van Snyder HISTORY: 14-163 m204 F08/0108 submitted 14-163r1 m204 Fixed examples in questions, revised answer - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0109 TITLE: LOCK_TYPE and unlimited polymorphic KEYWORD: LOCK_TYPE, unlimited polymorphic DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Assume type LOCK_TYPE from the intrinsic module ISO_Fortran_Env is available. Q1. Is allocation of X%C permitted? TYPE t TYPE(LOCK_TYPE),ALLOCATABLE :: c END TYPE TYPE(t) :: x[*],y[*] ALLOCATE(y%c) ALLOCATE(x%c,SOURCE=3Dy%c) Q2. Is allocation of C permitted? class(*), pointer :: C type(lock_type), intent(in) :: L[*] allocate ( C, source=3DL ) Q3. Is allocation of C permitted? class(*), pointer :: C allocate ( LOCK_TYPE :: C ) Q4. Is pointer assignment to C permitted? class(*), pointer :: C type(lock_type), intent(in), target :: L[*] c =3D> L Q5. Is this ALLOCATE statement conforming? CLASS(*),ALLOCATABLE :: C[:] TYPE(LOCK_TYPE) :: X ALLOCATE(C,MOLD=3DX) ANSWER: A1. Allocation of X%C is not intended to be allowed. An edit is supplied to correct the requirements on allocation of LOCK_TYPE. A2. Allocation of C is not intended to be allowed. An edit is supplied to correct the requirements on allocation of LOCK_TYPE. A3. This allocation of C is permitted. A4. Pointer assignment to C is permitted. A5. This statement was intended to be permitted. An edit is supplied to correct the requirements. EDITS: [6:7+] After definition 1.3.33.2 parent component, insert new term "1.3.33.2a potential subobject component nonpointer component, or potential subobject component of a nonpointer component (4.5.1)". [127:8-9] 6.7.1.1 Syntax, C643, Change "C_PTR," to "C_PTR or" Delete ", LOCK_TYPE ... LOCK_TYPE". [127:9+] Insert new constraint "C643a (R627) If SOURCE=3D appears, the declared type of shall not be LOCK_TYPE or have a potential subobject component of type LOCK_TYPE." [127:18-19] 6.7.1.1, p4, "If" -> "If an ALLOCATE statement has a SOURCE=3D specifier and an", {There is no problem with MOLD=3D. "subcomponent" works ok here because we have an object not a type.} SUBMITTED BY: Van Snyder HISTORY: 14-164 m204 F08/0109 submitted 14-164r3 m204 As amended, passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0110 TITLE: Interdependence of specifier values in input/output statements KEYWORD: specifier, input/output statement DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTIONS: 1. Are the following INQUIRE statements permitted? LOGICAL :: Exist, Opened INQUIRE ( FILE=3D'fred', EXIST=3Dexist ) INQUIRE ( UNIT=3D42, OPENED=3Dopened 2. Is the following INQUIRE statement permitted? INTEGER :: U INTERFACE FUNCTION P ( A ) INTEGER, INTENT(IN) :: A INTEGER, POINTER :: P END FUNCTION P END INTERFACE INQUIRE ( FILE=3D'fred', NUMBER=3Du, POSITION=3Dp(u) ) 3. Is the following READ statement permitted? INTEGER :: STATS(42) NAMELIST /IN/ V READ ( *, IN, IOSTAT=3DSTATS(V) ) ANSWERS: 1. According to 9.12p5 "The value of a specifier in an input/output statement shall not depend on the definition or evaluation of any other specifier in the or in that statement." the INQUIRE statements are prohibited because the values of the variables EXIST and OPEN depend upon the values of the FILE=3D and UNIT=3D specifiers, respectively. They were intended to be permitted. Edits are provided to correct this mistake. 2. According to 9.12p6 "The value of any subscript or substring bound of a variable that appears in a specifier in an input/output statement shall not depend on any , , or on the definition or evaluation of any other specifier in the or in that statement." the INQUIRE statement is not prohibited because U is not a subscript or substring bound. It was intended to be prohibited. Edits are provided to correct this mistake. 3. According to 9.12p5 "The value of any subscript or substring bound of a variable that appears in a specifier in an input/output statement shall not depend on any , , or on the definition or evaluation of any other specifier in the or in that statement." and 9.12p7 "In a data transfer statement, the variable specified in an IOSTAT=3D, IOMSG=3D, or SIZE=3D specifier, if any, shall not be associated with any entity in the ... ...." and 9.12p8 "In a data transfer statement, if a variable specified in an IOSTAT=3D, IOMSG=3D, or SIZE=3D specifier is an array element reference, its subscript values shall not be affected by the data transfer, the processing, or the definition or evaluation of any other specifier in the ." the READ statement is not prohibited because V does not "depend on any , , or on the definition or evaluation of any other specifier in the or in that statement." Although V is input from namelist, it is not "the variable specified in an IOSTAT=3D, IOMSG=3D, or SIZE=3D specifier." The READ statement was intended to be prohibited. Edits are provided to correct this mistake. EDITS to 10-007r1: [243:3-4 9.12p5] Within the first sentence, as amended by Corrigendum 2, replace "input/output" with "data transfer" and delete "or ", so that the sentence, as amended by Corrigendum 2, becomes "The value of a specifier in a data transfer statement shall not depend on the evaluation of any other specifier in the in that statement." If we assume that the UNIT=3D , FILE=3D , or ID=3D in an are established before the values of any of the s are changed, we need not append "The value of a , , or in an shall not depend upon the definition of any variable in that ." [243:6, 12-15 9.12p6,8] Replace the paragraphs: "In an input/output statement, the value of any argument in a function reference that is a , any subscript, or any substring bound, that appears in a specifier in that statement, shall not be affected by data transfer or processing caused by that statement, or definition or evaluation of any other specifier in the or in that statement." SUBMITTED BY: Van Snyder HISTORY: 14-193 m204 F08/0110 submitted 14-193r1 m204 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0111 TITLE: Undefinition KEYWORD: undefinition DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTIONS: 1. Does the following cause D to become undefined? Ought it? integer :: I(2) double precision :: D equivalence ( D, I ) d =3D 42.0 i(1) =3D 666 2. Does the following cause C to become undefined? Ought it? integer, parameter :: RK =3D kind(0.0d0) real(rk), pointer :: P complex(rk), target :: C =3D ( 1.0, 2.0 ) c =3D ( 1.0d0, 2.0d0 ) p =3D> c%re p =3D 24.0d0 3. Does the following cause D1 to become undefined? Does it cause C%IM to become undefined? Ought it? integer, parameter :: RK =3D kind(0.0d0) real(rk), pointer :: D1, D2 complex(rk), target :: C c =3D ( 1.0d0, 2.0d0 ) d1 =3D> c%re d2 =3D> c%im call s ( d2 ) ... contains subroutine S ( D ) real(rk), intent(out) :: D .... 4. Does the following cause Y to become undefined? Ought it? type :: T1 sequence integer :: C1 =3D 42 end type T1 type :: T2 sequence real :: C1 =3D 42.0e0 end type T2 type(t1) :: X type(t2) :: Y equivalence ( X, Y ) x =3D t1(21) ANSWERS: 1. Item (1) in subclause 16.6.6 says "When a scalar variable of intrinsic type becomes defined, all totally associated variables of different type become undefined.... When a scalar variable becomes undefined, all partially associated double precision scalar variables become undefined." D is not totally associated with I. I does not become undefined. Therefore, D does not become undefined. D ought to become undefined. Edits are provided to correct this mistake. 2. Item (1) in subclause 16.6.6 says "When a double precision scalar variable becomes defined, all partially associated scalar variables become undefined." P is partly associated with C, and therefore C becomes undefined by the assignment to the scalar variable P. C ought not to become undefined. Edits are provided to correct this mistake. 3. Item (1) in subclause 16.6.6 says "When a scalar variable becomes undefined, all partially associated double precision scalar variables become undefined." Subclause 16.6.1p5 says "A complex... scalar object is defined if and only if all of its subobjects are defined." The association of the scalar variable D2 with an INTENT(OUT) dummy argument causes it become undefined. 16.6.6p1(1) does not specify that when a scalar real variable becomes undefined, a totally associated part of a complex variable becomes undefined. Assuming C%IM ought to become undefined, then C ought to become undefined, even though C%RE is not undefined. D1 is associated with the C%RE, and therefore becomes undefined when C%IM becomes undefined. C%IM ought to become undefined, and D1 ought not to become undefined. Edits are provided to correct this mistake. 4. Item (1) in subclause 16.6.6 says "When a scalar variable of intrinsic type becomes defined, all totally associated variables of different type become undefined. X and Y are totally associated, and of different type, but neither one is of intrinsic type. Therefore, Y does not become undefined as a consequence of X becoming defined. Y ought to become undefined. Edits are provided to correct this mistake. EDITS: In Subclause 16.6.6p1, item(1), within the first sentence, remove "of intrinsic type". Before "different" insert "the same type with different values of kind type parameters, or of" In Subclause 16.6.6p1, replace item(1) with the following four sentences (all in one paragraph) "When a scalar variable becomes defined, all totally associated variables of different type become undefined. {Removing "of intrinsic type" from the existing first sentence of 16.6.6p1(1) addresses question 4.} When a scalar variable becomes defined, all partially associated variables of different type, or of the same type if corresponding kind type parameters have different values, become undefined, unless the scalar variable is totally associated with a subobject of the partially associated variable, that subobject is of the same type as the scalar variable, and corresponding kind type parameters have the same values. {This addresses questions 1 and 2. The references to kind type parameter values address the possibility of partially associating a double precision variable with a default real variable. Default real and double precision are now the same type (since 1990), but with a different kind type parameter value.} When a scalar variable becomes undefined, all partially associated variables become undefined, unless the partially associated variable is totally associated with a subobject of the scalar variable that does not become undefined. When a scalar variable becomes undefined, all totally associated subobjects of other variables become undefined if those subobjects are of different type from the scalar variable, or corresponding kind type parameters have different values." {The third and fourth sentences address question 3.} SUBMITTED BY: Van Snyder HISTORY: 14-195 m204 F08/0111 submitted - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0112 TITLE: STAT=3D and ERRMSG=3D in ALLOCATE and DEALLOCATE KEYWORDS: STAT=3D, ERRMSG=3D, ALLOCATE, DEALLOCATE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider CHARACTER(80) text(0:100), msg INTEGER stat,istat(0:80) REAL,ALLOCATABLE :: x(:),y(:,:) ... ALLOCATE(x(10),STAT=3Dstat,ERRMSG=3Dtext(stat)) ! A DEALLOCATE(x,STAT=3Dstat,ERRMSG=3Dtext(stat)) ! B msg =3D '' ALLOCATE(y(999999,999999),STAT=3Distat(LEN_TRIM(msg)),ERRMSG=3Dmsg) ! C msg =3D '' DEALLOCATE(x,STAT=3Distat(LEN_TRIM(msg)),ERRMSG=3Dmsg) ! D In each of the statements labelled A-D, there is a dependency between the STAT=3D specifier and the ERRMSG=3D specifier (from STAT=3D to ERRMSG= =3D in A and B, and from ERRMSG=3D to STAT in C and D). There appears to be no prohibition against this (though there are many prohibitions against other dependencies in ALLOCATE and DEALLOCATE). Are all these examples conforming, and if so, is the dependent variable referenced with the value of the other variable at the beginning of execution of the statement or at the end of execution of the statement? ANSWER: These are not standard-conforming, as no interpretation is established for them. An edit is supplied to clarify this prohibition. EDITS: [132:4] 6.7.4 STAT=3D specifier, p1, append "The shall not depend on the value of the .". [132:22] 6.7.5 ERRMSG=3D specifier, p1, append "The shall not depend on the value of the .". SUBMITTED BY: Malcolm Cohen HISTORY: 14-208 m204 F08/0112 submitted - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0113 TITLE: Specifiers in image control statements KEYWORDS: STAT=3D, ERRMSG=3D, ACQUIRED_LOCK=3D, image control DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider CHARACTER(80) text(0:100),msg INTEGER stat,istat(2) REAL,ALLOCATABLE :: x(:) TYPE(LOCK_TYPE) :: lock[*], alock(0:80)[*] LOGICAL acq, aacq(0:80) ... SYNC ALL(STAT=3Dstat,ERRMSG=3Dtext(stat)) ! A SYNC IMAGES (*,STAT=3Dstat,ERRMSG=3Dtext(stat)) ! B SYNC MEMORY(STAT=3Dstat,ERRMSG=3Dtext(stat)) ! C LOCK(lock,ACQUIRED_LOCK=3Dacq, & STAT=3Distat(MERGE(1,2,acq)), & ERRMSG=3Dtext(istat(MERGE(1,2,acq)))) ! D UNLOCK(lock,STAT=3Dstat,ERRMSG=3Dtext(stat)) ! E LOCK(alock(stat),STAT=3Dstat) ! F msg =3D '' UNLOCK(alock(LEN_TRIM(msg)),STAT=3Dstat, & ERRMSG=3Dmsg) ! G stat =3D 13 SYNC IMAGES(stat,STAT=3Dstat) ! H msg =3D 'oops' SYNC IMAGES(LEN_TRIM(msg),STAT=3Dstat, & ERRMSG=3Dmsg) ! I In each of the statements labelled A-F, there is a dependency between the STAT=3D specifier and the ERRMSG=3D specifier. There appears to be no prohibition against this. Additionally, in the LOCK statement (D), there is a dependency between the ACQUIRED_LOCK=3D specifier and the STAT=3D specifier (there is no dependency between ACQUIRED_LOCK=3D and ERRMSG=3D because the former is only set on successful execution and the latter is only set on an error condition). There appears to be no restrictions at all on any dependencies from ACQUIRED_LOCK=3D. In the LOCK statement (F), there is a dependency between the STAT=3D specifier and the lock variable. Similarly for the UNLOCK (G), there is a dependency between the lock variable and the ERRMSG=3D specifier. In the SYNC IMAGES statement (H), there is a dependency between the STAT=3D variable and the image set. In the SYNC IMAGES statement (I), there is a dependency between the ERRMSG=3D variable and the image set. Are all these examples conforming, and if so, is the dependent variable referenced with the value of the other variable at the beginning of execution of the statement or at the end of execution of the statement? ANSWER: No interpretation is established and therefore these are not conforming. An edit is provided to clarify this. EDITS: [190:16-] 8.5.4 SYNC IMAGES statement, insert new p1, "The value of shall not depend on the value of or .". [194:6-] 8.5.6 LOCK and UNLOCK statements, insert new p1, "The shall not depend on the value of , , or the in the ACQUIRED_LOCK=3D specifier. The shall not depend on the , , or .". [195:2-] 8.5.7 STAT=3D and ERRMSG=3D specifiers..., insert new p1, "The shall not depend on the value of the , , or the in the ACQUIRED_LOCK=3D specifier. The shall not depend on the value of the , , or the in the ACQUIRED_LOCK=3D specifier.". SUBMITTED BY: Malcolm Cohen HISTORY: 14-209 m204 F08/0113 submitted - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0114 TITLE: Can LOCK_TYPE components have the POINTER attribute? KEYWORD: LOCK_TYPE component, POINTER DEFECT TYPE: Erratum STATUS: Passed by J3 meeting Assume LOCK_TYPE is accessible from ISO_Fortran_Env. QUESTION: The following type definition and variable declaration are permitted by C1302: type :: One type(lock_type), pointer :: L end type One type(one), allocatable :: L1[*] C1302 requires a named variable of LOCK_TYPE to be a coarray. C526 requires a coarray to be allocatable or to have the SAVE attribute. The following declaration is apparently prohibited because L4 is not a coarray: type(lock_type), pointer :: L4 Was it intended that pointer components of type LOCK_TYPE be permitted, but that named variables of type LOCK_TYPE with the POINTER attribute be prohibited? ANSWER: It was intended that components of type LOCK_TYPE not be permitted to have the POINTER attribute. Edits are provided to correct this mistake. EDITS: [399:18+] 13.8.2.16 LOCK_TYPE, after C1302, insert new constraint "C1302a A component of type LOCK_TYPE, or that has a nonallocatable direct component of type LOCK_TYPE, shall not have the POINTER attribute.". SUBMITTED BY: Van Snyder HISTORY: 14-140 m204 F08/0114 submitted 14-140r1 m204 Revised to reverse decision 14-140r2 m204 Passed by J3 meeting ---------------------------------------------------------------------- --_000_4AA982B1265F43408480F737BE12F4D35F92E4F5ORSMSX103amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;            =            J3/14-233=

To:         =   J3 Members

From:       Stan Whitl= ock

Subject:   J3 Fortran interp letter ballot= #31 - due 6-Oct-2014

Date:        8-Se= p-2014

 

Enclosed in the next letter ballot on Fortran interp= retations.

 

The rules by which we operate say:

 

    o   J3 votes on the ans= wer at a J3 meeting; a simple majority

        vote mark= s the answer as "passed by J3 meeting".

 

    o   Between J3 meetings= the chair of /interp sends a J3 letter

        ballot to= J3 to approve interp answers that have been "passed

        by J3 mee= ting".  The letter ballot runs for 30 days.  Not<= /p>

        voting on= three of four consecutive J3 letter ballots is

        grounds t= o terminate J3 membership.  An interp answer passes

        by a 2/3r= ds vote;  a no vote must be accompanied by an

        explanati= on of the changes necessary to change the member's

        vote to y= es.

 

        J3/interp= reserves the right to recall an interp answer for

        more stud= y even if the answer passes.

 

7 Fortran interpretations are currently "Passed= by J3 meeting" after

J3 meeting #204.  This is the letter ballot pha= se to go from "Passed

by J3 meeting" to "Passed by J3 letter bal= lot".

 

The following Fortran interpretations are being ball= oted:

 

Yes  No   Number   &nb= sp; Title

 

---  ---  F08/0108   ultimate co= mponents and coarrays

---  ---  F08/0109   LOCK_TYPE a= nd unlimited polymorphic

---  ---  F08/0110   Interdepend= ence of specifier values in input/output

        &nbs= p;             =          statements=

---  ---  F08/0111   Undefinitio= n

---  ---  F08/0112   STAT=3D and= ERRMSG=3D in ALLOCATE and DEALLOCATE

---  ---  F08/0113   Specifiers = in image control statements

---  ---  F08/0114   Can LOCK_TY= PE components have the POINTER attribute?

 

The text of these interpretations is attached. = Each interpretation

starts with a row of "-"s.

 

Please mark the above -Y- in the Yes column for &quo= t;yes", -C- in the Yes

column for "yes with comment", or -N- in t= he No column for a "no"

answer {be sure to include your reasons with "n= o"} and send only the

above text {not this entire mail message} with any c= omments to

 

        j3@j3-for= tran.org

 

by 11:59:59PM, PDT, Monday, 6-Oct-2014, in order to = be counted.

 

 

Thanks       &nbs= p;            &= nbsp;    /Stan

 

----------------------------------------------------= --------------------

 

NUMBER: F08/0108

TITLE: ultimate components and coarrays

KEYWORD: ultimate components, coarrays

DEFECT TYPE: Interpretation

STATUS: Passed by J3 meeting

 

QUESTIONS:

 

1. Is the declaration of V permitted:

 

  type :: one

    real, allocatable :: C[:]

  end type one

 

  type :: two

    type(one), allocatable :: A<= /o:p>

  end type two

 

  type(two), pointer :: V(:)

 

2. Is the declaration of X permitted:

 

  type :: three

    real :: C

  end type three

 

  type :: four

    type(three), allocatable :: A[:]<= o:p>

  end type four

 

  type(four) :: X

 

ANSWERS:

 

1. Type two is not conforming, because the entity A = has a coarray

   ultimate component and C525 requires su= ch an entity to be a

   nonpointer nonallocatable scalar. = Therefore the declaration of V

   is not permitted.

 

2. X satisfies C525, so declaration of X is permitte= d.  X has an

   ultimate (allocatable) coarray componen= t (A[:]), and therefore

   acording to C526 must be a dummy argume= nt or have the ALLOCATABLE

   or SAVE attribute.

 

EDITS:

 

None.

 

SUBMITTED BY: Van Snyder

 

HISTORY: 14-163    m204  F08/010= 8 submitted

         14-= 163r1  m204  Fixed examples in questions, revised

        &nbs= p;            &= nbsp;   answer - passed by J3 meeting

 

----------------------------------------------------= ------------------

 

NUMBER: F08/0109

TITLE: LOCK_TYPE and unlimited polymorphic

KEYWORD: LOCK_TYPE, unlimited polymorphic=

DEFECT TYPE: Erratum

STATUS: Passed by J3 meeting

 

QUESTION:

 

Assume type LOCK_TYPE from the intrinsic module ISO_= Fortran_Env is

available.

 

Q1. Is allocation of X%C permitted?

 

  TYPE t

    TYPE(LOCK_TYPE),ALLOCATABLE :: c<= o:p>

  END TYPE

  TYPE(t) :: x[*],y[*]

  ALLOCATE(y%c)

  ALLOCATE(x%c,SOURCE=3Dy%c)

 

Q2. Is allocation of C permitted?

 

  class(*), pointer :: C

  type(lock_type), intent(in) :: L[*]

 

  allocate ( C, source=3DL )

 

Q3. Is allocation of C permitted?

 

  class(*), pointer :: C

 

  allocate ( LOCK_TYPE :: C )

 

Q4. Is pointer assignment to C permitted?=

 

  class(*), pointer :: C

  type(lock_type), intent(in), target :: L[*]

 

  c =3D> L

 

Q5. Is this ALLOCATE statement conforming?

 

  CLASS(*),ALLOCATABLE :: C[:]

  TYPE(LOCK_TYPE) :: X

  ALLOCATE(C,MOLD=3DX)

 

ANSWER:

 

A1. Allocation of X%C is not intended to be allowed.=   An edit is

    supplied to correct the requireme= nts on allocation of LOCK_TYPE.

 

A2. Allocation of C is not intended to be allowed.&n= bsp; An edit is

    supplied to correct the requireme= nts on allocation of LOCK_TYPE.

 

A3. This allocation of C is permitted.

 

A4. Pointer assignment to C is permitted.=

 

A5. This statement was intended to be permitted.&nbs= p; An edit is supplied

    to correct the requirements.=

 

EDITS:

 

[6:7+] After definition 1.3.33.2 parent componen= t, insert new term

  "1.3.33.2a

   potential subobject component

   nonpointer component, or potential subo= bject component of a

   nonpointer component (4.5.1)".

 

[127:8-9] 6.7.1.1 Syntax, C643,

         &nb= sp;Change "C_PTR," to "C_PTR or"

        &nbs= p; Delete ", LOCK_TYPE ... LOCK_TYPE".

 

[127:9+] Insert new constraint

  "C643a (R627) If SOURCE=3D appears, the = declared type of <source-expr>

         sha= ll not be LOCK_TYPE or have a potential subobject

         com= ponent of type LOCK_TYPE."

 

[127:18-19] 6.7.1.1, p4,

  "If" -> "If an ALLOCATE sta= tement has a SOURCE=3D specifier and an",

{There is no problem with MOLD=3D.  "subco= mponent" works ok here because

we have an object not a type.}

 

SUBMITTED BY: Van Snyder

 

HISTORY: 14-164    m204  F08/010= 9 submitted

         14-= 164r3  m204  As amended, passed by J3 meeting

 

----------------------------------------------------= ------------------

 

NUMBER: F08/0110

TITLE: Interdependence of specifier values in input/= output statements

KEYWORD: specifier, input/output statement

DEFECT TYPE: Erratum

STATUS: Passed by J3 meeting

 

QUESTIONS:

 

1. Are the following INQUIRE statements permitted?

 

    LOGICAL :: Exist, Opened

    INQUIRE ( FILE=3D'fred', EXIST=3D= exist )

    INQUIRE ( UNIT=3D42, OPENED=3Dope= ned

 

2. Is the following INQUIRE statement permitted?

 

    INTEGER :: U

    INTERFACE

      FUNCTION P ( A )=

        INTEGER, = INTENT(IN) :: A

        INTEGER, = POINTER :: P

      END FUNCTION P

    END INTERFACE

    INQUIRE ( FILE=3D'fred', NUMBER= =3Du, POSITION=3Dp(u) )

 

3. Is the following READ statement permitted?

 

    INTEGER :: STATS(42)

    NAMELIST /IN/ V

    READ ( *, IN, IOSTAT=3DSTATS(V) )=

 

ANSWERS:

 

1. According to 9.12p5

 

  "The value of a specifier in an input/ou= tput statement shall not

  depend on the definition or evaluation of any= other specifier in the

  <io-control-spec-list> or <inquire-s= pec-list> in that statement."

 

the INQUIRE statements are prohibited because the va= lues of the

variables EXIST and OPEN depend upon the values of t= he FILE=3D and UNIT=3D

specifiers, respectively.  They were intended t= o be permitted.  Edits

are provided to correct this mistake.

 

2. According to 9.12p6

 

  "The value of any subscript or substring= bound of a variable that

  appears in a specifier in an input/output sta= tement shall not depend

  on any <input-item>, <io-implied-do&= gt; <do-variable>, or on the

  definition or evaluation of any other specifi= er in the

  <io-control-spec> or <inquire-spec&g= t; in that statement."

 

the INQUIRE statement is not prohibited because U is= not a subscript or

substring bound.  It was intended to be prohibi= ted.  Edits are provided

to correct this mistake.

 

3. According to 9.12p5

 

  "The value of any subscript or substring= bound of a variable that

  appears in a specifier in an input/output sta= tement shall not depend

  on any <input-item>, <io-implied-do&= gt; <do-variable>, or on the

  definition or evaluation of any other specifi= er in the

  <io-control-spec> or <inquire-spec&g= t; in that statement."

 

and 9.12p7

 

  "In a data transfer statement, the varia= ble specified in an IOSTAT=3D,

  IOMSG=3D, or SIZE=3D specifier, if any, shall= not be associated with any

  entity in the ... <namelist-group-object-l= ist>...."

 

and 9.12p8

 

  "In a data transfer statement, if a vari= able specified in an IOSTAT=3D,

  IOMSG=3D, or SIZE=3D specifier is an array el= ement reference, its

  subscript values shall not be affected by the= data transfer, the

  <io-implied-do> processing, or the defi= nition or evaluation of any

  other specifier in the <io-control-spec-li= st>."

 

the READ statement is not prohibited because V does = not "depend on any

<input-item>, <io-implied-do> <do-var= iable>, or on the definition or

evaluation of any other specifier in the <io-cont= rol-spec> or

<inquire-spec> in that statement." &= nbsp; Although V is input from namelist,

it is not "the variable specified in an IOSTAT= =3D, IOMSG=3D, or SIZE=3D

specifier."  The READ statement was intend= ed to be prohibited.  Edits

are provided to correct this mistake.

 

EDITS to 10-007r1:

 

[243:3-4 9.12p5] Within the first sentence, as amend= ed by Corrigendum 2,

replace "input/output" with "data tra= nsfer" and delete "or

<inquire-spec-list>", so that the sentenc= e, as amended by Corrigendum

2, becomes

 

  "The value of a specifier in a data tran= sfer statement shall not

  depend on the evaluation of any other specifi= er in the

  <io-control-spec-list> in that statemen= t."

 

If we assume that the UNIT=3D <file-unit-number&g= t;, FILE=3D <file-name-expr>,

or ID=3D <scalar-int-expr> in an <inquire-s= pec-list> are established

before the values of any of the <variable>s ar= e changed, we need not

append

 

  "The value of a <file-unit-number>= , <file-name-expr>, or

  <scalar-int-expr> in an <inquire-spe= c-list> shall not depend upon the

  definition of any variable in that <inquir= e-spec-list>."

 

[243:6, 12-15 9.12p6,8] Replace the paragraphs:=

 

  "In an input/output statement, the value= of any argument in a function

  reference that is a <variable>, any sub= script, or any substring bound,

 that appears in a specifier in that statement,= shall not be affected

  by data transfer or <implied-do> proces= sing caused by that statement,

  or definition or evaluation of any other spec= ifier in the

  <io-control-spec-list> or <inquire-s= pec-list> in that statement."

 

SUBMITTED BY: Van Snyder

 

HISTORY: 14-193    m204  F08/011= 0 submitted

         14-= 193r1  m204  Passed by J3 meeting

 

----------------------------------------------------= ------------------

 

NUMBER: F08/0111

TITLE: Undefinition

KEYWORD: undefinition

DEFECT TYPE: Erratum

STATUS: Passed by J3 meeting

 

QUESTIONS:

 

1. Does the following cause D to become undefined?&n= bsp; Ought it?

 

  integer :: I(2)

  double precision :: D

  equivalence ( D, I )

  d =3D 42.0

  i(1) =3D 666

 

2. Does the following cause C to become undefined?&n= bsp; Ought it?

 

  integer, parameter :: RK =3D kind(0.0d0)=

  real(rk), pointer :: P

  complex(rk), target :: C =3D ( 1.0, 2.0 )

  c =3D ( 1.0d0, 2.0d0 )

  p =3D> c%re

  p =3D 24.0d0

 

3. Does the following cause D1 to become undefined?&= nbsp; Does it cause C%IM

to become undefined?  Ought it?

 

  integer, parameter :: RK =3D kind(0.0d0)=

  real(rk), pointer :: D1, D2

  complex(rk), target :: C

  c =3D ( 1.0d0, 2.0d0 )

  d1 =3D> c%re

  d2 =3D> c%im

  call s ( d2 )

  ...

  contains

    subroutine S ( D )

      real(rk), intent(out)= :: D

  ....

 

4. Does the following cause Y to become undefined?&n= bsp; Ought it?

 

  type :: T1

    sequence

    integer :: C1 =3D 42

  end type T1

  type :: T2

    sequence

    real :: C1 =3D 42.0e0<= /p>

  end type T2

  type(t1) :: X

  type(t2) :: Y

  equivalence ( X, Y )

  x =3D t1(21)

 

ANSWERS:

 

1. Item (1) in subclause 16.6.6 says

 

  "When a scalar variable of intrinsic typ= e becomes defined, all totally

  associated variables of different type become= undefined....  When a

  scalar variable becomes undefined, all partia= lly associated double

  precision scalar variables become undefined.&= quot;

 

D is not totally associated with I.  I does not= become undefined.

Therefore, D does not become undefined.  D ough= t to become undefined.

Edits are provided to correct this mistake.

 

2. Item (1) in subclause 16.6.6 says

 

  "When a double precision scalar variable= becomes defined, all

  partially associated scalar variables become = undefined."

 

P is partly associated with C, and therefore C becom= es undefined by the

assignment to the scalar variable P.  C ought n= ot to become undefined.

Edits are provided to correct this mistake.

 

3. Item (1) in subclause 16.6.6 says

 

  "When a scalar variable becomes undefine= d, all partially associated

  double precision scalar variables become unde= fined."

 

  Subclause 16.6.1p5 says

 

  "A complex... scalar object is defined i= f and only if all of its

  subobjects are defined."

 

The association of the scalar variable D2 with an IN= TENT(OUT) dummy

argument causes it become undefined.  16.6.6p1(= 1) does not specify that

when a scalar real variable becomes undefined, a tot= ally associated part

of a complex variable becomes undefined.  Assum= ing C%IM ought to become

undefined, then C ought to become undefined, even th= ough C%RE is not

undefined.  D1 is associated with the C%RE, and= therefore becomes

undefined when C%IM becomes undefined.  C%IM ou= ght to become undefined,

and D1 ought not to become undefined.  Edits ar= e provided to correct

this mistake.

 

4. Item (1) in subclause 16.6.6 says

 

  "When a scalar variable of intrinsic typ= e becomes defined, all totally

  associated variables of different type become= undefined.

 

X and Y are totally associated, and of different typ= e, but neither one is

of intrinsic type.  Therefore, Y does not becom= e undefined as a

consequence of X becoming defined.  Y ought to = become undefined.  Edits

are provided to correct this mistake.

 

EDITS:

 

In Subclause 16.6.6p1, item(1), within the first sen= tence, remove "of

intrinsic type".  Before "different&q= uot; insert "the same type with

different values of kind type parameters, or of"= ;

 

In Subclause 16.6.6p1, replace item(1) with the foll= owing four sentences

(all in one paragraph)

 

  "When a scalar variable becomes defined,= all totally associated

  variables of different type become undefined.=

 

{Removing "of intrinsic type" from the exi= sting first sentence of

16.6.6p1(1) addresses question 4.}

 

  When a scalar variable becomes defined, all p= artially associated

  variables of different type, or of the same t= ype if corresponding kind

  type parameters have different values, become= undefined, unless the

  scalar variable is totally associated with a = subobject of the

  partially associated variable, that subobject= is of the same type as

  the scalar variable, and corresponding kind t= ype parameters have the

  same values.

 

{This addresses questions 1 and 2.  The referen= ces to kind type

parameter values address the possibility of partiall= y associating a

double precision variable with a default real variab= le.  Default real

and double precision are now the same type (since 19= 90), but with a

different kind type parameter value.}

 

  When a scalar variable becomes undefined, all= partially associated

  variables become undefined, unless the partia= lly associated variable

  is totally associated with a subobject of the= scalar variable that

  does not become undefined.

 

  When a scalar variable becomes undefined, all= totally associated

  subobjects of other variables become undefine= d if those subobjects are

  of different type from the scalar variable, o= r corresponding kind type

  parameters have different values."<= /o:p>

 

{The third and fourth sentences address question 3.}=

 

SUBMITTED BY: Van Snyder

 

HISTORY: 14-195    m204  F08/011= 1 submitted - passed by J3 meeting

 

----------------------------------------------------= ------------------

 

NUMBER: F08/0112

TITLE: STAT=3D and ERRMSG=3D in ALLOCATE and DEALLOC= ATE

KEYWORDS: STAT=3D, ERRMSG=3D, ALLOCATE, DEALLOCATE

DEFECT TYPE: Erratum

STATUS: Passed by J3 meeting

 

QUESTION:

 

Consider

 

  CHARACTER(80) text(0:100), msg

  INTEGER stat,istat(0:80)

  REAL,ALLOCATABLE :: x(:),y(:,:)

  ...

  ALLOCATE(x(10),STAT=3Dstat,ERRMSG=3Dtext(stat= )) ! A

  DEALLOCATE(x,STAT=3Dstat,ERRMSG=3Dtext(stat))=    ! B

  msg =3D ''

  ALLOCATE(y(999999,999999),STAT=3Distat(LEN_TR= IM(msg)),ERRMSG=3Dmsg) ! C

  msg =3D ''

  DEALLOCATE(x,STAT=3Distat(LEN_TRIM(msg)),ERRM= SG=3Dmsg) ! D

 

In each of the statements labelled A-D, there is a d= ependency between

the STAT=3D specifier and the ERRMSG=3D specifier (f= rom STAT=3D to ERRMSG=3D

in A and B, and from ERRMSG=3D to STAT in C and D).&= nbsp; There appears to be

no prohibition against this (though there are many p= rohibitions

against other dependencies in ALLOCATE and DEALLOCAT= E).

 

Are all these examples conforming, and if so, is the= dependent

variable referenced with the value of the other vari= able at the

beginning of execution of the statement or at the en= d of execution of

the statement?

 

ANSWER:

 

These are not standard-conforming, as no interpretat= ion is established

for them.  An edit is supplied to clarify this = prohibition.

 

EDITS:

 

[132:4] 6.7.4 STAT=3D specifier, p1, append

  "The <stat-variable> shall not dep= end on the value of the

   <errmsg-variable>.".

 

[132:22] 6.7.5 ERRMSG=3D specifier, p1, append<= /o:p>

  "The <errmsg-variable> shall not d= epend on the value of the

   <stat-variable>.".

 

SUBMITTED BY: Malcolm Cohen

 

HISTORY: 14-208    m204  F08/011= 2 submitted - passed by J3 meeting

 

----------------------------------------------------= ------------------

 

NUMBER: F08/0113

TITLE: Specifiers in image control statements

KEYWORDS: STAT=3D, ERRMSG=3D, ACQUIRED_LOCK=3D, imag= e control

DEFECT TYPE: Erratum

STATUS: Passed by J3 meeting

 

QUESTION:

 

Consider

 

  CHARACTER(80) text(0:100),msg

  INTEGER stat,istat(2)

  REAL,ALLOCATABLE :: x(:)

  TYPE(LOCK_TYPE) :: lock[*], alock(0:80)[*]

  LOGICAL acq, aacq(0:80)

  ...

  SYNC ALL(STAT=3Dstat,ERRMSG=3Dtext(stat))&nbs= p;      ! A

  SYNC IMAGES (*,STAT=3Dstat,ERRMSG=3Dtext(stat= )) ! B

  SYNC MEMORY(STAT=3Dstat,ERRMSG=3Dtext(stat))&= nbsp;   ! C

  LOCK(lock,ACQUIRED_LOCK=3Dacq, &

       STAT=3Distat(ME= RGE(1,2,acq)), &

       ERRMSG=3Dtext(i= stat(MERGE(1,2,acq))))    ! D

  UNLOCK(lock,STAT=3Dstat,ERRMSG=3Dtext(stat))&= nbsp;   ! E

  LOCK(alock(stat),STAT=3Dstat)   &nb= sp;            =  ! F

  msg =3D ''

  UNLOCK(alock(LEN_TRIM(msg)),STAT=3Dstat, &= ;

         ERR= MSG=3Dmsg)           = ;            &n= bsp;  ! G

  stat =3D 13

  SYNC IMAGES(stat,STAT=3Dstat)  &nbs= p;            &= nbsp; ! H

  msg =3D 'oops'

  SYNC IMAGES(LEN_TRIM(msg),STAT=3Dstat, &<= o:p>

        &nbs= p;     ERRMSG=3Dmsg)      = ;            &n= bsp;  ! I

 

In each of the statements labelled A-F, there is a d= ependency between

the STAT=3D specifier and the ERRMSG=3D specifier.&n= bsp; There appears to be no

prohibition against this.

 

Additionally, in the LOCK statement (D), there is a = dependency between

the ACQUIRED_LOCK=3D specifier and the STAT=3D speci= fier (there is no

dependency between ACQUIRED_LOCK=3D and ERRMSG=3D be= cause the former is

only set on successful execution and the latter is o= nly set on an

error condition).  There appears to be no restr= ictions at all on any

dependencies from ACQUIRED_LOCK=3D.

 

In the LOCK statement (F), there is a dependency bet= ween the STAT=3D

specifier and the lock variable.  Similarly for= the UNLOCK (G), there

is a dependency between the lock variable and the ER= RMSG=3D specifier.

 

In the SYNC IMAGES statement (H), there is a depende= ncy between the

STAT=3D variable and the image set.  In the SYN= C IMAGES statement (I),

there is a dependency between the ERRMSG=3D variable= and the image set.

 

Are all these examples conforming, and if so, is the= dependent

variable referenced with the value of the other vari= able at the

beginning of execution of the statement or at the en= d of execution of

the statement?

 

ANSWER:

 

No interpretation is established and therefore these= are not

conforming.  An edit is provided to clarify thi= s.

 

EDITS:

 

[190:16-] 8.5.4 SYNC IMAGES statement, insert new p1= ,

  "The value of <image-set> shall no= t depend on the value of

   <stat-variable> or <errmsg-var= iable>.".

 

[194:6-] 8.5.6 LOCK and UNLOCK statements, insert ne= w p1,

  "The <lock-variable> shall not dep= end on the value of

   <stat-variable>, <errmsg-varia= ble>, or the

   <scalar-logical-variable> in the = ACQUIRED_LOCK=3D specifier.

   The <scalar-logical-variable> sha= ll not depend on the

   <lock-variable>, <stat-variabl= e>, or <errmsg-variable>.".

 

[195:2-] 8.5.7 STAT=3D and ERRMSG=3D specifiers..., = insert new p1,

  "The <stat-variable> shall not dep= end on the value of the

   <errmsg-variable>, <lock-varia= ble>, or the

   <scalar-logical-variable> in the = ACQUIRED_LOCK=3D specifier.

   The <errmsg-variable> shall not d= epend on the value of the

   <stat-variable>, <lock-variabl= e>, or the <scalar-logical-variable>

   in the ACQUIRED_LOCK=3D specifier."= ;.

 

SUBMITTED BY: Malcolm Cohen

 

HISTORY: 14-209    m204  F08/011= 3 submitted - passed by J3 meeting

 

----------------------------------------------------= ------------------

 

NUMBER: F08/0114

TITLE: Can LOCK_TYPE components have the POINTER att= ribute?

KEYWORD: LOCK_TYPE component, POINTER

DEFECT TYPE: Erratum

STATUS: Passed by J3 meeting

 

Assume LOCK_TYPE is accessible from ISO_Fortran_Env.=

 

QUESTION:

 

The following type definition and variable declarati= on are permitted by

C1302:

 

  type :: One

    type(lock_type), pointer :: L

  end type One

 

  type(one), allocatable :: L1[*]

 

C1302 requires a named variable of LOCK_TYPE to be a= coarray.  C526

requires a coarray to be allocatable or to have the = SAVE attribute.

 

The following declaration is apparently prohibited b= ecause L4 is

not a coarray:

 

  type(lock_type), pointer :: L4

 

Was it intended that pointer components of type LOCK= _TYPE be permitted,

but that named variables of type LOCK_TYPE with the = POINTER attribute be

prohibited?

 

ANSWER:

 

It was intended that components of type LOCK_TYPE no= t be permitted to

have the POINTER attribute.  Edits are provided= to correct this mistake.

 

EDITS:

 

[399:18+] 13.8.2.16 LOCK_TYPE, after C1302, inse= rt new constraint

  "C1302a A component of type LOCK_TYPE, o= r that has a nonallocatable

         dir= ect component of type LOCK_TYPE, shall not have the

         POI= NTER attribute.".

 

SUBMITTED BY: Van Snyder

 

HISTORY: 14-140    m204  F08/011= 4 submitted

         14-= 140r1  m204  Revised to reverse decision

         14-= 140r2  m204  Passed by J3 meeting

 

----------------------------------------------------= ------------------

--_000_4AA982B1265F43408480F737BE12F4D35F92E4F5ORSMSX103amrcor_-- --_004_4AA982B1265F43408480F737BE12F4D35F92E4F5ORSMSX103amrcor_ Content-Type: text/plain; name="14-233 interp LB #31 m205 due 6-Oct-2014.txt" Content-Description: 14-233 interp LB #31 m205 due 6-Oct-2014.txt Content-Disposition: attachment; filename="14-233 interp LB #31 m205 due 6-Oct-2014.txt"; size=22733; creation-date="Mon, 08 Sep 2014 07:04:47 GMT"; modification-date="Mon, 08 Sep 2014 07:04:32 GMT" Content-Transfer-Encoding: base64 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBK My8xNC0yMzMNClRvOiAgICAgICAgSjMgTWVtYmVycw0KRnJvbTogICAgICBTdGFuIFdoaXRsb2Nr DQpTdWJqZWN0OiAgIEozIEZvcnRyYW4gaW50ZXJwIGxldHRlciBiYWxsb3QgIzMxIC0gZHVlIDYt T2N0LTIwMTQNCkRhdGU6ICAgICAgOC1TZXAtMjAxNA0KDQpFbmNsb3NlZCBpbiB0aGUgbmV4dCBs ZXR0ZXIgYmFsbG90IG9uIEZvcnRyYW4gaW50ZXJwcmV0YXRpb25zLg0KDQpUaGUgcnVsZXMgYnkg d2hpY2ggd2Ugb3BlcmF0ZSBzYXk6DQoNCiAgICBvICAgSjMgdm90ZXMgb24gdGhlIGFuc3dlciBh dCBhIEozIG1lZXRpbmc7IGEgc2ltcGxlIG1ham9yaXR5DQogICAgICAgIHZvdGUgbWFya3MgdGhl IGFuc3dlciBhcyAicGFzc2VkIGJ5IEozIG1lZXRpbmciLg0KDQogICAgbyAgIEJldHdlZW4gSjMg bWVldGluZ3MgdGhlIGNoYWlyIG9mIC9pbnRlcnAgc2VuZHMgYSBKMyBsZXR0ZXINCiAgICAgICAg YmFsbG90IHRvIEozIHRvIGFwcHJvdmUgaW50ZXJwIGFuc3dlcnMgdGhhdCBoYXZlIGJlZW4gInBh c3NlZA0KICAgICAgICBieSBKMyBtZWV0aW5nIi4gIFRoZSBsZXR0ZXIgYmFsbG90IHJ1bnMgZm9y IDMwIGRheXMuICBOb3QNCiAgICAgICAgdm90aW5nIG9uIHRocmVlIG9mIGZvdXIgY29uc2VjdXRp dmUgSjMgbGV0dGVyIGJhbGxvdHMgaXMNCiAgICAgICAgZ3JvdW5kcyB0byB0ZXJtaW5hdGUgSjMg bWVtYmVyc2hpcC4gIEFuIGludGVycCBhbnN3ZXIgcGFzc2VzDQogICAgICAgIGJ5IGEgMi8zcmRz IHZvdGU7ICBhIG5vIHZvdGUgbXVzdCBiZSBhY2NvbXBhbmllZCBieSBhbg0KICAgICAgICBleHBs YW5hdGlvbiBvZiB0aGUgY2hhbmdlcyBuZWNlc3NhcnkgdG8gY2hhbmdlIHRoZSBtZW1iZXIncw0K ICAgICAgICB2b3RlIHRvIHllcy4NCg0KICAgICAgICBKMy9pbnRlcnAgcmVzZXJ2ZXMgdGhlIHJp Z2h0IHRvIHJlY2FsbCBhbiBpbnRlcnAgYW5zd2VyIGZvcg0KICAgICAgICBtb3JlIHN0dWR5IGV2 ZW4gaWYgdGhlIGFuc3dlciBwYXNzZXMuDQoNCjcgRm9ydHJhbiBpbnRlcnByZXRhdGlvbnMgYXJl IGN1cnJlbnRseSAiUGFzc2VkIGJ5IEozIG1lZXRpbmciIGFmdGVyDQpKMyBtZWV0aW5nICMyMDQu ICBUaGlzIGlzIHRoZSBsZXR0ZXIgYmFsbG90IHBoYXNlIHRvIGdvIGZyb20gIlBhc3NlZA0KYnkg SjMgbWVldGluZyIgdG8gIlBhc3NlZCBieSBKMyBsZXR0ZXIgYmFsbG90Ii4NCg0KVGhlIGZvbGxv d2luZyBGb3J0cmFuIGludGVycHJldGF0aW9ucyBhcmUgYmVpbmcgYmFsbG90ZWQ6DQoNClllcyAg Tm8gICBOdW1iZXIgICAgIFRpdGxlDQoNCi0tLSAgLS0tICBGMDgvMDEwOCAgIHVsdGltYXRlIGNv bXBvbmVudHMgYW5kIGNvYXJyYXlzDQotLS0gIC0tLSAgRjA4LzAxMDkgICBMT0NLX1RZUEUgYW5k IHVubGltaXRlZCBwb2x5bW9ycGhpYw0KLS0tICAtLS0gIEYwOC8wMTEwICAgSW50ZXJkZXBlbmRl bmNlIG9mIHNwZWNpZmllciB2YWx1ZXMgaW4gaW5wdXQvb3V0cHV0DQogICAgICAgICAgICAgICAg ICAgICAgIHN0YXRlbWVudHMNCi0tLSAgLS0tICBGMDgvMDExMSAgIFVuZGVmaW5pdGlvbg0KLS0t ICAtLS0gIEYwOC8wMTEyICAgU1RBVD0gYW5kIEVSUk1TRz0gaW4gQUxMT0NBVEUgYW5kIERFQUxM T0NBVEUNCi0tLSAgLS0tICBGMDgvMDExMyAgIFNwZWNpZmllcnMgaW4gaW1hZ2UgY29udHJvbCBz dGF0ZW1lbnRzDQotLS0gIC0tLSAgRjA4LzAxMTQgICBDYW4gTE9DS19UWVBFIGNvbXBvbmVudHMg aGF2ZSB0aGUgUE9JTlRFUiBhdHRyaWJ1dGU/DQoNClRoZSB0ZXh0IG9mIHRoZXNlIGludGVycHJl dGF0aW9ucyBpcyBhdHRhY2hlZC4gIEVhY2ggaW50ZXJwcmV0YXRpb24NCnN0YXJ0cyB3aXRoIGEg cm93IG9mICItInMuDQoNClBsZWFzZSBtYXJrIHRoZSBhYm92ZSAtWS0gaW4gdGhlIFllcyBjb2x1 bW4gZm9yICJ5ZXMiLCAtQy0gaW4gdGhlIFllcw0KY29sdW1uIGZvciAieWVzIHdpdGggY29tbWVu dCIsIG9yIC1OLSBpbiB0aGUgTm8gY29sdW1uIGZvciBhICJubyINCmFuc3dlciB7YmUgc3VyZSB0 byBpbmNsdWRlIHlvdXIgcmVhc29ucyB3aXRoICJubyJ9IGFuZCBzZW5kIG9ubHkgdGhlDQphYm92 ZSB0ZXh0IHtub3QgdGhpcyBlbnRpcmUgbWFpbCBtZXNzYWdlfSB3aXRoIGFueSBjb21tZW50cyB0 bw0KDQogICAgICAgIGozQGozLWZvcnRyYW4ub3JnDQoNCmJ5IDExOjU5OjU5UE0sIFBEVCwgTW9u ZGF5LCA2LU9jdC0yMDE0LCBpbiBvcmRlciB0byBiZSBjb3VudGVkLg0KDQoNClRoYW5rcyAgICAg ICAgICAgICAgICAgICAgICAgICAvU3Rhbg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTlVNQkVSOiBG MDgvMDEwOA0KVElUTEU6IHVsdGltYXRlIGNvbXBvbmVudHMgYW5kIGNvYXJyYXlzDQpLRVlXT1JE OiB1bHRpbWF0ZSBjb21wb25lbnRzLCBjb2FycmF5cw0KREVGRUNUIFRZUEU6IEludGVycHJldGF0 aW9uDQpTVEFUVVM6IFBhc3NlZCBieSBKMyBtZWV0aW5nDQoNClFVRVNUSU9OUzoNCg0KMS4gSXMg dGhlIGRlY2xhcmF0aW9uIG9mIFYgcGVybWl0dGVkOg0KDQogIHR5cGUgOjogb25lDQogICAgcmVh bCwgYWxsb2NhdGFibGUgOjogQ1s6XQ0KICBlbmQgdHlwZSBvbmUNCg0KICB0eXBlIDo6IHR3bw0K ICAgIHR5cGUob25lKSwgYWxsb2NhdGFibGUgOjogQQ0KICBlbmQgdHlwZSB0d28NCg0KICB0eXBl KHR3byksIHBvaW50ZXIgOjogVig6KQ0KDQoyLiBJcyB0aGUgZGVjbGFyYXRpb24gb2YgWCBwZXJt aXR0ZWQ6DQoNCiAgdHlwZSA6OiB0aHJlZQ0KICAgIHJlYWwgOjogQw0KICBlbmQgdHlwZSB0aHJl ZQ0KDQogIHR5cGUgOjogZm91cg0KICAgIHR5cGUodGhyZWUpLCBhbGxvY2F0YWJsZSA6OiBBWzpd DQogIGVuZCB0eXBlIGZvdXINCg0KICB0eXBlKGZvdXIpIDo6IFgNCg0KQU5TV0VSUzoNCg0KMS4g VHlwZSB0d28gaXMgbm90IGNvbmZvcm1pbmcsIGJlY2F1c2UgdGhlIGVudGl0eSBBIGhhcyBhIGNv YXJyYXkNCiAgIHVsdGltYXRlIGNvbXBvbmVudCBhbmQgQzUyNSByZXF1aXJlcyBzdWNoIGFuIGVu dGl0eSB0byBiZSBhDQogICBub25wb2ludGVyIG5vbmFsbG9jYXRhYmxlIHNjYWxhci4gIFRoZXJl Zm9yZSB0aGUgZGVjbGFyYXRpb24gb2YgVg0KICAgaXMgbm90IHBlcm1pdHRlZC4NCg0KMi4gWCBz YXRpc2ZpZXMgQzUyNSwgc28gZGVjbGFyYXRpb24gb2YgWCBpcyBwZXJtaXR0ZWQuICBYIGhhcyBh bg0KICAgdWx0aW1hdGUgKGFsbG9jYXRhYmxlKSBjb2FycmF5IGNvbXBvbmVudCAoQVs6XSksIGFu ZCB0aGVyZWZvcmUNCiAgIGFjb3JkaW5nIHRvIEM1MjYgbXVzdCBiZSBhIGR1bW15IGFyZ3VtZW50 IG9yIGhhdmUgdGhlIEFMTE9DQVRBQkxFDQogICBvciBTQVZFIGF0dHJpYnV0ZS4NCg0KRURJVFM6 DQoNCk5vbmUuDQoNClNVQk1JVFRFRCBCWTogVmFuIFNueWRlcg0KDQpISVNUT1JZOiAxNC0xNjMg ICAgbTIwNCAgRjA4LzAxMDggc3VibWl0dGVkDQogICAgICAgICAxNC0xNjNyMSAgbTIwNCAgRml4 ZWQgZXhhbXBsZXMgaW4gcXVlc3Rpb25zLCByZXZpc2VkDQogICAgICAgICAgICAgICAgICAgICAg ICAgYW5zd2VyIC0gcGFzc2VkIGJ5IEozIG1lZXRpbmcNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpOVU1C RVI6IEYwOC8wMTA5DQpUSVRMRTogTE9DS19UWVBFIGFuZCB1bmxpbWl0ZWQgcG9seW1vcnBoaWMN CktFWVdPUkQ6IExPQ0tfVFlQRSwgdW5saW1pdGVkIHBvbHltb3JwaGljDQpERUZFQ1QgVFlQRTog RXJyYXR1bQ0KU1RBVFVTOiBQYXNzZWQgYnkgSjMgbWVldGluZw0KDQpRVUVTVElPTjoNCg0KQXNz dW1lIHR5cGUgTE9DS19UWVBFIGZyb20gdGhlIGludHJpbnNpYyBtb2R1bGUgSVNPX0ZvcnRyYW5f RW52IGlzDQphdmFpbGFibGUuDQoNClExLiBJcyBhbGxvY2F0aW9uIG9mIFglQyBwZXJtaXR0ZWQ/ DQoNCiAgVFlQRSB0DQogICAgVFlQRShMT0NLX1RZUEUpLEFMTE9DQVRBQkxFIDo6IGMNCiAgRU5E IFRZUEUNCiAgVFlQRSh0KSA6OiB4WypdLHlbKl0NCiAgQUxMT0NBVEUoeSVjKQ0KICBBTExPQ0FU RSh4JWMsU09VUkNFPXklYykNCg0KUTIuIElzIGFsbG9jYXRpb24gb2YgQyBwZXJtaXR0ZWQ/DQoN CiAgY2xhc3MoKiksIHBvaW50ZXIgOjogQw0KICB0eXBlKGxvY2tfdHlwZSksIGludGVudChpbikg OjogTFsqXQ0KDQogIGFsbG9jYXRlICggQywgc291cmNlPUwgKQ0KDQpRMy4gSXMgYWxsb2NhdGlv biBvZiBDIHBlcm1pdHRlZD8NCg0KICBjbGFzcygqKSwgcG9pbnRlciA6OiBDDQoNCiAgYWxsb2Nh dGUgKCBMT0NLX1RZUEUgOjogQyApDQoNClE0LiBJcyBwb2ludGVyIGFzc2lnbm1lbnQgdG8gQyBw ZXJtaXR0ZWQ/DQoNCiAgY2xhc3MoKiksIHBvaW50ZXIgOjogQw0KICB0eXBlKGxvY2tfdHlwZSks IGludGVudChpbiksIHRhcmdldCA6OiBMWypdDQoNCiAgYyA9PiBMDQoNClE1LiBJcyB0aGlzIEFM TE9DQVRFIHN0YXRlbWVudCBjb25mb3JtaW5nPw0KDQogIENMQVNTKCopLEFMTE9DQVRBQkxFIDo6 IENbOl0NCiAgVFlQRShMT0NLX1RZUEUpIDo6IFgNCiAgQUxMT0NBVEUoQyxNT0xEPVgpDQoNCkFO U1dFUjoNCg0KQTEuIEFsbG9jYXRpb24gb2YgWCVDIGlzIG5vdCBpbnRlbmRlZCB0byBiZSBhbGxv d2VkLiAgQW4gZWRpdCBpcw0KICAgIHN1cHBsaWVkIHRvIGNvcnJlY3QgdGhlIHJlcXVpcmVtZW50 cyBvbiBhbGxvY2F0aW9uIG9mIExPQ0tfVFlQRS4NCg0KQTIuIEFsbG9jYXRpb24gb2YgQyBpcyBu b3QgaW50ZW5kZWQgdG8gYmUgYWxsb3dlZC4gIEFuIGVkaXQgaXMNCiAgICBzdXBwbGllZCB0byBj b3JyZWN0IHRoZSByZXF1aXJlbWVudHMgb24gYWxsb2NhdGlvbiBvZiBMT0NLX1RZUEUuDQoNCkEz LiBUaGlzIGFsbG9jYXRpb24gb2YgQyBpcyBwZXJtaXR0ZWQuDQoNCkE0LiBQb2ludGVyIGFzc2ln bm1lbnQgdG8gQyBpcyBwZXJtaXR0ZWQuDQoNCkE1LiBUaGlzIHN0YXRlbWVudCB3YXMgaW50ZW5k ZWQgdG8gYmUgcGVybWl0dGVkLiAgQW4gZWRpdCBpcyBzdXBwbGllZA0KICAgIHRvIGNvcnJlY3Qg dGhlIHJlcXVpcmVtZW50cy4NCg0KRURJVFM6DQoNCls2OjcrXSBBZnRlciBkZWZpbml0aW9uIDEu My4zMy4yIHBhcmVudCBjb21wb25lbnQsIGluc2VydCBuZXcgdGVybQ0KICAiMS4zLjMzLjJhDQog ICBwb3RlbnRpYWwgc3Vib2JqZWN0IGNvbXBvbmVudA0KICAgbm9ucG9pbnRlciBjb21wb25lbnQs IG9yIHBvdGVudGlhbCBzdWJvYmplY3QgY29tcG9uZW50IG9mIGENCiAgIG5vbnBvaW50ZXIgY29t cG9uZW50ICg0LjUuMSkiLg0KDQpbMTI3OjgtOV0gNi43LjEuMSBTeW50YXgsIEM2NDMsDQogICAg ICAgICAgQ2hhbmdlICJDX1BUUiwiIHRvICJDX1BUUiBvciINCiAgICAgICAgICBEZWxldGUgIiwg TE9DS19UWVBFIC4uLiBMT0NLX1RZUEUiLg0KDQpbMTI3OjkrXSBJbnNlcnQgbmV3IGNvbnN0cmFp bnQNCiAgIkM2NDNhIChSNjI3KSBJZiBTT1VSQ0U9IGFwcGVhcnMsIHRoZSBkZWNsYXJlZCB0eXBl IG9mIDxzb3VyY2UtZXhwcj4NCiAgICAgICAgIHNoYWxsIG5vdCBiZSBMT0NLX1RZUEUgb3IgaGF2 ZSBhIHBvdGVudGlhbCBzdWJvYmplY3QNCiAgICAgICAgIGNvbXBvbmVudCBvZiB0eXBlIExPQ0tf VFlQRS4iDQoNClsxMjc6MTgtMTldIDYuNy4xLjEsIHA0LA0KICAiSWYiIC0+ICJJZiBhbiBBTExP Q0FURSBzdGF0ZW1lbnQgaGFzIGEgU09VUkNFPSBzcGVjaWZpZXIgYW5kIGFuIiwNCntUaGVyZSBp cyBubyBwcm9ibGVtIHdpdGggTU9MRD0uICAic3ViY29tcG9uZW50IiB3b3JrcyBvayBoZXJlIGJl Y2F1c2UNCiB3ZSBoYXZlIGFuIG9iamVjdCBub3QgYSB0eXBlLn0NCg0KU1VCTUlUVEVEIEJZOiBW YW4gU255ZGVyDQoNCkhJU1RPUlk6IDE0LTE2NCAgICBtMjA0ICBGMDgvMDEwOSBzdWJtaXR0ZWQN CiAgICAgICAgIDE0LTE2NHIzICBtMjA0ICBBcyBhbWVuZGVkLCBwYXNzZWQgYnkgSjMgbWVldGlu Zw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCk5VTUJFUjogRjA4LzAxMTANClRJVExFOiBJbnRlcmRlcGVu ZGVuY2Ugb2Ygc3BlY2lmaWVyIHZhbHVlcyBpbiBpbnB1dC9vdXRwdXQgc3RhdGVtZW50cw0KS0VZ V09SRDogc3BlY2lmaWVyLCBpbnB1dC9vdXRwdXQgc3RhdGVtZW50DQpERUZFQ1QgVFlQRTogRXJy YXR1bQ0KU1RBVFVTOiBQYXNzZWQgYnkgSjMgbWVldGluZw0KDQpRVUVTVElPTlM6DQoNCjEuIEFy ZSB0aGUgZm9sbG93aW5nIElOUVVJUkUgc3RhdGVtZW50cyBwZXJtaXR0ZWQ/DQoNCiAgICBMT0dJ Q0FMIDo6IEV4aXN0LCBPcGVuZWQNCiAgICBJTlFVSVJFICggRklMRT0nZnJlZCcsIEVYSVNUPWV4 aXN0ICkNCiAgICBJTlFVSVJFICggVU5JVD00MiwgT1BFTkVEPW9wZW5lZA0KDQoyLiBJcyB0aGUg Zm9sbG93aW5nIElOUVVJUkUgc3RhdGVtZW50IHBlcm1pdHRlZD8NCg0KICAgIElOVEVHRVIgOjog VQ0KICAgIElOVEVSRkFDRQ0KICAgICAgRlVOQ1RJT04gUCAoIEEgKQ0KICAgICAgICBJTlRFR0VS LCBJTlRFTlQoSU4pIDo6IEENCiAgICAgICAgSU5URUdFUiwgUE9JTlRFUiA6OiBQDQogICAgICBF TkQgRlVOQ1RJT04gUA0KICAgIEVORCBJTlRFUkZBQ0UNCiAgICBJTlFVSVJFICggRklMRT0nZnJl ZCcsIE5VTUJFUj11LCBQT1NJVElPTj1wKHUpICkNCg0KMy4gSXMgdGhlIGZvbGxvd2luZyBSRUFE IHN0YXRlbWVudCBwZXJtaXR0ZWQ/DQoNCiAgICBJTlRFR0VSIDo6IFNUQVRTKDQyKQ0KICAgIE5B TUVMSVNUIC9JTi8gVg0KICAgIFJFQUQgKCAqLCBJTiwgSU9TVEFUPVNUQVRTKFYpICkNCg0KQU5T V0VSUzoNCg0KMS4gQWNjb3JkaW5nIHRvIDkuMTJwNQ0KDQogICJUaGUgdmFsdWUgb2YgYSBzcGVj aWZpZXIgaW4gYW4gaW5wdXQvb3V0cHV0IHN0YXRlbWVudCBzaGFsbCBub3QNCiAgZGVwZW5kIG9u IHRoZSBkZWZpbml0aW9uIG9yIGV2YWx1YXRpb24gb2YgYW55IG90aGVyIHNwZWNpZmllciBpbiB0 aGUNCiAgPGlvLWNvbnRyb2wtc3BlYy1saXN0PiBvciA8aW5xdWlyZS1zcGVjLWxpc3Q+IGluIHRo YXQgc3RhdGVtZW50LiINCg0KdGhlIElOUVVJUkUgc3RhdGVtZW50cyBhcmUgcHJvaGliaXRlZCBi ZWNhdXNlIHRoZSB2YWx1ZXMgb2YgdGhlDQp2YXJpYWJsZXMgRVhJU1QgYW5kIE9QRU4gZGVwZW5k IHVwb24gdGhlIHZhbHVlcyBvZiB0aGUgRklMRT0gYW5kIFVOSVQ9DQpzcGVjaWZpZXJzLCByZXNw ZWN0aXZlbHkuICBUaGV5IHdlcmUgaW50ZW5kZWQgdG8gYmUgcGVybWl0dGVkLiAgRWRpdHMNCmFy ZSBwcm92aWRlZCB0byBjb3JyZWN0IHRoaXMgbWlzdGFrZS4NCg0KMi4gQWNjb3JkaW5nIHRvIDku MTJwNg0KDQogICJUaGUgdmFsdWUgb2YgYW55IHN1YnNjcmlwdCBvciBzdWJzdHJpbmcgYm91bmQg b2YgYSB2YXJpYWJsZSB0aGF0DQogIGFwcGVhcnMgaW4gYSBzcGVjaWZpZXIgaW4gYW4gaW5wdXQv b3V0cHV0IHN0YXRlbWVudCBzaGFsbCBub3QgZGVwZW5kDQogIG9uIGFueSA8aW5wdXQtaXRlbT4s IDxpby1pbXBsaWVkLWRvPiA8ZG8tdmFyaWFibGU+LCBvciBvbiB0aGUNCiAgZGVmaW5pdGlvbiBv ciBldmFsdWF0aW9uIG9mIGFueSBvdGhlciBzcGVjaWZpZXIgaW4gdGhlDQogIDxpby1jb250cm9s LXNwZWM+IG9yIDxpbnF1aXJlLXNwZWM+IGluIHRoYXQgc3RhdGVtZW50LiINCg0KdGhlIElOUVVJ UkUgc3RhdGVtZW50IGlzIG5vdCBwcm9oaWJpdGVkIGJlY2F1c2UgVSBpcyBub3QgYSBzdWJzY3Jp cHQgb3INCnN1YnN0cmluZyBib3VuZC4gIEl0IHdhcyBpbnRlbmRlZCB0byBiZSBwcm9oaWJpdGVk LiAgRWRpdHMgYXJlIHByb3ZpZGVkDQp0byBjb3JyZWN0IHRoaXMgbWlzdGFrZS4NCg0KMy4gQWNj b3JkaW5nIHRvIDkuMTJwNQ0KDQogICJUaGUgdmFsdWUgb2YgYW55IHN1YnNjcmlwdCBvciBzdWJz dHJpbmcgYm91bmQgb2YgYSB2YXJpYWJsZSB0aGF0DQogIGFwcGVhcnMgaW4gYSBzcGVjaWZpZXIg aW4gYW4gaW5wdXQvb3V0cHV0IHN0YXRlbWVudCBzaGFsbCBub3QgZGVwZW5kDQogIG9uIGFueSA8 aW5wdXQtaXRlbT4sIDxpby1pbXBsaWVkLWRvPiA8ZG8tdmFyaWFibGU+LCBvciBvbiB0aGUNCiAg ZGVmaW5pdGlvbiBvciBldmFsdWF0aW9uIG9mIGFueSBvdGhlciBzcGVjaWZpZXIgaW4gdGhlDQog IDxpby1jb250cm9sLXNwZWM+IG9yIDxpbnF1aXJlLXNwZWM+IGluIHRoYXQgc3RhdGVtZW50LiIN Cg0KYW5kIDkuMTJwNw0KDQogICJJbiBhIGRhdGEgdHJhbnNmZXIgc3RhdGVtZW50LCB0aGUgdmFy aWFibGUgc3BlY2lmaWVkIGluIGFuIElPU1RBVD0sDQogIElPTVNHPSwgb3IgU0laRT0gc3BlY2lm aWVyLCBpZiBhbnksIHNoYWxsIG5vdCBiZSBhc3NvY2lhdGVkIHdpdGggYW55DQogIGVudGl0eSBp biB0aGUgLi4uIDxuYW1lbGlzdC1ncm91cC1vYmplY3QtbGlzdD4uLi4uIg0KDQphbmQgOS4xMnA4 DQoNCiAgIkluIGEgZGF0YSB0cmFuc2ZlciBzdGF0ZW1lbnQsIGlmIGEgdmFyaWFibGUgc3BlY2lm aWVkIGluIGFuIElPU1RBVD0sDQogIElPTVNHPSwgb3IgU0laRT0gc3BlY2lmaWVyIGlzIGFuIGFy cmF5IGVsZW1lbnQgcmVmZXJlbmNlLCBpdHMNCiAgc3Vic2NyaXB0IHZhbHVlcyBzaGFsbCBub3Qg YmUgYWZmZWN0ZWQgYnkgdGhlIGRhdGEgdHJhbnNmZXIsIHRoZQ0KICA8aW8taW1wbGllZC1kbz4g cHJvY2Vzc2luZywgb3IgdGhlIGRlZmluaXRpb24gb3IgZXZhbHVhdGlvbiBvZiBhbnkNCiAgb3Ro ZXIgc3BlY2lmaWVyIGluIHRoZSA8aW8tY29udHJvbC1zcGVjLWxpc3Q+LiINCg0KdGhlIFJFQUQg c3RhdGVtZW50IGlzIG5vdCBwcm9oaWJpdGVkIGJlY2F1c2UgViBkb2VzIG5vdCAiZGVwZW5kIG9u IGFueQ0KPGlucHV0LWl0ZW0+LCA8aW8taW1wbGllZC1kbz4gPGRvLXZhcmlhYmxlPiwgb3Igb24g dGhlIGRlZmluaXRpb24gb3INCmV2YWx1YXRpb24gb2YgYW55IG90aGVyIHNwZWNpZmllciBpbiB0 aGUgPGlvLWNvbnRyb2wtc3BlYz4gb3INCjxpbnF1aXJlLXNwZWM+IGluIHRoYXQgc3RhdGVtZW50 LiIgICBBbHRob3VnaCBWIGlzIGlucHV0IGZyb20gbmFtZWxpc3QsDQppdCBpcyBub3QgInRoZSB2 YXJpYWJsZSBzcGVjaWZpZWQgaW4gYW4gSU9TVEFUPSwgSU9NU0c9LCBvciBTSVpFPQ0Kc3BlY2lm aWVyLiIgIFRoZSBSRUFEIHN0YXRlbWVudCB3YXMgaW50ZW5kZWQgdG8gYmUgcHJvaGliaXRlZC4g IEVkaXRzDQphcmUgcHJvdmlkZWQgdG8gY29ycmVjdCB0aGlzIG1pc3Rha2UuDQoNCkVESVRTIHRv IDEwLTAwN3IxOg0KDQpbMjQzOjMtNCA5LjEycDVdIFdpdGhpbiB0aGUgZmlyc3Qgc2VudGVuY2Us IGFzIGFtZW5kZWQgYnkgQ29ycmlnZW5kdW0gMiwNCnJlcGxhY2UgImlucHV0L291dHB1dCIgd2l0 aCAiZGF0YSB0cmFuc2ZlciIgYW5kIGRlbGV0ZSAib3INCjxpbnF1aXJlLXNwZWMtbGlzdD4iLCBz byB0aGF0IHRoZSBzZW50ZW5jZSwgYXMgYW1lbmRlZCBieSBDb3JyaWdlbmR1bQ0KMiwgYmVjb21l cw0KDQogICJUaGUgdmFsdWUgb2YgYSBzcGVjaWZpZXIgaW4gYSBkYXRhIHRyYW5zZmVyIHN0YXRl bWVudCBzaGFsbCBub3QNCiAgZGVwZW5kIG9uIHRoZSBldmFsdWF0aW9uIG9mIGFueSBvdGhlciBz cGVjaWZpZXIgaW4gdGhlDQogIDxpby1jb250cm9sLXNwZWMtbGlzdD4gaW4gdGhhdCBzdGF0ZW1l bnQuIg0KDQpJZiB3ZSBhc3N1bWUgdGhhdCB0aGUgVU5JVD0gPGZpbGUtdW5pdC1udW1iZXI+LCBG SUxFPSA8ZmlsZS1uYW1lLWV4cHI+LA0Kb3IgSUQ9IDxzY2FsYXItaW50LWV4cHI+IGluIGFuIDxp bnF1aXJlLXNwZWMtbGlzdD4gYXJlIGVzdGFibGlzaGVkDQpiZWZvcmUgdGhlIHZhbHVlcyBvZiBh bnkgb2YgdGhlIDx2YXJpYWJsZT5zIGFyZSBjaGFuZ2VkLCB3ZSBuZWVkIG5vdA0KYXBwZW5kDQoN CiAgIlRoZSB2YWx1ZSBvZiBhIDxmaWxlLXVuaXQtbnVtYmVyPiwgPGZpbGUtbmFtZS1leHByPiwg b3INCiAgPHNjYWxhci1pbnQtZXhwcj4gaW4gYW4gPGlucXVpcmUtc3BlYy1saXN0PiBzaGFsbCBu b3QgZGVwZW5kIHVwb24gdGhlDQogIGRlZmluaXRpb24gb2YgYW55IHZhcmlhYmxlIGluIHRoYXQg PGlucXVpcmUtc3BlYy1saXN0Pi4iDQoNClsyNDM6NiwgMTItMTUgOS4xMnA2LDhdIFJlcGxhY2Ug dGhlIHBhcmFncmFwaHM6DQoNCiAgIkluIGFuIGlucHV0L291dHB1dCBzdGF0ZW1lbnQsIHRoZSB2 YWx1ZSBvZiBhbnkgYXJndW1lbnQgaW4gYSBmdW5jdGlvbg0KICByZWZlcmVuY2UgdGhhdCBpcyBh IDx2YXJpYWJsZT4sIGFueSBzdWJzY3JpcHQsIG9yIGFueSBzdWJzdHJpbmcgYm91bmQsDQogIHRo YXQgYXBwZWFycyBpbiBhIHNwZWNpZmllciBpbiB0aGF0IHN0YXRlbWVudCwgc2hhbGwgbm90IGJl IGFmZmVjdGVkDQogIGJ5IGRhdGEgdHJhbnNmZXIgb3IgPGltcGxpZWQtZG8+IHByb2Nlc3Npbmcg Y2F1c2VkIGJ5IHRoYXQgc3RhdGVtZW50LA0KICBvciBkZWZpbml0aW9uIG9yIGV2YWx1YXRpb24g b2YgYW55IG90aGVyIHNwZWNpZmllciBpbiB0aGUNCiAgPGlvLWNvbnRyb2wtc3BlYy1saXN0PiBv ciA8aW5xdWlyZS1zcGVjLWxpc3Q+IGluIHRoYXQgc3RhdGVtZW50LiINCg0KU1VCTUlUVEVEIEJZ OiBWYW4gU255ZGVyDQoNCkhJU1RPUlk6IDE0LTE5MyAgICBtMjA0ICBGMDgvMDExMCBzdWJtaXR0 ZWQNCiAgICAgICAgIDE0LTE5M3IxICBtMjA0ICBQYXNzZWQgYnkgSjMgbWVldGluZw0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCk5VTUJFUjogRjA4LzAxMTENClRJVExFOiBVbmRlZmluaXRpb24NCktFWVdP UkQ6IHVuZGVmaW5pdGlvbg0KREVGRUNUIFRZUEU6IEVycmF0dW0NClNUQVRVUzogUGFzc2VkIGJ5 IEozIG1lZXRpbmcNCg0KUVVFU1RJT05TOg0KDQoxLiBEb2VzIHRoZSBmb2xsb3dpbmcgY2F1c2Ug RCB0byBiZWNvbWUgdW5kZWZpbmVkPyAgT3VnaHQgaXQ/DQoNCiAgaW50ZWdlciA6OiBJKDIpDQog IGRvdWJsZSBwcmVjaXNpb24gOjogRA0KICBlcXVpdmFsZW5jZSAoIEQsIEkgKQ0KICBkID0gNDIu MA0KICBpKDEpID0gNjY2DQoNCjIuIERvZXMgdGhlIGZvbGxvd2luZyBjYXVzZSBDIHRvIGJlY29t ZSB1bmRlZmluZWQ/ICBPdWdodCBpdD8NCg0KICBpbnRlZ2VyLCBwYXJhbWV0ZXIgOjogUksgPSBr aW5kKDAuMGQwKQ0KICByZWFsKHJrKSwgcG9pbnRlciA6OiBQDQogIGNvbXBsZXgocmspLCB0YXJn ZXQgOjogQyA9ICggMS4wLCAyLjAgKQ0KICBjID0gKCAxLjBkMCwgMi4wZDAgKQ0KICBwID0+IGMl cmUNCiAgcCA9IDI0LjBkMA0KDQozLiBEb2VzIHRoZSBmb2xsb3dpbmcgY2F1c2UgRDEgdG8gYmVj b21lIHVuZGVmaW5lZD8gIERvZXMgaXQgY2F1c2UgQyVJTQ0KdG8gYmVjb21lIHVuZGVmaW5lZD8g IE91Z2h0IGl0Pw0KDQogIGludGVnZXIsIHBhcmFtZXRlciA6OiBSSyA9IGtpbmQoMC4wZDApDQog IHJlYWwocmspLCBwb2ludGVyIDo6IEQxLCBEMg0KICBjb21wbGV4KHJrKSwgdGFyZ2V0IDo6IEMN CiAgYyA9ICggMS4wZDAsIDIuMGQwICkNCiAgZDEgPT4gYyVyZQ0KICBkMiA9PiBjJWltDQogIGNh bGwgcyAoIGQyICkNCiAgLi4uDQogIGNvbnRhaW5zDQogICAgc3Vicm91dGluZSBTICggRCApDQog ICAgICByZWFsKHJrKSwgaW50ZW50KG91dCkgOjogRA0KICAuLi4uDQoNCjQuIERvZXMgdGhlIGZv bGxvd2luZyBjYXVzZSBZIHRvIGJlY29tZSB1bmRlZmluZWQ/ICBPdWdodCBpdD8NCg0KICB0eXBl IDo6IFQxDQogICAgc2VxdWVuY2UNCiAgICBpbnRlZ2VyIDo6IEMxID0gNDINCiAgZW5kIHR5cGUg VDENCiAgdHlwZSA6OiBUMg0KICAgIHNlcXVlbmNlDQogICAgcmVhbCA6OiBDMSA9IDQyLjBlMA0K ICBlbmQgdHlwZSBUMg0KICB0eXBlKHQxKSA6OiBYDQogIHR5cGUodDIpIDo6IFkNCiAgZXF1aXZh bGVuY2UgKCBYLCBZICkNCiAgeCA9IHQxKDIxKQ0KDQpBTlNXRVJTOg0KDQoxLiBJdGVtICgxKSBp biBzdWJjbGF1c2UgMTYuNi42IHNheXMNCg0KICAiV2hlbiBhIHNjYWxhciB2YXJpYWJsZSBvZiBp bnRyaW5zaWMgdHlwZSBiZWNvbWVzIGRlZmluZWQsIGFsbCB0b3RhbGx5DQogIGFzc29jaWF0ZWQg dmFyaWFibGVzIG9mIGRpZmZlcmVudCB0eXBlIGJlY29tZSB1bmRlZmluZWQuLi4uICBXaGVuIGEN CiAgc2NhbGFyIHZhcmlhYmxlIGJlY29tZXMgdW5kZWZpbmVkLCBhbGwgcGFydGlhbGx5IGFzc29j aWF0ZWQgZG91YmxlDQogIHByZWNpc2lvbiBzY2FsYXIgdmFyaWFibGVzIGJlY29tZSB1bmRlZmlu ZWQuIg0KDQpEIGlzIG5vdCB0b3RhbGx5IGFzc29jaWF0ZWQgd2l0aCBJLiAgSSBkb2VzIG5vdCBi ZWNvbWUgdW5kZWZpbmVkLg0KVGhlcmVmb3JlLCBEIGRvZXMgbm90IGJlY29tZSB1bmRlZmluZWQu ICBEIG91Z2h0IHRvIGJlY29tZSB1bmRlZmluZWQuDQpFZGl0cyBhcmUgcHJvdmlkZWQgdG8gY29y cmVjdCB0aGlzIG1pc3Rha2UuDQoNCjIuIEl0ZW0gKDEpIGluIHN1YmNsYXVzZSAxNi42LjYgc2F5 cw0KDQogICJXaGVuIGEgZG91YmxlIHByZWNpc2lvbiBzY2FsYXIgdmFyaWFibGUgYmVjb21lcyBk ZWZpbmVkLCBhbGwNCiAgcGFydGlhbGx5IGFzc29jaWF0ZWQgc2NhbGFyIHZhcmlhYmxlcyBiZWNv bWUgdW5kZWZpbmVkLiINCg0KUCBpcyBwYXJ0bHkgYXNzb2NpYXRlZCB3aXRoIEMsIGFuZCB0aGVy ZWZvcmUgQyBiZWNvbWVzIHVuZGVmaW5lZCBieSB0aGUNCmFzc2lnbm1lbnQgdG8gdGhlIHNjYWxh ciB2YXJpYWJsZSBQLiAgQyBvdWdodCBub3QgdG8gYmVjb21lIHVuZGVmaW5lZC4NCkVkaXRzIGFy ZSBwcm92aWRlZCB0byBjb3JyZWN0IHRoaXMgbWlzdGFrZS4NCg0KMy4gSXRlbSAoMSkgaW4gc3Vi Y2xhdXNlIDE2LjYuNiBzYXlzDQoNCiAgIldoZW4gYSBzY2FsYXIgdmFyaWFibGUgYmVjb21lcyB1 bmRlZmluZWQsIGFsbCBwYXJ0aWFsbHkgYXNzb2NpYXRlZA0KICBkb3VibGUgcHJlY2lzaW9uIHNj YWxhciB2YXJpYWJsZXMgYmVjb21lIHVuZGVmaW5lZC4iDQoNCiAgU3ViY2xhdXNlIDE2LjYuMXA1 IHNheXMNCg0KICAiQSBjb21wbGV4Li4uIHNjYWxhciBvYmplY3QgaXMgZGVmaW5lZCBpZiBhbmQg b25seSBpZiBhbGwgb2YgaXRzDQogIHN1Ym9iamVjdHMgYXJlIGRlZmluZWQuIg0KDQpUaGUgYXNz b2NpYXRpb24gb2YgdGhlIHNjYWxhciB2YXJpYWJsZSBEMiB3aXRoIGFuIElOVEVOVChPVVQpIGR1 bW15DQphcmd1bWVudCBjYXVzZXMgaXQgYmVjb21lIHVuZGVmaW5lZC4gIDE2LjYuNnAxKDEpIGRv ZXMgbm90IHNwZWNpZnkgdGhhdA0Kd2hlbiBhIHNjYWxhciByZWFsIHZhcmlhYmxlIGJlY29tZXMg dW5kZWZpbmVkLCBhIHRvdGFsbHkgYXNzb2NpYXRlZCBwYXJ0DQpvZiBhIGNvbXBsZXggdmFyaWFi bGUgYmVjb21lcyB1bmRlZmluZWQuICBBc3N1bWluZyBDJUlNIG91Z2h0IHRvIGJlY29tZQ0KdW5k ZWZpbmVkLCB0aGVuIEMgb3VnaHQgdG8gYmVjb21lIHVuZGVmaW5lZCwgZXZlbiB0aG91Z2ggQyVS RSBpcyBub3QNCnVuZGVmaW5lZC4gIEQxIGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgQyVSRSwgYW5k IHRoZXJlZm9yZSBiZWNvbWVzDQp1bmRlZmluZWQgd2hlbiBDJUlNIGJlY29tZXMgdW5kZWZpbmVk LiAgQyVJTSBvdWdodCB0byBiZWNvbWUgdW5kZWZpbmVkLA0KYW5kIEQxIG91Z2h0IG5vdCB0byBi ZWNvbWUgdW5kZWZpbmVkLiAgRWRpdHMgYXJlIHByb3ZpZGVkIHRvIGNvcnJlY3QNCnRoaXMgbWlz dGFrZS4NCg0KNC4gSXRlbSAoMSkgaW4gc3ViY2xhdXNlIDE2LjYuNiBzYXlzDQoNCiAgIldoZW4g YSBzY2FsYXIgdmFyaWFibGUgb2YgaW50cmluc2ljIHR5cGUgYmVjb21lcyBkZWZpbmVkLCBhbGwg dG90YWxseQ0KICBhc3NvY2lhdGVkIHZhcmlhYmxlcyBvZiBkaWZmZXJlbnQgdHlwZSBiZWNvbWUg dW5kZWZpbmVkLg0KDQpYIGFuZCBZIGFyZSB0b3RhbGx5IGFzc29jaWF0ZWQsIGFuZCBvZiBkaWZm ZXJlbnQgdHlwZSwgYnV0IG5laXRoZXIgb25lIGlzDQpvZiBpbnRyaW5zaWMgdHlwZS4gIFRoZXJl Zm9yZSwgWSBkb2VzIG5vdCBiZWNvbWUgdW5kZWZpbmVkIGFzIGENCmNvbnNlcXVlbmNlIG9mIFgg YmVjb21pbmcgZGVmaW5lZC4gIFkgb3VnaHQgdG8gYmVjb21lIHVuZGVmaW5lZC4gIEVkaXRzDQph cmUgcHJvdmlkZWQgdG8gY29ycmVjdCB0aGlzIG1pc3Rha2UuDQoNCkVESVRTOg0KDQpJbiBTdWJj bGF1c2UgMTYuNi42cDEsIGl0ZW0oMSksIHdpdGhpbiB0aGUgZmlyc3Qgc2VudGVuY2UsIHJlbW92 ZSAib2YNCmludHJpbnNpYyB0eXBlIi4gIEJlZm9yZSAiZGlmZmVyZW50IiBpbnNlcnQgInRoZSBz YW1lIHR5cGUgd2l0aA0KZGlmZmVyZW50IHZhbHVlcyBvZiBraW5kIHR5cGUgcGFyYW1ldGVycywg b3Igb2YiDQoNCkluIFN1YmNsYXVzZSAxNi42LjZwMSwgcmVwbGFjZSBpdGVtKDEpIHdpdGggdGhl IGZvbGxvd2luZyBmb3VyIHNlbnRlbmNlcw0KKGFsbCBpbiBvbmUgcGFyYWdyYXBoKQ0KDQogICJX aGVuIGEgc2NhbGFyIHZhcmlhYmxlIGJlY29tZXMgZGVmaW5lZCwgYWxsIHRvdGFsbHkgYXNzb2Np YXRlZA0KICB2YXJpYWJsZXMgb2YgZGlmZmVyZW50IHR5cGUgYmVjb21lIHVuZGVmaW5lZC4NCg0K e1JlbW92aW5nICJvZiBpbnRyaW5zaWMgdHlwZSIgZnJvbSB0aGUgZXhpc3RpbmcgZmlyc3Qgc2Vu dGVuY2Ugb2YNCjE2LjYuNnAxKDEpIGFkZHJlc3NlcyBxdWVzdGlvbiA0Ln0NCg0KICBXaGVuIGEg c2NhbGFyIHZhcmlhYmxlIGJlY29tZXMgZGVmaW5lZCwgYWxsIHBhcnRpYWxseSBhc3NvY2lhdGVk DQogIHZhcmlhYmxlcyBvZiBkaWZmZXJlbnQgdHlwZSwgb3Igb2YgdGhlIHNhbWUgdHlwZSBpZiBj b3JyZXNwb25kaW5nIGtpbmQNCiAgdHlwZSBwYXJhbWV0ZXJzIGhhdmUgZGlmZmVyZW50IHZhbHVl cywgYmVjb21lIHVuZGVmaW5lZCwgdW5sZXNzIHRoZQ0KICBzY2FsYXIgdmFyaWFibGUgaXMgdG90 YWxseSBhc3NvY2lhdGVkIHdpdGggYSBzdWJvYmplY3Qgb2YgdGhlDQogIHBhcnRpYWxseSBhc3Nv Y2lhdGVkIHZhcmlhYmxlLCB0aGF0IHN1Ym9iamVjdCBpcyBvZiB0aGUgc2FtZSB0eXBlIGFzDQog IHRoZSBzY2FsYXIgdmFyaWFibGUsIGFuZCBjb3JyZXNwb25kaW5nIGtpbmQgdHlwZSBwYXJhbWV0 ZXJzIGhhdmUgdGhlDQogIHNhbWUgdmFsdWVzLg0KDQp7VGhpcyBhZGRyZXNzZXMgcXVlc3Rpb25z IDEgYW5kIDIuICBUaGUgcmVmZXJlbmNlcyB0byBraW5kIHR5cGUNCnBhcmFtZXRlciB2YWx1ZXMg YWRkcmVzcyB0aGUgcG9zc2liaWxpdHkgb2YgcGFydGlhbGx5IGFzc29jaWF0aW5nIGENCmRvdWJs ZSBwcmVjaXNpb24gdmFyaWFibGUgd2l0aCBhIGRlZmF1bHQgcmVhbCB2YXJpYWJsZS4gIERlZmF1 bHQgcmVhbA0KYW5kIGRvdWJsZSBwcmVjaXNpb24gYXJlIG5vdyB0aGUgc2FtZSB0eXBlIChzaW5j ZSAxOTkwKSwgYnV0IHdpdGggYQ0KZGlmZmVyZW50IGtpbmQgdHlwZSBwYXJhbWV0ZXIgdmFsdWUu fQ0KDQogIFdoZW4gYSBzY2FsYXIgdmFyaWFibGUgYmVjb21lcyB1bmRlZmluZWQsIGFsbCBwYXJ0 aWFsbHkgYXNzb2NpYXRlZA0KICB2YXJpYWJsZXMgYmVjb21lIHVuZGVmaW5lZCwgdW5sZXNzIHRo ZSBwYXJ0aWFsbHkgYXNzb2NpYXRlZCB2YXJpYWJsZQ0KICBpcyB0b3RhbGx5IGFzc29jaWF0ZWQg d2l0aCBhIHN1Ym9iamVjdCBvZiB0aGUgc2NhbGFyIHZhcmlhYmxlIHRoYXQNCiAgZG9lcyBub3Qg YmVjb21lIHVuZGVmaW5lZC4NCg0KICBXaGVuIGEgc2NhbGFyIHZhcmlhYmxlIGJlY29tZXMgdW5k ZWZpbmVkLCBhbGwgdG90YWxseSBhc3NvY2lhdGVkDQogIHN1Ym9iamVjdHMgb2Ygb3RoZXIgdmFy aWFibGVzIGJlY29tZSB1bmRlZmluZWQgaWYgdGhvc2Ugc3Vib2JqZWN0cyBhcmUNCiAgb2YgZGlm ZmVyZW50IHR5cGUgZnJvbSB0aGUgc2NhbGFyIHZhcmlhYmxlLCBvciBjb3JyZXNwb25kaW5nIGtp bmQgdHlwZQ0KICBwYXJhbWV0ZXJzIGhhdmUgZGlmZmVyZW50IHZhbHVlcy4iDQoNCntUaGUgdGhp cmQgYW5kIGZvdXJ0aCBzZW50ZW5jZXMgYWRkcmVzcyBxdWVzdGlvbiAzLn0NCg0KU1VCTUlUVEVE IEJZOiBWYW4gU255ZGVyDQoNCkhJU1RPUlk6IDE0LTE5NSAgICBtMjA0ICBGMDgvMDExMSBzdWJt aXR0ZWQgLSBwYXNzZWQgYnkgSjMgbWVldGluZw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk5VTUJFUjog RjA4LzAxMTINClRJVExFOiBTVEFUPSBhbmQgRVJSTVNHPSBpbiBBTExPQ0FURSBhbmQgREVBTExP Q0FURQ0KS0VZV09SRFM6IFNUQVQ9LCBFUlJNU0c9LCBBTExPQ0FURSwgREVBTExPQ0FURQ0KREVG RUNUIFRZUEU6IEVycmF0dW0NClNUQVRVUzogUGFzc2VkIGJ5IEozIG1lZXRpbmcNCg0KUVVFU1RJ T046DQoNCkNvbnNpZGVyDQoNCiAgQ0hBUkFDVEVSKDgwKSB0ZXh0KDA6MTAwKSwgbXNnDQogIElO VEVHRVIgc3RhdCxpc3RhdCgwOjgwKQ0KICBSRUFMLEFMTE9DQVRBQkxFIDo6IHgoOikseSg6LDop DQogIC4uLg0KICBBTExPQ0FURSh4KDEwKSxTVEFUPXN0YXQsRVJSTVNHPXRleHQoc3RhdCkpICEg QQ0KICBERUFMTE9DQVRFKHgsU1RBVD1zdGF0LEVSUk1TRz10ZXh0KHN0YXQpKSAgICEgQg0KICBt c2cgPSAnJw0KICBBTExPQ0FURSh5KDk5OTk5OSw5OTk5OTkpLFNUQVQ9aXN0YXQoTEVOX1RSSU0o bXNnKSksRVJSTVNHPW1zZykgISBDDQogIG1zZyA9ICcnDQogIERFQUxMT0NBVEUoeCxTVEFUPWlz dGF0KExFTl9UUklNKG1zZykpLEVSUk1TRz1tc2cpICEgRA0KDQpJbiBlYWNoIG9mIHRoZSBzdGF0 ZW1lbnRzIGxhYmVsbGVkIEEtRCwgdGhlcmUgaXMgYSBkZXBlbmRlbmN5IGJldHdlZW4NCnRoZSBT VEFUPSBzcGVjaWZpZXIgYW5kIHRoZSBFUlJNU0c9IHNwZWNpZmllciAoZnJvbSBTVEFUPSB0byBF UlJNU0c9DQppbiBBIGFuZCBCLCBhbmQgZnJvbSBFUlJNU0c9IHRvIFNUQVQgaW4gQyBhbmQgRCku ICBUaGVyZSBhcHBlYXJzIHRvIGJlDQpubyBwcm9oaWJpdGlvbiBhZ2FpbnN0IHRoaXMgKHRob3Vn aCB0aGVyZSBhcmUgbWFueSBwcm9oaWJpdGlvbnMNCmFnYWluc3Qgb3RoZXIgZGVwZW5kZW5jaWVz IGluIEFMTE9DQVRFIGFuZCBERUFMTE9DQVRFKS4NCg0KQXJlIGFsbCB0aGVzZSBleGFtcGxlcyBj b25mb3JtaW5nLCBhbmQgaWYgc28sIGlzIHRoZSBkZXBlbmRlbnQNCnZhcmlhYmxlIHJlZmVyZW5j ZWQgd2l0aCB0aGUgdmFsdWUgb2YgdGhlIG90aGVyIHZhcmlhYmxlIGF0IHRoZQ0KYmVnaW5uaW5n IG9mIGV4ZWN1dGlvbiBvZiB0aGUgc3RhdGVtZW50IG9yIGF0IHRoZSBlbmQgb2YgZXhlY3V0aW9u IG9mDQp0aGUgc3RhdGVtZW50Pw0KDQpBTlNXRVI6DQoNClRoZXNlIGFyZSBub3Qgc3RhbmRhcmQt Y29uZm9ybWluZywgYXMgbm8gaW50ZXJwcmV0YXRpb24gaXMgZXN0YWJsaXNoZWQNCmZvciB0aGVt LiAgQW4gZWRpdCBpcyBzdXBwbGllZCB0byBjbGFyaWZ5IHRoaXMgcHJvaGliaXRpb24uDQoNCkVE SVRTOg0KDQpbMTMyOjRdIDYuNy40IFNUQVQ9IHNwZWNpZmllciwgcDEsIGFwcGVuZA0KICAiVGhl IDxzdGF0LXZhcmlhYmxlPiBzaGFsbCBub3QgZGVwZW5kIG9uIHRoZSB2YWx1ZSBvZiB0aGUNCiAg IDxlcnJtc2ctdmFyaWFibGU+LiIuDQoNClsxMzI6MjJdIDYuNy41IEVSUk1TRz0gc3BlY2lmaWVy LCBwMSwgYXBwZW5kDQogICJUaGUgPGVycm1zZy12YXJpYWJsZT4gc2hhbGwgbm90IGRlcGVuZCBv biB0aGUgdmFsdWUgb2YgdGhlDQogICA8c3RhdC12YXJpYWJsZT4uIi4NCg0KU1VCTUlUVEVEIEJZ OiBNYWxjb2xtIENvaGVuDQoNCkhJU1RPUlk6IDE0LTIwOCAgICBtMjA0ICBGMDgvMDExMiBzdWJt aXR0ZWQgLSBwYXNzZWQgYnkgSjMgbWVldGluZw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk5VTUJFUjog RjA4LzAxMTMNClRJVExFOiBTcGVjaWZpZXJzIGluIGltYWdlIGNvbnRyb2wgc3RhdGVtZW50cw0K S0VZV09SRFM6IFNUQVQ9LCBFUlJNU0c9LCBBQ1FVSVJFRF9MT0NLPSwgaW1hZ2UgY29udHJvbA0K REVGRUNUIFRZUEU6IEVycmF0dW0NClNUQVRVUzogUGFzc2VkIGJ5IEozIG1lZXRpbmcNCg0KUVVF U1RJT046DQoNCkNvbnNpZGVyDQoNCiAgQ0hBUkFDVEVSKDgwKSB0ZXh0KDA6MTAwKSxtc2cNCiAg SU5URUdFUiBzdGF0LGlzdGF0KDIpDQogIFJFQUwsQUxMT0NBVEFCTEUgOjogeCg6KQ0KICBUWVBF KExPQ0tfVFlQRSkgOjogbG9ja1sqXSwgYWxvY2soMDo4MClbKl0NCiAgTE9HSUNBTCBhY3EsIGFh Y3EoMDo4MCkNCiAgLi4uDQogIFNZTkMgQUxMKFNUQVQ9c3RhdCxFUlJNU0c9dGV4dChzdGF0KSkg ICAgICAgISBBDQogIFNZTkMgSU1BR0VTICgqLFNUQVQ9c3RhdCxFUlJNU0c9dGV4dChzdGF0KSkg ISBCDQogIFNZTkMgTUVNT1JZKFNUQVQ9c3RhdCxFUlJNU0c9dGV4dChzdGF0KSkgICAgISBDDQog IExPQ0sobG9jayxBQ1FVSVJFRF9MT0NLPWFjcSwgJg0KICAgICAgIFNUQVQ9aXN0YXQoTUVSR0Uo MSwyLGFjcSkpLCAmDQogICAgICAgRVJSTVNHPXRleHQoaXN0YXQoTUVSR0UoMSwyLGFjcSkpKSkg ICAgISBEDQogIFVOTE9DSyhsb2NrLFNUQVQ9c3RhdCxFUlJNU0c9dGV4dChzdGF0KSkgICAgISBF DQogIExPQ0soYWxvY2soc3RhdCksU1RBVD1zdGF0KSAgICAgICAgICAgICAgICAgISBGDQogIG1z ZyA9ICcnDQogIFVOTE9DSyhhbG9jayhMRU5fVFJJTShtc2cpKSxTVEFUPXN0YXQsICYNCiAgICAg ICAgIEVSUk1TRz1tc2cpICAgICAgICAgICAgICAgICAgICAgICAgICAhIEcNCiAgc3RhdCA9IDEz DQogIFNZTkMgSU1BR0VTKHN0YXQsU1RBVD1zdGF0KSAgICAgICAgICAgICAgICAgISBIDQogIG1z ZyA9ICdvb3BzJw0KICBTWU5DIElNQUdFUyhMRU5fVFJJTShtc2cpLFNUQVQ9c3RhdCwgJg0KICAg ICAgICAgICAgICBFUlJNU0c9bXNnKSAgICAgICAgICAgICAgICAgICAgICEgSQ0KDQpJbiBlYWNo IG9mIHRoZSBzdGF0ZW1lbnRzIGxhYmVsbGVkIEEtRiwgdGhlcmUgaXMgYSBkZXBlbmRlbmN5IGJl dHdlZW4NCnRoZSBTVEFUPSBzcGVjaWZpZXIgYW5kIHRoZSBFUlJNU0c9IHNwZWNpZmllci4gIFRo ZXJlIGFwcGVhcnMgdG8gYmUgbm8NCnByb2hpYml0aW9uIGFnYWluc3QgdGhpcy4NCg0KQWRkaXRp b25hbGx5LCBpbiB0aGUgTE9DSyBzdGF0ZW1lbnQgKEQpLCB0aGVyZSBpcyBhIGRlcGVuZGVuY3kg YmV0d2Vlbg0KdGhlIEFDUVVJUkVEX0xPQ0s9IHNwZWNpZmllciBhbmQgdGhlIFNUQVQ9IHNwZWNp ZmllciAodGhlcmUgaXMgbm8NCmRlcGVuZGVuY3kgYmV0d2VlbiBBQ1FVSVJFRF9MT0NLPSBhbmQg RVJSTVNHPSBiZWNhdXNlIHRoZSBmb3JtZXIgaXMNCm9ubHkgc2V0IG9uIHN1Y2Nlc3NmdWwgZXhl Y3V0aW9uIGFuZCB0aGUgbGF0dGVyIGlzIG9ubHkgc2V0IG9uIGFuDQplcnJvciBjb25kaXRpb24p LiAgVGhlcmUgYXBwZWFycyB0byBiZSBubyByZXN0cmljdGlvbnMgYXQgYWxsIG9uIGFueQ0KZGVw ZW5kZW5jaWVzIGZyb20gQUNRVUlSRURfTE9DSz0uDQoNCkluIHRoZSBMT0NLIHN0YXRlbWVudCAo RiksIHRoZXJlIGlzIGEgZGVwZW5kZW5jeSBiZXR3ZWVuIHRoZSBTVEFUPQ0Kc3BlY2lmaWVyIGFu ZCB0aGUgbG9jayB2YXJpYWJsZS4gIFNpbWlsYXJseSBmb3IgdGhlIFVOTE9DSyAoRyksIHRoZXJl DQppcyBhIGRlcGVuZGVuY3kgYmV0d2VlbiB0aGUgbG9jayB2YXJpYWJsZSBhbmQgdGhlIEVSUk1T Rz0gc3BlY2lmaWVyLg0KDQpJbiB0aGUgU1lOQyBJTUFHRVMgc3RhdGVtZW50IChIKSwgdGhlcmUg aXMgYSBkZXBlbmRlbmN5IGJldHdlZW4gdGhlDQpTVEFUPSB2YXJpYWJsZSBhbmQgdGhlIGltYWdl IHNldC4gIEluIHRoZSBTWU5DIElNQUdFUyBzdGF0ZW1lbnQgKEkpLA0KdGhlcmUgaXMgYSBkZXBl bmRlbmN5IGJldHdlZW4gdGhlIEVSUk1TRz0gdmFyaWFibGUgYW5kIHRoZSBpbWFnZSBzZXQuDQoN CkFyZSBhbGwgdGhlc2UgZXhhbXBsZXMgY29uZm9ybWluZywgYW5kIGlmIHNvLCBpcyB0aGUgZGVw ZW5kZW50DQp2YXJpYWJsZSByZWZlcmVuY2VkIHdpdGggdGhlIHZhbHVlIG9mIHRoZSBvdGhlciB2 YXJpYWJsZSBhdCB0aGUNCmJlZ2lubmluZyBvZiBleGVjdXRpb24gb2YgdGhlIHN0YXRlbWVudCBv ciBhdCB0aGUgZW5kIG9mIGV4ZWN1dGlvbiBvZg0KdGhlIHN0YXRlbWVudD8NCg0KQU5TV0VSOg0K DQpObyBpbnRlcnByZXRhdGlvbiBpcyBlc3RhYmxpc2hlZCBhbmQgdGhlcmVmb3JlIHRoZXNlIGFy ZSBub3QNCmNvbmZvcm1pbmcuICBBbiBlZGl0IGlzIHByb3ZpZGVkIHRvIGNsYXJpZnkgdGhpcy4N Cg0KRURJVFM6DQoNClsxOTA6MTYtXSA4LjUuNCBTWU5DIElNQUdFUyBzdGF0ZW1lbnQsIGluc2Vy dCBuZXcgcDEsDQogICJUaGUgdmFsdWUgb2YgPGltYWdlLXNldD4gc2hhbGwgbm90IGRlcGVuZCBv biB0aGUgdmFsdWUgb2YNCiAgIDxzdGF0LXZhcmlhYmxlPiBvciA8ZXJybXNnLXZhcmlhYmxlPi4i Lg0KDQpbMTk0OjYtXSA4LjUuNiBMT0NLIGFuZCBVTkxPQ0sgc3RhdGVtZW50cywgaW5zZXJ0IG5l dyBwMSwNCiAgIlRoZSA8bG9jay12YXJpYWJsZT4gc2hhbGwgbm90IGRlcGVuZCBvbiB0aGUgdmFs dWUgb2YNCiAgIDxzdGF0LXZhcmlhYmxlPiwgPGVycm1zZy12YXJpYWJsZT4sIG9yIHRoZQ0KICAg PHNjYWxhci1sb2dpY2FsLXZhcmlhYmxlPiBpbiB0aGUgQUNRVUlSRURfTE9DSz0gc3BlY2lmaWVy Lg0KICAgVGhlIDxzY2FsYXItbG9naWNhbC12YXJpYWJsZT4gc2hhbGwgbm90IGRlcGVuZCBvbiB0 aGUNCiAgIDxsb2NrLXZhcmlhYmxlPiwgPHN0YXQtdmFyaWFibGU+LCBvciA8ZXJybXNnLXZhcmlh YmxlPi4iLg0KDQpbMTk1OjItXSA4LjUuNyBTVEFUPSBhbmQgRVJSTVNHPSBzcGVjaWZpZXJzLi4u LCBpbnNlcnQgbmV3IHAxLA0KICAiVGhlIDxzdGF0LXZhcmlhYmxlPiBzaGFsbCBub3QgZGVwZW5k IG9uIHRoZSB2YWx1ZSBvZiB0aGUNCiAgIDxlcnJtc2ctdmFyaWFibGU+LCA8bG9jay12YXJpYWJs ZT4sIG9yIHRoZQ0KICAgPHNjYWxhci1sb2dpY2FsLXZhcmlhYmxlPiBpbiB0aGUgQUNRVUlSRURf TE9DSz0gc3BlY2lmaWVyLg0KICAgVGhlIDxlcnJtc2ctdmFyaWFibGU+IHNoYWxsIG5vdCBkZXBl bmQgb24gdGhlIHZhbHVlIG9mIHRoZQ0KICAgPHN0YXQtdmFyaWFibGU+LCA8bG9jay12YXJpYWJs ZT4sIG9yIHRoZSA8c2NhbGFyLWxvZ2ljYWwtdmFyaWFibGU+DQogICBpbiB0aGUgQUNRVUlSRURf TE9DSz0gc3BlY2lmaWVyLiIuDQoNClNVQk1JVFRFRCBCWTogTWFsY29sbSBDb2hlbg0KDQpISVNU T1JZOiAxNC0yMDkgICAgbTIwNCAgRjA4LzAxMTMgc3VibWl0dGVkIC0gcGFzc2VkIGJ5IEozIG1l ZXRpbmcNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpOVU1CRVI6IEYwOC8wMTE0DQpUSVRMRTogQ2FuIExP Q0tfVFlQRSBjb21wb25lbnRzIGhhdmUgdGhlIFBPSU5URVIgYXR0cmlidXRlPw0KS0VZV09SRDog TE9DS19UWVBFIGNvbXBvbmVudCwgUE9JTlRFUg0KREVGRUNUIFRZUEU6IEVycmF0dW0NClNUQVRV UzogUGFzc2VkIGJ5IEozIG1lZXRpbmcNCg0KQXNzdW1lIExPQ0tfVFlQRSBpcyBhY2Nlc3NpYmxl IGZyb20gSVNPX0ZvcnRyYW5fRW52Lg0KDQpRVUVTVElPTjoNCg0KVGhlIGZvbGxvd2luZyB0eXBl IGRlZmluaXRpb24gYW5kIHZhcmlhYmxlIGRlY2xhcmF0aW9uIGFyZSBwZXJtaXR0ZWQgYnkNCkMx MzAyOg0KDQogIHR5cGUgOjogT25lDQogICAgdHlwZShsb2NrX3R5cGUpLCBwb2ludGVyIDo6IEwN CiAgZW5kIHR5cGUgT25lDQoNCiAgdHlwZShvbmUpLCBhbGxvY2F0YWJsZSA6OiBMMVsqXQ0KDQpD MTMwMiByZXF1aXJlcyBhIG5hbWVkIHZhcmlhYmxlIG9mIExPQ0tfVFlQRSB0byBiZSBhIGNvYXJy YXkuICBDNTI2DQpyZXF1aXJlcyBhIGNvYXJyYXkgdG8gYmUgYWxsb2NhdGFibGUgb3IgdG8gaGF2 ZSB0aGUgU0FWRSBhdHRyaWJ1dGUuDQoNClRoZSBmb2xsb3dpbmcgZGVjbGFyYXRpb24gaXMgYXBw YXJlbnRseSBwcm9oaWJpdGVkIGJlY2F1c2UgTDQgaXMNCm5vdCBhIGNvYXJyYXk6DQoNCiAgdHlw ZShsb2NrX3R5cGUpLCBwb2ludGVyIDo6IEw0DQoNCldhcyBpdCBpbnRlbmRlZCB0aGF0IHBvaW50 ZXIgY29tcG9uZW50cyBvZiB0eXBlIExPQ0tfVFlQRSBiZSBwZXJtaXR0ZWQsDQpidXQgdGhhdCBu YW1lZCB2YXJpYWJsZXMgb2YgdHlwZSBMT0NLX1RZUEUgd2l0aCB0aGUgUE9JTlRFUiBhdHRyaWJ1 dGUgYmUNCnByb2hpYml0ZWQ/DQoNCkFOU1dFUjoNCg0KSXQgd2FzIGludGVuZGVkIHRoYXQgY29t cG9uZW50cyBvZiB0eXBlIExPQ0tfVFlQRSBub3QgYmUgcGVybWl0dGVkIHRvDQpoYXZlIHRoZSBQ T0lOVEVSIGF0dHJpYnV0ZS4gIEVkaXRzIGFyZSBwcm92aWRlZCB0byBjb3JyZWN0IHRoaXMgbWlz dGFrZS4NCg0KRURJVFM6DQoNClszOTk6MTgrXSAxMy44LjIuMTYgTE9DS19UWVBFLCBhZnRlciBD MTMwMiwgaW5zZXJ0IG5ldyBjb25zdHJhaW50DQogICJDMTMwMmEgQSBjb21wb25lbnQgb2YgdHlw ZSBMT0NLX1RZUEUsIG9yIHRoYXQgaGFzIGEgbm9uYWxsb2NhdGFibGUNCiAgICAgICAgIGRpcmVj dCBjb21wb25lbnQgb2YgdHlwZSBMT0NLX1RZUEUsIHNoYWxsIG5vdCBoYXZlIHRoZQ0KICAgICAg ICAgUE9JTlRFUiBhdHRyaWJ1dGUuIi4NCg0KU1VCTUlUVEVEIEJZOiBWYW4gU255ZGVyDQoNCkhJ U1RPUlk6IDE0LTE0MCAgICBtMjA0ICBGMDgvMDExNCBzdWJtaXR0ZWQNCiAgICAgICAgIDE0LTE0 MHIxICBtMjA0ICBSZXZpc2VkIHRvIHJldmVyc2UgZGVjaXNpb24NCiAgICAgICAgIDE0LTE0MHIy ICBtMjA0ICBQYXNzZWQgYnkgSjMgbWVldGluZw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= --_004_4AA982B1265F43408480F737BE12F4D35F92E4F5ORSMSX103amrcor_--