From oldham at codesourcery.com  Fri Jun  1 16:33:14 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Fri, 1 Jun 2001 09:33:14 -0700
Subject: Oldham's Weekly Report
Message-ID: <200106011633.JAA16756@oz.codesourcery.com>


This week, I:
  committed one more source code patch
  submitted another patch for approval
    To review this patch:

      1) point your browser to http://pooma.codesourcery.com:4242/track/
      2) log in using your last name as your username and your password
      3) Enter `reorder_patch' as the Issue ID.

Next week, I will return to working on Pooma.  I hope to work with
Stephen Smith to implement the interpolation and restriction operators
proposal and incorporate into the kernel.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From mark at codesourcery.com  Mon Jun  4 05:35:29 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Sun, 03 Jun 2001 22:35:29 -0700
Subject: [pooma-dev] docbook overview
Message-ID: <20010603223529V.mitchell@codesourcery.com>

>>>>> "Scott" == Scott Haney <scotth at proximation.com> writes:

    Scott> We'll give DocBook a try subject to the caveat that we're
    Scott> not going to spend time porting this to MacOS X or Windows,
    Scott> which means that we may be checking in badly-formed files
    Scott> that others will have to debug. Also, if it sucks for us,
    Scott> we'll provide input in other forms and allow the DocBook
    Scott> boosters to convert. Sound fair?

Yes, I think that's fair.

Thanks,

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From allan at stokes.ca  Tue Jun  5 08:40:26 2001
From: allan at stokes.ca (Allan Stokes)
Date: Tue, 5 Jun 2001 01:40:26 -0700
Subject: status
In-Reply-To: <20010603223529V.mitchell@codesourcery.com>
Message-ID: <NABBJEAOKIDHLPHKHPDLMEDNEBAA.allan@stokes.ca>


Last week I finished setting up Redhat 7.1 with the new KAI 4.0e release.  I
set up a Samba share so that I can develop under Redhat and NT against a
single checkout repository.

I solved my remaining problems with my DocBook configuration under NT.  I
wrote some small DocBook test documents and generated a variety of output
formats for different document types under NT with Jade and under Redhat
with the preconfigured OpenJade.  Everything seems to work.

I began authoring a test document in DocBook describing an approach to
optimal uniform partitioning which caught my fancy while I was reviewing
code in src/Partition.  This will be a two or three page exploration of
writing simple equations, psuedo-code, code formatting, etc. in a DocBook
context.

This week I will document the Pooma domain concept, and perhaps contribute
some documentation to the NewField div stencil which Jeffrey and Stephen are
presently working on.  I suggested that I begin by comparing Jeffrey's Pooma
implementation to similar constructs from the Blitz library, which factors
the code quite differently.




From scotth at proximation.com  Tue Jun  5 15:03:30 2001
From: scotth at proximation.com (Scott Haney)
Date: Tue, 5 Jun 2001 09:03:30 -0600
Subject: [pooma-dev] status
In-Reply-To: <NABBJEAOKIDHLPHKHPDLMEDNEBAA.allan@stokes.ca>
Message-ID: <mailman.35.1331172044.20475.pooma-dev@codesourcery.com>


On Tuesday, June 5, 2001, at 02:40 AM, Allan Stokes wrote:

> I began authoring a test document in DocBook describing an approach to
> optimal uniform partitioning which caught my fancy while I was reviewing
> code in src/Partition.  This will be a two or three page exploration of
> writing simple equations, psuedo-code, code formatting, etc. in a 
> DocBook
> context.
>
> This week I will document the Pooma domain concept, and perhaps 
> contribute
> some documentation to the NewField div stencil which Jeffrey and 
> Stephen are
> presently working on.  I suggested that I begin by comparing Jeffrey's 
> Pooma
> implementation to similar constructs from the Blitz library, which 
> factors
> the code quite differently.

Hi Allan,

This sounds like a very good plan.

When you're looking at domains, could you also try to construct a plan 
for simplifying the current implementation, which makes domains more 
heavyweight and harder to optimize than they should be, and improving 
the physical design.

Comparing with Blitz is always a good thing since Todd has great ideas. 
However, support for parallelism; first-class fields with geometry, 
centering, and boundary conditions; and arbitrary data representation 
provide some additional constraints that drive our design. We'd need to 
have some *really* good reasons to start changing things very much at 
this point. BTW, there is another interesting package that uses 
sophisticated stencil objects from LANL called Pdeum. The developer's 
name is Martin Staley at mstaley at lanl.gov.

Scott

P.S. Most of the Proximation folks have been working away on an internal 
project, which is supposed to be done by mid-June. Therefore, there is 
not a lot of POOMA progress to report. Also, I'm going on vacation June 
7. I'll be back June 18th. Stephen is going on vacation June 11 and will 
be back the same day as me. We're both going to get some POOMA work in 
before we leave.


From oldham at codesourcery.com  Tue Jun  5 18:44:34 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Tue, 5 Jun 2001 11:44:34 -0700
Subject: Patch: Reorder Member and Base Class Initializers
Message-ID: <20010605114434.B5180@codesourcery.com>

The patch basically consisted of reordering member initializers for
constructors.

2001 Jun 05  Jeffrey D. Oldham  <oldham at codesoucery.com>

	* Layout/LayoutBase.h (LayoutBaseData::LayoutBaseData): Reorder
	member initializers.
	* Layout/UniformGridLayout.h
	(UniformGridLayout::UniformGridLayout): Reorder base class
	initialization.
	* Partition/UniformGridPartition.h
	(UniformGridPartition::operator=): Reorder initializations.
	(UniformGridPartition::UniformGridPartition): Reorder
	member initializers.
	* Utilities/RefCountedBlockPtr.h
	(RefCountedBlockPtr::RefCountedBlockPtr): Likewise.

Tested on	sequential Linux using gcc 3.0 by compiling library
Approved by	Stephen Smith (stephens at proximation.com)

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: Layout/LayoutBase.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Layout/LayoutBase.h,v
retrieving revision 1.22
diff -c -p -r1.22 LayoutBase.h
*** Layout/LayoutBase.h	2001/05/04 15:41:28	1.22
--- Layout/LayoutBase.h	2001/05/29 22:01:13
*************** public:
*** 131,142 ****
    LayoutBaseData()
      :
      ID_m(Unique::get()),
      hasInternalGuards_m(false), 
      hasExternalGuards_m(false), 
-     externalGuards_m(0), 
      internalGuards_m(0),
!     domain_m(Interval<Dim>()), 
!     innerdomain_m(Interval<Dim>())
    {
    }
  
--- 131,142 ----
    LayoutBaseData()
      :
      ID_m(Unique::get()),
+     domain_m(Interval<Dim>()), 
+     innerdomain_m(Interval<Dim>()),
      hasInternalGuards_m(false), 
      hasExternalGuards_m(false), 
      internalGuards_m(0),
!     externalGuards_m(0)
    {
    }
  
*************** public:
*** 145,156 ****
  		 Domain_t d, Domain_t id)
      :
      ID_m(Unique::get()),
      hasInternalGuards_m(hasIG), 
      hasExternalGuards_m(hasEG), 
-     externalGuards_m(eg), 
      internalGuards_m(ig),
!     domain_m(d), 
!     innerdomain_m(id)
    {
    }
  
--- 145,156 ----
  		 Domain_t d, Domain_t id)
      :
      ID_m(Unique::get()),
+     domain_m(d), 
+     innerdomain_m(id),
      hasInternalGuards_m(hasIG), 
      hasExternalGuards_m(hasEG), 
      internalGuards_m(ig),
!     externalGuards_m(eg) 
    {
    }
  
Index: Layout/UniformGridLayout.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Layout/UniformGridLayout.h,v
retrieving revision 1.82
diff -c -p -r1.82 UniformGridLayout.h
*** Layout/UniformGridLayout.h	2001/05/04 15:41:28	1.82
--- Layout/UniformGridLayout.h	2001/05/29 22:01:14
*************** public:
*** 1629,1637 ****
  template <int Dim>
  inline UniformGridLayout<Dim>::
  UniformGridLayout()
! : Observable<This_t>(*this), 
!   LayoutBase<Dim,UniformGridLayoutData<Dim> >
!     (new LayoutData_t())
  { 
    pdata_m->attach(*this);
  }
--- 1629,1637 ----
  template <int Dim>
  inline UniformGridLayout<Dim>::
  UniformGridLayout()
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
!     (new LayoutData_t()),
!   Observable<This_t>(*this)
  { 
    pdata_m->attach(*this);
  }
*************** template <int Dim>
*** 1640,1650 ****
  inline UniformGridLayout<Dim>::
  UniformGridLayout(const Domain_t &gdom,
  		  const DistributedTag& t)
! : Observable<This_t>(*this), 
!   LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(),
! 		      DistributedMapper<Dim>(UniformGridPartition<Dim>())))
  {
    pdata_m->attach(*this);
  }
--- 1640,1650 ----
  inline UniformGridLayout<Dim>::
  UniformGridLayout(const Domain_t &gdom,
  		  const DistributedTag& t)
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(),
! 		      DistributedMapper<Dim>(UniformGridPartition<Dim>()))),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** template <int Dim>
*** 1653,1663 ****
  inline UniformGridLayout<Dim>::
  UniformGridLayout(const Domain_t &gdom,
  		  const ReplicatedTag & t)
! : Observable<This_t>(*this), 
!   LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(),
! 		      LocalMapper<Dim>()))
  {
    pdata_m->attach(*this);
  }
--- 1653,1663 ----
  inline UniformGridLayout<Dim>::
  UniformGridLayout(const Domain_t &gdom,
  		  const ReplicatedTag & t)
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(),
! 		      LocalMapper<Dim>())),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** inline UniformGridLayout<Dim>::
*** 1667,1677 ****
  UniformGridLayout(const Domain_t &gdom, 
  		  const GuardLayers_t &gcs,
  		  const DistributedTag &)
! : Observable<This_t>(*this), 
!   LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(gcs),
! 		      DistributedMapper<Dim>(UniformGridPartition<Dim>(gcs))))
  {
    pdata_m->attach(*this);
  }
--- 1667,1677 ----
  UniformGridLayout(const Domain_t &gdom, 
  		  const GuardLayers_t &gcs,
  		  const DistributedTag &)
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(gcs),
! 		      DistributedMapper<Dim>(UniformGridPartition<Dim>(gcs)))),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** inline UniformGridLayout<Dim>::
*** 1681,1691 ****
  UniformGridLayout(const Domain_t &gdom, 
  		  const GuardLayers_t &gcs,
  		  const ReplicatedTag & )
! : Observable<This_t>(*this), 
!   LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(gcs),
! 		      LocalMapper<Dim>()))
  {
    pdata_m->attach(*this);
  }
--- 1681,1691 ----
  UniformGridLayout(const Domain_t &gdom, 
  		  const GuardLayers_t &gcs,
  		  const ReplicatedTag & )
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(gcs),
! 		      LocalMapper<Dim>())),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** inline UniformGridLayout<Dim>::
*** 1695,1706 ****
  UniformGridLayout(const Domain_t &gdom, 
  		  const Loc<Dim> &blocks,
  		  const DistributedTag & )
! : Observable<This_t>(*this), 
!   LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(blocks),
  		      DistributedMapper<Dim>(
!                          UniformGridPartition<Dim>(blocks))))
  {
    pdata_m->attach(*this);
  }
--- 1695,1706 ----
  UniformGridLayout(const Domain_t &gdom, 
  		  const Loc<Dim> &blocks,
  		  const DistributedTag & )
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(blocks),
  		      DistributedMapper<Dim>(
! 		        UniformGridPartition<Dim>(blocks)))),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** inline UniformGridLayout<Dim>::
*** 1710,1720 ****
  UniformGridLayout(const Domain_t &gdom, 
  		  const Loc<Dim> &blocks,
  		  const ReplicatedTag & t)
! : Observable<This_t>(*this), 
!   LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(blocks),
! 		      LocalMapper<Dim>()))
  {
    pdata_m->attach(*this);
  }
--- 1710,1720 ----
  UniformGridLayout(const Domain_t &gdom, 
  		  const Loc<Dim> &blocks,
  		  const ReplicatedTag & t)
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(blocks),
! 		      LocalMapper<Dim>())),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** UniformGridLayout(const Domain_t &gdom, 
*** 1725,1736 ****
                    const Loc<Dim> &blocks, 
                    const GuardLayers_t &igcs,
  		  const DistributedTag &)
! : Observable<This_t>(*this), 
!  LayoutBase<Dim,UniformGridLayoutData<Dim> >
     (new LayoutData_t(gdom,
  		     UniformGridPartition<Dim>(blocks,igcs),
  		     DistributedMapper<Dim>(
!                        UniformGridPartition<Dim>(blocks,igcs))))
  {
    pdata_m->attach(*this);
  }
--- 1725,1736 ----
                    const Loc<Dim> &blocks, 
                    const GuardLayers_t &igcs,
  		  const DistributedTag &)
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
     (new LayoutData_t(gdom,
  		     UniformGridPartition<Dim>(blocks,igcs),
  		     DistributedMapper<Dim>(
! 		      UniformGridPartition<Dim>(blocks,igcs)))),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** UniformGridLayout(const Domain_t &gdom, 
*** 1741,1751 ****
                    const Loc<Dim> &blocks, 
                    const GuardLayers_t &igcs,
  		  const ReplicatedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,UniformGridLayoutData<Dim> >
!        (new LayoutData_t(gdom,
! 			 UniformGridPartition<Dim>(blocks,igcs),
! 			 LocalMapper<Dim>()))
  {
    pdata_m->attach(*this);
  }
--- 1741,1751 ----
                    const Loc<Dim> &blocks, 
                    const GuardLayers_t &igcs,
  		  const ReplicatedTag &)
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
!      (new LayoutData_t(gdom,
! 		       UniformGridPartition<Dim>(blocks,igcs),
! 		       LocalMapper<Dim>())),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** UniformGridLayout(const Domain_t &gdom, 
*** 1758,1769 ****
                    const GuardLayers_t &egcs,
  		  const DistributedTag &)
       
! : Observable<This_t>(*this), 
!  LayoutBase<Dim,UniformGridLayoutData<Dim> >
! (new LayoutData_t(gdom,
! 		  UniformGridPartition<Dim>(blocks,igcs,egcs),
! 		  DistributedMapper<Dim>(
! 		    UniformGridPartition<Dim>(blocks,igcs,egcs))))
  {
    pdata_m->attach(*this);
  }
--- 1758,1769 ----
                    const GuardLayers_t &egcs,
  		  const DistributedTag &)
       
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
!     (new LayoutData_t(gdom,
! 		      UniformGridPartition<Dim>(blocks,igcs,egcs),
! 		      DistributedMapper<Dim>(
!                        UniformGridPartition<Dim>(blocks,igcs,egcs)))),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** UniformGridLayout(const Domain_t &gdom, 
*** 1775,1785 ****
                    const GuardLayers_t &igcs, 
                    const GuardLayers_t &egcs,
  		  const ReplicatedTag &t)
! : Observable<This_t>(*this), 
!  LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(blocks,igcs,egcs),
! 		      LocalMapper<Dim>()))
  {
    pdata_m->attach(*this);
  }
--- 1775,1785 ----
                    const GuardLayers_t &igcs, 
                    const GuardLayers_t &egcs,
  		  const ReplicatedTag &t)
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
      (new LayoutData_t(gdom,
  		      UniformGridPartition<Dim>(blocks,igcs,egcs),
! 		      LocalMapper<Dim>())),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** inline UniformGridLayout<Dim>::
*** 1790,1798 ****
  UniformGridLayout(const Domain_t &gdom, 
  		  const Partitioner &gpar,
  		  const DistributedTag & )
! : Observable<This_t>(*this),
!   LayoutBase<Dim,UniformGridLayoutData<Dim> >
!    (new LayoutData_t(gdom,gpar,DistributedMapper<Dim>(gpar)))
  {
    pdata_m->attach(*this);
  }
--- 1790,1798 ----
  UniformGridLayout(const Domain_t &gdom, 
  		  const Partitioner &gpar,
  		  const DistributedTag & )
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
!    (new LayoutData_t(gdom,gpar,DistributedMapper<Dim>(gpar))),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** inline UniformGridLayout<Dim>::
*** 1803,1811 ****
  UniformGridLayout(const Domain_t &gdom, 
  		  const Partitioner &gpar,
  		  const ReplicatedTag &)
! : Observable<This_t>(*this),
!  LayoutBase<Dim,UniformGridLayoutData<Dim> >
!    (new LayoutData_t(gdom,gpar,LocalMapper<Dim>()))
  {
    pdata_m->attach(*this);
  }
--- 1803,1811 ----
  UniformGridLayout(const Domain_t &gdom, 
  		  const Partitioner &gpar,
  		  const ReplicatedTag &)
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
!    (new LayoutData_t(gdom,gpar,LocalMapper<Dim>())),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** inline UniformGridLayout<Dim>::
*** 1816,1824 ****
  UniformGridLayout(const Domain_t &gdom, 
  		  const Partitioner &gpar,
  		  const ContextMapper<Dim> & cmap)
! : Observable<This_t>(*this), 
!  LayoutBase<Dim,UniformGridLayoutData<Dim> >
!    (new LayoutData_t(gdom,gpar,cmap))
  {
    pdata_m->attach(*this);
  }
--- 1816,1824 ----
  UniformGridLayout(const Domain_t &gdom, 
  		  const Partitioner &gpar,
  		  const ContextMapper<Dim> & cmap)
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >
!     (new LayoutData_t(gdom,gpar,cmap)),
!   Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** UniformGridLayout(const Domain_t &gdom, 
*** 1826,1833 ****
  template <int Dim>
  inline UniformGridLayout<Dim>::
  UniformGridLayout(const This_t &model) 
!   : LayoutBase<Dim,UniformGridLayoutData<Dim> >(model.pdata_m),
!     Observable<This_t>(*this)
  { 
     pdata_m->attach(*this);
  }
--- 1826,1833 ----
  template <int Dim>
  inline UniformGridLayout<Dim>::
  UniformGridLayout(const This_t &model) 
! : LayoutBase<Dim,UniformGridLayoutData<Dim> >(model.pdata_m),
!   Observable<This_t>(*this)
  { 
     pdata_m->attach(*this);
  }
Index: Partition/UniformGridPartition.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Partition/UniformGridPartition.h,v
retrieving revision 1.24
diff -c -p -r1.24 UniformGridPartition.h
*** Partition/UniformGridPartition.h	2001/04/18 01:41:44	1.24
--- Partition/UniformGridPartition.h	2001/05/29 22:01:15
*************** public:
*** 223,233 ****
    {
      if (this != &g)
        {
  	hasGuards_m           = g.hasGuards_m;
  	hasCustomEdgeGuards_m = g.hasCustomEdgeGuards_m;
  	internalGuards_m      = g.internalGuards_m;
  	externalGuards_m      = g.externalGuards_m;
- 	blocks_m              = g.blocks();
  	num_m                 = g.maxSize();
        }
      return *this;
--- 223,233 ----
    {
      if (this != &g)
        {
+ 	blocks_m              = g.blocks();
  	hasGuards_m           = g.hasGuards_m;
  	hasCustomEdgeGuards_m = g.hasCustomEdgeGuards_m;
  	internalGuards_m      = g.internalGuards_m;
  	externalGuards_m      = g.externalGuards_m;
  	num_m                 = g.maxSize();
        }
      return *this;
*************** UniformGridPartition(const GuardLayers<D
*** 501,509 ****
  template <int Dim>
  inline UniformGridPartition<Dim>::
  UniformGridPartition(const Loc<Dim> &a)
! : hasGuards_m(false), 
!   hasCustomEdgeGuards_m(false),
!   blocks_m(a) 
  {
    calcNum();
  }
--- 501,509 ----
  template <int Dim>
  inline UniformGridPartition<Dim>::
  UniformGridPartition(const Loc<Dim> &a)
! : blocks_m(a),
!   hasGuards_m(false), 
!   hasCustomEdgeGuards_m(false)
  {
    calcNum();
  }
*************** template <int Dim>
*** 512,522 ****
  inline UniformGridPartition<Dim>::
  UniformGridPartition(const Loc<Dim> &a, 
                       const GuardLayers<Dim> &gcs)
! : hasGuards_m(gcs != 0), 
    hasCustomEdgeGuards_m(false), 
    internalGuards_m(gcs), 
!   externalGuards_m(gcs),
!   blocks_m(a) 
  {
    calcNum();
  }
--- 512,522 ----
  inline UniformGridPartition<Dim>::
  UniformGridPartition(const Loc<Dim> &a, 
                       const GuardLayers<Dim> &gcs)
! : blocks_m(a),
!   hasGuards_m(gcs != 0), 
    hasCustomEdgeGuards_m(false), 
    internalGuards_m(gcs), 
!   externalGuards_m(gcs)
  {
    calcNum();
  }
*************** inline UniformGridPartition<Dim>::
*** 526,536 ****
  UniformGridPartition(const Loc<Dim> &a, 
                       const GuardLayers<Dim> &igcs,
                       const GuardLayers<Dim> &egcs)
! : hasGuards_m(igcs != 0 || egcs != 0), 
    hasCustomEdgeGuards_m(igcs != egcs), 
    internalGuards_m(igcs), 
!   externalGuards_m(egcs),
!   blocks_m(a) 
  {
    calcNum();
  }
--- 526,536 ----
  UniformGridPartition(const Loc<Dim> &a, 
                       const GuardLayers<Dim> &igcs,
                       const GuardLayers<Dim> &egcs)
! : blocks_m(a),
!   hasGuards_m(igcs != 0 || egcs != 0), 
    hasCustomEdgeGuards_m(igcs != egcs), 
    internalGuards_m(igcs), 
!   externalGuards_m(egcs)
  {
    calcNum();
  }
*************** UniformGridPartition(const Loc<Dim> &a, 
*** 538,548 ****
  template <int Dim>
  inline UniformGridPartition<Dim>::
  UniformGridPartition(const UniformGridPartition<Dim> &b)
! : hasGuards_m(b.hasGuards_m), 
    hasCustomEdgeGuards_m(b.hasCustomEdgeGuards_m), 
    internalGuards_m(b.internalGuards_m), 
    externalGuards_m(b.externalGuards_m),
-   blocks_m(b.blocks_m), 
    num_m(b.num_m) 
  { }
  
--- 538,548 ----
  template <int Dim>
  inline UniformGridPartition<Dim>::
  UniformGridPartition(const UniformGridPartition<Dim> &b)
! : blocks_m(b.blocks_m), 
!   hasGuards_m(b.hasGuards_m), 
    hasCustomEdgeGuards_m(b.hasCustomEdgeGuards_m), 
    internalGuards_m(b.internalGuards_m), 
    externalGuards_m(b.externalGuards_m),
    num_m(b.num_m) 
  { }
  
Index: Utilities/RefCountedBlockPtr.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Utilities/RefCountedBlockPtr.h,v
retrieving revision 1.61
diff -c -p -r1.61 RefCountedBlockPtr.h
*** Utilities/RefCountedBlockPtr.h	2001/05/14 21:11:24	1.61
--- Utilities/RefCountedBlockPtr.h	2001/05/29 22:01:15
*************** public:
*** 588,605 ****
    { }
  
    inline RefCountedBlockPtr(size_t size, const T & model)
!     : blockControllerPtr_m(new Controller(size,model)),
!       offset_m(0)
    { }
  
    inline RefCountedBlockPtr(size_t size, const NoInitTag &)
!     : blockControllerPtr_m(new Controller(size,
  #ifndef __MWERKS__
! 					  typename Controller::NoInitTag())),
  #else
! 					  Controller::NoInitTag())),
  #endif
-       offset_m(0)
    { 
  #ifndef __MWERKS__
      blockControllerPtr_m->resize(0,typename Controller::NoInitTag());
--- 588,605 ----
    { }
  
    inline RefCountedBlockPtr(size_t size, const T & model)
!     : offset_m(0),
!       blockControllerPtr_m(new Controller(size,model))
    { }
  
    inline RefCountedBlockPtr(size_t size, const NoInitTag &)
!     : offset_m(0),
!       blockControllerPtr_m(new Controller(size,
  #ifndef __MWERKS__
! 					  typename Controller::NoInitTag()))
  #else
! 					  Controller::NoInitTag()))
  #endif
    { 
  #ifndef __MWERKS__
      blockControllerPtr_m->resize(0,typename Controller::NoInitTag());
*************** public:
*** 613,620 ****
    // but not the bounds checking.
  
    inline RefCountedBlockPtr(T *p, size_t size)
!     : blockControllerPtr_m(new Controller(p, size)),
!       offset_m(0)
    { }
    
    // Copy constructor
--- 613,620 ----
    // but not the bounds checking.
  
    inline RefCountedBlockPtr(T *p, size_t size)
!     : offset_m(0),
!       blockControllerPtr_m(new Controller(p, size))
    { }
    
    // Copy constructor
*************** public:
*** 628,635 ****
    // checking polarity (That_t).
  
    inline RefCountedBlockPtr(const That_t & model)
!     : blockControllerPtr_m(model.blockControllerPtr_m),
!       offset_m(model.offset_m)
    { }
  
    // Copy constructor with offset
--- 628,635 ----
    // checking polarity (That_t).
  
    inline RefCountedBlockPtr(const That_t & model)
!     : offset_m(model.offset_m),
!       blockControllerPtr_m(model.blockControllerPtr_m)
    { }
  
    // Copy constructor with offset

From johnharveyhall at qwest.net  Wed Jun  6 03:55:45 2001
From: johnharveyhall at qwest.net (John Hall)
Date: Tue, 5 Jun 2001 21:55:45 -0600
Subject: timings using optimized codewarrior
Message-ID: <v04220804b743471fabd9@[10.0.1.14]>

Gang:
Well, my student and I just got an optimized version of a simple 
little diffusion stencil using Metrowerks Codewarrior and frankly the 
results are kind of interesting. First, optimized code runs around 6 
times faster than unoptimzed code. Dave Nystrom and I seem to recall 
that optimized code under R1 ran 10-20 times faster than unoptimized 
using KCC. I don't want to attach too much significance to this 
though. It is an indicator that either Metrowerks optimizer is not 
all that hot (my belief) or that somehow the abstractions of R2 are 
somehow less onerous in debug mode (also a possibility).

Anyhow, this was a 2-D diffusion stencil and no matter what we tried 
we always got a linear response in the timing study. For the first 
block, this is a good result since we were just running the same size 
problem for more cycles.

But, we tried to run larger and larger problems to get us to go out 
of L2 cache (on this PIII we had a 256K L2 cache), and we were never 
able to notice a drop. It stayed linear versus the total number of 
cells. This will make more sense when we can convert the units to 
something like MFlops. So either you guys have done something really 
impressive regarding cache utilization, or we are running so slowly 
that cache misses are not noticeable.

Also, we ran optimized on a Mac and a PC and the result differed 
exactly by the difference in clock speed. This was a surprise, since 
Mac advocates had always claimed that the Motorola floating point 
performance was better than that of Intel at a given clock rate. 
(This was for a 650 MHZ PIII laptop and a 500 MHz G3 laptop).

As an aside, the Brick Engine ran reproducibly slightly slower than 
compressibleBrick (only about 5 percent, so it was basically a dead 
heat), but, I would have expected Brick to be slightly faster than 
compressibleBrick (and probably by more than a few percent since it 
should have less overhead).

Anyhow, here is the raw data for the Brick PIII runs:
cellsXY	cycles	elapsed time (secs):        Total Cells
101	1000	24	24	24		10201
101	2000	48	48	47		10201
101	3000	72	71	72		10201
101	5000	119	122	121		10201
101	10000	243	243	244		10201
101	25000	608	607	606		10201

25	1000	2	2	2		625
51	1000	6	5	5		2601
101	1000	24	24	24		10201
201	1000	103	103	103		40401
501	1000	635				251001
1001	1000	2520				1002001


15	5000	4	4	3		225
25	5000	8	9	8		625
51	5000	29	29	28		2601
75	5000	61	61	61		5625
101	5000	124				10201
201	5000	518				40401
401	5000	2054				160801


3	10000	3				9
6	10000	3				36
12	10000	6				144
24	10000	15				576

3	100000	28				9
6	100000	34				36
12	100000	59				144
24	100000	150				576

This was single processor with no MPI, etc under Win 2000. All I/O 
was turned off within the timed region so it was just Cycle Manager 
loop overhead (Tecolote Loops over models, in this case 1 Model) and 
floating point calculations being timed. There were 3 fields 
involved, Temperature, Conductivity and a TmpField to collect the 
stencil info. We used difftime and the time_t time functions to 
collect our data (in seconds), so only high granularity can be 
studied.

Code:
This is the relation between Conductivity (Lval) and Temperature:

template<class Traits>
void DiffRelation<Traits>::ConFuncT6( const ScalarField& Conductivity,
				      const ScalarField& Temperature ) {
     Conductivity = (1.0/(2.0*Dim))*pow(Temperature,Real(6.0));
}

This is the relation between TmpField (Lval) and Conductivity and Temperature:
template<class Traits>
void OffsetRelation<Traits>::sumNeighbors(const ScalarField& TmpField,
	const ScalarField& Conductivity, const ScalarField& Temperature ) {
	Interval<Dim> ND = Temperature.domain();
	Loc<Dim> offset;
	TmpField = 0.0;
	for ( int d = 0; d < Dim; ++d ) {
		for ( int off = 0; off < Dim; ++off ) {
		  offset[off] = off==d ? 1:0;
		}
		TmpField(ND) += 
Temperature(ND+offset)*Conductivity(ND+offset) +
				Temperature(ND-offset)*Conductivity(ND-offset);
	}
}

So the loop was just over this one line:

Temperature = (1.0-2.0*Conductivity*Dim)*Temperature + TmpField;

which kept causing the other two updater dependencies above to get 
called as relations.

There are some obvious optimizations which can be performed on this 
code, but, it was the relative timings of optimized and unoptimized 
executables (factor of 6) along with these simple scaling studies 
that we were interested in.

Hope this is interesting,
John Hall and Richard Williams




From wdn at lanl.gov  Wed Jun  6 17:03:19 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Wed, 6 Jun 2001 11:03:19 -0600
Subject: gcc
Message-ID: <15134.25175.82568.381984@saltydog.lanl.gov>

Can someone explain to me how gcc handles template instantiations.  I would
like to try using the new gcc 3.0 snapshot to build our applications on my
new laptop which is running RedHat 7.1.  I have several questions which I
will need to resolve in order to build our stuff with gcc.  I assume that I
need to invoke the gcc C++ compiler by using g++.  I am very experienced
using KCC.  With KCC, we actually use KCC on the command line to build both
the library and the executable.  When we build the library, we add lower
level libraries to the end of the command line so that KCC will perform
library closure and not have the prelinker instantiate functions or classes
that have already been instantiated in lower level libraries that we will be
linking against.  Does gcc have any support for this sort of thing?  With
KCC, or any EDG based compiler, files are first compiled without
instantiating any templates and a database is constructed which tells the
compiler what templates can be instantiated in any given translation unit.
Then the prelinker uses this database and it's knowledge of what templates
need to be instantiated to assign templates to a translation unit and then
that translation unit is recompiled.  Does gcc handle template instantiation
differently and if so, how?  Does gcc have any support analagous to the KCC
one instantiation per object capability?  Does gcc have support for
precompiled headers?  Should I use ar and ld on the command lines to build
the library and executable respectively or should I use g++?  How do I
use/build shared libraries with gcc?  Does gcc support the -rpath option or
something similar that allows you to build the shared library paths into the
executable?

I have built the gcc 3.0 snapshot on my new linux laptop running RH 7.1 and
it seemed to be successful although there was some problem with running the
checks.  If you can think of anything else I might need to know about using
g++, please let me know.  I assume Jeffrey or Mark will be the main
respondents to this email.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From wdn at lanl.gov  Wed Jun  6 17:17:30 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Wed, 6 Jun 2001 11:17:30 -0600
Subject: Prelinker Bug in KCC-4.0e
Message-ID: <15134.26026.296934.654215@saltydog.lanl.gov>

This is to let you know that I talked to Peter Hartman at KAI yesterday and
he confirmed that there is a bug in the prelinker for KCC-4.0e which causes
recompilation of alot of files when they are large including the side effect
of putting extra copies of functions in the same translation unit which would
contribute to code bloat and give multiple symbol definition warnings when
linking.

Peter is building a version of KCC-4.0d for RedHat 7.1 which should be
available by Thursday or Friday of this week.  I'm going to drop back to 4.0d
until the problem with 4.0e gets fixed.  I'll be beta testing 4.0e also when
Peter thinks he has the problem fixed.  If you want a copy of 4.0d for RH
7.1, let Peter know.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From stephens at proximation.com  Wed Jun  6 17:40:31 2001
From: stephens at proximation.com (Stephen Smith)
Date: Wed, 6 Jun 2001 10:40:31 -0700 
Subject: [pooma-dev] Prelinker Bug in KCC-4.0e
Message-ID: <F871BB04B0EA224A821A5274C31DF315021700@proxim-sf001.santafe.proximation.com>

You can compile using 4.0e if you use the --oneper option when
configuring pooma. (It's fine for POOMA examples, I don't know
how this would affect compile times for Blanca.)

    Stephen

-----Original Message-----
From: Dave Nystrom [mailto:wdn at lanl.gov]
Sent: Wednesday, June 06, 2001 11:18 AM
To: pooma-dev; Lee Ankeny; Steve Sydoriak; John Hall; Don Marshall; Jean
Marshall
Cc: Peter Hartman
Subject: [pooma-dev] Prelinker Bug in KCC-4.0e


This is to let you know that I talked to Peter Hartman at KAI yesterday and
he confirmed that there is a bug in the prelinker for KCC-4.0e which causes
recompilation of alot of files when they are large including the side effect
of putting extra copies of functions in the same translation unit which
would
contribute to code bloat and give multiple symbol definition warnings when
linking.

Peter is building a version of KCC-4.0d for RedHat 7.1 which should be
available by Thursday or Friday of this week.  I'm going to drop back to
4.0d
until the problem with 4.0e gets fixed.  I'll be beta testing 4.0e also when
Peter thinks he has the problem fixed.  If you want a copy of 4.0d for RH
7.1, let Peter know.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010606/cb74a9a9/attachment.html>

From wdn at lanl.gov  Wed Jun  6 17:41:29 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Wed, 6 Jun 2001 11:41:29 -0600
Subject: Problem checking the build of gcc
Message-ID: <15134.27465.936992.200470@saltydog.lanl.gov>

Hi Jeffrey,

Here is the build log from my attempt to perform the checks of my gcc build.

Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046

----------------------------------build-log--------------------------------------------------
saltydog % pwd
/home/wdn/packages/tmp/gcc-3.0-20010527/objdir/gcc

saltydog % make -j 3 check
(rootme=`pwd`; export rootme; \
srcdir=`cd ../../gcc; pwd` ; export srcdir ; \
cd testsuite; \
EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo ${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then  \
   TCL_LIBRARY=`cd .. ; cd ../../gcc/../tcl/library ; pwd` ; \
   export TCL_LIBRARY ; fi ; \
`if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo ${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gcc )
(rootme=`pwd`; export rootme; \
srcdir=`cd ../../gcc; pwd` ; export srcdir ; \
cd testsuite; \
EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo ${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then  \
   TCL_LIBRARY=`cd .. ; cd ../../gcc/../tcl/library ; pwd` ; \
    export TCL_LIBRARY ; fi ; \
`if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo ${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool g++ )
(rootme=`pwd`; export rootme; \
srcdir=`cd ../../gcc; pwd` ; export srcdir ; \
cd testsuite; \
EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo ${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then  \
   TCL_LIBRARY=`cd .. ; cd ../../gcc/../tcl/library ; pwd` ; \
   export TCL_LIBRARY ; fi ; \
`if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo ${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool g77 )
/bin/sh: runtest: command not found
make: [check-gcc] Error 127 (ignored)
(rootme=`pwd`; export rootme; \
srcdir=`cd ../../gcc; pwd` ; export srcdir ; \
cd testsuite; \
EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo ${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then  \
   TCL_LIBRARY=`cd .. ; cd ../../gcc/../tcl/library ; pwd` ; \
    export TCL_LIBRARY ; fi ; \
`if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo ${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool objc )
/bin/sh: runtest: command not found
make: [check-objc] Error 127 (ignored)
if test -f cp/Makefile && test -f f/Makefile && \
   test -f java/Makefile && test -f objc/Makefile; then \
   make -C po check-po; \
fi
/bin/sh: runtest: command not found
make: [check-g++] Error 127 (ignored)
/bin/sh: runtest: command not found
make: [check-g77] Error 127 (ignored)


From wdn at lanl.gov  Wed Jun  6 17:52:41 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Wed, 6 Jun 2001 11:52:41 -0600
Subject: [pooma-dev] Prelinker Bug in KCC-4.0e
In-Reply-To: <F871BB04B0EA224A821A5274C31DF315021700@proxim-sf001.santafe.proximation.com>
References: <F871BB04B0EA224A821A5274C31DF315021700@proxim-sf001.santafe.proximation.com>
Message-ID: <15134.28137.515127.644702@saltydog.lanl.gov>

Stephen Smith writes:
 > You can compile using 4.0e if you use the --oneper option when
 > configuring pooma. (It's fine for POOMA examples, I don't know
 > how this would affect compile times for Blanca.)

Using oneper adds about a 50% hit on compile times on my Linux box.  On
bluemountain, in the past it has been basically intolerable.

Are you saying that the prelinker bug does not exist for 4.0e if you use
--oneper or that by using oneper, it fixes the problem of multiple symbol
warnings.  I suspect the latter.

Anyway, for me on my new laptop, we are basically talking about intolerable
compile times - it takes 7-8 hours to build a debug copy of everything from
scratch and so you can see my reluctance to make that time 50% longer.
Things are exacerbated with this prelinker bug because several files are
being recompiled more than once by the prelinker and they tend to be the
largest ones that take the longest to recompile.  Things are also exacerbated
by the problems in Pooma 2 which are keeping me from being able to explicitly
instantiate all the Pooma functions.  Hopefully Scott is making some progress
on this.

Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046

 >     Stephen
 > 
 > -----Original Message-----
 > From: Dave Nystrom [mailto:wdn at lanl.gov]
 > Sent: Wednesday, June 06, 2001 11:18 AM
 > To: pooma-dev; Lee Ankeny; Steve Sydoriak; John Hall; Don Marshall; Jean
 > Marshall
 > Cc: Peter Hartman
 > Subject: [pooma-dev] Prelinker Bug in KCC-4.0e
 > 
 > 
 > This is to let you know that I talked to Peter Hartman at KAI yesterday and
 > he confirmed that there is a bug in the prelinker for KCC-4.0e which causes
 > recompilation of alot of files when they are large including the side effect
 > of putting extra copies of functions in the same translation unit which
 > would
 > contribute to code bloat and give multiple symbol definition warnings when
 > linking.
 > 
 > Peter is building a version of KCC-4.0d for RedHat 7.1 which should be
 > available by Thursday or Friday of this week.  I'm going to drop back to
 > 4.0d
 > until the problem with 4.0e gets fixed.  I'll be beta testing 4.0e also when
 > Peter thinks he has the problem fixed.  If you want a copy of 4.0d for RH
 > 7.1, let Peter know.
 > 
 > -- 
 > Dave Nystrom			email: wdn at lanl.gov
 > LANL X-3			phone: 505-667-7913	fax: 505-665-3046
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
 > <TITLE>RE: [pooma-dev] Prelinker Bug in KCC-4.0e</TITLE>
 > </HEAD>
 > <BODY>
 > 
 > <P><FONT SIZE=2>You can compile using 4.0e if you use the --oneper option when</FONT>
 > <BR><FONT SIZE=2>configuring pooma. (It's fine for POOMA examples, I don't know</FONT>
 > <BR><FONT SIZE=2>how this would affect compile times for Blanca.)</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; Stephen</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>-----Original Message-----</FONT>
 > <BR><FONT SIZE=2>From: Dave Nystrom [<A HREF="mailto:wdn at lanl.gov">mailto:wdn at lanl.gov</A>]</FONT>
 > <BR><FONT SIZE=2>Sent: Wednesday, June 06, 2001 11:18 AM</FONT>
 > <BR><FONT SIZE=2>To: pooma-dev; Lee Ankeny; Steve Sydoriak; John Hall; Don Marshall; Jean</FONT>
 > <BR><FONT SIZE=2>Marshall</FONT>
 > <BR><FONT SIZE=2>Cc: Peter Hartman</FONT>
 > <BR><FONT SIZE=2>Subject: [pooma-dev] Prelinker Bug in KCC-4.0e</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2>This is to let you know that I talked to Peter Hartman at KAI yesterday and</FONT>
 > <BR><FONT SIZE=2>he confirmed that there is a bug in the prelinker for KCC-4.0e which causes</FONT>
 > <BR><FONT SIZE=2>recompilation of alot of files when they are large including the side effect</FONT>
 > <BR><FONT SIZE=2>of putting extra copies of functions in the same translation unit which would</FONT>
 > <BR><FONT SIZE=2>contribute to code bloat and give multiple symbol definition warnings when</FONT>
 > <BR><FONT SIZE=2>linking.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Peter is building a version of KCC-4.0d for RedHat 7.1 which should be</FONT>
 > <BR><FONT SIZE=2>available by Thursday or Friday of this week.&nbsp; I'm going to drop back to 4.0d</FONT>
 > <BR><FONT SIZE=2>until the problem with 4.0e gets fixed.&nbsp; I'll be beta testing 4.0e also when</FONT>
 > <BR><FONT SIZE=2>Peter thinks he has the problem fixed.&nbsp; If you want a copy of 4.0d for RH</FONT>
 > <BR><FONT SIZE=2>7.1, let Peter know.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>-- </FONT>
 > <BR><FONT SIZE=2>Dave Nystrom&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; email: wdn at lanl.gov</FONT>
 > <BR><FONT SIZE=2>LANL X-3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; phone: 505-667-7913&nbsp;&nbsp;&nbsp;&nbsp; fax: 505-665-3046</FONT>
 > </P>
 > 
 > </BODY>
 > </HTML>


From scotth at proximation.com  Wed Jun  6 18:33:19 2001
From: scotth at proximation.com (Scott Haney)
Date: Wed, 6 Jun 2001 12:33:19 -0600
Subject: [pooma-dev] Prelinker Bug in KCC-4.0e
In-Reply-To: <15134.28137.515127.644702@saltydog.lanl.gov>
Message-ID: <mailman.36.1331172044.20475.pooma-dev@codesourcery.com>


On Wednesday, June 6, 2001, at 11:52 AM, Dave Nystrom wrote:

> Hopefully Scott is making some progress
> on this.

Ahem, I have to admit that I haven't spent much time on this due to an 
internal Proximation deadline.

Moreover, I'm going to Disneyland  (really!) at 4pm today and will 
return on June 18th.

I agree that the compile times you describe are too long. When I get 
back, I'll look into this from the POOMA perspective. However, I've got 
to  think that there are physical design issues on the Blanca-side or 
maybe compiler issues that are playing into this.

Scott


From oldham at codesourcery.com  Wed Jun  6 18:38:19 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Wed, 6 Jun 2001 11:38:19 -0700
Subject: [pooma-dev] Problem checking the build of gcc
In-Reply-To: <15134.27465.936992.200470@saltydog.lanl.gov>; from wdn@lanl.gov on Wed, Jun 06, 2001 at 11:41:29AM -0600
References: <15134.27465.936992.200470@saltydog.lanl.gov>
Message-ID: <20010606113819.A8734@codesourcery.com>

On Wed, Jun 06, 2001 at 11:41:29AM -0600, Dave Nystrom wrote:
> Hi Jeffrey,
> 
> Here is the build log from my attempt to perform the checks of my gcc build.
>
> saltydog % pwd
> /home/wdn/packages/tmp/gcc-3.0-20010527/objdir/gcc
> ...
> `if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo ${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool g77 )
> /bin/sh: runtest: command not found
> ...
> fi
> /bin/sh: runtest: command not found
> make: [check-g++] Error 127 (ignored)

runtest is part of the dejagnu tool used to perform the gcc regression
tests.  The easiest thing is to omit running the regression tests.

If you do want to run the tests and you are willing to build some more
infrastructure by installing dejagnu, follow these instructions:

1. Download the most recent copy of dejagnu.  Read
`http://www.gnu.org/software/dejagnu/dejagnu.html#TOCdownloading' how
to access the CVS tree.

2. Configure for compilation.
   cd dejagnu		# the root of the directory that was downloaded
   mkdir objdir		# always better to compile in a separate directory
   cd objdir
   declare -x CC=${HOME}/gcc-install/gcc1/bin/gcc
   declare -x CXX=${HOME}/gcc-install/gcc1/bin/g++
   declare -x LD_LIBRARY_PATH=/home/oldham/gcc-install/gcc1/lib
   ../configure linux --srcdir .. --prefix ${HOME}/bin

Change the paths to the location of your C and C++ compilers.  I
recommend using your gcc 3.0 installation.  Change the `--prefix' to
wherever you want the results to be installed.

3. Compile.

   make CC=${CC} CXX=${CXX}

(I forget how to check the code.)

4. Install.

   make install

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From oldham at codesourcery.com  Wed Jun  6 19:20:58 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Wed, 6 Jun 2001 12:20:58 -0700
Subject: [pooma-dev] gcc
In-Reply-To: <15134.25175.82568.381984@saltydog.lanl.gov>; from wdn@lanl.gov on Wed, Jun 06, 2001 at 11:03:19AM -0600
References: <15134.25175.82568.381984@saltydog.lanl.gov>
Message-ID: <20010606122058.B8734@codesourcery.com>

On Wed, Jun 06, 2001 at 11:03:19AM -0600, Dave Nystrom wrote:
> Can someone explain to me how gcc handles template instantiations.  I would
> like to try using the new gcc 3.0 snapshot to build our applications on my
> new laptop which is running RedHat 7.1.  I have several questions which I
> will need to resolve in order to build our stuff with gcc.  I assume that I
> need to invoke the gcc C++ compiler by using g++.  I am very experienced
> using KCC.  With KCC, we actually use KCC on the command line to build both
> the library and the executable.  When we build the library, we add lower
> level libraries to the end of the command line so that KCC will perform
> library closure and not have the prelinker instantiate functions or classes
> that have already been instantiated in lower level libraries that we will be
> linking against.  Does gcc have any support for this sort of thing?  With
> KCC, or any EDG based compiler, files are first compiled without
> instantiating any templates and a database is constructed which tells the
> compiler what templates can be instantiated in any given translation unit.
> Then the prelinker uses this database and it's knowledge of what templates
> need to be instantiated to assign templates to a translation unit and then
> that translation unit is recompiled.  Does gcc handle template instantiation
> differently and if so, how?  Does gcc have any support analagous to the KCC
> one instantiation per object capability?  Does gcc have support for
> precompiled headers?  Should I use ar and ld on the command lines to build
> the library and executable respectively or should I use g++?  How do I
> use/build shared libraries with gcc?  Does gcc support the -rpath option or
> something similar that allows you to build the shared library paths into the
> executable?

Use g++ to compile C++ programs.  gcc 3.0 documentation (including
g++) is available using a command like

  info -f ${HOME}/gcc-install/info/gcc.info,

where ${HOME}/gcc-install indicates the directory where gcc is
installed.  When using info(1), many of the regular emacs commands are
available.

Mark Mitchell better understands gcc's template instantiation.

Gcc does not provide support for precompiled headers.  Mark has been
looking for a sponsor to pay for adding this feature.  Contact him if
you know of an interested company.

Using g++ for archiving and linking should suffice.  I personally let
gcc or g++ figure out what linker to use.

Regarding building shared libraries, see
http://gcc.gnu.org/fom_serv/cache/40.html.  To use shared libraries,
compile by specifying the directory path using a `-L<directory>'
command-line option.  Then I set LD_LIBRARY_PATH (or
LD_LIBRARYN32_PATH on Irix6.5) to specify the location of the shared
libraries.  If this does not suffice and you want to pass `-rpath' to
the linker, pass `-Wl,-rpath' to g++.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From wdn at lanl.gov  Wed Jun  6 19:27:49 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Wed, 6 Jun 2001 13:27:49 -0600
Subject: [pooma-dev] Prelinker Bug in KCC-4.0e
In-Reply-To: <200106061833.f56IXYj29980@mailproxy1.lanl.gov>
References: <15134.28137.515127.644702@saltydog.lanl.gov>
	<200106061833.f56IXYj29980@mailproxy1.lanl.gov>
Message-ID: <15134.33845.146463.283899@saltydog.lanl.gov>

Scott Haney writes:
 > 
 > On Wednesday, June 6, 2001, at 11:52 AM, Dave Nystrom wrote:
 > 
 > > Hopefully Scott is making some progress
 > > on this.
 > 
 > Ahem, I have to admit that I haven't spent much time on this due to an 
 > internal Proximation deadline.
 > 
 > Moreover, I'm going to Disneyland  (really!) at 4pm today and will 
 > return on June 18th.

Wow.  I did not know it was possible to spend 12 days at Disneyland.  Hope
you have a nice vacation.

 > I agree that the compile times you describe are too long. When I get 
 > back, I'll look into this from the POOMA perspective. However, I've got 
 > to  think that there are physical design issues on the Blanca-side or 
 > maybe compiler issues that are playing into this.

Blanca certainly has some physical design problems but my
Pooma2Instantiations library does not depend on or know about any Blanca code
and so all the compile time problems associated with it seem to me to be
localized to either physical design problems associated with Pooma 2 or
problems with how KCC deals with template instantiation.  When I see how much
intermediate C code is being generated from my Pooma2Instantiations library,
I have to believe that most of the problem I am seeing with this particular
library is with Pooma 2's design.  It is taking about 4 hours to compile just
this library.

I am wondering if you are really the only person who can deal with this
issue.  One thing that we have just learned is that the new Blanca project
leader, Tom Gorman, has a meeting with Stephen Lee and Don McCoy of the
program office on June 18 to discuss the Blanca Project.  Tom has requested
that the four of us provide him with some input for this meeting.  As I
understand it, he would basically like us to have something he could show to
the program office by then.

I think there are two ways that the Pooma 2 team could help us regarding
compile time issues that are associated with Pooma 2.  One I would classify
as a short term item and the other as a longer term item.  The short term
item is to make it possible for us to instantiate any template that the
compiler can instantiate in some reasonable fashion.  The second and longer
term item is to evaluate the Pooma 2 logical design and see if there are
changes that can be made to factor things differently or some other design
techniques that would result in Pooma 2's template code generating less
code.  In reality, being unfamiliar with the Pooma 2 design, I don't even
know if this second item would be very successful.

I am trying everything I know to try and get a handle on this issue and get
manageable compile times in our Unix environments.  I have KAI building me a
version of KCC-4.0d for RedHat 7.1 that I can use on my laptop until they get
the prelinker bug for 4.0e fixed.  I've sent email to Arch Robison to see if
it would be possible to use gcc as the backend C compiler on bluemountain
since the SGI C compiler seems to have some problem with compiling large
files.  So far, I have resisted turning my 20 instantiation files for the
Pooma 2 assign function into 100+ files so the SGI C compiler can handle them
better but I may have to do that.  I am looking at the possiblity of using
gcc 3.0 as a development compiler in Unix environments.  If you have any
ideas of more things I could do, please let me know.  Right now, I think my
best option is to try and press on with explicitly instantiating everything
and if someone else could help out with getting Pooma 2 to support this, it
would really be great.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From scotth at proximation.com  Wed Jun  6 21:23:01 2001
From: scotth at proximation.com (Scott Haney)
Date: Wed, 6 Jun 2001 15:23:01 -0600
Subject: Vacation
Message-ID: <mailman.37.1331172044.20475.pooma-dev@codesourcery.com>

I am on vacation starting essentially now through June 18th.

Jim Crotinger is in charge at Proximation in my absence. Please contact 
him with any questions or concerns.

Scott


From scotth at proximation.com  Wed Jun  6 21:35:51 2001
From: scotth at proximation.com (Scott Haney)
Date: Wed, 6 Jun 2001 15:35:51 -0600
Subject: Compile Time Work
In-Reply-To: <15134.33845.146463.283899@saltydog.lanl.gov>
Message-ID: <mailman.38.1331172044.20475.pooma-dev@codesourcery.com>

Dave and I discussed the issues in a phone conversation and came to the 
following conclusions:

(1) the compile times currently suck
(2) this needs to be addressed at some point
(3) there is some reasonable expectation that we can significantly 
reduce the number of templates that get instantiated
(4) how much that reduces compile time is unclear
(5) given the fact that Stephen and I will be out of town, there is no 
way to do anything that will have any serious impact by June 18th
(6) working on reducing compile time sooner rather than later represents 
a change in priorities
(7) the Blanca team needs to decide if the compile time work should be 
given higher priority than other tasks
(8) Stephen and/or myself are the best people to do this compile time 
work and will redirect our efforts if Blanca wants us to

Dave tells me that the Blanca team wants to give it a few days before 
making a final decision.

My bottom line is that I want to do whatever is required to help these 
folks succeed. We just need to know what the priorities are and don't 
want to have changes in direction on too small of a time scale or else 
we can't efficiently work.

Scott


From cummings at linkline.com  Thu Jun  7 06:18:09 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Wed, 6 Jun 2001 23:18:09 -0700
Subject: [pooma-dev] gcc
In-Reply-To: <20010606122058.B8734@codesourcery.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGIEAMCCAA.cummings@linkline.com>

Dave,

My understanding is that gcc does not perform
prelinking for template closure the way the KCC
and SGI compilers do, unless things have changed
with gcc 3.0.  Also, gcc can be used to build
shared libraries by using the -shared flag, but
you should use ar to build static libraries.

Julian C.


> -----Original Message-----
> From: Jeffrey Oldham [mailto:oldham at codesourcery.com]
> Sent: Wednesday, June 06, 2001 12:21 PM
> To: Dave Nystrom
> Cc: pooma-dev; John Hall; Jean Marshall; Don Marshall
> Subject: Re: [pooma-dev] gcc
>
>
> On Wed, Jun 06, 2001 at 11:03:19AM -0600, Dave Nystrom wrote:
> > Can someone explain to me how gcc handles template
> instantiations.  I would
> > like to try using the new gcc 3.0 snapshot to build our
> applications on my
> > new laptop which is running RedHat 7.1.  I have several
> questions which I
> > will need to resolve in order to build our stuff with gcc.  I
> assume that I
> > need to invoke the gcc C++ compiler by using g++.  I am very experienced
> > using KCC.  With KCC, we actually use KCC on the command line
> to build both
> > the library and the executable.  When we build the library, we add lower
> > level libraries to the end of the command line so that KCC will perform
> > library closure and not have the prelinker instantiate
> functions or classes
> > that have already been instantiated in lower level libraries
> that we will be
> > linking against.  Does gcc have any support for this sort of
> thing?  With
> > KCC, or any EDG based compiler, files are first compiled without
> > instantiating any templates and a database is constructed which
> tells the
> > compiler what templates can be instantiated in any given
> translation unit.
> > Then the prelinker uses this database and it's knowledge of
> what templates
> > need to be instantiated to assign templates to a translation
> unit and then
> > that translation unit is recompiled.  Does gcc handle template
> instantiation
> > differently and if so, how?  Does gcc have any support
> analagous to the KCC
> > one instantiation per object capability?  Does gcc have support for
> > precompiled headers?  Should I use ar and ld on the command
> lines to build
> > the library and executable respectively or should I use g++?  How do I
> > use/build shared libraries with gcc?  Does gcc support the
> -rpath option or
> > something similar that allows you to build the shared library
> paths into the
> > executable?
>
> Use g++ to compile C++ programs.  gcc 3.0 documentation (including
> g++) is available using a command like
>
>   info -f ${HOME}/gcc-install/info/gcc.info,
>
> where ${HOME}/gcc-install indicates the directory where gcc is
> installed.  When using info(1), many of the regular emacs commands are
> available.
>
> Mark Mitchell better understands gcc's template instantiation.
>
> Gcc does not provide support for precompiled headers.  Mark has been
> looking for a sponsor to pay for adding this feature.  Contact him if
> you know of an interested company.
>
> Using g++ for archiving and linking should suffice.  I personally let
> gcc or g++ figure out what linker to use.
>
> Regarding building shared libraries, see
> http://gcc.gnu.org/fom_serv/cache/40.html.  To use shared libraries,
> compile by specifying the directory path using a `-L<directory>'
> command-line option.  Then I set LD_LIBRARY_PATH (or
> LD_LIBRARYN32_PATH on Irix6.5) to specify the location of the shared
> libraries.  If this does not suffice and you want to pass `-rpath' to
> the linker, pass `-Wl,-rpath' to g++.
>
> Thanks,
> Jeffrey D. Oldham
> oldham at codesourcery.com
>



From allan at stokes.ca  Thu Jun  7 13:31:22 2001
From: allan at stokes.ca (Allan Stokes)
Date: Thu, 7 Jun 2001 06:31:22 -0700
Subject: template idiom in the Blitz stencils; TList as a Domain simplification
Message-ID: <NABBJEAOKIDHLPHKHPDLOEELEBAA.allan@stokes.ca>


Yesterday I read through the Blitz stencil implementation.  It's relatively
uncomplicated.   The main trick is the use of #define tricks to make it
convenient to define user stencils.

This is a good example of one of the many dozens of prebuild stencils which
Blitz includes.

BZ_DECLARE_STENCIL_OPERATOR1(Laplacian3D, A)
    return -6.0 * A
      + A.shift(-1,0) + A.shift(1,0)
      + A.shift(-1,1) + A.shift(1,1)
      + A.shift(-1,2) + A.shift(1,2);
BZ_END_STENCIL_OPERATOR

Laplacian3D becomes the name of the stencil.  The array A is the single
argument.  The offsets are applied by shifting the "entire" array.  Blitz
uses a trick internally to figure out what "entire" means.

The first time a stencil is run, it is applied to a psuedo-array which does
nothing but keep track of the range of offsets supplied.  Blitz then
restricts the stencil to the largest interior sub-array such that the
supplied shifts are legal.

I'll write a short note describing the Blitz approach in more detail after
contrasting the Pooma stencils.

What caught my eye was a complaint, presumably by Todd, which is reminiscent
of some ugly template constructs in the Domain module.

/*
 * There are a lot of kludges in this code to work around the fact that
 * you can't have default template parameters with function templates.
 * Ideally, one would implement applyStencil(..) as:
 *
 * template<class T_stencil, class T_numtype1, class T_array2,
 *    class T_array3, class T_array4, class T_array5, class T_array6,
 *    class T_array7, class T_array8, class T_array9, class T_array10,
 *    class T_array11>
 * void applyStencil(const T_stencil& stencil, Array<T_numtype1,3>& A,
 *    T_array2& B = _dummyArray, T_array3& C = _dummyArray, ......)
 *
 * and allow for up to (say) 11 arrays to be passed.  But this doesn't
 * appear to be legal C++.  Instead, 11 versions of applyStencil are
 * provided, each one with a different number of array parameters,
 * and these stubs fill in the _dummyArray parameters and invoke
 * applyStencil_imp().
 */

I'm quite certain that C++ doesn't allow this.  I vaguely recall discussing
the point with John Spicer when I tried to something like this myself.

Lately there's been some discussion of possible extensions to C++ on
comp.std.c++  I often have ideas about how C++ could be fixed, but few which
are practical.  This is a case which could be handled quite easily.

template <class T, class A = Dummy, class B = Dummy>
  void applyStencil (T t, A a = Dummy(), B b = Dummy())

Presently, default types are not allowed for function templates.  Default
types could be allowed in the role of providing a default type when the
argument position is not supplied in the call.  If the type had a default in
this situation, then the default value would have somewhere to go.

This is one mechanism which might help prevent clusters of redundant
function signatures.

One of the ways in which Pooma goes against the grain is the use of domain
arguments in vararg contexts, much like Todd is doing here with stencil
arguments.  Aside from the possibility of salvaging Todd's trick, the C++
language has no reasonable mechanism for supporting vararg parameter lists.

One of the ideas I've been considering is the use of typelists to handle
this construct.  TLists are described in Andrei Alexandrescu's "Modern C++
Design", chapter 3.

A TList is a recursively defined list template.  You can think of them as a
generalization of pair<>.  Andrei's Loki library includes a full set of
compile time TList manipulations: indexing, erasing, replacing, etc.

With the use of Tlists, Todd's function might look like something like this:

template<class T_stencil, class TypeList>
 void applyStencil(const T_stencil& stencil, TypeList& L)

To call this function you need to package the varargs:

  applyStencil (stencil, make_tlist(a1, a2, a3, a4));

Loki has enough #defines on TList to support up to 50 parameters.

I remember noticing somewhere in the Domain/Layout code situations where
seven instances of a member function where defined each with a different
vararg length, and each of the functions just passed the same parameters
through to another Pooma module, which presumably also defines seven member
functions to handle all the ranks.

There might be a case for adopting a TList mechanism to handle vararg
constructs in Pooma.  The TList itself contains all the nasty code
replication.  There would no longer be a need for Pooma components to
replicate member functions on rank.

I don't know to what extend vararg constructs are currently exposed in user
level contexts, or how much of an imposition it would be to require users to
package their varargs.

A possible compromise would be to retain the functions for 1 to 3
dimensions, and only require packaging for extended ranks.  Is having three
versions any better than having seven?

I'm tossing this construct out first, because it's the least "C++ compliant"
of all the conveniences which Domain presently offers.  Allowing integers to
act as a domain type is also a hassle, but at least it's a hassle the
language endorses.

Allan




From JimC at proximation.com  Fri Jun  8 15:42:48 2001
From: JimC at proximation.com (James Crotinger)
Date: Fri, 8 Jun 2001 08:42:48 -0700 
Subject: cygwin/pthread question
Message-ID: <F871BB04B0EA224A821A5274C31DF3152C36@proxim-sf001.santafe.proximation.com>

This isn't Pooma related, but I think there are a number of cygwin users on
the list so I was hoping someone might know the answer or be able to tell me
who to ask.

The following program runs fine from a shell window, but when I try to run
it under gdb, the call to pthread_mutex_init returns EBUSY (16). The
documentation claims this means the the mutex has already been initialized,
which it obviously hasn't. Does cygwin's gdb not work with pthreads? Do I
need to do something special to use it with pthreads? Is there any way to
compile with g++ so that I could use the VC++ debugger to do source level
debugging with this code? Are there any other debugger possibilities? (Note
that this appears to work just fine under Linux.)

#include <iostream>
using std::cout;
using std::endl;

#include <pthread.h>

main()
{
  pthread_mutex_t foo;
  int result = pthread_mutex_init(&foo, 0);
  cout << "pthread_mutex_initialize returned " << result << endl;
  return 0;
}

BTW, I'm using gdb 5.0 (20010428-1) and gcc 2.95.3-4. 

Thanks,

	Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010608/4c44ea3d/attachment.html>

From cummings at linkline.com  Fri Jun  8 16:59:46 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Fri, 8 Jun 2001 09:59:46 -0700
Subject: [pooma-dev] template idiom in the Blitz stencils; TList as a Domain simplification
In-Reply-To: <NABBJEAOKIDHLPHKHPDLOEELEBAA.allan@stokes.ca>
Message-ID: <NEBBLCJDELMDOJLGLNJGAEAOCCAA.cummings@linkline.com>

Hi Allan,

I think you will find that the Blitz and Pooma stencil
mechanisms are fairly similar because we had many
discussions with Todd when these things were being
designed.  Our stencils have to deal with some extra
issues such as multipatch arrays and geometry info.

I don't think the varargs issue is such a big deal
for Domains.  The issue is with all the repetitive
constructors for Array, etc.  (Maybe this is what
you meant.)  In fact, the variable number of Domain
arguments are wrapped together by sending them off
to the magical "combine" function to make a complete
Domain of the proper dimensionality.

The repetitive constructors are annoying, but I don't
think it is good to shift this burden onto users by
forcing them to pre-package the constructor arguments.
Since the Array dimension is limited, this is not a
problem that spirals out of control.

The same problem pops up with Pooma Stencils and the
number of arrays involved in the stencil, as well as
with functions that are defined to operate on some
set of partricle attributes.  Here you do have a real
problem, because the number of Arrays involved is
potentially unlimited.  I might be missing something,
but I don't think the dummy arguments idea you mention
actually solves this problem.  You still need to know
how many of those arguments are real Arrays involved
in the stencil and how many are just dummy arguments.
Either that, or the dummy argument class has to be
sophisticated enough to have some dummy methods for
retrieving a patch, etc.  Anyway, I don't see what
the big deal is about default template arguments for
function templates.  Can't you just wrap the function
in a functor class and then use default template
arguments with the functor class template?

Julian C.


> -----Original Message-----
> From: Allan Stokes [mailto:allan at stokes.ca]
> Sent: Thursday, June 07, 2001 6:31 AM
> To: Pooma-Dev
> Subject: [pooma-dev] template idiom in the Blitz stencils; TList as a
> Domain simplification
>
>
>
> Yesterday I read through the Blitz stencil implementation.  It's
> relatively
> uncomplicated.   The main trick is the use of #define tricks to make it
> convenient to define user stencils.
>
> This is a good example of one of the many dozens of prebuild
> stencils which
> Blitz includes.
>
> BZ_DECLARE_STENCIL_OPERATOR1(Laplacian3D, A)
>     return -6.0 * A
>       + A.shift(-1,0) + A.shift(1,0)
>       + A.shift(-1,1) + A.shift(1,1)
>       + A.shift(-1,2) + A.shift(1,2);
> BZ_END_STENCIL_OPERATOR
>
> Laplacian3D becomes the name of the stencil.  The array A is the single
> argument.  The offsets are applied by shifting the "entire" array.  Blitz
> uses a trick internally to figure out what "entire" means.
>
> The first time a stencil is run, it is applied to a psuedo-array
> which does
> nothing but keep track of the range of offsets supplied.  Blitz then
> restricts the stencil to the largest interior sub-array such that the
> supplied shifts are legal.
>
> I'll write a short note describing the Blitz approach in more detail after
> contrasting the Pooma stencils.
>
> What caught my eye was a complaint, presumably by Todd, which is
> reminiscent
> of some ugly template constructs in the Domain module.
>
> /*
>  * There are a lot of kludges in this code to work around the fact that
>  * you can't have default template parameters with function templates.
>  * Ideally, one would implement applyStencil(..) as:
>  *
>  * template<class T_stencil, class T_numtype1, class T_array2,
>  *    class T_array3, class T_array4, class T_array5, class T_array6,
>  *    class T_array7, class T_array8, class T_array9, class T_array10,
>  *    class T_array11>
>  * void applyStencil(const T_stencil& stencil, Array<T_numtype1,3>& A,
>  *    T_array2& B = _dummyArray, T_array3& C = _dummyArray, ......)
>  *
>  * and allow for up to (say) 11 arrays to be passed.  But this doesn't
>  * appear to be legal C++.  Instead, 11 versions of applyStencil are
>  * provided, each one with a different number of array parameters,
>  * and these stubs fill in the _dummyArray parameters and invoke
>  * applyStencil_imp().
>  */
>
> I'm quite certain that C++ doesn't allow this.  I vaguely recall
> discussing
> the point with John Spicer when I tried to something like this myself.
>
> Lately there's been some discussion of possible extensions to C++ on
> comp.std.c++  I often have ideas about how C++ could be fixed,
> but few which
> are practical.  This is a case which could be handled quite easily.
>
> template <class T, class A = Dummy, class B = Dummy>
>   void applyStencil (T t, A a = Dummy(), B b = Dummy())
>
> Presently, default types are not allowed for function templates.  Default
> types could be allowed in the role of providing a default type when the
> argument position is not supplied in the call.  If the type had a
> default in
> this situation, then the default value would have somewhere to go.
>
> This is one mechanism which might help prevent clusters of redundant
> function signatures.
>
> One of the ways in which Pooma goes against the grain is the use of domain
> arguments in vararg contexts, much like Todd is doing here with stencil
> arguments.  Aside from the possibility of salvaging Todd's trick, the C++
> language has no reasonable mechanism for supporting vararg
> parameter lists.
>
> One of the ideas I've been considering is the use of typelists to handle
> this construct.  TLists are described in Andrei Alexandrescu's "Modern C++
> Design", chapter 3.
>
> A TList is a recursively defined list template.  You can think of
> them as a
> generalization of pair<>.  Andrei's Loki library includes a full set of
> compile time TList manipulations: indexing, erasing, replacing, etc.
>
> With the use of Tlists, Todd's function might look like something
> like this:
>
> template<class T_stencil, class TypeList>
>  void applyStencil(const T_stencil& stencil, TypeList& L)
>
> To call this function you need to package the varargs:
>
>   applyStencil (stencil, make_tlist(a1, a2, a3, a4));
>
> Loki has enough #defines on TList to support up to 50 parameters.
>
> I remember noticing somewhere in the Domain/Layout code situations where
> seven instances of a member function where defined each with a different
> vararg length, and each of the functions just passed the same parameters
> through to another Pooma module, which presumably also defines
> seven member
> functions to handle all the ranks.
>
> There might be a case for adopting a TList mechanism to handle vararg
> constructs in Pooma.  The TList itself contains all the nasty code
> replication.  There would no longer be a need for Pooma components to
> replicate member functions on rank.
>
> I don't know to what extend vararg constructs are currently
> exposed in user
> level contexts, or how much of an imposition it would be to
> require users to
> package their varargs.
>
> A possible compromise would be to retain the functions for 1 to 3
> dimensions, and only require packaging for extended ranks.  Is
> having three
> versions any better than having seven?
>
> I'm tossing this construct out first, because it's the least "C++
> compliant"
> of all the conveniences which Domain presently offers.  Allowing
> integers to
> act as a domain type is also a hassle, but at least it's a hassle the
> language endorses.
>
> Allan
>
>
>



From wdn at lanl.gov  Fri Jun  8 17:32:19 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Fri, 8 Jun 2001 11:32:19 -0600
Subject: (2/2)
Message-ID: <200106081732.f58HWMg05460@saltydog.lanl.gov>

bm9yTG9jKSAgICAgIC09IGFkdmVjdGVkTWFzczsNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIF4NCiAgICAgICAgICBkZXRlY3RlZCBkdXJpbmcg
aW5zdGFudGlhdGlvbiBvZiAidm9pZA0KICAgICAgICAgICAgICAgICAgICBQaHlzaWNzQmV0
YTo6SU1BZHZlY3Rpb248VHJhaXRzPjo6dmFyaWFibGVBZHZlY3Rpb24ocG9vbWFsbw0KICAg
ICAgICAgICAgICAgICAgICB0ZTo6UmVhbCAmKSBbd2l0aA0KICAgICAgICAgICAgICAgICAg
ICBUcmFpdHM9cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bHRUcmFpdHM+XSIg
DQoNCiIvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNp
Y3NMYXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0lN
QWR2ZWN0aW9uL0lNQWR2ZWN0aW9uLnQuaGgiLCBsaW5lIDg5NjogZXJyb3IgIzM0OTogDQog
ICAgICAgICAgbm8gb3BlcmF0b3IgIis9IiBtYXRjaGVzIHRoZXNlIG9wZXJhbmRzDQogICAg
ICAgICAgICBvcGVyYW5kIHR5cGVzIGFyZToNCiAgICAgICAgICAgICAgICAgICAgICBBbHRW
aWV3MTxGaWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG8N
CiAgICAgICAgICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZhdWx0VHJhaXRzPj46Ok1lc2hU
YWcsIHBvb21hbG90ZTo6UmVhbCwNCiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxvdGU6
Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG9vbWFsb3RlOjpEZWZhdWwNCiAgICAg
ICAgICAgICAgICAgICAgICB0VHJhaXRzPj46OkVuZ2luZVRhZz4sIExvYzwxPj46OlR5cGVf
dCArPSBwb29tYWxvdGU6OlJlYWwNCiAgICAgICAgICAgICAgICAgICAgICBNTV9NYXNzW21d
KGFjY2VwdG9yTG9jKSAgICs9IGFkdmVjdGVkTWFzczsNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4NCiAgICAgICAgICBkZXRlY3RlZCBkdXJp
bmcgaW5zdGFudGlhdGlvbiBvZiAidm9pZA0KICAgICAgICAgICAgICAgICAgICBQaHlzaWNz
QmV0YTo6SU1BZHZlY3Rpb248VHJhaXRzPjo6dmFyaWFibGVBZHZlY3Rpb24ocG9vbWFsbw0K
ICAgICAgICAgICAgICAgICAgICB0ZTo6UmVhbCAmKSBbd2l0aA0KICAgICAgICAgICAgICAg
ICAgICBUcmFpdHM9cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bHRUcmFpdHM+
XSIgDQoNCiIvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1Bo
eXNpY3NMYXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2Rz
L0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9uLnQuaGgiLCBsaW5lIDg5OTogZXJyb3IgIzM0OTog
DQogICAgICAgICAgbm8gb3BlcmF0b3IgIi09IiBtYXRjaGVzIHRoZXNlIG9wZXJhbmRzDQog
ICAgICAgICAgICBvcGVyYW5kIHR5cGVzIGFyZToNCiAgICAgICAgICAgICAgICAgICAgICBB
bHRWaWV3MTxGaWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8
cG8NCiAgICAgICAgICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZhdWx0VHJhaXRzPj46Ok1l
c2hUYWcsIHBvb21hbG90ZTo6UmVhbCwNCiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxv
dGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG9vbWFsb3RlOjpEZWZhdWwNCiAg
ICAgICAgICAgICAgICAgICAgICB0VHJhaXRzPj46OkVuZ2luZVRhZz4sIExvYzwxPj46OlR5
cGVfdCAtPSBwb29tYWxvdGU6OlJlYWwNCiAgICAgICAgICAgICAgICAgICAgICBNTV9Wb2xG
cmFjW21dKGRvbm9yTG9jKSAgICAtPSBhZHZlY3RlZFZvbHVtZTsNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeDQogICAgICAgICAgZGV0ZWN0
ZWQgZHVyaW5nIGluc3RhbnRpYXRpb24gb2YgInZvaWQNCiAgICAgICAgICAgICAgICAgICAg
UGh5c2ljc0JldGE6OklNQWR2ZWN0aW9uPFRyYWl0cz46OnZhcmlhYmxlQWR2ZWN0aW9uKHBv
b21hbG8NCiAgICAgICAgICAgICAgICAgICAgdGU6OlJlYWwgJikgW3dpdGgNCiAgICAgICAg
ICAgICAgICAgICAgVHJhaXRzPXBvb21hbG90ZTo6T25lREY8cG9vbWFsb3RlOjpEZWZhdWx0
VHJhaXRzPl0iIA0KDQoiL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3Jj
XzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL0ludGVncmFs
TWV0aG9kcy9JTUFkdmVjdGlvbi9JTUFkdmVjdGlvbi50LmhoIiwgbGluZSA5MDA6IGVycm9y
ICMzNDk6IA0KICAgICAgICAgIG5vIG9wZXJhdG9yICIrPSIgbWF0Y2hlcyB0aGVzZSBvcGVy
YW5kcw0KICAgICAgICAgICAgb3BlcmFuZCB0eXBlcyBhcmU6DQogICAgICAgICAgICAgICAg
ICAgICAgQWx0VmlldzE8RmllbGQ8cG9vbWFsb3RlOjpNb2RlbFRyYWl0czxwb29tYWxvdGU6
Ok9uZURGPHBvDQogICAgICAgICAgICAgICAgICAgICAgb21hbG90ZTo6RGVmYXVsdFRyYWl0
cz4+OjpNZXNoVGFnLCBwb29tYWxvdGU6OlJlYWwsDQogICAgICAgICAgICAgICAgICAgICAg
cG9vbWFsb3RlOjpNb2RlbFRyYWl0czxwb29tYWxvdGU6Ok9uZURGPHBvb21hbG90ZTo6RGVm
YXVsDQogICAgICAgICAgICAgICAgICAgICAgdFRyYWl0cz4+OjpFbmdpbmVUYWc+LCBMb2M8
MT4+OjpUeXBlX3QgKz0gcG9vbWFsb3RlOjpSZWFsDQogICAgICAgICAgICAgICAgICAgICAg
TU1fVm9sRnJhY1ttXShhY2NlcHRvckxvYykgKz0gYWR2ZWN0ZWRWb2x1bWU7DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXg0KICAgICAgICAg
IGRldGVjdGVkIGR1cmluZyBpbnN0YW50aWF0aW9uIG9mICJ2b2lkDQogICAgICAgICAgICAg
ICAgICAgIFBoeXNpY3NCZXRhOjpJTUFkdmVjdGlvbjxUcmFpdHM+Ojp2YXJpYWJsZUFkdmVj
dGlvbihwb29tYWxvDQogICAgICAgICAgICAgICAgICAgIHRlOjpSZWFsICYpIFt3aXRoDQog
ICAgICAgICAgICAgICAgICAgIFRyYWl0cz1wb29tYWxvdGU6Ok9uZURGPHBvb21hbG90ZTo6
RGVmYXVsdFRyYWl0cz5dIiANCg0KIi91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxh
bmNhX3NyY180LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhL1BoeXNpY3NCZXRhX3NyYy9J
bnRlZ3JhbE1ldGhvZHMvSU1BZHZlY3Rpb24vSU1BZHZlY3Rpb24udC5oaCIsIGxpbmUgMTAz
OTogZXJyb3IgIzM0OTogDQogICAgICAgICAgbm8gb3BlcmF0b3IgIi09IiBtYXRjaGVzIHRo
ZXNlIG9wZXJhbmRzDQogICAgICAgICAgICBvcGVyYW5kIHR5cGVzIGFyZToNCiAgICAgICAg
ICAgICAgICAgICAgICBBbHRWaWV3MTxGaWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBv
b21hbG90ZTo6T25lREY8cG8NCiAgICAgICAgICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZh
dWx0VHJhaXRzPj46Ok1lc2hUYWcsIHBvb21hbG90ZTo6UmVhbCwNCiAgICAgICAgICAgICAg
ICAgICAgICBwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG9vbWFs
b3RlOjpEZWZhdWwNCiAgICAgICAgICAgICAgICAgICAgICB0VHJhaXRzPj46OkVuZ2luZVRh
Zz4sIExvYzwxPj46OlR5cGVfdCAtPSBwb29tYWxvdGU6OlJlYWwNCiAgICAgICAgICAgICAg
QWR2ZWN0RmllbGRbbV0oZG9ub3JMb2MpICAgIC09IGFkdmVjdGVkUXVhbnRpdHk7DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeDQogICAgICAgICAgZGV0
ZWN0ZWQgZHVyaW5nIGluc3RhbnRpYXRpb24gb2YgInZvaWQNCiAgICAgICAgICAgICAgICAg
ICAgUGh5c2ljc0JldGE6OklNQWR2ZWN0aW9uPFRyYWl0cz46OmFkdmVjdFZhcmlhYmxlU2V0
KGNvbnN0DQogICAgICAgICAgICAgICAgICAgIHN0ZDo6c2V0PHN0ZDo6c3RyaW5nLCBzdGQ6
Omxlc3M8c3RkOjpzdHJpbmc+LA0KICAgICAgICAgICAgICAgICAgICBzdGQ6OmFsbG9jYXRv
cjxzdGQ6OnN0cmluZz4+ICYsIGNvbnN0DQogICAgICAgICAgICAgICAgICAgIFBoeXNpY3NC
ZXRhOjpJTUFkdmVjdGlvbjxUcmFpdHM+OjpTY2FsYXJGaWVsZCAmLCBjb25zdCBpbnQNCiAg
ICAgICAgICAgICAgICAgICAgJikgW3dpdGgNCiAgICAgICAgICAgICAgICAgICAgVHJhaXRz
PXBvb21hbG90ZTo6T25lREY8cG9vbWFsb3RlOjpEZWZhdWx0VHJhaXRzPl0iIA0KDQoiL3Vz
ci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIv
UGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9JTUFkdmVjdGlv
bi9JTUFkdmVjdGlvbi50LmhoIiwgbGluZSAxMDQwOiBlcnJvciAjMzQ5OiANCiAgICAgICAg
ICBubyBvcGVyYXRvciAiKz0iIG1hdGNoZXMgdGhlc2Ugb3BlcmFuZHMNCiAgICAgICAgICAg
IG9wZXJhbmQgdHlwZXMgYXJlOg0KICAgICAgICAgICAgICAgICAgICAgIEFsdFZpZXcxPEZp
ZWxkPHBvb21hbG90ZTo6TW9kZWxUcmFpdHM8cG9vbWFsb3RlOjpPbmVERjxwbw0KICAgICAg
ICAgICAgICAgICAgICAgIG9tYWxvdGU6OkRlZmF1bHRUcmFpdHM+Pjo6TWVzaFRhZywgcG9v
bWFsb3RlOjpSZWFsLA0KICAgICAgICAgICAgICAgICAgICAgIHBvb21hbG90ZTo6TW9kZWxU
cmFpdHM8cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bA0KICAgICAgICAgICAg
ICAgICAgICAgIHRUcmFpdHM+Pjo6RW5naW5lVGFnPiwgTG9jPDE+Pjo6VHlwZV90ICs9IHBv
b21hbG90ZTo6UmVhbA0KICAgICAgICAgICAgICBBZHZlY3RGaWVsZFttXShhY2NlcHRvckxv
YykgKz0gYWR2ZWN0ZWRRdWFudGl0eTsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIF4NCiAgICAgICAgICBkZXRlY3RlZCBkdXJpbmcgaW5zdGFudGlhdGlv
biBvZiAidm9pZA0KICAgICAgICAgICAgICAgICAgICBQaHlzaWNzQmV0YTo6SU1BZHZlY3Rp
b248VHJhaXRzPjo6YWR2ZWN0VmFyaWFibGVTZXQoY29uc3QNCiAgICAgICAgICAgICAgICAg
ICAgc3RkOjpzZXQ8c3RkOjpzdHJpbmcsIHN0ZDo6bGVzczxzdGQ6OnN0cmluZz4sDQogICAg
ICAgICAgICAgICAgICAgIHN0ZDo6YWxsb2NhdG9yPHN0ZDo6c3RyaW5nPj4gJiwgY29uc3QN
CiAgICAgICAgICAgICAgICAgICAgUGh5c2ljc0JldGE6OklNQWR2ZWN0aW9uPFRyYWl0cz46
OlNjYWxhckZpZWxkICYsIGNvbnN0IGludA0KICAgICAgICAgICAgICAgICAgICAmKSBbd2l0
aA0KICAgICAgICAgICAgICAgICAgICBUcmFpdHM9cG9vbWFsb3RlOjpPbmVERjxwb29tYWxv
dGU6OkRlZmF1bHRUcmFpdHM+XSIgDQoNCjEzIGVycm9ycyBkZXRlY3RlZCBpbiB0aGUgY29t
cGlsYXRpb24gb2YgIi91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180
LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1l
dGhvZHMvSU1BZHZlY3Rpb24vSU1BZHZlY3Rpb24xRC5jYyIuDQpLQ0M6IENvbXBpbGF0aW9u
IGZhaWxlZC4NCkNvbW1hbmQgZXhpdGVkIHdpdGggbm9uLXplcm8gc3RhdHVzIDINCnJlYWwg
MTQuNTkNCnVzZXIgMTIuMDMNCnN5cyAxLjAyDQoNCkVycm9yIGNvbXBpbGluZyAvc2NyYXRj
aC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNp
Y3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvSU1BZHZlY3Rpb24vSU1BZHZlY3Rpb24xRC5v
DQptYWtlOiAqKiogWy9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tD
Q19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9JTUFkdmVj
dGlvbi9JTUFkdmVjdGlvbjFELm9dIEVycm9yIDkNCkNvbW1hbmQgZXhpdGVkIHdpdGggbm9u
LXplcm8gc3RhdHVzIDINCnJlYWwgMzU3LjI0DQp1c2VyIDI5OS4yOA0Kc3lzIDI4LjkzDQoN
CkNvbXBpbGF0aW9uIGV4aXRlZCBhYm5vcm1hbGx5IHdpdGggY29kZSAyIGF0IEZyaSBKdW4g
IDggMTE6MDk6NDk=



From wdn at lanl.gov  Fri Jun  8 17:32:19 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Fri, 8 Jun 2001 11:32:19 -0600
Subject: (1/2)
Message-ID: <200106081732.f58HWMM05459@saltydog.lanl.gov>

SGkgSmVmZnJleSBhbmQgU3RlcGhlbiwNCg0KSSd2ZSBydW4gaW50byBzb21lIHByb2JsZW1z
IHRyeWluZyB0byBidWlsZCBhbiBtcGkvQ2hlZXRhaCB2ZXJzaW9uIG9mIG91cg0KYXBwbGlj
YXRpb24uICBCZWxvdyBpcyBhIGJ1aWxkIGxvZyBvZiBteSBjb21waWxlIGVycm9ycy4gIENv
dWxkIHlvdSBndXlzIHRha2UNCmEgbG9vayBhdCB0aGlzIGFuZCBzZWUgaWYgaXQgaXMgYSBQ
b29tYSBwcm9ibGVtIGFuZCBpZiBzbywgd2hhdCB3b3VsZCBiZQ0KaW52b2x2ZWQgdG8gZ2V0
IGEgZml4Pw0KDQpUaGFua3MsDQoNCkRhdmUgTnlzdHJvbQkJCWVtYWlsOiB3ZG5AbGFubC5n
b3YNCkxBTkwgWC0zCQkJcGhvbmU6IDUwNS02NjctNzkxMwlmYXg6IDUwNS02NjUtMzA0Ng0K
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1idWlsZC1sb2ctLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmNk
IC91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvQXBwbGljYXRp
b25zTGF5ZXIvRGVtby8NCmRhdGU7IC91c3IvYmluL3RpbWUgLXAgbWFrZSBSRUNVUlNFPTEg
UEFTUz1NUEkxIGFwcA0KRnJpIEp1biAgOCAxMTowMzo1MiBNRFQgMjAwMQ0KQ09QWUlORy4u
LiAvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsvVGVjRnJhbWV3
b3JrX3NyYy9NYWluL21haW4uY2MgdG8gL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5V
WF9LQ0NfQ0FSVF9YWVpfTVBJL21haW4uY2MNCg0KQ09NUElMSU5HLi4uIFNlZSAvc2NyYXRj
aC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMvaW5j
bHVkZS9EZW1vUENILm9fTVBJMS5pbmZvDQoNCktDQyAtYyAvdXNyL3Byb2plY3RzL2JsYW5j
YS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL0FwcGxpY2F0aW9uc0xheWVyL0RlbW8vRGVtb19z
cmMvaW5jbHVkZS9EZW1vUENILmNjIC1vIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElO
VVhfS0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9pbmNsdWRlL0RlbW9QQ0gubyAtLW91dHB1
dF9kZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FS
VF9YWVpfTVBJL0RlbW9fc3JjL2luY2x1ZGUvRGVtb1BDSC5vLmRlcGVuZC5tay50ZW1wIC0t
ZGlhZ19zdXBwcmVzcyA2MzAgLS1jcmVhdGVfcGNoIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RF
TU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9ERU1PX01QSTEucGNoIC1EVEVDX1VTRV9ERU1P
IC1EVEVDX1VTRV9QSFlTSUNTQkVUQSAtRFRFQ19VU0VfSFlEUk9EWU5BTUlDUyAtRFRFQ19V
U0VfUEhZU0lDU1NVUFBPUlRCRVRBIC1EVEVDX1VTRV9QSFlTSUNTQkFTRUNMQVNTRVMgLURU
RUNfVVNFX1BPT01BMklOVEVHUkFUSU9OIC1EVEVDX1VTRV9URUNGUkFNRVdPUksgLURURUNf
VVNFX1BPT01BIC1EVEVDX1VTRV9DSEVFVEFIIC1EVEVDX1VTRV9NTSAtRFRFQ19VU0VfUENH
IC1EVEVDX0xJTlVYIC1EVEVDX0lOU1QgLURURUNfVVNFX1BDSCAtSS91c3IvcHJvamVjdHMv
YmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvQXBwbGljYXRpb25zTGF5ZXIvRGVtbyAt
SS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xh
eWVyL1BoeXNpY3NCZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9QaHlzaWNzTGF5ZXIvSHlkcm9keW5hbWljcyAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNz
U3VwcG9ydEJldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNf
NC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc0Jhc2VDbGFzc2VzIC1JL3Vzci9wcm9q
ZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9UZWNJbnRlZ3JhdGlvbkxheWVy
L1Bvb21hMkludGVncmF0aW9uIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvVGVj
RnJhbWV3b3JrIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL3Ny
YyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9saWIvTElOVVhf
S0NDX0RFQlVHX0NIRUVUQUggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVl
dGFoL2NoZWV0YWgtMS4wLjAvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMv
Q2hlZXRhaC9jaGVldGFoLTEuMC4wL2xpYi9MSU5VWF9LQ0NfREVCVUcgLUkvaG9tZS93ZG4v
cGFja2FnZXMvbXBpY2gtMS4yLjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Bh
Y2thZ2VzL21tLTEuMS4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdl
cy9wY2cvcGNnX2Y3NyAtLWRpc3BsYXlfZXJyb3JfbnVtYmVyIC1mcGljIC1rIC0tc3RyaWN0
IC1EX19LQUlfU1RSSUNUIC0tZGlhZ19zdXBwcmVzcyA0NTAgK0swDQoNCiIvdXNyL3Byb2pl
Y3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL0FwcGxpY2F0aW9uc0xheWVyL0Rl
bW8vRGVtb19zcmMvaW5jbHVkZS9EZW1vUENILmNjIjogY3JlYXRpbmcgcHJlY29tcGlsZWQg
aGVhZGVyIGZpbGUgIi9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRf
WFlaX01QSS9ERU1PX01QSTEucGNoIg0KcmVhbCAxNC41Ng0KdXNlciA2LjcxDQpzeXMgMS4x
Mg0KDQpEb25lIGNvbXBpbGluZyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tD
Q19DQVJUX1hZWl9NUEkvRGVtb19zcmMvaW5jbHVkZS9EZW1vUENILm8NCg0KQ09NUElMSU5H
Li4uIFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9N
UEkvbWFpbi5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3NjcmF0Y2gvd2RuL29ial80LjAvREVN
Ty9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL21haW4uY2MgLW8gL3NjcmF0Y2gvd2RuL29ial80
LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL21haW4ubyAtLW91dHB1dF9kZXBlbmRl
bmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJ
L21haW4uby5kZXBlbmQubWsudGVtcCAtLWRpYWdfc3VwcHJlc3MgNjMwIC0tQ09NUERPX2Zl
X2NjMmMgLS1wY2hfaWdub3JlX2RpciAtLXVzZV9wY2ggL3NjcmF0Y2gvd2RuL29ial80LjAv
REVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RFTU9fTVBJMS5wY2ggLURURUNfVVNFX0RF
TU8gLURURUNfVVNFX1BIWVNJQ1NCRVRBIC1EVEVDX1VTRV9IWURST0RZTkFNSUNTIC1EVEVD
X1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEgLURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xBU1NFUyAt
RFRFQ19VU0VfUE9PTUEySU5URUdSQVRJT04gLURURUNfVVNFX1RFQ0ZSQU1FV09SSyAtRFRF
Q19VU0VfUE9PTUEgLURURUNfVVNFX0NIRUVUQUggLURURUNfVVNFX01NIC1EVEVDX1VTRV9Q
Q0cgLURURUNfTElOVVggLURURUNfSU5TVCAtRFRFQ19VU0VfUENIIC1JL3Vzci9wcm9qZWN0
cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9BcHBsaWNhdGlvbnNMYXllci9EZW1v
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNz
TGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5j
YV9zcmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5bmFtaWNzIC1JL3Vzci9wcm9qZWN0cy9i
bGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNp
Y3NTdXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3Ny
Y180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzQmFzZUNsYXNzZXMgLUkvdXNyL3By
b2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1RlY0ludGVncmF0aW9uTGF5
ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9U
ZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIv
c3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL2xpYi9MSU5V
WF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0No
ZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdl
cy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJTlVYX0tDQ19ERUJVRyAtSS9ob21lL3dk
bi9wYWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2Ev
cGFja2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2th
Z2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJvcl9udW1iZXIgLWZwaWMgLWsgLS1zdHJp
Y3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHByZXNzIDQ1MCArSzANCg0KcmVhbCAxLjUy
DQp1c2VyIDAuOTINCnN5cyAwLjE3DQoNCkRvbmUgY29tcGlsaW5nIC9zY3JhdGNoL3dkbi9v
YmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9tYWluLm8NCg0KQ09NUElMSU5H
Li4uIFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9N
UEkvRGVtb19zcmMvRGVtb0FwcEdyb3VwLm9fTVBJMS5pbmZvDQoNCktDQyAtYyAvdXNyL3By
b2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL0FwcGxpY2F0aW9uc0xheWVy
L0RlbW8vRGVtb19zcmMvRGVtb0FwcEdyb3VwLmNjIC1vIC9zY3JhdGNoL3dkbi9vYmpfNC4w
L0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9EZW1vQXBwR3JvdXAubyAt
LW91dHB1dF9kZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9L
Q0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3JjL0RlbW9BcHBHcm91cC5vLmRlcGVuZC5tay50ZW1w
IC0tZGlhZ19zdXBwcmVzcyA2MzAgLS1DT01QRE9fZmVfY2MyYyAtLXBjaF9pZ25vcmVfZGly
IC0tdXNlX3BjaCAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZ
Wl9NUEkvREVNT19NUEkxLnBjaCAtRFRFQ19VU0VfREVNTyAtRFRFQ19VU0VfUEhZU0lDU0JF
VEEgLURURUNfVVNFX0hZRFJPRFlOQU1JQ1MgLURURUNfVVNFX1BIWVNJQ1NTVVBQT1JUQkVU
QSAtRFRFQ19VU0VfUEhZU0lDU0JBU0VDTEFTU0VTIC1EVEVDX1VTRV9QT09NQTJJTlRFR1JB
VElPTiAtRFRFQ19VU0VfVEVDRlJBTUVXT1JLIC1EVEVDX1VTRV9QT09NQSAtRFRFQ19VU0Vf
Q0hFRVRBSCAtRFRFQ19VU0VfTU0gLURURUNfVVNFX1BDRyAtRFRFQ19MSU5VWCAtRFRFQ19J
TlNUIC1EVEVDX1VTRV9QQ0ggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5j
YV9zcmNfNC4wL0FwcGxpY2F0aW9uc0xheWVyL0RlbW8gLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YSAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVy
L0h5ZHJvZHluYW1pY3MgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9z
cmNfNC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc1N1cHBvcnRCZXRhIC1JL3Vzci9w
cm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExh
eWVyL1BoeXNpY3NCYXNlQ2xhc3NlcyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4v
YmxhbmNhX3NyY180LjAvVGVjSW50ZWdyYXRpb25MYXllci9Qb29tYTJJbnRlZ3JhdGlvbiAt
SS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1RlY0ZyYW1ld29yayAtSS91c3IvcHJv
amVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9zcmMgLUkvdXNyL3Byb2plY3RzL2Js
YW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvbGliL0xJTlVYX0tDQ19ERUJVR19DSEVFVEFIIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFoLTEuMC4wL3Ny
YyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAu
MC9saWIvTElOVVhfS0NDX0RFQlVHIC1JL2hvbWUvd2RuL3BhY2thZ2VzL21waWNoLTEuMi4x
L2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9tbS0xLjEuMS9pbmNs
dWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvcGNnL3BjZ19mNzcgLS1kaXNw
bGF5X2Vycm9yX251bWJlciAtZnBpYyAtayAtLXN0cmljdCAtRF9fS0FJX1NUUklDVCAtLWRp
YWdfc3VwcHJlc3MgNDUwICtLMA0KDQpyZWFsIDAuNzENCnVzZXIgMC4yNA0Kc3lzIDAuMDQN
Cg0KRG9uZSBjb21waWxpbmcgL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0Nf
Q0FSVF9YWVpfTVBJL0RlbW9fc3JjL0RlbW9BcHBHcm91cC5vDQoNCkNPTVBJTElORy4uLiBT
ZWUgL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0Rl
bW9fc3JjL0RlbW9Hcm91cC5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9i
bGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9BcHBsaWNhdGlvbnNMYXllci9EZW1vL0Rl
bW9fc3JjL0RlbW9Hcm91cC5jYyAtbyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVY
X0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMvRGVtb0dyb3VwLm8gLS1vdXRwdXRfZGVwZW5k
ZW5jaWVzIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01Q
SS9EZW1vX3NyYy9EZW1vR3JvdXAuby5kZXBlbmQubWsudGVtcCAtLWRpYWdfc3VwcHJlc3Mg
NjMwIC0tQ09NUERPX2ZlX2NjMmMgLS1wY2hfaWdub3JlX2RpciAtLXVzZV9wY2ggL3NjcmF0
Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RFTU9fTVBJMS5w
Y2ggLURURUNfVVNFX0RFTU8gLURURUNfVVNFX1BIWVNJQ1NCRVRBIC1EVEVDX1VTRV9IWURS
T0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEgLURURUNfVVNFX1BIWVNJ
Q1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0VfUE9PTUEySU5URUdSQVRJT04gLURURUNfVVNFX1RF
Q0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9PTUEgLURURUNfVVNFX0NIRUVUQUggLURURUNfVVNF
X01NIC1EVEVDX1VTRV9QQ0cgLURURUNfTElOVVggLURURUNfSU5TVCAtRFRFQ19VU0VfUENI
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9BcHBsaWNh
dGlvbnNMYXllci9EZW1vIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5bmFtaWNzIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3Vw
cG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vz
ci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzQmFzZUNs
YXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1Rl
Y0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3Byb2plY3RzL2Js
YW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNr
YWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9v
bWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNyL3Byb2plY3Rz
L2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJTlVYX0tDQ19E
RUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRlIC1JL3Vzci9w
cm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91c3IvcHJvamVj
dHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJvcl9udW1iZXIg
LWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHByZXNzIDQ1MCAr
SzANCg0KcmVhbCAwLjcxDQp1c2VyIDAuMjQNCnN5cyAwLjAyDQoNCkRvbmUgY29tcGlsaW5n
IC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9EZW1v
X3NyYy9EZW1vR3JvdXAubw0KDQpDT01QSUxJTkcuLi4gU2VlIC9zY3JhdGNoL3dkbi9vYmpf
NC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9Nb2RlbC9BZGRNb2Rl
bFR1dG9yaWFsL1NpbXBsZU1vZGVsLm9fTVBJMS5pbmZvDQoNCktDQyAtYyAvdXNyL3Byb2pl
Y3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL0FwcGxpY2F0aW9uc0xheWVyL0Rl
bW8vRGVtb19zcmMvTW9kZWwvQWRkTW9kZWxUdXRvcmlhbC9TaW1wbGVNb2RlbC5jYyAtbyAv
c2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvRGVtb19z
cmMvTW9kZWwvQWRkTW9kZWxUdXRvcmlhbC9TaW1wbGVNb2RlbC5vIC0tb3V0cHV0X2RlcGVu
ZGVuY2llcyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9N
UEkvRGVtb19zcmMvTW9kZWwvQWRkTW9kZWxUdXRvcmlhbC9TaW1wbGVNb2RlbC5vLmRlcGVu
ZC5tay50ZW1wIC0tZGlhZ19zdXBwcmVzcyA2MzAgLS1DT01QRE9fZmVfY2MyYyAtLXBjaF9p
Z25vcmVfZGlyIC0tdXNlX3BjaCAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tD
Q19DQVJUX1hZWl9NUEkvREVNT19NUEkxLnBjaCAtRFRFQ19VU0VfREVNTyAtRFRFQ19VU0Vf
UEhZU0lDU0JFVEEgLURURUNfVVNFX0hZRFJPRFlOQU1JQ1MgLURURUNfVVNFX1BIWVNJQ1NT
VVBQT1JUQkVUQSAtRFRFQ19VU0VfUEhZU0lDU0JBU0VDTEFTU0VTIC1EVEVDX1VTRV9QT09N
QTJJTlRFR1JBVElPTiAtRFRFQ19VU0VfVEVDRlJBTUVXT1JLIC1EVEVDX1VTRV9QT09NQSAt
RFRFQ19VU0VfQ0hFRVRBSCAtRFRFQ19VU0VfTU0gLURURUNfVVNFX1BDRyAtRFRFQ19MSU5V
WCAtRFRFQ19JTlNUIC1EVEVDX1VTRV9QQ0ggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Iv
d2RuL2JsYW5jYV9zcmNfNC4wL0FwcGxpY2F0aW9uc0xheWVyL0RlbW8gLUkvdXNyL3Byb2pl
Y3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNz
QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5
c2ljc0xheWVyL0h5ZHJvZHluYW1pY3MgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2Ru
L2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc1N1cHBvcnRCZXRh
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNz
U3VwcG9ydExheWVyL1BoeXNpY3NCYXNlQ2xhc3NlcyAtSS91c3IvcHJvamVjdHMvYmxhbmNh
L3Vzci93ZG4vYmxhbmNhX3NyY180LjAvVGVjSW50ZWdyYXRpb25MYXllci9Qb29tYTJJbnRl
Z3JhdGlvbiAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1RlY0ZyYW1ld29yayAt
SS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9zcmMgLUkvdXNyL3By
b2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvbGliL0xJTlVYX0tDQ19ERUJVR19D
SEVFVEFIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFo
LTEuMC4wL3NyYyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hl
ZXRhaC0xLjAuMC9saWIvTElOVVhfS0NDX0RFQlVHIC1JL2hvbWUvd2RuL3BhY2thZ2VzL21w
aWNoLTEuMi4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9tbS0x
LjEuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvcGNnL3BjZ19m
NzcgLS1kaXNwbGF5X2Vycm9yX251bWJlciAtZnBpYyAtayAtLXN0cmljdCAtRF9fS0FJX1NU
UklDVCAtLWRpYWdfc3VwcHJlc3MgNDUwICtLMA0KDQpyZWFsIDExLjk5DQp1c2VyIDEwLjA2
DQpzeXMgMS4wNQ0KDQpEb25lIGNvbXBpbGluZyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1P
L0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMvTW9kZWwvQWRkTW9kZWxUdXRvcmlh
bC9TaW1wbGVNb2RlbC5vDQoNCkNPTVBJTElORy4uLiBTZWUgL3NjcmF0Y2gvd2RuL29ial80
LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3JjL01vZGVsL0J1cmdlci9C
dXJnZXIub19NUEkxLmluZm8NCg0KS0NDIC1jIC91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93
ZG4vYmxhbmNhX3NyY180LjAvQXBwbGljYXRpb25zTGF5ZXIvRGVtby9EZW1vX3NyYy9Nb2Rl
bC9CdXJnZXIvQnVyZ2VyLmNjIC1vIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhf
S0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9Nb2RlbC9CdXJnZXIvQnVyZ2VyLm8gLS1vdXRw
dXRfZGVwZW5kZW5jaWVzIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NB
UlRfWFlaX01QSS9EZW1vX3NyYy9Nb2RlbC9CdXJnZXIvQnVyZ2VyLm8uZGVwZW5kLm1rLnRl
bXAgLS1kaWFnX3N1cHByZXNzIDYzMCAtLUNPTVBET19mZV9jYzJjIC0tcGNoX2lnbm9yZV9k
aXIgLS11c2VfcGNoIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRf
WFlaX01QSS9ERU1PX01QSTEucGNoIC1EVEVDX1VTRV9ERU1PIC1EVEVDX1VTRV9QSFlTSUNT
QkVUQSAtRFRFQ19VU0VfSFlEUk9EWU5BTUlDUyAtRFRFQ19VU0VfUEhZU0lDU1NVUFBPUlRC
RVRBIC1EVEVDX1VTRV9QSFlTSUNTQkFTRUNMQVNTRVMgLURURUNfVVNFX1BPT01BMklOVEVH
UkFUSU9OIC1EVEVDX1VTRV9URUNGUkFNRVdPUksgLURURUNfVVNFX1BPT01BIC1EVEVDX1VT
RV9DSEVFVEFIIC1EVEVDX1VTRV9NTSAtRFRFQ19VU0VfUENHIC1EVEVDX0xJTlVYIC1EVEVD
X0lOU1QgLURURUNfVVNFX1BDSCAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxh
bmNhX3NyY180LjAvQXBwbGljYXRpb25zTGF5ZXIvRGVtbyAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5
ZXIvSHlkcm9keW5hbWljcyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNh
X3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzU3VwcG9ydEJldGEgLUkvdXNy
L3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0
TGF5ZXIvUGh5c2ljc0Jhc2VDbGFzc2VzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dk
bi9ibGFuY2Ffc3JjXzQuMC9UZWNJbnRlZ3JhdGlvbkxheWVyL1Bvb21hMkludGVncmF0aW9u
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvVGVjRnJhbWV3b3JrIC1JL3Vzci9w
cm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL3NyYyAtSS91c3IvcHJvamVjdHMv
YmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9saWIvTElOVVhfS0NDX0RFQlVHX0NIRUVUQUgg
LUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAv
c3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFoLTEu
MC4wL2xpYi9MSU5VWF9LQ0NfREVCVUcgLUkvaG9tZS93ZG4vcGFja2FnZXMvbXBpY2gtMS4y
LjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL21tLTEuMS4xL2lu
Y2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9wY2cvcGNnX2Y3NyAtLWRp
c3BsYXlfZXJyb3JfbnVtYmVyIC1mcGljIC1rIC0tc3RyaWN0IC1EX19LQUlfU1RSSUNUIC0t
ZGlhZ19zdXBwcmVzcyA0NTAgK0swDQoNCnJlYWwgMjguNjQNCnVzZXIgMjQuMTcNCnN5cyAx
LjczDQoNCkRvbmUgY29tcGlsaW5nIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhf
S0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9Nb2RlbC9CdXJnZXIvQnVyZ2VyLm8NCg0KQ09N
UElMSU5HLi4uIFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJU
X1hZWl9NUEkvRGVtb19zcmMvTW9kZWwvRGlmZnVzaW9uL0RpZmZ1c2lvbi5vX01QSTEuaW5m
bw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQu
MC9BcHBsaWNhdGlvbnNMYXllci9EZW1vL0RlbW9fc3JjL01vZGVsL0RpZmZ1c2lvbi9EaWZm
dXNpb24uY2MgLW8gL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9Y
WVpfTVBJL0RlbW9fc3JjL01vZGVsL0RpZmZ1c2lvbi9EaWZmdXNpb24ubyAtLW91dHB1dF9k
ZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9Y
WVpfTVBJL0RlbW9fc3JjL01vZGVsL0RpZmZ1c2lvbi9EaWZmdXNpb24uby5kZXBlbmQubWsu
dGVtcCAtLWRpYWdfc3VwcHJlc3MgNjMwIC0tQ09NUERPX2ZlX2NjMmMgLS1wY2hfaWdub3Jl
X2RpciAtLXVzZV9wY2ggL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FS
VF9YWVpfTVBJL0RFTU9fTVBJMS5wY2ggLURURUNfVVNFX0RFTU8gLURURUNfVVNFX1BIWVNJ
Q1NCRVRBIC1EVEVDX1VTRV9IWURST0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlTSUNTU1VQUE9S
VEJFVEEgLURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0VfUE9PTUEySU5U
RUdSQVRJT04gLURURUNfVVNFX1RFQ0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9PTUEgLURURUNf
VVNFX0NIRUVUQUggLURURUNfVVNFX01NIC1EVEVDX1VTRV9QQ0cgLURURUNfTElOVVggLURU
RUNfSU5TVCAtRFRFQ19VU0VfUENIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9i
bGFuY2Ffc3JjXzQuMC9BcHBsaWNhdGlvbnNMYXllci9EZW1vIC1JL3Vzci9wcm9qZWN0cy9i
bGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEg
LUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NM
YXllci9IeWRyb2R5bmFtaWNzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFu
Y2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBv
cnRMYXllci9QaHlzaWNzQmFzZUNsYXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Iv
d2RuL2JsYW5jYV9zcmNfNC4wL1RlY0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRp
b24gLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNy
L3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0
cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRB
SCAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAu
MC9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgt
MS4wLjAvbGliL0xJTlVYX0tDQ19ERUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGljaC0x
LjIuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4xLjEv
aW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0t
ZGlzcGxheV9lcnJvcl9udW1iZXIgLWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJQ1Qg
LS1kaWFnX3N1cHByZXNzIDQ1MCArSzANCg0KcmVhbCAyNC40NA0KdXNlciAyMS42NA0Kc3lz
IDEuNTMNCg0KRG9uZSBjb21waWxpbmcgL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5V
WF9LQ0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3JjL01vZGVsL0RpZmZ1c2lvbi9EaWZmdXNpb24u
bw0KDQpDT01QSUxJTkcuLi4gU2VlIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhf
S0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9Nb2RlbC9MYXhXZW5kcm9mZi9MYXhXZW5kcm9m
Zi5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9i
bGFuY2Ffc3JjXzQuMC9BcHBsaWNhdGlvbnNMYXllci9EZW1vL0RlbW9fc3JjL01vZGVsL0xh
eFdlbmRyb2ZmL0xheFdlbmRyb2ZmLmNjIC1vIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8v
TElOVVhfS0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9Nb2RlbC9MYXhXZW5kcm9mZi9MYXhX
ZW5kcm9mZi5vIC0tb3V0cHV0X2RlcGVuZGVuY2llcyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9E
RU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMvTW9kZWwvTGF4V2VuZHJvZmYv
TGF4V2VuZHJvZmYuby5kZXBlbmQubWsudGVtcCAtLWRpYWdfc3VwcHJlc3MgNjMwIC0tQ09N
UERPX2ZlX2NjMmMgLS1wY2hfaWdub3JlX2RpciAtLXVzZV9wY2ggL3NjcmF0Y2gvd2RuL29i
al80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RFTU9fTVBJMS5wY2ggLURURUNf
VVNFX0RFTU8gLURURUNfVVNFX1BIWVNJQ1NCRVRBIC1EVEVDX1VTRV9IWURST0RZTkFNSUNT
IC1EVEVDX1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEgLURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xB
U1NFUyAtRFRFQ19VU0VfUE9PTUEySU5URUdSQVRJT04gLURURUNfVVNFX1RFQ0ZSQU1FV09S
SyAtRFRFQ19VU0VfUE9PTUEgLURURUNfVVNFX0NIRUVUQUggLURURUNfVVNFX01NIC1EVEVD
X1VTRV9QQ0cgLURURUNfTElOVVggLURURUNfSU5TVCAtRFRFQ19VU0VfUENIIC1JL3Vzci9w
cm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9BcHBsaWNhdGlvbnNMYXll
ci9EZW1vIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9Q
aHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2Ru
L2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5bmFtaWNzIC1JL3Vzci9wcm9q
ZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVy
L1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxh
bmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzQmFzZUNsYXNzZXMgLUkv
dXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1RlY0ludGVncmF0
aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNr
YWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29t
YTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL2xp
Yi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2th
Z2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9w
YWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJTlVYX0tDQ19ERUJVRyAtSS9o
b21lL3dkbi9wYWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9i
bGFuY2EvcGFja2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNh
L3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJvcl9udW1iZXIgLWZwaWMgLWsg
LS1zdHJpY3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHByZXNzIDQ1MCArSzANCg0KcmVh
bCA0NS4wNQ0KdXNlciA0MC42MQ0Kc3lzIDIuOTINCg0KRG9uZSBjb21waWxpbmcgL3NjcmF0
Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3JjL01v
ZGVsL0xheFdlbmRyb2ZmL0xheFdlbmRyb2ZmLm8NCg0KQ09NUElMSU5HLi4uIFNlZSAvc2Ny
YXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMv
TW9kZWwvTGF4V2VuZHJvZmYvTGF4V2VuZHJvZmZSZWxhdGlvbnMub19NUEkxLmluZm8NCg0K
S0NDIC1jIC91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvQXBw
bGljYXRpb25zTGF5ZXIvRGVtby9EZW1vX3NyYy9Nb2RlbC9MYXhXZW5kcm9mZi9MYXhXZW5k
cm9mZlJlbGF0aW9ucy5jYyAtbyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tD
Q19DQVJUX1hZWl9NUEkvRGVtb19zcmMvTW9kZWwvTGF4V2VuZHJvZmYvTGF4V2VuZHJvZmZS
ZWxhdGlvbnMubyAtLW91dHB1dF9kZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAv
REVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3JjL01vZGVsL0xheFdlbmRyb2Zm
L0xheFdlbmRyb2ZmUmVsYXRpb25zLm8uZGVwZW5kLm1rLnRlbXAgLS1kaWFnX3N1cHByZXNz
IDYzMCAtLUNPTVBET19mZV9jYzJjIC0tcGNoX2lnbm9yZV9kaXIgLS11c2VfcGNoIC9zY3Jh
dGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9ERU1PX01QSTEu
cGNoIC1EVEVDX1VTRV9ERU1PIC1EVEVDX1VTRV9QSFlTSUNTQkVUQSAtRFRFQ19VU0VfSFlE
Uk9EWU5BTUlDUyAtRFRFQ19VU0VfUEhZU0lDU1NVUFBPUlRCRVRBIC1EVEVDX1VTRV9QSFlT
SUNTQkFTRUNMQVNTRVMgLURURUNfVVNFX1BPT01BMklOVEVHUkFUSU9OIC1EVEVDX1VTRV9U
RUNGUkFNRVdPUksgLURURUNfVVNFX1BPT01BIC1EVEVDX1VTRV9DSEVFVEFIIC1EVEVDX1VT
RV9NTSAtRFRFQ19VU0VfUENHIC1EVEVDX0xJTlVYIC1EVEVDX0lOU1QgLURURUNfVVNFX1BD
SCAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvQXBwbGlj
YXRpb25zTGF5ZXIvRGVtbyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNh
X3NyY180LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFu
Y2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvSHlkcm9keW5hbWljcyAt
SS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1
cHBvcnRMYXllci9QaHlzaWNzU3VwcG9ydEJldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91
c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc0Jhc2VD
bGFzc2VzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9U
ZWNJbnRlZ3JhdGlvbkxheWVyL1Bvb21hMkludGVncmF0aW9uIC1JL3Vzci9wcm9qZWN0cy9i
bGFuY2EvcGFja2FnZXMvVGVjRnJhbWV3b3JrIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFj
a2FnZXMvUG9vbWEyL3IyL3NyYyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bv
b21hMi9yMi9saWIvTElOVVhfS0NDX0RFQlVHX0NIRUVUQUggLUkvdXNyL3Byb2plY3RzL2Js
YW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvc3JjIC1JL3Vzci9wcm9qZWN0
cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFoLTEuMC4wL2xpYi9MSU5VWF9LQ0Nf
REVCVUcgLUkvaG9tZS93ZG4vcGFja2FnZXMvbXBpY2gtMS4yLjEvaW5jbHVkZSAtSS91c3Iv
cHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL21tLTEuMS4xL2luY2x1ZGUgLUkvdXNyL3Byb2pl
Y3RzL2JsYW5jYS9wYWNrYWdlcy9wY2cvcGNnX2Y3NyAtLWRpc3BsYXlfZXJyb3JfbnVtYmVy
IC1mcGljIC1rIC0tc3RyaWN0IC1EX19LQUlfU1RSSUNUIC0tZGlhZ19zdXBwcmVzcyA0NTAg
K0swDQoNCnJlYWwgMzYuNTkNCnVzZXIgMzIuMzgNCnN5cyAyLjQyDQoNCkRvbmUgY29tcGls
aW5nIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9E
ZW1vX3NyYy9Nb2RlbC9MYXhXZW5kcm9mZi9MYXhXZW5kcm9mZlJlbGF0aW9ucy5vDQoNCkNP
TVBJTElORy4uLiBTZWUgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhf
S0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvaW5jbHVkZS9QaHlzaWNzQmV0YVBD
SC5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9i
bGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3Jj
L2luY2x1ZGUvUGh5c2ljc0JldGFQQ0guY2MgLW8gL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZ
U0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvaW5jbHVk
ZS9QaHlzaWNzQmV0YVBDSC5vIC0tb3V0cHV0X2RlcGVuZGVuY2llcyAvc2NyYXRjaC93ZG4v
b2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRh
X3NyYy9pbmNsdWRlL1BoeXNpY3NCZXRhUENILm8uZGVwZW5kLm1rLnRlbXAgLS1kaWFnX3N1
cHByZXNzIDYzMCAtLWNyZWF0ZV9wY2ggL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JF
VEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QSFlTSUNTQkVUQV9NUEkxLnBjaCAtRFRFQ19V
U0VfUEhZU0lDU0JFVEEgLURURUNfVVNFX0hZRFJPRFlOQU1JQ1MgLURURUNfVVNFX1BIWVNJ
Q1NTVVBQT1JUQkVUQSAtRFRFQ19VU0VfUEhZU0lDU0JBU0VDTEFTU0VTIC1EVEVDX1VTRV9Q
T09NQTJJTlRFR1JBVElPTiAtRFRFQ19VU0VfVEVDRlJBTUVXT1JLIC1EVEVDX1VTRV9QT09N
QSAtRFRFQ19VU0VfQ0hFRVRBSCAtRFRFQ19VU0VfTU0gLURURUNfVVNFX1BDRyAtRFRFQ19M
SU5VWCAtRFRFQ19JTlNUIC1EVEVDX1VTRV9QQ0ggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91
c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YSAtSS91c3Iv
cHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL0h5
ZHJvZHluYW1pY3MgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNf
NC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc1N1cHBvcnRCZXRhIC1JL3Vzci9wcm9q
ZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVy
L1BoeXNpY3NCYXNlQ2xhc3NlcyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxh
bmNhX3NyY180LjAvVGVjSW50ZWdyYXRpb25MYXllci9Qb29tYTJJbnRlZ3JhdGlvbiAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1RlY0ZyYW1ld29yayAtSS91c3IvcHJvamVj
dHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS9wYWNrYWdlcy9Qb29tYTIvcjIvbGliL0xJTlVYX0tDQ19ERUJVR19DSEVFVEFIIC1JL3Vz
ci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFoLTEuMC4wL3NyYyAt
SS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9s
aWIvTElOVVhfS0NDX0RFQlVHIC1JL2hvbWUvd2RuL3BhY2thZ2VzL21waWNoLTEuMi4xL2lu
Y2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9tbS0xLjEuMS9pbmNsdWRl
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvcGNnL3BjZ19mNzcgLS1kaXNwbGF5
X2Vycm9yX251bWJlciAtZnBpYyAtayAtLXN0cmljdCAtRF9fS0FJX1NUUklDVCAtLWRpYWdf
c3VwcHJlc3MgNDUwICtLMA0KDQoiL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFu
Y2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL2lu
Y2x1ZGUvUGh5c2ljc0JldGFQQ0guY2MiOiBjcmVhdGluZyBwcmVjb21waWxlZCBoZWFkZXIg
ZmlsZSAiL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRf
WFlaX01QSS9QSFlTSUNTQkVUQV9NUEkxLnBjaCINCnJlYWwgOC44MQ0KdXNlciA2LjM4DQpz
eXMgMS4zMg0KDQpEb25lIGNvbXBpbGluZyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNT
QkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9pbmNsdWRlL1Bo
eXNpY3NCZXRhUENILm8NCg0KQ09NUElMSU5HLi4uIFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQu
MC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9Q
aHlzaWNzQmV0YUdyb3VwLm9fTVBJMS5pbmZvDQoNCktDQyAtYyAvdXNyL3Byb2plY3RzL2Js
YW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YS9Q
aHlzaWNzQmV0YV9zcmMvUGh5c2ljc0JldGFHcm91cC5jYyAtbyAvc2NyYXRjaC93ZG4vb2Jq
XzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3Ny
Yy9QaHlzaWNzQmV0YUdyb3VwLm8gLS1vdXRwdXRfZGVwZW5kZW5jaWVzIC9zY3JhdGNoL3dk
bi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0Jl
dGFfc3JjL1BoeXNpY3NCZXRhR3JvdXAuby5kZXBlbmQubWsudGVtcCAtLWRpYWdfc3VwcHJl
c3MgNjMwIC0tQ09NUERPX2ZlX2NjMmMgLS1wY2hfaWdub3JlX2RpciAtLXVzZV9wY2ggL3Nj
cmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9Q
SFlTSUNTQkVUQV9NUEkxLnBjaCAtRFRFQ19VU0VfUEhZU0lDU0JFVEEgLURURUNfVVNFX0hZ
RFJPRFlOQU1JQ1MgLURURUNfVVNFX1BIWVNJQ1NTVVBQT1JUQkVUQSAtRFRFQ19VU0VfUEhZ
U0lDU0JBU0VDTEFTU0VTIC1EVEVDX1VTRV9QT09NQTJJTlRFR1JBVElPTiAtRFRFQ19VU0Vf
VEVDRlJBTUVXT1JLIC1EVEVDX1VTRV9QT09NQSAtRFRFQ19VU0VfQ0hFRVRBSCAtRFRFQ19V
U0VfTU0gLURURUNfVVNFX1BDRyAtRFRFQ19MSU5VWCAtRFRFQ19JTlNUIC1EVEVDX1VTRV9Q
Q0ggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNp
Y3NMYXllci9QaHlzaWNzQmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxh
bmNhX3NyY180LjAvUGh5c2ljc0xheWVyL0h5ZHJvZHluYW1pY3MgLUkvdXNyL3Byb2plY3Rz
L2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5
c2ljc1N1cHBvcnRCZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NCYXNlQ2xhc3NlcyAtSS91c3Iv
cHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvVGVjSW50ZWdyYXRpb25M
YXllci9Qb29tYTJJbnRlZ3JhdGlvbiAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2Vz
L1RlY0ZyYW1ld29yayAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9y
Mi9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvbGliL0xJ
TlVYX0tDQ19ERUJVR19DSEVFVEFIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMv
Q2hlZXRhaC9jaGVldGFoLTEuMC4wL3NyYyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2th
Z2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9saWIvTElOVVhfS0NDX0RFQlVHIC1JL2hvbWUv
d2RuL3BhY2thZ2VzL21waWNoLTEuMi4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS9wYWNrYWdlcy9tbS0xLjEuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFj
a2FnZXMvcGNnL3BjZ19mNzcgLS1kaXNwbGF5X2Vycm9yX251bWJlciAtZnBpYyAtayAtLXN0
cmljdCAtRF9fS0FJX1NUUklDVCAtLWRpYWdfc3VwcHJlc3MgNDUwICtLMA0KDQpyZWFsIDAu
NzMNCnVzZXIgMC4yMw0Kc3lzIDAuMDQNCg0KRG9uZSBjb21waWxpbmcgL3NjcmF0Y2gvd2Ru
L29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0
YV9zcmMvUGh5c2ljc0JldGFHcm91cC5vDQoNCkNPTVBJTElORy4uLiBTZWUgL3NjcmF0Y2gv
d2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNz
QmV0YV9zcmMvQW5hbHl0aWNPcGFjaXR5L0FuYWx5dGljT3BhY2l0eVJlbGF0aW9ucy5vX01Q
STEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL0FuYWx5
dGljT3BhY2l0eS9BbmFseXRpY09wYWNpdHlSZWxhdGlvbnMuY2MgLW8gL3NjcmF0Y2gvd2Ru
L29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0
YV9zcmMvQW5hbHl0aWNPcGFjaXR5L0FuYWx5dGljT3BhY2l0eVJlbGF0aW9ucy5vIC0tb3V0
cHV0X2RlcGVuZGVuY2llcyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5V
WF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9BbmFseXRpY09wYWNpdHkvQW5h
bHl0aWNPcGFjaXR5UmVsYXRpb25zLm8uZGVwZW5kLm1rLnRlbXAgLS1kaWFnX3N1cHByZXNz
IDYzMCAtLUNPTVBET19mZV9jYzJjIC0tcGNoX2lnbm9yZV9kaXIgLS11c2VfcGNoIC9zY3Jh
dGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUEhZ
U0lDU0JFVEFfTVBJMS5wY2ggLURURUNfVVNFX1BIWVNJQ1NCRVRBIC1EVEVDX1VTRV9IWURS
T0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEgLURURUNfVVNFX1BIWVNJ
Q1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0VfUE9PTUEySU5URUdSQVRJT04gLURURUNfVVNFX1RF
Q0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9PTUEgLURURUNfVVNFX0NIRUVUQUggLURURUNfVVNF
X01NIC1EVEVDX1VTRV9QQ0cgLURURUNfTElOVVggLURURUNfSU5TVCAtRFRFQ19VU0VfUENI
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNz
TGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5j
YV9zcmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5bmFtaWNzIC1JL3Vzci9wcm9qZWN0cy9i
bGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNp
Y3NTdXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3Ny
Y180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzQmFzZUNsYXNzZXMgLUkvdXNyL3By
b2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1RlY0ludGVncmF0aW9uTGF5
ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9U
ZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIv
c3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL2xpYi9MSU5V
WF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0No
ZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdl
cy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJTlVYX0tDQ19ERUJVRyAtSS9ob21lL3dk
bi9wYWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2Ev
cGFja2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2th
Z2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJvcl9udW1iZXIgLWZwaWMgLWsgLS1zdHJp
Y3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHByZXNzIDQ1MCArSzANCg0KcmVhbCA4LjU2
DQp1c2VyIDcuMDENCnN5cyAxLjAxDQoNCkRvbmUgY29tcGlsaW5nIC9zY3JhdGNoL3dkbi9v
YmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFf
c3JjL0FuYWx5dGljT3BhY2l0eS9BbmFseXRpY09wYWNpdHlSZWxhdGlvbnMubw0KDQpDT01Q
SUxJTkcuLi4gU2VlIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tD
Q19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9JTVJlbGF0
aW9ucy5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dk
bi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFf
c3JjL0ludGVncmFsTWV0aG9kcy9JTVJlbGF0aW9ucy5jYyAtbyAvc2NyYXRjaC93ZG4vb2Jq
XzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3Ny
Yy9JbnRlZ3JhbE1ldGhvZHMvSU1SZWxhdGlvbnMubyAtLW91dHB1dF9kZXBlbmRlbmNpZXMg
L3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01Q
SS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0lNUmVsYXRpb25zLm8uZGVwZW5k
Lm1rLnRlbXAgLS1kaWFnX3N1cHByZXNzIDYzMCAtLUNPTVBET19mZV9jYzJjIC0tcGNoX2ln
bm9yZV9kaXIgLS11c2VfcGNoIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJ
TlVYX0tDQ19DQVJUX1hZWl9NUEkvUEhZU0lDU0JFVEFfTVBJMS5wY2ggLURURUNfVVNFX1BI
WVNJQ1NCRVRBIC1EVEVDX1VTRV9IWURST0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlTSUNTU1VQ
UE9SVEJFVEEgLURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0VfUE9PTUEy
SU5URUdSQVRJT04gLURURUNfVVNFX1RFQ0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9PTUEgLURU
RUNfVVNFX0NIRUVUQUggLURURUNfVVNFX01NIC1EVEVDX1VTRV9QQ0cgLURURUNfTElOVVgg
LURURUNfSU5TVCAtRFRFQ19VU0VfUENIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dk
bi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2pl
Y3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5
bmFtaWNzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9Q
aHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMv
YmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlz
aWNzQmFzZUNsYXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9z
cmNfNC4wL1RlY0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3By
b2plY3RzL2JsYW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2Js
YW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFj
a2FnZXMvUG9vbWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJv
amVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNy
L3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJ
TlVYX0tDQ19ERUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRl
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJv
cl9udW1iZXIgLWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHBy
ZXNzIDQ1MCArSzANCg0KcmVhbCAzOS4xMA0KdXNlciAzNS4zNg0Kc3lzIDIuNDMNCg0KRG9u
ZSBjb21waWxpbmcgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0ND
X0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0lNUmVsYXRp
b25zLm8NCg0KQ09NUElMSU5HLi4uIFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNT
QkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1l
dGhvZHMvU3ltbWV0cnlSZWxhdGlvbnMyRC5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9w
cm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5
c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9TeW1tZXRyeVJlbGF0
aW9uczJELmNjIC1vIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tD
Q19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9TeW1tZXRy
eVJlbGF0aW9uczJELm8gLS1vdXRwdXRfZGVwZW5kZW5jaWVzIC9zY3JhdGNoL3dkbi9vYmpf
NC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3Jj
L0ludGVncmFsTWV0aG9kcy9TeW1tZXRyeVJlbGF0aW9uczJELm8uZGVwZW5kLm1rLnRlbXAg
LS1kaWFnX3N1cHByZXNzIDYzMCAtLUNPTVBET19mZV9jYzJjIC0tcGNoX2lnbm9yZV9kaXIg
LS11c2VfcGNoIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19D
QVJUX1hZWl9NUEkvUEhZU0lDU0JFVEFfTVBJMS5wY2ggLURURUNfVVNFX1BIWVNJQ1NCRVRB
IC1EVEVDX1VTRV9IWURST0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEg
LURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0VfUE9PTUEySU5URUdSQVRJ
T04gLURURUNfVVNFX1RFQ0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9PTUEgLURURUNfVVNFX0NI
RUVUQUggLURURUNfVVNFX01NIC1EVEVDX1VTRV9QQ0cgLURURUNfTElOVVggLURURUNfSU5T
VCAtRFRFQ19VU0VfUENIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5bmFtaWNzIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3Vw
cG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vz
ci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzQmFzZUNs
YXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1Rl
Y0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3Byb2plY3RzL2Js
YW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNr
YWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9v
bWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNyL3Byb2plY3Rz
L2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJTlVYX0tDQ19E
RUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRlIC1JL3Vzci9w
cm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91c3IvcHJvamVj
dHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJvcl9udW1iZXIg
LWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHByZXNzIDQ1MCAr
SzANCg0KcmVhbCAyNy43Mw0KdXNlciAyNC44Mg0Kc3lzIDEuNzQNCg0KRG9uZSBjb21waWxp
bmcgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFla
X01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL1N5bW1ldHJ5UmVsYXRpb25z
MkQubw0KDQpDT01QSUxJTkcuLi4gU2VlIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NC
RVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0
aG9kcy9HZW9tZXRyeS9DeWxpbmRyaWNhbFJlbGF0aW9ucy5vX01QSTEuaW5mbw0KDQpLQ0Mg
LWMgL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNz
TGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9HZW9t
ZXRyeS9DeWxpbmRyaWNhbFJlbGF0aW9ucy5jYyAtbyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9Q
SFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRl
Z3JhbE1ldGhvZHMvR2VvbWV0cnkvQ3lsaW5kcmljYWxSZWxhdGlvbnMubyAtLW91dHB1dF9k
ZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0ND
X0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21ldHJ5
L0N5bGluZHJpY2FsUmVsYXRpb25zLm8uZGVwZW5kLm1rLnRlbXAgLS1kaWFnX3N1cHByZXNz
IDYzMCAtLUNPTVBET19mZV9jYzJjIC0tcGNoX2lnbm9yZV9kaXIgLS11c2VfcGNoIC9zY3Jh
dGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUEhZ
U0lDU0JFVEFfTVBJMS5wY2ggLURURUNfVVNFX1BIWVNJQ1NCRVRBIC1EVEVDX1VTRV9IWURS
T0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEgLURURUNfVVNFX1BIWVNJ
Q1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0VfUE9PTUEySU5URUdSQVRJT04gLURURUNfVVNFX1RF
Q0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9PTUEgLURURUNfVVNFX0NIRUVUQUggLURURUNfVVNF
X01NIC1EVEVDX1VTRV9QQ0cgLURURUNfTElOVVggLURURUNfSU5TVCAtRFRFQ19VU0VfUENI
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNz
TGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5j
YV9zcmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5bmFtaWNzIC1JL3Vzci9wcm9qZWN0cy9i
bGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNp
Y3NTdXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3Ny
Y180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzQmFzZUNsYXNzZXMgLUkvdXNyL3By
b2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1RlY0ludGVncmF0aW9uTGF5
ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9U
ZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIv
c3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL2xpYi9MSU5V
WF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0No
ZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdl
cy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJTlVYX0tDQ19ERUJVRyAtSS9ob21lL3dk
bi9wYWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2Ev
cGFja2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2th
Z2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJvcl9udW1iZXIgLWZwaWMgLWsgLS1zdHJp
Y3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHByZXNzIDQ1MCArSzANCg0KcmVhbCAxMy4z
OQ0KdXNlciAxMS4wNA0Kc3lzIDEuMTINCg0KRG9uZSBjb21waWxpbmcgL3NjcmF0Y2gvd2Ru
L29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0
YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21ldHJ5L0N5bGluZHJpY2FsUmVsYXRpb25zLm8N
Cg0KQ09NUElMSU5HLi4uIFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9M
SU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMv
R2VvbWV0cnkvUGxhbmFyUmVsYXRpb25zLm9fTVBJMS5pbmZvDQoNCktDQyAtYyAvdXNyL3By
b2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlz
aWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21ldHJ5L1BsYW5h
clJlbGF0aW9ucy5jYyAtbyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5V
WF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvR2Vv
bWV0cnkvUGxhbmFyUmVsYXRpb25zLm8gLS1vdXRwdXRfZGVwZW5kZW5jaWVzIC9zY3JhdGNo
L3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2lj
c0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9HZW9tZXRyeS9QbGFuYXJSZWxhdGlvbnMuby5k
ZXBlbmQubWsudGVtcCAtLWRpYWdfc3VwcHJlc3MgNjMwIC0tQ09NUERPX2ZlX2NjMmMgLS1w
Y2hfaWdub3JlX2RpciAtLXVzZV9wY2ggL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JF
VEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QSFlTSUNTQkVUQV9NUEkxLnBjaCAtRFRFQ19V
U0VfUEhZU0lDU0JFVEEgLURURUNfVVNFX0hZRFJPRFlOQU1JQ1MgLURURUNfVVNFX1BIWVNJ
Q1NTVVBQT1JUQkVUQSAtRFRFQ19VU0VfUEhZU0lDU0JBU0VDTEFTU0VTIC1EVEVDX1VTRV9Q
T09NQTJJTlRFR1JBVElPTiAtRFRFQ19VU0VfVEVDRlJBTUVXT1JLIC1EVEVDX1VTRV9QT09N
QSAtRFRFQ19VU0VfQ0hFRVRBSCAtRFRFQ19VU0VfTU0gLURURUNfVVNFX1BDRyAtRFRFQ19M
SU5VWCAtRFRFQ19JTlNUIC1EVEVDX1VTRV9QQ0ggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91
c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YSAtSS91c3Iv
cHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL0h5
ZHJvZHluYW1pY3MgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNf
NC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc1N1cHBvcnRCZXRhIC1JL3Vzci9wcm9q
ZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVy
L1BoeXNpY3NCYXNlQ2xhc3NlcyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxh
bmNhX3NyY180LjAvVGVjSW50ZWdyYXRpb25MYXllci9Qb29tYTJJbnRlZ3JhdGlvbiAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1RlY0ZyYW1ld29yayAtSS91c3IvcHJvamVj
dHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS9wYWNrYWdlcy9Qb29tYTIvcjIvbGliL0xJTlVYX0tDQ19ERUJVR19DSEVFVEFIIC1JL3Vz
ci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFoLTEuMC4wL3NyYyAt
SS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9s
aWIvTElOVVhfS0NDX0RFQlVHIC1JL2hvbWUvd2RuL3BhY2thZ2VzL21waWNoLTEuMi4xL2lu
Y2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9tbS0xLjEuMS9pbmNsdWRl
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvcGNnL3BjZ19mNzcgLS1kaXNwbGF5
X2Vycm9yX251bWJlciAtZnBpYyAtayAtLXN0cmljdCAtRF9fS0FJX1NUUklDVCAtLWRpYWdf
c3VwcHJlc3MgNDUwICtLMA0KDQpyZWFsIDEyLjEwDQp1c2VyIDEwLjUwDQpzeXMgMS4wOQ0K
DQpEb25lIGNvbXBpbGluZyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5V
WF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvR2Vv
bWV0cnkvUGxhbmFyUmVsYXRpb25zLm8NCg0KQ09NUElMSU5HLi4uIFNlZSAvc2NyYXRjaC93
ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NC
ZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvR2VvbWV0cnkvUlpSZWxhdGlvbnMub19NUEkxLmlu
Zm8NCg0KS0NDIC1jIC91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180
LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1l
dGhvZHMvR2VvbWV0cnkvUlpSZWxhdGlvbnMuY2MgLW8gL3NjcmF0Y2gvd2RuL29ial80LjAv
UEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50
ZWdyYWxNZXRob2RzL0dlb21ldHJ5L1JaUmVsYXRpb25zLm8gLS1vdXRwdXRfZGVwZW5kZW5j
aWVzIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZ
Wl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9HZW9tZXRyeS9SWlJlbGF0
aW9ucy5vLmRlcGVuZC5tay50ZW1wIC0tZGlhZ19zdXBwcmVzcyA2MzAgLS1DT01QRE9fZmVf
Y2MyYyAtLXBjaF9pZ25vcmVfZGlyIC0tdXNlX3BjaCAvc2NyYXRjaC93ZG4vb2JqXzQuMC9Q
SFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BIWVNJQ1NCRVRBX01QSTEucGNo
IC1EVEVDX1VTRV9QSFlTSUNTQkVUQSAtRFRFQ19VU0VfSFlEUk9EWU5BTUlDUyAtRFRFQ19V
U0VfUEhZU0lDU1NVUFBPUlRCRVRBIC1EVEVDX1VTRV9QSFlTSUNTQkFTRUNMQVNTRVMgLURU
RUNfVVNFX1BPT01BMklOVEVHUkFUSU9OIC1EVEVDX1VTRV9URUNGUkFNRVdPUksgLURURUNf
VVNFX1BPT01BIC1EVEVDX1VTRV9DSEVFVEFIIC1EVEVDX1VTRV9NTSAtRFRFQ19VU0VfUENH
IC1EVEVDX0xJTlVYIC1EVEVDX0lOU1QgLURURUNfVVNFX1BDSCAtSS91c3IvcHJvamVjdHMv
YmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRh
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNz
TGF5ZXIvSHlkcm9keW5hbWljcyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxh
bmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzU3VwcG9ydEJldGEgLUkv
dXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBw
b3J0TGF5ZXIvUGh5c2ljc0Jhc2VDbGFzc2VzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNy
L3dkbi9ibGFuY2Ffc3JjXzQuMC9UZWNJbnRlZ3JhdGlvbkxheWVyL1Bvb21hMkludGVncmF0
aW9uIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvVGVjRnJhbWV3b3JrIC1JL3Vz
ci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL3NyYyAtSS91c3IvcHJvamVj
dHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9saWIvTElOVVhfS0NDX0RFQlVHX0NIRUVU
QUggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4w
LjAvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFo
LTEuMC4wL2xpYi9MSU5VWF9LQ0NfREVCVUcgLUkvaG9tZS93ZG4vcGFja2FnZXMvbXBpY2gt
MS4yLjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL21tLTEuMS4x
L2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9wY2cvcGNnX2Y3NyAt
LWRpc3BsYXlfZXJyb3JfbnVtYmVyIC1mcGljIC1rIC0tc3RyaWN0IC1EX19LQUlfU1RSSUNU
IC0tZGlhZ19zdXBwcmVzcyA0NTAgK0swDQoNCnJlYWwgMTYuNTMNCnVzZXIgMTMuOTkNCnN5
cyAxLjU3DQoNCkRvbmUgY29tcGlsaW5nIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NC
RVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0
aG9kcy9HZW9tZXRyeS9SWlJlbGF0aW9ucy5vDQoNCkNPTVBJTElORy4uLiBTZWUgL3NjcmF0
Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlz
aWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21ldHJ5L1NwaGVyaWNhbFJlbGF0aW9u
cy5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9i
bGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3Jj
L0ludGVncmFsTWV0aG9kcy9HZW9tZXRyeS9TcGhlcmljYWxSZWxhdGlvbnMuY2MgLW8gL3Nj
cmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9Q
aHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21ldHJ5L1NwaGVyaWNhbFJlbGF0
aW9ucy5vIC0tb3V0cHV0X2RlcGVuZGVuY2llcyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlT
SUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3Jh
bE1ldGhvZHMvR2VvbWV0cnkvU3BoZXJpY2FsUmVsYXRpb25zLm8uZGVwZW5kLm1rLnRlbXAg
LS1kaWFnX3N1cHByZXNzIDYzMCAtLUNPTVBET19mZV9jYzJjIC0tcGNoX2lnbm9yZV9kaXIg
LS11c2VfcGNoIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19D
QVJUX1hZWl9NUEkvUEhZU0lDU0JFVEFfTVBJMS5wY2ggLURURUNfVVNFX1BIWVNJQ1NCRVRB
IC1EVEVDX1VTRV9IWURST0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEg
LURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0VfUE9PTUEySU5URUdSQVRJ
T04gLURURUNfVVNFX1RFQ0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9PTUEgLURURUNfVVNFX0NI
RUVUQUggLURURUNfVVNFX01NIC1EVEVDX1VTRV9QQ0cgLURURUNfTElOVVggLURURUNfSU5T
VCAtRFRFQ19VU0VfUENIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5bmFtaWNzIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3Vw
cG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vz
ci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzQmFzZUNs
YXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1Rl
Y0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3Byb2plY3RzL2Js
YW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNr
YWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9v
bWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNyL3Byb2plY3Rz
L2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJTlVYX0tDQ19E
RUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRlIC1JL3Vzci9w
cm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91c3IvcHJvamVj
dHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJvcl9udW1iZXIg
LWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHByZXNzIDQ1MCAr
SzANCg0KcmVhbCAxMy4yNQ0KdXNlciAxMS41NQ0Kc3lzIDEuMTENCg0KRG9uZSBjb21waWxp
bmcgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFla
X01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21ldHJ5L1NwaGVyaWNh
bFJlbGF0aW9ucy5vDQoNCkNPTVBJTElORy4uLiBTZWUgL3NjcmF0Y2gvd2RuL29ial80LjAv
UEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50
ZWdyYWxNZXRob2RzL0dlb21ldHJ5L1hZUmVsYXRpb25zLm9fTVBJMS5pbmZvDQoNCktDQyAt
YyAvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NM
YXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21l
dHJ5L1hZUmVsYXRpb25zLmNjIC1vIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRB
L0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9k
cy9HZW9tZXRyeS9YWVJlbGF0aW9ucy5vIC0tb3V0cHV0X2RlcGVuZGVuY2llcyAvc2NyYXRj
aC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNp
Y3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvR2VvbWV0cnkvWFlSZWxhdGlvbnMuby5kZXBl
bmQubWsudGVtcCAtLWRpYWdfc3VwcHJlc3MgNjMwIC0tQ09NUERPX2ZlX2NjMmMgLS1wY2hf
aWdub3JlX2RpciAtLXVzZV9wY2ggL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEv
TElOVVhfS0NDX0NBUlRfWFlaX01QSS9QSFlTSUNTQkVUQV9NUEkxLnBjaCAtRFRFQ19VU0Vf
UEhZU0lDU0JFVEEgLURURUNfVVNFX0hZRFJPRFlOQU1JQ1MgLURURUNfVVNFX1BIWVNJQ1NT
VVBQT1JUQkVUQSAtRFRFQ19VU0VfUEhZU0lDU0JBU0VDTEFTU0VTIC1EVEVDX1VTRV9QT09N
QTJJTlRFR1JBVElPTiAtRFRFQ19VU0VfVEVDRlJBTUVXT1JLIC1EVEVDX1VTRV9QT09NQSAt
RFRFQ19VU0VfQ0hFRVRBSCAtRFRFQ19VU0VfTU0gLURURUNfVVNFX1BDRyAtRFRFQ19MSU5V
WCAtRFRFQ19JTlNUIC1EVEVDX1VTRV9QQ0ggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Iv
d2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YSAtSS91c3IvcHJv
amVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL0h5ZHJv
ZHluYW1pY3MgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4w
L1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc1N1cHBvcnRCZXRhIC1JL3Vzci9wcm9qZWN0
cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1Bo
eXNpY3NCYXNlQ2xhc3NlcyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNh
X3NyY180LjAvVGVjSW50ZWdyYXRpb25MYXllci9Qb29tYTJJbnRlZ3JhdGlvbiAtSS91c3Iv
cHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1RlY0ZyYW1ld29yayAtSS91c3IvcHJvamVjdHMv
YmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9w
YWNrYWdlcy9Qb29tYTIvcjIvbGliL0xJTlVYX0tDQ19ERUJVR19DSEVFVEFIIC1JL3Vzci9w
cm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFoLTEuMC4wL3NyYyAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9saWIv
TElOVVhfS0NDX0RFQlVHIC1JL2hvbWUvd2RuL3BhY2thZ2VzL21waWNoLTEuMi4xL2luY2x1
ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9tbS0xLjEuMS9pbmNsdWRlIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvcGNnL3BjZ19mNzcgLS1kaXNwbGF5X2Vy
cm9yX251bWJlciAtZnBpYyAtayAtLXN0cmljdCAtRF9fS0FJX1NUUklDVCAtLWRpYWdfc3Vw
cHJlc3MgNDUwICtLMA0KDQpyZWFsIDE1LjE2DQp1c2VyIDEzLjQwDQpzeXMgMS4xOQ0KDQpE
b25lIGNvbXBpbGluZyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9L
Q0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvR2VvbWV0
cnkvWFlSZWxhdGlvbnMubw0KDQpDT01QSUxJTkcuLi4gU2VlIC9zY3JhdGNoL3dkbi9vYmpf
NC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3Jj
L0ludGVncmFsTWV0aG9kcy9HZW9tZXRyeS9YWVpSZWxhdGlvbnMub19NUEkxLmluZm8NCg0K
S0NDIC1jIC91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5
c2ljc0xheWVyL1BoeXNpY3NCZXRhL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMv
R2VvbWV0cnkvWFlaUmVsYXRpb25zLmNjIC1vIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJ
Q1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFs
TWV0aG9kcy9HZW9tZXRyeS9YWVpSZWxhdGlvbnMubyAtLW91dHB1dF9kZXBlbmRlbmNpZXMg
L3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01Q
SS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21ldHJ5L1hZWlJlbGF0aW9u
cy5vLmRlcGVuZC5tay50ZW1wIC0tZGlhZ19zdXBwcmVzcyA2MzAgLS1DT01QRE9fZmVfY2My
YyAtLXBjaF9pZ25vcmVfZGlyIC0tdXNlX3BjaCAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlT
SUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BIWVNJQ1NCRVRBX01QSTEucGNoIC1E
VEVDX1VTRV9QSFlTSUNTQkVUQSAtRFRFQ19VU0VfSFlEUk9EWU5BTUlDUyAtRFRFQ19VU0Vf
UEhZU0lDU1NVUFBPUlRCRVRBIC1EVEVDX1VTRV9QSFlTSUNTQkFTRUNMQVNTRVMgLURURUNf
VVNFX1BPT01BMklOVEVHUkFUSU9OIC1EVEVDX1VTRV9URUNGUkFNRVdPUksgLURURUNfVVNF
X1BPT01BIC1EVEVDX1VTRV9DSEVFVEFIIC1EVEVDX1VTRV9NTSAtRFRFQ19VU0VfUENHIC1E
VEVDX0xJTlVYIC1EVEVDX0lOU1QgLURURUNfVVNFX1BDSCAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5
ZXIvSHlkcm9keW5hbWljcyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNh
X3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzU3VwcG9ydEJldGEgLUkvdXNy
L3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0
TGF5ZXIvUGh5c2ljc0Jhc2VDbGFzc2VzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dk
bi9ibGFuY2Ffc3JjXzQuMC9UZWNJbnRlZ3JhdGlvbkxheWVyL1Bvb21hMkludGVncmF0aW9u
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvVGVjRnJhbWV3b3JrIC1JL3Vzci9w
cm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL3NyYyAtSS91c3IvcHJvamVjdHMv
YmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9saWIvTElOVVhfS0NDX0RFQlVHX0NIRUVUQUgg
LUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAv
c3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFoLTEu
MC4wL2xpYi9MSU5VWF9LQ0NfREVCVUcgLUkvaG9tZS93ZG4vcGFja2FnZXMvbXBpY2gtMS4y
LjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL21tLTEuMS4xL2lu
Y2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9wY2cvcGNnX2Y3NyAtLWRp
c3BsYXlfZXJyb3JfbnVtYmVyIC1mcGljIC1rIC0tc3RyaWN0IC1EX19LQUlfU1RSSUNUIC0t
ZGlhZ19zdXBwcmVzcyA0NTAgK0swDQoNCnJlYWwgMTUuMTQNCnVzZXIgMTMuMjENCnN5cyAx
LjQ1DQoNCkRvbmUgY29tcGlsaW5nIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRB
L0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9k
cy9HZW9tZXRyeS9YWVpSZWxhdGlvbnMubw0KDQpDT01QSUxJTkcuLi4gU2VlIC9zY3JhdGNo
L3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2lj
c0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9JTUFkdmVjdGlvbi9JTUFkdmVjdGlvbjFELm9f
TVBJMS5pbmZvDQoNCktDQyAtYyAvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5j
YV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMvSW50
ZWdyYWxNZXRob2RzL0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9uMUQuY2MgLW8gL3NjcmF0Y2gv
d2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNz
QmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9uMUQubyAt
LW91dHB1dF9kZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEv
TElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2Rz
L0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9uMUQuby5kZXBlbmQubWsudGVtcCAtLWRpYWdfc3Vw
cHJlc3MgNjMwIC0tQ09NUERPX2ZlX2NjMmMgLS1wY2hfaWdub3JlX2RpciAtLXVzZV9wY2gg
L3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01Q
SS9QSFlTSUNTQkVUQV9NUEkxLnBjaCAtRFRFQ19VU0VfUEhZU0lDU0JFVEEgLURURUNfVVNF
X0hZRFJPRFlOQU1JQ1MgLURURUNfVVNFX1BIWVNJQ1NTVVBQT1JUQkVUQSAtRFRFQ19VU0Vf
UEhZU0lDU0JBU0VDTEFTU0VTIC1EVEVDX1VTRV9QT09NQTJJTlRFR1JBVElPTiAtRFRFQ19V
U0VfVEVDRlJBTUVXT1JLIC1EVEVDX1VTRV9QT09NQSAtRFRFQ19VU0VfQ0hFRVRBSCAtRFRF
Q19VU0VfTU0gLURURUNfVVNFX1BDRyAtRFRFQ19MSU5VWCAtRFRFQ19JTlNUIC1EVEVDX1VT
RV9QQ0ggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1Bo
eXNpY3NMYXllci9QaHlzaWNzQmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4v
YmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL0h5ZHJvZHluYW1pY3MgLUkvdXNyL3Byb2pl
Y3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIv
UGh5c2ljc1N1cHBvcnRCZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFu
Y2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NCYXNlQ2xhc3NlcyAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvVGVjSW50ZWdyYXRp
b25MYXllci9Qb29tYTJJbnRlZ3JhdGlvbiAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2th
Z2VzL1RlY0ZyYW1ld29yayAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21h
Mi9yMi9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvbGli
L0xJTlVYX0tDQ19ERUJVR19DSEVFVEFIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2Fn
ZXMvQ2hlZXRhaC9jaGVldGFoLTEuMC4wL3NyYyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Bh
Y2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9saWIvTElOVVhfS0NDX0RFQlVHIC1JL2hv
bWUvd2RuL3BhY2thZ2VzL21waWNoLTEuMi4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2Js
YW5jYS9wYWNrYWdlcy9tbS0xLjEuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2Ev
cGFja2FnZXMvcGNnL3BjZ19mNzcgLS1kaXNwbGF5X2Vycm9yX251bWJlciAtZnBpYyAtayAt
LXN0cmljdCAtRF9fS0FJX1NUUklDVCAtLWRpYWdfc3VwcHJlc3MgNDUwICtLMA0KDQoiL3Vz
ci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIv
UGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9JTUFkdmVjdGlv
bi9JTUFkdmVjdGlvbi50LmhoIiwgbGluZSAxMTI4OiBlcnJvciAjMzQ5OiANCiAgICAgICAg
ICBubyBvcGVyYXRvciAiLSIgbWF0Y2hlcyB0aGVzZSBvcGVyYW5kcw0KICAgICAgICAgICAg
b3BlcmFuZCB0eXBlcyBhcmU6DQogICAgICAgICAgICAgICAgICAgICAgQWx0VmlldzE8Rmll
bGQ8cG9vbWFsb3RlOjpNb2RlbFRyYWl0czxwb29tYWxvdGU6Ok9uZURGPHBvDQogICAgICAg
ICAgICAgICAgICAgICAgb21hbG90ZTo6RGVmYXVsdFRyYWl0cz4+OjpNZXNoVGFnLCBWZWN0
b3I8MSwNCiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxvdGU6OlJlYWwsIEZ1bGw+LA0K
ICAgICAgICAgICAgICAgICAgICAgIHBvb21hbG90ZTo6TW9kZWxUcmFpdHM8cG9vbWFsb3Rl
OjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bA0KICAgICAgICAgICAgICAgICAgICAgIHRUcmFp
dHM+Pjo6RW5naW5lVGFnPiwgRG9tYWluQXJpdGhPcHNUcmFpdHM8TG9jPDE+LA0KICAgICAg
ICAgICAgICAgICAgICAgIExvYzwxPj46OkFkZFJlc3VsdF90Pjo6VHlwZV90IC0NCiAgICAg
ICAgICAgICAgICAgICAgICBBbHRWaWV3MTxGaWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRz
PHBvb21hbG90ZTo6T25lREY8cG8NCiAgICAgICAgICAgICAgICAgICAgICBvbWFsb3RlOjpE
ZWZhdWx0VHJhaXRzPj46Ok1lc2hUYWcsIFZlY3RvcjwxLA0KICAgICAgICAgICAgICAgICAg
ICAgIHBvb21hbG90ZTo6UmVhbCwgRnVsbD4sDQogICAgICAgICAgICAgICAgICAgICAgcG9v
bWFsb3RlOjpNb2RlbFRyYWl0czxwb29tYWxvdGU6Ok9uZURGPHBvb21hbG90ZTo6RGVmYXVs
DQogICAgICAgICAgICAgICAgICAgICAgdFRyYWl0cz4+OjpFbmdpbmVUYWc+LCBEb21haW5B
cml0aE9wc1RyYWl0czxMb2M8MT4sDQogICAgICAgICAgICAgICAgICAgICAgTG9jPDE+Pjo6
QWRkUmVzdWx0X3Q+OjpUeXBlX3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgLSBTdWJSZWxheGVkTWVzaChmYWNlTG9jICsgb2Zmc2V0KTsNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXg0KICAgICAgICAgIGRldGVjdGVk
IGR1cmluZyBpbnN0YW50aWF0aW9uIG9mICJ2b2lkDQogICAgICAgICAgICAgICAgICAgIFBo
eXNpY3NCZXRhOjpJTUFkdmVjdGlvbjxUcmFpdHM+Ojptb21lbnR1bUFkdmVjdGlvbihwb29t
YWxvDQogICAgICAgICAgICAgICAgICAgIHRlOjpSZWFsICYpIFt3aXRoDQogICAgICAgICAg
ICAgICAgICAgIFRyYWl0cz1wb29tYWxvdGU6Ok9uZURGPHBvb21hbG90ZTo6RGVmYXVsdFRy
YWl0cz5dIiANCg0KIi91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9z
cmMvUEVURS9PcGVyYXRvclRhZ3MuaCIsIGxpbmUgNzU3OiBlcnJvciAjNDEzOiANCiAgICAg
ICAgICBubyBzdWl0YWJsZSBjb252ZXJzaW9uIGZ1bmN0aW9uIGZyb20NCiAgICAgICAgICAi
Y29uc3QgUmVtb3RlUHJveHk8VmVjdG9yPDEsIHBvb21hbG90ZTo6UmVhbCwgRnVsbD4+IiB0
bw0KICAgICAgICAgICJwb29tYWxvdGU6OlJlYWwiIGV4aXN0cw0KICAgICAgcmV0dXJuIChj
b25zdF9jYXN0PFQxICY+KGEpID0gYik7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBeDQogICAgICAgICAgZGV0ZWN0ZWQgZHVyaW5nOg0KICAgICAgICAgICAgaW5z
dGFudGlhdGlvbiBvZiAiQmluYXJ5UmV0dXJuPFQxLCBUMiwgT3BBc3NpZ24+OjpUeXBlX3QN
CiAgICAgICAgICAgICAgICAgICAgICBPcEFzc2lnbjo6b3BlcmF0b3IoKShjb25zdCBUMSAm
LCBjb25zdCBUMiAmKSBjb25zdCBbd2l0aA0KICAgICAgICAgICAgICAgICAgICAgIFQxPXBv
b21hbG90ZTo6UmVhbCwgVDI9UmVtb3RlUHJveHk8VmVjdG9yPDEsDQogICAgICAgICAgICAg
ICAgICAgICAgcG9vbWFsb3RlOjpSZWFsLCBGdWxsPj5dIiBhdCBsaW5lIDE0NiBvZg0KICAg
ICAgICAgICAgICAgICAgICAgICIvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29t
YTIvcjIvc3JjL1RpbnkvVmVjdG9yRQ0KICAgICAgICAgICAgICAgICAgICAgIGxlbWVudHMu
aCINCiAgICAgICAgICAgIGluc3RhbnRpYXRpb24gb2YgInZvaWQgVmVjdG9yQXNzaWduPFYx
LCBWMiwgT3AsIEIsIDE+OjphcHBseShWMSAmLA0KICAgICAgICAgICAgICAgICAgICAgIGNv
bnN0IFYyICYsIE9wKSBbd2l0aCBWMT1WZWN0b3JFbmdpbmU8MSwNCiAgICAgICAgICAgICAg
ICAgICAgICBwb29tYWxvdGU6OlJlYWwsIEZ1bGw+OjpUaGlzX3QsIFYyPVJlbW90ZVByb3h5
PFZlY3RvcjwxLA0KICAgICAgICAgICAgICAgICAgICAgIHBvb21hbG90ZTo6UmVhbCwgRnVs
bD4+LCBPcD1PcEFzc2lnbiwgQj0wXSIgYXQgbGluZSAzMzINCiAgICAgICAgICAgICAgICAg
ICAgICBvZg0KICAgICAgICAgICAgICAgICAgICAgICIvdXNyL3Byb2plY3RzL2JsYW5jYS9w
YWNrYWdlcy9Qb29tYTIvcjIvc3JjL1RpbnkvVmVjdG9yLg0KICAgICAgICAgICAgICAgICAg
ICAgIGgiDQogICAgICAgICAgICBpbnN0YW50aWF0aW9uIG9mICJWZWN0b3JFbmdpbmU8RCwg
VCwgRnVsbD46OlRoaXNfdA0KICAgICAgICAgICAgICAgICAgICAgICZWZWN0b3JFbmdpbmU8
RCwgVCwgRnVsbD46Om9wZXJhdG9yPShjb25zdCBWICYpIFt3aXRoDQogICAgICAgICAgICAg
ICAgICAgICAgRD0xLCBUPXBvb21hbG90ZTo6UmVhbCwgVj1SZW1vdGVQcm94eTxWZWN0b3I8
MSwNCiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxvdGU6OlJlYWwsIEZ1bGw+Pl0iIGF0
IGxpbmUgMTQ5IG9mDQogICAgICAgICAgICAgICAgICAgICAgIi91c3IvcHJvamVjdHMvYmxh
bmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9zcmMvVGlueS9WZWN0b3IuDQogICAgICAgICAgICAg
ICAgICAgICAgaCINCiAgICAgICAgICAgIGluc3RhbnRpYXRpb24gb2YgIlZlY3RvcjxEaW0s
IFQsIEVuZ2luZVRhZz46OlRoaXNfdCAmVmVjdG9yPERpbSwNCiAgICAgICAgICAgICAgICAg
ICAgICBULCBFbmdpbmVUYWc+OjpvcGVyYXRvcj0oY29uc3QgViAmKSBbd2l0aCBEaW09MSwN
CiAgICAgICAgICAgICAgICAgICAgICBUPXBvb21hbG90ZTo6UmVhbCwgRW5naW5lVGFnPUZ1
bGwsDQogICAgICAgICAgICAgICAgICAgICAgVj1BbHRWaWV3MTxGaWVsZDxwb29tYWxvdGU6
Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8DQogICAgICAgICAgICAgICAgICAgICAg
cG9vbWFsb3RlOjpEZWZhdWx0VHJhaXRzPj46Ok1lc2hUYWcsIFZlY3RvcjwxLA0KICAgICAg
ICAgICAgICAgICAgICAgIHBvb21hbG90ZTo6UmVhbCwgRnVsbD4sDQogICAgICAgICAgICAg
ICAgICAgICAgcG9vbWFsb3RlOjpNb2RlbFRyYWl0czxwb29tYWxvdGU6Ok9uZURGPHBvb21h
bG90ZTo6RGVmYXVsDQogICAgICAgICAgICAgICAgICAgICAgdFRyYWl0cz4+OjpFbmdpbmVU
YWc+LCBEb21haW5Bcml0aE9wc1RyYWl0czxMb2M8MT4sDQogICAgICAgICAgICAgICAgICAg
ICAgTG9jPDE+Pjo6QWRkUmVzdWx0X3Q+OjpUeXBlX3RdIiBhdCBsaW5lIDExMzAgb2YNCiAg
ICAgICAgICAgICAgICAgICAgICAiL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFu
Y2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXINCiAgICAgICAgICAgICAgICAgICAgICAvUGh5c2lj
c0JldGEvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9JTUFkdmVjdGlvbi8NCiAg
ICAgICAgICAgICAgICAgICAgICBJTUFkdmVjdGlvbi50LmhoIg0KICAgICAgICAgICAgaW5z
dGFudGlhdGlvbiBvZiAidm9pZA0KICAgICAgICAgICAgICAgICAgICAgIFBoeXNpY3NCZXRh
OjpJTUFkdmVjdGlvbjxUcmFpdHM+Ojptb21lbnR1bUFkdmVjdGlvbihwb29tYQ0KICAgICAg
ICAgICAgICAgICAgICAgIGxvdGU6OlJlYWwgJikgW3dpdGgNCiAgICAgICAgICAgICAgICAg
ICAgICBUcmFpdHM9cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bHRUcmFpdHM+
XSIgDQoNCiIvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1Bo
eXNpY3NMYXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2Rz
L0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9uLnQuaGgiLCBsaW5lIDExNjU6IGVycm9yICMzNDk6
IA0KICAgICAgICAgIG5vIG9wZXJhdG9yICItIiBtYXRjaGVzIHRoZXNlIG9wZXJhbmRzDQog
ICAgICAgICAgICBvcGVyYW5kIHR5cGVzIGFyZToNCiAgICAgICAgICAgICAgICAgICAgICBB
bHRWaWV3MTxGaWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8
cG8NCiAgICAgICAgICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZhdWx0VHJhaXRzPj46Ok1l
c2hUYWcsIFZlY3RvcjwxLA0KICAgICAgICAgICAgICAgICAgICAgIHBvb21hbG90ZTo6UmVh
bCwgRnVsbD4sDQogICAgICAgICAgICAgICAgICAgICAgcG9vbWFsb3RlOjpNb2RlbFRyYWl0
czxwb29tYWxvdGU6Ok9uZURGPHBvb21hbG90ZTo6RGVmYXVsDQogICAgICAgICAgICAgICAg
ICAgICAgdFRyYWl0cz4+OjpFbmdpbmVUYWc+LCBEb21haW5Bcml0aE9wc1RyYWl0czxMb2M8
MT4sDQogICAgICAgICAgICAgICAgICAgICAgTG9jPDE+Pjo6QWRkUmVzdWx0X3Q+OjpUeXBl
X3QgLQ0KICAgICAgICAgICAgICAgICAgICAgIEFsdFZpZXcxPEZpZWxkPHBvb21hbG90ZTo6
TW9kZWxUcmFpdHM8cG9vbWFsb3RlOjpPbmVERjxwbw0KICAgICAgICAgICAgICAgICAgICAg
IG9tYWxvdGU6OkRlZmF1bHRUcmFpdHM+Pjo6TWVzaFRhZywgVmVjdG9yPDEsDQogICAgICAg
ICAgICAgICAgICAgICAgcG9vbWFsb3RlOjpSZWFsLCBGdWxsPiwNCiAgICAgICAgICAgICAg
ICAgICAgICBwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG9vbWFs
b3RlOjpEZWZhdWwNCiAgICAgICAgICAgICAgICAgICAgICB0VHJhaXRzPj46OkVuZ2luZVRh
Zz4sIERvbWFpbkFyaXRoT3BzVHJhaXRzPExvYzwxPiwNCiAgICAgICAgICAgICAgICAgICAg
ICBMb2M8MT4+OjpBZGRSZXN1bHRfdD46OlR5cGVfdA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAtIFN1YlJlbGF4ZWRNZXNoKGZhY2VMb2MgLSBvZmZzZXQp
Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeDQogICAgICAg
ICAgZGV0ZWN0ZWQgZHVyaW5nIGluc3RhbnRpYXRpb24gb2YgInZvaWQNCiAgICAgICAgICAg
ICAgICAgICAgUGh5c2ljc0JldGE6OklNQWR2ZWN0aW9uPFRyYWl0cz46Om1vbWVudHVtQWR2
ZWN0aW9uKHBvb21hbG8NCiAgICAgICAgICAgICAgICAgICAgdGU6OlJlYWwgJikgW3dpdGgN
CiAgICAgICAgICAgICAgICAgICAgVHJhaXRzPXBvb21hbG90ZTo6T25lREY8cG9vbWFsb3Rl
OjpEZWZhdWx0VHJhaXRzPl0iIA0KDQoiL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9i
bGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3Jj
L0ludGVncmFsTWV0aG9kcy9JTUFkdmVjdGlvbi9JTUFkdmVjdGlvbi50LmhoIiwgbGluZSAx
MjA0OiBlcnJvciAjMzQ5OiANCiAgICAgICAgICBubyBvcGVyYXRvciAiLSIgbWF0Y2hlcyB0
aGVzZSBvcGVyYW5kcw0KICAgICAgICAgICAgb3BlcmFuZCB0eXBlcyBhcmU6DQogICAgICAg
ICAgICAgICAgICAgICAgQWx0VmlldzE8RmllbGQ8cG9vbWFsb3RlOjpNb2RlbFRyYWl0czxw
b29tYWxvdGU6Ok9uZURGPHBvDQogICAgICAgICAgICAgICAgICAgICAgb21hbG90ZTo6RGVm
YXVsdFRyYWl0cz4+OjpNZXNoVGFnLCBWZWN0b3I8MSwNCiAgICAgICAgICAgICAgICAgICAg
ICBwb29tYWxvdGU6OlJlYWwsIEZ1bGw+LA0KICAgICAgICAgICAgICAgICAgICAgIHBvb21h
bG90ZTo6TW9kZWxUcmFpdHM8cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bA0K
ICAgICAgICAgICAgICAgICAgICAgIHRUcmFpdHM+Pjo6RW5naW5lVGFnPiwgRG9tYWluQXJp
dGhPcHNUcmFpdHM8TG9jPDE+LA0KICAgICAgICAgICAgICAgICAgICAgIExvYzwxPj46OkFk
ZFJlc3VsdF90Pjo6VHlwZV90IC0NCiAgICAgICAgICAgICAgICAgICAgICBBbHRWaWV3MTxG
aWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG8NCiAgICAg
ICAgICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZhdWx0VHJhaXRzPj46Ok1lc2hUYWcsIFZl
Y3RvcjwxLA0KICAgICAgICAgICAgICAgICAgICAgIHBvb21hbG90ZTo6UmVhbCwgRnVsbD4s
DQogICAgICAgICAgICAgICAgICAgICAgcG9vbWFsb3RlOjpNb2RlbFRyYWl0czxwb29tYWxv
dGU6Ok9uZURGPHBvb21hbG90ZTo6RGVmYXVsDQogICAgICAgICAgICAgICAgICAgICAgdFRy
YWl0cz4+OjpFbmdpbmVUYWc+LCBEb21haW5Bcml0aE9wc1RyYWl0czxMb2M8MT4sDQogICAg
ICAgICAgICAgICAgICAgICAgTG9jPDE+Pjo6QWRkUmVzdWx0X3Q+OjpUeXBlX3QNCiAgCSAg
ICAgICAgICAgICAgZGVsdGFEaXNwbGFjZW1lbnQgPSBPbGQuU3ViVmVydFBvaW50cyhmYWNl
TG9jKSAtIFN1YlJlbGF4ZWRNZXNoKGZhY2VMb2MpOw0KICAJICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4NCiAgICAgICAg
ICBkZXRlY3RlZCBkdXJpbmcgaW5zdGFudGlhdGlvbiBvZiAidm9pZA0KICAgICAgICAgICAg
ICAgICAgICBQaHlzaWNzQmV0YTo6SU1BZHZlY3Rpb248VHJhaXRzPjo6bW9tZW50dW1BZHZl
Y3Rpb24ocG9vbWFsbw0KICAgICAgICAgICAgICAgICAgICB0ZTo6UmVhbCAmKSBbd2l0aA0K
ICAgICAgICAgICAgICAgICAgICBUcmFpdHM9cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6
OkRlZmF1bHRUcmFpdHM+XSIgDQoNCiIvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2Js
YW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMv
SW50ZWdyYWxNZXRob2RzL0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9uLnQuaGgiLCBsaW5lIDc2
MTogZXJyb3IgIzM0OTogDQogICAgICAgICAgbm8gb3BlcmF0b3IgIi0iIG1hdGNoZXMgdGhl
c2Ugb3BlcmFuZHMNCiAgICAgICAgICAgIG9wZXJhbmQgdHlwZXMgYXJlOg0KICAgICAgICAg
ICAgICAgICAgICAgIEFsdFZpZXcxPEZpZWxkPHBvb21hbG90ZTo6TW9kZWxUcmFpdHM8cG9v
bWFsb3RlOjpPbmVERjxwbw0KICAgICAgICAgICAgICAgICAgICAgIG9tYWxvdGU6OkRlZmF1
bHRUcmFpdHM+Pjo6TWVzaFRhZywgVmVjdG9yPDEsDQogICAgICAgICAgICAgICAgICAgICAg
cG9vbWFsb3RlOjpSZWFsLCBGdWxsPiwNCiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxv
dGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG9vbWFsb3RlOjpEZWZhdWwNCiAg
ICAgICAgICAgICAgICAgICAgICB0VHJhaXRzPj46OkVuZ2luZVRhZz4sIERvbWFpbkFyaXRo
T3BzVHJhaXRzPExvYzwxPiwNCiAgICAgICAgICAgICAgICAgICAgICBMb2M8MT4+OjpBZGRS
ZXN1bHRfdD46OlR5cGVfdCAtDQogICAgICAgICAgICAgICAgICAgICAgQWx0VmlldzE8Rmll
bGQ8cG9vbWFsb3RlOjpNb2RlbFRyYWl0czxwb29tYWxvdGU6Ok9uZURGPHBvDQogICAgICAg
ICAgICAgICAgICAgICAgb21hbG90ZTo6RGVmYXVsdFRyYWl0cz4+OjpNZXNoVGFnLCBWZWN0
b3I8MSwNCiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxvdGU6OlJlYWwsIEZ1bGw+LA0K
ICAgICAgICAgICAgICAgICAgICAgIHBvb21hbG90ZTo6TW9kZWxUcmFpdHM8cG9vbWFsb3Rl
OjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bA0KICAgICAgICAgICAgICAgICAgICAgIHRUcmFp
dHM+Pjo6RW5naW5lVGFnPiwgRG9tYWluQXJpdGhPcHNUcmFpdHM8TG9jPDE+LA0KICAgICAg
ICAgICAgICAgICAgICAgIExvYzwxPj46OkFkZFJlc3VsdF90Pjo6VHlwZV90DQogICAgICAg
ICAgICAgICAgZGVsdGFEaXNwbGFjZW1lbnQgPSAgT2xkLlZlcnRQb2ludHModmVydExvYykg
LSBSZWxheGVkTWVzaCh2ZXJ0TG9jKTsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeDQogICAgICAgICAgZGV0ZWN0ZWQg
ZHVyaW5nIGluc3RhbnRpYXRpb24gb2YgInZvaWQNCiAgICAgICAgICAgICAgICAgICAgUGh5
c2ljc0JldGE6OklNQWR2ZWN0aW9uPFRyYWl0cz46OnZhcmlhYmxlQWR2ZWN0aW9uKHBvb21h
bG8NCiAgICAgICAgICAgICAgICAgICAgdGU6OlJlYWwgJikgW3dpdGgNCiAgICAgICAgICAg
ICAgICAgICAgVHJhaXRzPXBvb21hbG90ZTo6T25lREY8cG9vbWFsb3RlOjpEZWZhdWx0VHJh
aXRzPl0iIA0KDQoiL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQu
MC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0
aG9kcy9JTUFkdmVjdGlvbi9JTUFkdmVjdGlvbi50LmhoIiwgbGluZSA4OTE6IGVycm9yICMz
MDQ6IA0KICAgICAgICAgIG5vIGluc3RhbmNlIG9mIG92ZXJsb2FkZWQgZnVuY3Rpb24gIm1p
biIgbWF0Y2hlcyB0aGUgYXJndW1lbnQgbGlzdA0KICAgICAgICAgICAgYXJndW1lbnQgdHlw
ZXMgYXJlOiAoZG91YmxlLA0KICAgICAgICAgICAgICAgICAgICAgIEFsdFZpZXcxPEZpZWxk
PHBvb21hbG90ZTo6TW9kZWxUcmFpdHM8cG9vbWFsb3RlOjpPbmVERjxwbw0KICAgICAgICAg
ICAgICAgICAgICAgIG9tYWxvdGU6OkRlZmF1bHRUcmFpdHM+Pjo6TWVzaFRhZywgcG9vbWFs
b3RlOjpSZWFsLA0KICAgICAgICAgICAgICAgICAgICAgIHBvb21hbG90ZTo6TW9kZWxUcmFp
dHM8cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bA0KICAgICAgICAgICAgICAg
ICAgICAgIHRUcmFpdHM+Pjo6RW5naW5lVGFnPiwgTG9jPDE+Pjo6VHlwZV90KQ0KICAgICAg
ICAgICAgICAgICAgICAgIGFkdmVjdGVkTWFzcyAgID0gbWluKCBhZHZlY3RlZE1hc3MgKiBt
bV9Wb2xGbHV4W21dLCBNTV9NYXNzW21dKGRvbm9yTG9jKSApOw0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXg0KICAgICAgICAgIGRldGVjdGVkIGR1cmluZyBp
bnN0YW50aWF0aW9uIG9mICJ2b2lkDQogICAgICAgICAgICAgICAgICAgIFBoeXNpY3NCZXRh
OjpJTUFkdmVjdGlvbjxUcmFpdHM+Ojp2YXJpYWJsZUFkdmVjdGlvbihwb29tYWxvDQogICAg
ICAgICAgICAgICAgICAgIHRlOjpSZWFsICYpIFt3aXRoDQogICAgICAgICAgICAgICAgICAg
IFRyYWl0cz1wb29tYWxvdGU6Ok9uZURGPHBvb21hbG90ZTo6RGVmYXVsdFRyYWl0cz5dIiAN
Cg0KIi91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2lj
c0xheWVyL1BoeXNpY3NCZXRhL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvSU1B
ZHZlY3Rpb24vSU1BZHZlY3Rpb24udC5oaCIsIGxpbmUgODkzOiBlcnJvciAjMzA0OiANCiAg
ICAgICAgICBubyBpbnN0YW5jZSBvZiBvdmVybG9hZGVkIGZ1bmN0aW9uICJtaW4iIG1hdGNo
ZXMgdGhlIGFyZ3VtZW50IGxpc3QNCiAgICAgICAgICAgIGFyZ3VtZW50IHR5cGVzIGFyZTog
KHBvb21hbG90ZTo6UmVhbCwNCiAgICAgICAgICAgICAgICAgICAgICBBbHRWaWV3MTxGaWVs
ZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG8NCiAgICAgICAg
ICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZhdWx0VHJhaXRzPj46Ok1lc2hUYWcsIHBvb21h
bG90ZTo6UmVhbCwNCiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxvdGU6Ok1vZGVsVHJh
aXRzPHBvb21hbG90ZTo6T25lREY8cG9vbWFsb3RlOjpEZWZhdWwNCiAgICAgICAgICAgICAg
ICAgICAgICB0VHJhaXRzPj46OkVuZ2luZVRhZz4sIExvYzwxPj46OlR5cGVfdCkNCiAgICAg
ICAgICAgICAgICAgICAgICBSZWFsIGFkdmVjdGVkVm9sdW1lID0gbWluKCBtbV9Wb2xGbHV4
W21dLCBNTV9Wb2xGcmFjW21dKGRvbm9yTG9jKSk7DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIF4NCiAgICAgICAgICBkZXRlY3RlZCBkdXJpbmcgaW5z
dGFudGlhdGlvbiBvZiAidm9pZA0KICAgICAgICAgICAgICAgICAgICBQaHlzaWNzQmV0YTo6
SU1BZHZlY3Rpb248VHJhaXRzPjo6dmFyaWFibGVBZHZlY3Rpb24ocG9vbWFsbw0KICAgICAg
ICAgICAgICAgICAgICB0ZTo6UmVhbCAmKSBbd2l0aA0KICAgICAgICAgICAgICAgICAgICBU
cmFpdHM9cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bHRUcmFpdHM+XSIgDQoN
CiIvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NM
YXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0lNQWR2
ZWN0aW9uL0lNQWR2ZWN0aW9uLnQuaGgiLCBsaW5lIDg5NTogZXJyb3IgIzM0OTogDQogICAg
ICAgICAgbm8gb3BlcmF0b3IgIi09IiBtYXRjaGVzIHRoZXNlIG9wZXJhbmRzDQogICAgICAg
ICAgICBvcGVyYW5kIHR5cGVzIGFyZToNCiAgICAgICAgICAgICAgICAgICAgICBBbHRWaWV3
MTxGaWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG8NCiAg
ICAgICAgICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZhdWx0VHJhaXRzPj46Ok1lc2hUYWcs
IHBvb21hbG90ZTo6UmVhbCwNCiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxvdGU6Ok1v
ZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG9vbWFsb3RlOjpEZWZhdWwNCiAgICAgICAg
ICAgICAgICAgICAgICB0VHJhaXRzPj46OkVuZ2luZVRhZz4sIExvYzwxPj46OlR5cGVfdCAt
PSBwb29tYWxvdGU6OlJlYWwNCiAgICAgICAgICAgICAgICAgICAgICBNTV9NYXNzW21dKGRv


From wdn at lanl.gov  Fri Jun  8 17:41:10 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Fri, 8 Jun 2001 11:41:10 -0600
Subject: Problem Compiling Blanca Application with Cheetah (2/2)
Message-ID: <200106081741.f58HfDn05469@saltydog.lanl.gov>

ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4NCiAgICAgICAgICBk
ZXRlY3RlZCBkdXJpbmcgaW5zdGFudGlhdGlvbiBvZiAidm9pZA0KICAgICAgICAgICAgICAg
ICAgICBQaHlzaWNzQmV0YTo6SU1BZHZlY3Rpb248VHJhaXRzPjo6dmFyaWFibGVBZHZlY3Rp
b24ocG9vbWFsbw0KICAgICAgICAgICAgICAgICAgICB0ZTo6UmVhbCAmKSBbd2l0aA0KICAg
ICAgICAgICAgICAgICAgICBUcmFpdHM9cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRl
ZmF1bHRUcmFpdHM+XSIgDQoNCiIvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5j
YV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMvSW50
ZWdyYWxNZXRob2RzL0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9uLnQuaGgiLCBsaW5lIDg5Njog
ZXJyb3IgIzM0OTogDQogICAgICAgICAgbm8gb3BlcmF0b3IgIis9IiBtYXRjaGVzIHRoZXNl
IG9wZXJhbmRzDQogICAgICAgICAgICBvcGVyYW5kIHR5cGVzIGFyZToNCiAgICAgICAgICAg
ICAgICAgICAgICBBbHRWaWV3MTxGaWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21h
bG90ZTo6T25lREY8cG8NCiAgICAgICAgICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZhdWx0
VHJhaXRzPj46Ok1lc2hUYWcsIHBvb21hbG90ZTo6UmVhbCwNCiAgICAgICAgICAgICAgICAg
ICAgICBwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG9vbWFsb3Rl
OjpEZWZhdWwNCiAgICAgICAgICAgICAgICAgICAgICB0VHJhaXRzPj46OkVuZ2luZVRhZz4s
IExvYzwxPj46OlR5cGVfdCArPSBwb29tYWxvdGU6OlJlYWwNCiAgICAgICAgICAgICAgICAg
ICAgICBNTV9NYXNzW21dKGFjY2VwdG9yTG9jKSAgICs9IGFkdmVjdGVkTWFzczsNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4NCiAgICAgICAg
ICBkZXRlY3RlZCBkdXJpbmcgaW5zdGFudGlhdGlvbiBvZiAidm9pZA0KICAgICAgICAgICAg
ICAgICAgICBQaHlzaWNzQmV0YTo6SU1BZHZlY3Rpb248VHJhaXRzPjo6dmFyaWFibGVBZHZl
Y3Rpb24ocG9vbWFsbw0KICAgICAgICAgICAgICAgICAgICB0ZTo6UmVhbCAmKSBbd2l0aA0K
ICAgICAgICAgICAgICAgICAgICBUcmFpdHM9cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6
OkRlZmF1bHRUcmFpdHM+XSIgDQoNCiIvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2Js
YW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMv
SW50ZWdyYWxNZXRob2RzL0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9uLnQuaGgiLCBsaW5lIDg5
OTogZXJyb3IgIzM0OTogDQogICAgICAgICAgbm8gb3BlcmF0b3IgIi09IiBtYXRjaGVzIHRo
ZXNlIG9wZXJhbmRzDQogICAgICAgICAgICBvcGVyYW5kIHR5cGVzIGFyZToNCiAgICAgICAg
ICAgICAgICAgICAgICBBbHRWaWV3MTxGaWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBv
b21hbG90ZTo6T25lREY8cG8NCiAgICAgICAgICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZh
dWx0VHJhaXRzPj46Ok1lc2hUYWcsIHBvb21hbG90ZTo6UmVhbCwNCiAgICAgICAgICAgICAg
ICAgICAgICBwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG9vbWFs
b3RlOjpEZWZhdWwNCiAgICAgICAgICAgICAgICAgICAgICB0VHJhaXRzPj46OkVuZ2luZVRh
Zz4sIExvYzwxPj46OlR5cGVfdCAtPSBwb29tYWxvdGU6OlJlYWwNCiAgICAgICAgICAgICAg
ICAgICAgICBNTV9Wb2xGcmFjW21dKGRvbm9yTG9jKSAgICAtPSBhZHZlY3RlZFZvbHVtZTsN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeDQog
ICAgICAgICAgZGV0ZWN0ZWQgZHVyaW5nIGluc3RhbnRpYXRpb24gb2YgInZvaWQNCiAgICAg
ICAgICAgICAgICAgICAgUGh5c2ljc0JldGE6OklNQWR2ZWN0aW9uPFRyYWl0cz46OnZhcmlh
YmxlQWR2ZWN0aW9uKHBvb21hbG8NCiAgICAgICAgICAgICAgICAgICAgdGU6OlJlYWwgJikg
W3dpdGgNCiAgICAgICAgICAgICAgICAgICAgVHJhaXRzPXBvb21hbG90ZTo6T25lREY8cG9v
bWFsb3RlOjpEZWZhdWx0VHJhaXRzPl0iIA0KDQoiL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNy
L3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0Jl
dGFfc3JjL0ludGVncmFsTWV0aG9kcy9JTUFkdmVjdGlvbi9JTUFkdmVjdGlvbi50LmhoIiwg
bGluZSA5MDA6IGVycm9yICMzNDk6IA0KICAgICAgICAgIG5vIG9wZXJhdG9yICIrPSIgbWF0
Y2hlcyB0aGVzZSBvcGVyYW5kcw0KICAgICAgICAgICAgb3BlcmFuZCB0eXBlcyBhcmU6DQog
ICAgICAgICAgICAgICAgICAgICAgQWx0VmlldzE8RmllbGQ8cG9vbWFsb3RlOjpNb2RlbFRy
YWl0czxwb29tYWxvdGU6Ok9uZURGPHBvDQogICAgICAgICAgICAgICAgICAgICAgb21hbG90
ZTo6RGVmYXVsdFRyYWl0cz4+OjpNZXNoVGFnLCBwb29tYWxvdGU6OlJlYWwsDQogICAgICAg
ICAgICAgICAgICAgICAgcG9vbWFsb3RlOjpNb2RlbFRyYWl0czxwb29tYWxvdGU6Ok9uZURG
PHBvb21hbG90ZTo6RGVmYXVsDQogICAgICAgICAgICAgICAgICAgICAgdFRyYWl0cz4+OjpF
bmdpbmVUYWc+LCBMb2M8MT4+OjpUeXBlX3QgKz0gcG9vbWFsb3RlOjpSZWFsDQogICAgICAg
ICAgICAgICAgICAgICAgTU1fVm9sRnJhY1ttXShhY2NlcHRvckxvYykgKz0gYWR2ZWN0ZWRW
b2x1bWU7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgXg0KICAgICAgICAgIGRldGVjdGVkIGR1cmluZyBpbnN0YW50aWF0aW9uIG9mICJ2b2lk
DQogICAgICAgICAgICAgICAgICAgIFBoeXNpY3NCZXRhOjpJTUFkdmVjdGlvbjxUcmFpdHM+
Ojp2YXJpYWJsZUFkdmVjdGlvbihwb29tYWxvDQogICAgICAgICAgICAgICAgICAgIHRlOjpS
ZWFsICYpIFt3aXRoDQogICAgICAgICAgICAgICAgICAgIFRyYWl0cz1wb29tYWxvdGU6Ok9u
ZURGPHBvb21hbG90ZTo6RGVmYXVsdFRyYWl0cz5dIiANCg0KIi91c3IvcHJvamVjdHMvYmxh
bmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhL1Bo
eXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvSU1BZHZlY3Rpb24vSU1BZHZlY3Rpb24u
dC5oaCIsIGxpbmUgMTAzOTogZXJyb3IgIzM0OTogDQogICAgICAgICAgbm8gb3BlcmF0b3Ig
Ii09IiBtYXRjaGVzIHRoZXNlIG9wZXJhbmRzDQogICAgICAgICAgICBvcGVyYW5kIHR5cGVz
IGFyZToNCiAgICAgICAgICAgICAgICAgICAgICBBbHRWaWV3MTxGaWVsZDxwb29tYWxvdGU6
Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG8NCiAgICAgICAgICAgICAgICAgICAg
ICBvbWFsb3RlOjpEZWZhdWx0VHJhaXRzPj46Ok1lc2hUYWcsIHBvb21hbG90ZTo6UmVhbCwN
CiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90
ZTo6T25lREY8cG9vbWFsb3RlOjpEZWZhdWwNCiAgICAgICAgICAgICAgICAgICAgICB0VHJh
aXRzPj46OkVuZ2luZVRhZz4sIExvYzwxPj46OlR5cGVfdCAtPSBwb29tYWxvdGU6OlJlYWwN
CiAgICAgICAgICAgICAgQWR2ZWN0RmllbGRbbV0oZG9ub3JMb2MpICAgIC09IGFkdmVjdGVk
UXVhbnRpdHk7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBe
DQogICAgICAgICAgZGV0ZWN0ZWQgZHVyaW5nIGluc3RhbnRpYXRpb24gb2YgInZvaWQNCiAg
ICAgICAgICAgICAgICAgICAgUGh5c2ljc0JldGE6OklNQWR2ZWN0aW9uPFRyYWl0cz46OmFk
dmVjdFZhcmlhYmxlU2V0KGNvbnN0DQogICAgICAgICAgICAgICAgICAgIHN0ZDo6c2V0PHN0
ZDo6c3RyaW5nLCBzdGQ6Omxlc3M8c3RkOjpzdHJpbmc+LA0KICAgICAgICAgICAgICAgICAg
ICBzdGQ6OmFsbG9jYXRvcjxzdGQ6OnN0cmluZz4+ICYsIGNvbnN0DQogICAgICAgICAgICAg
ICAgICAgIFBoeXNpY3NCZXRhOjpJTUFkdmVjdGlvbjxUcmFpdHM+OjpTY2FsYXJGaWVsZCAm
LCBjb25zdCBpbnQNCiAgICAgICAgICAgICAgICAgICAgJikgW3dpdGgNCiAgICAgICAgICAg
ICAgICAgICAgVHJhaXRzPXBvb21hbG90ZTo6T25lREY8cG9vbWFsb3RlOjpEZWZhdWx0VHJh
aXRzPl0iIA0KDQoiL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQu
MC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0
aG9kcy9JTUFkdmVjdGlvbi9JTUFkdmVjdGlvbi50LmhoIiwgbGluZSAxMDQwOiBlcnJvciAj
MzQ5OiANCiAgICAgICAgICBubyBvcGVyYXRvciAiKz0iIG1hdGNoZXMgdGhlc2Ugb3BlcmFu
ZHMNCiAgICAgICAgICAgIG9wZXJhbmQgdHlwZXMgYXJlOg0KICAgICAgICAgICAgICAgICAg
ICAgIEFsdFZpZXcxPEZpZWxkPHBvb21hbG90ZTo6TW9kZWxUcmFpdHM8cG9vbWFsb3RlOjpP
bmVERjxwbw0KICAgICAgICAgICAgICAgICAgICAgIG9tYWxvdGU6OkRlZmF1bHRUcmFpdHM+
Pjo6TWVzaFRhZywgcG9vbWFsb3RlOjpSZWFsLA0KICAgICAgICAgICAgICAgICAgICAgIHBv
b21hbG90ZTo6TW9kZWxUcmFpdHM8cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRlZmF1
bA0KICAgICAgICAgICAgICAgICAgICAgIHRUcmFpdHM+Pjo6RW5naW5lVGFnPiwgTG9jPDE+
Pjo6VHlwZV90ICs9IHBvb21hbG90ZTo6UmVhbA0KICAgICAgICAgICAgICBBZHZlY3RGaWVs
ZFttXShhY2NlcHRvckxvYykgKz0gYWR2ZWN0ZWRRdWFudGl0eTsNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4NCiAgICAgICAgICBkZXRlY3RlZCBkdXJp
bmcgaW5zdGFudGlhdGlvbiBvZiAidm9pZA0KICAgICAgICAgICAgICAgICAgICBQaHlzaWNz
QmV0YTo6SU1BZHZlY3Rpb248VHJhaXRzPjo6YWR2ZWN0VmFyaWFibGVTZXQoY29uc3QNCiAg
ICAgICAgICAgICAgICAgICAgc3RkOjpzZXQ8c3RkOjpzdHJpbmcsIHN0ZDo6bGVzczxzdGQ6
OnN0cmluZz4sDQogICAgICAgICAgICAgICAgICAgIHN0ZDo6YWxsb2NhdG9yPHN0ZDo6c3Ry
aW5nPj4gJiwgY29uc3QNCiAgICAgICAgICAgICAgICAgICAgUGh5c2ljc0JldGE6OklNQWR2
ZWN0aW9uPFRyYWl0cz46OlNjYWxhckZpZWxkICYsIGNvbnN0IGludA0KICAgICAgICAgICAg
ICAgICAgICAmKSBbd2l0aA0KICAgICAgICAgICAgICAgICAgICBUcmFpdHM9cG9vbWFsb3Rl
OjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bHRUcmFpdHM+XSIgDQoNCjEzIGVycm9ycyBkZXRl
Y3RlZCBpbiB0aGUgY29tcGlsYXRpb24gb2YgIi91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93
ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhL1BoeXNpY3NCZXRh
X3NyYy9JbnRlZ3JhbE1ldGhvZHMvSU1BZHZlY3Rpb24vSU1BZHZlY3Rpb24xRC5jYyIuDQpL
Q0M6IENvbXBpbGF0aW9uIGZhaWxlZC4NCkNvbW1hbmQgZXhpdGVkIHdpdGggbm9uLXplcm8g
c3RhdHVzIDINCnJlYWwgMTQuNTkNCnVzZXIgMTIuMDMNCnN5cyAxLjAyDQoNCkVycm9yIGNv
bXBpbGluZyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FS
VF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvSU1BZHZlY3Rpb24v
SU1BZHZlY3Rpb24xRC5vDQptYWtlOiAqKiogWy9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJ
Q1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFs
TWV0aG9kcy9JTUFkdmVjdGlvbi9JTUFkdmVjdGlvbjFELm9dIEVycm9yIDkNCkNvbW1hbmQg
ZXhpdGVkIHdpdGggbm9uLXplcm8gc3RhdHVzIDINCnJlYWwgMzU3LjI0DQp1c2VyIDI5OS4y
OA0Kc3lzIDI4LjkzDQoNCkNvbXBpbGF0aW9uIGV4aXRlZCBhYm5vcm1hbGx5IHdpdGggY29k
ZSAyIGF0IEZyaSBKdW4gIDggMTE6MDk6NDk=



From wdn at lanl.gov  Fri Jun  8 17:41:10 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Fri, 8 Jun 2001 11:41:10 -0600
Subject: Problem Compiling Blanca Application with Cheetah (1/2)
Message-ID: <200106081741.f58HfDk05468@saltydog.lanl.gov>

SGkgSmVmZnJleSBhbmQgU3RlcGhlbiwNCg0KSSBhbSB1bmFibGUgdG8gY29tcGlsZSBvdXIg
YXBwbGljYXRpb24gd2l0aCBtcGkvQ2hlZXRhaCBiZWNhdXNlIG9mIGVycm9ycw0Kd2hpY2gg
YXJlIGxpc3RlZCBpbiB0aGUgYnVpbGQgbG9nIGJlbG93LiAgQ291bGQgeW91IGd1eXMgdGFr
ZSBhIGxvb2sgYXQgdGhlc2UNCmVycm9ycyB0byBzZWUgaWYgdGhlIHByb2JsZW0gaXMgaW4g
UG9vbWEgYW5kIGlmIHNvLCBsZXQgdXMga25vdyB3aGF0IHdvdWxkIGJlDQppbnZvbHZlZCBp
biBmaXhpbmcgdGhlIHByb2JsZW0/DQoNClRoYW5rcywNCg0KRGF2ZSBOeXN0cm9tCQkJZW1h
aWw6IHdkbkBsYW5sLmdvdg0KTEFOTCBYLTMJCQlwaG9uZTogNTA1LTY2Ny03OTEzCWZheDog
NTA1LTY2NS0zMDQ2DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tYnVpbGQtbG9nLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCmNkIC91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3Ny
Y180LjAvQXBwbGljYXRpb25zTGF5ZXIvRGVtby8NCmRhdGU7IC91c3IvYmluL3RpbWUgLXAg
bWFrZSBSRUNVUlNFPTEgUEFTUz1NUEkxIGFwcA0KRnJpIEp1biAgOCAxMTowMzo1MiBNRFQg
MjAwMQ0KQ09QWUlORy4uLiAvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9UZWNGcmFt
ZXdvcmsvVGVjRnJhbWV3b3JrX3NyYy9NYWluL21haW4uY2MgdG8gL3NjcmF0Y2gvd2RuL29i
al80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL21haW4uY2MNCg0KQ09NUElMSU5H
Li4uIFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9N
UEkvRGVtb19zcmMvaW5jbHVkZS9EZW1vUENILm9fTVBJMS5pbmZvDQoNCktDQyAtYyAvdXNy
L3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL0FwcGxpY2F0aW9uc0xh
eWVyL0RlbW8vRGVtb19zcmMvaW5jbHVkZS9EZW1vUENILmNjIC1vIC9zY3JhdGNoL3dkbi9v
YmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9pbmNsdWRlL0Rl
bW9QQ0gubyAtLW91dHB1dF9kZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAvREVN
Ty9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3JjL2luY2x1ZGUvRGVtb1BDSC5vLmRl
cGVuZC5tay50ZW1wIC0tZGlhZ19zdXBwcmVzcyA2MzAgLS1jcmVhdGVfcGNoIC9zY3JhdGNo
L3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9ERU1PX01QSTEucGNo
IC1EVEVDX1VTRV9ERU1PIC1EVEVDX1VTRV9QSFlTSUNTQkVUQSAtRFRFQ19VU0VfSFlEUk9E
WU5BTUlDUyAtRFRFQ19VU0VfUEhZU0lDU1NVUFBPUlRCRVRBIC1EVEVDX1VTRV9QSFlTSUNT
QkFTRUNMQVNTRVMgLURURUNfVVNFX1BPT01BMklOVEVHUkFUSU9OIC1EVEVDX1VTRV9URUNG
UkFNRVdPUksgLURURUNfVVNFX1BPT01BIC1EVEVDX1VTRV9DSEVFVEFIIC1EVEVDX1VTRV9N
TSAtRFRFQ19VU0VfUENHIC1EVEVDX0xJTlVYIC1EVEVDX0lOU1QgLURURUNfVVNFX1BDSCAt
SS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvQXBwbGljYXRp
b25zTGF5ZXIvRGVtbyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3Ny
Y180LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2Ev
dXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvSHlkcm9keW5hbWljcyAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBv
cnRMYXllci9QaHlzaWNzU3VwcG9ydEJldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Iv
d2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc0Jhc2VDbGFz
c2VzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9UZWNJ
bnRlZ3JhdGlvbkxheWVyL1Bvb21hMkludGVncmF0aW9uIC1JL3Vzci9wcm9qZWN0cy9ibGFu
Y2EvcGFja2FnZXMvVGVjRnJhbWV3b3JrIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2Fn
ZXMvUG9vbWEyL3IyL3NyYyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21h
Mi9yMi9saWIvTElOVVhfS0NDX0RFQlVHX0NIRUVUQUggLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvc3JjIC1JL3Vzci9wcm9qZWN0cy9i
bGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFoLTEuMC4wL2xpYi9MSU5VWF9LQ0NfREVC
VUcgLUkvaG9tZS93ZG4vcGFja2FnZXMvbXBpY2gtMS4yLjEvaW5jbHVkZSAtSS91c3IvcHJv
amVjdHMvYmxhbmNhL3BhY2thZ2VzL21tLTEuMS4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3Rz
L2JsYW5jYS9wYWNrYWdlcy9wY2cvcGNnX2Y3NyAtLWRpc3BsYXlfZXJyb3JfbnVtYmVyIC1m
cGljIC1rIC0tc3RyaWN0IC1EX19LQUlfU1RSSUNUIC0tZGlhZ19zdXBwcmVzcyA0NTAgK0sw
DQoNCiIvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL0FwcGxp
Y2F0aW9uc0xheWVyL0RlbW8vRGVtb19zcmMvaW5jbHVkZS9EZW1vUENILmNjIjogY3JlYXRp
bmcgcHJlY29tcGlsZWQgaGVhZGVyIGZpbGUgIi9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8v
TElOVVhfS0NDX0NBUlRfWFlaX01QSS9ERU1PX01QSTEucGNoIg0KcmVhbCAxNC41Ng0KdXNl
ciA2LjcxDQpzeXMgMS4xMg0KDQpEb25lIGNvbXBpbGluZyAvc2NyYXRjaC93ZG4vb2JqXzQu
MC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMvaW5jbHVkZS9EZW1vUENI
Lm8NCg0KQ09NUElMSU5HLi4uIFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVY
X0tDQ19DQVJUX1hZWl9NUEkvbWFpbi5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3NjcmF0Y2gv
d2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL21haW4uY2MgLW8gL3Nj
cmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL21haW4ubyAt
LW91dHB1dF9kZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9L
Q0NfQ0FSVF9YWVpfTVBJL21haW4uby5kZXBlbmQubWsudGVtcCAtLWRpYWdfc3VwcHJlc3Mg
NjMwIC0tQ09NUERPX2ZlX2NjMmMgLS1wY2hfaWdub3JlX2RpciAtLXVzZV9wY2ggL3NjcmF0
Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RFTU9fTVBJMS5w
Y2ggLURURUNfVVNFX0RFTU8gLURURUNfVVNFX1BIWVNJQ1NCRVRBIC1EVEVDX1VTRV9IWURS
T0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEgLURURUNfVVNFX1BIWVNJ
Q1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0VfUE9PTUEySU5URUdSQVRJT04gLURURUNfVVNFX1RF
Q0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9PTUEgLURURUNfVVNFX0NIRUVUQUggLURURUNfVVNF
X01NIC1EVEVDX1VTRV9QQ0cgLURURUNfTElOVVggLURURUNfSU5TVCAtRFRFQ19VU0VfUENI
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9BcHBsaWNh
dGlvbnNMYXllci9EZW1vIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5bmFtaWNzIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3Vw
cG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vz
ci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzQmFzZUNs
YXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1Rl
Y0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3Byb2plY3RzL2Js
YW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNr
YWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9v
bWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNyL3Byb2plY3Rz
L2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJTlVYX0tDQ19E
RUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRlIC1JL3Vzci9w
cm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91c3IvcHJvamVj
dHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJvcl9udW1iZXIg
LWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHByZXNzIDQ1MCAr
SzANCg0KcmVhbCAxLjUyDQp1c2VyIDAuOTINCnN5cyAwLjE3DQoNCkRvbmUgY29tcGlsaW5n
IC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9tYWlu
Lm8NCg0KQ09NUElMSU5HLi4uIFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVY
X0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMvRGVtb0FwcEdyb3VwLm9fTVBJMS5pbmZvDQoN
CktDQyAtYyAvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL0Fw
cGxpY2F0aW9uc0xheWVyL0RlbW8vRGVtb19zcmMvRGVtb0FwcEdyb3VwLmNjIC1vIC9zY3Jh
dGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9E
ZW1vQXBwR3JvdXAubyAtLW91dHB1dF9kZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80
LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3JjL0RlbW9BcHBHcm91cC5v
LmRlcGVuZC5tay50ZW1wIC0tZGlhZ19zdXBwcmVzcyA2MzAgLS1DT01QRE9fZmVfY2MyYyAt
LXBjaF9pZ25vcmVfZGlyIC0tdXNlX3BjaCAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJ
TlVYX0tDQ19DQVJUX1hZWl9NUEkvREVNT19NUEkxLnBjaCAtRFRFQ19VU0VfREVNTyAtRFRF
Q19VU0VfUEhZU0lDU0JFVEEgLURURUNfVVNFX0hZRFJPRFlOQU1JQ1MgLURURUNfVVNFX1BI
WVNJQ1NTVVBQT1JUQkVUQSAtRFRFQ19VU0VfUEhZU0lDU0JBU0VDTEFTU0VTIC1EVEVDX1VT
RV9QT09NQTJJTlRFR1JBVElPTiAtRFRFQ19VU0VfVEVDRlJBTUVXT1JLIC1EVEVDX1VTRV9Q
T09NQSAtRFRFQ19VU0VfQ0hFRVRBSCAtRFRFQ19VU0VfTU0gLURURUNfVVNFX1BDRyAtRFRF
Q19MSU5VWCAtRFRFQ19JTlNUIC1EVEVDX1VTRV9QQ0ggLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL0FwcGxpY2F0aW9uc0xheWVyL0RlbW8gLUkvdXNy
L3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9Q
aHlzaWNzQmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180
LjAvUGh5c2ljc0xheWVyL0h5ZHJvZHluYW1pY3MgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91
c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc1N1cHBv
cnRCZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9Q
aHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NCYXNlQ2xhc3NlcyAtSS91c3IvcHJvamVjdHMv
YmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvVGVjSW50ZWdyYXRpb25MYXllci9Qb29t
YTJJbnRlZ3JhdGlvbiAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1RlY0ZyYW1l
d29yayAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9zcmMgLUkv
dXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvbGliL0xJTlVYX0tDQ19E
RUJVR19DSEVFVEFIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9j
aGVldGFoLTEuMC4wL3NyYyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0
YWgvY2hlZXRhaC0xLjAuMC9saWIvTElOVVhfS0NDX0RFQlVHIC1JL2hvbWUvd2RuL3BhY2th
Z2VzL21waWNoLTEuMi4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdl
cy9tbS0xLjEuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvcGNn
L3BjZ19mNzcgLS1kaXNwbGF5X2Vycm9yX251bWJlciAtZnBpYyAtayAtLXN0cmljdCAtRF9f
S0FJX1NUUklDVCAtLWRpYWdfc3VwcHJlc3MgNDUwICtLMA0KDQpyZWFsIDAuNzENCnVzZXIg
MC4yNA0Kc3lzIDAuMDQNCg0KRG9uZSBjb21waWxpbmcgL3NjcmF0Y2gvd2RuL29ial80LjAv
REVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3JjL0RlbW9BcHBHcm91cC5vDQoN
CkNPTVBJTElORy4uLiBTZWUgL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0Nf
Q0FSVF9YWVpfTVBJL0RlbW9fc3JjL0RlbW9Hcm91cC5vX01QSTEuaW5mbw0KDQpLQ0MgLWMg
L3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9BcHBsaWNhdGlv
bnNMYXllci9EZW1vL0RlbW9fc3JjL0RlbW9Hcm91cC5jYyAtbyAvc2NyYXRjaC93ZG4vb2Jq
XzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMvRGVtb0dyb3VwLm8g
LS1vdXRwdXRfZGVwZW5kZW5jaWVzIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhf
S0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9EZW1vR3JvdXAuby5kZXBlbmQubWsudGVtcCAt
LWRpYWdfc3VwcHJlc3MgNjMwIC0tQ09NUERPX2ZlX2NjMmMgLS1wY2hfaWdub3JlX2RpciAt
LXVzZV9wY2ggL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpf
TVBJL0RFTU9fTVBJMS5wY2ggLURURUNfVVNFX0RFTU8gLURURUNfVVNFX1BIWVNJQ1NCRVRB
IC1EVEVDX1VTRV9IWURST0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEg
LURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0VfUE9PTUEySU5URUdSQVRJ
T04gLURURUNfVVNFX1RFQ0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9PTUEgLURURUNfVVNFX0NI
RUVUQUggLURURUNfVVNFX01NIC1EVEVDX1VTRV9QQ0cgLURURUNfTElOVVggLURURUNfSU5T
VCAtRFRFQ19VU0VfUENIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9BcHBsaWNhdGlvbnNMYXllci9EZW1vIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2Ev
dXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNy
L3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9I
eWRyb2R5bmFtaWNzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3Jj
XzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91c3IvcHJv
amVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXll
ci9QaHlzaWNzQmFzZUNsYXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2Js
YW5jYV9zcmNfNC4wL1RlY0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkv
dXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2pl
Y3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFu
Y2EvcGFja2FnZXMvUG9vbWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMg
LUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAv
bGliL0xJTlVYX0tDQ19ERUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGljaC0xLjIuMS9p
bmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4xLjEvaW5jbHVk
ZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxh
eV9lcnJvcl9udW1iZXIgLWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFn
X3N1cHByZXNzIDQ1MCArSzANCg0KcmVhbCAwLjcxDQp1c2VyIDAuMjQNCnN5cyAwLjAyDQoN
CkRvbmUgY29tcGlsaW5nIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NB
UlRfWFlaX01QSS9EZW1vX3NyYy9EZW1vR3JvdXAubw0KDQpDT01QSUxJTkcuLi4gU2VlIC9z
Y3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9EZW1vX3Ny
Yy9Nb2RlbC9BZGRNb2RlbFR1dG9yaWFsL1NpbXBsZU1vZGVsLm9fTVBJMS5pbmZvDQoNCktD
QyAtYyAvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL0FwcGxp
Y2F0aW9uc0xheWVyL0RlbW8vRGVtb19zcmMvTW9kZWwvQWRkTW9kZWxUdXRvcmlhbC9TaW1w
bGVNb2RlbC5jYyAtbyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJU
X1hZWl9NUEkvRGVtb19zcmMvTW9kZWwvQWRkTW9kZWxUdXRvcmlhbC9TaW1wbGVNb2RlbC5v
IC0tb3V0cHV0X2RlcGVuZGVuY2llcyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVY
X0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMvTW9kZWwvQWRkTW9kZWxUdXRvcmlhbC9TaW1w
bGVNb2RlbC5vLmRlcGVuZC5tay50ZW1wIC0tZGlhZ19zdXBwcmVzcyA2MzAgLS1DT01QRE9f
ZmVfY2MyYyAtLXBjaF9pZ25vcmVfZGlyIC0tdXNlX3BjaCAvc2NyYXRjaC93ZG4vb2JqXzQu
MC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvREVNT19NUEkxLnBjaCAtRFRFQ19VU0Vf
REVNTyAtRFRFQ19VU0VfUEhZU0lDU0JFVEEgLURURUNfVVNFX0hZRFJPRFlOQU1JQ1MgLURU
RUNfVVNFX1BIWVNJQ1NTVVBQT1JUQkVUQSAtRFRFQ19VU0VfUEhZU0lDU0JBU0VDTEFTU0VT
IC1EVEVDX1VTRV9QT09NQTJJTlRFR1JBVElPTiAtRFRFQ19VU0VfVEVDRlJBTUVXT1JLIC1E
VEVDX1VTRV9QT09NQSAtRFRFQ19VU0VfQ0hFRVRBSCAtRFRFQ19VU0VfTU0gLURURUNfVVNF
X1BDRyAtRFRFQ19MSU5VWCAtRFRFQ19JTlNUIC1EVEVDX1VTRV9QQ0ggLUkvdXNyL3Byb2pl
Y3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL0FwcGxpY2F0aW9uc0xheWVyL0Rl
bW8gLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNp
Y3NMYXllci9QaHlzaWNzQmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxh
bmNhX3NyY180LjAvUGh5c2ljc0xheWVyL0h5ZHJvZHluYW1pY3MgLUkvdXNyL3Byb2plY3Rz
L2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5
c2ljc1N1cHBvcnRCZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NCYXNlQ2xhc3NlcyAtSS91c3Iv
cHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvVGVjSW50ZWdyYXRpb25M
YXllci9Qb29tYTJJbnRlZ3JhdGlvbiAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2Vz
L1RlY0ZyYW1ld29yayAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9y
Mi9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvbGliL0xJ
TlVYX0tDQ19ERUJVR19DSEVFVEFIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMv
Q2hlZXRhaC9jaGVldGFoLTEuMC4wL3NyYyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2th
Z2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9saWIvTElOVVhfS0NDX0RFQlVHIC1JL2hvbWUv
d2RuL3BhY2thZ2VzL21waWNoLTEuMi4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS9wYWNrYWdlcy9tbS0xLjEuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFj
a2FnZXMvcGNnL3BjZ19mNzcgLS1kaXNwbGF5X2Vycm9yX251bWJlciAtZnBpYyAtayAtLXN0
cmljdCAtRF9fS0FJX1NUUklDVCAtLWRpYWdfc3VwcHJlc3MgNDUwICtLMA0KDQpyZWFsIDEx
Ljk5DQp1c2VyIDEwLjA2DQpzeXMgMS4wNQ0KDQpEb25lIGNvbXBpbGluZyAvc2NyYXRjaC93
ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMvTW9kZWwv
QWRkTW9kZWxUdXRvcmlhbC9TaW1wbGVNb2RlbC5vDQoNCkNPTVBJTElORy4uLiBTZWUgL3Nj
cmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3Jj
L01vZGVsL0J1cmdlci9CdXJnZXIub19NUEkxLmluZm8NCg0KS0NDIC1jIC91c3IvcHJvamVj
dHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvQXBwbGljYXRpb25zTGF5ZXIvRGVt
by9EZW1vX3NyYy9Nb2RlbC9CdXJnZXIvQnVyZ2VyLmNjIC1vIC9zY3JhdGNoL3dkbi9vYmpf
NC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9Nb2RlbC9CdXJnZXIv
QnVyZ2VyLm8gLS1vdXRwdXRfZGVwZW5kZW5jaWVzIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RF
TU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9Nb2RlbC9CdXJnZXIvQnVyZ2Vy
Lm8uZGVwZW5kLm1rLnRlbXAgLS1kaWFnX3N1cHByZXNzIDYzMCAtLUNPTVBET19mZV9jYzJj
IC0tcGNoX2lnbm9yZV9kaXIgLS11c2VfcGNoIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8v
TElOVVhfS0NDX0NBUlRfWFlaX01QSS9ERU1PX01QSTEucGNoIC1EVEVDX1VTRV9ERU1PIC1E
VEVDX1VTRV9QSFlTSUNTQkVUQSAtRFRFQ19VU0VfSFlEUk9EWU5BTUlDUyAtRFRFQ19VU0Vf
UEhZU0lDU1NVUFBPUlRCRVRBIC1EVEVDX1VTRV9QSFlTSUNTQkFTRUNMQVNTRVMgLURURUNf
VVNFX1BPT01BMklOVEVHUkFUSU9OIC1EVEVDX1VTRV9URUNGUkFNRVdPUksgLURURUNfVVNF
X1BPT01BIC1EVEVDX1VTRV9DSEVFVEFIIC1EVEVDX1VTRV9NTSAtRFRFQ19VU0VfUENHIC1E
VEVDX0xJTlVYIC1EVEVDX0lOU1QgLURURUNfVVNFX1BDSCAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvQXBwbGljYXRpb25zTGF5ZXIvRGVtbyAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVy
L1BoeXNpY3NCZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3Jj
XzQuMC9QaHlzaWNzTGF5ZXIvSHlkcm9keW5hbWljcyAtSS91c3IvcHJvamVjdHMvYmxhbmNh
L3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzU3Vw
cG9ydEJldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4w
L1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc0Jhc2VDbGFzc2VzIC1JL3Vzci9wcm9qZWN0
cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9UZWNJbnRlZ3JhdGlvbkxheWVyL1Bv
b21hMkludGVncmF0aW9uIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvVGVjRnJh
bWV3b3JrIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL3NyYyAt
SS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9saWIvTElOVVhfS0ND
X0RFQlVHX0NIRUVUQUggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFo
L2NoZWV0YWgtMS4wLjAvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hl
ZXRhaC9jaGVldGFoLTEuMC4wL2xpYi9MSU5VWF9LQ0NfREVCVUcgLUkvaG9tZS93ZG4vcGFj
a2FnZXMvbXBpY2gtMS4yLjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2th
Z2VzL21tLTEuMS4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9w
Y2cvcGNnX2Y3NyAtLWRpc3BsYXlfZXJyb3JfbnVtYmVyIC1mcGljIC1rIC0tc3RyaWN0IC1E
X19LQUlfU1RSSUNUIC0tZGlhZ19zdXBwcmVzcyA0NTAgK0swDQoNCnJlYWwgMjguNjQNCnVz
ZXIgMjQuMTcNCnN5cyAxLjczDQoNCkRvbmUgY29tcGlsaW5nIC9zY3JhdGNoL3dkbi9vYmpf
NC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9Nb2RlbC9CdXJnZXIv
QnVyZ2VyLm8NCg0KQ09NUElMSU5HLi4uIFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1P
L0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMvTW9kZWwvRGlmZnVzaW9uL0RpZmZ1
c2lvbi5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dk
bi9ibGFuY2Ffc3JjXzQuMC9BcHBsaWNhdGlvbnNMYXllci9EZW1vL0RlbW9fc3JjL01vZGVs
L0RpZmZ1c2lvbi9EaWZmdXNpb24uY2MgLW8gL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9M
SU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3JjL01vZGVsL0RpZmZ1c2lvbi9EaWZmdXNp
b24ubyAtLW91dHB1dF9kZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9M
SU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3JjL01vZGVsL0RpZmZ1c2lvbi9EaWZmdXNp
b24uby5kZXBlbmQubWsudGVtcCAtLWRpYWdfc3VwcHJlc3MgNjMwIC0tQ09NUERPX2ZlX2Nj
MmMgLS1wY2hfaWdub3JlX2RpciAtLXVzZV9wY2ggL3NjcmF0Y2gvd2RuL29ial80LjAvREVN
Ty9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RFTU9fTVBJMS5wY2ggLURURUNfVVNFX0RFTU8g
LURURUNfVVNFX1BIWVNJQ1NCRVRBIC1EVEVDX1VTRV9IWURST0RZTkFNSUNTIC1EVEVDX1VT
RV9QSFlTSUNTU1VQUE9SVEJFVEEgLURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xBU1NFUyAtRFRF
Q19VU0VfUE9PTUEySU5URUdSQVRJT04gLURURUNfVVNFX1RFQ0ZSQU1FV09SSyAtRFRFQ19V
U0VfUE9PTUEgLURURUNfVVNFX0NIRUVUQUggLURURUNfVVNFX01NIC1EVEVDX1VTRV9QQ0cg
LURURUNfTElOVVggLURURUNfSU5TVCAtRFRFQ19VU0VfUENIIC1JL3Vzci9wcm9qZWN0cy9i
bGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9BcHBsaWNhdGlvbnNMYXllci9EZW1vIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5
ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9z
cmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5bmFtaWNzIC1JL3Vzci9wcm9qZWN0cy9ibGFu
Y2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NT
dXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180
LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzQmFzZUNsYXNzZXMgLUkvdXNyL3Byb2pl
Y3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1RlY0ludGVncmF0aW9uTGF5ZXIv
UG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9UZWNG
cmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvc3Jj
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL2xpYi9MSU5VWF9L
Q0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0
YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9D
aGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJTlVYX0tDQ19ERUJVRyAtSS9ob21lL3dkbi9w
YWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFj
a2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2Vz
L3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJvcl9udW1iZXIgLWZwaWMgLWsgLS1zdHJpY3Qg
LURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHByZXNzIDQ1MCArSzANCg0KcmVhbCAyNC40NA0K
dXNlciAyMS42NA0Kc3lzIDEuNTMNCg0KRG9uZSBjb21waWxpbmcgL3NjcmF0Y2gvd2RuL29i
al80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3JjL01vZGVsL0RpZmZ1
c2lvbi9EaWZmdXNpb24ubw0KDQpDT01QSUxJTkcuLi4gU2VlIC9zY3JhdGNoL3dkbi9vYmpf
NC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9Nb2RlbC9MYXhXZW5k
cm9mZi9MYXhXZW5kcm9mZi5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9i
bGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9BcHBsaWNhdGlvbnNMYXllci9EZW1vL0Rl
bW9fc3JjL01vZGVsL0xheFdlbmRyb2ZmL0xheFdlbmRyb2ZmLmNjIC1vIC9zY3JhdGNoL3dk
bi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFlaX01QSS9EZW1vX3NyYy9Nb2RlbC9M
YXhXZW5kcm9mZi9MYXhXZW5kcm9mZi5vIC0tb3V0cHV0X2RlcGVuZGVuY2llcyAvc2NyYXRj
aC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMvTW9k
ZWwvTGF4V2VuZHJvZmYvTGF4V2VuZHJvZmYuby5kZXBlbmQubWsudGVtcCAtLWRpYWdfc3Vw
cHJlc3MgNjMwIC0tQ09NUERPX2ZlX2NjMmMgLS1wY2hfaWdub3JlX2RpciAtLXVzZV9wY2gg
L3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RFTU9f
TVBJMS5wY2ggLURURUNfVVNFX0RFTU8gLURURUNfVVNFX1BIWVNJQ1NCRVRBIC1EVEVDX1VT
RV9IWURST0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEgLURURUNfVVNF
X1BIWVNJQ1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0VfUE9PTUEySU5URUdSQVRJT04gLURURUNf
VVNFX1RFQ0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9PTUEgLURURUNfVVNFX0NIRUVUQUggLURU
RUNfVVNFX01NIC1EVEVDX1VTRV9QQ0cgLURURUNfTElOVVggLURURUNfSU5TVCAtRFRFQ19V
U0VfUENIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9B
cHBsaWNhdGlvbnNMYXllci9EZW1vIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9i
bGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2plY3Rz
L2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5bmFt
aWNzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlz
aWNzU3VwcG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNz
QmFzZUNsYXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNf
NC4wL1RlY0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3Byb2pl
Y3RzL2JsYW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS9wYWNrYWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2Fn
ZXMvUG9vbWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJvamVj
dHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNyL3By
b2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJTlVY
X0tDQ19ERUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRlIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91c3Iv
cHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJvcl9u
dW1iZXIgLWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHByZXNz
IDQ1MCArSzANCg0KcmVhbCA0NS4wNQ0KdXNlciA0MC42MQ0Kc3lzIDIuOTINCg0KRG9uZSBj
b21waWxpbmcgL3NjcmF0Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpf
TVBJL0RlbW9fc3JjL01vZGVsL0xheFdlbmRyb2ZmL0xheFdlbmRyb2ZmLm8NCg0KQ09NUElM
SU5HLi4uIFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQuMC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZ
Wl9NUEkvRGVtb19zcmMvTW9kZWwvTGF4V2VuZHJvZmYvTGF4V2VuZHJvZmZSZWxhdGlvbnMu
b19NUEkxLmluZm8NCg0KS0NDIC1jIC91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxh
bmNhX3NyY180LjAvQXBwbGljYXRpb25zTGF5ZXIvRGVtby9EZW1vX3NyYy9Nb2RlbC9MYXhX
ZW5kcm9mZi9MYXhXZW5kcm9mZlJlbGF0aW9ucy5jYyAtbyAvc2NyYXRjaC93ZG4vb2JqXzQu
MC9ERU1PL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvRGVtb19zcmMvTW9kZWwvTGF4V2VuZHJv
ZmYvTGF4V2VuZHJvZmZSZWxhdGlvbnMubyAtLW91dHB1dF9kZXBlbmRlbmNpZXMgL3NjcmF0
Y2gvd2RuL29ial80LjAvREVNTy9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL0RlbW9fc3JjL01v
ZGVsL0xheFdlbmRyb2ZmL0xheFdlbmRyb2ZmUmVsYXRpb25zLm8uZGVwZW5kLm1rLnRlbXAg
LS1kaWFnX3N1cHByZXNzIDYzMCAtLUNPTVBET19mZV9jYzJjIC0tcGNoX2lnbm9yZV9kaXIg
LS11c2VfcGNoIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0NDX0NBUlRfWFla
X01QSS9ERU1PX01QSTEucGNoIC1EVEVDX1VTRV9ERU1PIC1EVEVDX1VTRV9QSFlTSUNTQkVU
QSAtRFRFQ19VU0VfSFlEUk9EWU5BTUlDUyAtRFRFQ19VU0VfUEhZU0lDU1NVUFBPUlRCRVRB
IC1EVEVDX1VTRV9QSFlTSUNTQkFTRUNMQVNTRVMgLURURUNfVVNFX1BPT01BMklOVEVHUkFU
SU9OIC1EVEVDX1VTRV9URUNGUkFNRVdPUksgLURURUNfVVNFX1BPT01BIC1EVEVDX1VTRV9D
SEVFVEFIIC1EVEVDX1VTRV9NTSAtRFRFQ19VU0VfUENHIC1EVEVDX0xJTlVYIC1EVEVDX0lO
U1QgLURURUNfVVNFX1BDSCAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNh
X3NyY180LjAvQXBwbGljYXRpb25zTGF5ZXIvRGVtbyAtSS91c3IvcHJvamVjdHMvYmxhbmNh
L3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhIC1JL3Vz
ci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIv
SHlkcm9keW5hbWljcyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3Ny
Y180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzU3VwcG9ydEJldGEgLUkvdXNyL3By
b2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0TGF5
ZXIvUGh5c2ljc0Jhc2VDbGFzc2VzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9i
bGFuY2Ffc3JjXzQuMC9UZWNJbnRlZ3JhdGlvbkxheWVyL1Bvb21hMkludGVncmF0aW9uIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvVGVjRnJhbWV3b3JrIC1JL3Vzci9wcm9q
ZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL3NyYyAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9saWIvTElOVVhfS0NDX0RFQlVHX0NIRUVUQUggLUkv
dXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvc3Jj
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFoLTEuMC4w
L2xpYi9MSU5VWF9LQ0NfREVCVUcgLUkvaG9tZS93ZG4vcGFja2FnZXMvbXBpY2gtMS4yLjEv
aW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL21tLTEuMS4xL2luY2x1
ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9wY2cvcGNnX2Y3NyAtLWRpc3Bs
YXlfZXJyb3JfbnVtYmVyIC1mcGljIC1rIC0tc3RyaWN0IC1EX19LQUlfU1RSSUNUIC0tZGlh
Z19zdXBwcmVzcyA0NTAgK0swDQoNCnJlYWwgMzYuNTkNCnVzZXIgMzIuMzgNCnN5cyAyLjQy
DQoNCkRvbmUgY29tcGlsaW5nIC9zY3JhdGNoL3dkbi9vYmpfNC4wL0RFTU8vTElOVVhfS0ND
X0NBUlRfWFlaX01QSS9EZW1vX3NyYy9Nb2RlbC9MYXhXZW5kcm9mZi9MYXhXZW5kcm9mZlJl
bGF0aW9ucy5vDQoNCkNPTVBJTElORy4uLiBTZWUgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZ
U0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvaW5jbHVk
ZS9QaHlzaWNzQmV0YVBDSC5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9i
bGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEv
UGh5c2ljc0JldGFfc3JjL2luY2x1ZGUvUGh5c2ljc0JldGFQQ0guY2MgLW8gL3NjcmF0Y2gv
d2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNz
QmV0YV9zcmMvaW5jbHVkZS9QaHlzaWNzQmV0YVBDSC5vIC0tb3V0cHV0X2RlcGVuZGVuY2ll
cyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpf
TVBJL1BoeXNpY3NCZXRhX3NyYy9pbmNsdWRlL1BoeXNpY3NCZXRhUENILm8uZGVwZW5kLm1r
LnRlbXAgLS1kaWFnX3N1cHByZXNzIDYzMCAtLWNyZWF0ZV9wY2ggL3NjcmF0Y2gvd2RuL29i
al80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QSFlTSUNTQkVUQV9N
UEkxLnBjaCAtRFRFQ19VU0VfUEhZU0lDU0JFVEEgLURURUNfVVNFX0hZRFJPRFlOQU1JQ1Mg
LURURUNfVVNFX1BIWVNJQ1NTVVBQT1JUQkVUQSAtRFRFQ19VU0VfUEhZU0lDU0JBU0VDTEFT
U0VTIC1EVEVDX1VTRV9QT09NQTJJTlRFR1JBVElPTiAtRFRFQ19VU0VfVEVDRlJBTUVXT1JL
IC1EVEVDX1VTRV9QT09NQSAtRFRFQ19VU0VfQ0hFRVRBSCAtRFRFQ19VU0VfTU0gLURURUNf
VVNFX1BDRyAtRFRFQ19MSU5VWCAtRFRFQ19JTlNUIC1EVEVDX1VTRV9QQ0ggLUkvdXNyL3By
b2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlz
aWNzQmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAv
UGh5c2ljc0xheWVyL0h5ZHJvZHluYW1pY3MgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Iv
d2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc1N1cHBvcnRC
ZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlz
aWNzU3VwcG9ydExheWVyL1BoeXNpY3NCYXNlQ2xhc3NlcyAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvVGVjSW50ZWdyYXRpb25MYXllci9Qb29tYTJJ
bnRlZ3JhdGlvbiAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1RlY0ZyYW1ld29y
ayAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9zcmMgLUkvdXNy
L3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvbGliL0xJTlVYX0tDQ19ERUJV
R19DSEVFVEFIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVl
dGFoLTEuMC4wL3NyYyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgv
Y2hlZXRhaC0xLjAuMC9saWIvTElOVVhfS0NDX0RFQlVHIC1JL2hvbWUvd2RuL3BhY2thZ2Vz
L21waWNoLTEuMi4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9t
bS0xLjEuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvcGNnL3Bj
Z19mNzcgLS1kaXNwbGF5X2Vycm9yX251bWJlciAtZnBpYyAtayAtLXN0cmljdCAtRF9fS0FJ
X1NUUklDVCAtLWRpYWdfc3VwcHJlc3MgNDUwICtLMA0KDQoiL3Vzci9wcm9qZWN0cy9ibGFu
Y2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5
c2ljc0JldGFfc3JjL2luY2x1ZGUvUGh5c2ljc0JldGFQQ0guY2MiOiBjcmVhdGluZyBwcmVj
b21waWxlZCBoZWFkZXIgZmlsZSAiL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEv
TElOVVhfS0NDX0NBUlRfWFlaX01QSS9QSFlTSUNTQkVUQV9NUEkxLnBjaCINCnJlYWwgOC44
MQ0KdXNlciA2LjM4DQpzeXMgMS4zMg0KDQpEb25lIGNvbXBpbGluZyAvc2NyYXRjaC93ZG4v
b2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRh
X3NyYy9pbmNsdWRlL1BoeXNpY3NCZXRhUENILm8NCg0KQ09NUElMSU5HLi4uIFNlZSAvc2Ny
YXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1Bo
eXNpY3NCZXRhX3NyYy9QaHlzaWNzQmV0YUdyb3VwLm9fTVBJMS5pbmZvDQoNCktDQyAtYyAv
dXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXll
ci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMvUGh5c2ljc0JldGFHcm91cC5jYyAtbyAv
c2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJ
L1BoeXNpY3NCZXRhX3NyYy9QaHlzaWNzQmV0YUdyb3VwLm8gLS1vdXRwdXRfZGVwZW5kZW5j
aWVzIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZ
Wl9NUEkvUGh5c2ljc0JldGFfc3JjL1BoeXNpY3NCZXRhR3JvdXAuby5kZXBlbmQubWsudGVt
cCAtLWRpYWdfc3VwcHJlc3MgNjMwIC0tQ09NUERPX2ZlX2NjMmMgLS1wY2hfaWdub3JlX2Rp
ciAtLXVzZV9wY2ggL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0ND
X0NBUlRfWFlaX01QSS9QSFlTSUNTQkVUQV9NUEkxLnBjaCAtRFRFQ19VU0VfUEhZU0lDU0JF
VEEgLURURUNfVVNFX0hZRFJPRFlOQU1JQ1MgLURURUNfVVNFX1BIWVNJQ1NTVVBQT1JUQkVU
QSAtRFRFQ19VU0VfUEhZU0lDU0JBU0VDTEFTU0VTIC1EVEVDX1VTRV9QT09NQTJJTlRFR1JB
VElPTiAtRFRFQ19VU0VfVEVDRlJBTUVXT1JLIC1EVEVDX1VTRV9QT09NQSAtRFRFQ19VU0Vf
Q0hFRVRBSCAtRFRFQ19VU0VfTU0gLURURUNfVVNFX1BDRyAtRFRFQ19MSU5VWCAtRFRFQ19J
TlNUIC1EVEVDX1VTRV9QQ0ggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5j
YV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YSAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL0h5ZHJvZHluYW1pY3Mg
LUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NT
dXBwb3J0TGF5ZXIvUGh5c2ljc1N1cHBvcnRCZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2Ev
dXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NCYXNl
Q2xhc3NlcyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAv
VGVjSW50ZWdyYXRpb25MYXllci9Qb29tYTJJbnRlZ3JhdGlvbiAtSS91c3IvcHJvamVjdHMv
YmxhbmNhL3BhY2thZ2VzL1RlY0ZyYW1ld29yayAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Bh
Y2thZ2VzL1Bvb21hMi9yMi9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Q
b29tYTIvcjIvbGliL0xJTlVYX0tDQ19ERUJVR19DSEVFVEFIIC1JL3Vzci9wcm9qZWN0cy9i
bGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFoLTEuMC4wL3NyYyAtSS91c3IvcHJvamVj
dHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9saWIvTElOVVhfS0ND
X0RFQlVHIC1JL2hvbWUvd2RuL3BhY2thZ2VzL21waWNoLTEuMi4xL2luY2x1ZGUgLUkvdXNy
L3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9tbS0xLjEuMS9pbmNsdWRlIC1JL3Vzci9wcm9q
ZWN0cy9ibGFuY2EvcGFja2FnZXMvcGNnL3BjZ19mNzcgLS1kaXNwbGF5X2Vycm9yX251bWJl
ciAtZnBpYyAtayAtLXN0cmljdCAtRF9fS0FJX1NUUklDVCAtLWRpYWdfc3VwcHJlc3MgNDUw
ICtLMA0KDQpyZWFsIDAuNzMNCnVzZXIgMC4yMw0Kc3lzIDAuMDQNCg0KRG9uZSBjb21waWxp
bmcgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFla
X01QSS9QaHlzaWNzQmV0YV9zcmMvUGh5c2ljc0JldGFHcm91cC5vDQoNCkNPTVBJTElORy4u
LiBTZWUgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRf
WFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvQW5hbHl0aWNPcGFjaXR5L0FuYWx5dGljT3BhY2l0
eVJlbGF0aW9ucy5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9ibGFuY2Ev
dXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2lj
c0JldGFfc3JjL0FuYWx5dGljT3BhY2l0eS9BbmFseXRpY09wYWNpdHlSZWxhdGlvbnMuY2Mg
LW8gL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFla
X01QSS9QaHlzaWNzQmV0YV9zcmMvQW5hbHl0aWNPcGFjaXR5L0FuYWx5dGljT3BhY2l0eVJl
bGF0aW9ucy5vIC0tb3V0cHV0X2RlcGVuZGVuY2llcyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9Q
SFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9BbmFs
eXRpY09wYWNpdHkvQW5hbHl0aWNPcGFjaXR5UmVsYXRpb25zLm8uZGVwZW5kLm1rLnRlbXAg
LS1kaWFnX3N1cHByZXNzIDYzMCAtLUNPTVBET19mZV9jYzJjIC0tcGNoX2lnbm9yZV9kaXIg
LS11c2VfcGNoIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19D
QVJUX1hZWl9NUEkvUEhZU0lDU0JFVEFfTVBJMS5wY2ggLURURUNfVVNFX1BIWVNJQ1NCRVRB
IC1EVEVDX1VTRV9IWURST0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEg
LURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0VfUE9PTUEySU5URUdSQVRJ
T04gLURURUNfVVNFX1RFQ0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9PTUEgLURURUNfVVNFX0NI
RUVUQUggLURURUNfVVNFX01NIC1EVEVDX1VTRV9QQ0cgLURURUNfTElOVVggLURURUNfSU5T
VCAtRFRFQ19VU0VfUENIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5bmFtaWNzIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3Vw
cG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vz
ci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzQmFzZUNs
YXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1Rl
Y0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3Byb2plY3RzL2Js
YW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNr
YWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9v
bWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNyL3Byb2plY3Rz
L2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJTlVYX0tDQ19E
RUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRlIC1JL3Vzci9w
cm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91c3IvcHJvamVj
dHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJvcl9udW1iZXIg
LWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHByZXNzIDQ1MCAr
SzANCg0KcmVhbCA4LjU2DQp1c2VyIDcuMDENCnN5cyAxLjAxDQoNCkRvbmUgY29tcGlsaW5n
IC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9N
UEkvUGh5c2ljc0JldGFfc3JjL0FuYWx5dGljT3BhY2l0eS9BbmFseXRpY09wYWNpdHlSZWxh
dGlvbnMubw0KDQpDT01QSUxJTkcuLi4gU2VlIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJ
Q1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFs
TWV0aG9kcy9JTVJlbGF0aW9ucy5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0
cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0Jl
dGEvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9JTVJlbGF0aW9ucy5jYyAtbyAv
c2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJ
L1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvSU1SZWxhdGlvbnMubyAtLW91dHB1
dF9kZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhf
S0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0lNUmVs
YXRpb25zLm8uZGVwZW5kLm1rLnRlbXAgLS1kaWFnX3N1cHByZXNzIDYzMCAtLUNPTVBET19m
ZV9jYzJjIC0tcGNoX2lnbm9yZV9kaXIgLS11c2VfcGNoIC9zY3JhdGNoL3dkbi9vYmpfNC4w
L1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUEhZU0lDU0JFVEFfTVBJMS5w
Y2ggLURURUNfVVNFX1BIWVNJQ1NCRVRBIC1EVEVDX1VTRV9IWURST0RZTkFNSUNTIC1EVEVD
X1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEgLURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xBU1NFUyAt
RFRFQ19VU0VfUE9PTUEySU5URUdSQVRJT04gLURURUNfVVNFX1RFQ0ZSQU1FV09SSyAtRFRF
Q19VU0VfUE9PTUEgLURURUNfVVNFX0NIRUVUQUggLURURUNfVVNFX01NIC1EVEVDX1VTRV9Q
Q0cgLURURUNfTElOVVggLURURUNfSU5TVCAtRFRFQ19VU0VfUENIIC1JL3Vzci9wcm9qZWN0
cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0Jl
dGEgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNp
Y3NMYXllci9IeWRyb2R5bmFtaWNzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9i
bGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAt
SS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1
cHBvcnRMYXllci9QaHlzaWNzQmFzZUNsYXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91
c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1RlY0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdy
YXRpb24gLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkv
dXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9q
ZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hF
RVRBSCAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0x
LjAuMC9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0
YWgtMS4wLjAvbGliL0xJTlVYX0tDQ19ERUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGlj
aC0xLjIuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4x
LjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3
IC0tZGlzcGxheV9lcnJvcl9udW1iZXIgLWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJ
Q1QgLS1kaWFnX3N1cHByZXNzIDQ1MCArSzANCg0KcmVhbCAzOS4xMA0KdXNlciAzNS4zNg0K
c3lzIDIuNDMNCg0KRG9uZSBjb21waWxpbmcgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lD
U0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxN
ZXRob2RzL0lNUmVsYXRpb25zLm8NCg0KQ09NUElMSU5HLi4uIFNlZSAvc2NyYXRjaC93ZG4v
b2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRh
X3NyYy9JbnRlZ3JhbE1ldGhvZHMvU3ltbWV0cnlSZWxhdGlvbnMyRC5vX01QSTEuaW5mbw0K
DQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9Q
aHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9k
cy9TeW1tZXRyeVJlbGF0aW9uczJELmNjIC1vIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJ
Q1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFs
TWV0aG9kcy9TeW1tZXRyeVJlbGF0aW9uczJELm8gLS1vdXRwdXRfZGVwZW5kZW5jaWVzIC9z
Y3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkv
UGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9TeW1tZXRyeVJlbGF0aW9uczJELm8u
ZGVwZW5kLm1rLnRlbXAgLS1kaWFnX3N1cHByZXNzIDYzMCAtLUNPTVBET19mZV9jYzJjIC0t
cGNoX2lnbm9yZV9kaXIgLS11c2VfcGNoIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NC
RVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUEhZU0lDU0JFVEFfTVBJMS5wY2ggLURURUNf
VVNFX1BIWVNJQ1NCRVRBIC1EVEVDX1VTRV9IWURST0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlT
SUNTU1VQUE9SVEJFVEEgLURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0Vf
UE9PTUEySU5URUdSQVRJT04gLURURUNfVVNFX1RFQ0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9P
TUEgLURURUNfVVNFX0NIRUVUQUggLURURUNfVVNFX01NIC1EVEVDX1VTRV9QQ0cgLURURUNf
TElOVVggLURURUNfSU5TVCAtRFRFQ19VU0VfUENIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2Ev
dXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNy
L3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9I
eWRyb2R5bmFtaWNzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3Jj
XzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91c3IvcHJv
amVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXll
ci9QaHlzaWNzQmFzZUNsYXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2Js
YW5jYV9zcmNfNC4wL1RlY0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkv
dXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2pl
Y3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFu
Y2EvcGFja2FnZXMvUG9vbWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMg
LUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAv
bGliL0xJTlVYX0tDQ19ERUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGljaC0xLjIuMS9p
bmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4xLjEvaW5jbHVk
ZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxh
eV9lcnJvcl9udW1iZXIgLWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFn
X3N1cHByZXNzIDQ1MCArSzANCg0KcmVhbCAyNy43Mw0KdXNlciAyNC44Mg0Kc3lzIDEuNzQN
Cg0KRG9uZSBjb21waWxpbmcgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElO
VVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL1N5
bW1ldHJ5UmVsYXRpb25zMkQubw0KDQpDT01QSUxJTkcuLi4gU2VlIC9zY3JhdGNoL3dkbi9v
YmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFf
c3JjL0ludGVncmFsTWV0aG9kcy9HZW9tZXRyeS9DeWxpbmRyaWNhbFJlbGF0aW9ucy5vX01Q
STEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL0ludGVn
cmFsTWV0aG9kcy9HZW9tZXRyeS9DeWxpbmRyaWNhbFJlbGF0aW9ucy5jYyAtbyAvc2NyYXRj
aC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNp
Y3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvR2VvbWV0cnkvQ3lsaW5kcmljYWxSZWxhdGlv
bnMubyAtLW91dHB1dF9kZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lD
U0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxN
ZXRob2RzL0dlb21ldHJ5L0N5bGluZHJpY2FsUmVsYXRpb25zLm8uZGVwZW5kLm1rLnRlbXAg
LS1kaWFnX3N1cHByZXNzIDYzMCAtLUNPTVBET19mZV9jYzJjIC0tcGNoX2lnbm9yZV9kaXIg
LS11c2VfcGNoIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19D
QVJUX1hZWl9NUEkvUEhZU0lDU0JFVEFfTVBJMS5wY2ggLURURUNfVVNFX1BIWVNJQ1NCRVRB
IC1EVEVDX1VTRV9IWURST0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlTSUNTU1VQUE9SVEJFVEEg
LURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0VfUE9PTUEySU5URUdSQVRJ
T04gLURURUNfVVNFX1RFQ0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9PTUEgLURURUNfVVNFX0NI
RUVUQUggLURURUNfVVNFX01NIC1EVEVDX1VTRV9QQ0cgLURURUNfTElOVVggLURURUNfSU5T
VCAtRFRFQ19VU0VfUENIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5j
YS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9IeWRyb2R5bmFtaWNzIC1J
L3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3Vw
cG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vz
ci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzQmFzZUNs
YXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1Rl
Y0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkvdXNyL3Byb2plY3RzL2Js
YW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNr
YWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9v
bWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMgLUkvdXNyL3Byb2plY3Rz
L2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAvbGliL0xJTlVYX0tDQ19E
RUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGljaC0xLjIuMS9pbmNsdWRlIC1JL3Vzci9w
cm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4xLjEvaW5jbHVkZSAtSS91c3IvcHJvamVj
dHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxheV9lcnJvcl9udW1iZXIg
LWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFnX3N1cHByZXNzIDQ1MCAr
SzANCg0KcmVhbCAxMy4zOQ0KdXNlciAxMS4wNA0Kc3lzIDEuMTINCg0KRG9uZSBjb21waWxp
bmcgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFla
X01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21ldHJ5L0N5bGluZHJp
Y2FsUmVsYXRpb25zLm8NCg0KQ09NUElMSU5HLi4uIFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQu
MC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9J
bnRlZ3JhbE1ldGhvZHMvR2VvbWV0cnkvUGxhbmFyUmVsYXRpb25zLm9fTVBJMS5pbmZvDQoN
CktDQyAtYyAvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1Bo
eXNpY3NMYXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2Rz
L0dlb21ldHJ5L1BsYW5hclJlbGF0aW9ucy5jYyAtbyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9Q
SFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRl
Z3JhbE1ldGhvZHMvR2VvbWV0cnkvUGxhbmFyUmVsYXRpb25zLm8gLS1vdXRwdXRfZGVwZW5k
ZW5jaWVzIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJU
X1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9HZW9tZXRyeS9QbGFu
YXJSZWxhdGlvbnMuby5kZXBlbmQubWsudGVtcCAtLWRpYWdfc3VwcHJlc3MgNjMwIC0tQ09N
UERPX2ZlX2NjMmMgLS1wY2hfaWdub3JlX2RpciAtLXVzZV9wY2ggL3NjcmF0Y2gvd2RuL29i
al80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QSFlTSUNTQkVUQV9N
UEkxLnBjaCAtRFRFQ19VU0VfUEhZU0lDU0JFVEEgLURURUNfVVNFX0hZRFJPRFlOQU1JQ1Mg
LURURUNfVVNFX1BIWVNJQ1NTVVBQT1JUQkVUQSAtRFRFQ19VU0VfUEhZU0lDU0JBU0VDTEFT
U0VTIC1EVEVDX1VTRV9QT09NQTJJTlRFR1JBVElPTiAtRFRFQ19VU0VfVEVDRlJBTUVXT1JL
IC1EVEVDX1VTRV9QT09NQSAtRFRFQ19VU0VfQ0hFRVRBSCAtRFRFQ19VU0VfTU0gLURURUNf
VVNFX1BDRyAtRFRFQ19MSU5VWCAtRFRFQ19JTlNUIC1EVEVDX1VTRV9QQ0ggLUkvdXNyL3By
b2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlz
aWNzQmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAv
UGh5c2ljc0xheWVyL0h5ZHJvZHluYW1pY3MgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Iv
d2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc1N1cHBvcnRC
ZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlz
aWNzU3VwcG9ydExheWVyL1BoeXNpY3NCYXNlQ2xhc3NlcyAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvVGVjSW50ZWdyYXRpb25MYXllci9Qb29tYTJJ
bnRlZ3JhdGlvbiAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1RlY0ZyYW1ld29y
ayAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9zcmMgLUkvdXNy
L3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvbGliL0xJTlVYX0tDQ19ERUJV
R19DSEVFVEFIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVl
dGFoLTEuMC4wL3NyYyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgv
Y2hlZXRhaC0xLjAuMC9saWIvTElOVVhfS0NDX0RFQlVHIC1JL2hvbWUvd2RuL3BhY2thZ2Vz
L21waWNoLTEuMi4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9t
bS0xLjEuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvcGNnL3Bj
Z19mNzcgLS1kaXNwbGF5X2Vycm9yX251bWJlciAtZnBpYyAtayAtLXN0cmljdCAtRF9fS0FJ
X1NUUklDVCAtLWRpYWdfc3VwcHJlc3MgNDUwICtLMA0KDQpyZWFsIDEyLjEwDQp1c2VyIDEw
LjUwDQpzeXMgMS4wOQ0KDQpEb25lIGNvbXBpbGluZyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9Q
SFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRl
Z3JhbE1ldGhvZHMvR2VvbWV0cnkvUGxhbmFyUmVsYXRpb25zLm8NCg0KQ09NUElMSU5HLi4u
IFNlZSAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9Y
WVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvR2VvbWV0cnkvUlpSZWxh
dGlvbnMub19NUEkxLmluZm8NCg0KS0NDIC1jIC91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93
ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhL1BoeXNpY3NCZXRh
X3NyYy9JbnRlZ3JhbE1ldGhvZHMvR2VvbWV0cnkvUlpSZWxhdGlvbnMuY2MgLW8gL3NjcmF0
Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlz
aWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21ldHJ5L1JaUmVsYXRpb25zLm8gLS1v
dXRwdXRfZGVwZW5kZW5jaWVzIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJ
TlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9H
ZW9tZXRyeS9SWlJlbGF0aW9ucy5vLmRlcGVuZC5tay50ZW1wIC0tZGlhZ19zdXBwcmVzcyA2
MzAgLS1DT01QRE9fZmVfY2MyYyAtLXBjaF9pZ25vcmVfZGlyIC0tdXNlX3BjaCAvc2NyYXRj
aC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BIWVNJ
Q1NCRVRBX01QSTEucGNoIC1EVEVDX1VTRV9QSFlTSUNTQkVUQSAtRFRFQ19VU0VfSFlEUk9E
WU5BTUlDUyAtRFRFQ19VU0VfUEhZU0lDU1NVUFBPUlRCRVRBIC1EVEVDX1VTRV9QSFlTSUNT
QkFTRUNMQVNTRVMgLURURUNfVVNFX1BPT01BMklOVEVHUkFUSU9OIC1EVEVDX1VTRV9URUNG
UkFNRVdPUksgLURURUNfVVNFX1BPT01BIC1EVEVDX1VTRV9DSEVFVEFIIC1EVEVDX1VTRV9N
TSAtRFRFQ19VU0VfUENHIC1EVEVDX0xJTlVYIC1EVEVDX0lOU1QgLURURUNfVVNFX1BDSCAt
SS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xh
eWVyL1BoeXNpY3NCZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ff
c3JjXzQuMC9QaHlzaWNzTGF5ZXIvSHlkcm9keW5hbWljcyAtSS91c3IvcHJvamVjdHMvYmxh
bmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNz
U3VwcG9ydEJldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNf
NC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc0Jhc2VDbGFzc2VzIC1JL3Vzci9wcm9q
ZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9UZWNJbnRlZ3JhdGlvbkxheWVy
L1Bvb21hMkludGVncmF0aW9uIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvVGVj
RnJhbWV3b3JrIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL3Ny
YyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9saWIvTElOVVhf
S0NDX0RFQlVHX0NIRUVUQUggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVl
dGFoL2NoZWV0YWgtMS4wLjAvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMv
Q2hlZXRhaC9jaGVldGFoLTEuMC4wL2xpYi9MSU5VWF9LQ0NfREVCVUcgLUkvaG9tZS93ZG4v
cGFja2FnZXMvbXBpY2gtMS4yLjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Bh
Y2thZ2VzL21tLTEuMS4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdl
cy9wY2cvcGNnX2Y3NyAtLWRpc3BsYXlfZXJyb3JfbnVtYmVyIC1mcGljIC1rIC0tc3RyaWN0
IC1EX19LQUlfU1RSSUNUIC0tZGlhZ19zdXBwcmVzcyA0NTAgK0swDQoNCnJlYWwgMTYuNTMN
CnVzZXIgMTMuOTkNCnN5cyAxLjU3DQoNCkRvbmUgY29tcGlsaW5nIC9zY3JhdGNoL3dkbi9v
YmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFf
c3JjL0ludGVncmFsTWV0aG9kcy9HZW9tZXRyeS9SWlJlbGF0aW9ucy5vDQoNCkNPTVBJTElO
Ry4uLiBTZWUgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NB
UlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21ldHJ5L1Nw
aGVyaWNhbFJlbGF0aW9ucy5vX01QSTEuaW5mbw0KDQpLQ0MgLWMgL3Vzci9wcm9qZWN0cy9i
bGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEv
UGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9HZW9tZXRyeS9TcGhlcmljYWxSZWxh
dGlvbnMuY2MgLW8gL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0ND
X0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21ldHJ5
L1NwaGVyaWNhbFJlbGF0aW9ucy5vIC0tb3V0cHV0X2RlcGVuZGVuY2llcyAvc2NyYXRjaC93
ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NC
ZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvR2VvbWV0cnkvU3BoZXJpY2FsUmVsYXRpb25zLm8u
ZGVwZW5kLm1rLnRlbXAgLS1kaWFnX3N1cHByZXNzIDYzMCAtLUNPTVBET19mZV9jYzJjIC0t
cGNoX2lnbm9yZV9kaXIgLS11c2VfcGNoIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NC
RVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUEhZU0lDU0JFVEFfTVBJMS5wY2ggLURURUNf
VVNFX1BIWVNJQ1NCRVRBIC1EVEVDX1VTRV9IWURST0RZTkFNSUNTIC1EVEVDX1VTRV9QSFlT
SUNTU1VQUE9SVEJFVEEgLURURUNfVVNFX1BIWVNJQ1NCQVNFQ0xBU1NFUyAtRFRFQ19VU0Vf
UE9PTUEySU5URUdSQVRJT04gLURURUNfVVNFX1RFQ0ZSQU1FV09SSyAtRFRFQ19VU0VfUE9P
TUEgLURURUNfVVNFX0NIRUVUQUggLURURUNfVVNFX01NIC1EVEVDX1VTRV9QQ0cgLURURUNf
TElOVVggLURURUNfSU5TVCAtRFRFQ19VU0VfUENIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2Ev
dXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEgLUkvdXNy
L3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9I
eWRyb2R5bmFtaWNzIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3Jj
XzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NTdXBwb3J0QmV0YSAtSS91c3IvcHJv
amVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXll
ci9QaHlzaWNzQmFzZUNsYXNzZXMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2Js
YW5jYV9zcmNfNC4wL1RlY0ludGVncmF0aW9uTGF5ZXIvUG9vbWEySW50ZWdyYXRpb24gLUkv
dXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9UZWNGcmFtZXdvcmsgLUkvdXNyL3Byb2pl
Y3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFu
Y2EvcGFja2FnZXMvUG9vbWEyL3IyL2xpYi9MSU5VWF9LQ0NfREVCVUdfQ0hFRVRBSCAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9zcmMg
LUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFoL2NoZWV0YWgtMS4wLjAv
bGliL0xJTlVYX0tDQ19ERUJVRyAtSS9ob21lL3dkbi9wYWNrYWdlcy9tcGljaC0xLjIuMS9p
bmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvbW0tMS4xLjEvaW5jbHVk
ZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL3BjZy9wY2dfZjc3IC0tZGlzcGxh
eV9lcnJvcl9udW1iZXIgLWZwaWMgLWsgLS1zdHJpY3QgLURfX0tBSV9TVFJJQ1QgLS1kaWFn
X3N1cHByZXNzIDQ1MCArSzANCg0KcmVhbCAxMy4yNQ0KdXNlciAxMS41NQ0Kc3lzIDEuMTEN
Cg0KRG9uZSBjb21waWxpbmcgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElO
VVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dl
b21ldHJ5L1NwaGVyaWNhbFJlbGF0aW9ucy5vDQoNCkNPTVBJTElORy4uLiBTZWUgL3NjcmF0
Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlz
aWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21ldHJ5L1hZUmVsYXRpb25zLm9fTVBJ
MS5pbmZvDQoNCktDQyAtYyAvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9z
cmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdy
YWxNZXRob2RzL0dlb21ldHJ5L1hZUmVsYXRpb25zLmNjIC1vIC9zY3JhdGNoL3dkbi9vYmpf
NC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3Jj
L0ludGVncmFsTWV0aG9kcy9HZW9tZXRyeS9YWVJlbGF0aW9ucy5vIC0tb3V0cHV0X2RlcGVu
ZGVuY2llcyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FS
VF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3JhbE1ldGhvZHMvR2VvbWV0cnkvWFlS
ZWxhdGlvbnMuby5kZXBlbmQubWsudGVtcCAtLWRpYWdfc3VwcHJlc3MgNjMwIC0tQ09NUERP
X2ZlX2NjMmMgLS1wY2hfaWdub3JlX2RpciAtLXVzZV9wY2ggL3NjcmF0Y2gvd2RuL29ial80
LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QSFlTSUNTQkVUQV9NUEkx
LnBjaCAtRFRFQ19VU0VfUEhZU0lDU0JFVEEgLURURUNfVVNFX0hZRFJPRFlOQU1JQ1MgLURU
RUNfVVNFX1BIWVNJQ1NTVVBQT1JUQkVUQSAtRFRFQ19VU0VfUEhZU0lDU0JBU0VDTEFTU0VT
IC1EVEVDX1VTRV9QT09NQTJJTlRFR1JBVElPTiAtRFRFQ19VU0VfVEVDRlJBTUVXT1JLIC1E
VEVDX1VTRV9QT09NQSAtRFRFQ19VU0VfQ0hFRVRBSCAtRFRFQ19VU0VfTU0gLURURUNfVVNF
X1BDRyAtRFRFQ19MSU5VWCAtRFRFQ19JTlNUIC1EVEVDX1VTRV9QQ0ggLUkvdXNyL3Byb2pl
Y3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNz
QmV0YSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5
c2ljc0xheWVyL0h5ZHJvZHluYW1pY3MgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2Ru
L2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc1N1cHBvcnRCZXRh
IC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNz
U3VwcG9ydExheWVyL1BoeXNpY3NCYXNlQ2xhc3NlcyAtSS91c3IvcHJvamVjdHMvYmxhbmNh
L3Vzci93ZG4vYmxhbmNhX3NyY180LjAvVGVjSW50ZWdyYXRpb25MYXllci9Qb29tYTJJbnRl
Z3JhdGlvbiAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1RlY0ZyYW1ld29yayAt
SS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9zcmMgLUkvdXNyL3By
b2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvbGliL0xJTlVYX0tDQ19ERUJVR19D
SEVFVEFIIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFo
LTEuMC4wL3NyYyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hl
ZXRhaC0xLjAuMC9saWIvTElOVVhfS0NDX0RFQlVHIC1JL2hvbWUvd2RuL3BhY2thZ2VzL21w
aWNoLTEuMi4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9tbS0x
LjEuMS9pbmNsdWRlIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvcGNnL3BjZ19m
NzcgLS1kaXNwbGF5X2Vycm9yX251bWJlciAtZnBpYyAtayAtLXN0cmljdCAtRF9fS0FJX1NU
UklDVCAtLWRpYWdfc3VwcHJlc3MgNDUwICtLMA0KDQpyZWFsIDE1LjE2DQp1c2VyIDEzLjQw
DQpzeXMgMS4xOQ0KDQpEb25lIGNvbXBpbGluZyAvc2NyYXRjaC93ZG4vb2JqXzQuMC9QSFlT
SUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BoeXNpY3NCZXRhX3NyYy9JbnRlZ3Jh
bE1ldGhvZHMvR2VvbWV0cnkvWFlSZWxhdGlvbnMubw0KDQpDT01QSUxJTkcuLi4gU2VlIC9z
Y3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkv
UGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9HZW9tZXRyeS9YWVpSZWxhdGlvbnMu
b19NUEkxLmluZm8NCg0KS0NDIC1jIC91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxh
bmNhX3NyY180LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhL1BoeXNpY3NCZXRhX3NyYy9J
bnRlZ3JhbE1ldGhvZHMvR2VvbWV0cnkvWFlaUmVsYXRpb25zLmNjIC1vIC9zY3JhdGNoL3dk
bi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0Jl
dGFfc3JjL0ludGVncmFsTWV0aG9kcy9HZW9tZXRyeS9YWVpSZWxhdGlvbnMubyAtLW91dHB1
dF9kZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhf
S0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0dlb21l
dHJ5L1hZWlJlbGF0aW9ucy5vLmRlcGVuZC5tay50ZW1wIC0tZGlhZ19zdXBwcmVzcyA2MzAg
LS1DT01QRE9fZmVfY2MyYyAtLXBjaF9pZ25vcmVfZGlyIC0tdXNlX3BjaCAvc2NyYXRjaC93
ZG4vb2JqXzQuMC9QSFlTSUNTQkVUQS9MSU5VWF9LQ0NfQ0FSVF9YWVpfTVBJL1BIWVNJQ1NC
RVRBX01QSTEucGNoIC1EVEVDX1VTRV9QSFlTSUNTQkVUQSAtRFRFQ19VU0VfSFlEUk9EWU5B
TUlDUyAtRFRFQ19VU0VfUEhZU0lDU1NVUFBPUlRCRVRBIC1EVEVDX1VTRV9QSFlTSUNTQkFT
RUNMQVNTRVMgLURURUNfVVNFX1BPT01BMklOVEVHUkFUSU9OIC1EVEVDX1VTRV9URUNGUkFN
RVdPUksgLURURUNfVVNFX1BPT01BIC1EVEVDX1VTRV9DSEVFVEFIIC1EVEVDX1VTRV9NTSAt
RFRFQ19VU0VfUENHIC1EVEVDX0xJTlVYIC1EVEVDX0lOU1QgLURURUNfVVNFX1BDSCAtSS91
c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVy
L1BoeXNpY3NCZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3Jj
XzQuMC9QaHlzaWNzTGF5ZXIvSHlkcm9keW5hbWljcyAtSS91c3IvcHJvamVjdHMvYmxhbmNh
L3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc1N1cHBvcnRMYXllci9QaHlzaWNzU3Vw
cG9ydEJldGEgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4w
L1BoeXNpY3NTdXBwb3J0TGF5ZXIvUGh5c2ljc0Jhc2VDbGFzc2VzIC1JL3Vzci9wcm9qZWN0
cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9UZWNJbnRlZ3JhdGlvbkxheWVyL1Bv
b21hMkludGVncmF0aW9uIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvVGVjRnJh
bWV3b3JrIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvUG9vbWEyL3IyL3NyYyAt
SS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9saWIvTElOVVhfS0ND
X0RFQlVHX0NIRUVUQUggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9DaGVldGFo
L2NoZWV0YWgtMS4wLjAvc3JjIC1JL3Vzci9wcm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvQ2hl
ZXRhaC9jaGVldGFoLTEuMC4wL2xpYi9MSU5VWF9LQ0NfREVCVUcgLUkvaG9tZS93ZG4vcGFj
a2FnZXMvbXBpY2gtMS4yLjEvaW5jbHVkZSAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2th
Z2VzL21tLTEuMS4xL2luY2x1ZGUgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9w
Y2cvcGNnX2Y3NyAtLWRpc3BsYXlfZXJyb3JfbnVtYmVyIC1mcGljIC1rIC0tc3RyaWN0IC1E
X19LQUlfU1RSSUNUIC0tZGlhZ19zdXBwcmVzcyA0NTAgK0swDQoNCnJlYWwgMTUuMTQNCnVz
ZXIgMTMuMjENCnN5cyAxLjQ1DQoNCkRvbmUgY29tcGlsaW5nIC9zY3JhdGNoL3dkbi9vYmpf
NC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJUX1hZWl9NUEkvUGh5c2ljc0JldGFfc3Jj
L0ludGVncmFsTWV0aG9kcy9HZW9tZXRyeS9YWVpSZWxhdGlvbnMubw0KDQpDT01QSUxJTkcu
Li4gU2VlIC9zY3JhdGNoL3dkbi9vYmpfNC4wL1BIWVNJQ1NCRVRBL0xJTlVYX0tDQ19DQVJU
X1hZWl9NUEkvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9JTUFkdmVjdGlvbi9J
TUFkdmVjdGlvbjFELm9fTVBJMS5pbmZvDQoNCktDQyAtYyAvdXNyL3Byb2plY3RzL2JsYW5j
YS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YS9QaHlz
aWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9uMUQu
Y2MgLW8gL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRf
WFlaX01QSS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0lNQWR2ZWN0aW9uL0lN
QWR2ZWN0aW9uMUQubyAtLW91dHB1dF9kZXBlbmRlbmNpZXMgL3NjcmF0Y2gvd2RuL29ial80
LjAvUEhZU0lDU0JFVEEvTElOVVhfS0NDX0NBUlRfWFlaX01QSS9QaHlzaWNzQmV0YV9zcmMv
SW50ZWdyYWxNZXRob2RzL0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9uMUQuby5kZXBlbmQubWsu
dGVtcCAtLWRpYWdfc3VwcHJlc3MgNjMwIC0tQ09NUERPX2ZlX2NjMmMgLS1wY2hfaWdub3Jl
X2RpciAtLXVzZV9wY2ggL3NjcmF0Y2gvd2RuL29ial80LjAvUEhZU0lDU0JFVEEvTElOVVhf
S0NDX0NBUlRfWFlaX01QSS9QSFlTSUNTQkVUQV9NUEkxLnBjaCAtRFRFQ19VU0VfUEhZU0lD
U0JFVEEgLURURUNfVVNFX0hZRFJPRFlOQU1JQ1MgLURURUNfVVNFX1BIWVNJQ1NTVVBQT1JU
QkVUQSAtRFRFQ19VU0VfUEhZU0lDU0JBU0VDTEFTU0VTIC1EVEVDX1VTRV9QT09NQTJJTlRF
R1JBVElPTiAtRFRFQ19VU0VfVEVDRlJBTUVXT1JLIC1EVEVDX1VTRV9QT09NQSAtRFRFQ19V
U0VfQ0hFRVRBSCAtRFRFQ19VU0VfTU0gLURURUNfVVNFX1BDRyAtRFRFQ19MSU5VWCAtRFRF
Q19JTlNUIC1EVEVDX1VTRV9QQ0ggLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2Js
YW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YSAtSS91c3IvcHJvamVjdHMv
YmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180LjAvUGh5c2ljc0xheWVyL0h5ZHJvZHluYW1p
Y3MgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNp
Y3NTdXBwb3J0TGF5ZXIvUGh5c2ljc1N1cHBvcnRCZXRhIC1JL3Vzci9wcm9qZWN0cy9ibGFu
Y2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzU3VwcG9ydExheWVyL1BoeXNpY3NC
YXNlQ2xhc3NlcyAtSS91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNhX3NyY180
LjAvVGVjSW50ZWdyYXRpb25MYXllci9Qb29tYTJJbnRlZ3JhdGlvbiAtSS91c3IvcHJvamVj
dHMvYmxhbmNhL3BhY2thZ2VzL1RlY0ZyYW1ld29yayAtSS91c3IvcHJvamVjdHMvYmxhbmNh
L3BhY2thZ2VzL1Bvb21hMi9yMi9zcmMgLUkvdXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdl
cy9Qb29tYTIvcjIvbGliL0xJTlVYX0tDQ19ERUJVR19DSEVFVEFIIC1JL3Vzci9wcm9qZWN0
cy9ibGFuY2EvcGFja2FnZXMvQ2hlZXRhaC9jaGVldGFoLTEuMC4wL3NyYyAtSS91c3IvcHJv
amVjdHMvYmxhbmNhL3BhY2thZ2VzL0NoZWV0YWgvY2hlZXRhaC0xLjAuMC9saWIvTElOVVhf
S0NDX0RFQlVHIC1JL2hvbWUvd2RuL3BhY2thZ2VzL21waWNoLTEuMi4xL2luY2x1ZGUgLUkv
dXNyL3Byb2plY3RzL2JsYW5jYS9wYWNrYWdlcy9tbS0xLjEuMS9pbmNsdWRlIC1JL3Vzci9w
cm9qZWN0cy9ibGFuY2EvcGFja2FnZXMvcGNnL3BjZ19mNzcgLS1kaXNwbGF5X2Vycm9yX251
bWJlciAtZnBpYyAtayAtLXN0cmljdCAtRF9fS0FJX1NUUklDVCAtLWRpYWdfc3VwcHJlc3Mg
NDUwICtLMA0KDQoiL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQu
MC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0
aG9kcy9JTUFkdmVjdGlvbi9JTUFkdmVjdGlvbi50LmhoIiwgbGluZSAxMTI4OiBlcnJvciAj
MzQ5OiANCiAgICAgICAgICBubyBvcGVyYXRvciAiLSIgbWF0Y2hlcyB0aGVzZSBvcGVyYW5k
cw0KICAgICAgICAgICAgb3BlcmFuZCB0eXBlcyBhcmU6DQogICAgICAgICAgICAgICAgICAg
ICAgQWx0VmlldzE8RmllbGQ8cG9vbWFsb3RlOjpNb2RlbFRyYWl0czxwb29tYWxvdGU6Ok9u
ZURGPHBvDQogICAgICAgICAgICAgICAgICAgICAgb21hbG90ZTo6RGVmYXVsdFRyYWl0cz4+
OjpNZXNoVGFnLCBWZWN0b3I8MSwNCiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxvdGU6
OlJlYWwsIEZ1bGw+LA0KICAgICAgICAgICAgICAgICAgICAgIHBvb21hbG90ZTo6TW9kZWxU
cmFpdHM8cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bA0KICAgICAgICAgICAg
ICAgICAgICAgIHRUcmFpdHM+Pjo6RW5naW5lVGFnPiwgRG9tYWluQXJpdGhPcHNUcmFpdHM8
TG9jPDE+LA0KICAgICAgICAgICAgICAgICAgICAgIExvYzwxPj46OkFkZFJlc3VsdF90Pjo6
VHlwZV90IC0NCiAgICAgICAgICAgICAgICAgICAgICBBbHRWaWV3MTxGaWVsZDxwb29tYWxv
dGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG8NCiAgICAgICAgICAgICAgICAg
ICAgICBvbWFsb3RlOjpEZWZhdWx0VHJhaXRzPj46Ok1lc2hUYWcsIFZlY3RvcjwxLA0KICAg
ICAgICAgICAgICAgICAgICAgIHBvb21hbG90ZTo6UmVhbCwgRnVsbD4sDQogICAgICAgICAg
ICAgICAgICAgICAgcG9vbWFsb3RlOjpNb2RlbFRyYWl0czxwb29tYWxvdGU6Ok9uZURGPHBv
b21hbG90ZTo6RGVmYXVsDQogICAgICAgICAgICAgICAgICAgICAgdFRyYWl0cz4+OjpFbmdp
bmVUYWc+LCBEb21haW5Bcml0aE9wc1RyYWl0czxMb2M8MT4sDQogICAgICAgICAgICAgICAg
ICAgICAgTG9jPDE+Pjo6QWRkUmVzdWx0X3Q+OjpUeXBlX3QNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgLSBTdWJSZWxheGVkTWVzaChmYWNlTG9jICsgb2Zm
c2V0KTsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXg0KICAg
ICAgICAgIGRldGVjdGVkIGR1cmluZyBpbnN0YW50aWF0aW9uIG9mICJ2b2lkDQogICAgICAg
ICAgICAgICAgICAgIFBoeXNpY3NCZXRhOjpJTUFkdmVjdGlvbjxUcmFpdHM+Ojptb21lbnR1
bUFkdmVjdGlvbihwb29tYWxvDQogICAgICAgICAgICAgICAgICAgIHRlOjpSZWFsICYpIFt3
aXRoDQogICAgICAgICAgICAgICAgICAgIFRyYWl0cz1wb29tYWxvdGU6Ok9uZURGPHBvb21h
bG90ZTo6RGVmYXVsdFRyYWl0cz5dIiANCg0KIi91c3IvcHJvamVjdHMvYmxhbmNhL3BhY2th
Z2VzL1Bvb21hMi9yMi9zcmMvUEVURS9PcGVyYXRvclRhZ3MuaCIsIGxpbmUgNzU3OiBlcnJv
ciAjNDEzOiANCiAgICAgICAgICBubyBzdWl0YWJsZSBjb252ZXJzaW9uIGZ1bmN0aW9uIGZy
b20NCiAgICAgICAgICAiY29uc3QgUmVtb3RlUHJveHk8VmVjdG9yPDEsIHBvb21hbG90ZTo6
UmVhbCwgRnVsbD4+IiB0bw0KICAgICAgICAgICJwb29tYWxvdGU6OlJlYWwiIGV4aXN0cw0K
ICAgICAgcmV0dXJuIChjb25zdF9jYXN0PFQxICY+KGEpID0gYik7DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBeDQogICAgICAgICAgZGV0ZWN0ZWQgZHVyaW5nOg0K
ICAgICAgICAgICAgaW5zdGFudGlhdGlvbiBvZiAiQmluYXJ5UmV0dXJuPFQxLCBUMiwgT3BB
c3NpZ24+OjpUeXBlX3QNCiAgICAgICAgICAgICAgICAgICAgICBPcEFzc2lnbjo6b3BlcmF0
b3IoKShjb25zdCBUMSAmLCBjb25zdCBUMiAmKSBjb25zdCBbd2l0aA0KICAgICAgICAgICAg
ICAgICAgICAgIFQxPXBvb21hbG90ZTo6UmVhbCwgVDI9UmVtb3RlUHJveHk8VmVjdG9yPDEs
DQogICAgICAgICAgICAgICAgICAgICAgcG9vbWFsb3RlOjpSZWFsLCBGdWxsPj5dIiBhdCBs
aW5lIDE0NiBvZg0KICAgICAgICAgICAgICAgICAgICAgICIvdXNyL3Byb2plY3RzL2JsYW5j
YS9wYWNrYWdlcy9Qb29tYTIvcjIvc3JjL1RpbnkvVmVjdG9yRQ0KICAgICAgICAgICAgICAg
ICAgICAgIGxlbWVudHMuaCINCiAgICAgICAgICAgIGluc3RhbnRpYXRpb24gb2YgInZvaWQg
VmVjdG9yQXNzaWduPFYxLCBWMiwgT3AsIEIsIDE+OjphcHBseShWMSAmLA0KICAgICAgICAg
ICAgICAgICAgICAgIGNvbnN0IFYyICYsIE9wKSBbd2l0aCBWMT1WZWN0b3JFbmdpbmU8MSwN
CiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxvdGU6OlJlYWwsIEZ1bGw+OjpUaGlzX3Qs
IFYyPVJlbW90ZVByb3h5PFZlY3RvcjwxLA0KICAgICAgICAgICAgICAgICAgICAgIHBvb21h
bG90ZTo6UmVhbCwgRnVsbD4+LCBPcD1PcEFzc2lnbiwgQj0wXSIgYXQgbGluZSAzMzINCiAg
ICAgICAgICAgICAgICAgICAgICBvZg0KICAgICAgICAgICAgICAgICAgICAgICIvdXNyL3By
b2plY3RzL2JsYW5jYS9wYWNrYWdlcy9Qb29tYTIvcjIvc3JjL1RpbnkvVmVjdG9yLg0KICAg
ICAgICAgICAgICAgICAgICAgIGgiDQogICAgICAgICAgICBpbnN0YW50aWF0aW9uIG9mICJW
ZWN0b3JFbmdpbmU8RCwgVCwgRnVsbD46OlRoaXNfdA0KICAgICAgICAgICAgICAgICAgICAg
ICZWZWN0b3JFbmdpbmU8RCwgVCwgRnVsbD46Om9wZXJhdG9yPShjb25zdCBWICYpIFt3aXRo
DQogICAgICAgICAgICAgICAgICAgICAgRD0xLCBUPXBvb21hbG90ZTo6UmVhbCwgVj1SZW1v
dGVQcm94eTxWZWN0b3I8MSwNCiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxvdGU6OlJl
YWwsIEZ1bGw+Pl0iIGF0IGxpbmUgMTQ5IG9mDQogICAgICAgICAgICAgICAgICAgICAgIi91
c3IvcHJvamVjdHMvYmxhbmNhL3BhY2thZ2VzL1Bvb21hMi9yMi9zcmMvVGlueS9WZWN0b3Iu
DQogICAgICAgICAgICAgICAgICAgICAgaCINCiAgICAgICAgICAgIGluc3RhbnRpYXRpb24g
b2YgIlZlY3RvcjxEaW0sIFQsIEVuZ2luZVRhZz46OlRoaXNfdCAmVmVjdG9yPERpbSwNCiAg
ICAgICAgICAgICAgICAgICAgICBULCBFbmdpbmVUYWc+OjpvcGVyYXRvcj0oY29uc3QgViAm
KSBbd2l0aCBEaW09MSwNCiAgICAgICAgICAgICAgICAgICAgICBUPXBvb21hbG90ZTo6UmVh
bCwgRW5naW5lVGFnPUZ1bGwsDQogICAgICAgICAgICAgICAgICAgICAgVj1BbHRWaWV3MTxG
aWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8DQogICAgICAg
ICAgICAgICAgICAgICAgcG9vbWFsb3RlOjpEZWZhdWx0VHJhaXRzPj46Ok1lc2hUYWcsIFZl
Y3RvcjwxLA0KICAgICAgICAgICAgICAgICAgICAgIHBvb21hbG90ZTo6UmVhbCwgRnVsbD4s
DQogICAgICAgICAgICAgICAgICAgICAgcG9vbWFsb3RlOjpNb2RlbFRyYWl0czxwb29tYWxv
dGU6Ok9uZURGPHBvb21hbG90ZTo6RGVmYXVsDQogICAgICAgICAgICAgICAgICAgICAgdFRy
YWl0cz4+OjpFbmdpbmVUYWc+LCBEb21haW5Bcml0aE9wc1RyYWl0czxMb2M8MT4sDQogICAg
ICAgICAgICAgICAgICAgICAgTG9jPDE+Pjo6QWRkUmVzdWx0X3Q+OjpUeXBlX3RdIiBhdCBs
aW5lIDExMzAgb2YNCiAgICAgICAgICAgICAgICAgICAgICAiL3Vzci9wcm9qZWN0cy9ibGFu
Y2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXINCiAgICAgICAgICAgICAg
ICAgICAgICAvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9J
TUFkdmVjdGlvbi8NCiAgICAgICAgICAgICAgICAgICAgICBJTUFkdmVjdGlvbi50LmhoIg0K
ICAgICAgICAgICAgaW5zdGFudGlhdGlvbiBvZiAidm9pZA0KICAgICAgICAgICAgICAgICAg
ICAgIFBoeXNpY3NCZXRhOjpJTUFkdmVjdGlvbjxUcmFpdHM+Ojptb21lbnR1bUFkdmVjdGlv
bihwb29tYQ0KICAgICAgICAgICAgICAgICAgICAgIGxvdGU6OlJlYWwgJikgW3dpdGgNCiAg
ICAgICAgICAgICAgICAgICAgICBUcmFpdHM9cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6
OkRlZmF1bHRUcmFpdHM+XSIgDQoNCiIvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2Js
YW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMv
SW50ZWdyYWxNZXRob2RzL0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9uLnQuaGgiLCBsaW5lIDEx
NjU6IGVycm9yICMzNDk6IA0KICAgICAgICAgIG5vIG9wZXJhdG9yICItIiBtYXRjaGVzIHRo
ZXNlIG9wZXJhbmRzDQogICAgICAgICAgICBvcGVyYW5kIHR5cGVzIGFyZToNCiAgICAgICAg
ICAgICAgICAgICAgICBBbHRWaWV3MTxGaWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBv
b21hbG90ZTo6T25lREY8cG8NCiAgICAgICAgICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZh
dWx0VHJhaXRzPj46Ok1lc2hUYWcsIFZlY3RvcjwxLA0KICAgICAgICAgICAgICAgICAgICAg
IHBvb21hbG90ZTo6UmVhbCwgRnVsbD4sDQogICAgICAgICAgICAgICAgICAgICAgcG9vbWFs
b3RlOjpNb2RlbFRyYWl0czxwb29tYWxvdGU6Ok9uZURGPHBvb21hbG90ZTo6RGVmYXVsDQog
ICAgICAgICAgICAgICAgICAgICAgdFRyYWl0cz4+OjpFbmdpbmVUYWc+LCBEb21haW5Bcml0
aE9wc1RyYWl0czxMb2M8MT4sDQogICAgICAgICAgICAgICAgICAgICAgTG9jPDE+Pjo6QWRk
UmVzdWx0X3Q+OjpUeXBlX3QgLQ0KICAgICAgICAgICAgICAgICAgICAgIEFsdFZpZXcxPEZp
ZWxkPHBvb21hbG90ZTo6TW9kZWxUcmFpdHM8cG9vbWFsb3RlOjpPbmVERjxwbw0KICAgICAg
ICAgICAgICAgICAgICAgIG9tYWxvdGU6OkRlZmF1bHRUcmFpdHM+Pjo6TWVzaFRhZywgVmVj
dG9yPDEsDQogICAgICAgICAgICAgICAgICAgICAgcG9vbWFsb3RlOjpSZWFsLCBGdWxsPiwN
CiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90
ZTo6T25lREY8cG9vbWFsb3RlOjpEZWZhdWwNCiAgICAgICAgICAgICAgICAgICAgICB0VHJh
aXRzPj46OkVuZ2luZVRhZz4sIERvbWFpbkFyaXRoT3BzVHJhaXRzPExvYzwxPiwNCiAgICAg
ICAgICAgICAgICAgICAgICBMb2M8MT4+OjpBZGRSZXN1bHRfdD46OlR5cGVfdA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtIFN1YlJlbGF4ZWRNZXNoKGZh
Y2VMb2MgLSBvZmZzZXQpOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBeDQogICAgICAgICAgZGV0ZWN0ZWQgZHVyaW5nIGluc3RhbnRpYXRpb24gb2YgInZv
aWQNCiAgICAgICAgICAgICAgICAgICAgUGh5c2ljc0JldGE6OklNQWR2ZWN0aW9uPFRyYWl0
cz46Om1vbWVudHVtQWR2ZWN0aW9uKHBvb21hbG8NCiAgICAgICAgICAgICAgICAgICAgdGU6
OlJlYWwgJikgW3dpdGgNCiAgICAgICAgICAgICAgICAgICAgVHJhaXRzPXBvb21hbG90ZTo6
T25lREY8cG9vbWFsb3RlOjpEZWZhdWx0VHJhaXRzPl0iIA0KDQoiL3Vzci9wcm9qZWN0cy9i
bGFuY2EvdXNyL3dkbi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEv
UGh5c2ljc0JldGFfc3JjL0ludGVncmFsTWV0aG9kcy9JTUFkdmVjdGlvbi9JTUFkdmVjdGlv
bi50LmhoIiwgbGluZSAxMjA0OiBlcnJvciAjMzQ5OiANCiAgICAgICAgICBubyBvcGVyYXRv
ciAiLSIgbWF0Y2hlcyB0aGVzZSBvcGVyYW5kcw0KICAgICAgICAgICAgb3BlcmFuZCB0eXBl
cyBhcmU6DQogICAgICAgICAgICAgICAgICAgICAgQWx0VmlldzE8RmllbGQ8cG9vbWFsb3Rl
OjpNb2RlbFRyYWl0czxwb29tYWxvdGU6Ok9uZURGPHBvDQogICAgICAgICAgICAgICAgICAg
ICAgb21hbG90ZTo6RGVmYXVsdFRyYWl0cz4+OjpNZXNoVGFnLCBWZWN0b3I8MSwNCiAgICAg
ICAgICAgICAgICAgICAgICBwb29tYWxvdGU6OlJlYWwsIEZ1bGw+LA0KICAgICAgICAgICAg
ICAgICAgICAgIHBvb21hbG90ZTo6TW9kZWxUcmFpdHM8cG9vbWFsb3RlOjpPbmVERjxwb29t
YWxvdGU6OkRlZmF1bA0KICAgICAgICAgICAgICAgICAgICAgIHRUcmFpdHM+Pjo6RW5naW5l
VGFnPiwgRG9tYWluQXJpdGhPcHNUcmFpdHM8TG9jPDE+LA0KICAgICAgICAgICAgICAgICAg
ICAgIExvYzwxPj46OkFkZFJlc3VsdF90Pjo6VHlwZV90IC0NCiAgICAgICAgICAgICAgICAg
ICAgICBBbHRWaWV3MTxGaWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6
T25lREY8cG8NCiAgICAgICAgICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZhdWx0VHJhaXRz
Pj46Ok1lc2hUYWcsIFZlY3RvcjwxLA0KICAgICAgICAgICAgICAgICAgICAgIHBvb21hbG90
ZTo6UmVhbCwgRnVsbD4sDQogICAgICAgICAgICAgICAgICAgICAgcG9vbWFsb3RlOjpNb2Rl
bFRyYWl0czxwb29tYWxvdGU6Ok9uZURGPHBvb21hbG90ZTo6RGVmYXVsDQogICAgICAgICAg
ICAgICAgICAgICAgdFRyYWl0cz4+OjpFbmdpbmVUYWc+LCBEb21haW5Bcml0aE9wc1RyYWl0
czxMb2M8MT4sDQogICAgICAgICAgICAgICAgICAgICAgTG9jPDE+Pjo6QWRkUmVzdWx0X3Q+
OjpUeXBlX3QNCiAgCSAgICAgICAgICAgICAgZGVsdGFEaXNwbGFjZW1lbnQgPSBPbGQuU3Vi
VmVydFBvaW50cyhmYWNlTG9jKSAtIFN1YlJlbGF4ZWRNZXNoKGZhY2VMb2MpOw0KICAJICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIF4NCiAgICAgICAgICBkZXRlY3RlZCBkdXJpbmcgaW5zdGFudGlhdGlvbiBvZiAidm9p
ZA0KICAgICAgICAgICAgICAgICAgICBQaHlzaWNzQmV0YTo6SU1BZHZlY3Rpb248VHJhaXRz
Pjo6bW9tZW50dW1BZHZlY3Rpb24ocG9vbWFsbw0KICAgICAgICAgICAgICAgICAgICB0ZTo6
UmVhbCAmKSBbd2l0aA0KICAgICAgICAgICAgICAgICAgICBUcmFpdHM9cG9vbWFsb3RlOjpP
bmVERjxwb29tYWxvdGU6OkRlZmF1bHRUcmFpdHM+XSIgDQoNCiIvdXNyL3Byb2plY3RzL2Js
YW5jYS91c3Ivd2RuL2JsYW5jYV9zcmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YS9Q
aHlzaWNzQmV0YV9zcmMvSW50ZWdyYWxNZXRob2RzL0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9u
LnQuaGgiLCBsaW5lIDc2MTogZXJyb3IgIzM0OTogDQogICAgICAgICAgbm8gb3BlcmF0b3Ig
Ii0iIG1hdGNoZXMgdGhlc2Ugb3BlcmFuZHMNCiAgICAgICAgICAgIG9wZXJhbmQgdHlwZXMg
YXJlOg0KICAgICAgICAgICAgICAgICAgICAgIEFsdFZpZXcxPEZpZWxkPHBvb21hbG90ZTo6
TW9kZWxUcmFpdHM8cG9vbWFsb3RlOjpPbmVERjxwbw0KICAgICAgICAgICAgICAgICAgICAg
IG9tYWxvdGU6OkRlZmF1bHRUcmFpdHM+Pjo6TWVzaFRhZywgVmVjdG9yPDEsDQogICAgICAg
ICAgICAgICAgICAgICAgcG9vbWFsb3RlOjpSZWFsLCBGdWxsPiwNCiAgICAgICAgICAgICAg
ICAgICAgICBwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG9vbWFs
b3RlOjpEZWZhdWwNCiAgICAgICAgICAgICAgICAgICAgICB0VHJhaXRzPj46OkVuZ2luZVRh
Zz4sIERvbWFpbkFyaXRoT3BzVHJhaXRzPExvYzwxPiwNCiAgICAgICAgICAgICAgICAgICAg
ICBMb2M8MT4+OjpBZGRSZXN1bHRfdD46OlR5cGVfdCAtDQogICAgICAgICAgICAgICAgICAg
ICAgQWx0VmlldzE8RmllbGQ8cG9vbWFsb3RlOjpNb2RlbFRyYWl0czxwb29tYWxvdGU6Ok9u
ZURGPHBvDQogICAgICAgICAgICAgICAgICAgICAgb21hbG90ZTo6RGVmYXVsdFRyYWl0cz4+
OjpNZXNoVGFnLCBWZWN0b3I8MSwNCiAgICAgICAgICAgICAgICAgICAgICBwb29tYWxvdGU6
OlJlYWwsIEZ1bGw+LA0KICAgICAgICAgICAgICAgICAgICAgIHBvb21hbG90ZTo6TW9kZWxU
cmFpdHM8cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bA0KICAgICAgICAgICAg
ICAgICAgICAgIHRUcmFpdHM+Pjo6RW5naW5lVGFnPiwgRG9tYWluQXJpdGhPcHNUcmFpdHM8
TG9jPDE+LA0KICAgICAgICAgICAgICAgICAgICAgIExvYzwxPj46OkFkZFJlc3VsdF90Pjo6
VHlwZV90DQogICAgICAgICAgICAgICAgZGVsdGFEaXNwbGFjZW1lbnQgPSAgT2xkLlZlcnRQ
b2ludHModmVydExvYykgLSBSZWxheGVkTWVzaCh2ZXJ0TG9jKTsNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeDQogICAg
ICAgICAgZGV0ZWN0ZWQgZHVyaW5nIGluc3RhbnRpYXRpb24gb2YgInZvaWQNCiAgICAgICAg
ICAgICAgICAgICAgUGh5c2ljc0JldGE6OklNQWR2ZWN0aW9uPFRyYWl0cz46OnZhcmlhYmxl
QWR2ZWN0aW9uKHBvb21hbG8NCiAgICAgICAgICAgICAgICAgICAgdGU6OlJlYWwgJikgW3dp
dGgNCiAgICAgICAgICAgICAgICAgICAgVHJhaXRzPXBvb21hbG90ZTo6T25lREY8cG9vbWFs
b3RlOjpEZWZhdWx0VHJhaXRzPl0iIA0KDQoiL3Vzci9wcm9qZWN0cy9ibGFuY2EvdXNyL3dk
bi9ibGFuY2Ffc3JjXzQuMC9QaHlzaWNzTGF5ZXIvUGh5c2ljc0JldGEvUGh5c2ljc0JldGFf
c3JjL0ludGVncmFsTWV0aG9kcy9JTUFkdmVjdGlvbi9JTUFkdmVjdGlvbi50LmhoIiwgbGlu
ZSA4OTE6IGVycm9yICMzMDQ6IA0KICAgICAgICAgIG5vIGluc3RhbmNlIG9mIG92ZXJsb2Fk
ZWQgZnVuY3Rpb24gIm1pbiIgbWF0Y2hlcyB0aGUgYXJndW1lbnQgbGlzdA0KICAgICAgICAg
ICAgYXJndW1lbnQgdHlwZXMgYXJlOiAoZG91YmxlLA0KICAgICAgICAgICAgICAgICAgICAg
IEFsdFZpZXcxPEZpZWxkPHBvb21hbG90ZTo6TW9kZWxUcmFpdHM8cG9vbWFsb3RlOjpPbmVE
Rjxwbw0KICAgICAgICAgICAgICAgICAgICAgIG9tYWxvdGU6OkRlZmF1bHRUcmFpdHM+Pjo6
TWVzaFRhZywgcG9vbWFsb3RlOjpSZWFsLA0KICAgICAgICAgICAgICAgICAgICAgIHBvb21h
bG90ZTo6TW9kZWxUcmFpdHM8cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRlZmF1bA0K
ICAgICAgICAgICAgICAgICAgICAgIHRUcmFpdHM+Pjo6RW5naW5lVGFnPiwgTG9jPDE+Pjo6
VHlwZV90KQ0KICAgICAgICAgICAgICAgICAgICAgIGFkdmVjdGVkTWFzcyAgID0gbWluKCBh
ZHZlY3RlZE1hc3MgKiBtbV9Wb2xGbHV4W21dLCBNTV9NYXNzW21dKGRvbm9yTG9jKSApOw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXg0KICAgICAgICAgIGRl
dGVjdGVkIGR1cmluZyBpbnN0YW50aWF0aW9uIG9mICJ2b2lkDQogICAgICAgICAgICAgICAg
ICAgIFBoeXNpY3NCZXRhOjpJTUFkdmVjdGlvbjxUcmFpdHM+Ojp2YXJpYWJsZUFkdmVjdGlv
bihwb29tYWxvDQogICAgICAgICAgICAgICAgICAgIHRlOjpSZWFsICYpIFt3aXRoDQogICAg
ICAgICAgICAgICAgICAgIFRyYWl0cz1wb29tYWxvdGU6Ok9uZURGPHBvb21hbG90ZTo6RGVm
YXVsdFRyYWl0cz5dIiANCg0KIi91c3IvcHJvamVjdHMvYmxhbmNhL3Vzci93ZG4vYmxhbmNh
X3NyY180LjAvUGh5c2ljc0xheWVyL1BoeXNpY3NCZXRhL1BoeXNpY3NCZXRhX3NyYy9JbnRl
Z3JhbE1ldGhvZHMvSU1BZHZlY3Rpb24vSU1BZHZlY3Rpb24udC5oaCIsIGxpbmUgODkzOiBl
cnJvciAjMzA0OiANCiAgICAgICAgICBubyBpbnN0YW5jZSBvZiBvdmVybG9hZGVkIGZ1bmN0
aW9uICJtaW4iIG1hdGNoZXMgdGhlIGFyZ3VtZW50IGxpc3QNCiAgICAgICAgICAgIGFyZ3Vt
ZW50IHR5cGVzIGFyZTogKHBvb21hbG90ZTo6UmVhbCwNCiAgICAgICAgICAgICAgICAgICAg
ICBBbHRWaWV3MTxGaWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25l
REY8cG8NCiAgICAgICAgICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZhdWx0VHJhaXRzPj46
Ok1lc2hUYWcsIHBvb21hbG90ZTo6UmVhbCwNCiAgICAgICAgICAgICAgICAgICAgICBwb29t
YWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG9vbWFsb3RlOjpEZWZhdWwN
CiAgICAgICAgICAgICAgICAgICAgICB0VHJhaXRzPj46OkVuZ2luZVRhZz4sIExvYzwxPj46
OlR5cGVfdCkNCiAgICAgICAgICAgICAgICAgICAgICBSZWFsIGFkdmVjdGVkVm9sdW1lID0g
bWluKCBtbV9Wb2xGbHV4W21dLCBNTV9Wb2xGcmFjW21dKGRvbm9yTG9jKSk7DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4NCiAgICAgICAgICBkZXRl
Y3RlZCBkdXJpbmcgaW5zdGFudGlhdGlvbiBvZiAidm9pZA0KICAgICAgICAgICAgICAgICAg
ICBQaHlzaWNzQmV0YTo6SU1BZHZlY3Rpb248VHJhaXRzPjo6dmFyaWFibGVBZHZlY3Rpb24o
cG9vbWFsbw0KICAgICAgICAgICAgICAgICAgICB0ZTo6UmVhbCAmKSBbd2l0aA0KICAgICAg
ICAgICAgICAgICAgICBUcmFpdHM9cG9vbWFsb3RlOjpPbmVERjxwb29tYWxvdGU6OkRlZmF1
bHRUcmFpdHM+XSIgDQoNCiIvdXNyL3Byb2plY3RzL2JsYW5jYS91c3Ivd2RuL2JsYW5jYV9z
cmNfNC4wL1BoeXNpY3NMYXllci9QaHlzaWNzQmV0YS9QaHlzaWNzQmV0YV9zcmMvSW50ZWdy
YWxNZXRob2RzL0lNQWR2ZWN0aW9uL0lNQWR2ZWN0aW9uLnQuaGgiLCBsaW5lIDg5NTogZXJy
b3IgIzM0OTogDQogICAgICAgICAgbm8gb3BlcmF0b3IgIi09IiBtYXRjaGVzIHRoZXNlIG9w
ZXJhbmRzDQogICAgICAgICAgICBvcGVyYW5kIHR5cGVzIGFyZToNCiAgICAgICAgICAgICAg
ICAgICAgICBBbHRWaWV3MTxGaWVsZDxwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90
ZTo6T25lREY8cG8NCiAgICAgICAgICAgICAgICAgICAgICBvbWFsb3RlOjpEZWZhdWx0VHJh
aXRzPj46Ok1lc2hUYWcsIHBvb21hbG90ZTo6UmVhbCwNCiAgICAgICAgICAgICAgICAgICAg
ICBwb29tYWxvdGU6Ok1vZGVsVHJhaXRzPHBvb21hbG90ZTo6T25lREY8cG9vbWFsb3RlOjpE
ZWZhdWwNCiAgICAgICAgICAgICAgICAgICAgICB0VHJhaXRzPj46OkVuZ2luZVRhZz4sIExv
YzwxPj46OlR5cGVfdCAtPSBwb29tYWxvdGU6OlJlYWwNCiAgICAgICAgICAgICAgICAgICAg
ICBNTV9NYXNzW21dKGRvbm9yTG9jKSAgICAgIC09IGFkdmVjdGVkTWFzczsNCiAgICAgICAg


From oldham at codesourcery.com  Fri Jun  8 19:38:13 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Fri, 8 Jun 2001 12:38:13 -0700
Subject: Oldham's Weekly Pooma Report
Message-ID: <200106081938.MAA22725@oz.codesourcery.com>


This week, I:

reviewed the proposal to implement interpolation and restriction operators
read Stephen Smith's code for some interpolation operators
read the Pooma NewField stencil code for understanding
started implementing the total<2>() restriction operator

Next week, I will be on holiday (until 18June).

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From JimC at proximation.com  Fri Jun  8 19:54:34 2001
From: JimC at proximation.com (James Crotinger)
Date: Fri, 8 Jun 2001 12:54:34 -0700 
Subject: Weekly non-report
Message-ID: <F871BB04B0EA224A821A5274C31DF3152C37@proxim-sf001.santafe.proximation.com>

I've been off doing Proximation stuff basically for the last month and that
will continue to be my main focus in the near future, so there isn't really
much to report. I've put in a bit of time on email, discussions, and code
reviews. 

	Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010608/b0e2bd5e/attachment.html>

From allan at stokes.ca  Sat Jun  9 17:57:20 2001
From: allan at stokes.ca (Allan Stokes)
Date: Sat, 9 Jun 2001 10:57:20 -0700
Subject: doxygen
Message-ID: <NABBJEAOKIDHLPHKHPDLMEFBEBAA.allan@stokes.ca>


Has anyone considered the possibility of generating browsable code
documentation using an automated documentation tool?

The tool I've seen mentioned most often for this purpose is Doxygen.
http://www.stack.nl/~dimitri/doxygen/

I did a quick check on the web to determine whether Doxygen can reasonably
cope with template libraries.  The bulk of the comments which came up on
this subject were in the libstdc++ thread (I saw a number of posts from Mark
on that list).

Some people there have recently discussed applying Doxygen to the gcc
iostreams library (or portions thereof).  If it can do a good job of
iostreams it can cope with most template constructs.  They seem to be moving
in the right direction.

I was thinking it might possible to set up the conceptual documentation to
hyperlink into an actual web-based source archive.  This browsable archive
could either be something like Doxygen or it could be a simple CVS web
interface.

Doxygen includes a mechanism for adding documentation directives into your
source code.  I wouldn't be surprised if Doxygen contained a feature whereby
we could mark each source file with tags indicating which concepts it was
associated with.  It might not be all that difficult to then use those tags
to automatically create links between the generated documentation and the
written documentation.  This is the kind of thing that DocBook is supposed
to facilitate.

Is there any interest in having me run the Pooma sources through Doxygen on
a trial basis to see what can be done along these lines?

Allan



From stephens at proximation.com  Sun Jun 10 17:21:46 2001
From: stephens at proximation.com (Stephen Smith)
Date: Sun, 10 Jun 2001 10:21:46 -0700
Subject: weekly report
Message-ID: <F871BB04B0EA224A821A5274C31DF315021703@proxim-sf001.santafe.proximation.com>

I spent no time on POOMA this week because we've been wrapping
up a Proximation project.  Next week I'm on vacation.  I have spent some
time recently looking at the hydrodynamics kernel that Jeffrey wrote, and
when I'm back, I hope to spend some time discussing how the field stencils
could be used to implement some of the operations with Jeffrey and Alan.

    Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010610/625a8e39/attachment.html>

From wdn at lanl.gov  Wed Jun 13 17:38:18 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Wed, 13 Jun 2001 11:38:18 -0600
Subject: Problems Compiling Pooma 2 with gcc snapshot dated 5/27/01
Message-ID: <15143.42250.396584.522130@saltydog.lanl.gov>

I tried building Pooma 2 with the 5/27/01 snapshot of gcc from the
CodeSourcery web site that Jeffrey recommended.  I'm having compilation
problems trying to build Pooma 2 with this snapshot of gcc.  Here is how I'm
trying to build Pooma 2:


#######################################################################
# Build a debug version of Pooma 2 for Linux using GCC.

if [ "$BUILD_LINUX_GCC_DEBUG" = "true" ]; then
  configure \
    --arch LINUXgcc \
    --suite LINUX_GCC_DEBUG \
    --static \
    --debug \
    --bounds \
    --printdebug \
    --oneper \
    --with-fortran \
    --pool \
    --ex

  SUITE=LINUX_GCC_DEBUG
  export SUITE

  make -j $NPROCS_FOR_COMPILES

  cd lib/$SUITE
  ln -s libpooma-gcc-ex.a libpooma.a
  cd ../..
fi

Here is the translation unit that is failing to build and it's associated
error messages.

saltydog % more src/IO/LINUX_GCC_DEBUG/Serializers.cmpl.o_1.info
Wed Jun 13 10:53:43 MDT 2001
Compiler location: /home/wdn/bin/g++
cd /home/wdn/blanca/packages/Pooma2/r2_2001_05_23; \
 TMPDIR=/scratch/wdn/tmp/LINUX_GCC_DEBUG; \
 /usr/bin/time g++ -c /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializers.cmpl.cpp \
-o /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/LINUX_GCC_DEBUG/Serializers.cmpl.o \
  -ftemplate-depth-60 \
-Drestrict=__restrict__   -g \
-I/home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src \
-I/home/wdn/blanca/packages/Pooma2/r2_2001_05_23/lib/LINUX_GCC_DEBUG  



/home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializers.h: In 
   function `int streamOut(char*&, const T&) [with T = int]':
/home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializers.h:133:   instantiated from `int serialize(Stream&, const T&) [with Stream = ch
ar*, T = int]'
/home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializers.cmpl.cpp:111:   instantiated from here
/home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializers.h:71: `memcpy'
   undeclared (first use this function)
/home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializers.h:71: (Each 
   undeclared identifier is reported only once for each function it appears 
   in.)
Command exited with non-zero status 1
1.76user 0.07system 0:03.69elapsed 49%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (941major+3059minor)pagefaults 0swaps

Let me know if I am doing something wrong.  I think I am using the right
g++.  Could I be configuring wrong?  BTW, I'm using gcc on my Linux laptop
which is running RedHat 7.1.

saltydog % which g++
~/bin/g++

saltydog % ll ~/bin/g++
lrwxrwxrwx    1 wdn      x10             8 Jun 10 17:18 /home/wdn/bin/g++ -> g++_3pt0*

saltydog % ll ~/bin/g++_3pt0
lrwxrwxrwx    1 wdn      x10            36 Jun 10 17:16 /home/wdn/bin/g++_3pt0 -> ../packages/gcc-3.0-20010527/bin/g++*

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From mark at codesourcery.com  Wed Jun 13 17:47:47 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Wed, 13 Jun 2001 10:47:47 -0700
Subject: doxygen
In-Reply-To: <NABBJEAOKIDHLPHKHPDLMEFBEBAA.allan@stokes.ca>
Message-ID: <209240000.992454467@gandalf.codesourcery.com>



--On Saturday, June 09, 2001 10:57:20 AM -0700 Allan Stokes 
<allan at stokes.ca> wrote:

>
> Has anyone considered the possibility of generating browsable code
> documentation using an automated documentation tool?
>
> The tool I've seen mentioned most often for this purpose is Doxygen.
> http://www.stack.nl/~dimitri/doxygen/

Yes, this is quickly become the open-source JavaDoc for C++.  But,
I haven't used it personally, so I don't know how well it works in
practice.

I think the experiment would be useful.

However, I think it is more important that we get the concepts themselves
documented in DocBook, as we're behind where I had hoped on that task.

How is it coming?  Is there stuff that  people can look at?

Thanks,

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com



From JimC at proximation.com  Wed Jun 13 18:34:03 2001
From: JimC at proximation.com (James Crotinger)
Date: Wed, 13 Jun 2001 11:34:03 -0700
Subject: [pooma-dev] Problems Compiling Pooma 2 with gcc snapshot date
	d 5/27/01
Message-ID: <F871BB04B0EA224A821A5274C31DF3152C42@proxim-sf001.santafe.proximation.com>

Dave, try again. Ambro had put

extern "C" {
#include <string.h>
}

in two of the files in that directory, and that may have been causing a
problem. If this doesn't fix it, then it sounds like a GCC problem since
memcpy is supposed to be in string.h.

	Jim

> -----Original Message-----
> From: Dave Nystrom [mailto:wdn at lanl.gov]
> Sent: Wednesday, June 13, 2001 11:38 AM
> To: pooma-dev
> Cc: Don Marshall
> Subject: [pooma-dev] Problems Compiling Pooma 2 with gcc 
> snapshot dated
> 5/27/01
> 
[...]

> /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
> ers.h: In 
>    function `int streamOut(char*&, const T&) [with T = int]':
> /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
> ers.h:133:   instantiated from `int serialize(Stream&, const 
> T&) [with Stream = ch
> ar*, T = int]'
> /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
ers.cmpl.cpp:111:   instantiated from > here
> /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
> ers.h:71: `memcpy'
>    undeclared (first use this function)
> /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
> ers.h:71: (Each 
>    undeclared identifier is reported only once for each 
> function it appears 
>    in.)
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010613/420dcf94/attachment.html>

From wdn at lanl.gov  Wed Jun 13 19:13:10 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Wed, 13 Jun 2001 13:13:10 -0600
Subject: [pooma-dev] Problems Compiling Pooma 2 with gcc snapshot date
	d 5/27/01
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152C42@proxim-sf001.santafe.proximation.com>
References: <F871BB04B0EA224A821A5274C31DF3152C42@proxim-sf001.santafe.proximation.com>
Message-ID: <15143.47942.798782.559161@saltydog.lanl.gov>

Hi Jim,

Thanks.  I tried your change and I still get the same result - failed compile
with the same error message.

Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046

James Crotinger writes:
 > Dave, try again. Ambro had put
 > 
 > extern "C" {
 > #include <string.h>
 > }
 > 
 > in two of the files in that directory, and that may have been causing a
 > problem. If this doesn't fix it, then it sounds like a GCC problem since
 > memcpy is supposed to be in string.h.
 > 
 > 	Jim
 > 
 > > -----Original Message-----
 > > From: Dave Nystrom [mailto:wdn at lanl.gov]
 > > Sent: Wednesday, June 13, 2001 11:38 AM
 > > To: pooma-dev
 > > Cc: Don Marshall
 > > Subject: [pooma-dev] Problems Compiling Pooma 2 with gcc 
 > > snapshot dated
 > > 5/27/01
 > > 
 > [...]
 > 
 > > /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
 > > ers.h: In 
 > >    function `int streamOut(char*&, const T&) [with T = int]':
 > > /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
 > > ers.h:133:   instantiated from `int serialize(Stream&, const 
 > > T&) [with Stream = ch
 > > ar*, T = int]'
 > > /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
 > ers.cmpl.cpp:111:   instantiated from > here
 > > /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
 > > ers.h:71: `memcpy'
 > >    undeclared (first use this function)
 > > /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
 > > ers.h:71: (Each 
 > >    undeclared identifier is reported only once for each 
 > > function it appears 
 > >    in.)
 > > 
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
 > <TITLE>RE: [pooma-dev] Problems Compiling Pooma 2 with gcc snapshot dated 5/27/01</TITLE>
 > </HEAD>
 > <BODY>
 > 
 > <P><FONT SIZE=2>Dave, try again. Ambro had put</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>extern &quot;C&quot; {</FONT>
 > <BR><FONT SIZE=2>#include &lt;string.h&gt;</FONT>
 > <BR><FONT SIZE=2>}</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>in two of the files in that directory, and that may have been causing a problem. If this doesn't fix it, then it sounds like a GCC problem since memcpy is supposed to be in string.h.</FONT></P>
 > 
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Jim</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
 > <BR><FONT SIZE=2>&gt; From: Dave Nystrom [<A HREF="mailto:wdn at lanl.gov">mailto:wdn at lanl.gov</A>]</FONT>
 > <BR><FONT SIZE=2>&gt; Sent: Wednesday, June 13, 2001 11:38 AM</FONT>
 > <BR><FONT SIZE=2>&gt; To: pooma-dev</FONT>
 > <BR><FONT SIZE=2>&gt; Cc: Don Marshall</FONT>
 > <BR><FONT SIZE=2>&gt; Subject: [pooma-dev] Problems Compiling Pooma 2 with gcc </FONT>
 > <BR><FONT SIZE=2>&gt; snapshot dated</FONT>
 > <BR><FONT SIZE=2>&gt; 5/27/01</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>[...]</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&gt; /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ</FONT>
 > <BR><FONT SIZE=2>&gt; ers.h: In </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; function `int streamOut(char*&amp;, const T&amp;) [with T = int]':</FONT>
 > <BR><FONT SIZE=2>&gt; /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ</FONT>
 > <BR><FONT SIZE=2>&gt; ers.h:133:&nbsp;&nbsp; instantiated from `int serialize(Stream&amp;, const </FONT>
 > <BR><FONT SIZE=2>&gt; T&amp;) [with Stream = ch</FONT>
 > <BR><FONT SIZE=2>&gt; ar*, T = int]'</FONT>
 > <BR><FONT SIZE=2>&gt; /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ</FONT>
 > <BR><FONT SIZE=2>ers.cmpl.cpp:111:&nbsp;&nbsp; instantiated from &gt; here</FONT>
 > <BR><FONT SIZE=2>&gt; /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ</FONT>
 > <BR><FONT SIZE=2>&gt; ers.h:71: `memcpy'</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; undeclared (first use this function)</FONT>
 > <BR><FONT SIZE=2>&gt; /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ</FONT>
 > <BR><FONT SIZE=2>&gt; ers.h:71: (Each </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; undeclared identifier is reported only once for each </FONT>
 > <BR><FONT SIZE=2>&gt; function it appears </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; in.)</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > </P>
 > 
 > </BODY>
 > </HTML>


From JimC at proximation.com  Wed Jun 13 19:30:53 2001
From: JimC at proximation.com (James Crotinger)
Date: Wed, 13 Jun 2001 12:30:53 -0700
Subject: [pooma-dev] Problems Compiling Pooma 2 with gcc snapshot date
	 d 5/27/01
Message-ID: <F871BB04B0EA224A821A5274C31DF3152C43@proxim-sf001.santafe.proximation.com>

Did you look at GCC's string.h? memcpy should be declared in there. If not,
I think this is a GCC bug. 

	Jim


> -----Original Message-----
> From: Dave Nystrom [mailto:wdn at lanl.gov]
> Sent: Wednesday, June 13, 2001 1:13 PM
> To: James Crotinger
> Cc: 'Dave Nystrom'; pooma-dev; Don Marshall
> Subject: RE: [pooma-dev] Problems Compiling Pooma 2 with gcc snapshot
> date d 5/27/01
> 
> 
> Hi Jim,
> 
> Thanks.  I tried your change and I still get the same result 
> - failed compile
> with the same error message.
> 
> Dave Nystrom			email: wdn at lanl.gov
> LANL X-3			phone: 505-667-7913	fax: 
> 505-665-3046
> 
> James Crotinger writes:
>  > Dave, try again. Ambro had put
>  > 
>  > extern "C" {
>  > #include <string.h>
>  > }
>  > 
>  > in two of the files in that directory, and that may have 
> been causing a
>  > problem. If this doesn't fix it, then it sounds like a GCC 
> problem since
>  > memcpy is supposed to be in string.h.
>  > 
>  > 	Jim
>  > 
>  > > -----Original Message-----
>  > > From: Dave Nystrom [mailto:wdn at lanl.gov]
>  > > Sent: Wednesday, June 13, 2001 11:38 AM
>  > > To: pooma-dev
>  > > Cc: Don Marshall
>  > > Subject: [pooma-dev] Problems Compiling Pooma 2 with gcc 
>  > > snapshot dated
>  > > 5/27/01
>  > > 
>  > [...]
>  > 
>  > > /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
>  > > ers.h: In 
>  > >    function `int streamOut(char*&, const T&) [with T = int]':
>  > > /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
>  > > ers.h:133:   instantiated from `int serialize(Stream&, const 
>  > > T&) [with Stream = ch
>  > > ar*, T = int]'
>  > > /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
>  > ers.cmpl.cpp:111:   instantiated from > here
>  > > /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
>  > > ers.h:71: `memcpy'
>  > >    undeclared (first use this function)
>  > > /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ
>  > > ers.h:71: (Each 
>  > >    undeclared identifier is reported only once for each 
>  > > function it appears 
>  > >    in.)
>  > > 
>  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
>  > <HTML>
>  > <HEAD>
>  > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; 
> charset=iso-8859-1">
>  > <META NAME="Generator" CONTENT="MS Exchange Server version 
> 5.5.2650.12">
>  > <TITLE>RE: [pooma-dev] Problems Compiling Pooma 2 with gcc 
> snapshot dated 5/27/01</TITLE>
>  > </HEAD>
>  > <BODY>
>  > 
>  > <P><FONT SIZE=2>Dave, try again. Ambro had put</FONT>
>  > </P>
>  > 
>  > <P><FONT SIZE=2>extern &quot;C&quot; {</FONT>
>  > <BR><FONT SIZE=2>#include &lt;string.h&gt;</FONT>
>  > <BR><FONT SIZE=2>}</FONT>
>  > </P>
>  > 
>  > <P><FONT SIZE=2>in two of the files in that directory, and 
> that may have been causing a problem. If this doesn't fix it, 
> then it sounds like a GCC problem since memcpy is supposed to 
> be in string.h.</FONT></P>
>  > 
>  > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
> SIZE=2>Jim</FONT>
>  > </P>
>  > 
>  > <P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
>  > <BR><FONT SIZE=2>&gt; From: Dave Nystrom [<A 
> HREF="mailto:wdn at lanl.gov">mailto:wdn at lanl.gov</A>]</FONT>
>  > <BR><FONT SIZE=2>&gt; Sent: Wednesday, June 13, 2001 11:38 
> AM</FONT>
>  > <BR><FONT SIZE=2>&gt; To: pooma-dev</FONT>
>  > <BR><FONT SIZE=2>&gt; Cc: Don Marshall</FONT>
>  > <BR><FONT SIZE=2>&gt; Subject: [pooma-dev] Problems 
> Compiling Pooma 2 with gcc </FONT>
>  > <BR><FONT SIZE=2>&gt; snapshot dated</FONT>
>  > <BR><FONT SIZE=2>&gt; 5/27/01</FONT>
>  > <BR><FONT SIZE=2>&gt; </FONT>
>  > <BR><FONT SIZE=2>[...]</FONT>
>  > </P>
>  > 
>  > <P><FONT SIZE=2>&gt; 
> /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ</FONT>
>  > <BR><FONT SIZE=2>&gt; ers.h: In </FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; function `int 
> streamOut(char*&amp;, const T&amp;) [with T = int]':</FONT>
>  > <BR><FONT SIZE=2>&gt; 
> /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ</FONT>
>  > <BR><FONT SIZE=2>&gt; ers.h:133:&nbsp;&nbsp; instantiated 
> from `int serialize(Stream&amp;, const </FONT>
>  > <BR><FONT SIZE=2>&gt; T&amp;) [with Stream = ch</FONT>
>  > <BR><FONT SIZE=2>&gt; ar*, T = int]'</FONT>
>  > <BR><FONT SIZE=2>&gt; 
> /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ</FONT>
>  > <BR><FONT SIZE=2>ers.cmpl.cpp:111:&nbsp;&nbsp; 
> instantiated from &gt; here</FONT>
>  > <BR><FONT SIZE=2>&gt; 
> /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ</FONT>
>  > <BR><FONT SIZE=2>&gt; ers.h:71: `memcpy'</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; undeclared (first 
> use this function)</FONT>
>  > <BR><FONT SIZE=2>&gt; 
> /home/wdn/blanca/packages/Pooma2/r2_2001_05_23/src/IO/Serializ</FONT>
>  > <BR><FONT SIZE=2>&gt; ers.h:71: (Each </FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; undeclared 
> identifier is reported only once for each </FONT>
>  > <BR><FONT SIZE=2>&gt; function it appears </FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; in.)</FONT>
>  > <BR><FONT SIZE=2>&gt; </FONT>
>  > </P>
>  > 
>  > </BODY>
>  > </HTML>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010613/d5de2ec4/attachment.html>

From wdn at lanl.gov  Wed Jun 13 19:39:48 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Wed, 13 Jun 2001 13:39:48 -0600
Subject: [pooma-dev] Problems Compiling Pooma 2 with gcc snapshot date
	 d 5/27/01
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152C43@proxim-sf001.santafe.proximation.com>
References: <F871BB04B0EA224A821A5274C31DF3152C43@proxim-sf001.santafe.proximation.com>
Message-ID: <15143.49540.572428.637954@saltydog.lanl.gov>

James Crotinger writes:
 > Did you look at GCC's string.h? memcpy should be declared in there. If not,
 > I think this is a GCC bug. 

Here it is.  Looks like memcpy is declared to me.

Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046

/* Copyright (C) 1991,92,93,95,96,97,98,99,2000,2001 Free Software Foundation, Inc.
   This file is part of the GNU C Library.

   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Library General Public License as
   published by the Free Software Foundation; either version 2 of the
   License, or (at your option) any later version.

   The GNU C Library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Library General Public License for more details.

   You should have received a copy of the GNU Library General Public
   License along with the GNU C Library; see the file COPYING.LIB.  If not,
   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
   Boston, MA 02111-1307, USA.  */

/*
 *	ISO C99 Standard: 7.21 String handling	<string.h>
 */

#ifndef	_STRING_H
#define	_STRING_H	1

#include <features.h>

__BEGIN_DECLS

/* Get size_t and NULL from <stddef.h>.  */
#define	__need_size_t
#define	__need_NULL
#include <stddef.h>


/* Copy N bytes of SRC to DEST.  */
extern void *memcpy (void *__restrict __dest,
		     __const void *__restrict __src, size_t __n) __THROW;
/* Copy N bytes of SRC to DEST, guaranteeing
   correct behavior for overlapping strings.  */
extern void *memmove (void *__dest, __const void *__src, size_t __n)
     __THROW;

/* Copy no more than N bytes of SRC to DEST, stopping when C is found.
   Return the position in DEST one byte past where C was copied,
   or NULL if C was not found in the first N bytes of SRC.  */
#if defined __USE_SVID || defined __USE_BSD || defined __USE_XOPEN
extern void *memccpy (void *__restrict __dest, __const void *__restrict __src,
		      int __c, size_t __n)
     __THROW;
#endif /* SVID.  */


/* Set N bytes of S to C.  */
extern void *memset (void *__s, int __c, size_t __n) __THROW;

/* Compare N bytes of S1 and S2.  */
extern int memcmp (__const void *__s1, __const void *__s2, size_t __n)
     __THROW __attribute_pure__;

/* Search N bytes of S for C.  */
extern void *memchr (__const void *__s, int __c, size_t __n)
      __THROW __attribute_pure__;

#ifdef __USE_GNU
/* Search in S for C.  This is similar to `memchr' but there is no
   length limit.  */
extern void *rawmemchr (__const void *__s, int __c) __THROW __attribute_pure__;

/* Search N bytes of S for the final occurrence of C.  */
extern void *memrchr (__const void *__s, int __c, size_t __n)
      __THROW __attribute_pure__;
#endif


/* Copy SRC to DEST.  */
extern char *strcpy (char *__restrict __dest, __const char *__restrict __src)
     __THROW;
/* Copy no more than N characters of SRC to DEST.  */
extern char *strncpy (char *__restrict __dest,
		      __const char *__restrict __src, size_t __n) __THROW;

/* Append SRC onto DEST.  */
extern char *strcat (char *__restrict __dest, __const char *__restrict __src)
     __THROW;
/* Append no more than N characters from SRC onto DEST.  */
extern char *strncat (char *__restrict __dest, __const char *__restrict __src,
		      size_t __n) __THROW;

/* Compare S1 and S2.  */
extern int strcmp (__const char *__s1, __const char *__s2)
     __THROW __attribute_pure__;
/* Compare N characters of S1 and S2.  */
extern int strncmp (__const char *__s1, __const char *__s2, size_t __n)
     __THROW __attribute_pure__;

/* Compare the collated forms of S1 and S2.  */
extern int strcoll (__const char *__s1, __const char *__s2)
     __THROW __attribute_pure__;
/* Put a transformation of SRC into no more than N bytes of DEST.  */
extern size_t strxfrm (char *__restrict __dest,
		       __const char *__restrict __src, size_t __n) __THROW;

#ifdef __USE_GNU
/* The following functions are equivalent to the both above but they
   take the locale they use for the collation as an extra argument.
   This is not standardsized but something like will come.  */
# include <xlocale.h>

/* Compare the collated forms of S1 and S2 using rules from L.  */
extern int __strcoll_l (__const char *__s1, __const char *__s2, __locale_t __l)
     __THROW __attribute_pure__;
/* Put a transformation of SRC into no more than N bytes of DEST.  */
extern size_t __strxfrm_l (char *__dest, __const char *__src, size_t __n,
			   __locale_t __l) __THROW;
#endif

#if defined __USE_SVID || defined __USE_BSD || defined __USE_XOPEN_EXTENDED
/* Duplicate S, returning an identical malloc'd string.  */
extern char *strdup (__const char *__s) __THROW __attribute_malloc__;
#endif

/* Return a malloc'd copy of at most N bytes of STRING.  The
   resultant string is terminated even if no null terminator
   appears before STRING[N].  */
#if defined __USE_GNU
extern char *strndup (__const char *__string, size_t __n)
     __THROW __attribute_malloc__;
#endif

#if defined __USE_GNU && defined __GNUC__
/* Duplicate S, returning an identical alloca'd string.  */
# define strdupa(s)							      \
  (__extension__							      \
    ({									      \
      __const char *__old = (s);					      \
      size_t __len = strlen (__old) + 1;				      \
      char *__new = __builtin_alloca (__len);				      \
      (char *) memcpy (__new, __old, __len);				      \
    }))

/* Return an alloca'd copy of at most N bytes of string.  */
# define strndupa(s, n)							      \
  (__extension__							      \
    ({									      \
      __const char *__old = (s);					      \
      size_t __len = strnlen (__old, (n));				      \
      char *__new = __builtin_alloca (__len + 1);			      \
      __new[__len] = '\0';						      \
      (char *) memcpy (__new, __old, __len);				      \
    }))
#endif

/* Find the first occurrence of C in S.  */
extern char *strchr (__const char *__s, int __c) __THROW __attribute_pure__;
/* Find the last occurrence of C in S.  */
extern char *strrchr (__const char *__s, int __c) __THROW __attribute_pure__;

#ifdef __USE_GNU
/* This funciton is similar to `strchr'.  But it returns a pointer to
   the closing NUL byte in case C is not found in S.  */
extern char *strchrnul (__const char *__s, int __c) __THROW __attribute_pure__;
#endif

/* Return the length of the initial segment of S which
   consists entirely of characters not in REJECT.  */
extern size_t strcspn (__const char *__s, __const char *__reject)
     __THROW __attribute_pure__;
/* Return the length of the initial segment of S which
   consists entirely of characters in ACCEPT.  */
extern size_t strspn (__const char *__s, __const char *__accept)
     __THROW __attribute_pure__;
/* Find the first occurrence in S of any character in ACCEPT.  */
extern char *strpbrk (__const char *__s, __const char *__accept)
     __THROW __attribute_pure__;
/* Find the first occurrence of NEEDLE in HAYSTACK.  */
extern char *strstr (__const char *__haystack, __const char *__needle)
     __THROW __attribute_pure__;

#ifdef __USE_GNU
/* Similar to `strstr' but this function ignores the case of both strings.  */
extern char *strcasestr (__const char *__haystack, __const char *__needle)
     __THROW __attribute_pure__;
#endif

/* Divide S into tokens separated by characters in DELIM.  */
extern char *strtok (char *__restrict __s, __const char *__restrict __delim)
     __THROW;

/* Divide S into tokens separated by characters in DELIM.  Information
   passed between calls are stored in SAVE_PTR.  */
extern char *__strtok_r (char *__restrict __s,
			 __const char *__restrict __delim,
			 char **__restrict __save_ptr) __THROW;
#if defined __USE_POSIX || defined __USE_MISC
extern char *strtok_r (char *__restrict __s, __const char *__restrict __delim,
		       char **__restrict __save_ptr) __THROW;
#endif

#ifdef __USE_GNU
/* Find the first occurrence of NEEDLE in HAYSTACK.
   NEEDLE is NEEDLELEN bytes long;
   HAYSTACK is HAYSTACKLEN bytes long.  */
extern void *memmem (__const void *__haystack, size_t __haystacklen,
		     __const void *__needle, size_t __needlelen)
     __THROW __attribute_pure__;

/* Copy N bytes of SRC to DEST, return pointer to bytes after the
   last written byte.  */
extern void *__mempcpy (void *__restrict __dest,
			__const void *__restrict __src, size_t __n) __THROW;
extern void *mempcpy (void *__restrict __dest,
		      __const void *__restrict __src, size_t __n) __THROW;
#endif


/* Return the length of S.  */
extern size_t strlen (__const char *__s) __THROW __attribute_pure__;

#ifdef	__USE_GNU
/* Find the length of STRING, but scan at most MAXLEN characters.
   If no '\0' terminator is found in that many characters, return MAXLEN.  */
extern size_t strnlen (__const char *__string, size_t __maxlen)
     __THROW __attribute_pure__;
#endif


/* Return a string describing the meaning of the `errno' code in ERRNUM.  */
extern char *strerror (int __errnum) __THROW;
#ifdef	__USE_MISC
/* Reentrant version of `strerror'.  If a temporary buffer is required, at
   most BUFLEN bytes of BUF will be used.  */
extern char *strerror_r (int __errnum, char *__buf, size_t __buflen) __THROW;
#endif

/* We define this function always since `bzero' is sometimes needed when
   the namespace rules does not allow this.  */
extern void __bzero (void *__s, size_t __n) __THROW;

#if defined __USE_BSD
/* Copy N bytes of SRC to DEST (like memmove, but args reversed).  */
extern void bcopy (__const void *__src, void *__dest, size_t __n) __THROW;

/* Set N bytes of S to 0.  */
extern void bzero (void *__s, size_t __n) __THROW;

/* Compare N bytes of S1 and S2 (same as memcmp).  */
extern int bcmp (__const void *__s1, __const void *__s2, size_t __n)
     __THROW __attribute_pure__;

/* Find the first occurrence of C in S (same as strchr).  */
extern char *index (__const char *__s, int __c) __THROW __attribute_pure__;

/* Find the last occurrence of C in S (same as strrchr).  */
extern char *rindex (__const char *__s, int __c) __THROW __attribute_pure__;

/* Return the position of the first bit set in I, or 0 if none are set.
   The least-significant bit is position 1, the most-significant 32.  */
extern int ffs (int __i) __THROW __attribute__ ((const));

/* The following two functions are non-standard but necessary for non-32 bit
   platforms.  */
# ifdef	__USE_GNU
extern int ffsl (long int __l) __THROW __attribute__ ((const));
#  ifdef __GNUC__
__extension__ extern int ffsll (long long int __ll)
     __THROW __attribute__ ((const));
#  endif
# endif

/* Compare S1 and S2, ignoring case.  */
extern int strcasecmp (__const char *__s1, __const char *__s2)
     __THROW __attribute_pure__;

/* Compare no more than N chars of S1 and S2, ignoring case.  */
extern int strncasecmp (__const char *__s1, __const char *__s2, size_t __n)
     __THROW __attribute_pure__;
#endif /* Use BSD.  */

#ifdef	__USE_GNU
/* Again versions of a few functions which use the given locale instead
   of the global one.  */
extern int __strcasecmp_l (__const char *__s1, __const char *__s2,
			   __locale_t __loc) __THROW __attribute_pure__;

extern int __strncasecmp_l (__const char *__s1, __const char *__s2,
			    size_t __n, __locale_t __loc)
     __THROW __attribute_pure__;
#endif

#ifdef	__USE_BSD
/* Return the next DELIM-delimited token from *STRINGP,
   terminating it with a '\0', and update *STRINGP to point past it.  */
extern char *strsep (char **__restrict __stringp,
		     __const char *__restrict __delim) __THROW;
#endif

#ifdef	__USE_GNU
/* Compare S1 and S2 as strings holding name & indices/version numbers.  */
extern int strverscmp (__const char *__s1, __const char *__s2)
     __THROW __attribute_pure__;

/* Return a string describing the meaning of the signal number in SIG.  */
extern char *strsignal (int __sig) __THROW;

/* Copy SRC to DEST, returning the address of the terminating '\0' in DEST.  */
extern char *__stpcpy (char *__restrict __dest, __const char *__restrict __src)
     __THROW;
extern char *stpcpy (char *__restrict __dest, __const char *__restrict __src)
     __THROW;

/* Copy no more than N characters of SRC to DEST, returning the address of
   the last character written into DEST.  */
extern char *__stpncpy (char *__restrict __dest,
			__const char *__restrict __src, size_t __n) __THROW;
extern char *stpncpy (char *__restrict __dest,
		      __const char *__restrict __src, size_t __n) __THROW;

/* Sautee STRING briskly.  */
extern char *strfry (char *__string) __THROW;

/* Frobnicate N bytes of S.  */
extern void *memfrob (void *__s, size_t __n) __THROW;

# ifndef basename
/* Return the file name within directory of FILENAME.  We don't
   declare the function if the `basename' macro is available (defined
   in <libgen.h>) which makes the XPG version of this function
   available.  */
extern char *basename (__const char *__filename) __THROW;
# endif
#endif


#if defined __GNUC__ && __GNUC__ >= 2
# if defined __OPTIMIZE__ && !defined __OPTIMIZE_SIZE__ && !defined __cplusplus
/* When using GNU CC we provide some optimized versions of selected
   functions from this header.  There are two kinds of optimizations:

   - machine-dependent optimizations, most probably using inline
     assembler code; these might be quite expensive since the code
     size can increase significantly.
     These optimizations are not used unless the symbol
	__USE_STRING_INLINES
     is defined before including this header.

   - machine-independent optimizations which do not increase the
     code size significantly and which optimize mainly situations
     where one or more arguments are compile-time constants.
     These optimizations are used always when the compiler is
     taught to optimize.

   One can inhibit all optimizations by defining __NO_STRING_INLINES.  */

/* Get the machine-dependent optimizations (if any).  */
#  include <bits/string.h>

/* These are generic optimizations which do not add too much inline code.  */
#  include <bits/string2.h>
# endif
#endif

__END_DECLS

#endif /* string.h  */


From wdn at lanl.gov  Thu Jun 14 21:39:18 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Thu, 14 Jun 2001 15:39:18 -0600
Subject: Building and Running Pooma 2 Tests
Message-ID: <15145.12038.817213.693193@saltydog.lanl.gov>

Could someone give me some explanation about how to build and run the various
types of test problems for Pooma 2 in a Unix environment.  My impression is
that there are several types of test problems available within the Pooma 2
distribution i.e. Tutorials, Unit tests, Examples and Benchmarks.  I'm
interested in all of these but am most interested in the Unit tests for
Arrays and Fields.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From JimC at proximation.com  Thu Jun 14 21:45:27 2001
From: JimC at proximation.com (James Crotinger)
Date: Thu, 14 Jun 2001 14:45:27 -0700
Subject: [pooma-dev] Building and Running Pooma 2 Tests
Message-ID: <F871BB04B0EA224A821A5274C31DF3152C48@proxim-sf001.santafe.proximation.com>

Go to src/Array/tests and type "make" (ditto for Field, or whatever) - I
believe that will make them all. You can type "make run_tests" and it will
build them and run them. There should be some make variables use in the
makefile that will allow using various options for all of the runs.

	Jim

> -----Original Message-----
> From: Dave Nystrom [mailto:wdn at lanl.gov]
> Sent: Thursday, June 14, 2001 3:39 PM
> To: pooma-dev
> Subject: [pooma-dev] Building and Running Pooma 2 Tests
> 
> 
> Could someone give me some explanation about how to build and 
> run the various
> types of test problems for Pooma 2 in a Unix environment.  My 
> impression is
> that there are several types of test problems available 
> within the Pooma 2
> distribution i.e. Tutorials, Unit tests, Examples and Benchmarks.  I'm
> interested in all of these but am most interested in the Unit 
> tests for
> Arrays and Fields.
> 
> -- 
> Dave Nystrom			email: wdn at lanl.gov
> LANL X-3			phone: 505-667-7913	fax: 
> 505-665-3046
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010614/a6acc020/attachment.html>

From wdn at lanl.gov  Thu Jun 14 22:46:58 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Thu, 14 Jun 2001 16:46:58 -0600
Subject: [pooma-dev] Building and Running Pooma 2 Tests
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152C48@proxim-sf001.santafe.proximation.com>
References: <F871BB04B0EA224A821A5274C31DF3152C48@proxim-sf001.santafe.proximation.com>
Message-ID: <15145.16098.662712.2681@saltydog.lanl.gov>

How does your Unix build system know what suite to use?  I've built several
different flavors of Pooma 2 on my laptop.  Is this handled automatically?

Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046

James Crotinger writes:
 > Go to src/Array/tests and type "make" (ditto for Field, or whatever) - I
 > believe that will make them all. You can type "make run_tests" and it will
 > build them and run them. There should be some make variables use in the
 > makefile that will allow using various options for all of the runs.
 > 
 > 	Jim
 > 
 > > -----Original Message-----
 > > From: Dave Nystrom [mailto:wdn at lanl.gov]
 > > Sent: Thursday, June 14, 2001 3:39 PM
 > > To: pooma-dev
 > > Subject: [pooma-dev] Building and Running Pooma 2 Tests
 > > 
 > > 
 > > Could someone give me some explanation about how to build and 
 > > run the various
 > > types of test problems for Pooma 2 in a Unix environment.  My 
 > > impression is
 > > that there are several types of test problems available 
 > > within the Pooma 2
 > > distribution i.e. Tutorials, Unit tests, Examples and Benchmarks.  I'm
 > > interested in all of these but am most interested in the Unit 
 > > tests for
 > > Arrays and Fields.
 > > 
 > > -- 
 > > Dave Nystrom			email: wdn at lanl.gov
 > > LANL X-3			phone: 505-667-7913	fax: 
 > > 505-665-3046
 > > 
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
 > <TITLE>RE: [pooma-dev] Building and Running Pooma 2 Tests</TITLE>
 > </HEAD>
 > <BODY>
 > 
 > <P><FONT SIZE=2>Go to src/Array/tests and type &quot;make&quot; (ditto for Field, or whatever) - I believe that will make them all. You can type &quot;make run_tests&quot; and it will build them and run them. There should be some make variables use in the makefile that will allow using various options for all of the runs.</FONT></P>
 > 
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Jim</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
 > <BR><FONT SIZE=2>&gt; From: Dave Nystrom [<A HREF="mailto:wdn at lanl.gov">mailto:wdn at lanl.gov</A>]</FONT>
 > <BR><FONT SIZE=2>&gt; Sent: Thursday, June 14, 2001 3:39 PM</FONT>
 > <BR><FONT SIZE=2>&gt; To: pooma-dev</FONT>
 > <BR><FONT SIZE=2>&gt; Subject: [pooma-dev] Building and Running Pooma 2 Tests</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; Could someone give me some explanation about how to build and </FONT>
 > <BR><FONT SIZE=2>&gt; run the various</FONT>
 > <BR><FONT SIZE=2>&gt; types of test problems for Pooma 2 in a Unix environment.&nbsp; My </FONT>
 > <BR><FONT SIZE=2>&gt; impression is</FONT>
 > <BR><FONT SIZE=2>&gt; that there are several types of test problems available </FONT>
 > <BR><FONT SIZE=2>&gt; within the Pooma 2</FONT>
 > <BR><FONT SIZE=2>&gt; distribution i.e. Tutorials, Unit tests, Examples and Benchmarks.&nbsp; I'm</FONT>
 > <BR><FONT SIZE=2>&gt; interested in all of these but am most interested in the Unit </FONT>
 > <BR><FONT SIZE=2>&gt; tests for</FONT>
 > <BR><FONT SIZE=2>&gt; Arrays and Fields.</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; -- </FONT>
 > <BR><FONT SIZE=2>&gt; Dave Nystrom&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; email: wdn at lanl.gov</FONT>
 > <BR><FONT SIZE=2>&gt; LANL X-3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; phone: 505-667-7913&nbsp;&nbsp;&nbsp;&nbsp; fax: </FONT>
 > <BR><FONT SIZE=2>&gt; 505-665-3046</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > </P>
 > 
 > </BODY>
 > </HTML>


From JimC at proximation.com  Thu Jun 14 23:24:15 2001
From: JimC at proximation.com (James Crotinger)
Date: Thu, 14 Jun 2001 16:24:15 -0700
Subject: [pooma-dev] Building and Running Pooma 2 Tests
Message-ID: <F871BB04B0EA224A821A5274C31DF3152C49@proxim-sf001.santafe.proximation.com>

I always set the SUITE environment variable (I think POOMASUITE is also
allowed). 

  Jim

> -----Original Message-----
> From: Dave Nystrom [mailto:wdn at lanl.gov]
> Sent: Thursday, June 14, 2001 4:47 PM
> To: James Crotinger
> Cc: pooma-dev
> Subject: RE: [pooma-dev] Building and Running Pooma 2 Tests
> 
> 
> How does your Unix build system know what suite to use?  I've 
> built several
> different flavors of Pooma 2 on my laptop.  Is this handled 
> automatically?
> 
> Dave Nystrom			email: wdn at lanl.gov
> LANL X-3			phone: 505-667-7913	fax: 
> 505-665-3046
> 
> James Crotinger writes:
>  > Go to src/Array/tests and type "make" (ditto for Field, or 
> whatever) - I
>  > believe that will make them all. You can type "make 
> run_tests" and it will
>  > build them and run them. There should be some make 
> variables use in the
>  > makefile that will allow using various options for all of the runs.
>  > 
>  > 	Jim
>  > 
>  > > -----Original Message-----
>  > > From: Dave Nystrom [mailto:wdn at lanl.gov]
>  > > Sent: Thursday, June 14, 2001 3:39 PM
>  > > To: pooma-dev
>  > > Subject: [pooma-dev] Building and Running Pooma 2 Tests
>  > > 
>  > > 
>  > > Could someone give me some explanation about how to build and 
>  > > run the various
>  > > types of test problems for Pooma 2 in a Unix environment.  My 
>  > > impression is
>  > > that there are several types of test problems available 
>  > > within the Pooma 2
>  > > distribution i.e. Tutorials, Unit tests, Examples and 
> Benchmarks.  I'm
>  > > interested in all of these but am most interested in the Unit 
>  > > tests for
>  > > Arrays and Fields.
>  > > 
>  > > -- 
>  > > Dave Nystrom			email: wdn at lanl.gov
>  > > LANL X-3			phone: 505-667-7913	fax: 
>  > > 505-665-3046
>  > > 
>  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
>  > <HTML>
>  > <HEAD>
>  > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; 
> charset=iso-8859-1">
>  > <META NAME="Generator" CONTENT="MS Exchange Server version 
> 5.5.2650.12">
>  > <TITLE>RE: [pooma-dev] Building and Running Pooma 2 Tests</TITLE>
>  > </HEAD>
>  > <BODY>
>  > 
>  > <P><FONT SIZE=2>Go to src/Array/tests and type 
> &quot;make&quot; (ditto for Field, or whatever) - I believe 
> that will make them all. You can type &quot;make 
> run_tests&quot; and it will build them and run them. There 
> should be some make variables use in the makefile that will 
> allow using various options for all of the runs.</FONT></P>
>  > 
>  > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
> SIZE=2>Jim</FONT>
>  > </P>
>  > 
>  > <P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
>  > <BR><FONT SIZE=2>&gt; From: Dave Nystrom [<A 
> HREF="mailto:wdn at lanl.gov">mailto:wdn at lanl.gov</A>]</FONT>
>  > <BR><FONT SIZE=2>&gt; Sent: Thursday, June 14, 2001 3:39 PM</FONT>
>  > <BR><FONT SIZE=2>&gt; To: pooma-dev</FONT>
>  > <BR><FONT SIZE=2>&gt; Subject: [pooma-dev] Building and 
> Running Pooma 2 Tests</FONT>
>  > <BR><FONT SIZE=2>&gt; </FONT>
>  > <BR><FONT SIZE=2>&gt; </FONT>
>  > <BR><FONT SIZE=2>&gt; Could someone give me some 
> explanation about how to build and </FONT>
>  > <BR><FONT SIZE=2>&gt; run the various</FONT>
>  > <BR><FONT SIZE=2>&gt; types of test problems for Pooma 2 
> in a Unix environment.&nbsp; My </FONT>
>  > <BR><FONT SIZE=2>&gt; impression is</FONT>
>  > <BR><FONT SIZE=2>&gt; that there are several types of test 
> problems available </FONT>
>  > <BR><FONT SIZE=2>&gt; within the Pooma 2</FONT>
>  > <BR><FONT SIZE=2>&gt; distribution i.e. Tutorials, Unit 
> tests, Examples and Benchmarks.&nbsp; I'm</FONT>
>  > <BR><FONT SIZE=2>&gt; interested in all of these but am 
> most interested in the Unit </FONT>
>  > <BR><FONT SIZE=2>&gt; tests for</FONT>
>  > <BR><FONT SIZE=2>&gt; Arrays and Fields.</FONT>
>  > <BR><FONT SIZE=2>&gt; </FONT>
>  > <BR><FONT SIZE=2>&gt; -- </FONT>
>  > <BR><FONT SIZE=2>&gt; Dave Nystrom&nbsp; 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; email: wdn at lanl.gov</FONT>
>  > <BR><FONT SIZE=2>&gt; LANL 
> X-3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; phone: 
> 505-667-7913&nbsp;&nbsp;&nbsp;&nbsp; fax: </FONT>
>  > <BR><FONT SIZE=2>&gt; 505-665-3046</FONT>
>  > <BR><FONT SIZE=2>&gt; </FONT>
>  > </P>
>  > 
>  > </BODY>
>  > </HTML>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010614/02155335/attachment.html>

From scotth at proximation.com  Fri Jun 15 21:43:49 2001
From: scotth at proximation.com (Scott Haney)
Date: Fri, 15 Jun 2001 15:43:49 -0600
Subject: [pooma-dev] template idiom in the Blitz stencils; TList as a Domain simplification
In-Reply-To: <NABBJEAOKIDHLPHKHPDLOEELEBAA.allan@stokes.ca>
Message-ID: <mailman.39.1331172045.20475.pooma-dev@codesourcery.com>


On Thursday, June 7, 2001, at 07:31 AM, Allan Stokes wrote:

> There might be a case for adopting a TList mechanism to handle vararg
> constructs in Pooma.  The TList itself contains all the nasty code
> replication.  There would no longer be a need for Pooma components to
> replicate member functions on rank.
>
> I don't know to what extend vararg constructs are currently exposed in 
> user
> level contexts, or how much of an imposition it would be to require 
> users to
> package their varargs.
>
> A possible compromise would be to retain the functions for 1 to 3
> dimensions, and only require packaging for extended ranks.  Is having 
> three
> versions any better than having seven?
>
> I'm tossing this construct out first, because it's the least "C++ 
> compliant"
> of all the conveniences which Domain presently offers.  Allowing 
> integers to
> act as a domain type is also a hassle, but at least it's a hassle the
> language endorses.


Hi Allan,

Having one function would be wonderful from an implementation 
perspective; however, I believe that asking the users to package their 
domains would be viewed as ugly and onerous. Providing 7 versions of 
some functions really isn't all that big of a deal, certainly not 
significantly harder than providing 3.

I thought that our approach was C++-compliant. Could you explain where 
it falls short here?

As for integers appearing in a mix of domains, one could legitimately 
argue that this adds a lot of complexity that might better be handled in 
other ways: for example, having  slices require a specific syntax and 
doing indexing with a separate set of member functions.

I do like Todd's approach of defining the stencils. It probably wouldn't 
be horribly hard to try a similar thing with POOMA . Are you interested 
in pursuing a prototype of, say, a cell->cell divergence for comparison 
purposes?

Scott


From oldham at codesourcery.com  Tue Jun 19 18:57:49 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Tue, 19 Jun 2001 11:57:49 -0700
Subject: [pooma-dev] Problems Compiling Pooma 2 with gcc snapshot dated 5/27/01
In-Reply-To: <15143.42250.396584.522130@saltydog.lanl.gov>; from wdn@lanl.gov on Wed, Jun 13, 2001 at 11:38:18AM -0600
References: <15143.42250.396584.522130@saltydog.lanl.gov>
Message-ID: <20010619115749.A4973@codesourcery.com>

On Wed, Jun 13, 2001 at 11:38:18AM -0600, Dave Nystrom wrote:
> I tried building Pooma 2 with the 5/27/01 snapshot of gcc from the
> CodeSourcery web site that Jeffrey recommended.  I'm having compilation
> problems trying to build Pooma 2 with this snapshot of gcc.  Here is how I'm
> trying to build Pooma 2:

I believe this was a gcc3.0 error that was fixed last week.  I just
successfully built the Pooma library using today's gcc 3.0, but I did
not compile and run all the tests.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From oldham at codesourcery.com  Tue Jun 19 19:01:43 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Tue, 19 Jun 2001 12:01:43 -0700
Subject: [pooma-dev] Building and Running Pooma 2 Tests
In-Reply-To: <15145.12038.817213.693193@saltydog.lanl.gov>; from wdn@lanl.gov on Thu, Jun 14, 2001 at 03:39:18PM -0600
References: <15145.12038.817213.693193@saltydog.lanl.gov>
Message-ID: <20010619120143.B4973@codesourcery.com>

On Thu, Jun 14, 2001 at 03:39:18PM -0600, Dave Nystrom wrote:
> Could someone give me some explanation about how to build and run the various
> types of test problems for Pooma 2 in a Unix environment.  My impression is
> that there are several types of test problems available within the Pooma 2
> distribution i.e. Tutorials, Unit tests, Examples and Benchmarks.  I'm
> interested in all of these but am most interested in the Unit tests for
> Arrays and Fields.

2001 March 28, Scott Haney said to avoid use of the BConds,
CoordinateSystems, Field, Geometry, and Meshes directories.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From oldham at codesourcery.com  Wed Jun 20 04:13:18 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Tue, 19 Jun 2001 21:13:18 -0700
Subject: Using Cheetah with Pooma
Message-ID: <20010619211318.A14734@codesourcery.com>

Here are the steps I used to compile Pooma with Cheetah on my
uniprocessor Linux machine.

1. Since I am using a uniprocessor Linux computer, I need to use the
shared memory library mm with Cheetah.

a. Obtain a tarball from http://www.engelschall.com/sw/mm/.
b. tar xzvf mm-1.1.3.tar.gz
   cd mm-1.1.3
c. declare -x CC=/home/oldham/gcc-install/gcc1/bin/gcc
	# I wanted to use my gcc3.0 so I declared its location.
	# Otherwise, some default compiler is used.
d. ./configure --prefix=${HOME}/pooma/mm-1.1.3
	# I wanted the resulting files to be placed in the specified directory.
e. make -j 3
   make -j 3 test	# prints success if all tests pass
   make -j 3 install

2. Install the Cheetah code.

a. Obtain a tarball from http://pooma.codesourcery.com/downloads.
   tar xzvf cheetah-1.0.tgz
   cd cheetah-1.0
b. Modify the source code for correct compilation:
  i. Append "*/" to line 9 of src/Utilities/i386-lock.s
  ii. I copied the attached LINUXgcc.conf to config.
	# Modify all lines containing "oldham" to have proper values for you.
  iii. Modify configure using the attached patch.
c. Configure:
  ./configure --noex --arch LINUXgcc --shmem --nompi --prefix ${HOME}/pooma/cheetah-1.0
	# `--noex' specifies no exceptions
	# QUESTION: Should we use exceptions for Pooma and Cheetah?
	# `--shmem' specifies use of the mm package
	# `--nompi' specifies no use of MPI
	# `--prefix' specifies where to install cheetah
d. Compile.
   cd lib/LINUXgcc
   make -j 3
   make -j 3 tests
   make install

3. Compile Pooma with Cheetah specified.

a. Modify ~/pooma/pooma0/src/config/LINUXgcc.conf by specifying Cheetah's location.
b. ./configure --messaging --arch LINUXgcc --suite LINUXgcc --opt
	# --messaging indicates use of Cheetah
c. declare -x POOMASUITE=LINUXgcc && make -j 3

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
*** cheetah-1.0/configure	Wed Jul  5 09:03:03 2000
--- cheetah-1.0/configure	Tue Jun 19 20:14:14 2001
***************
*** 1,3 ****
! #!/usr/local/bin/perl
  ###########################################################################
  #
--- 1,3 ----
! #!/usr/bin/env perl
  ###########################################################################
  #
***************
*** 546,550 ****
        $cpp = $arghash{$cppnm}[1];
      }
!   $extensions .= $cpp;
  
    if (scalar @{$arghash{$arnm}} > 1)
--- 546,551 ----
        $cpp = $arghash{$cppnm}[1];
      }
!   $extensions .= $comptype;
! #  $extensions .= ((split('/', $cpp))[-1]);
  
    if (scalar @{$arghash{$arnm}} > 1)
-------------- next part --------------
###########################################################################
# Cheetah configuration settings
#
# Platform: LINUX
# Compiler: GNU C++ compiler (g++)
#
###########################################################################
#
# This file contains specialized settings indicating how to build Cheetah
# with this platform and compiler.  This is a perl script executed by
# the 'configure' script at the top level of the Cheetah directory structure.
# This file has two sections:
#   1) The locations of include files and libraries for external packages.
#   3) The specialized settings on how to use this platform and compiler.
# You should edit the lines in section 1) to the proper location of the
# external packages.  Do not edit the lines in section 2) unless you
# know what you're doing.
#
###########################################################################

###########################################################################
# Section 1: external package locations. 
#   Include search directories should have a '-I' prepended.
#   Library search directories should have a '-L' prepended.
#   Library filenames should just list the name or use -l prefix as needed.
#   Required defines should have -a '-D' prepended.
###########################################################################

### location of MM files, for shmem controller (if available)

$has_shmem                 = 1;
$shmem_default_dir         = "/home/oldham/pooma/mm-1.1.3";
$shmem_inc                 = "-I$shmem_default_dir/include";
$shmem_lib                 = "-L$shmem_default_dir/lib -lmm";
$shmem_def                 = "";
$shmem_locksrc             = "Utilities/i386-lock.s";
$shmem_lockobj             = "i386-lock.o";
$shmem_as                  = "as";

### location of ULM files, for ULM controller (if available)

$has_ulm                   = 0;


###########################################################################
# Section 2: compilation settings
###########################################################################


###################
### characteristics
###################

### the name of this architecture

$archtype = "linux";
$comptype = "g++";

### are shared libraries supported?

$canmakesharedlib = 1;
$sharedext = "so";


################
### C++ settings
################

### general settings for using the C++ compiler, for both libs and apps

$cpp        = "/home/oldham/gcc-install/gcc1/bin/g++";

$cppargs    = "-ftemplate-depth-60";

$cppex      = "";                  # flag to use exceptions
$cppnoex    = "-fno-exceptions";   # flag to turn off exceptions

$cppverbose = "-v";                # flag for verbose compiler output

$cppshare   = "-fPIC";             # flag for compiling for shared libs


### debug or optimized build settings for C++ applications

$cppdbg     = "-ggdb";

$cppopt     = "-O3 -funroll-loops -fstrict-aliasing";


###################
### linker settings
###################

$link        = $cpp;

$linkargs    = "-L/home/oldham/gcc-install/gcc1/lib";

$linkverbose = "-Wl,-v";

$linkshare   = "-Wl,-rpath,\$(CHEETAH_LIBDIR)";


#####################
### archiver settings
#####################

$ar          = "ar";

$arargs      = "rcsl";

$arshare     = $cpp;             # program to make shared lib

$arshareargs = "-shared -o";      # arguments to make shared lib


# ACL:rcsinfo
#  ----------------------------------------------------------------------
#  $RCSfile: LINUXGCC.conf,v $   $Author: rasmussn $
#  $Revision: 1.3 $   $Date: 2000/06/26 22:07:27 $
#  ----------------------------------------------------------------------
# ACL:rcsinfo

###########################################################################
# the last line of this file must be a '1' so that Perl sees a non-zero
# results from this file
###########################################################################
1;


From oldham at codesourcery.com  Wed Jun 20 23:40:53 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Wed, 20 Jun 2001 16:40:53 -0700
Subject: Caramana Kernel
Message-ID: <200106202340.QAA13353@oz.codesourcery.com>


	The Caramana hydrodynamics kernel is now available in the Pooma
CVS tree at examples/NewField/Caramana/.

	The initial conditions are a constant pressure and arbitrarily
zero velocities.  The boundary conditions are zero normal components
along the coordinates axes and zero velocity for the origin.

	As the simulation runs, the cells furthest from the origin
should spread away from the origin.  As these spread, the other cells
start spreading.  To make this visible, modify the code to increase
the time step and increase the number of iterations.

	I do not know of analytical solutions to double check the
solution.  Don or Jean, do you know?

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From mark at codesourcery.com  Thu Jun 21 19:50:21 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Thu, 21 Jun 2001 12:50:21 -0700
Subject: Welcome Gabriel Dos Reis
Message-ID: <35190000.993153021@localhost.localdomain>

Gabriel Dos Reis <gdr at codesourcery.com> will be joining the POOMA team. 
Gaby
is an experienced numericist and an excellent C++ programmer.

Gaby, the other developers on this list are:

  Jim Crotinger
  Scott Haney
  Steven Smith
  Jeffrey Oldham
  Julian Cummings
  Allan Stokes

Jim, Scott, Steven, and Julian are part of the original POOMA development 
team.  Scott
is the team leader is responsible for guiding the development process day 
to day.

Gaby, I will need an SSH key from you so that you can work on the POOMA 
source tree.
(We use CVS).  The Open Air project code is "POOMA 2.4".

Gaby, you should begin by visiting www.poooma.com and looking briefly at 
one or two
of the papers there.  Then, once you have CVS access, please get it touch 
with
Jeffrey about building the sources.  Please let me know when you've been 
able to
build one of the included POOMA test programs.  Once you've gotten your 
feet wet,
we'll set you to work.

Welcome!

--
Mark Mitchelll               mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


From mark at codesourcery.com  Thu Jun 21 20:14:14 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Thu, 21 Jun 2001 13:14:14 -0700
Subject: The Big Picture
Message-ID: <36980000.993154454@localhost.localdomain>

Some of you have indicated that the big picture was getting a little fuzzy.

Obviously, LANL is our customer, and therefore we must continue to be 
responsive
to requests for bug-fixes from the Blanca project.  However, it is 
important that
we begin to make much more definitive progress on our major strategic goals.

We have two major strategic goals at this point:

  - Finish the new Field abstraction.

  - Make POOMA run faster.

In the long run, the success of POOMA depends on its ability to combine 
rapid application development with high performance.  Once the Field work 
is complete, including the relationship updaters, we will have a very 
compelling story on the rapid application development front.  In order to 
sell POOMA to industrial customers, however, we need to improve the 
performance.

In order to meet these goals, we will be dividing our efforts into several 
teams:

  Abstraction Team
  ----------------
  Scott Haney [leader]
  Jeffrey Oldham
  Steven Smith

  Performance Team
  ----------------
  Jim Crotinger [leader]
  Gabriel Dos Reis

Meanwhile, Allan will continue to work on documentation and Julian will 
continue to work on making Particles work with the new Fields.

When the Abstraction Team finishes up the work on Fields, it will be merged 
into the
Performance Team, as the performance issues will then dominate the 
remainder of our work.
However, because compile-times are also important, part of the work at that 
time will
be to improve the compile-time performance, probably by reducing the use of 
unncessary
template instantiations.

Scott estimates that the remainder of Field work will take one month.  To 
be conservative,
August 1st will be the goal date for the completion of this work.  By that 
time, we want
to have the stenciling, centering, and updating features implemented, and 
we want to
remove the old Field code from the tree entirely.  Abstraction Team, please 
make every
effort to make this date.  The last month was slow; this month, we should 
be able
to pick up the pace.

Jim will coordinate the performance team.  Scott and I believe that the 
best place for
Gaby to start, once he is up and running, is to look at the Doof2D 
benchmark and to
begin trying to reduce the abstraction penalty.  This will be a good way of 
seeing how
the evaluator code paths operate and will simultaneously give us ideas 
about how to
improve our serial performance.

My job will continue to be non-technical, for the most part.  My major job 
will be marketing: I will be evaluating and contacting potential industrial 
partners, and I
will be publicizing the work that you are doing to a wider audience.

-- The pointy-haired boss


From allan at stokes.ca  Fri Jun 22 18:18:19 2001
From: allan at stokes.ca (Allan Stokes)
Date: Fri, 22 Jun 2001 11:18:19 -0700
Subject: DocBook sample
Message-ID: <NABBJEAOKIDHLPHKHPDLIELKEBAA.allan@stokes.ca>


Hello all,

I have been working on setting up the DocBook tool chain, learning the psgml
authoring environment, and trying to figure out how different DocBook
constructs are rendered by the various backend options.

I have been working on an experimental document which discusses partitioning
strategies.  This document includes equations and some other things I
haven't mastered yet.  While I was comparing my notes to the Pooma source
code I stumbled upon r2/docs/Layout.html which I hadn't noticed in this
connection before.  I've most accessed the tutorial directly off the Pooma
web site and I had forgotten that there were a couple of other pieces.

Last night I decided it would be a reference point to convert this document
into DocBook format.

I did this process almost entirely on the NT side.  The image conversion
from .gif to .png was done with Gimp under Linux.

There are three main pathways in the Jade backend processing.

With the HTML style sheet, Jade generates HTML directly.
With the PRINT style sheet, Jade generates either RTF or TeX.
>From TeX, one can produce PS or PDF.

The biggest problem in the production process is including appropriate image
formats.  Different backends require different image formats to be supplied
from a single source document.

The idea in DocBook is that you declare multiple image sources and each
backend chooses one from the list it is able to handle.  I haven't yet been
able to get that to work as advertised.  In every case I tried explicitly,
the backend choose the first image from the list, even if the backend was
not capable of processing that format.  It's possible I need to find a
customization layer for the stylesheets to impose selectivity.  Stylesheets
do everything in this world.

My conversion focused exclusively on block-level elements.  There are many
DocBook elements which can be applied inline, but these are not yet present.
I have also left the stylesheets in their stock configuration.  Everything
here is virgin Jade/MikTex.  I converted the .gif images with Gimp without
modification, except for the first image which appears, which was too big to
fit on the page in PDF mode.  There's a scaling factor problem between the
HTML and PRINT outputs which I don't yet understand.

Working with psgml I didn't find the process onerous.  It would be more
difficult to do this kind of conversion without using emacs.  psgml has a
quick internal validator which found 90% of my errors immediately.  A very
small number of errors were reported with the external validator after the
internal validation passed.  A somewhat larger body of complaints was
produced by different backends concerning values accepted in attribute tags.
(The DTD doesn't say much about values.)  Nothing was any worse than a
typical error message from a C compiler.

The biggest hassle concerned the angle brackets.  I was relieved to discover
that I could represent &lt; in my text with "<-" and &gt; with "->" and the
SGML tools don't get all huffy about it.  I think the best approach is to
leave the (decorated) angle brackets in code examples during authorship, and
add an extra sed to the final production step.  Manglations like
Dom&lt;int&gt; are simply impossible to read if you are trying to think
seriously about the code you are quoting.

Included is the DocBook source document, the PDF output file, and all the
HTML fragments as one attachment.  Initially I had very poor results from
RTF.  When I went back and looked at RTF it wasn't as bad as I thought, so
I've included it separately as sample RTF output.

Once again I welcome any comments people might have about the DocBook
process or the suitability of DocBook to the kinds of documentation
processes the Pooma project requires.

Allan



Here is the list of files included in the main attachment.

layout-docbook/
layout-docbook/images/
layout-docbook/images/advection1d.png
layout-docbook/images/bordergraph.png
layout-docbook/images/grid-2bisection.png
layout-docbook/images/grid-2D.png
layout-docbook/images/grid-2gl.png
layout-docbook/images/grid-2stl.png
layout-docbook/images/grid-2ugl.png
layout-docbook/images/grid-2uniform.png
layout-docbook/layout.pdf
layout-docbook/layout.sgml
layout-docbook/t1.htm
layout-docbook/x104.htm
layout-docbook/x109.htm
layout-docbook/x120.htm
layout-docbook/x125.htm
layout-docbook/x150.htm
layout-docbook/x155.htm
layout-docbook/x36.htm
layout-docbook/x39.htm
layout-docbook/x44.htm
layout-docbook/x47.htm
layout-docbook/x55.htm
layout-docbook/x59.htm
layout-docbook/x64.htm
layout-docbook/x79.htm
layout-docbook/x82.htm
layout-docbook/x84.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laydb.tgz
Type: application/x-compressed
Size: 70118 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010622/83d1013e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: layout.rtf
Type: application/msword
Size: 13720 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010622/83d1013e/attachment.doc>

From mark at codesourcery.com  Fri Jun 22 18:14:49 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Fri, 22 Jun 2001 11:14:49 -0700
Subject: DocBook sample
In-Reply-To: <NABBJEAOKIDHLPHKHPDLIELKEBAA.allan@stokes.ca>
Message-ID: <346830000.993233689@localhost.localdomain>



]> Last night I decided it would be a reference point to convert this
> document into DocBook format.
>

The experiment seems to have gone pretty well; the PDF looks fine to me.
(Except that `<Dim>' in the first page looks like `<-Dim->'.)  I'm sure
that Docbook has some way of quoting code literally; that's one of it's
major applications.  Alex, is there a way to do the equivalent of

  Here, in the middle of a sentence is some @code{a<b>} code.

?

Anyhow, I'd say you've proved the infrastructure, and that it's time
to move on to the concept docs.

As for the image nuisances, if we need to get serious about generating
more formats than work conveniently, we will simply buy a commercial
formatter if need be.  I would suggest that for now we focus on PDF;
that's conveniently viewable on the web and also easily printable.
HTML would definitely be the second most important format.  Anything
else is a distant third.

Thanks,

--
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


From oldham at codesourcery.com  Fri Jun 22 18:36:18 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Fri, 22 Jun 2001 11:36:18 -0700
Subject: Cheetah 1.0 Improvements
Message-ID: <20010622113618.A25908@codesourcery.com>

Mr. Rasmussen,

	Where do I find the latest version of Cheetah for use with
Pooma?

	For use with Pooma r.2.4 (not yet released), I modified
src/Utilities/i386-lock.s and modified LINUXGCC.conf file to be more
analogous to Pooma's configuration files as well as better support
specifying a different compiler.  Would you please incorporate the
i386-lock.s patch and consider making the LINUXGCC.conf changes?

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
*** i386-lock.s	Mon Apr 17 13:46:39 2000
--- i386-lock.s	Tue Jun 19 17:37:55 2001
***************
*** 6,12 ****
  /* 8(ebp) - address of lock, a long word */
  /* 12(ebp) - winning content, assumed to have a value of 1 */
  
! /* OUTPUT:		
  	.text
  	.align 4
  .globl spinlock
--- 6,12 ----
  /* 8(ebp) - address of lock, a long word */
  /* 12(ebp) - winning content, assumed to have a value of 1 */
  
! /* OUTPUT:		*/
  	.text
  	.align 4
  .globl spinlock
-------------- next part --------------
*** LINUXGCC.conf	Mon Jun 26 15:07:27 2000
--- LINUXGCC.conf	Fri Jun 22 11:34:47 2001
***************
*** 70,76 ****
  
  $cpp        = "g++";
  
! $cppargs    = "-ftemplate-depth-40";
  
  $cppex      = "";                  # flag to use exceptions
  $cppnoex    = "-fno-exceptions";   # flag to turn off exceptions
--- 70,76 ----
  
  $cpp        = "g++";
  
! $cppargs    = "-ftemplate-depth-60";
  
  $cppex      = "";                  # flag to use exceptions
  $cppnoex    = "-fno-exceptions";   # flag to turn off exceptions
***************
*** 84,101 ****
  
  $cppdbg     = "-ggdb";
  
! $cppopt     = "-O3 -funroll-loops";
  
  
  ###################
  ### linker settings
  ###################
  
! $link        = "g++";
  
  $linkargs    = "\$(CHEETAH_CXX_ARGS)";
  
! $linkverbose = "";
  
  $linkshare   = "-Wl,-rpath,\$(CHEETAH_LIBDIR)";
  
--- 84,101 ----
  
  $cppdbg     = "-ggdb";
  
! $cppopt     = "-O3 -funroll-loops -fstrict-aliasing";
  
  
  ###################
  ### linker settings
  ###################
  
! $link        = $cpp;
  
  $linkargs    = "\$(CHEETAH_CXX_ARGS)";
  
! $linkverbose = "-Wl,-v";
  
  $linkshare   = "-Wl,-rpath,\$(CHEETAH_LIBDIR)";
  
***************
*** 108,114 ****
  
  $arargs      = "rcsl";
  
! $arshare     = "g++";             # program to make shared lib
  
  $arshareargs = "-shared -o";      # arguments to make shared lib
  
--- 108,114 ----
  
  $arargs      = "rcsl";
  
! $arshare     = $cpp;             # program to make shared lib
  
  $arshareargs = "-shared -o";      # arguments to make shared lib
  

From oldham at codesourcery.com  Fri Jun 22 18:37:01 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Fri, 22 Jun 2001 11:37:01 -0700
Subject: Patch: src/NewField/tests/makefile: Add StencilTests.
Message-ID: <200106221837.LAA25936@oz.codesourcery.com>


I made a minor change to src/NewField/tests/makefile to include
correctly StencilTests among the tests to run.

OK to commit?  To see a description, visit issue
`makefile_stenciltests' using
http://pooma.codesourcery.com:4242/track/.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From oldham at codesourcery.com  Fri Jun 22 18:40:26 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Fri, 22 Jun 2001 11:40:26 -0700
Subject: [pooma-dev] Using Cheetah with Pooma
In-Reply-To: <20010619211318.A14734@codesourcery.com>; from oldham@codesourcery.com on Tue, Jun 19, 2001 at 09:13:18PM -0700
References: <20010619211318.A14734@codesourcery.com>
Message-ID: <20010622114026.A25445@codesourcery.com>

On Tue, Jun 19, 2001 at 09:13:18PM -0700, Jeffrey Oldham wrote:
> Here are the steps I used to compile Pooma with Cheetah on my
> uniprocessor Linux machine.
> 
> 1. Since I am using a uniprocessor Linux computer, I need to use the
> shared memory library mm with Cheetah.
> 
> a. Obtain a tarball from http://www.engelschall.com/sw/mm/.
> b. tar xzvf mm-1.1.3.tar.gz
>    cd mm-1.1.3
> c. declare -x CC=/home/oldham/gcc-install/gcc1/bin/gcc
> 	# I wanted to use my gcc3.0 so I declared its location.
> 	# Otherwise, some default compiler is used.
> d. ./configure --prefix=${HOME}/pooma/mm-1.1.3
> 	# I wanted the resulting files to be placed in the specified directory.
> e. make -j 3
>    make -j 3 test	# prints success if all tests pass
>    make -j 3 install
> 
> 2. Install the Cheetah code.
> 
> a. Obtain a tarball from http://pooma.codesourcery.com/downloads.
>    tar xzvf cheetah-1.0.tgz
>    cd cheetah-1.0
> b. Modify the source code for correct compilation:
>   i. Append "*/" to line 9 of src/Utilities/i386-lock.s
>   ii. I copied the attached LINUXgcc.conf to config.
> 	# Modify all lines containing "oldham" to have proper values for you.
>   iii. Modify configure using the attached patch.
> c. Configure:
>   ./configure --noex --arch LINUXgcc --shmem --nompi --prefix ${HOME}/pooma/cheetah-1.0

CHANGE:
./configure --static --noex --arch LINUXgcc --shmem --nompi --prefix ${HOME}/pooma/cheetah-1.0

	# `--static' specifies building a regular, non-shared library
	This is necessary to be compatible with Pooma, which has a
	default of non-shared libraries.  Alternatively, one can
	change Pooma's default value.

> 	# `--noex' specifies no exceptions
> 	# QUESTION: Should we use exceptions for Pooma and Cheetah?
> 	# `--shmem' specifies use of the mm package
> 	# `--nompi' specifies no use of MPI
> 	# `--prefix' specifies where to install cheetah
> d. Compile.
>    cd lib/LINUXgcc
>    make -j 3
>    make -j 3 tests
>    make install
> 
> 3. Compile Pooma with Cheetah specified.
> 
> a. Modify ~/pooma/pooma0/src/config/LINUXgcc.conf by specifying Cheetah's location.
> b. ./configure --messaging --arch LINUXgcc --suite LINUXgcc --opt
> 	# --messaging indicates use of Cheetah
> c. declare -x POOMASUITE=LINUXgcc && make -j 3
> 
Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From oldham at codesourcery.com  Fri Jun 22 20:47:19 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Fri, 22 Jun 2001 13:47:19 -0700
Subject: RFA: Fix Spelling Mistakes in NewField Code
Message-ID: <20010622134719.A26077@codesourcery.com>

I made three minor spelling changes to src/NewField/ files.

OK to commit?  To see a description, visit issue `newfields_spelling'
using http://pooma.codesourcery.com:4242/track/.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From oldham at codesourcery.com  Fri Jun 22 22:51:50 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Fri, 22 Jun 2001 15:51:50 -0700
Subject: Patch: Fix Spelling Mistakes in NewField Code
Message-ID: <20010622155150.A26454@codesourcery.com>

2001-06-22  Jeffrey D. Oldham  <oldham at codesourcery.com>

	* DiffOps/Div.UR.h: Fix spelling mistake in initial comments.
	* FieldEngine/FieldEngineBase.ExprEngine.h (Overview): Fix
	spelling mistakes in comments.

Untested since comments does not affect code correctness.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: DiffOps/Div.UR.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/DiffOps/Div.UR.h,v
retrieving revision 1.4
diff -c -p -r1.4 Div.UR.h
*** DiffOps/Div.UR.h	2001/04/11 21:39:27	1.4
--- DiffOps/Div.UR.h	2001/06/22 20:41:01
***************
*** 100,106 ****
  //
  // lowerExtent(int d) - Returns the stencil width in direction d, at the "low"
  //                      end of the (logically) rectilinear mesh. This is the
! //                      maximim positive integer offset from the element 
  //                      indexed by integer i in the input Field's index space
  //                      along dimension d used in outputting the element
  //                      indexed by integer i in the output Field's index space
--- 100,106 ----
  //
  // lowerExtent(int d) - Returns the stencil width in direction d, at the "low"
  //                      end of the (logically) rectilinear mesh. This is the
! //                      maximum positive integer offset from the element 
  //                      indexed by integer i in the input Field's index space
  //                      along dimension d used in outputting the element
  //                      indexed by integer i in the output Field's index space
Index: FieldEngine/FieldEngineBase.ExprEngine.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngineBase.ExprEngine.h,v
retrieving revision 1.11
diff -c -p -r1.11 FieldEngineBase.ExprEngine.h
*** FieldEngine/FieldEngineBase.ExprEngine.h	2001/05/14 21:11:24	1.11
--- FieldEngine/FieldEngineBase.ExprEngine.h	2001/06/22 20:41:02
***************
*** 37,45 ****
  //-----------------------------------------------------------------------------
  // Overview: 
  // 
! // FieldEngineBase and related classes. POOMA supports a flexifble form 
  // of "centering" that allows a hierarchy of multiple centering points per 
! // cell. The centering information, managemed by the FieldEngineBase
  // class, is initialized using a flexible set of functors.
  //-----------------------------------------------------------------------------
  
--- 37,45 ----
  //-----------------------------------------------------------------------------
  // Overview: 
  // 
! // FieldEngineBase and related classes. POOMA supports a flexible form 
  // of "centering" that allows a hierarchy of multiple centering points per 
! // cell. The centering information, managed by the FieldEngineBase
  // class, is initialized using a flexible set of functors.
  //-----------------------------------------------------------------------------
  

From oldham at codesourcery.com  Mon Jun 25 20:41:18 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Mon, 25 Jun 2001 13:41:18 -0700
Subject: RFA: Tiny Changes to tests/makefile's
Message-ID: <20010625134118.A16514@codesourcery.com>

As I worked toward a system that will automatically check for changes
in Pooma regression tests, I discovered several testing makefiles that
needed slight revisions.  Several did not contain `run' targets.
Others needed small other changes.

OK to commit?

(These filenames are all relative to the `src' directory.)

2001-06-25  Jeffrey D. Oldham  <oldham at codesourcery.com>

	* Connect/Lux/tests/makefile (run): New target.
	* Connect/Paws/tests/makefile (run): Likewise.
	* IO/tests/makefile (run_tests): Add dependence on `tests'.
	* NewField/tests/makefile (field_tests): Add StencilTests.
	* Partition/tests/makefile (run): New target.
	* Pooma/tests/makefile (tests): Likewise.
	(run): Likewise.
	* Threads/tests/makefile: Likewise.
	* Tulip/tests/ReduceOverContextsTest.cpp (main): Change function
	call to object creation and then function call.

Tested on	sequential Linux using GNU make version 3.78.1
		  by running "make run" in the associated test directory
Approved by	???you???

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: Connect/Lux/tests/makefile
===================================================================
RCS file: /home/pooma/Repository/r2/src/Connect/Lux/tests/makefile,v
retrieving revision 1.4
diff -c -p -r1.4 makefile
*** Connect/Lux/tests/makefile	2000/07/21 18:29:22	1.4
--- Connect/Lux/tests/makefile	2001/06/25 20:25:12
*************** TSTOPTS =
*** 39,44 ****
--- 39,46 ----
  
  default:: lux_tests
  
+ run:: lux_tests
+ 
  tests:: lux_tests
  
  lux_tests:: lux_test1 lux_test2 bytefield
Index: Connect/Paws/tests/makefile
===================================================================
RCS file: /home/pooma/Repository/r2/src/Connect/Paws/tests/makefile,v
retrieving revision 1.6
diff -c -p -r1.6 makefile
*** Connect/Paws/tests/makefile	2000/07/21 18:29:22	1.6
--- Connect/Paws/tests/makefile	2001/06/25 20:25:12
*************** TSTOPTS =
*** 39,44 ****
--- 39,46 ----
  
  default:: paws_tests
  
+ run:: tests
+ 
  tests:: paws_tests
  
  paws_tests:: paws_test1 paws_test2 paws_test3 paws_test4 \
Index: IO/tests/makefile
===================================================================
RCS file: /home/pooma/Repository/r2/src/IO/tests/makefile,v
retrieving revision 1.25
diff -c -p -r1.25 makefile
*** IO/tests/makefile	2000/07/27 12:33:24	1.25
--- IO/tests/makefile	2001/06/25 20:25:12
*************** tests:: testBaseSerializers testMatrixSe
*** 43,49 ****
  run: run_tests
  	cat *.out
  
! run_tests:
  	$(ODIR)/testBaseSerializers $(TSTOPTS) 1>testBaseSerializers.out 2>&1
  	$(ODIR)/testMatrixSerializers $(TSTOPTS) 1>testMatrixSerializers.out 2>&1
  	$(ODIR)/testLayoutSerializers $(TSTOPTS) 1>testLayoutSerializers.out 2>&1
--- 43,49 ----
  run: run_tests
  	cat *.out
  
! run_tests: tests
  	$(ODIR)/testBaseSerializers $(TSTOPTS) 1>testBaseSerializers.out 2>&1
  	$(ODIR)/testMatrixSerializers $(TSTOPTS) 1>testMatrixSerializers.out 2>&1
  	$(ODIR)/testLayoutSerializers $(TSTOPTS) 1>testLayoutSerializers.out 2>&1
Index: NewField/tests/makefile
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/tests/makefile,v
retrieving revision 1.10
diff -c -p -r1.10 makefile
*** NewField/tests/makefile	2001/05/14 21:11:24	1.10
--- NewField/tests/makefile	2001/06/25 20:25:12
*************** run_tests: tests
*** 58,64 ****
  field_tests:: $(ODIR)/BasicTest1 $(ODIR)/BasicTest2 \
  	$(ODIR)/FieldTour1 $(ODIR)/FieldTour2 \
  	$(ODIR)/WhereTest $(ODIR)/VectorTest \
! 	$(ODIR)/ScalarCode $(ODIR)/ExpressionTest
  
  
  ###########################
--- 58,65 ----
  field_tests:: $(ODIR)/BasicTest1 $(ODIR)/BasicTest2 \
  	$(ODIR)/FieldTour1 $(ODIR)/FieldTour2 \
  	$(ODIR)/WhereTest $(ODIR)/VectorTest \
! 	$(ODIR)/ScalarCode $(ODIR)/StencilTests \
!         $(ODIR)/ExpressionTest
  
  
  ###########################
Index: Partition/tests/makefile
===================================================================
RCS file: /home/pooma/Repository/r2/src/Partition/tests/makefile,v
retrieving revision 1.5
diff -c -p -r1.5 makefile
*** Partition/tests/makefile	2000/07/21 18:29:22	1.5
--- Partition/tests/makefile	2001/06/25 20:25:13
*************** default:: partition_tests
*** 42,47 ****
--- 42,49 ----
  
  tests:: partition_tests
  
+ run:: partition_tests
+ 
  run_tests: partition_tests
  	$(ODIR)/ugp_test $(TSTOPTS) 1>ugp_test.out 2>&1
  
Index: Pooma/tests/makefile
===================================================================
RCS file: /home/pooma/Repository/r2/src/Pooma/tests/makefile,v
retrieving revision 1.4
diff -c -p -r1.4 makefile
*** Pooma/tests/makefile	2000/07/21 18:29:22	1.4
--- Pooma/tests/makefile	2001/06/25 20:25:13
*************** include $(PROJECT_ROOT)/config/head.mk
*** 33,38 ****
--- 33,42 ----
  
  default:: finalize pooma
  
+ tests:: finalize pooma
+ 
+ run:: tests
+ 
  .PHONY: pooma
  .PHONY: finalize
  
Index: Threads/tests/makefile
===================================================================
RCS file: /home/pooma/Repository/r2/src/Threads/tests/makefile,v
retrieving revision 1.7
diff -c -p -r1.7 makefile
*** Threads/tests/makefile	2000/03/20 14:01:07	1.7
--- Threads/tests/makefile	2001/06/25 20:25:13
*************** PASS=APP
*** 35,40 ****
--- 35,42 ----
  
  default:: tests
  
+ run:: tests
+ 
  tests:: 
  
  include $(SHARED_ROOT)/tail.mk
Index: Tulip/tests/ReduceOverContextsTest.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/Tulip/tests/ReduceOverContextsTest.cpp,v
retrieving revision 1.1
diff -c -p -r1.1 ReduceOverContextsTest.cpp
*** Tulip/tests/ReduceOverContextsTest.cpp	2000/06/06 16:51:00	1.1
--- Tulip/tests/ReduceOverContextsTest.cpp	2001/06/25 20:25:13
*************** int main(int argc, char *argv[])
*** 68,74 ****
  
    int result1;
  
!   SumReduction_t(foo[myContext]).broadcast(result1);  
  
    BARRIER;
  
--- 68,75 ----
  
    int result1;
  
!   SumReduction_t goo(foo[myContext]);
!   goo.broadcast(result1);  
  
    BARRIER;
  

From wdn at lanl.gov  Mon Jun 25 20:40:14 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Mon, 25 Jun 2001 14:40:14 -0600
Subject: How to run in parallel
Message-ID: <15159.41390.486641.770138@saltydog.lanl.gov>

I have a Pooma 2 application that I have built using Cheetah.  My version of
Cheetah was built with both mpi support using mpich and shmem support using
mm.  What is the command line that I should use to run in parallel with say 2
processors using either mpi or shmem?

Thanks,

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From oldham at codesourcery.com  Mon Jun 25 21:43:28 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Mon, 25 Jun 2001 14:43:28 -0700
Subject: [pooma-dev] How to run in parallel
In-Reply-To: <15159.41390.486641.770138@saltydog.lanl.gov>; from wdn@lanl.gov on Mon, Jun 25, 2001 at 02:40:14PM -0600
References: <15159.41390.486641.770138@saltydog.lanl.gov>
Message-ID: <20010625144328.A16650@codesourcery.com>

On Mon, Jun 25, 2001 at 02:40:14PM -0600, Dave Nystrom wrote:
> I have a Pooma 2 application that I have built using Cheetah.  My version of
> Cheetah was built with both mpi support using mpich and shmem support using
> mm.  What is the command line that I should use to run in parallel with say 2
> processors using either mpi or shmem?

The Pooma source code (src/Utilities/Options.cmpl.cpp: Options::usage)
seems to indicate that adding `--pooma-threads 5' will set a
concurrency level of 5.  I do not know how to check whether five
threads are actually created.  I also do not know if Cheetah, MPI, or
Shmem requires special command-line options.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From oldham at codesourcery.com  Mon Jun 25 21:50:33 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Mon, 25 Jun 2001 14:50:33 -0700
Subject: RFA: Utilities/Tester.h: Fix Typographical Error
Message-ID: <20010625145033.A16695@codesourcery.com>

OK to commit this patch?

2001-06-25  Jeffrey D. Oldham  <oldham at codesourcery.com>

	* Tester.h (Full Description): Fix subject-verb agreement error in
	these comments.

Untested	since it changes a comment.
Approved by	???you???

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: Tester.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Utilities/Tester.h,v
retrieving revision 1.10
diff -c -p -r1.10 Tester.h
*** Tester.h	2000/03/28 01:10:57	1.10
--- Tester.h	2001/06/25 21:47:02
***************
*** 88,94 ****
  //        PASSED ..... message
  //    or
  //        FAILED ..... message
! //    depending on the current value of the OK flag.  It return an exit
  //    code value, 1 if the test FAILED, 0 if the test PASSED, that you can
  //    use to return from main.  For example:
  //
--- 88,94 ----
  //        PASSED ..... message
  //    or
  //        FAILED ..... message
! //    depending on the current value of the OK flag.  It returns an exit
  //    code value, 1 if the test FAILED, 0 if the test PASSED, that you can
  //    use to return from main.  For example:
  //

From oldham at codesourcery.com  Tue Jun 26 02:06:32 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Mon, 25 Jun 2001 19:06:32 -0700
Subject: Pooma Regression Testing: A First Approach
Message-ID: <200106260206.TAA20478@oz.codesourcery.com>


	Using Alex Samuel's QMTest tool for automatically running a
set of regression tests
(http://software-carpentry.codesourcery.com/dev/), I have a
provisional testsuite to run all the tests in the src/*/tests and
src/*/*/tests directories.  On my sequential Linux computer using
gcc3.0, all of these tests pass except
src/DynamicArray/tests/dynamic_array_test5.cpp (iterator conversion
problems) and src/Functions/tests/rngArray.cpp (gcc3.0 problem).

	Sometime this week, I will start nightly tests so we can catch
programming errors soon after they are introduced.

	What other regression tests, if any, should I include in the
set of tests?  What about the benchmarks, examples, and test
directories?  Are their makefiles set up to compare the results
against desired results?

	Until we get my local Linux testing finished, I am not keen to
add testing for other configurations and platforms.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com

P.S. Actually, the tests have not actually passed, but they should all
pass tonight since I patched all the problems that caused them to
fail during the last run.


From wdn at lanl.gov  Tue Jun 26 04:21:49 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Mon, 25 Jun 2001 22:21:49 -0600
Subject: Problems running in parallel
Message-ID: <15160.3549.807635.576747@saltydog.lanl.gov>

     John and I are trying to get our stuff running in parallel and we are
having runtime problems.  We are using KCC-4.0e with the 4.0f prelinker on
RedHat Linux 7.1.  We are using Cheetah 1.0 sitting on top of mm-1.1.1
i.e. we used --shmem --nompi on the Cheetah configure script.  We
successfully ran the tests for mm and Cheetah.  We built Pooma 2 using the
--messaging option to select the use of Cheetah.  We built tests in the Array
and NewField directory and ran them.  For these tests, we were doing debug
builds with KCC without exceptions and for the Cheetah case.  We ran about
half of the Array tests and they all reported passing.  We ran all of the
tests for the NewField case and all passed except one.  The one that failed
was FieldTour1 which is the only one that seemed to have any Cheetah specific
code in it.  The command line that we were using was:

     FieldTour1 -shmem -np 4

Also, the following command line failed:

     FieldTour1 -shmem -np 1

How should we proceed on this?  Are there examples in the Pooma 2 source tree
which demonstrate how to use the NewField Fields in parallel that we can look
at?  Are there any Pooma 2 tests that exercise running in parallel that pass?
John and I would like to get our stuff running in parallel before I leave for
vacation.  Right now, we only have 3 more days in which our schedules
overlap.

     Also, it turns out that John used the FieldTour1.cpp example as a guide
for building our Fields for the parallel case.  When we run our test problem,
we are getting some pretty strange behavior - it seems that we are not even
getting reproducible results from one run to the next and only about half of
the field is getting the correct answer.  Our test problems run correctly for
the serial case i.e. no Cheetah and CompressibleBrick.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From wdn at lanl.gov  Tue Jun 26 04:34:25 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Mon, 25 Jun 2001 22:34:25 -0600
Subject: Problems getting to various web sites
Message-ID: <15160.4305.575965.605100@saltydog.lanl.gov>

I have been unable to get to a website to download either mm-1.1.3 or the
latest gzipped tar file of gcc-3.0.  Is it possible to get mm-1.1.3.tar.gz
and a snapshot of gcc that will compile Pooma 2 put on the downloads section
of the CodeSourcery web site?

Thanks,

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From allan at stokes.ca  Tue Jun 26 07:26:46 2001
From: allan at stokes.ca (Allan Stokes)
Date: Tue, 26 Jun 2001 00:26:46 -0700
Subject: Domain::operator<
Message-ID: <NABBJEAOKIDHLPHKHPDLEEMCEBAA.allan@stokes.ca>


Hello,

I spent my time today converting my Domain notes into a DocBook document.
At this point the bottom half of the document resembles a code review, the
top half of the document discusses concepts.

While I was checking into equivalence and ordering I came across this
function definition from Domain.h:

  template<class T>
  bool operator<(const T &d2) const {
    CTAssert(Dim == DomainTraits<T>::dimensions);
    for (int i = 0; i < Dim; i++)
      if (domain_m[i] >= DomainTraits<T>::getDomain(d2, i))
        return false;
    return true;
  }


This is not a complete ordering relation.

  3 4 < 3 5 : false
  3 5 < 3 4 : false
  3 5 == 3 4 : false

I also see that operator!=, operator>, operator<=, operator>= are all
defined individually rather than have just operator== and operator< and
everything else defined in terms of these.

Is this meant to be an ordering relation?  Or this is this just a typo?  Is
there any situation where it matters how domains are ordered?

I also noted that there is a CTAssert() that both domains have the same Dim.
This creates a separate equivalence class and ordering relation for each N.
Since Domain<N> and Domain<M> are different types where N!=M this could be
the right choice.

However, the way these function signatures are set up we aren't checking
that T is the same type of Domain (Grid, Interval, etc.) as *this.  Is there
a reason why having the same dimensions in the types is more important that
having the same domain types?

Allan



From oldham at codesourcery.com  Tue Jun 26 15:09:38 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Tue, 26 Jun 2001 08:09:38 -0700
Subject: [pooma-dev] Problems getting to various web sites
In-Reply-To: <15160.4305.575965.605100@saltydog.lanl.gov>; from wdn@lanl.gov on Mon, Jun 25, 2001 at 10:34:25PM -0600
References: <15160.4305.575965.605100@saltydog.lanl.gov>
Message-ID: <20010626080938.A24141@codesourcery.com>

On Mon, Jun 25, 2001 at 10:34:25PM -0600, Dave Nystrom wrote:
> I have been unable to get to a website to download either mm-1.1.3 or the
> latest gzipped tar file of gcc-3.0.  Is it possible to get mm-1.1.3.tar.gz
> and a snapshot of gcc that will compile Pooma 2 put on the downloads section
> of the CodeSourcery web site?

For mm-1.1.3, use http://www.engelschall.com/sw/mm/.  For gcc3.0, use
ftp://ftp.mirror.ac.uk/sites/sourceware.cygnus.com/pub/gcc/releases/gcc-3.0/gcc-3.0.tar.gz
or
ftp://ftp.mirror.ac.uk/sites/sourceware.cygnus.com/pub/gcc/releases/gcc-3.0/gcc-3.0.tar.bz2.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From wdn at lanl.gov  Tue Jun 26 15:46:32 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Tue, 26 Jun 2001 09:46:32 -0600
Subject: [pooma-dev] Problems getting to various web sites
In-Reply-To: <20010626080938.A24141@codesourcery.com>
References: <15160.4305.575965.605100@saltydog.lanl.gov>
	<20010626080938.A24141@codesourcery.com>
Message-ID: <15160.44632.731081.644779@saltydog.lanl.gov>

Jeffrey Oldham writes:
 > On Mon, Jun 25, 2001 at 10:34:25PM -0600, Dave Nystrom wrote:
 > > I have been unable to get to a website to download either mm-1.1.3 or the
 > > latest gzipped tar file of gcc-3.0.  Is it possible to get mm-1.1.3.tar.gz
 > > and a snapshot of gcc that will compile Pooma 2 put on the downloads section
 > > of the CodeSourcery web site?
 > 
 > For mm-1.1.3, use http://www.engelschall.com/sw/mm/.  For gcc3.0, use

I tried this site several times yesterday and could never get through.

 > ftp://ftp.mirror.ac.uk/sites/sourceware.cygnus.com/pub/gcc/releases/gcc-3.0/gcc-3.0.tar.gz
 > or
 > ftp://ftp.mirror.ac.uk/sites/sourceware.cygnus.com/pub/gcc/releases/gcc-3.0/gcc-3.0.tar.bz2.

I don't think I tried this one but I tried about 6-8 different gcc mirror
sites with no success.  I'll try again but I have not had any trouble getting
to the CodeSourcery site.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From JimC at proximation.com  Tue Jun 26 16:07:17 2001
From: JimC at proximation.com (James Crotinger)
Date: Tue, 26 Jun 2001 09:07:17 -0700
Subject: README
Message-ID: <F871BB04B0EA224A821A5274C31DF3152C52@proxim-sf001.santafe.proximation.com>

I just checked in some minor changes to the README file, which was directing
readers to the html directory for the tutorial. Speaking of which, my
computer complains that the .gif files are  unreadable. Can anyone else read
these? Also, these files are not checked in as binary files, which is bad. 

	Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010626/ca139af4/attachment.html>

From scotth at proximation.com  Tue Jun 26 16:11:20 2001
From: scotth at proximation.com (Scott Haney)
Date: Tue, 26 Jun 2001 10:11:20 -0600
Subject: [pooma-dev] README
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152C52@proxim-sf001.santafe.proximation.com>
Message-ID: <mailman.40.1331172045.20475.pooma-dev@codesourcery.com>

Yup, I noticed this as well. If they're not checked in as binary files, 
Windows and Mac clients perform CR/LF translation, which is bad. Someone 
needs to do a 'cvs remove' and then delete them from the CVS attic and 
then a 'cvs add -kb'.

Scott

On Tuesday, June 26, 2001, at 10:07 AM, James Crotinger wrote:

> I just checked in some minor changes to the README file, which was 
> directing readers to the html directory for the tutorial. Speaking of 
> which, my computer complains that the .gif files are? unreadable. Can 
> anyone else read these? Also, these files are not checked in as binary 
> files, which is bad.
>
> ?
--
Scott W. Haney
Development Manager
Proximation LLC
2960 Rodeo Park Drive West
Santa Fe, NM 87505
Voice: 505-424-3809 x101
FAX: 505-438-4161
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 804 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010626/f1700f5b/attachment.bin>

From oldham at codesourcery.com  Tue Jun 26 16:26:27 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Tue, 26 Jun 2001 09:26:27 -0700
Subject: [pooma-dev] README
In-Reply-To: <200106261615.JAA28723@oz.codesourcery.com>; from scotth@proximation.com on Tue, Jun 26, 2001 at 10:11:20AM -0600
References: <F871BB04B0EA224A821A5274C31DF3152C52@proxim-sf001.santafe.proximation.com> <200106261615.JAA28723@oz.codesourcery.com>
Message-ID: <20010626092627.A28726@codesourcery.com>

On Tue, Jun 26, 2001 at 10:11:20AM -0600, Scott Haney wrote:
> Yup, I noticed this as well. If they're not checked in as binary 
> files, Windows and Mac clients perform CR/LF translation, which is bad. 
> Someone needs to do a 'cvs remove' and then delete them from the CVS 
> attic and then a 'cvs add -kb'. 

I performed a `cvs admin -kb' on all the .gif files I found in the CVS
tree.  Does this solve the problem for you?

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From oldham at codesourcery.com  Tue Jun 26 17:14:10 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Tue, 26 Jun 2001 10:14:10 -0700
Subject: [pooma-dev] Problems running in parallel
In-Reply-To: <15160.3549.807635.576747@saltydog.lanl.gov>; from wdn@lanl.gov on Mon, Jun 25, 2001 at 10:21:49PM -0600
References: <15160.3549.807635.576747@saltydog.lanl.gov>
Message-ID: <20010626101410.A29191@codesourcery.com>

On Mon, Jun 25, 2001 at 10:21:49PM -0600, Dave Nystrom wrote:
> 
> Also, the following command line failed:
> 
>      FieldTour1 -shmem -np 1

Here is what I know so far using a uniprocessor Linux computer.  In
src/Engine/MultiPatchEngine.cpp's Engine<Dim, T, MultiPatch<LayoutTag,
PatchTag> >:: Engine(const Layout_t &layout),
the first PInsist fails because fpID == -1.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From JimC at proximation.com  Tue Jun 26 17:34:52 2001
From: JimC at proximation.com (James Crotinger)
Date: Tue, 26 Jun 2001 10:34:52 -0700
Subject: [pooma-dev] How to run in parallel
Message-ID: <F871BB04B0EA224A821A5274C31DF3152C53@proxim-sf001.santafe.proximation.com>

Dave asked:
> What is the command line that I should use to run in parallel with
> say 2 processors using either mpi or shmem?

and Jeffrey replied:
> The Pooma source code (src/Utilities/Options.cmpl.cpp:
> Options::usage) seems to indicate that adding `--pooma-threads 5'
> will set a concurrency level of 5.  I do not know how to check
> whether five

Actually, the --pooma-threads option only applies if you're running with
threads.

How one uses MPI is, I believe, system dependent. The file
docs/parallelism.html says to do

  mpirun -np 4 mycode -mpi 

to use MPI, which works on the SGI with the various MPI libraries. 

I can't find any direct documentation for shared memory, but I believe that
you do:

  mycode -shmem -np 4

to run with shared memory.

I think it is unfortunate that we're using "-shmem" here. SHMEM is Cray's
system for making a logical memory space on a set of distributed memory
computers. It provides high-performance one-sided messaging. If we ever get
back to running on Cray's, it would probably be a good idea to put Cheetah
on SHMEM, but I don't think there is a version that does that right now. mm
simply implements shared memory between forked processes. 

Mike thinks that the term "shmem" has been used more generically for
one-sided messaging using shared memory, which is probably why Cheetah chose
it, but a quick web search turned up hits that deal almost exclusively with
Cray's SHMEM, so if we tell folks that POOMA or Cheetah uses shmem it could
be quite misleading. 

(Actually, Burton Smith from Cray was through here the week before last and
mentioned that shmem is being implemented on other vendors' hardware and so
it might be a good thing to explore at some point, but I don't think we want
to go there right now.)

  Jim

BTW, the README was out of date - the tutorials are in docs. I've fixed
this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010626/dda5cf74/attachment.html>

From JimC at proximation.com  Tue Jun 26 17:43:16 2001
From: JimC at proximation.com (James Crotinger)
Date: Tue, 26 Jun 2001 10:43:16 -0700
Subject: [pooma-dev] Domain::operator<
Message-ID: <F871BB04B0EA224A821A5274C31DF3152C54@proxim-sf001.santafe.proximation.com>

I haven't looked, but this might be used in DomainMap. I agree that we
should fix this to be a complete ordering.

Since this is a template member, I'm assuming that it was an explicit
decision to allow different types of domains to be compared. I think this
makes sense for Interval, Range, and Grid. 

	Jim


> -----Original Message-----
> From: Allan Stokes [mailto:allan at stokes.ca]
> Sent: Tuesday, June 26, 2001 1:27 AM
> To: Pooma-Dev
> Subject: [pooma-dev] Domain::operator<
> 
> 
> 
> Hello,
> 
> I spent my time today converting my Domain notes into a 
> DocBook document.
> At this point the bottom half of the document resembles a 
> code review, the
> top half of the document discusses concepts.
> 
> While I was checking into equivalence and ordering I came across this
> function definition from Domain.h:
> 
>   template<class T>
>   bool operator<(const T &d2) const {
>     CTAssert(Dim == DomainTraits<T>::dimensions);
>     for (int i = 0; i < Dim; i++)
>       if (domain_m[i] >= DomainTraits<T>::getDomain(d2, i))
>         return false;
>     return true;
>   }
> 
> 
> This is not a complete ordering relation.
> 
>   3 4 < 3 5 : false
>   3 5 < 3 4 : false
>   3 5 == 3 4 : false
> 
> I also see that operator!=, operator>, operator<=, operator>= are all
> defined individually rather than have just operator== and 
> operator< and
> everything else defined in terms of these.
> 
> Is this meant to be an ordering relation?  Or this is this 
> just a typo?  Is
> there any situation where it matters how domains are ordered?
> 
> I also noted that there is a CTAssert() that both domains 
> have the same Dim.
> This creates a separate equivalence class and ordering 
> relation for each N.
> Since Domain<N> and Domain<M> are different types where N!=M 
> this could be
> the right choice.
> 
> However, the way these function signatures are set up we 
> aren't checking
> that T is the same type of Domain (Grid, Interval, etc.) as 
> *this.  Is there
> a reason why having the same dimensions in the types is more 
> important that
> having the same domain types?
> 
> Allan
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010626/4bc4df1a/attachment.html>

From JimC at proximation.com  Tue Jun 26 17:44:10 2001
From: JimC at proximation.com (James Crotinger)
Date: Tue, 26 Jun 2001 10:44:10 -0700
Subject: [pooma-dev] README
Message-ID: <F871BB04B0EA224A821A5274C31DF3152C55@proxim-sf001.santafe.proximation.com>

Yes. Thanks, Jeffrey.

> -----Original Message-----
> From: Jeffrey Oldham [mailto:oldham at codesourcery.com]
> Sent: Tuesday, June 26, 2001 10:26 AM
> To: Scott Haney
> Cc: pooma-dev at pooma.codesourcery.com
> Subject: Re: [pooma-dev] README
> 
> 
> On Tue, Jun 26, 2001 at 10:11:20AM -0600, Scott Haney wrote:
> > Yup, I noticed this as well. If they're not checked in as binary 
> > files, Windows and Mac clients perform CR/LF translation, 
> which is bad. 
> > Someone needs to do a 'cvs remove' and then delete them 
> from the CVS 
> > attic and then a 'cvs add -kb'. 
> 
> I performed a `cvs admin -kb' on all the .gif files I found in the CVS
> tree.  Does this solve the problem for you?
> 
> Thanks,
> Jeffrey D. Oldham
> oldham at codesourcery.com
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010626/611fdb90/attachment.html>

From wdn at lanl.gov  Tue Jun 26 18:38:35 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Tue, 26 Jun 2001 12:38:35 -0600
Subject: Accounts on chi
Message-ID: <15160.54955.597034.43007@saltydog.lanl.gov>

Jean, Don, John and I just got our accounts on the chi machine which is an
open Compaq machine.  Don't know much about it yet.  Anyway, to get our
accounts, we filled out a web form at the following web address.  It took
about 24 hours to get our accounts because they had to be approved, I believe
by Ken Koch.  Here is the address of the web form:

www.lanl.gov/asci/access/ChiNewAccount.html

The form takes just a very short time to fill out.  Could you guys fill out
this form so you can get your account?  Let us know if you run into
problems.  I think it would be good to get up and running on chi as soon as
possible.  For your section on connection/relation to ASCI, be sure to say
that you are supporting Pooma 2 for the Blanca ASCI Project.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From oldham at codesourcery.com  Tue Jun 26 20:53:50 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Tue, 26 Jun 2001 13:53:50 -0700
Subject: RFA: Tulip/SendReceive.h: Reorder Initializers
Message-ID: <20010626135350.A31324@codesourcery.com>

OK to commit this patch?

This patch reorders initializers to reflect declaration order.

2001-06-26  Jeffrey D. Oldham  <oldham at codesourcery.com>

	* SendReceive.h (SendIterate::SendIterate): Reorder initializers.
	(ReceiveIterate::ReceiveIterate): Likewise.

Tested on	sequential Linux gcc3.0 by compiling Pooma library
Approved by	???you???

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: SendReceive.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Tulip/SendReceive.h,v
retrieving revision 1.8
diff -c -p -r1.8 SendReceive.h
*** SendReceive.h	2000/06/20 20:46:30	1.8
--- SendReceive.h	2001/06/26 20:44:53
*************** class SendIterate
*** 86,94 ****
  public:
    SendIterate(const View &view, int toContext, int tag)
      : Pooma::Iterate_t(Pooma::scheduler()),
-       view_m(view),
        toContext_m(toContext),
!       tag_m(tag)
   {
      PAssert(toContext >= 0);
     
--- 86,94 ----
  public:
    SendIterate(const View &view, int toContext, int tag)
      : Pooma::Iterate_t(Pooma::scheduler()),
        toContext_m(toContext),
!       tag_m(tag),
!       view_m(view)
   {
      PAssert(toContext >= 0);
     
*************** public:
*** 153,162 ****
    typedef ReceiveIterate<View, IncomingView> This_t;
  
    ReceiveIterate(const View &view, int fromContext, int tag)
!     : view_m(view),
        fromContext_m(fromContext),
        tag_m(tag),
!       Pooma::Iterate_t(Pooma::scheduler())
    {
      PAssert(fromContext >= 0);
      
--- 153,162 ----
    typedef ReceiveIterate<View, IncomingView> This_t;
  
    ReceiveIterate(const View &view, int fromContext, int tag)
!     : Pooma::Iterate_t(Pooma::scheduler()),
        fromContext_m(fromContext),
        tag_m(tag),
!       view_m(view)
    {
      PAssert(fromContext >= 0);
      

From gdr at codesourcery.com  Tue Jun 26 22:17:02 2001
From: gdr at codesourcery.com (Gabriel Dos Reis)
Date: 27 Jun 2001 00:17:02 +0200
Subject: [pooma-dev] Accounts on chi
In-Reply-To: Dave Nystrom's message of "Tue, 26 Jun 2001 12:38:35 -0600"
References: <15160.54955.597034.43007@saltydog.lanl.gov>
Message-ID: <fly9qe6g4h.fsf@pizza.cmla.ens-cachan.fr>

Dave Nystrom <wdn at lanl.gov> writes:

| Jean, Don, John and I just got our accounts on the chi machine which is an
| open Compaq machine.  Don't know much about it yet.  Anyway, to get our
| accounts, we filled out a web form at the following web address.  It took
| about 24 hours to get our accounts because they had to be approved, I believe
| by Ken Koch.  Here is the address of the web form:
| 
| www.lanl.gov/asci/access/ChiNewAccount.html
| 
| The form takes just a very short time to fill out.  Could you guys fill out
| this form so you can get your account?  Let us know if you run into
| problems.  I think it would be good to get up and running on chi as soon as
| possible.  For your section on connection/relation to ASCI, be sure to say
| that you are supporting Pooma 2 for the Blanca ASCI Project.

Hi,

I'm new to this project.

Am I wrong in assuming that I'm not qualified for the above?

Thanks,

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com


From wdn at lanl.gov  Tue Jun 26 22:22:52 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Tue, 26 Jun 2001 16:22:52 -0600
Subject: [pooma-dev] Accounts on chi
In-Reply-To: <fly9qe6g4h.fsf@pizza.cmla.ens-cachan.fr>
References: <15160.54955.597034.43007@saltydog.lanl.gov>
	<fly9qe6g4h.fsf@pizza.cmla.ens-cachan.fr>
Message-ID: <15161.2876.53435.539156@saltydog.lanl.gov>

Gabriel Dos Reis writes:
 > Dave Nystrom <wdn at lanl.gov> writes:
 > 
 > | Jean, Don, John and I just got our accounts on the chi machine which is an
 > | open Compaq machine.  Don't know much about it yet.  Anyway, to get our
 > | accounts, we filled out a web form at the following web address.  It took
 > | about 24 hours to get our accounts because they had to be approved, I believe
 > | by Ken Koch.  Here is the address of the web form:
 > | 
 > | www.lanl.gov/asci/access/ChiNewAccount.html
 > | 
 > | The form takes just a very short time to fill out.  Could you guys fill out
 > | this form so you can get your account?  Let us know if you run into
 > | problems.  I think it would be good to get up and running on chi as soon as
 > | possible.  For your section on connection/relation to ASCI, be sure to say
 > | that you are supporting Pooma 2 for the Blanca ASCI Project.
 > 
 > Hi,
 > 
 > I'm new to this project.
 > 
 > Am I wrong in assuming that I'm not qualified for the above?
 > 
 > Thanks,
 > 
 > -- Gaby
 > CodeSourcery, LLC                       http://www.codesourcery.com
 > 

Hi Gaby,

I would assume that that is up to Mark Mitchell and I would assume that he
would want you to have an account.  It may take a little longer for you to
get set up since there is some paperwork that needs to be filled out that the
others have gotten filled out that you have not.  Anyway, I would check with
Mark to see how he wants you to proceed on this.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From gdr at codesourcery.com  Tue Jun 26 22:40:45 2001
From: gdr at codesourcery.com (Gabriel Dos Reis)
Date: 27 Jun 2001 00:40:45 +0200
Subject: [pooma-dev] Accounts on chi
In-Reply-To: Dave Nystrom's message of "Tue, 26 Jun 2001 16:22:52 -0600"
References: <15160.54955.597034.43007@saltydog.lanl.gov> <fly9qe6g4h.fsf@pizza.cmla.ens-cachan.fr> <15161.2876.53435.539156@saltydog.lanl.gov>
Message-ID: <flpubq6f0y.fsf@pizza.cmla.ens-cachan.fr>

Dave Nystrom <wdn at lanl.gov> writes:

|  > Hi,
|  > 
|  > I'm new to this project.
|  > 
|  > Am I wrong in assuming that I'm not qualified for the above?
|  > 
|  > Thanks,
|  > 
|  > -- Gaby
|  > CodeSourcery, LLC                       http://www.codesourcery.com
|  > 
| 
| Hi Gaby,
| 
| I would assume that that is up to Mark Mitchell and I would assume that he
| would want you to have an account.  It may take a little longer for you to
| get set up since there is some paperwork that needs to be filled out that the
| others have gotten filled out that you have not.  Anyway, I would check with
| Mark to see how he wants you to proceed on this.

Thanks a lot.  I didn't intend to put pressure on you.  I just wanted
to make sure I understand the issues correctly.  Thank you for the
detailed explanation.

Thanks,

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com


From stephens at proximation.com  Tue Jun 26 23:06:31 2001
From: stephens at proximation.com (Stephen Smith)
Date: Tue, 26 Jun 2001 16:06:31 -0700
Subject: [pooma-dev] Problems running in parallel
Message-ID: <F871BB04B0EA224A821A5274C31DF31502170B@proxim-sf001.santafe.proximation.com>

Dave,

Almost all the of tests in NewField/tests create fields that are
distributed in parallel.  Running ExpressionTest and StencilTests
with -shmem -np 4 verifies that you are running on top of Cheetah
correctly.  FieldTour1 creates a layout with ReplicatedTag() instead
of LayoutTag_t(), which is why it fails (the test has a bug).

If you based your parallel code on FieldTour1, verify that you are
using Remote<Brick> or Remote<CompressibleBrick> as the patch tag,
and DistributeTag() as the tag used to initialize the layout.
The fact that you are not getting reproducible results is disturbing.
Could you compile with --bounds as well as --messaging to verify that
enough guard layers are used everywhere?  If the code still runs without
errors, then we probably have a problem with the evaluation somewhere.
A useful serial test would be to compile with "--sched serialAsync" which
uses data-flow evaluation on one processor.  If you see problems
with serialAsync, then we would know that the error is coming from
some basic ordering problem (like boundary conditions).

    Stephen



-----Original Message-----
From: Dave Nystrom [mailto:wdn at lanl.gov]
Sent: Monday, June 25, 2001 10:22 PM
To: pooma-dev
Subject: [pooma-dev] Problems running in parallel


     John and I are trying to get our stuff running in parallel and we are
having runtime problems.  We are using KCC-4.0e with the 4.0f prelinker on
RedHat Linux 7.1.  We are using Cheetah 1.0 sitting on top of mm-1.1.1
i.e. we used --shmem --nompi on the Cheetah configure script.  We
successfully ran the tests for mm and Cheetah.  We built Pooma 2 using the
--messaging option to select the use of Cheetah.  We built tests in the
Array
and NewField directory and ran them.  For these tests, we were doing debug
builds with KCC without exceptions and for the Cheetah case.  We ran about
half of the Array tests and they all reported passing.  We ran all of the
tests for the NewField case and all passed except one.  The one that failed
was FieldTour1 which is the only one that seemed to have any Cheetah
specific
code in it.  The command line that we were using was:

     FieldTour1 -shmem -np 4

Also, the following command line failed:

     FieldTour1 -shmem -np 1

How should we proceed on this?  Are there examples in the Pooma 2 source
tree
which demonstrate how to use the NewField Fields in parallel that we can
look
at?  Are there any Pooma 2 tests that exercise running in parallel that
pass?
John and I would like to get our stuff running in parallel before I leave
for
vacation.  Right now, we only have 3 more days in which our schedules
overlap.

     Also, it turns out that John used the FieldTour1.cpp example as a guide
for building our Fields for the parallel case.  When we run our test
problem,
we are getting some pretty strange behavior - it seems that we are not even
getting reproducible results from one run to the next and only about half of
the field is getting the correct answer.  Our test problems run correctly
for
the serial case i.e. no Cheetah and CompressibleBrick.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010626/8c34c342/attachment.html>

From oldham at codesourcery.com  Wed Jun 27 00:08:57 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Tue, 26 Jun 2001 17:08:57 -0700
Subject: Changing Domain Sizes?
Message-ID: <200106270008.RAA01046@oz.codesourcery.com>


      	Given a domain of unknown type, how do I construct a domain
equivalent in every way except that, for each dimension, it is twice
as large?  half as large?  Should I use the functions in
src/Domain/Shrink.h?

Thanks for the information,
Jeffrey D. Oldham
oldham at codesourcery.com


From stephens at proximation.com  Wed Jun 27 00:14:58 2001
From: stephens at proximation.com (Stephen Smith)
Date: Tue, 26 Jun 2001 17:14:58 -0700
Subject: [pooma-dev] Changing Domain Sizes?
Message-ID: <F871BB04B0EA224A821A5274C31DF31502170D@proxim-sf001.santafe.proximation.com>

You should be able to say  2 * domain, and domain / 2.
I believe the functions in Shrink.h are used to grow by
additive amounts ([0..3] <-> [-1..4]).

    Stephen

-----Original Message-----
From: Jeffrey Oldham [mailto:oldham at codesourcery.com]
Sent: Tuesday, June 26, 2001 6:09 PM
To: pooma-dev at pooma.codesourcery.com
Subject: [pooma-dev] Changing Domain Sizes?



      	Given a domain of unknown type, how do I construct a domain
equivalent in every way except that, for each dimension, it is twice
as large?  half as large?  Should I use the functions in
src/Domain/Shrink.h?

Thanks for the information,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010626/a9d49f60/attachment.html>

From oldham at codesourcery.com  Wed Jun 27 02:29:13 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Tue, 26 Jun 2001 19:29:13 -0700
Subject: RFA: Miscellaneous src Changes
Message-ID: <20010626192913.A4787@codesourcery.com>

OK to commit this patch?

This patch fixes minor spelling errors and rorders member initializers
according to class declarations.

2001-06-26  Jeffrey D. Oldham  <oldham at codesourcery.com>

	* Domain/DomainArithOpsTraits.h: Fix spelling mistake.
	* Domain/DomainBlockIterator.h
	(DomainBlockIterator::DomainBlockIterator): Reorder initializers
	according to declaration order.
	* Layout/GridLayout.cpp (GridLayout::GridLayout): Likewise.
	* NewField/FieldEngine/FieldEngineBase.h: Fix spelling mistake.
	* Partition/GridPartition.h (GridPartition::GridPartition):
	Reorder initializers according to declaration order.
	(GridPartition::partition): Remove unused variable.
	* Utilities/Tester.h: Fix subject-verb agreement.

Tested on	sequential Linux using gcc3.0 by compiling Pooma library
Approved by	???you???

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: Domain/DomainArithOpsTraits.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/DomainArithOpsTraits.h,v
retrieving revision 1.5
diff -c -p -r1.5 DomainArithOpsTraits.h
*** Domain/DomainArithOpsTraits.h	2000/03/07 13:16:33	1.5
--- Domain/DomainArithOpsTraits.h	2001/06/27 02:07:44
***************
*** 40,46 ****
  //-----------------------------------------------------------------------------
  // Overview: 
  // DomainArithOpsTraits is intended to be used to select the return type of 
! // arithmatic operations between domains and pseudo-domains comprising the following
  // list:
  
  // Loc<1> Loc<N> Interval<N> Range<N> IndirectionList<int> Grid<N>
--- 40,46 ----
  //-----------------------------------------------------------------------------
  // Overview: 
  // DomainArithOpsTraits is intended to be used to select the return type of 
! // arithmetic operations between domains and pseudo-domains comprising the following
  // list:
  
  // Loc<1> Loc<N> Interval<N> Range<N> IndirectionList<int> Grid<N>
Index: Domain/DomainBlockIterator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/DomainBlockIterator.h,v
retrieving revision 1.7
diff -c -p -r1.7 DomainBlockIterator.h
*** Domain/DomainBlockIterator.h	2001/04/13 02:12:59	1.7
--- Domain/DomainBlockIterator.h	2001/06/27 02:07:45
*************** private:
*** 292,298 ****
  
  template<class Dom>
  DomainBlockIterator<Dom>::DomainBlockIterator(const Dom &d)
!   : domain_m(d), index_m(0), loc_m(0)
  {
    for (int i=0; i < dimensions; ++i)
      {
--- 292,298 ----
  
  template<class Dom>
  DomainBlockIterator<Dom>::DomainBlockIterator(const Dom &d)
!   : domain_m(d), loc_m(0), index_m(0)
  {
    for (int i=0; i < dimensions; ++i)
      {
*************** DomainBlockIterator<Dom>::DomainBlockIte
*** 332,339 ****
  
  template<class Dom>
  DomainBlockIterator<Dom>::DomainBlockIterator(const This_t &model)
!   : domain_m(model.domain_m), block_m(model.block_m),
!     loc_m(model.loc_m), index_m(model.index_m)
  {
    for (int i=0; i < dimensions; ++i)
      current_m[i] = model.current_m[i];
--- 332,339 ----
  
  template<class Dom>
  DomainBlockIterator<Dom>::DomainBlockIterator(const This_t &model)
!   : domain_m(model.domain_m), loc_m(model.loc_m),
!     block_m(model.block_m), index_m(model.index_m)
  {
    for (int i=0; i < dimensions; ++i)
      current_m[i] = model.current_m[i];
Index: Layout/GridLayout.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/Layout/GridLayout.cpp,v
retrieving revision 1.85
diff -c -p -r1.85 GridLayout.cpp
*** Layout/GridLayout.cpp	2001/04/18 02:15:33	1.85
--- Layout/GridLayout.cpp	2001/06/27 02:07:47
*************** GridLayout<Dim>::GridLayout(const Domain
*** 1071,1082 ****
  template <int Dim>
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid,
  			    const DistributedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >( 
        new LayoutData_t( grid, 
  			GridPartition<Dim>(grid),
! 			DistributedMapper<Dim>(GridPartition<Dim>(grid))))
! 
  {
    pdata_m->attach(*this);
  }
--- 1071,1081 ----
  template <int Dim>
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid,
  			    const DistributedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >( 
        new LayoutData_t( grid, 
  			GridPartition<Dim>(grid),
! 			DistributedMapper<Dim>(GridPartition<Dim>(grid)))),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** GridLayout<Dim>::GridLayout(const Grid<D
*** 1084,1095 ****
  template <int Dim>
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid,
  			    const ReplicatedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >( 
        new LayoutData_t( grid, 
  			GridPartition<Dim>(grid),
! 			LocalMapper<Dim>()))
! 
  {
    pdata_m->attach(*this);
  }
--- 1083,1093 ----
  template <int Dim>
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid,
  			    const ReplicatedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >( 
        new LayoutData_t( grid, 
  			GridPartition<Dim>(grid),
! 			LocalMapper<Dim>())),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** template <int Dim>
*** 1098,1108 ****
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid, 
  			    const GuardLayers_t &gcs,
  			    const DistributedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >
  ( new LayoutData_t( grid, 
  		    GridPartition<Dim>(grid,gcs),
! 		    DistributedMapper<Dim>(GridPartition<Dim>(grid,gcs) )) )
  {
    pdata_m->attach(*this);
  }
--- 1096,1106 ----
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid, 
  			    const GuardLayers_t &gcs,
  			    const DistributedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >
  ( new LayoutData_t( grid, 
  		    GridPartition<Dim>(grid,gcs),
! 		    DistributedMapper<Dim>(GridPartition<Dim>(grid,gcs) )) ),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** template <int Dim>
*** 1111,1121 ****
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid, 
  			    const GuardLayers_t &gcs,
  			    const ReplicatedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >
  ( new LayoutData_t( grid, 
  		    GridPartition<Dim>(grid,gcs),
! 		    LocalMapper<Dim>()) )
  {
    pdata_m->attach(*this);
  }
--- 1109,1119 ----
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid, 
  			    const GuardLayers_t &gcs,
  			    const ReplicatedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >
  ( new LayoutData_t( grid, 
  		    GridPartition<Dim>(grid,gcs),
! 		    LocalMapper<Dim>()) ),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** GridLayout<Dim>::GridLayout(const Grid<D
*** 1126,1136 ****
  			    const GuardLayers_t &igcs, 
  			    const GuardLayers_t &egcs,
  			    const DistributedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >
  (new LayoutData_t(grid, 
  		  GridPartition<Dim>(grid,igcs,egcs),
! 		  DistributedMapper<Dim>(GridPartition<Dim>(grid,igcs,egcs))))
  {
    pdata_m->attach(*this);
  }
--- 1124,1134 ----
  			    const GuardLayers_t &igcs, 
  			    const GuardLayers_t &egcs,
  			    const DistributedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >
  (new LayoutData_t(grid, 
  		  GridPartition<Dim>(grid,igcs,egcs),
! 		  DistributedMapper<Dim>(GridPartition<Dim>(grid,igcs,egcs)))),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** GridLayout<Dim>::GridLayout(const Grid<D
*** 1141,1151 ****
  			    const GuardLayers_t &igcs, 
  			    const GuardLayers_t &egcs,
  			    const ReplicatedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >
  (new LayoutData_t( grid, 
  		   GridPartition<Dim>(grid,igcs,egcs),
! 		   LocalMapper<Dim>() ) )
  {
    pdata_m->attach(*this);
  }
--- 1139,1149 ----
  			    const GuardLayers_t &igcs, 
  			    const GuardLayers_t &egcs,
  			    const ReplicatedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >
  (new LayoutData_t( grid, 
  		   GridPartition<Dim>(grid,igcs,egcs),
! 		   LocalMapper<Dim>() ) ),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** template <class Partitioner>
*** 1155,1165 ****
  GridLayout<Dim>::GridLayout(const Domain_t &gdom, 
  			    const Partitioner &gpar,
  			    const DistributedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >
  (new LayoutData_t(gdom, 
  		  gpar,
! 		  DistributedMapper<Dim>(gpar)) )
  {
    pdata_m->attach(*this);
  }
--- 1153,1163 ----
  GridLayout<Dim>::GridLayout(const Domain_t &gdom, 
  			    const Partitioner &gpar,
  			    const DistributedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >
  (new LayoutData_t(gdom, 
  		  gpar,
! 		  DistributedMapper<Dim>(gpar)) ),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** template <class Partitioner>
*** 1169,1179 ****
  GridLayout<Dim>::GridLayout(const Domain_t &gdom, 
  			    const Partitioner &gpar,
  			    const ReplicatedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >
! (new LayoutData_t(gdom, 
! 		  gpar,
! 		  LocalMapper<Dim>()) )
  {
    pdata_m->attach(*this);
  }
--- 1167,1177 ----
  GridLayout<Dim>::GridLayout(const Domain_t &gdom, 
  			    const Partitioner &gpar,
  			    const ReplicatedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >
!       (new LayoutData_t(gdom, 
!        		  	gpar,
! 			LocalMapper<Dim>()) ),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** template <class Partitioner>
*** 1183,1198 ****
  GridLayout<Dim>::GridLayout(const Domain_t &gdom, 
  			    const Partitioner &gpar,
  			    const ContextMapper<Dim> &cmap)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >(new LayoutData_t(gdom, gpar, cmap) )
  {
    pdata_m->attach(*this);
  }
  
  template <int Dim>
  GridLayout<Dim>::GridLayout(const This_t &model) 
!   : Observable<This_t>(*this),
!     LayoutBase<Dim,GridLayoutData<Dim> >(model.pdata_m)
  { 
     pdata_m->attach(*this);
  }
--- 1181,1196 ----
  GridLayout<Dim>::GridLayout(const Domain_t &gdom, 
  			    const Partitioner &gpar,
  			    const ContextMapper<Dim> &cmap)
!   : LayoutBase<Dim,GridLayoutData<Dim> >(new LayoutData_t(gdom, gpar, cmap) ),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
  
  template <int Dim>
  GridLayout<Dim>::GridLayout(const This_t &model) 
!   : LayoutBase<Dim,GridLayoutData<Dim> >(model.pdata_m),
!     Observable<This_t>(*this)
  { 
     pdata_m->attach(*this);
  }
Index: NewField/FieldEngine/FieldEngineBase.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngineBase.h,v
retrieving revision 1.12
diff -c -p -r1.12 FieldEngineBase.h
*** NewField/FieldEngine/FieldEngineBase.h	2001/05/14 21:11:24	1.12
--- NewField/FieldEngine/FieldEngineBase.h	2001/06/27 02:07:47
***************
*** 39,45 ****
  // 
  // FieldEngineBase and related classes. POOMA supports a flexible form 
  // of "centering" that allows a hierarchy of multiple centering points per 
! // cell. The centering information, managemed by the FieldEngineBase
  // class, is initialized using a flexible set of functors.
  //-----------------------------------------------------------------------------
  
--- 39,45 ----
  // 
  // FieldEngineBase and related classes. POOMA supports a flexible form 
  // of "centering" that allows a hierarchy of multiple centering points per 
! // cell. The centering information, managed by the FieldEngineBase
  // class, is initialized using a flexible set of functors.
  //-----------------------------------------------------------------------------
  
Index: Partition/GridPartition.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Partition/GridPartition.h,v
retrieving revision 1.27
diff -c -p -r1.27 GridPartition.h
*** Partition/GridPartition.h	2001/04/18 02:17:11	1.27
--- Partition/GridPartition.h	2001/06/27 02:20:26
*************** public:
*** 153,163 ****
  
  
    GridPartition(const Grid<Dim> &g)
!     : grid_m(g), 
!       hasInternalGuards_m(false), 
        hasExternalGuards_m(false),
        internalGuards_m(0),
!       externalGuards_m(0)
    {
      num_m=1;
      for (int i=0;i<Dim;i++)
--- 153,163 ----
  
  
    GridPartition(const Grid<Dim> &g)
!     : hasInternalGuards_m(false), 
        hasExternalGuards_m(false),
        internalGuards_m(0),
!       externalGuards_m(0),
!       grid_m(g)
    {
      num_m=1;
      for (int i=0;i<Dim;i++)
*************** public:
*** 170,180 ****
    
    GridPartition(const Grid<Dim> &g, 
  		const GuardLayers<Dim> &gcs)
!     : grid_m(g), 
!       hasInternalGuards_m(true),
        hasExternalGuards_m(true),
        internalGuards_m(gcs),
!       externalGuards_m(gcs)
    {
      num_m=1;
      for (int i=0;i<Dim;i++)
--- 170,180 ----
    
    GridPartition(const Grid<Dim> &g, 
  		const GuardLayers<Dim> &gcs)
!     : hasInternalGuards_m(true),
        hasExternalGuards_m(true),
        internalGuards_m(gcs),
!       externalGuards_m(gcs),
!       grid_m(g)
    {
      num_m=1;
      for (int i=0;i<Dim;i++)
*************** public:
*** 187,197 ****
    GridPartition(const Grid<Dim> &g, 
  		const GuardLayers<Dim> &igcs,
  		const GuardLayers<Dim> &egcs)
!     : grid_m(g),
!       hasInternalGuards_m(true), 
        hasExternalGuards_m(true), 
        internalGuards_m(igcs), 
!       externalGuards_m(egcs)
    {
      num_m=1;
      for (int i=0;i<Dim;i++)
--- 187,197 ----
    GridPartition(const Grid<Dim> &g, 
  		const GuardLayers<Dim> &igcs,
  		const GuardLayers<Dim> &egcs)
!     : hasInternalGuards_m(true), 
        hasExternalGuards_m(true), 
        internalGuards_m(igcs), 
!       externalGuards_m(egcs),
!       grid_m(g)
    {
      num_m=1;
      for (int i=0;i<Dim;i++)
*************** public:
*** 205,224 ****
    GridPartition() 
      : hasInternalGuards_m(false), 
        hasExternalGuards_m(false),
-       num_m(1),
        internalGuards_m(0),
!       externalGuards_m(0)
    {  
      for (int i=0;i<Dim;++i)
        blocks_m[i]=Loc<1>(1);
    }
  
    GridPartition(const Loc<Dim> &a)
!     : hasInternalGuards_m(false), 
        hasExternalGuards_m(false),
        internalGuards_m(0),
!       externalGuards_m(0),
!       blocks_m(a)
    {
      num_m = blocks_m[0].first();
      for (int d=1; d < Dim; ++d)
--- 205,224 ----
    GridPartition() 
      : hasInternalGuards_m(false), 
        hasExternalGuards_m(false),
        internalGuards_m(0),
!       externalGuards_m(0),
!       num_m(1)
    {  
      for (int i=0;i<Dim;++i)
        blocks_m[i]=Loc<1>(1);
    }
  
    GridPartition(const Loc<Dim> &a)
!     : blocks_m(a),
!       hasInternalGuards_m(false),
        hasExternalGuards_m(false),
        internalGuards_m(0),
!       externalGuards_m(0)
    {
      num_m = blocks_m[0].first();
      for (int d=1; d < Dim; ++d)
*************** public:
*** 227,237 ****
   
    GridPartition(const Loc<Dim> &a,
  		const GuardLayers<Dim> &gcs)
!     : hasInternalGuards_m(true), 
        hasExternalGuards_m(true), 
        internalGuards_m(gcs), 
!       externalGuards_m(gcs),
!       blocks_m(a) 
    { 
      num_m = blocks_m[0].first();
      for (int d=1; d < Dim; ++d) 
--- 227,237 ----
   
    GridPartition(const Loc<Dim> &a,
  		const GuardLayers<Dim> &gcs)
!     : blocks_m(a),
!       hasInternalGuards_m(true), 
        hasExternalGuards_m(true), 
        internalGuards_m(gcs), 
!       externalGuards_m(gcs)
    { 
      num_m = blocks_m[0].first();
      for (int d=1; d < Dim; ++d) 
*************** public:
*** 241,251 ****
    GridPartition(const Loc<Dim> &a,
  		const GuardLayers<Dim> &igcs, 
  		const GuardLayers<Dim> &egcs)
!     : hasInternalGuards_m(true), 
        hasExternalGuards_m(true), 
        internalGuards_m(igcs), 
!       externalGuards_m(egcs),
!       blocks_m(a) 
    {
      num_m = blocks_m[0].first();
      for (int d=1; d < Dim; ++d) 
--- 241,251 ----
    GridPartition(const Loc<Dim> &a,
  		const GuardLayers<Dim> &igcs, 
  		const GuardLayers<Dim> &egcs)
!     : blocks_m(a),
!       hasInternalGuards_m(true), 
        hasExternalGuards_m(true), 
        internalGuards_m(igcs), 
!       externalGuards_m(egcs)
    {
      num_m = blocks_m[0].first();
      for (int d=1; d < Dim; ++d) 
*************** public:
*** 255,265 ****
    // copy constructor
  
    GridPartition(const GridPartition<Dim> & b)
!     : hasInternalGuards_m(b.hasInternalGuards_m),
        hasExternalGuards_m(b.hasExternalGuards_m),
        internalGuards_m(b.internalGuards_m),
        externalGuards_m(b.externalGuards_m),
-       blocks_m(b.blocks_m),
        num_m(b.num_m),
        grid_m(b.grid_m)
    {
--- 255,265 ----
    // copy constructor
  
    GridPartition(const GridPartition<Dim> & b)
!     : blocks_m(b.blocks_m),
!       hasInternalGuards_m(b.hasInternalGuards_m),
        hasExternalGuards_m(b.hasExternalGuards_m),
        internalGuards_m(b.internalGuards_m),
        externalGuards_m(b.externalGuards_m),
        num_m(b.num_m),
        grid_m(b.grid_m)
    {
*************** public:
*** 268,278 ****
    // copy from a GP
    
   GridPartition(const UniformGridPartition<Dim> & b)
!    : hasInternalGuards_m(b.hasInternalGuards_m),
       hasExternalGuards_m(b.hasExternalGuards_m),
       internalGuards_m(b.internalGuards_m),
       externalGuards_m(b.externalGuards_m),
-      blocks_m(b.blocks_m),
       num_m(b.num_m)
    {}
  
--- 268,278 ----
    // copy from a GP
    
   GridPartition(const UniformGridPartition<Dim> & b)
!    : blocks_m(b.blocks_m),
!      hasInternalGuards_m(b.hasInternalGuards_m),
       hasExternalGuards_m(b.hasExternalGuards_m),
       internalGuards_m(b.internalGuards_m),
       externalGuards_m(b.externalGuards_m),
       num_m(b.num_m)
    {}
  
*************** public:
*** 408,414 ****
  
  	// Calculate the guard cell specification for this domain.
  	
- 	GuardLayers<Dim> gcs(0); // No guards by default.
  	if (hasInternalGuards()||hasExternalGuards())
  	  {
  	    for (int i=0;i<Dim;i++)
--- 408,413 ----
Index: Utilities/Tester.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Utilities/Tester.h,v
retrieving revision 1.10
diff -c -p -r1.10 Tester.h
*** Utilities/Tester.h	2000/03/28 01:10:57	1.10
--- Utilities/Tester.h	2001/06/27 02:07:48
***************
*** 88,94 ****
  //        PASSED ..... message
  //    or
  //        FAILED ..... message
! //    depending on the current value of the OK flag.  It return an exit
  //    code value, 1 if the test FAILED, 0 if the test PASSED, that you can
  //    use to return from main.  For example:
  //
--- 88,94 ----
  //        PASSED ..... message
  //    or
  //        FAILED ..... message
! //    depending on the current value of the OK flag.  It returns an exit
  //    code value, 1 if the test FAILED, 0 if the test PASSED, that you can
  //    use to return from main.  For example:
  //

From scotth at proximation.com  Wed Jun 27 15:53:52 2001
From: scotth at proximation.com (Scott Haney)
Date: Wed, 27 Jun 2001 09:53:52 -0600
Subject: [pooma-dev] Accounts on chi
In-Reply-To: <fly9qe6g4h.fsf@pizza.cmla.ens-cachan.fr>
Message-ID: <mailman.41.1331172045.20475.pooma-dev@codesourcery.com>

Hi Gaby,

First, welcome to the Project!

Getting an account on LANL machines is a bit of a pain, especially for 
non-US citizens, but we should start the process. We need to talk to 
LANL folks to  get the paperwork rolling. Mark, would you be willing to 
give Jeff Brown a call?

Scott

On Tuesday, June 26, 2001, at 04:17 PM, Gabriel Dos Reis wrote:

> Hi,
>
> I'm new to this project.
>
> Am I wrong in assuming that I'm not qualified for the above?
>
> Thanks,

--
Scott W. Haney
Development Manager
Proximation LLC
2960 Rodeo Park Drive West
Santa Fe, NM 87505
Voice: 505-424-3809 x101
FAX: 505-438-4161


From mark at codesourcery.com  Wed Jun 27 15:50:51 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Wed, 27 Jun 2001 08:50:51 -0700
Subject: Problems getting to various web sites
In-Reply-To: <15160.4305.575965.605100@saltydog.lanl.gov>
Message-ID: <71630000.993657051@warlock.codesourcery.com>



--On Monday, June 25, 2001 10:34:25 PM -0600 Dave Nystrom <wdn at lanl.gov> 
wrote:

> I have been unable to get to a website to download either mm-1.1.3 or the
> latest gzipped tar file of gcc-3.0.  Is it possible to get mm-1.1.3.tar.gz
> and a snapshot of gcc that will compile Pooma 2 put on the downloads
> section of the CodeSourcery web site?

I was planning on adding `mm' as soon as I get a little information from
Stephen.  The GCC mirrors should have calmed down by now, I think.

Thanks,

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


From mark at codesourcery.com  Wed Jun 27 15:53:24 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Wed, 27 Jun 2001 08:53:24 -0700
Subject: Domain::operator<
In-Reply-To: <NABBJEAOKIDHLPHKHPDLEEMCEBAA.allan@stokes.ca>
Message-ID: <78470000.993657204@warlock.codesourcery.com>


> This is not a complete ordering relation.

This is a good observation.  Exactly the reason why having someone
who thinks hard working on the documentation is a good idea.

I don't know the answer (maybe it's a partial order, not a total order?),
but I'm glad you asked.  Is there preliminary documentation somewhere
at this point?

Thanks,

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


From mark at codesourcery.com  Wed Jun 27 15:58:35 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Wed, 27 Jun 2001 08:58:35 -0700
Subject: README
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152C52@proxim-sf001.santafe.proximation.com>
Message-ID: <83730000.993657514@warlock.codesourcery.com>



\> which, my computer complains that the .gif files are  unreadable. Can
> anyone else read these? Also, these files are not checked in as binary
> files, which is bad.

They worked fine for me -- but your comment about binaryness might be
the problem.  I have done `cvs admin -kb' on those files, so hopefully
that will fix it.

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


From mark at codesourcery.com  Wed Jun 27 16:00:07 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Wed, 27 Jun 2001 09:00:07 -0700
Subject: [pooma-dev] Accounts on chi
In-Reply-To: <fly9qe6g4h.fsf@pizza.cmla.ens-cachan.fr>
Message-ID: <85700000.993657607@warlock.codesourcery.com>



> Am I wrong in assuming that I'm not qualified for the above?
>

You can try -- but as a French national you're likely out of luck.
(It turns out France is on the list of Countries We Do Not Like at
the moment.)

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


From jxyh at lanl.gov  Wed Jun 27 16:25:04 2001
From: jxyh at lanl.gov (John Hall)
Date: Wed, 27 Jun 2001 10:25:04 -0600
Subject: parallel runs
In-Reply-To: <200106271554.f5RFsIS24378@mailproxy1.lanl.gov>
References: <200106271554.f5RFsIS24378@mailproxy1.lanl.gov>
Message-ID: <p04320400b75fb51aa529@[128.165.16.39]>

Scott and Stephen:
It turns out that I had already noticed that I needed to use 
DistributedTag instead of ReplicatedTag in my field and layout 
creation routines, so the error in FieldTour1.cpp was not my problem 
(unfortunately). When we made the suggested change to Fieldtour1.cpp 
of course we ran that test correctly along with all the others in the 
NewField test directory. We do not seem to have a StencilTest in that 
directory using the standard checkout.

We also tried last night running with no guard cells, 
--pooma-nocompress and changing CompressibleBrick to simply Brick. 
None of these changes had any effect on the final result, which is 
hints of patches of correct behavior surrounded by gibberish.

I have a series of further tests in mind today including running 
under the debugger (totalview, which has finally gotten to the point 
where it is an excellent tool even with KCC) and determining whether 
the data is correct and maybe the problem lies simply in the printing 
(we can all dream, right?). I am also going to start coding some of 
our tests directly in Pooma, although I am already running in the 
Poomalote regression test layer which is essentially straight Pooma 
anyhow since it is our lowest layer.

Anyhow, I will finally get it down to exactly when we can run OK and 
when we can't since I now have some working reliable examples. Until 
then we will have to keep saying that "Blanca/Pooma is without 
parallel without exception" since performance is dramatically 
improved without exceptions.
Thanks,
John


From mark at codesourcery.com  Wed Jun 27 16:03:48 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Wed, 27 Jun 2001 09:03:48 -0700
Subject: [pooma-dev] Accounts on chi
Message-ID: <87170000.993657828@warlock.codesourcery.com>



--On Wednesday, June 27, 2001 09:53:52 AM -0600 Scott Haney 
<scotth at proximation.com> wrote:

> Hi Gaby,
>
> First, welcome to the Project!
>
> Getting an account on LANL machines is a bit of a pain, especially for
> non-US citizens, but we should start the process. We need to talk to LANL
> folks to  get the paperwork rolling. Mark, would you be willing to give
> Jeff Brown a call?

It now becomes painfully obvious that I read this list in digest form. :-)

Gaby, I suggest that you fill in the form.  Then, let's see what happens
next.  If nothing happens in a day or two, email me directly and I
will follow up with Jeff Brown.  For the statement of how your work
releates to ASCI, indicate that you are working on POOMA for
CodeSourcery, under contract from LANL.

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


From gdr at codesourcery.com  Wed Jun 27 16:26:24 2001
From: gdr at codesourcery.com (Gabriel Dos Reis)
Date: 27 Jun 2001 18:26:24 +0200
Subject: [pooma-dev] Accounts on chi
In-Reply-To: Mark Mitchell's message of "Wed, 27 Jun 2001 09:00:07 -0700"
References: <85700000.993657607@warlock.codesourcery.com>
Message-ID: <flwv5xkhxr.fsf@sel.cmla.ens-cachan.fr>

Mark Mitchell <mark at codesourcery.com> writes:

| > Am I wrong in assuming that I'm not qualified for the above?
| >
| 
| You can try -- but as a French national you're likely out of luck.
| (It turns out France is on the list of Countries We Do Not Like at
| the moment.)

Interesting :-)))

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com


From oldham at codesourcery.com  Wed Jun 27 16:28:49 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Wed, 27 Jun 2001 09:28:49 -0700
Subject: [pooma-dev] Accounts on chi
In-Reply-To: <87170000.993657828@warlock.codesourcery.com>; from mark@codesourcery.com on Wed, Jun 27, 2001 at 09:03:48AM -0700
References: <87170000.993657828@warlock.codesourcery.com>
Message-ID: <20010627092849.A5517@codesourcery.com>

On Wed, Jun 27, 2001 at 09:03:48AM -0700, Mark Mitchell wrote:
> 
> 
> --On Wednesday, June 27, 2001 09:53:52 AM -0600 Scott Haney 
> <scotth at proximation.com> wrote:
> 
> > Hi Gaby,
> >
> > First, welcome to the Project!
> >
> > Getting an account on LANL machines is a bit of a pain, especially for
> > non-US citizens, but we should start the process. We need to talk to LANL
> > folks to  get the paperwork rolling. Mark, would you be willing to give
> > Jeff Brown a call?
> 
> It now becomes painfully obvious that I read this list in digest form. :-)
> 
> Gaby, I suggest that you fill in the form.  Then, let's see what happens
> next.  If nothing happens in a day or two, email me directly and I
> will follow up with Jeff Brown.  For the statement of how your work
> releates to ASCI, indicate that you are working on POOMA for
> CodeSourcery, under contract from LANL.

He probably needs a z-number and a passcode, which he does not have,
to complete the form.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From gdr at codesourcery.com  Wed Jun 27 16:34:32 2001
From: gdr at codesourcery.com (Gabriel Dos Reis)
Date: 27 Jun 2001 18:34:32 +0200
Subject: [pooma-dev] Accounts on chi
In-Reply-To: Jeffrey Oldham's message of "Wed, 27 Jun 2001 09:28:49 -0700"
References: <87170000.993657828@warlock.codesourcery.com> <20010627092849.A5517@codesourcery.com>
Message-ID: <fln16tkhk7.fsf@sel.cmla.ens-cachan.fr>

Jeffrey Oldham <oldham at codesourcery.com> writes:

| He probably needs a z-number and a passcode, which he does not have,
| to complete the form.

You're absolutely right :-)
(I confess my ignorance about what a "z-number" is :-)

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com


From mark at codesourcery.com  Wed Jun 27 16:26:24 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Wed, 27 Jun 2001 09:26:24 -0700
Subject: [pooma-dev] Accounts on chi
In-Reply-To: <fln16tkhk7.fsf@sel.cmla.ens-cachan.fr>
Message-ID: <98820000.993659184@warlock.codesourcery.com>



--On Wednesday, June 27, 2001 06:34:32 PM +0200 Gabriel Dos Reis 
<gdr at codesourcery.com> wrote:

> Jeffrey Oldham <oldham at codesourcery.com> writes:
>
> | He probably needs a z-number and a passcode, which he does not have,
> | to complete the form.
>
> You're absolutely right :-)
> (I confess my ignorance about what a "z-number" is :-)

It's essentially a userid.

Scott, do you think filling out the old ACL account application form
will still work?

Gaby, you may as well try it.  Visit:

  http://www.acl.lanl.gov/scripts/accounts.pl

Meanwhile, I will contact Jeff Brown.

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


From scotth at proximation.com  Wed Jun 27 17:04:51 2001
From: scotth at proximation.com (Scott Haney)
Date: Wed, 27 Jun 2001 11:04:51 -0600
Subject: [pooma-dev] Domain::operator<
In-Reply-To: <NABBJEAOKIDHLPHKHPDLEEMCEBAA.allan@stokes.ca>
Message-ID: <mailman.42.1331172045.20475.pooma-dev@codesourcery.com>

Hi Allan,

I just compiled the little snippet of code

   Range<1> R(3, 4), R1(3, 5, 2);
   std::cout << (R < R1) << std::endl;
   std::cout << (R > R1) << std::endl;
   std::cout << (R == R1) << std::endl;

   Interval<1> I(3, 4), I1(3, 5);
   std::cout << (I < I1) << std::endl;
   std::cout << (I > I1) << std::endl;
   std::cout << (I == I1) << std::endl;

and got

1
0
0
1
0
0

as the output. What exactly were you doing in your analysis? On the 
broader issue as to why operator< exists at all: I can think of no other 
reason than wanting to put domains in a map. Is LessThanComparable 
required for map elements?

Scott

On Tuesday, June 26, 2001, at 01:26 AM, Allan Stokes wrote:

> This is not a complete ordering relation.
>
>   3 4 < 3 5 : false
>   3 5 < 3 4 : false
>   3 5 == 3 4 : false
>
> I also see that operator!=, operator>, operator<=, operator>= are all
> defined individually rather than have just operator== and operator< and
> everything else defined in terms of these.
>
> Is this meant to be an ordering relation?  Or this is this just a 
> typo?  Is
> there any situation where it matters how domains are ordered?
>


From gdr at codesourcery.com  Wed Jun 27 17:10:27 2001
From: gdr at codesourcery.com (Gabriel Dos Reis)
Date: 27 Jun 2001 19:10:27 +0200
Subject: [pooma-dev] Accounts on chi
In-Reply-To: Mark Mitchell's message of "Wed, 27 Jun 2001 09:26:24 -0700"
References: <98820000.993659184@warlock.codesourcery.com>
Message-ID: <fl4rt1kfwc.fsf@sel.cmla.ens-cachan.fr>

Mark Mitchell <mark at codesourcery.com> writes:

| Gaby, you may as well try it.  Visit:
| 
|   http://www.acl.lanl.gov/scripts/accounts.pl


Thank you Mark.  Now, I'm unable to answer the question on the pae
LANL Contact Information :-)

	Contact's Name:   

	Contact's Division-Group:

	Contact's E-Mail Address:


Sorry for being so painful.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com


From scotth at proximation.com  Wed Jun 27 17:12:40 2001
From: scotth at proximation.com (Scott Haney)
Date: Wed, 27 Jun 2001 11:12:40 -0600
Subject: [pooma-dev] Accounts on chi
In-Reply-To: <98820000.993659184@warlock.codesourcery.com>
Message-ID: <mailman.43.1331172045.20475.pooma-dev@codesourcery.com>

It is premature to go and fill in the form without getting the z-number 
etc. This will take a bit of time since there are more approvals 
required.  Jeff Brown is the guy who needs to file the form.

BTW, to head off a Simpsons-like international incident between the US 
and France, I'd like to mention that the LANL list I told Mark about 
isn't exactly "Countries We Do Not Like at the Moment". :-) All non-US 
citizens require special approvals to get lab computer access these 
days, including Stephen who used to work there.

There is a list of "sensitive" countries, some fairly obvious and some 
not, that require still more paperwork, but happily we've been able to 
confirm that France is not on this list.

Scott

On Wednesday, June 27, 2001, at 10:26 AM, Mark Mitchell wrote:

>> Jeffrey Oldham <oldham at codesourcery.com> writes:
>>
>> | He probably needs a z-number and a passcode, which he does not have,
>> | to complete the form.
>>
>> You're absolutely right :-)
>> (I confess my ignorance about what a "z-number" is :-)
>
> It's essentially a userid.
>
> Scott, do you think filling out the old ACL account application form
> will still work?
>
> Gaby, you may as well try it.  Visit:
>
>  http://www.acl.lanl.gov/scripts/accounts.pl
>
> Meanwhile, I will contact Jeff Brown.


--
Scott W. Haney
Development Manager
Proximation LLC
2960 Rodeo Park Drive West
Santa Fe, NM 87505
Voice: 505-424-3809 x101
FAX: 505-438-4161


From wdn at lanl.gov  Wed Jun 27 17:41:43 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Wed, 27 Jun 2001 11:41:43 -0600
Subject: [pooma-dev] Accounts on chi
In-Reply-To: <87170000.993657828@warlock.codesourcery.com>
References: <87170000.993657828@warlock.codesourcery.com>
Message-ID: <15162.6871.208859.884360@saltydog.lanl.gov>

Mark Mitchell writes:
 > 
 > 
 > --On Wednesday, June 27, 2001 09:53:52 AM -0600 Scott Haney 
 > <scotth at proximation.com> wrote:
 > 
 > > Hi Gaby,
 > >
 > > First, welcome to the Project!
 > >
 > > Getting an account on LANL machines is a bit of a pain, especially for
 > > non-US citizens, but we should start the process. We need to talk to LANL
 > > folks to  get the paperwork rolling. Mark, would you be willing to give
 > > Jeff Brown a call?
 > 
 > It now becomes painfully obvious that I read this list in digest form. :-)
 > 
 > Gaby, I suggest that you fill in the form.  Then, let's see what happens
 > next.  If nothing happens in a day or two, email me directly and I
 > will follow up with Jeff Brown.  For the statement of how your work
 > releates to ASCI, indicate that you are working on POOMA for
 > CodeSourcery, under contract from LANL.

I'd also add that this work is supporting the Blanca ASCI Project.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From mark at codesourcery.com  Wed Jun 27 17:27:07 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Wed, 27 Jun 2001 10:27:07 -0700
Subject: [pooma-dev] Accounts on chi
In-Reply-To: <fl4rt1kfwc.fsf@sel.cmla.ens-cachan.fr>
Message-ID: <14230000.993662827@warlock.codesourcery.com>



--On Wednesday, June 27, 2001 07:10:27 PM +0200 Gabriel Dos Reis 
<gdr at codesourcery.com> wrote:

> Mark Mitchell <mark at codesourcery.com> writes:
>
> | Gaby, you may as well try it.  Visit:
> |
> |   http://www.acl.lanl.gov/scripts/accounts.pl
>
>
> Thank you Mark.  Now, I'm unable to answer the question on the pae
> LANL Contact Information :-)
>
> 	Contact's Name:
>
> 	Contact's Division-Group:
>
> 	Contact's E-Mail Address:
>
>
> Sorry for being so painful.

Try "Jeff Brown" and "jeffb at lanl.gov".  Leave the Division-Group blank.

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


From gdr at codesourcery.com  Wed Jun 27 17:54:01 2001
From: gdr at codesourcery.com (Gabriel Dos Reis)
Date: 27 Jun 2001 19:54:01 +0200
Subject: [pooma-dev] Accounts on chi
In-Reply-To: Mark Mitchell's message of "Wed, 27 Jun 2001 10:27:07 -0700"
References: <14230000.993662827@warlock.codesourcery.com>
Message-ID: <flr8w5izba.fsf@sel.cmla.ens-cachan.fr>

Mark Mitchell <mark at codesourcery.com> writes:

| Leave the Division-Group blank.

Hmmm, the `Division-Group' field is required.

Thanks,

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com


From wdn at lanl.gov  Wed Jun 27 19:55:14 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Wed, 27 Jun 2001 13:55:14 -0600
Subject: Compilation problem with gcc-3.0
Message-ID: <15162.14882.302137.947192@saltydog.lanl.gov>

Below is a small test case that includes two functions, find1 and find2.
When I try to compile this with the g++ from gcc-3.0, I get the following
error:

saltydog % make
g++ -c -o tUnwrapKernel.o tUnwrapKernel.cc
tUnwrapKernel.cc: In member function `void X<C>::find2(Ptr<AnyType>)':
tUnwrapKernel.cc:33: parse error before `;' token
make: *** [tUnwrapKernel.o] Error 1

The construct in the find2 function, i.e.
"C* pClass( unwrap<C*>()(*object) );" is ubiquitous in our TecFramework
library package.  John Hall and I experimented last night with various
attempts to eliminate the error by using typename, etc.  The only solution we
found was to replace this construct with the two line construct that is in
the find1 function.  The original construct compiles just fine with KCC-4.0
using --strict.  Is the failure to compile a problem with gcc-3.0 or is KCC
taking liberties that it should not.  If there is a problem with gcc, would
it be possible to get a fix anytime soon.  We would like to get our code up
and running with gcc but making this change in so many places in our source
code base would be tedious and undesirable if there is really a problem with
gcc.  Also, we do not really own TecFramework and making these changes would
require negotiation with other people - this is not really that big of a deal
but we would just as soon avoid it if possible.

Thanks,

Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046

--------------------------------test.cc---------------------------------------
class AnyType
{};

template<class T>
class Ptr
{
  public:
    Ptr( T* inT ) : t(inT) {}
    T* operator*() { return t; }

  private:
    T* t;
};

template<class T>
struct unwrap
{
    Ptr<AnyType> operator()( T& ) {}
};

template<class C>
class X
{
  public:
    void find1( Ptr<AnyType> object )
    {
	unwrap<C*> myUnwrap;
	C* pClass( myUnwrap(*object));
    }

    void find2( Ptr<AnyType> object )
    {
	C* pClass( unwrap<C*>()(*object));
    }
};


From mark at codesourcery.com  Wed Jun 27 19:44:34 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Wed, 27 Jun 2001 12:44:34 -0700
Subject: Compilation problem with gcc-3.0
In-Reply-To: <15162.14882.302137.947192@saltydog.lanl.gov>
Message-ID: <55910000.993671074@warlock.codesourcery.com>



--On Wednesday, June 27, 2001 01:55:14 PM -0600 Dave Nystrom <wdn at lanl.gov> 
wrote:

> Below is a small test case that includes two functions, find1 and find2.
> When I try to compile this with the g++ from gcc-3.0, I get the following
> error:

Yes, this is a famous problem in GCC -- it uses a YACC parser that
doesn't have enough look-ahead to see whether or not that construct
is a function-declaration or an expression.  We need a new parser.

I've begged LANL to let me do that for years -- and they agreed!  In
fact, what I'm working on right now, is writing a nice bright shiny new
C++ parser -- and it aready gets this example correct.  So, I'd expect
this to be fixed in G++ 3.1, probably ready in about 6 months.  And,
in development snaphots before that.

Besides the workaround you found, another one that usually works is:

  C* pclass ((0, unwrap<C*>()(*object)));

The `0' can't appear in a parameter-declaration, so g++ knows pclass
is a variable, and not a function.

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


From zander at lanl.gov  Wed Jun 27 21:07:39 2001
From: zander at lanl.gov (Mark Zander)
Date: Wed, 27 Jun 2001 15:07:39 -0600
Subject: [pooma-dev] Compilation problem with gcc-3.0
In-Reply-To: <15162.14882.302137.947192@saltydog.lanl.gov>
Message-ID: <5.0.1.4.2.20010627145214.02d17d70@cic-mail.lanl.gov>

Dave,

unwrap takes an AnyType and attempts to turn it into a specific type. At 
the time I wanted to write it as a function:

         T* t = unwrap<T*>(any);

Unfortunately, that syntax wasn't available to me in the compilers we were 
using. Is that explicit function specification? Not having that available I 
templated a whole class, and with a dummy constructor could end up with 
(almost) the same syntax:

         T* t = unwrap<T*>()(any);

Later, after the code was well in place, I realized that a static member 
function would be more efficient and wouldn't rely on an optimizing 
compiler to delete the code of a dummy constructor:

         T* t = unwrap<T*>::do_it(any);

Can we just rewrite unwrap as a function and get rid of all of those dummy 
constructors as shown in the first example above?

By the way your example for unwrap is wrong, it should be:

template<class T>
struct unwrap
{
     T* operator()( Ptr<AnyType>) {}
};

But maybe we could rewrite it as:

template<class T>
T* unwrap(Ptr<AnyType>) {}

Please stop by my office some time so we can finish hashing this out. Even 
though an improved compiler will compile this awkward construct, the 
compiler features are available such that we can eliminate the awkward 
construct altogether.

Mark


At 01:55 PM 6/27/2001 -0600, Dave Nystrom wrote:
>Hi Mark,
>
>John and I have been doing a little work to try and compile our stuff with
>gcc-3.0 which just came out.  We have been able to compile Pooma 2
>successfully with gcc-3.0 and several people on the Pooma 2 support contract
>are using it - so, we are optimistic about our chances.  Last night we ran
>into a problem in TecFramework for which John was able to contrive a
>workaround.  The message below which I am bouncing to you I sent to Mark
>Mitchell and the pooma-dev mailing list.  Also, below, I have included Mark
>Mitchell's response in which he offers another workaround.  So, there are two
>workarounds to this ubiquitous construct that TecFramework uses.  We don't
>really understand Mark's workaround but it is a one liner versus our two
>liner.  Assuming it really works, John says that it would be easier to go
>back and change the one liner than the two liner when gcc-3.1 is released.
>Anyway, what do you and Sid think is the best way to resolve this problem.
>We are very interested in being able to build and run with gcc if possible.
>
>Dave Nystrom                    email: wdn at lanl.gov
>LANL X-3                        phone: 505-667-7913     fax: 505-665-3046
>
>--------------------------original-message-to-mark-mitchell-------------------------------
>Below is a small test case that includes two functions, find1 and find2.
>When I try to compile this with the g++ from gcc-3.0, I get the following
>error:
>
>saltydog % make
>g++ -c -o tUnwrapKernel.o tUnwrapKernel.cc
>tUnwrapKernel.cc: In member function `void X<C>::find2(Ptr<AnyType>)':
>tUnwrapKernel.cc:33: parse error before `;' token
>make: *** [tUnwrapKernel.o] Error 1
>
>The construct in the find2 function, i.e.
>"C* pClass( unwrap<C*>()(*object) );" is ubiquitous in our TecFramework
>library package.  John Hall and I experimented last night with various
>attempts to eliminate the error by using typename, etc.  The only solution we
>found was to replace this construct with the two line construct that is in
>the find1 function.  The original construct compiles just fine with KCC-4.0
>using --strict.  Is the failure to compile a problem with gcc-3.0 or is KCC
>taking liberties that it should not.  If there is a problem with gcc, would
>it be possible to get a fix anytime soon.  We would like to get our code up
>and running with gcc but making this change in so many places in our source
>code base would be tedious and undesirable if there is really a problem with
>gcc.  Also, we do not really own TecFramework and making these changes would
>require negotiation with other people - this is not really that big of a deal
>but we would just as soon avoid it if possible.
>
>Thanks,
>
>Dave Nystrom                    email: wdn at lanl.gov
>LANL X-3                        phone: 505-667-7913     fax: 505-665-3046
>
>--------------------------------test.cc---------------------------------------
>class AnyType
>{};
>
>template<class T>
>class Ptr
>{
>   public:
>     Ptr( T* inT ) : t(inT) {}
>     T* operator*() { return t; }
>
>   private:
>     T* t;
>};
>
>template<class T>
>struct unwrap
>{
>     Ptr<AnyType> operator()( T& ) {}
>};
>
>template<class C>
>class X
>{
>   public:
>     void find1( Ptr<AnyType> object )
>     {
>         unwrap<C*> myUnwrap;
>         C* pClass( myUnwrap(*object));
>     }
>
>     void find2( Ptr<AnyType> object )
>     {
>         C* pClass( unwrap<C*>()(*object));
>     }
>};
>
>---------------------------------------mark-mitchell's-response---------------------------------------
>--On Wednesday, June 27, 2001 01:55:14 PM -0600 Dave Nystrom <wdn at lanl.gov>
>wrote:
>
> > Below is a small test case that includes two functions, find1 and find2.
> > When I try to compile this with the g++ from gcc-3.0, I get the following
> > error:
>
>Yes, this is a famous problem in GCC -- it uses a YACC parser that
>doesn't have enough look-ahead to see whether or not that construct
>is a function-declaration or an expression.  We need a new parser.
>
>I've begged LANL to let me do that for years -- and they agreed!  In
>fact, what I'm working on right now, is writing a nice bright shiny new
>C++ parser -- and it aready gets this example correct.  So, I'd expect
>this to be fixed in G++ 3.1, probably ready in about 6 months.  And,
>in development snaphots before that.
>
>Besides the workaround you found, another one that usually works is:
>
>   C* pclass ((0, unwrap<C*>()(*object)));
>
>The `0' can't appear in a parameter-declaration, so g++ knows pclass
>is a variable, and not a function.



From JimC at proximation.com  Wed Jun 27 21:12:32 2001
From: JimC at proximation.com (James Crotinger)
Date: Wed, 27 Jun 2001 14:12:32 -0700
Subject: [pooma-dev] Domain::operator<
Message-ID: <F871BB04B0EA224A821A5274C31DF3152C57@proxim-sf001.santafe.proximation.com>

> as the output. What exactly were you doing in your analysis? On the 
> broader issue as to why operator< exists at all: I can think 
> of no other 
> reason than wanting to put domains in a map. Is LessThanComparable 
> required for map elements?

LessThanComparable is not required as map uses a compare functor instead of
directly using operator<(). But I think you knew that. The actual
requirement is that the compare functor impose a strict weak ordering on the
keys. Which is just saying that it must do for the keys what < normally
does.

	Jim
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010627/4f823ebb/attachment.html>

From wdn at lanl.gov  Thu Jun 28 16:48:28 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Thu, 28 Jun 2001 10:48:28 -0600
Subject: [pooma-dev] Compilation problem with gcc-3.0
In-Reply-To: <5.0.1.4.2.20010627145214.02d17d70@cic-mail.lanl.gov>
References: <15162.14882.302137.947192@saltydog.lanl.gov>
	<5.0.1.4.2.20010627145214.02d17d70@cic-mail.lanl.gov>
Message-ID: <15163.24540.848339.407825@gargle.gargle.HOWL>

Mark Zander writes:
 > Please stop by my office some time so we can finish hashing this out. Even 
 > though an improved compiler will compile this awkward construct, the 
 > compiler features are available such that we can eliminate the awkward 
 > construct altogether.

Hi Mark,

John and I will be happy to accept whatever decision that you and Sid work
out.  I am leaving soon - July 7 - for a month of vacation back on the east
coast i.e. a family reunion and so am scrambling to get things done for John,
Jean and Don that they need done before I leave.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046


From cummings at linkline.com  Thu Jun 28 18:21:13 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Thu, 28 Jun 2001 11:21:13 -0700
Subject: [pooma-dev] RFA: Tiny Changes to tests/makefile's
In-Reply-To: <20010625134118.A16514@codesourcery.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGMECNCCAA.cummings@linkline.com>

Jeffrey,

These changes appear OK to me, although I'm a bit 
confused because it looks like some of the "run"
targets don't actually run the tests but just build
them.  Is that what you intended?  Anyway, making 
these targets have more uniform behavior for the
purposes of regression testing is a good thing.

Julian C.


> -----Original Message-----
> From: Jeffrey Oldham [mailto:oldham at codesourcery.com]
> Sent: Monday, June 25, 2001 1:41 PM
> To: pooma-dev at pooma.codesourcery.com
> Cc: scotth at proximation.com
> Subject: [pooma-dev] RFA: Tiny Changes to tests/makefile's
> 
> 
> As I worked toward a system that will automatically check for changes
> in Pooma regression tests, I discovered several testing makefiles that
> needed slight revisions.  Several did not contain `run' targets.
> Others needed small other changes.
> 
> OK to commit?
> 
> (These filenames are all relative to the `src' directory.)
> 
> 2001-06-25  Jeffrey D. Oldham  <oldham at codesourcery.com>
> 
> 	* Connect/Lux/tests/makefile (run): New target.
> 	* Connect/Paws/tests/makefile (run): Likewise.
> 	* IO/tests/makefile (run_tests): Add dependence on `tests'.
> 	* NewField/tests/makefile (field_tests): Add StencilTests.
> 	* Partition/tests/makefile (run): New target.
> 	* Pooma/tests/makefile (tests): Likewise.
> 	(run): Likewise.
> 	* Threads/tests/makefile: Likewise.
> 	* Tulip/tests/ReduceOverContextsTest.cpp (main): Change function
> 	call to object creation and then function call.
> 
> Tested on	sequential Linux using GNU make version 3.78.1
> 		  by running "make run" in the associated test directory
> Approved by	???you???
> 
> Thanks,
> Jeffrey D. Oldham
> oldham at codesourcery.com


From cummings at linkline.com  Thu Jun 28 18:21:14 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Thu, 28 Jun 2001 11:21:14 -0700
Subject: [pooma-dev] RFA: Utilities/Tester.h: Fix Typographical Error
In-Reply-To: <20010625145033.A16695@codesourcery.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGOECNCCAA.cummings@linkline.com>

This is OK.  -- Julian C.


> -----Original Message-----
> From: Jeffrey Oldham [mailto:oldham at codesourcery.com]
> Sent: Monday, June 25, 2001 2:51 PM
> To: pooma-dev at pooma.codesourcery.com
> Cc: stephens at proximation.com
> Subject: [pooma-dev] RFA: Utilities/Tester.h: Fix Typographical Error
> 
> 
> OK to commit this patch?
> 
> 2001-06-25  Jeffrey D. Oldham  <oldham at codesourcery.com>
> 
> 	* Tester.h (Full Description): Fix subject-verb agreement error in
> 	these comments.
> 
> Untested	since it changes a comment.
> Approved by	???you???
> 
> Thanks,
> Jeffrey D. Oldham
> oldham at codesourcery.com


From cummings at linkline.com  Thu Jun 28 18:21:14 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Thu, 28 Jun 2001 11:21:14 -0700
Subject: [pooma-dev] RFA: Tulip/SendReceive.h: Reorder Initializers
In-Reply-To: <20010626135350.A31324@codesourcery.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGAECOCCAA.cummings@linkline.com>

This patch is OK.  -- Julian C.


> -----Original Message-----
> From: Jeffrey Oldham [mailto:oldham at codesourcery.com]
> Sent: Tuesday, June 26, 2001 1:54 PM
> To: pooma-dev at pooma.codesourcery.com
> Subject: [pooma-dev] RFA: Tulip/SendReceive.h: Reorder Initializers
> 
> 
> OK to commit this patch?
> 
> This patch reorders initializers to reflect declaration order.
> 
> 2001-06-26  Jeffrey D. Oldham  <oldham at codesourcery.com>
> 
> 	* SendReceive.h (SendIterate::SendIterate): Reorder initializers.
> 	(ReceiveIterate::ReceiveIterate): Likewise.
> 
> Tested on	sequential Linux gcc3.0 by compiling Pooma library
> Approved by	???you???
> 
> Thanks,
> Jeffrey D. Oldham
> oldham at codesourcery.com


From cummings at linkline.com  Thu Jun 28 18:31:20 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Thu, 28 Jun 2001 11:31:20 -0700
Subject: [pooma-dev] RFA: Miscellaneous src Changes
In-Reply-To: <20010626192913.A4787@codesourcery.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGEECOCCAA.cummings@linkline.com>

I have tested this patch with gcc on cygwin
and everything seems to be OK.

Julian C.


> -----Original Message-----
> From: Jeffrey Oldham [mailto:oldham at codesourcery.com]
> Sent: Tuesday, June 26, 2001 7:29 PM
> To: pooma-dev at pooma.codesourcery.com
> Subject: [pooma-dev] RFA: Miscellaneous src Changes
> 
> 
> OK to commit this patch?
> 
> This patch fixes minor spelling errors and rorders member initializers
> according to class declarations.
> 
> 2001-06-26  Jeffrey D. Oldham  <oldham at codesourcery.com>
> 
> 	* Domain/DomainArithOpsTraits.h: Fix spelling mistake.
> 	* Domain/DomainBlockIterator.h
> 	(DomainBlockIterator::DomainBlockIterator): Reorder initializers
> 	according to declaration order.
> 	* Layout/GridLayout.cpp (GridLayout::GridLayout): Likewise.
> 	* NewField/FieldEngine/FieldEngineBase.h: Fix spelling mistake.
> 	* Partition/GridPartition.h (GridPartition::GridPartition):
> 	Reorder initializers according to declaration order.
> 	(GridPartition::partition): Remove unused variable.
> 	* Utilities/Tester.h: Fix subject-verb agreement.
> 
> Tested on	sequential Linux using gcc3.0 by compiling Pooma library
> Approved by	???you???
> 
> Thanks,
> Jeffrey D. Oldham
> oldham at codesourcery.com


From oldham at codesourcery.com  Thu Jun 28 18:54:30 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Thu, 28 Jun 2001 11:54:30 -0700
Subject: Patch: Tiny Changes to tests/makefiles
Message-ID: <20010628115430.A21962@codesourcery.com>

As I worked toward a system that will automatically check for changes
in Pooma regression tests, I discovered several testing makefiles that
needed slight revisions.  Given Julian Cummings's comment that some
makefiles do not actually run the executables, I eliminated my
proposed addition of "run" targets for these makefiles but kept the
remaining changes.

2001-06-28  Jeffrey D. Oldham  <oldham at codesourcery.com>

	* IO/tests/makefile (run_tests): Add dependence on `tests'.
	* NewField/tests/makefile (field_tests): Add StencilTests.
	* Partition/tests/makefile (run): New target.
	* Pooma/tests/makefile (tests): Likewise.
	* Tulip/tests/ReduceOverContextsTest.cpp (main): Change function
	call to object creation and then function call.

Tested on       sequential Linux using GNU make version 3.78.1
                  by running "make run" in the associated test directory
Approved by     Julian C. Cummings (cummings at linkline.com)

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: IO/tests/makefile
===================================================================
RCS file: /home/pooma/Repository/r2/src/IO/tests/makefile,v
retrieving revision 1.25
diff -c -p -r1.25 makefile
*** IO/tests/makefile	2000/07/27 12:33:24	1.25
--- IO/tests/makefile	2001/06/25 20:25:12
*************** tests:: testBaseSerializers testMatrixSe
*** 43,49 ****
  run: run_tests
  	cat *.out
  
! run_tests:
  	$(ODIR)/testBaseSerializers $(TSTOPTS) 1>testBaseSerializers.out 2>&1
  	$(ODIR)/testMatrixSerializers $(TSTOPTS) 1>testMatrixSerializers.out 2>&1
  	$(ODIR)/testLayoutSerializers $(TSTOPTS) 1>testLayoutSerializers.out 2>&1
--- 43,49 ----
  run: run_tests
  	cat *.out
  
! run_tests: tests
  	$(ODIR)/testBaseSerializers $(TSTOPTS) 1>testBaseSerializers.out 2>&1
  	$(ODIR)/testMatrixSerializers $(TSTOPTS) 1>testMatrixSerializers.out 2>&1
  	$(ODIR)/testLayoutSerializers $(TSTOPTS) 1>testLayoutSerializers.out 2>&1
Index: NewField/tests/makefile
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/tests/makefile,v
retrieving revision 1.10
diff -c -p -r1.10 makefile
*** NewField/tests/makefile	2001/05/14 21:11:24	1.10
--- NewField/tests/makefile	2001/06/25 20:25:12
*************** run_tests: tests
*** 58,64 ****
  field_tests:: $(ODIR)/BasicTest1 $(ODIR)/BasicTest2 \
  	$(ODIR)/FieldTour1 $(ODIR)/FieldTour2 \
  	$(ODIR)/WhereTest $(ODIR)/VectorTest \
! 	$(ODIR)/ScalarCode $(ODIR)/ExpressionTest
  
  
  ###########################
--- 58,65 ----
  field_tests:: $(ODIR)/BasicTest1 $(ODIR)/BasicTest2 \
  	$(ODIR)/FieldTour1 $(ODIR)/FieldTour2 \
  	$(ODIR)/WhereTest $(ODIR)/VectorTest \
! 	$(ODIR)/ScalarCode $(ODIR)/StencilTests \
!         $(ODIR)/ExpressionTest
  
  
  ###########################
Index: Partition/tests/makefile
===================================================================
RCS file: /home/pooma/Repository/r2/src/Partition/tests/makefile,v
retrieving revision 1.5
diff -c -p -r1.5 makefile
*** Partition/tests/makefile	2000/07/21 18:29:22	1.5
--- Partition/tests/makefile	2001/06/25 20:25:13
*************** default:: partition_tests
*** 42,47 ****
--- 42,49 ----
  
  tests:: partition_tests
  
+ run:: partition_tests
+ 
  run_tests: partition_tests
  	$(ODIR)/ugp_test $(TSTOPTS) 1>ugp_test.out 2>&1
  
Index: Pooma/tests/makefile
===================================================================
RCS file: /home/pooma/Repository/r2/src/Pooma/tests/makefile,v
retrieving revision 1.4
diff -c -p -r1.4 makefile
*** Pooma/tests/makefile	2000/07/21 18:29:22	1.4
--- Pooma/tests/makefile	2001/06/25 20:25:13
*************** include $(PROJECT_ROOT)/config/head.mk
*** 33,38 ****
--- 33,42 ----
  
  default:: finalize pooma
  
+ tests:: finalize pooma
+ 
+ run:: tests
+ 
  .PHONY: pooma
  .PHONY: finalize
  
Index: Tulip/tests/ReduceOverContextsTest.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/Tulip/tests/ReduceOverContextsTest.cpp,v
retrieving revision 1.1
diff -c -p -r1.1 ReduceOverContextsTest.cpp
*** Tulip/tests/ReduceOverContextsTest.cpp	2000/06/06 16:51:00	1.1
--- Tulip/tests/ReduceOverContextsTest.cpp	2001/06/25 20:25:13
*************** int main(int argc, char *argv[])
*** 68,74 ****
  
    int result1;
  
!   SumReduction_t(foo[myContext]).broadcast(result1);  
  
    BARRIER;
  
--- 68,75 ----
  
    int result1;
  
!   SumReduction_t goo(foo[myContext]);
!   goo.broadcast(result1);  
  
    BARRIER;
  

From oldham at codesourcery.com  Thu Jun 28 18:58:02 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Thu, 28 Jun 2001 11:58:02 -0700
Subject: Patch: Utilities/Tester.h: Fix Subject/Verb Agreement
Message-ID: <20010628115802.B21962@codesourcery.com>

2001-06-28  Jeffrey D. Oldham  <oldham at codesourcery.com>

        * Tester.h (Full Description): Fix subject-verb agreement error in
        these comments.

Untested        since it changes a comment.
Approved by	Julian C. Cummings (cummings at linkline.com)

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: Tester.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Utilities/Tester.h,v
retrieving revision 1.10
diff -c -p -r1.10 Tester.h
*** Tester.h	2000/03/28 01:10:57	1.10
--- Tester.h	2001/06/25 21:47:02
***************
*** 88,94 ****
  //        PASSED ..... message
  //    or
  //        FAILED ..... message
! //    depending on the current value of the OK flag.  It return an exit
  //    code value, 1 if the test FAILED, 0 if the test PASSED, that you can
  //    use to return from main.  For example:
  //
--- 88,94 ----
  //        PASSED ..... message
  //    or
  //        FAILED ..... message
! //    depending on the current value of the OK flag.  It returns an exit
  //    code value, 1 if the test FAILED, 0 if the test PASSED, that you can
  //    use to return from main.  For example:
  //

From oldham at codesourcery.com  Thu Jun 28 19:02:43 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Thu, 28 Jun 2001 12:02:43 -0700
Subject: Patch: Tulp/SendReceive.h: Reorder Initializers
Message-ID: <20010628120243.C21962@codesourcery.com>

This patch reorders initializers to reflect declaration order.

2001-06-28  Jeffrey D. Oldham  <oldham at codesourcery.com>

        * SendReceive.h (SendIterate::SendIterate): Reorder initializers.
        (ReceiveIterate::ReceiveIterate): Likewise.

Tested on       sequential Linux gcc3.0 by compiling Pooma library
Approved by	Julian C. Cummings (cummings at linkline.com)

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: SendReceive.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Tulip/SendReceive.h,v
retrieving revision 1.8
diff -c -p -r1.8 SendReceive.h
*** SendReceive.h	2000/06/20 20:46:30	1.8
--- SendReceive.h	2001/06/26 20:44:53
*************** class SendIterate
*** 86,94 ****
  public:
    SendIterate(const View &view, int toContext, int tag)
      : Pooma::Iterate_t(Pooma::scheduler()),
-       view_m(view),
        toContext_m(toContext),
!       tag_m(tag)
   {
      PAssert(toContext >= 0);
     
--- 86,94 ----
  public:
    SendIterate(const View &view, int toContext, int tag)
      : Pooma::Iterate_t(Pooma::scheduler()),
        toContext_m(toContext),
!       tag_m(tag),
!       view_m(view)
   {
      PAssert(toContext >= 0);
     
*************** public:
*** 153,162 ****
    typedef ReceiveIterate<View, IncomingView> This_t;
  
    ReceiveIterate(const View &view, int fromContext, int tag)
!     : view_m(view),
        fromContext_m(fromContext),
        tag_m(tag),
!       Pooma::Iterate_t(Pooma::scheduler())
    {
      PAssert(fromContext >= 0);
      
--- 153,162 ----
    typedef ReceiveIterate<View, IncomingView> This_t;
  
    ReceiveIterate(const View &view, int fromContext, int tag)
!     : Pooma::Iterate_t(Pooma::scheduler()),
        fromContext_m(fromContext),
        tag_m(tag),
!       view_m(view)
    {
      PAssert(fromContext >= 0);
      

From oldham at codesourcery.com  Thu Jun 28 19:09:48 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Thu, 28 Jun 2001 12:09:48 -0700
Subject: Patch: Miscellaneous src Changes
Message-ID: <20010628120948.D21962@codesourcery.com>

This patch fixes minor spelling errors and rorders member initializers
according to class declarations.

2001-06-28  Jeffrey D. Oldham  <oldham at codesourcery.com>

	* Domain/DomainArithOpsTraits.h: Fix spelling mistake.
	* Domain/DomainBlockIterator.h
	(DomainBlockIterator::DomainBlockIterator): Reorder initializers
	according to declaration order.
	* Layout/GridLayout.cpp (GridLayout::GridLayout): Likewise.
	* NewField/FieldEngine/FieldEngineBase.h: Fix spelling mistake.
	* Partition/GridPartition.h (GridPartition::GridPartition):
	Reorder initializers according to declaration order.
	(GridPartition::partition): Remove unused variable.

Tested on       sequential Linux using gcc3.0 by compiling Pooma library
Approved by 	Julian C. Cummings (cummings at linkline.com)

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: Domain/DomainArithOpsTraits.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/DomainArithOpsTraits.h,v
retrieving revision 1.5
diff -c -p -r1.5 DomainArithOpsTraits.h
*** Domain/DomainArithOpsTraits.h	2000/03/07 13:16:33	1.5
--- Domain/DomainArithOpsTraits.h	2001/06/27 02:07:44
***************
*** 40,46 ****
  //-----------------------------------------------------------------------------
  // Overview: 
  // DomainArithOpsTraits is intended to be used to select the return type of 
! // arithmatic operations between domains and pseudo-domains comprising the following
  // list:
  
  // Loc<1> Loc<N> Interval<N> Range<N> IndirectionList<int> Grid<N>
--- 40,46 ----
  //-----------------------------------------------------------------------------
  // Overview: 
  // DomainArithOpsTraits is intended to be used to select the return type of 
! // arithmetic operations between domains and pseudo-domains comprising the following
  // list:
  
  // Loc<1> Loc<N> Interval<N> Range<N> IndirectionList<int> Grid<N>
Index: Domain/DomainBlockIterator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/DomainBlockIterator.h,v
retrieving revision 1.7
diff -c -p -r1.7 DomainBlockIterator.h
*** Domain/DomainBlockIterator.h	2001/04/13 02:12:59	1.7
--- Domain/DomainBlockIterator.h	2001/06/27 02:07:45
*************** private:
*** 292,298 ****
  
  template<class Dom>
  DomainBlockIterator<Dom>::DomainBlockIterator(const Dom &d)
!   : domain_m(d), index_m(0), loc_m(0)
  {
    for (int i=0; i < dimensions; ++i)
      {
--- 292,298 ----
  
  template<class Dom>
  DomainBlockIterator<Dom>::DomainBlockIterator(const Dom &d)
!   : domain_m(d), loc_m(0), index_m(0)
  {
    for (int i=0; i < dimensions; ++i)
      {
*************** DomainBlockIterator<Dom>::DomainBlockIte
*** 332,339 ****
  
  template<class Dom>
  DomainBlockIterator<Dom>::DomainBlockIterator(const This_t &model)
!   : domain_m(model.domain_m), block_m(model.block_m),
!     loc_m(model.loc_m), index_m(model.index_m)
  {
    for (int i=0; i < dimensions; ++i)
      current_m[i] = model.current_m[i];
--- 332,339 ----
  
  template<class Dom>
  DomainBlockIterator<Dom>::DomainBlockIterator(const This_t &model)
!   : domain_m(model.domain_m), loc_m(model.loc_m),
!     block_m(model.block_m), index_m(model.index_m)
  {
    for (int i=0; i < dimensions; ++i)
      current_m[i] = model.current_m[i];
Index: Layout/GridLayout.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/Layout/GridLayout.cpp,v
retrieving revision 1.85
diff -c -p -r1.85 GridLayout.cpp
*** Layout/GridLayout.cpp	2001/04/18 02:15:33	1.85
--- Layout/GridLayout.cpp	2001/06/27 02:07:47
*************** GridLayout<Dim>::GridLayout(const Domain
*** 1071,1082 ****
  template <int Dim>
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid,
  			    const DistributedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >( 
        new LayoutData_t( grid, 
  			GridPartition<Dim>(grid),
! 			DistributedMapper<Dim>(GridPartition<Dim>(grid))))
! 
  {
    pdata_m->attach(*this);
  }
--- 1071,1081 ----
  template <int Dim>
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid,
  			    const DistributedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >( 
        new LayoutData_t( grid, 
  			GridPartition<Dim>(grid),
! 			DistributedMapper<Dim>(GridPartition<Dim>(grid)))),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** GridLayout<Dim>::GridLayout(const Grid<D
*** 1084,1095 ****
  template <int Dim>
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid,
  			    const ReplicatedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >( 
        new LayoutData_t( grid, 
  			GridPartition<Dim>(grid),
! 			LocalMapper<Dim>()))
! 
  {
    pdata_m->attach(*this);
  }
--- 1083,1093 ----
  template <int Dim>
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid,
  			    const ReplicatedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >( 
        new LayoutData_t( grid, 
  			GridPartition<Dim>(grid),
! 			LocalMapper<Dim>())),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** template <int Dim>
*** 1098,1108 ****
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid, 
  			    const GuardLayers_t &gcs,
  			    const DistributedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >
  ( new LayoutData_t( grid, 
  		    GridPartition<Dim>(grid,gcs),
! 		    DistributedMapper<Dim>(GridPartition<Dim>(grid,gcs) )) )
  {
    pdata_m->attach(*this);
  }
--- 1096,1106 ----
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid, 
  			    const GuardLayers_t &gcs,
  			    const DistributedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >
  ( new LayoutData_t( grid, 
  		    GridPartition<Dim>(grid,gcs),
! 		    DistributedMapper<Dim>(GridPartition<Dim>(grid,gcs) )) ),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** template <int Dim>
*** 1111,1121 ****
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid, 
  			    const GuardLayers_t &gcs,
  			    const ReplicatedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >
  ( new LayoutData_t( grid, 
  		    GridPartition<Dim>(grid,gcs),
! 		    LocalMapper<Dim>()) )
  {
    pdata_m->attach(*this);
  }
--- 1109,1119 ----
  GridLayout<Dim>::GridLayout(const Grid<Dim> &grid, 
  			    const GuardLayers_t &gcs,
  			    const ReplicatedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >
  ( new LayoutData_t( grid, 
  		    GridPartition<Dim>(grid,gcs),
! 		    LocalMapper<Dim>()) ),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** GridLayout<Dim>::GridLayout(const Grid<D
*** 1126,1136 ****
  			    const GuardLayers_t &igcs, 
  			    const GuardLayers_t &egcs,
  			    const DistributedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >
  (new LayoutData_t(grid, 
  		  GridPartition<Dim>(grid,igcs,egcs),
! 		  DistributedMapper<Dim>(GridPartition<Dim>(grid,igcs,egcs))))
  {
    pdata_m->attach(*this);
  }
--- 1124,1134 ----
  			    const GuardLayers_t &igcs, 
  			    const GuardLayers_t &egcs,
  			    const DistributedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >
  (new LayoutData_t(grid, 
  		  GridPartition<Dim>(grid,igcs,egcs),
! 		  DistributedMapper<Dim>(GridPartition<Dim>(grid,igcs,egcs)))),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** GridLayout<Dim>::GridLayout(const Grid<D
*** 1141,1151 ****
  			    const GuardLayers_t &igcs, 
  			    const GuardLayers_t &egcs,
  			    const ReplicatedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >
  (new LayoutData_t( grid, 
  		   GridPartition<Dim>(grid,igcs,egcs),
! 		   LocalMapper<Dim>() ) )
  {
    pdata_m->attach(*this);
  }
--- 1139,1149 ----
  			    const GuardLayers_t &igcs, 
  			    const GuardLayers_t &egcs,
  			    const ReplicatedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >
  (new LayoutData_t( grid, 
  		   GridPartition<Dim>(grid,igcs,egcs),
! 		   LocalMapper<Dim>() ) ),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** template <class Partitioner>
*** 1155,1165 ****
  GridLayout<Dim>::GridLayout(const Domain_t &gdom, 
  			    const Partitioner &gpar,
  			    const DistributedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >
  (new LayoutData_t(gdom, 
  		  gpar,
! 		  DistributedMapper<Dim>(gpar)) )
  {
    pdata_m->attach(*this);
  }
--- 1153,1163 ----
  GridLayout<Dim>::GridLayout(const Domain_t &gdom, 
  			    const Partitioner &gpar,
  			    const DistributedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >
  (new LayoutData_t(gdom, 
  		  gpar,
! 		  DistributedMapper<Dim>(gpar)) ),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** template <class Partitioner>
*** 1169,1179 ****
  GridLayout<Dim>::GridLayout(const Domain_t &gdom, 
  			    const Partitioner &gpar,
  			    const ReplicatedTag &)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >
! (new LayoutData_t(gdom, 
! 		  gpar,
! 		  LocalMapper<Dim>()) )
  {
    pdata_m->attach(*this);
  }
--- 1167,1177 ----
  GridLayout<Dim>::GridLayout(const Domain_t &gdom, 
  			    const Partitioner &gpar,
  			    const ReplicatedTag &)
!   : LayoutBase<Dim,GridLayoutData<Dim> >
!       (new LayoutData_t(gdom, 
!        		  	gpar,
! 			LocalMapper<Dim>()) ),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
*************** template <class Partitioner>
*** 1183,1198 ****
  GridLayout<Dim>::GridLayout(const Domain_t &gdom, 
  			    const Partitioner &gpar,
  			    const ContextMapper<Dim> &cmap)
!   : Observable<This_t>(*this), 
!     LayoutBase<Dim,GridLayoutData<Dim> >(new LayoutData_t(gdom, gpar, cmap) )
  {
    pdata_m->attach(*this);
  }
  
  template <int Dim>
  GridLayout<Dim>::GridLayout(const This_t &model) 
!   : Observable<This_t>(*this),
!     LayoutBase<Dim,GridLayoutData<Dim> >(model.pdata_m)
  { 
     pdata_m->attach(*this);
  }
--- 1181,1196 ----
  GridLayout<Dim>::GridLayout(const Domain_t &gdom, 
  			    const Partitioner &gpar,
  			    const ContextMapper<Dim> &cmap)
!   : LayoutBase<Dim,GridLayoutData<Dim> >(new LayoutData_t(gdom, gpar, cmap) ),
!     Observable<This_t>(*this)
  {
    pdata_m->attach(*this);
  }
  
  template <int Dim>
  GridLayout<Dim>::GridLayout(const This_t &model) 
!   : LayoutBase<Dim,GridLayoutData<Dim> >(model.pdata_m),
!     Observable<This_t>(*this)
  { 
     pdata_m->attach(*this);
  }
Index: NewField/FieldEngine/FieldEngineBase.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngineBase.h,v
retrieving revision 1.12
diff -c -p -r1.12 FieldEngineBase.h
*** NewField/FieldEngine/FieldEngineBase.h	2001/05/14 21:11:24	1.12
--- NewField/FieldEngine/FieldEngineBase.h	2001/06/27 02:07:47
***************
*** 39,45 ****
  // 
  // FieldEngineBase and related classes. POOMA supports a flexible form 
  // of "centering" that allows a hierarchy of multiple centering points per 
! // cell. The centering information, managemed by the FieldEngineBase
  // class, is initialized using a flexible set of functors.
  //-----------------------------------------------------------------------------
  
--- 39,45 ----
  // 
  // FieldEngineBase and related classes. POOMA supports a flexible form 
  // of "centering" that allows a hierarchy of multiple centering points per 
! // cell. The centering information, managed by the FieldEngineBase
  // class, is initialized using a flexible set of functors.
  //-----------------------------------------------------------------------------
  
Index: Partition/GridPartition.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Partition/GridPartition.h,v
retrieving revision 1.27
diff -c -p -r1.27 GridPartition.h
*** Partition/GridPartition.h	2001/04/18 02:17:11	1.27
--- Partition/GridPartition.h	2001/06/27 02:20:26
*************** public:
*** 153,163 ****
  
  
    GridPartition(const Grid<Dim> &g)
!     : grid_m(g), 
!       hasInternalGuards_m(false), 
        hasExternalGuards_m(false),
        internalGuards_m(0),
!       externalGuards_m(0)
    {
      num_m=1;
      for (int i=0;i<Dim;i++)
--- 153,163 ----
  
  
    GridPartition(const Grid<Dim> &g)
!     : hasInternalGuards_m(false), 
        hasExternalGuards_m(false),
        internalGuards_m(0),
!       externalGuards_m(0),
!       grid_m(g)
    {
      num_m=1;
      for (int i=0;i<Dim;i++)
*************** public:
*** 170,180 ****
    
    GridPartition(const Grid<Dim> &g, 
  		const GuardLayers<Dim> &gcs)
!     : grid_m(g), 
!       hasInternalGuards_m(true),
        hasExternalGuards_m(true),
        internalGuards_m(gcs),
!       externalGuards_m(gcs)
    {
      num_m=1;
      for (int i=0;i<Dim;i++)
--- 170,180 ----
    
    GridPartition(const Grid<Dim> &g, 
  		const GuardLayers<Dim> &gcs)
!     : hasInternalGuards_m(true),
        hasExternalGuards_m(true),
        internalGuards_m(gcs),
!       externalGuards_m(gcs),
!       grid_m(g)
    {
      num_m=1;
      for (int i=0;i<Dim;i++)
*************** public:
*** 187,197 ****
    GridPartition(const Grid<Dim> &g, 
  		const GuardLayers<Dim> &igcs,
  		const GuardLayers<Dim> &egcs)
!     : grid_m(g),
!       hasInternalGuards_m(true), 
        hasExternalGuards_m(true), 
        internalGuards_m(igcs), 
!       externalGuards_m(egcs)
    {
      num_m=1;
      for (int i=0;i<Dim;i++)
--- 187,197 ----
    GridPartition(const Grid<Dim> &g, 
  		const GuardLayers<Dim> &igcs,
  		const GuardLayers<Dim> &egcs)
!     : hasInternalGuards_m(true), 
        hasExternalGuards_m(true), 
        internalGuards_m(igcs), 
!       externalGuards_m(egcs),
!       grid_m(g)
    {
      num_m=1;
      for (int i=0;i<Dim;i++)
*************** public:
*** 205,224 ****
    GridPartition() 
      : hasInternalGuards_m(false), 
        hasExternalGuards_m(false),
-       num_m(1),
        internalGuards_m(0),
!       externalGuards_m(0)
    {  
      for (int i=0;i<Dim;++i)
        blocks_m[i]=Loc<1>(1);
    }
  
    GridPartition(const Loc<Dim> &a)
!     : hasInternalGuards_m(false), 
        hasExternalGuards_m(false),
        internalGuards_m(0),
!       externalGuards_m(0),
!       blocks_m(a)
    {
      num_m = blocks_m[0].first();
      for (int d=1; d < Dim; ++d)
--- 205,224 ----
    GridPartition() 
      : hasInternalGuards_m(false), 
        hasExternalGuards_m(false),
        internalGuards_m(0),
!       externalGuards_m(0),
!       num_m(1)
    {  
      for (int i=0;i<Dim;++i)
        blocks_m[i]=Loc<1>(1);
    }
  
    GridPartition(const Loc<Dim> &a)
!     : blocks_m(a),
!       hasInternalGuards_m(false),
        hasExternalGuards_m(false),
        internalGuards_m(0),
!       externalGuards_m(0)
    {
      num_m = blocks_m[0].first();
      for (int d=1; d < Dim; ++d)
*************** public:
*** 227,237 ****
   
    GridPartition(const Loc<Dim> &a,
  		const GuardLayers<Dim> &gcs)
!     : hasInternalGuards_m(true), 
        hasExternalGuards_m(true), 
        internalGuards_m(gcs), 
!       externalGuards_m(gcs),
!       blocks_m(a) 
    { 
      num_m = blocks_m[0].first();
      for (int d=1; d < Dim; ++d) 
--- 227,237 ----
   
    GridPartition(const Loc<Dim> &a,
  		const GuardLayers<Dim> &gcs)
!     : blocks_m(a),
!       hasInternalGuards_m(true), 
        hasExternalGuards_m(true), 
        internalGuards_m(gcs), 
!       externalGuards_m(gcs)
    { 
      num_m = blocks_m[0].first();
      for (int d=1; d < Dim; ++d) 
*************** public:
*** 241,251 ****
    GridPartition(const Loc<Dim> &a,
  		const GuardLayers<Dim> &igcs, 
  		const GuardLayers<Dim> &egcs)
!     : hasInternalGuards_m(true), 
        hasExternalGuards_m(true), 
        internalGuards_m(igcs), 
!       externalGuards_m(egcs),
!       blocks_m(a) 
    {
      num_m = blocks_m[0].first();
      for (int d=1; d < Dim; ++d) 
--- 241,251 ----
    GridPartition(const Loc<Dim> &a,
  		const GuardLayers<Dim> &igcs, 
  		const GuardLayers<Dim> &egcs)
!     : blocks_m(a),
!       hasInternalGuards_m(true), 
        hasExternalGuards_m(true), 
        internalGuards_m(igcs), 
!       externalGuards_m(egcs)
    {
      num_m = blocks_m[0].first();
      for (int d=1; d < Dim; ++d) 
*************** public:
*** 255,265 ****
    // copy constructor
  
    GridPartition(const GridPartition<Dim> & b)
!     : hasInternalGuards_m(b.hasInternalGuards_m),
        hasExternalGuards_m(b.hasExternalGuards_m),
        internalGuards_m(b.internalGuards_m),
        externalGuards_m(b.externalGuards_m),
-       blocks_m(b.blocks_m),
        num_m(b.num_m),
        grid_m(b.grid_m)
    {
--- 255,265 ----
    // copy constructor
  
    GridPartition(const GridPartition<Dim> & b)
!     : blocks_m(b.blocks_m),
!       hasInternalGuards_m(b.hasInternalGuards_m),
        hasExternalGuards_m(b.hasExternalGuards_m),
        internalGuards_m(b.internalGuards_m),
        externalGuards_m(b.externalGuards_m),
        num_m(b.num_m),
        grid_m(b.grid_m)
    {
*************** public:
*** 268,278 ****
    // copy from a GP
    
   GridPartition(const UniformGridPartition<Dim> & b)
!    : hasInternalGuards_m(b.hasInternalGuards_m),
       hasExternalGuards_m(b.hasExternalGuards_m),
       internalGuards_m(b.internalGuards_m),
       externalGuards_m(b.externalGuards_m),
-      blocks_m(b.blocks_m),
       num_m(b.num_m)
    {}
  
--- 268,278 ----
    // copy from a GP
    
   GridPartition(const UniformGridPartition<Dim> & b)
!    : blocks_m(b.blocks_m),
!      hasInternalGuards_m(b.hasInternalGuards_m),
       hasExternalGuards_m(b.hasExternalGuards_m),
       internalGuards_m(b.internalGuards_m),
       externalGuards_m(b.externalGuards_m),
       num_m(b.num_m)
    {}
  
*************** public:
*** 408,414 ****
  
  	// Calculate the guard cell specification for this domain.
  	
- 	GuardLayers<Dim> gcs(0); // No guards by default.
  	if (hasInternalGuards()||hasExternalGuards())
  	  {
  	    for (int i=0;i<Dim;i++)
--- 408,413 ----

From oldham at codesourcery.com  Thu Jun 28 22:03:24 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Thu, 28 Jun 2001 15:03:24 -0700
Subject: [pooma-dev] Pooma Regression Testing: A First Approach
In-Reply-To: <200106260206.TAA20478@oz.codesourcery.com>; from oldham@codesourcery.com on Mon, Jun 25, 2001 at 07:06:32PM -0700
References: <200106260206.TAA20478@oz.codesourcery.com>
Message-ID: <20010628150324.A957@codesourcery.com>

On Mon, Jun 25, 2001 at 07:06:32PM -0700, Jeffrey Oldham wrote:
> 
> 	Using CodeSourcery's QMTest tool for automatically running a
> set of regression tests
> (http://software-carpentry.codesourcery.com/dev/), I have a
> provisional testsuite to run all the tests in the src/*/tests and
> src/*/*/tests directories.  On my sequential Linux computer using
> gcc3.0, all of these tests pass except
> src/DynamicArray/tests/dynamic_array_test5.cpp (iterator conversion
> problems) and src/Functions/tests/rngArray.cpp (gcc3.0 problem).
> 
> 	Sometime this week, I will start nightly tests so we can catch
> programming errors soon after they are introduced.

A nightly Cron job now tests checks the Pooma code for regressions
using a sequential Linux computer running gcc 3.0.  Since the code
changes infrequently, I do not plan to distribute daily results unless
someone requests them.

These two questions remain:

> 	1) What other regression tests, if any, should I include in the
> set of tests?  What about the benchmarks, examples, and test
> directories?  Are their makefiles set up to compare the results
> against desired results?

	2) What other configurations on a sequential Linux computer do
you want tested?

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From allan at stokes.ca  Fri Jun 29 11:45:38 2001
From: allan at stokes.ca (Allan Stokes)
Date: Fri, 29 Jun 2001 04:45:38 -0700
Subject: domain architecture diagram
Message-ID: <NABBJEAOKIDHLPHKHPDLEEMPEBAA.allan@stokes.ca>


Hello,

I spent a number of hours looking at relationships within the Domain sources
without becoming entirely conscious how many different boxes I was visiting.

As an experiment I decided to fork my own implementation of the Interval<>
class to see how much I could change without breaking higher level
dependencies.  The first thing I discovered is that I needed a diagram.

I mocked up a quasi-UML diagram which I prepared with the Dome UML editor.
This is available from http://www.src.honeywell.com/dome/ for Windows/Linux.
This diagram is attached as a GIF.

The first phase of the experiment was simply to clone Interval<> as
Interval2<> and succeed in running domaintest.cpp with the identical clone
Interval2<> substituted for all occurrences of Interval<>.

This required creating four new source files: Interval2.h,
DomainTraits.Interval2.h, NewDomain2.h, and DomainArithOpsTraits2.h

DomainTraits.Interval2.h and Interval2.h are just copies of the reference
implementation with all instances of Interval replaced by Interval2.

NewDomain2.h is my cloned copy of NewDomain.h which defines ten instances of
POOOMA_NEWDOMAIN_XXXX macro expansions.  These grant Interval2 the same
standing as Interval in new domain expressions.

DomainArithOpsTraits2.h defines a number of specializations of class
DomainArithOpTraits<> on the type Interval2<Dim>.

I have a number of comments about the relationships present in this diagram
which I could discuss, but I don't wish to duplicate material which I'm
already developing for the conceptual documentation.

I'll make a few comments to express some relationships I didn't fully
capture in the diagram and leave the full discussion for later.

The traits classes in the top right of the diagram are better thought of as
implementation classes.  DomainTraits<> is functioning as a catalog and
Interval<Dim> is functioning as a lookup tag.  Because Interval<> is using
itself to bind types to its own base classes, Interval<Dim> will be an
incomplete type in the context of any of the traits classes.  I haven't
determined yet whether the traits classes depend upon the lookup tag
actually being the same as the name of the Interval class being defined,
e.g. in a cast expression (can you do much else with an incomplete type?)

The top left shows the Interval classes and base classes.  Only the
relationship is not that of a base class.  It makes more sense to think of
these boxes as representing different interfaces to a single
implementation.

The key to understanding the structure is the declaration for the class
state.

template <> struct DomainTraits< Interval<1> >::Storage_t;

This type encapsulates the runtime state of any Interval<1> object.  The
N-dimensional case looks like this (paraphrased):

template <int Dim> struct DomainTraits< Interval<Dim> > {
  typedef UninitializedVector<Interval<1>,Dim,Element_t> Storage_t;
};

OK, that's interesting.  Interval<N> defines its state in terms of its own
specialization Interval<1>.

The only object with state is DomainBase which contains a member of this
type Storage_t.  All Interval<> objects inherit their state from this base
class via this idiom:

struct foo : public base<foo>;

It's important to note that polymorphism does not exist in this construct.
A unique downcast is always implied.  If the derived class contains no
state, the downcast becomes a change of interface and nothing more.

template <class DT>
class DomainBase {
  // unwrap this object back to its derived-class type
  inline
  Domain_t &unwrap() { return *static_cast<Domain_t *>(this); }

  // a const version of unwrap
  const Domain_t &unwrap() const {
    return *static_cast<Domain_t *>(const_cast<DomainBase<DT> *>(this));
  }
};

I'm curious why the second version is not written:

  static_cast<const Domain_t *>(this);

Is the two-step conversion required by the language, or was this shaped by
one of the compilers being used at the time?  I don't know the exact rules
of casting.  Is static_cast defined to leave constness unchanged?

In Pooma as it stands, these casts are essentially null-operations.
However, if a class derived from Interval<> employed virtual functions or
multiple inheritance, this would no longer be true.  However, this unwrap()
downcast would remain legal even if non-trivial.

I'm not certain that the unwrapped object can be used without restriction
within the DomainBase context; difficulties might arise involving incomplete
definition.  Mostly DomainBase delegates the Storage_t member to functions
in the traits class implementation (which defines Storage_t in the first
place, so the circularity evaporates).

There are two steps down in the downcast direction: Domain<Dim,Inteval<Dim>>
and Interval<Dim>.  These classes are effectively the same thing.
Interval<Dim> obtains its entire implementation from
Domain<Dim,Interval<Dim>>, excepting constructors and the assignment
operator.  In a sense, Interval<> implements a notation, Domain<> implements
the semantics.

The Domain<> layer has two distinct functions.  The obvious purpose is to
factor out commonalities between different domain components (Range,
Interval, Grid, etc.)

The less obvious purpose is that Domain<> is used in the higher layers of
Pooma to specialize function arguments to "all things domain" as a class.

For example, from DynamicLayout.h

template <class DT>
inline DynamicLayoutViewData(const Layout_t &layout,
                            const Domain<1,DT> &dom);

This template declaration matches any one-dimensional object of generic type
Domain.  You catch this object as a base class.  With a compile-time
downcast you recover the (uniquely typed) derived object.

>From the point of view of writing the conceptual documentation, none of the
relationships expressed in this graph as inheritance relationships are
functioning as runtime polymorphism.  The labels on the lines are deceptive.

In practical terms it's not easy to formulate conceptual documentation
unless you can envision multiple ways to implement a compliant object.  The
technique of matching on Domain<N,T> type patterns makes it tricky to depart
from the existing framework, and perhaps the ArithOps/NewDomain accessories
also mandate elements of this framework (I haven't looked at this closely).

One of the questions I'll be asking myself of the next couple of days (as I
flesh out the formal documentation) is whether placing the Storage_t member
variable at the bottom of the structure (DomainBase) is a vital aspect of
the unwrap() magic, or is entirely independent as an optimization to avoid
empty-base-class size penalities, and to what extent it complicates the code
to preserve this as such.

Allan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interval.gif
Type: image/gif
Size: 11488 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010629/ed4daa29/attachment.gif>

From cummings at linkline.com  Fri Jun 29 17:53:15 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Fri, 29 Jun 2001 10:53:15 -0700
Subject: [pooma-dev] domain architecture diagram
In-Reply-To: <NABBJEAOKIDHLPHKHPDLEEMPEBAA.allan@stokes.ca>
Message-ID: <NEBBLCJDELMDOJLGLNJGGEDECCAA.cummings@linkline.com>

Hi Allan,

I really enjoyed reading through your analysis of
the relationships between the Domain classes.  You
did a great job of unentangling it all.  By the way,
is that UML tool available free-of-charge?  I will
check out the URL you gave for it.  Just a few brief
comments and replies...

>
> The key to understanding the structure is the declaration for the class
> state.
>
> template <> struct DomainTraits< Interval<1> >::Storage_t;
>
> This type encapsulates the runtime state of any Interval<1> object.  The
> N-dimensional case looks like this (paraphrased):
>
> template <int Dim> struct DomainTraits< Interval<Dim> > {
>   typedef UninitializedVector<Interval<1>,Dim,Element_t> Storage_t;
> };
>
> OK, that's interesting.  Interval<N> defines its state in terms of its own
> specialization Interval<1>.

This is why I added a bunch of forward declarations
of the 1D specializations of the Domain classes all
over the place.  Bad things happen if the compiler
is not told in advance that specializations will be
forthcoming.  But the storage scheme does make sense.

>
> The only object with state is DomainBase which contains a member of this
> type Storage_t.  All Interval<> objects inherit their state from this base
> class via this idiom:
>
> struct foo : public base<foo>;
>
> It's important to note that polymorphism does not exist in this construct.
> A unique downcast is always implied.  If the derived class contains no
> state, the downcast becomes a change of interface and nothing more.
>
> template <class DT>
> class DomainBase {
>   // unwrap this object back to its derived-class type
>   inline
>   Domain_t &unwrap() { return *static_cast<Domain_t *>(this); }
>
>   // a const version of unwrap
>   const Domain_t &unwrap() const {
>     return *static_cast<Domain_t *>(const_cast<DomainBase<DT> *>(this));
>   }
> };
>
> I'm curious why the second version is not written:
>
>   static_cast<const Domain_t *>(this);
>
> Is the two-step conversion required by the language, or was this shaped by
> one of the compilers being used at the time?  I don't know the exact rules
> of casting.  Is static_cast defined to leave constness unchanged?

I think this is simply a mistake.  Your version (with
a * in front of it to dereference the result) is
correct.  There is no reason to cast away const here.

> One of the questions I'll be asking myself of the next couple of
> days (as I
> flesh out the formal documentation) is whether placing the
> Storage_t member
> variable at the bottom of the structure (DomainBase) is a vital aspect of
> the unwrap() magic, or is entirely independent as an optimization to avoid
> empty-base-class size penalities, and to what extent it
> complicates the code
> to preserve this as such.

I'm pretty sure this was originally designed to avoid the
empty-base-class size penalties.  The unwrap magic is used
in many other instances, such as the Barton-Nachman trick,
in which the base class is indeed empty.  I don't know if
this issue of the empty base class is important anymore
with current C++ compilers.  If not, then the DomainBase
layer could probably go away, and the actual data storage
could be relocated to the derived classes.

-- Julian C.


Dr. Julian C. Cummings
Staff Scientist, CACR/Caltech
(626) 395-2543
cummings at cacr.caltech.edu




From oldham at codesourcery.com  Fri Jun 29 21:24:33 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Fri, 29 Jun 2001 14:24:33 -0700
Subject: Location of the Latest Cheetah
Message-ID: <200106292124.OAA07429@oz.codesourcery.com>


	As you probably know, the latest Cheetah code is (always)
located at http://www.acl.lanl.gov/cheetah/ and
http://www.acl.lanl.gov/cheetah/download/index.html.

	Is anyone interested in trying it out with Pooma?

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From oldham at codesourcery.com  Sat Jun 30 00:21:03 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Fri, 29 Jun 2001 17:21:03 -0700
Subject: RFA: Improving StencilEngine Comments
Message-ID: <20010629172103.A18560@codesourcery.com>

OK to commit this patch?  Does it meet Pooma comment guidelines?

When working on implementing restriction operators for arrays, I read
through src/Engine/Stencil.h.  The most confusing aspect was that
"domain" is used for both stencil input and stencil output.  Also, the
invariants and data members for the StencilEngine were not documented.
I wrote comments that, I hope, clarify these aspects.

2001-06-29  Jeffrey D. Oldham  <oldham at codesourcery.com>

	* Stencil.h: Fix typographical errors.
	Add stencil concept comments.
	(insetDomain): Modify initial comments.
	(Engine<D,T,StencilEngine>): Fix typographical error.
	(Engine::Engine): Modify initial comments.
	(Engine::read): Likewise.
	(Engine::domain): Likewise.
	(Engine::first): Likewise.
	(Engine::viewDomain): Likewise.  Add other comments.
	(Engine::intersectDomain): Add initial comment.
	(View1): Modify initial comments.
	(View2): Likewise.
	(Stencil): Fix typographical error in initial comments.
	(DataObjectRequest): Likewise.

Tested on	sequential Linux using gcc 3.0 by compiling Pooma library
Approved by	???you???

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: Stencil.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Engine/Stencil.h,v
retrieving revision 1.42
diff -c -p -r1.42 Stencil.h
*** Stencil.h	2000/09/20 16:22:07	1.42
--- Stencil.h	2001/06/29 23:03:06
***************
*** 32,38 ****
  //   StencilEngine         - An tag for an engine for representing a stencil
  //   ArrayStencil          - contains utility functions for building stencils
  //                           on arrays
! //   View1                  - Specialization for Stencil
  //   Engine                - Specialization for StencilEngine
  //   NewEngine             - Specialization for StencilEngine
  //   EvaluatorEngineTraits - Specialization for StencilEngine
--- 32,38 ----
  //   StencilEngine         - An tag for an engine for representing a stencil
  //   ArrayStencil          - contains utility functions for building stencils
  //                           on arrays
! //   View1                 - Specialization for Stencil
  //   Engine                - Specialization for StencilEngine
  //   NewEngine             - Specialization for StencilEngine
  //   EvaluatorEngineTraits - Specialization for StencilEngine
***************
*** 93,98 ****
--- 93,153 ----
  //-----------------------------------------------------------------------------
  
  //-----------------------------------------------------------------------------
+ //
+ // Stencil Concepts:
+ // 
+ // A stencil is a pattern repeatedly applied to elements in an input domain to
+ // yield elements in the output domain.  For example, the simplest
+ // stencil copies each element in the input domain to exactly the same
+ // element in the output domain.  A second-order difference stencil can
+ // be represented by the formula
+ // 
+ // 		 out(i) = 2 in(i-1) + in(i) + in(i+1)
+ // 
+ // where in(i) and out(i) indicate the ith input and output elements,
+ // respectively.  This stencil illustrates that a stencil can use more
+ // than one input element, but that all input elements must be
+ // contiguous.
+ // 
+ // A StencilEngine is an engine applying a stencil to an input array.
+ // When invoked, the result is an array filled with values from applying
+ // the stencil to the input array.  We explain the engine's data members
+ // and assumptions.  Even though a StencilEngine stores the data for its
+ // computation, actually performing the computation only when requested,
+ // we use the slang of its "output" to avoid writing "its output when the
+ // computation is invoked."  Also, in the explanation below, we use
+ // one-dimensional terminology.  The only supported domains and ranges
+ // are Cartesian products so the one-dimensional terminology is easily
+ // generalized.
+ // 
+ // When created, engines frequently are given the desired array output
+ // range indices, e.g., -3, ..., 5.  Any such range can be shifted so the
+ // leftmost element's index is zero, i.e., zero-based.  For example, 0,
+ // ..., 8 with an offset of -3.  To return to the "original," desired
+ // range, add the offset to each index.  The `domain_m' variable records
+ // the number of output elements.
+ // 
+ // Assume the engine's stencil uses input array elements with indices
+ // lowerExtent, lowerExtent+1, ..., 0, ..., upperExtent.  Thus, to
+ // produce out(0) requires knowing in(lowerExtent), ..., in(upperExtent).
+ // The input domain to consisting of the values used to compute the
+ // zero-based output range is in(lowerExtent), ..., in(domain_m +
+ // upperExtent).
+ // 
+ // The StencilEngine's data members are
+ // 1) function_m representing the stencil
+ // 2) expression_m which is approximately the input
+ // 3) domain_m representing the indices for the output
+ // 4) offset_m representing the 'shift' to yield zero-based output indices
+ // Note all members concern output, not input.
+ // 
+ // When reading the source code below, "domain" is used for both input
+ // and output indices.  The reader must decide the meaning of each
+ // occurrence.
+ // 
+ //-----------------------------------------------------------------------------
+ 
+ //-----------------------------------------------------------------------------
  // Includes:
  //-----------------------------------------------------------------------------
  
*************** struct StencilEngine 
*** 158,163 ****
--- 213,221 ----
  // b(range) = st(a,range);
  //
  // because that version doesn't inset.
+ //
+ // In other words, given a stencil and an input domain, return the
+ // resulting output indices.
  //---------------------------------------------------------------------------
  
  template<class Function, int D>
*************** Interval<D> insetDomain(const Function &
*** 186,192 ****
  // 
  // Typedefs for the tag, element types, domain and dimensions.
  // Operator() with integers to evaluate elements quickly.
! // Operator() with a doman to subset.
  // Accessor for the domain.
  //
  //-----------------------------------------------------------------------------
--- 244,250 ----
  // 
  // Typedefs for the tag, element types, domain and dimensions.
  // Operator() with integers to evaluate elements quickly.
! // Operator() with a domain to subset.
  // Accessor for the domain.
  //
  //-----------------------------------------------------------------------------
*************** public:
*** 215,226 ****
    enum { zeroBased = true };
  
    //============================================================
!   // Construct from a Function object and an expression.
    //============================================================
  
    Engine(const Function &f, const Expression &e)
      : function_m(f), expression_m(e), domain_m(Pooma::NoInit())
    {
      Interval<D> inset = insetDomain(f, e.domain());
      int d;
      for (d = 0; d < D; ++d)
--- 273,287 ----
    enum { zeroBased = true };
  
    //============================================================
!   // Construct from a Function object (effectively a stencil)
!   // and an expression (effectively the input array), and
!   // sometimes an output (not input) domain.
    //============================================================
  
    Engine(const Function &f, const Expression &e)
      : function_m(f), expression_m(e), domain_m(Pooma::NoInit())
    {
+     // inset is the indices for the stencil's output.
      Interval<D> inset = insetDomain(f, e.domain());
      int d;
      for (d = 0; d < D; ++d)
*************** public:
*** 241,246 ****
--- 302,309 ----
      }
    }
  
+   // Construct an engine for composing stencils, e.g.,
+   // stencil1(stencil2(array)).
    template<class OtherE>
    Engine(const Engine<D, T, StencilEngine<Function, OtherE> > &e,
  	 const INode<D> &node)
*************** public:
*** 271,281 ****
    }
  
    //============================================================
!   // Element access via ints for speed.
    //============================================================
  
    inline Element_t read(int i) const 
    {
      return function()(expression_m,
  		      i + offset_m[0]);
    }
--- 334,346 ----
    }
  
    //============================================================
!   // Element access via ints for speed.  The arguments correspond to
!   // output elements, not input elements.
    //============================================================
  
    inline Element_t read(int i) const 
    {
+     // Input index `i + offset_m[0]' corresponds to output index `i'.
      return function()(expression_m,
  		      i + offset_m[0]);
    }
*************** public:
*** 333,345 ****
    }
  
    //============================================================
!   // Return the domain.
    //============================================================
  
    inline Domain_t domain() const { return domain_m; }
  
    //============================================================
!   // Return the first index value for the specified direction
    // (always zero since this engine is zero-based).
    //============================================================
    
--- 398,410 ----
    }
  
    //============================================================
!   // Return the output domain.
    //============================================================
  
    inline Domain_t domain() const { return domain_m; }
  
    //============================================================
!   // Return the first output index value for the specified direction
    // (always zero since this engine is zero-based).
    //============================================================
    
*************** public:
*** 351,357 ****
  
    //---------------------------------------------------------------------------
    // viewDomain() gives the region of the expression needed to compute a given
!   // region of the stencil.
    //---------------------------------------------------------------------------
  
    inline
--- 416,423 ----
  
    //---------------------------------------------------------------------------
    // viewDomain() gives the region of the expression needed to compute a given
!   // region of the stencil.  That is, viewDomain(outputDomain) yields
!   // the corresponding input domain.
    //---------------------------------------------------------------------------
  
    inline
*************** public:
*** 361,366 ****
--- 427,434 ----
      int d;
      for (d = 0; d < D; ++d)
      {
+       // The computation subtracts and adds the stencil's extent from
+       // the "original", unshifted output domain.
        ret[d] =
  	Interval<1>(
  		    domain[d].first() + offset_m[d]
*************** public:
*** 377,382 ****
--- 445,454 ----
      return INode<D>(inode, viewDomain(inode.domain()));
    }
  
+   //---------------------------------------------------------------------------
+   // intersectDomain() gives the "original", unshifted output domain.
+   //---------------------------------------------------------------------------
+ 
    inline
    Interval<D> intersectDomain() const
    {
*************** private:
*** 411,417 ****
  
  //-----------------------------------------------------------------------------
  // View types for stencil objects.  Stencils define operator() to return a
! // stencil engine object.  If you wanted to store that object, you could write:
  //
  // A a;
  // Laplace laplace;
--- 483,492 ----
  
  //-----------------------------------------------------------------------------
  // View types for stencil objects.  Stencils define operator() to return a
! // stencil engine object, which, when invoked, yields the result of
! // applying the stencil to the given array.
! //
! // If you wanted to store that object, you could write:
  //
  // A a;
  // Laplace laplace;
*************** struct View1<Stencil<Function>, Array<D,
*** 438,444 ****
  
  //-----------------------------------------------------------------------------
  // View2 is used to construct the return type for stencils where the
! // domain is given as well.
  //-----------------------------------------------------------------------------
  
  template<class Function, class ArrayIn, int Dim>
--- 513,519 ----
  
  //-----------------------------------------------------------------------------
  // View2 is used to construct the return type for stencils where the
! // output domain is given as well.
  //-----------------------------------------------------------------------------
  
  template<class Function, class ArrayIn, int Dim>
*************** struct View2<Stencil<Function>, ArrayIn,
*** 517,523 ****
  // 
  // The return type is whatever the stencil outputs.  If this is not
  // the same type as the elements of 'expr', you must specialize
! // the pooma FunctorResult class (see Pooma/FunctorResult.h).
  //
  // To apply a stencil, create an instance of the Stencil<> class.
  //
--- 592,598 ----
  // 
  // The return type is whatever the stencil outputs.  If this is not
  // the same type as the elements of 'expr', you must specialize
! // the Pooma FunctorResult class (see Pooma/FunctorResult.h).
  //
  // To apply a stencil, create an instance of the Stencil<> class.
  //
*************** struct LeafFunctor<Engine<D,T,StencilEng
*** 795,801 ****
  };
  
  //---------------------------------------------------------------------------
! // Specialization of  DataObjectRequest engineFunctor to pass the request to
  // the contained engine.
  //---------------------------------------------------------------------------
  
--- 870,876 ----
  };
  
  //---------------------------------------------------------------------------
! // Specialization of DataObjectRequest engineFunctor to pass the request to
  // the contained engine.
  //---------------------------------------------------------------------------
  

From scotth at proximation.com  Sat Jun 30 16:38:12 2001
From: scotth at proximation.com (Scott Haney)
Date: Sat, 30 Jun 2001 10:38:12 -0600
Subject: [pooma-dev] RFA: Improving StencilEngine Comments
In-Reply-To: <20010629172103.A18560@codesourcery.com>
Message-ID: <mailman.44.1331172046.20475.pooma-dev@codesourcery.com>

Jeffrey,

This is fine.

Scott

On Friday, June 29, 2001, at 06:21 PM, Jeffrey Oldham wrote:

> OK to commit this patch?  Does it meet Pooma comment guidelines?
>
> When working on implementing restriction operators for arrays, I read
> through src/Engine/Stencil.h.  The most confusing aspect was that
> "domain" is used for both stencil input and stencil output.  Also, the
> invariants and data members for the StencilEngine were not documented.
> I wrote comments that, I hope, clarify these aspects.
>
> 2001-06-29  Jeffrey D. Oldham  <oldham at codesourcery.com>
>
> 	* Stencil.h: Fix typographical errors.
> 	Add stencil concept comments.
> 	(insetDomain): Modify initial comments.
> 	(Engine<D,T,StencilEngine>): Fix typographical error.
> 	(Engine::Engine): Modify initial comments.
> 	(Engine::read): Likewise.
> 	(Engine::domain): Likewise.
> 	(Engine::first): Likewise.
> 	(Engine::viewDomain): Likewise.  Add other comments.
> 	(Engine::intersectDomain): Add initial comment.
> 	(View1): Modify initial comments.
> 	(View2): Likewise.
> 	(Stencil): Fix typographical error in initial comments.
> 	(DataObjectRequest): Likewise.
>
> Tested on	sequential Linux using gcc 3.0 by compiling Pooma library
> Approved by	???you???
>
> Thanks,
> Jeffrey D. Oldham
> oldham at codesourcery.com
>
<Attachment missing>>
-------------- next part --------------
Jeffrey,

This is fine.

Scott

On Friday, June 29, 2001, at 06:21 PM, Jeffrey Oldham wrote:

> OK to commit this patch?  Does it meet Pooma comment guidelines?
>
> When working on implementing restriction operators for arrays, I read
> through src/Engine/Stencil.h.  The most confusing aspect was that
> "domain" is used for both stencil input and stencil output.  Also, the
> invariants and data members for the StencilEngine were not documented.
> I wrote comments that, I hope, clarify these aspects.
>
> 2001-06-29  Jeffrey D. Oldham  <oldham at codesourcery.com>
>
> 	* Stencil.h: Fix typographical errors.
> 	Add stencil concept comments.
> 	(insetDomain): Modify initial comments.
> 	(Engine<D,T,StencilEngine>): Fix typographical error.
> 	(Engine::Engine): Modify initial comments.
> 	(Engine::read): Likewise.
> 	(Engine::domain): Likewise.
> 	(Engine::first): Likewise.
> 	(Engine::viewDomain): Likewise.  Add other comments.
> 	(Engine::intersectDomain): Add initial comment.
> 	(View1): Modify initial comments.
> 	(View2): Likewise.
> 	(Stencil): Fix typographical error in initial comments.
> 	(DataObjectRequest): Likewise.
>
> Tested on	sequential Linux using gcc 3.0 by compiling Pooma library
> Approved by	???you???
>
> Thanks,
> Jeffrey D. Oldham
> oldham at codesourcery.com
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Stencil.h.patch
Type: application/applefile
Size: 75 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010630/051c0cbb/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Stencil.h.patch
Type: application/text
Size: 12854 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010630/051c0cbb/attachment-0001.bin>
-------------- next part --------------
>

From mark at codesourcery.com  Sat Jun 30 16:24:41 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Sat, 30 Jun 2001 09:24:41 -0700
Subject: Adding Link to mm from Pooma's Download Page
In-Reply-To: <F871BB04B0EA224A821A5274C31DF315021710@proxim-sf001.santafe.proximation.com>
Message-ID: <12020000.993918281@warlock.codesourcery.com>



--On Wednesday, June 27, 2001 06:33:17 PM -0700 Stephen Smith 
<stephens at proximation.com> wrote:

>
> Hi Mark.
>
> The mm library is necessary to build Cheetah to use the shared-memory
> option, which implements a message-passing transport layer using shared
> memory.

Thanks; I've added this package to the web-site.

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com