\start
Date: Tue, 01 Dec 2009 09:45:47 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: [Aldor-l] License for FriCAS-Aldor interface files
Cc: Mike Dewar, Stephen Watt

Ralf Hemmecke wrote:
> Dear Mike, dear Stephen,
>
> may I ask you again to consider the attached request.
>
> Thank you
> Ralf
>
>
> On 09/24/2009 11:38 PM, Ralf HEMMECKE wrote:
>> Dear Stephen, dear Mike
>
>> as you might know, I have built some scripts in FriCAS (a fork of 
>> Axiom) (http://fricas.sourceforge.net/) in order to build libaxiom.al 
>> from scratch. Unfortunately, I can neither distribute libaxiom.al nor 
>> some necessary .as files under the same license as FriCAS (mBSD), 
>> since this code is only available under the Aldor Public License 2.0.
>>
>> I hereby kindly ask you to release the following files under a BSD 
>> license (same as for the Axiom code).
>>
>>   https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/axiom.as
>>   
>> https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/axextend.as
>>   https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/axlit.as
>>   https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/stub.as
>>   
>> https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/minimach.as
>>   
>> https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/axllib/src/lang.as
>>
>> Furthermore, in order to distribute a precompiled libaxiom.al 
>> together with FriCAS, it would be helpful to also release
>>
>> $(ALDORROOT)/lib/libfoam.al(runtime.ao)
>>
>> under a BSD license. For 'runtime.ao', also releasing the sources 
>> under a BSD license would be good, but I explicitly ask for the 
>> release of the .ao format.
>>
>> Please help the FriCAS project and don't let Aldor die.
>>
>> Has meanwhile anything been done to release all of the Aldor 
>> compiler+library sources under a GPL-compatible license?
>>
>> Thank you for your time.
>>
>> Yours sincerely
>> Ralf Hemmecke
>
>
> _______________________________________________
> Aldor-l mailing list
> Aldor-l@aldor.org
> http://aldor.org/mailman/listinfo/aldor-l_aldor.org
>
Mike, Stephen,

I have recently decided after two years that Aldor was
never going to become free enough to be integrated back
into Axiom. The FriCAS project has been trying to keep
the connection alive.

It would seem that changing the license on the FriCAS
related files would at least help them in their efforts
to keep the connection alive. Thus, I'm adding my voice
to the request to make this change.

I realize that such changes involve your legal department
and come at a non-trivial cost. I also realize that you
may have prior agreements that prevent it. In any case,
I think that the sense of frustration in FriCAS appears
to be reaching a critical tipping point and this is likely
to end with Aldor being deleted.

\start
Date: Fri, 04 Dec 2009 04:20:54 -0500
From: Tim Daly
To: list
Subject: Re: Literate programming and how it scales


(actual text is snipped out since this was not public but I want to record
the reply on axiom-developer)

...[snip]...comments about scale...

What kind of scaling are you thinking about? Axiom currently has about
20 books that will eventually have all of the source code in literate
form. Some of the books are several thousand pages long. There is
hyperlinking within the files.  Axiom is about 1 million "things of
code" and it will all reside in literate files so I think the
technology scales to really large systems.

If you are talking about scaling in terms of humans I think the
problem is not one of technology. The problem is that you really can't
do a literate work with dozens of authors. Literature requires one, or
at most a few, authors in order to make sure that the "style" and
"voice" of the documentation is coherent. So I think that many people
can work on the system but only a very few are the "editors/primary
authors". I don't think there is a good label for this historically,
except perhaps the "Chief Programmer" from Harlan Mills "Chief
Programmer Teams". I don't care for that label.

Ultimately literate programming requires a complete understanding of
the system.  The point of literate programming is to convey this
understanding to the reader in a smooth, consistent way. Since
programming is involved it is also important that all of the details
are explained, but also important that they are introduced in some
"motivated" fashion. It is the "motivation" for code snippets that is
usually left out of other documentation forms (e.g. doxygen, javadoc,
etc.).

...[snip]...comments about TeX and multiple languages

I see TeX as a major strength since most technical papers are written
in Latex.  TeX is also a strength for Axiom because it handles
mathematical typesetting very well and Axiom is a mathematical system.

Every literate system will have at least 2 languages, one for
programming and one for writing. I find that TeX does everything I
need or can be extended with macros to do what I need. I don't know
how to add macros to an HTML system (without writing in Perl as you
do, which is yet a third language)

... [snip] ...comments about noweb

Axiom is moving away from noweb, although we have used it for years
and I can highly recommend it. Some of Axiom's literate files now have
"straight latex" macros for chunks so where you would write

<<noweb chunk name>>=
   your code
@

now Axiom allows you to write

\begin{chunk}{Axiom chunk name}
  your code
\end{chunk}

This uses straight latex macros which means that your file is pure Latex.
Since the file is pure Latex you no longer need "weave" so half of noweb 
is gone.

The only other remaining function is "tangle". Axiom is being rewritten
to understand Latex files directly so it can "tangle" the file without 
using noweb.
The underlying lisp system (GCL) has been modified to include a "tangle"
function directly so Axiom is not needed to extract code.

Thus we will no longer need noweb in the future.

...[snip]...comments about new tool features for code organization

Programmers have been conditioned to believe that they should work on small
files with "include files" to carry information that is shared.

If you look where this idea comes from historically you'll find there
was a memory limitation on the PDP 11/40 (I worked on one so I know)
that limited a file to about 4K characters. In order to make larger
files you needed to invent "include files".  So C programs started the
idea that files should be really small.

Then you needed to invent directories since groups of files in a
directory made up a single larger idea.

Then you needed to invent "make" because it becomes impossible to
figure out how to compile all the files in all the directories and get
all the parts right.

Then you needed to invent "grep" to find functions.

Then you needed to invent IDEs so you could work with the whole project.

Today I have 4G of memory and a 1T of disk space. I can trivially
handle multi-megabyte files, my functions are all in one file, "make"
is trivial, "grep" is an editor "find" command and I don't need an
IDE. Latex provides an automatic cross-reference mechanism that allows
me to find all of the places where a function is called.

Once we stop pretending we work on a PDP 11/40 life gets so much easier

...[snip]... tool description using HTML, Perl, Javascript

So instead of Latex and Lisp, I now need Lisp, HTML, Perl,
and Javascript?

Is adding new languages an improvement? Are HTML files "documents", i.e.,
are they designed to be read as books? Can you control the layout and fonts
that are so necessary to convey certain information?

...[snip]... features of the new tool

Like any author, I keep my ongoing work in the manuscript, which is
the literate file itself.  There are no auxillary files, no project
files, no directory structure, no includes, nothing.

...[snip]...

I'm sure you have a good tool set that most people would find useful.
Unfortunately, the Axiom project is working to "remove the tools" that
are not absolutely required by making Axiom aware of its own file format
(pamphlet, also known as .tex, files)

\start
Date: Fri, 04 Dec 2009 13:06:57 -0500
From: Tim Daly
To: list
Subject: ISSAC 2011

*---------------------------------------------------------------*

             Call for Proposals for Workshops

                      ISSAC 2011

                    June 8-11, 2011

*---------------------------------------------------------------*


We solicit proposals for satellite workshops to be held in conjunction
with ISSAC 2011.

For the first time, ISSAC will participate in the Federated Computing
Research Conference (FCRC). FCRC occurs once every four years, and is
the world's largest computing research conference.  FCRC consists of a
collection of conferences that agree to share the same conference
facility. To learn more, see http://acm.org/fcrc/  .

The FCRC week in 2011 will run June 4-11  The ACM is able to offer
space for workshops or small conferences at no additional charge.
Participants are responsible for paying a modest FCRC registration fee
(approx. 50 USD for the entire FCRC week) and a ``per diem'' fee to
cover refreshments (approx. 80 USD per day).  These fees are the same
regardless of how many events one attends, i.e., there is no penalty
to register for one conference and attend a different workshop.  ISSAC
will take place at the end of the FCRC week, and space for workshops
is available for us starting the day before, June 7.

Opportunities abound for making connections with other fields of
computer science. Conferences that have confirmed their participation
include the

* ACM Symposium on Theory of Computing (STOC),

* ACM Symposium on Parallelism in Algorithms and Architectures (SPAA),

* ACM Conference on Programming Language Design and Implementation
(PLDI),

* CRA-W Career Mentoring Workshop.


Potential ideas for workshops that take advantage of the presence of
these related conferences might then be Complexity in Computer
Algebra, Parallel Symbolic Computation, Programming Languages for
Computer Algebra, or Mentoring Women in Computer Algebra.

We also welcome proposals for other topics.  Holding your workshop at
an event with international presence might heighten participation.



Please email your proposal to General Chair Eric Schost at
eschost@uwo.ca.  There is no hard deadline, but because space is
limited, we encourage you to submit by December 14, 2009. We will make
decisions on a ``first come, first served'' basis and may close
submissions before December 1st.

For questions concerning the Federated Computing Research Conference,
any organizational details, current list of participating conferences,
or current availability of space, please contact Local Arrangements
Chair Emil Volcheck at Emil Volcheck.

\start
Date: Fri, 04 Dec 2009 21:54:56 -0500
From: Tim Daly
To: Rich Hickey
Subject: Intell SCC chip, Clojure, and Provisos

Rich,

I've been looking at the newly-announced Intel SCC chip.
It looks like 48 processors with local cache connected
by 24 routers.

It seems feasible to me to put a Clojure on each node
and have them share a heap image. The cache is likely
large enough to contain the kernel of the clojure code
(they plan to run 48 linux images).

One question that I'd have is whether there is a way to
present a single-image REPL that can use this chip. I'd
like to experiment with parallel symbolic computing in
Axiom and the combination of Clojure and the SCC seems ideal.

Can multiple Clojures share a heap?

I'd like to be able to dynamically fork tasks to different
lisp images that worked on the same heap. For example, I'd
like to be able to compute f(x) in two ways with different
assumptions as in:
   f(x) x>0
   f(x) x<=0
and the combine the result into a single solution. Computing
under assumptions (provisos) is an ideal mechanism for doing
parallel symbolic computations.

\start
Date: Fri, 4 Dec 2009 19:10:59 -0800
From: Ed Borasky
To: Tim Daly
Subject: Re: Intell SCC chip, Clojure, and Provisos
Cc: Rich Hickey

On Fri, Dec 4, 2009 at 6:54 PM, Tim Daly wrote:
> Rich,
>
> I've been looking at the newly-announced Intel SCC chip.
> It looks like 48 processors with local cache connected
> by 24 routers.
>
> It seems feasible to me to put a Clojure on each node
> and have them share a heap image. The cache is likely
> large enough to contain the kernel of the clojure code
> (they plan to run 48 linux images).
>
> One question that I'd have is whether there is a way to
> present a single-image REPL that can use this chip. I'd
> like to experiment with parallel symbolic computing in
> Axiom and the combination of Clojure and the SCC seems ideal.
>
> Can multiple Clojures share a heap?
>
> I'd like to be able to dynamically fork tasks to different
> lisp images that worked on the same heap. For example, I'd
> like to be able to compute f(x) in two ways with different
> assumptions as in:
> =C2=A0f(x) x>0
> =C2=A0f(x) x<=0
> and the combine the result into a single solution. Computing
> under assumptions (provisos) is an ideal mechanism for doing
> parallel symbolic computations.

Hmmm ... interesting concept. How small an OS can you get away with
and still have the JVM on each node? Surely you don't need a whole
GNU/Linux stack. Perhaps something like the openSUSE JeOS (Just Enough
Operation System)? Which JVM would you be using? Are the parallel /
concurrent hooks in the JVM?

\start
Date: Fri, 04 Dec 2009 22:42:28 -0500
From: Tim Daly
To: Edward Borasky
Subject: Re: Intell SCC chip, Clojure, and Provisos
Cc: Rich Hickey

Ed Borasky wrote:
> On Fri, Dec 4, 2009 at 6:54 PM, Tim Daly wrote:
>   
>> Rich,
>>
>> I've been looking at the newly-announced Intel SCC chip.
>> It looks like 48 processors with local cache connected
>> by 24 routers.
>>
>> It seems feasible to me to put a Clojure on each node
>> and have them share a heap image. The cache is likely
>> large enough to contain the kernel of the clojure code
>> (they plan to run 48 linux images).
>>
>> One question that I'd have is whether there is a way to
>> present a single-image REPL that can use this chip. I'd
>> like to experiment with parallel symbolic computing in
>> Axiom and the combination of Clojure and the SCC seems ideal.
>>
>> Can multiple Clojures share a heap?
>>
>> I'd like to be able to dynamically fork tasks to different
>> lisp images that worked on the same heap. For example, I'd
>> like to be able to compute f(x) in two ways with different
>> assumptions as in:
>>  f(x) x>0
>>  f(x) x<=0
>> and the combine the result into a single solution. Computing
>> under assumptions (provisos) is an ideal mechanism for doing
>> parallel symbolic computations.
>>
>> Tim Daly
>>
>>
>>
>> _______________________________________________
>> Axiom-developer mailing list
>> list
>> http://lists.nongnu.org/mailman/listinfo/axiom-developer
>>
>>     
>
> Hmmm ... interesting concept. How small an OS can you get away with
> and still have the JVM on each node? Surely you don't need a whole
> GNU/Linux stack. Perhaps something like the openSUSE JeOS (Just Enough
> Operation System)? Which JVM would you be using? Are the parallel /
> concurrent hooks in the JVM?
>
>
>   
Intel has been muttering about putting a whole virtual machine on
each of the 48 nodes. I'm thinking more along the lines of a lisp
kernel per node with shared heap. Clojure is interesting because of
its immutable data structures and refs. Asus systems sells a 384
node machine that runs a JVM per node and I had previously looked
at that for a Clojure-based Axiom.

I have been looking for details on the individual nodes and their
cache sizes. I suspect they are planning on a wide range of cache
sizes. Given a 2M cache it would easily hold a lisp kernel although
I'm not sure of minimum JVM sizes. However, byte coding is a way of
minimizing memory footprint.

SCC appears to be optimized for a message passing architecture which
is a style that can easily be adopted in lisp since you can pass
s-expressions directly.

Intel has asked for research ideas and I submitted this idea. Since
this is open source the best we can hope for would be internet access
to a hardware platform (which might be implemented in ASIC chips for
all we know).

I have been collection parallel constructs and building a set of lisp
tools for each one. For example, take, drop, interleave, curry, zip,
filter, etc. would be primitives for control. Rich Hickey made the
interesting observation that essentially amounts to something like
"Loops considered harmful". As I rewrite the Axiom internals I'm
working on lifting it onto the parallel primitives.

The real game is to lift the whole parallel idea into the symbolic
context so algorithms can be fully parallel. My view on that is to use
provisos as the basis for fork/join computations under restricted
assumptions for each fork. Of course, a forked computation of
  f(x,y) such that x > 0
could end up forking again under
  f(x,y) such that x > 0 & y > 0
  f(x,y) such that x > 0 & y = 0
  f(x,y) such that x > 0 & y < 0

Groebner basis computations could be done in parallel with different
orders and terminated when a solution is found (parallel poisoning)

Parallel root finders could use a blackboard structure to use the
discovery of one root to reduce the problem for other parallel finders.
 
There are a lot of interesting paths to take.

\start
Date: Fri, 4 Dec 2009 20:05:19 -0800
From: Edward Borasky
To: Tim Daly
Subject: Re: Intell SCC chip, Clojure, and Provisos
Cc: Rich Hickey

On Fri, Dec 4, 2009 at 7:42 PM, Tim Daly wrote:
> Intel has been muttering about putting a whole virtual machine on
> each of the 48 nodes. I'm thinking more along the lines of a lisp
> kernel per node with shared heap. Clojure is interesting because of
> its immutable data structures and refs. Asus systems sells a 384
> node machine that runs a JVM per node and I had previously looked
> at that for a Clojure-based Axiom.

The nodes are full x86_64, right? I think you need *some* kind of OS /
kernel, although it might well be a "microkernel" along the lines of
the Dresden Real-Time Operating System (DROPS) rather than a full
Linux or BSD kernel. I don't know if there's a "bare metal JVM" or a
hardware implementation of the JVM. Then again, I'm mostly a number
cruncher and operating system programmer, so maybe I see a need for an
OS simply because I like working on them. ;-)

> Intel has asked for research ideas and I submitted this idea. Since
> this is open source the best we can hope for would be internet access
> to a hardware platform (which might be implemented in ASIC chips for
> all we know).

I don't know about that - Intel is pretty supportive of open source,
at least here in Oregon. ;-) And they used to have a pretty strong HPC
team here (Floating Point Systems alumni), although I haven't run into
any of them recently. If there is an upstream market for massively
parallel symbolic computing, I'm sure they'll give you what you need.

> I have been collection parallel constructs and building a set of lisp
> tools for each one. For example, take, drop, interleave, curry, zip,
> filter, etc. would be primitives for control. Rich Hickey made the
> interesting observation that essentially amounts to something like
> "Loops considered harmful". As I rewrite the Axiom internals I'm
> working on lifting it onto the parallel primitives.
>
> The real game is to lift the whole parallel idea into the symbolic
> context so algorithms can be fully parallel. My view on that is to use
> provisos as the basis for fork/join computations under restricted
> assumptions for each fork. Of course, a forked computation of
> =C2=A0f(x,y) such that x > 0
> could end up forking again under
> =C2=A0f(x,y) such that x > 0 & y > 0
> =C2=A0f(x,y) such that x > 0 & y = 0
> =C2=A0f(x,y) such that x > 0 & y < 0
>
> Groebner basis computations could be done in parallel with different
> orders and terminated when a solution is found (parallel poisoning)

I thought there were "massively parallel" Groebner basis solvers
already - is that a wheel that needs re-inventing?

> Parallel root finders could use a blackboard structure to use the
> discovery of one root to reduce the problem for other parallel finders.
>
> There are a lot of interesting paths to take.

Yeah - many of these paths were partially illuminated in the late
1980s - early 1990s and then abandoned. I think, though, this time
around, there's massive commitment to parallel / concurrent
programming from big players like IBM, Intel, Microsoft and Google.
Oracle too, probably. ;-)

\start
Date: Tue, 08 Dec 2009 16:51:57 -0500
From: Tim Daly
To: Franz Lehner
Subject: Re: hyperdoc on the web
Cc: Martin Rubey, Bill Page

Well, since my name came up in discussion I feel I have to respond
with a couple points.

1) My original "translation" from spad files to "literate" files involved
adding a latex header and a footer to every file. Fricas removed this from
almost every other file except the algebra files. Waldek's complaint is that
this makes algebra files hard to use. (Note that Axiom no longer has
any spad files or separate algebra pamphlet files. What you have was
a trivial first step in the process and worthless as it stands.)

I might suggest that since you don't plan to really do literate programming
it would be perfectly sane to remove the header and footer from the
algebra files. This has 2 benefits. First, you can use the spad files 
directly
Second, you no longer need noweb which simplifies your build process
considerably (removing steps and removing the need to fetch noweb)
In fact, you hardly use noweb because it appears you build from the lisp
translations most of the time.

You can't really do literate programming "half way". What you have
now is just a "dust jacket" over an empty novel. What is the point?
Why be irrational?

2) The debate seems to depend on whether Fricas will attract more
users if more functionality is added or if more documentation is added.
I think you will only judge this in the long term by whether Fricas or
Axiom ends up with more users. In fact, though, I don't consider
this an interesting metric; but we disagree on that also.

Given that I'm a complete Knuth fanboi about literate programming,
I have SO much more to say but since Fricas forked the Axiom project
over the literate issue, this is the wrong audience. There is nothing I
can say that would convince you otherwise.

Tim


=================================================

Martuin Rubey asked about stmult routine which I recently
commited to 'sttaylor.spad'.  I think the best explanation
is to give short reconstruction how the routine was
written.

1) Let us look first at general pattern of stream fortines.  Good
example is the simpified version of 'map':

    map(f,x)== delay
      empty? x => empty()
      concat(f frst x, map(f,rst x))

Note that the result is produced by the 'delay' function.  'delay(f)'
takes function 'f' as argument and produces from is a stream, such
that evaluation of the strem causes f to be called.  The name 'delay'
is releated to the fact that 'delay' effectively delayes evaluation
of its argument to the moment when first value from the stream
is requested.  When strean is evaluated: evaluation triggered
by call to 'empty?'.  In other words, before trying to access
first element of the stream we need to call 'empty?' to cause
evaluaton, after the call we know if the element is there (and
if it is present we can use it).  So above the first line calls
'empty?' which either give us true, in which case we simply return
empty stream or we may use the first element of input stream to
produce first element of the result result.  Now, once we have
first element of the result in hand we can produce the result by
concatenating first element of the result with the rest of the
result.  In case of 'map' the result is obtained by recursive
application of 'map' to the rest of input stream.

Important remark: stream are produced and should be consumed
in lazy way.  'delay' makes sure that no computation takes
place before first element of the result is requested.  However
for single request map should produce only one element and to
produce it should consume only one elemet form input stream.
Using 'concat' makes sure that caller will get the computed
element and that request for further elements will go to map
applied to the rest of stream.

Let me also say that the code above looks like unbounded
recursion, but in fact there is _no_ recursion at runtime:
what looks like recursive call to 'map' is done _after_
call to outer map has finished.

2) Having pattern for general operation, how we apply it in a
concrete situation.  For example, we would like to multiply
each element 'n' of the stream by 'n+1'.  To do this we need
to know what 'n' is, so we need to pass 'n' between invocations
of function.  So we need an auxilary function and a wrapper:

   stmuln_aux(n0, x) == delay
       empty? x => empty()
       n := n0 + 1
       firstval := n*frst x
       concat(firstval, stmuln_aux(n, rst x))

   stmuln(x) == stmuln_aux(0, x)

Note: due to stupidity of Spad compiler I can not simply increment
n0, but must introduce extra variable n.

3) Back to multiplication.  For multiplication formula is:

   (f*g)(n) = \sum_{i=0}^{n} f(i)*g(n-i)

This is more complicated then previous case because I need terms
f(0),...,f(n) and g(0),...,g(n) to produce the result.
Naive implementation (assuming infinte streams) may look like:

   stmult(n, x, y) == delay
       valn := sum(coefficient(x, i)*coefficient(y, n - i), i=0..n)
       concat(valn, stmult(n + 1, x, y))

   mult(x, y) == stmult(0, x, y)

However, coefficient for streams has step trough stream from
the start up to requested element, so it is slow if n gets large.
It is easy to see that we can step trough x as we sum saving
half ot the operations:

   stmult(n, x, y) == delay
       valn : A := 0
       xp := x
       for i in 0..n repeat
           empty? xp => break
           valn := frst xp * coefficient(y, n - i)
           xp := rst xp
       concat(valn, stmult(n + 1, x, y))

We still use coefficient on y.  Since we need to go trough y
backwards, it is a bit harder to get rid of.  Easy way it to
have a list which stores the first n elements of y in backward
order:

   stmult(n, x, y0, ll0) == delay
       yval : A
       y := y0
       if empty? y then
           yval := 0
       else
           yval := frst y
           y := rst y
       ll := cons(yval, ll0)
       xp := x
       llp := ll
       valn : A := 0
       for i in 0..n repeat
           empty? xp => break
           valn := valn + frst xp * first(llp)
           llp := rest(llp)
           xp := rst xp
       concat(valn, stmult(n + 1, x, y, ll))

This may be (I did not test it) correct routine to multiply infinite
power series, but it does not conform to expectation of rest of FriCAS.
Namely, if we are given to finite series it will produce infinite
series -- after finite number of nonzero terms we will get infinite
stream of zeros.  There is also unneeded eagerness: if first element
if y is zero we do not need element n of x to produce first element
of the result.  Also, if y is finite there is no need to append
zeros.  First, let us handle leading zeros of 'y'.  I first
element of y is zero we get zero as fist element of the result and
rest of resulst is x times rest of y:

     ...
     yval := frst y
     n = 0 and yval = 0 => concat(0, stmult(n, x, rst y, ll))

Note: we need to test if n is 0 to know that we really have first
elememt and not some zero in the middle.

Next, if we get to the end of y instead of extending ll by zero
we may drop first element of x.  We need to be a little
careful if x is also empty ( possibly after dropping several
elements).  And we need to properly adjust n.  Adjusting n is
easier if we start from n = -1 instead of n = 0.  Also, if at start
y is empty then the result is 0 (empty):

       if empty? y then
            n < 0 => return empty()
            empty? x => return empty()
            x := rst x

If we in the loop we discover that x is empty we can also
return 0.  FinallCollection the changes above we get:

   stmult(n0, x0, y0, ll0) == delay
       x := x0
       y := y0
       ll := ll0
       n = n0
       if empty? y then
           n < 0 => return empty()
           empty? x => return empty()
           x := rst x
       else
           yval := frst y
           n < 0 and yval = 0 => concat(0, stmult(n, x, rst y, ll))
           y := rst y
           ll := cons(yval, ll)
           n := n + 1
       xp := x
       llp := ll
       valn : A := 0
       for i in 0..n repeat
           empty? xp =>
               i = 0 => return empty()
               break
           valn := valn + frst xp * first(llp)
           llp := rest(llp)
           xp := rst xp
       concat(valn, stmult(n + 1, x, y, ll))

This is almost the routine I want to use.  However, there is one
extra problem: if series has unevaluated tail printing routines
print O(..) term even if after further evaluation it turns out
that in fact the tail is empty.  To avoid such artifacts printing
routines check if tail is explicitly empty.  Note that testing
if tail is empty causes evaluation and printing routines are not
allow to evaluate extra terms.  But 'explicitlyEmpty?' does not
cause evaluation, even if 'explicitlyEmpty?' return false
'empty?' may return 'true'.  So, to make printing routines
happy we need to make sure that the tail is explicitely empty.
This is done adding after loop test:

         ....
      explicitlyEmpty? rst x and
        explicitlyEmpty? y => concat(res, empty())

Note that we if x is empty we call return inside loop, so after
loop x is always nonempy and calling rst is safe.  Note that
if x has only one element and y is empty then in the next iteration
we will throw out the only element of x and get empty result.
So the test allows us to produce earlier the empty result.
OTOH if that test fails in principle we can get more elements,
so must use general form.

Martin also asked why the new version uses less space than the
old one and why the old one used so much space.

First, note that stream data is stored in nested anonymous
functions.  The new version creates single function for
each term of the series, so when we want n terms n such
functions are created.  Each function takes fixed amount
of space for variables (the space is actually taken by "frozen"
values of variables from outside which the function uses).
The variables may reference large data structure (for
example x and y may be big), but fortunatly such large
structures may be shared.  In particular parts of x and y are
shared so that at each step we add (compute) only one extra element
of x and of y.  The list ll has in general n + 1 element, but
we share n with previous iteration.  So at each step we
allocate fixed aount of memory.  More precisely, we allocate
whatever memory is needed to store element n of x and element
n of y plus fixed storage (of order 10-15 machine words).
In other words, memory usage is linear in n.

The old version was:

   (x:ST A) * (y:ST A) == delay
     empty? y => zro()
     empty? x => zro()
     concat(frst x * frst y,frst x * rst y + rst x * y)

It is easy to see that this version allocates stream node for
each term in the product, that is of order n^2 nodes.  Theoretically
most of those nodes may be garbage collected.  I did not check
if the FriCAS code for some reason (for example due to keeping
unnecessery extra reference to the data) did not allow collection,
or if this was problem with SBCL garbage collector, but the fact
was that the space usage grow quadratically...

The new version allocates much less memory, so there is no
chance for garbage collector (or FriCAS programmers) to scrow up.

-- 
                              Waldek Hebisch
hebi...@math.uni.wroc.pl

From: Ralf Hemmecke <r...@hemmecke.de>
Date: Sat, 05 Dec 2009 12:23:10 +0100
Local: Sat, Dec 5 2009 6:23 am
Subject: Re: [fricas-devel] Multiplication of power series

Waldek,

Since we have literate programming, I think your explanation would be
best put just next to your implementation. Can you commit that?

In the mailing list archive it will be just forgotten or relatively hard
to find if the code does not (at least) have a link to your message.
Anyway, better put it directly into the code.

Since I've also worked on powerseries in aldor-combinat... does your
code allow to define powerseries by recursion? I think that should be
somehow possible by using "delay".

Further, I still would very much like a native implementation of
"Generator" in SPAD. Do you have any plans for that?

Ralf

On 12/05/2009 04:17 AM, Waldek Hebisch wrote:


 > Martuin Rubey asked about stmult routine which I recently
 > commited to 'sttaylor.spad'.  I think the best explanation
 > is to give short reconstruction how the routine was
 > written.


       

From: Waldek Hebisch <hebi...@math.uni.wroc.pl>
Date: Sat, 5 Dec 2009 16:54:52 +0100 (CET)
Local: Sat, Dec 5 2009 10:54 am
Subject: Re: [fricas-devel] Multiplication of power series


Ralf Hemmecke wrote:
 > Waldek,

 > Since we have literate programming, I think your explanation would be
 > best put just next to your implementation. Can you commit that?

No!!!  I _really_ do not want to see such texts inside source
files.  Such for given person such text may be useful once,
maybe few times, but having to read it or even only look at
it every time when looking at code is simply too distracting.

In other words, persons looking at/modifying algebra code are
supposed to have appropriate background knowledge.  Consider
research article on some fancy rings.  If you put there
elementary introduction to rings every referee will tell
you to delete such material.  Background specific to topic
at hand is welcome, but is normally put in separate
section.  The main body of article simply uses notation/facts
from background section without repeating them.  This is
due to separation of concerns principle: systems with many
interactiong parts are hard to understand.  Splitting them
into pieces and using hierachical description makes things
easier.  Also, people are pretty good at analogy, so explaing
one thing allows them to understand similar thins.  Again,
separating material into background and specific parts
means that background is easier to reuse.

For background we should have documentation (separate
from source code!).  Unfortunatly, past "literate"
effort removed places where normally documentation
should live.  But is relatively easy to cure.

There are practical aspects releated to tools that we
use.  Let me explain my workflow when developing algebra
code:

1) copy XXX.spad file from build directory to work directory
2) start up FriCAS in work directory
3) in separate window start an editor on XXX.spad file (I use vi,
   but any reasonable editor would do).
4) modify the XXX.spad file and save it
5) Do

)compile XXX.spad

(typically the command is in command history so this is fast)
6) Test (frequently test are in history too, so this also is
   fast)
7) if not done goto 4
8) make diff of original XXX.spad and modified XXX.spad
9) Edit the diff replacing XXX.spad by xxx.spad.pamphlet
10) Applay the diff to algebra
11) Do full bootrap to final test.

Typically there are several interations of inner edit-compile-test
loop.  On small files mechanical parts take fraction of second, on
larger few seconds, so it does not intrude too much into natural
flow of developement.  Note that step 10 depends on code inside
pamphlet beeing just wrapped version of code in XXX.spad, any noweb
tricks means to I need to do merging manually -- this looses time
and may introduce extra errors.

In principle good "literate" tools could work as well or better.
But external tools are a dependency while tools specific to
the project take effort ot develop.  So it is better to use
popular tools unless there is some really big gain from nonstandard
tool.  Looking at many project I see to use of exotic tools
frequently limits adoption of otherwise quite good ones.

 > In the mailing list archive it will be just forgotten or relatively hard
 > to find if the code does not (at least) have a link to your message.
 > Anyway, better put it directly into the code.

My fist feeling was that this text was too rough to elevate it
to status of documentation.  But if you think that it is good
enough we can create documentation subdirectory and put it there.

 > Since I've also worked on powerseries in aldor-combinat... does your
 > code allow to define powerseries by recursion? I think that should be
 > somehow possible by using "delay".

Well "my code" is routine for mutiplying power series.  The framework
for computing power series is due to original Axiom developer.  AFAICS
you can use quite general recursive construct when defining power
series.  Note: while conceptualy there is recursion at runtime
typically there are no recursive calls, so no need to worry about
overflowing stack due to deep recursion (but as the power series
example illustrates whithout some care one may exhaust available
memory (heap)).

 > Further, I still would very much like a native implementation of
 > "Generator" in SPAD. Do you have any plans for that?

They are in queue of "nice things that we would do if we had
enough resources", but IMHO other things are more important,
so no specific plans ATM.

-- 
                              Waldek Hebisch
hebi...@math.uni.wroc.pl


From: Martin Rubey <martin.ru...@math.uni-hannover.de>
Date: Sat, 05 Dec 2009 21:44:22 +0100
Local: Sat, Dec 5 2009 3:44 pm
Subject: Re: [fricas-devel] Multiplication of power series


Waldek Hebisch <hebi...@math.uni.wroc.pl> writes:
 > Ralf Hemmecke wrote:
 >> Waldek,

 >> Since we have literate programming, I think your explanation would be
 >> best put just next to your implementation. Can you commit that?

 > No!!!  I _really_ do not want to see such texts inside source
 > files.  Such for given person such text may be useful once,
 > maybe few times, but having to read it or even only look at
 > it every time when looking at code is simply too distracting.

How about putting it into a separate subsection but at least in the same
file?  I'm afraid that there will never be concensus, but maybe we cann
have a compromise?

When working on GUESS, I updated the doc (for myself!!!) at least from
time to time.  I admit it is far from perfect, outdated at places and
often inaccurate.  But it happened already a few times that reading my
old doc helped myself remember what I was trying to do.

 > In other words, persons looking at/modifying algebra code are
 > supposed to have appropriate background knowledge.  Consider
 > research article on some fancy rings.  If you put there
 > elementary introduction to rings every referee will tell
 > you to delete such material. 

So far this didn't happen to me - actually rather the opposite -
although I consider myself as doing "elementary" stuff.  I am frequently
surprised what other mathematicians find "elementary", by the way.

 > Let me explain my workflow when developing algebra code:

 > 1) copy XXX.spad file from build directory to work directory
 > 2) start up FriCAS in work directory
 > 3) in separate window start an editor on XXX.spad file (I use vi,
 >    but any reasonable editor would do).
 > 4) modify the XXX.spad file and save it

I think you might save time in 9, 10 below by editing the pamhlet
directly, and binding some keystroke to notangle or document.

I admit however, that it is probably better to have only one chunk per
function.  Having it in a completely separate section looks "far away"
from me, I probably won't ever update documentation in a different file.

 > 5) Do

 > )compile XXX.spad

 > (typically the command is in command history so this is fast)
 > 6) Test (frequently test are in history too, so this also is
 >    fast)
 > 7) if not done goto 4
 > 8) make diff of original XXX.spad and modified XXX.spad
 > 9) Edit the diff replacing XXX.spad by xxx.spad.pamphlet
 > 10) Applay the diff to algebra
 > 11) Do full bootrap to final test.

The true question probably is: how to allow different workflows in the
same project...

Martin
From: leh...@bayou.uni-linz.ac.at
Date: Sat, 5 Dec 2009 22:02:01 +0100
Local: Sat, Dec 5 2009 4:02 pm
Subject: Re: [fricas-devel] Multiplication of power series

Dear Waldek

thank you for the explanations on streams.
Incidentally I am working with streams too these days
(moments, Jacobi parameters and continued fractions)
and found this extremely helpful.
Also the recent comments on the spad compiler.

On Sat, Dec 05, 2009 at 04:54:52PM +0100, Waldek Hebisch wrote:
 > No!!!  I _really_ do not want to see such texts inside source
 > files.

well after notangle they disappear ... this way everyone is more or less
happy.

 > Such for given person such text may be useful once,

Given many persons it will be useful many times :)

 > In other words, persons looking at/modifying algebra code are
 > supposed to have appropriate background knowledge.

At the moment the source code is an essential part of the documentation.
Most prospective library programmers and readers will be mathematicians
with low programming background (I have almost none),
concentrating on mathematics.
Given that the compiler and the library is mostly undocumented,
where should this background knowledge come from?

 > Consider
 > research article on some fancy rings.  If you put there
 > elementary introduction to rings every referee will tell
 > you to delete such material.

Well, research papers without proofs are also rejected.
Having to reconstruct every proof is even more tedious than
reading too many trivialities. Similarly here some hints
on why and what the code is supposed to do can be helpful.

 > easier.  Also, people are pretty good at analogy, so explaing
 > one thing allows them to understand similar thins.

Indeed. The information should be there and cross referenced
when needed.

 > For background we should have documentation (separate
 > from source code!).  Unfortunatly, past "literate"
 > effort removed places where normally documentation
 > should live.  But is relatively easy to cure.

So where should I put documentation for my domains?
I mostly write it for myself in order to understand my own code later
and where it came from.
Being a forgetful person I very much like having everything in one file,
but understand that this is personal taste.
Another advantage is that I can have multiple alternative versions of
a chunk in _one_ file and being able to quickly switch by just
changing the name of subchunks.

 > )compile XXX.spad

I write a Makefile extracting the *.spad and *.input code from  *.nw and do
)sys make
)compile XXX.spad
)read test
this is almost as fast. And only one source file for everything.
And if this is too much typing,
put the three lines into yet another .input file.

 > 7) if not done goto 4
 > 8) make diff of original XXX.spad and modified XXX.spad
 > 9) Edit the diff replacing XXX.spad by xxx.spad.pamphlet

not needed.

 > My fist feeling was that this text was too rough to elevate it
 > to status of documentation.  But if you think that it is good
 > enough we can create documentation subdirectory and put it there.

Yes, please this is exactly the kind of documentation newcomers like to see.
In any case documentation not written immediately will never be written.
Given that everyone's time on this planet is finite,
things which are not written down will be gone sooner or later.

just my 2c
Franz


From: Ralf Hemmecke <r...@hemmecke.de>
Date: Sat, 05 Dec 2009 23:30:10 +0100
Local: Sat, Dec 5 2009 5:30 pm
Subject: Re: [fricas-devel] Multiplication of power series

On 12/05/2009 04:54 PM, Waldek Hebisch wrote:

 > Ralf Hemmecke wrote:
 >> Waldek,

 >> Since we have literate programming, I think your explanation would be
 >> best put just next to your implementation. Can you commit that?

 > No!!!  I _really_ do not want to see such texts inside source
 > files.  Such for given person such text may be useful once,
 > maybe few times, but having to read it or even only look at
 > it every time when looking at code is simply too distracting.

Hmmm. OK, I cannot and will not force anybody to find literate
programming important.

There are still proper tools missing to support LP. Thank you, Martin
and Franz, that now I know you are more or less on the LP side and find
this a good thing.

Anyway, I guess, what Waldek says should not be overlooked. Looking at
what I did during my work at aldor-combinat

http://www.risc.uni-linz.ac.at/people/hemmecke/aldor/combinat/

I must say that it was a time when I tried to figure out whether LP is
good or bad. Look at the text there, it's not perfect. Not perfect in
terms of structure of the text and not perfect to fit one's workflow.
And, although there is lot's of information, most people will probably
find an overview section missing. Yes, aldor-combinat is unfinished in
terms of documentation.

An important point that Waldek makes is that as the original programmer,
one knows all the background and just wants to code and refactor the
code. Documentation is just getting in the way.

Unfortunately, documentation is more often read than written and the
most important thing is that the documentation is for other people. In
particular for other programmers that want to understand the code and
improve it.

I think, we as the FriCAS team have to make a compromise to make
everyone happy. If Waldek doesn't (yet) like LP, we must accept it. As I
said in my last mail, however, there should at least be a pointer in the
.spad file (write it as -- comment) which points to a file or section
that contains the corresponding information.

Waldek, I'm so happy that you wrote that section in
http://groups.google.com/group/fricas-devel/browse_thread/thread/7bf2...
but please put it into the source code repository. For me it doesn't
matter where. I find that in the same .pamphlet file is the best option,
but if you like, open up another place, but put a link to that place in
the .spad file.

Whenever we become more than 100 developers (smiling a little), we can
be more strict with LP rules. But who knows when this will happen.
Waldek is right in the sense that FriCAS should be made interesting in
term of functionality in order to attract more people.

Ralf

From: Bill Page <bill.p...@newsynthesis.org>
Date: Tue, 8 Dec 2009 13:46:55 -0500
Local: Tues, Dec 8 2009 1:46 pm
Subject: Re: [fricas-devel] Multiplication of power series


- Hide quoted text -
- Show quoted text -
On Sat, Dec 5, 2009 at 5:30 PM, Ralf Hemmecke wrote:
 > On 12/05/2009 04:54 PM, Waldek Hebisch wrote:
 >> Ralf Hemmecke wrote:
 >>> Waldek,

 >>> Since we have literate programming, I think your explanation would be
 >>> best put just next to your implementation. Can you commit that?

 >> No!!!  I _really_ do not want to see such texts inside source
 >> files.  Such for given person such text may be useful once,
 >> maybe few times, but having to read it or even only look at
 >> it every time when looking at code is simply too distracting.

 > Hmmm. OK, I cannot and will not force anybody to find literate
 > programming important.

 > There are still proper tools missing to support LP. Thank you, Martin
 > and Franz, that now I know you are more or less on the LP side and
 > find this a good thing.
 > ...

Perhaps there are also people like me who have "lost faith" in the
concept of literate programming. When I first started with the Axiom
project several years ago I originally thought it was a good idea and
a reasonable response to the serious problem of lack of documentation
of the Axiom system. But now I agree with Waldek that almost always
the "documentation" part of the pamphlet files gets in the way of my
understanding of the code and work almost exclusively with the .spad
files until forced to re-assemble them into the pamphlet form.

I do not think that this is only a result of the lack of proper tools
to support LP although I have long argued that there are better
approaches than the one originally advocated by Donald Knuth. There
are multiple problems but I think the most serious problem is that the
methodology just does not fit the psychology of many (most?) of the
talented people who are able to do this kind of work - particularly
when they do it voluntarily. Advocated "re-education" and greater
self-discipline is simply impractical. And hoping that other motivated
users/developers will appear who are willing to put an effort into
documenting other people's code is simply unrealistic.

Having worked with Sage for awhile it seems to me that the "doc
string" methodology much better suits the current state-of-the-art and
state-of-mind in software development. Ironically this is very similar
to the ++ style comments in Spad and how they interact with hyperdoc.
I am very happy that Waldek has stated elsewhere that he considers the
hyperdoc documentation to be the "definitive source" for documentation
of FriCAS and that he spent considerable effort to resurrect the tools
from the original Axiom source code to help keep Hyperdoc up to date.
It seems that even more can be done in this direction to advance the
original approach developed before Axiom became an open source
project. For example as I understand it the Axiom book was originally
extracted from the same set of enhanced tex files combined with
documentation in the Axiom source code and derived by running Axiom
itself.

I think that it was a great experiment but in the end it is rather
unfortunate that Tim Daly choose to adopt a new "technology" based on
the Knuth literate programming approach when initiating the first open
source Axiom project rather than focusing on extending and expanding
the use of hyperdoc. I cannot see any evidence at all that the use of
literate programming as such in the original Axiom project has
contributed anything to the acceptance of Axiom in the potential
user/developer community.

Needless to repeat I suppose that this is of course only my personal
opinion. :-)

\start
Date: Thu, 10 Dec 2009 03:34:17 -0500
From: Tim Daly
To: Bertfried Fauser, Martin Baker
Subject: GrassmannAlgebra domain

The GrassmannAlgebra domain has been added to Axiom. --Tim

\start
Date: Thu, 10 Dec 2009 18:12:30 +0000
From: Martin Baker
To: list
Subject: Re: GrassmannAlgebra domain

> The GrassmannAlgebra domain has been added to Axiom. --Tim

Tim,

Thanks, do you have any views about how it should evolve from here? I think 
the first stage is to fix the known issues and get the inverse function 
working well enough to be able to implement transforms for any metric.  At 
that stage I think the code should be useful for experimenting with 
geometry/physics applications.

Then at some stage I think it would be good if there were to be some sort of 
discussion about the code and naming structure. For instance: how the 
categories and so on should be designed to relate to other algebra families in 
Axiom such as Cayley-Dickson, Spinor, Hopf and Tensor Algebras.

\start
Date: Thu, 10 Dec 2009 15:03:34 -0500
From: Tim Daly
To: Martin Baker
Subject: Re: GrassmannAlgebra domain

Martin Baker wrote:
>> The GrassmannAlgebra domain has been added to Axiom. --Tim
>>     
>
> Tim,
>
> Thanks, do you have any views about how it should evolve from here? I think 
> the first stage is to fix the known issues and get the inverse function 
> working well enough to be able to implement transforms for any metric.  At 
> that stage I think the code should be useful for experimenting with 
> geometry/physics applications.
>
> Then at some stage I think it would be good if there were to be some sort of 
> discussion about the code and naming structure. For instance: how the 
> categories and so on should be designed to relate to other algebra families in 
> Axiom such as Cayley-Dickson, Spinor, Hopf and Tensor Algebras.
>
> Martin
>
>   

Well Axiom is all about organizing the algebra into hierarchical
categories where each category build on prior ones.

Is there a natural hierarchy of these algebras? If so, I think it is
important to extract that hierarchy, define the operations at the
category level even if they do not have an implementation there, and
layer the categories naturally.

I would start by just writing the Cayley-Dickson, Spinor, Hopf, and
Tensor domain definitions (without implementations), find the common
operations, collect them into a category, and inherit from that
category.

I know a little bit about Clifford algebra and I'm reading the
Grassman algebra book now but I do not know enough to say anything
about what would be common among the various algebras.

\start
Date: Sat, 19 Dec 2009 12:30:32 +0800
From: Lee Duhem
To: list
Subject: [PATCH] Fix some typo and formatting problems in books/bookvol0.pamphlet and books/bookvol1.pamphlet

I have found some typo and formatting problems in
books/bookvol0.pamphlet and books/bookvol1.pamphlet,
this is the fix. You may want take a look.

lee

--001636ed67822270a1047b0d51ef

ZGlmZiAtLWdpdCBhL2Jvb2tzL2Jvb2t2b2wwLnBhbXBobGV0IGIvYm9va3MvYm9va3ZvbDAucGFt
cGhsZXQKaW5kZXggZTlkZjM2Yy4uMTFjZmE0NCAxMDA2NDQKLS0tIGEvYm9va3MvYm9va3ZvbDAu
cGFtcGhsZXQKKysrIGIvYm9va3MvYm9va3ZvbDAucGFtcGhsZXQKQEAgLTE0MTYsNyArMTQxNiw3
IEBAIGZsb2F0aW5nIHBvaW50IG51bWJlciB0byB0aGUgbmVhcmVzdCBpbnRlZ2VyIHdoaWxlIHRo
ZSBvdGhlciB0cnVuY2F0ZXMKIHtcYmYgZmxvYXRpbmcgcG9pbnR9IG51bWJlci4gVG8gZXh0cmFj
dCB0aGUgZnJhY3Rpb25hbCBwYXJ0IG9mIGEgZmxvYXRpbmcKIHBvaW50IG51bWJlciB1c2UgdGhl
IGZ1bmN0aW9uIHtcYmYgZnJhY3Rpb25QYXJ0fSBidXQgbm90ZSB0aGF0IHRoZSBzaWduCiBvZiB0
aGUgcmVzdWx0IGRlcGVuZHMgb24gdGhlIHNpZ24gb2YgdGhlIGFyZ3VtZW50LiBBeGlvbSBvYnRh
aW5zIHRoZQotZnJhY3Rpb25hbCBwYXJ0b2YgJHgkIHVzaW5nICR4IC0gdHJ1bmNhdGUoeCkkOgor
ZnJhY3Rpb25hbCBwYXJ0IG9mICR4JCB1c2luZyAkeCAtIHRydW5jYXRlKHgpJDoKIAogXHNwYWRj
b21tYW5ke3JvdW5kKDMuNzc2MjMpfQogJCQKQEAgLTE2NDIsNyArMTY0Miw3IEBAIEdpdmVuIHRo
YXQgd2UgY2FuIGRlZmluZSBleHByZXNzaW9ucyBpbnZvbHZpbmcgc3ltYm9scywgaG93IGRvIHdl
IGFjdHVhbGx5CiBjb21wdXRlIHRoZSByZXN1bHQgd2hlbiB0aGUgc3ltYm9scyBhcmUgYXNzaWdu
ZWQgdmFsdWVzPyBUaGUgYW5zd2VyIGlzIHRvCiB1c2UgdGhlIHtcYmYgZXZhbH0gZnVuY3Rpb24g
d2hpY2ggdGFrZXMgYW4gZXhwcmVzc2lvbiBhcyBpdHMgZmlyc3QgYXJndW1lbnQKIGZvbGxvd2Vk
IGJ5IGEgbGlzdCBvZiBhc3NpZ25tZW50cy4gRm9yIGV4YW1wbGUsIHRvIGV2YWx1YXRlIHRoZSBl
eHByZXNzaW9ucwote1xiZiBYRHVtbXl9IGFuZCB7eHlEdW1teX0gcmVzdWx0aW5nIGZyb20gdGhl
aXIgcmVzcGVjdGl2ZSBhc3NpZ25tZW50cyBhYm92ZQore1xiZiB4RHVtbXl9IGFuZCB7XGJmIHh5
RHVtbXl9IHJlc3VsdGluZyBmcm9tIHRoZWlyIHJlc3BlY3RpdmUgYXNzaWdubWVudHMgYWJvdmUK
IHdlIHR5cGU6CiAKIFxzcGFkY29tbWFuZHtldmFsKHhEdW1teSx4PTMpfQpAQCAtMTc2Miw3ICsx
NzYyLDcgQEAgJCQKIAogTm90ZSB0aGF0IHRoZSBzZW1pY29sb24gYGA7JycgaW4gdGhlIGV4YW1w
bGVzIGFib3ZlIGFsbG93cyBzZXZlcmFsCiBleHByZXNzaW9ucyB0byBiZSBlbnRlcmVkIG9uIG9u
ZSBsaW5lLiBUaGUgcmVzdWx0IG9mIHRoZSBsYXN0IGV4cHJlc3Npb24KLWlzIGRpc3BsYXllZC4g
cmVtZW1iZXIgYWxzbyB0aGF0IHRoZSBwZXJjZW50IHN5bWJvbCBgYFwlJycgaXMgdXNlZCB0bwor
aXMgZGlzcGxheWVkLiBSZW1lbWJlciBhbHNvIHRoYXQgdGhlIHBlcmNlbnQgc3ltYm9sIGBgXCUn
JyBpcyB1c2VkIHRvCiByZXByZXNlbnQgdGhlIHJlc3VsdCBvZiBhIHByZXZpb3VzIGNhbGN1bGF0
aW9uLgogCiBUbyBkaXNwbGF5IHJhdGlvbmFsIG51bWJlcnMgaW4gYSBiYXNlIG90aGVyIHRoYW4g
MTAgdGhlIGZ1bmN0aW9uIHtcYmYgcmFkaXh9CkBAIC0xODM0LDcgKzE4MzQsNyBAQCBpcyBhdmFp
bGFibGUgYW5kIHJldHVybnMgYSBwYXJ0aWFsIGZyYWN0aW9uIG9mIG9uZSB0ZXJtLiBUbyBkZWNv
bXBvc2UgdGhpcwogZnVydGhlciB0aGUgbnVtZXJhdG9yIGNhbiBiZSBvYnRhaW5lZCB1c2luZyB7
XGJmIGZpcnN0TnVtZXJ9IGFuZCB0aGUgCiBkZW5vbWluYXRvciB3aXRoIHtcYmYgZmlyc3REZW5v
bX0uIFRoZSB3aG9sZSBwYXJ0IG9mIGEgcGFydGlhbCBmcmFjdGlvbiBjYW4KIGJlIHJldHJpZXZl
ZCB1c2luZyB7XGJmIHdob2xlUGFydH0gYW5kIHRoZSBudW1iZXIgb2YgZnJhY3Rpb25hbCBwYXJ0
cyBjYW4KLWJlIGZvdW5kIHVzaW5nIHRoZSBmdW5jdGlvbiB7XGJmIG51bWJlck9mIEZyYWN0aW9u
YWxUZXJtc306CitiZSBmb3VuZCB1c2luZyB0aGUgZnVuY3Rpb24ge1xiZiBudW1iZXJPZkZyYWN0
aW9uYWxUZXJtc306CiAKIFxzcGFkY29tbWFuZHt0IDo9IHBhcnRpYWxGcmFjdGlvbigyMzQsNDAp
fQogJCQKQEAgLTE5OTQsNyArMTk5NCw3IEBAIGluY2x1ZGUgdGhlbSBpbiB0aGUgb2JqZWN0IGZp
bGVzIHByb2R1Y2VkIGFuZCBtYWtlIHRoZW0gYXZhaWxhYmUgdG8gdGhlCiBlbmQgdXNlciBmb3Ig
ZG9jdW1lbnRhdGlvbiBwdXJwb3Nlcy4KIAogQSBkZXNjcmlwdGlvbiBpcyBwbGFjZWQge1xiZiBi
ZWZvcmV9IGEgY2FsY3VsYXRpb24gYmVnaW5zIHdpdGggdGhyZWUKLWBgKysrJycgc2lnbnMgYW5k
IGEgZGVzY3JpcHRpb24gcGxhY2VkIGFmdGVyIGEgY2FsY3VsYXRpb24gYmVnaW5zIHdpdGgKK2Bg
KycnIHNpZ25zIGFuZCBhIGRlc2NyaXB0aW9uIHBsYWNlZCBhZnRlciBhIGNhbGN1bGF0aW9uIGJl
Z2lucyB3aXRoCiB0d28gcGx1cyBzeW1ib2xzIGBgKysnJy4gVGhlIHNvLWNhbGxlZCBgYHBsdXMg
cGx1cycnIGNvbW1lbnRzIGFyZSB1c2VkCiB3aXRoaW4gdGhlIGFsZ2VicmEgZmlsZXMgYW5kIGFy
ZSBwcm9jZXNzZWQgYnkgdGhlIGNvbXBpbGVyIHRvIGFkZAogdG8gdGhlIGRvY3VtZW50YXRpb24u
IFRoZSBzby1jYWxsZWQgYGBtaW51cyBtaW51cycnIGNvbW1lbnRzIGFyZSBpZ25vcmVkCkBAIC0y
NzE4LDcgKzI3MTgsNyBAQCAkJAogCiAobm90ZSB0aGF0IHtcdHQgQVJSQVkxfSBpcyBhbiBhYmJy
ZXZpYXRpb24gZm9yIHRoZSB0eXBlIAoge1x0dCBPbmVEaW1lbnNpb25hbEFycmF5fS4pIE90aGVy
IHR5cGVzIGJhc2VkIG9uIG9uZS1kaW1lbnNpb25hbCBhcnJheXMgYXJlCi17XHR0IFZlY3Rvcn0s
IHtcdHQgU3RyaW5nfSwgYW5kIHt0dCBCaXRzfS4KK3tcdHQgVmVjdG9yfSwge1x0dCBTdHJpbmd9
LCBhbmQge1x0dCBCaXRzfS4KIAogXHNwYWRjb21tYW5ke21hcCEoaSArLT4gaSsxLGEpOyBhfQog
JCQKQEAgLTI4OTksOCArMjg5OSw4IEBAICQkCiBUaGVyZSBhcmUgc2V2ZXJhbCB0aGluZ3MgdG8g
cG9pbnQgb3V0IGNvbmNlcm5pbmcgdGhlc2UKIGV4YW1wbGVzLiBGaXJzdCwgYWx0aG91Z2ggZmxl
eGlibGUgYXJyYXlzIGFyZSBtdXRhYmxlLCBtYWtpbmcgY29waWVzCiBvZiB0aGVzZSBhcnJheXMg
Y3JlYXRlcyBzZXBhcmF0ZSBlbnRpdGllcy4gVGhpcyBjYW4gYmUgc2VlbiBieSB0aGUKLWZhY3Qg
dGhhdCB0aGUgbW9kaWZpY2F0aW9uIG9mIGVsZW1lbnQge1xzbCBiLjJ9IGFib3ZlIGRpZCBub3Qg
YWx0ZXIKLXtcc2wgYX0uIFNlY29uZCwgdGhlIHtcYmYgbWVyZ2UhfSAgZnVuY3Rpb24gY2FuIHRh
a2UgYW4gZXh0cmEgYXJndW1lbnQKK2ZhY3QgdGhhdCB0aGUgbW9kaWZpY2F0aW9uIG9mIGVsZW1l
bnQge1xzbCBnLjJ9IGFib3ZlIGRpZCBub3QgYWx0ZXIKK3tcc2wgZn0uIFNlY29uZCwgdGhlIHtc
YmYgbWVyZ2UhfSAgZnVuY3Rpb24gY2FuIHRha2UgYW4gZXh0cmEgYXJndW1lbnQKIGJlZm9yZSB0
aGUgdHdvIGFycmF5cyBhcmUgbWVyZ2VkLiBUaGUgYXJndW1lbnQgaXMgYSBjb21wYXJpc29uCiBm
dW5jdGlvbiBhbmQgZGVmYXVsdHMgdG8gYGB7XHR0IDw9fScnIGlmIG9taXR0ZWQuIExhc3RseSwg
CiB7XGJmIHNocmlua2FibGV9IHRlbGxzIHRoZSBzeXN0ZW0gd2hldGhlciBvciBub3QgdG8gbGV0
IGZsZXhpYmxlIGFycmF5cwpAQCAtMzMyMCw3ICszMzIwLDcgQEAgY3VycmVudCBibG9jayB3aGVy
ZWFzIHtcYmYgYnJlYWt9IGxlYXZlcyB0aGUgY3VycmVudCBsb29wLiBUaGUge1xiZiByZXR1cm59
CiBzdGF0ZW1lbnQgbGVhdmVzIHRoZSBjdXJyZW50IGZ1bmN0aW9uLgogCiBUbyBza2lwIHRoZSBy
ZXN0IG9mIGEgbG9vcCBib2R5IGFuZCBjb250aW51ZSB0aGUgbmV4dCBpdGVyYXRpb24gb2YgdGhl
IGxvb3AKLXVzZSB0aGUge1xiZiBpdGVyYXRlfSBzdGF0ZW1lbnQgKHRoZSAtLSBzdGFydHMgYSBj
b21tZW50IGluIEF4aW9tKQordXNlIHRoZSB7XGJmIGl0ZXJhdGV9IHN0YXRlbWVudCAodGhlIHtc
dHQgLS19IHN0YXJ0cyBhIGNvbW1lbnQgaW4gQXhpb20pCiBcYmVnaW57dmVyYmF0aW19CiBpIDo9
IDAKIHJlcGVhdApAQCAtMzU5NSw4ICszNTk1LDggQEAgZm9yIHcgaW4gWyJUaGlzIiwgImlzIiwg
InlvdXIiLCAibGlmZSEiXSByZXBlYXQKIFRoZSBzZWNvbmQgZm9ybSBvZiB0aGUge1xiZiBmb3J9
IGxvb3Agc3ludGF4IGluY2x1ZGVzIGEgYGB7XGJmIHN1Y2ggdGhhdH0nJwogY2xhdXNlIHdoaWNo
IG11c3QgYmUgb2YgdHlwZSB7XGJmIEJvb2xlYW59OgogXGJlZ2lue2NlbnRlcn0KLWZvciB7XHNs
IHZhcn0gfCB7XHNsIEJvb2xFeHByfSBpbiB7XHNsIHNlZ30gcmVwZWF0IHtcc2wgbG9vcEJvZHl9
XFwKLWZvciB7XHNsIHZhcn0gfCB7XHNsIEJvb2xFeHByfSBpbiB7XHNsIGxpc3R9IHJlcGVhdCB7
XHNsIGxvb3BCb2R5fQorZm9yIHtcc2wgdmFyfSBpbiB7XHNsIHNlZ30gXHRleHRiYXJcIHtcc2wg
Qm9vbEV4cHJ9IHJlcGVhdCB7XHNsIGxvb3BCb2R5fVxcCitmb3Ige1xzbCB2YXJ9IGluIHtcc2wg
bGlzdH0gXHRleHRiYXJcIHtcc2wgQm9vbEV4cHJ9IHJlcGVhdCB7XHNsIGxvb3BCb2R5fQogXGVu
ZHtjZW50ZXJ9CiBTb21lIGV4YW1wbGVzIGFyZToKIFxiZWdpbnt2ZXJiYXRpbX0KQEAgLTQyNjIs
NyArNDI2Miw3IEBAIGlzIHRoZSBzYW1lIGFzIGlmIHlvdSBoYWQgZW50ZXJlZAogCiBBeGlvbSBz
dGF0ZW1lbnRzIGluIGFuIGlucHV0IGZpbGUKIChzZWUgXHNlY3Rpb25yZWZ7dWdJbk91dElufSkK
LWNhbiB1c2UgaW5kZW50YXRpb24gdG8gaW5kaWNhdGUgdGhlIHByb2dyYW0gc3RydWN0dXJlIC4K
K2NhbiB1c2UgaW5kZW50YXRpb24gdG8gaW5kaWNhdGUgdGhlIHByb2dyYW0gc3RydWN0dXJlCiAo
c2VlIFxzZWN0aW9ucmVme3VnTGFuZ0Jsb2Nrc30pLgogCiBcc3Vic2VjdGlvbntDb21tZW50c30K
QEAgLTQzMzcsNyArNDMzNyw3IEBAICQkCiAkJAogXHJldHVyblR5cGV7VHlwZTogRnJhY3Rpb24g
SW50ZWdlcn0KIAotVG8gZmFjdG9yIGZyYWN0aW9ucywgeW91IGhhdmUgdG8gcG1hcCB7XGJmIGZh
Y3Rvcn0gb250byB0aGUgbnVtZXJhdG9yCitUbyBmYWN0b3IgZnJhY3Rpb25zLCB5b3UgaGF2ZSB0
byBtYXAge1xiZiBmYWN0b3J9IG9udG8gdGhlIG51bWVyYXRvcgogYW5kIGRlbm9taW5hdG9yLgog
CiBcc3BhZGNvbW1hbmR7bWFwKGZhY3RvcixyKX0KQEAgLTQ4NzAsMTcgKzQ4NzAsMTcgQEAgJCQK
ICQkCiBccmV0dXJuVHlwZXtUeXBlOiBGbGV4aWJsZUFycmF5IEludGVnZXJ9CiAKLUZsZXhpYmxl
IGFycmF5cyBhcmUgdXNlZCB0byBpbXBsZW1lbnQgYGBoZWFwcy4nJyBBIHtcaXQgaGVhcH0gaXMg
YW4KLWV4YW1wbGUgb2YgYSBkYXRhIHN0cnVjdHVyZSBjYWxsZWQgYSB7XGl0IHByaW9yaXR5IHF1
ZXVlfSwgd2hlcmUKLWVsZW1lbnRzIGFyZSBvcmRlcmVkIHdpdGggcmVzcGVjdCB0byBvbmUgYW5v
dGhlci4gQSBoZWFwCitGbGV4aWJsZSBhcnJheXMgYXJlIHVzZWQgdG8gaW1wbGVtZW50IGBgaGVh
cHMuJycgQSB7XGl0IGhlYXB9CiBcZm9vdG5vdGV7XGRvbWFpbnJlZntIZWFwfX0KK2lzIGFuIGV4
YW1wbGUgb2YgYSBkYXRhIHN0cnVjdHVyZSBjYWxsZWQgYSB7XGl0IHByaW9yaXR5IHF1ZXVlfSwg
d2hlcmUKK2VsZW1lbnRzIGFyZSBvcmRlcmVkIHdpdGggcmVzcGVjdCB0byBvbmUgYW5vdGhlci4g
QSBoZWFwCiBpcyBvcmdhbml6ZWQgc28gYXMgdG8gb3B0aW1pemUgaW5zZXJ0aW9uCiBhbmQgZXh0
cmFjdGlvbiBvZiBtYXhpbXVtIGVsZW1lbnRzLiAgVGhlIHtcYmYgZXh0cmFjdCF9IG9wZXJhdGlv
bgogcmV0dXJucyB0aGUgbWF4aW11bSBlbGVtZW50IG9mIHRoZSBoZWFwLCBhZnRlciBkZXN0cnVj
dGl2ZWx5IHJlbW92aW5nCiB0aGF0IGVsZW1lbnQgYW5kIHJlb3JnYW5pemluZyB0aGUgaGVhcCBz
byB0aGF0IHRoZSBuZXh0IG1heGltdW0KIGVsZW1lbnQgaXMgcmVhZHkgdG8gYmUgZGVsaXZlcmVk
LgogCi1BbiBlYXN5IHdheSB0byBjcmVhdGUgYSBoZWFwIGlzIHRvIGFwcGx5IHRoZSBvcGVyYXRp
b24ge1xpdCBoZWFwfQorQW4gZWFzeSB3YXkgdG8gY3JlYXRlIGEgaGVhcCBpcyB0byBhcHBseSB0
aGUgb3BlcmF0aW9uIHtcYmYgaGVhcH0KIHRvIGEgbGlzdCBvZiB2YWx1ZXMuCiBcc3BhZGNvbW1h
bmR7aCA6PSBoZWFwIFstNCw3LDExLDMsNCwtN119CiAkJApAQCAtNDkwNCwxNiArNDkwNCwxNCBA
QCAkJAogQSB7XGl0IGJpbmFyeSB0cmVlfSBpcyBhIGBgdHJlZScnIHdpdGggYXQgbW9zdCB0d28g
YnJhbmNoZXMKIFxpbmRleHt0cmVlfSBwZXIgbm9kZTogaXQgaXMgZWl0aGVyIGVtcHR5LCBvciBl
bHNlIGlzIGEgbm9kZQogY29uc2lzdGluZyBvZiBhIHZhbHVlLCBhbmQgYSBsZWZ0IGFuZCByaWdo
dCBzdWJ0cmVlIChhZ2FpbiwgYmluYXJ5Ci10cmVlcykuIFxmb290bm90ZXtcZG9tYWlucmVme0Jp
bmFyeVNlYXJjaFRyZWV9fQotRXhhbXBsZXMgb2YgYmluYXJ5IHRyZWUgdHlwZXMgYXJlIHtcdHQg
QmluYXJ5U2VhcmNoVHJlZX0sIAordHJlZXMpLiBFeGFtcGxlcyBvZiBiaW5hcnkgdHJlZSB0eXBl
cyBhcmUge1x0dCBCaW5hcnlTZWFyY2hUcmVlfSwgCiB7XHR0IFBlbmRhbnRUcmVlfSwge1x0dCBU
b3VybmFtZW50VHJlZX0sIGFuZCB7XHR0IEJhbGFuY2VkQmluYXJ5VHJlZX0uCi1cZm9vdG5vdGV7
XGRvbWFpbnJlZntCYWxhbmNlZEJpbmFyeVRyZWV9fQogCiBBIHtcaXQgYmluYXJ5IHNlYXJjaCB0
cmVlfSBpcyBhIGJpbmFyeSB0cmVlIHN1Y2ggdGhhdCwKIFxpbmRleHt0cmVlIWJpbmFyeSBzZWFy
Y2h9IGZvciBlYWNoIG5vZGUsIHRoZSB2YWx1ZSBvZiB0aGUgbm9kZSBpcwogXGluZGV4e2JpbmFy
eSBzZWFyY2ggdHJlZX0gZ3JlYXRlciB0aGFuIGFsbCB2YWx1ZXMgKGlmIGFueSkgaW4gdGhlCiBs
ZWZ0IHN1YnRyZWUsIGFuZCBsZXNzIHRoYW4gb3IgZXF1YWwgYWxsIHZhbHVlcyAoaWYgYW55KSBp
biB0aGUgcmlnaHQKLXN1YnRyZWUuCitzdWJ0cmVlLiBcZm9vdG5vdGV7XGRvbWFpbnJlZntCaW5h
cnlTZWFyY2hUcmVlfX0KIFxzcGFkY29tbWFuZHtiaW5hcnlTZWFyY2hUcmVlIFs1LDMsMiw5LDQs
NywxMV19CiAkJAogXGxlZnRbCkBAIC00OTI2LDYgKzQ5MjQsNyBAQCAkJAogXHJldHVyblR5cGV7
VHlwZTogQmluYXJ5U2VhcmNoVHJlZSBQb3NpdGl2ZUludGVnZXJ9CiAKIEEge1xpdCBiYWxhbmNl
ZCBiaW5hcnkgdHJlZX0gaXMgdXNlZnVsIGZvciBkb2luZyBtb2R1bGFyIGNvbXB1dGF0aW9ucy4K
K1xmb290bm90ZXtcZG9tYWlucmVme0JhbGFuY2VkQmluYXJ5VHJlZX19CiBcaW5kZXh7YmFsYW5j
ZWQgYmluYXJ5IHRyZWV9IEdpdmVuIGEgbGlzdCAkbG0kIG9mIG1vZHVsaSwKIFxpbmRleHt0cmVl
IWJhbGFuY2VkIGJpbmFyeX0ge1xiZiBtb2RUcmVlfSQoYSxsbSkkIHByb2R1Y2VzCiBhIGJhbGFu
Y2VkIGJpbmFyeSB0cmVlIHdpdGggdGhlIHZhbHVlcyAkYSBcYm1vZCBtJCBhdCBpdHMgbGVhdmVz
LgpAQCAtNDk0NCw3ICs0OTQzLDcgQEAgY29ycmVzcG9uZGluZyBzdHJ1Y3R1cmUgbGlrZSBzdHJl
YW1zIGZvciBpbmZpbml0ZSBjb2xsZWN0aW9ucy4KIAogQ3JlYXRlIHNldHMgdXNpbmcgYnJhY2Vz
IGBgXHtgYCBhbmQgYGBcfScnIHJhdGhlciB0aGFuIGJyYWNrZXRzLgogCi1cc3BhZGNvbW1hbmR7
ZnMgOj0gc2V0WzEvMyw0LzUsLTEvMyw0LzVdfQorXHNwYWRjb21tYW5ke2ZzIDo9IHNldCBbMS8z
LDQvNSwtMS8zLDQvNV19CiAkJAogXGxlZnRcewogLXtcZnJhY3sxfXszfX0sICB7XGZyYWN7MX17
M319LCAge1xmcmFjezR9ezV9fSAK
--001636ed67822270a1047b0d51ef

ZGlmZiAtLWdpdCBhL2Jvb2tzL2Jvb2t2b2wxLnBhbXBobGV0IGIvYm9va3MvYm9va3ZvbDEucGFt
cGhsZXQKaW5kZXggOGE2NWI1NC4uNDIyNmM4MCAxMDA2NDQKLS0tIGEvYm9va3MvYm9va3ZvbDEu
cGFtcGhsZXQKKysrIGIvYm9va3MvYm9va3ZvbDEucGFtcGhsZXQKQEAgLTE3NTYsNyArMTc1Niw3
IEBAIGlzIHRoZSBzYW1lIGFzIGlmIHlvdSBoYWQgZW50ZXJlZAogXGVuZHt2ZXJiYXRpbX0KIAog
QXhpb20gc3RhdGVtZW50cyBpbiBhbiB7XGJmIGlucHV0fSBmaWxlCi1jYW4gdXNlIGluZGVudGF0
aW9uIHRvIGluZGljYXRlIHRoZSBwcm9ncmFtIHN0cnVjdHVyZSAuCitjYW4gdXNlIGluZGVudGF0
aW9uIHRvIGluZGljYXRlIHRoZSBwcm9ncmFtIHN0cnVjdHVyZS4KIAogXHN1YnNlY3Rpb257Q29t
bWVudHN9CiBcbGFiZWx7c2VjOkNvbW1lbnRzfQpAQCAtMTg5OSw3ICsxODk5LDcgQEAgZmxvYXRp
bmcgcG9pbnQgbnVtYmVyIHRvIHRoZSBuZWFyZXN0IGludGVnZXIgd2hpbGUgdGhlIG90aGVyIHRy
dW5jYXRlcwoge1xiZiBmbG9hdGluZyBwb2ludH0gbnVtYmVyLiBUbyBleHRyYWN0IHRoZSBmcmFj
dGlvbmFsIHBhcnQgb2YgYSBmbG9hdGluZwogcG9pbnQgbnVtYmVyIHVzZSB0aGUgZnVuY3Rpb24g
e1xiZiBmcmFjdGlvblBhcnR9IGJ1dCBub3RlIHRoYXQgdGhlIHNpZ24KIG9mIHRoZSByZXN1bHQg
ZGVwZW5kcyBvbiB0aGUgc2lnbiBvZiB0aGUgYXJndW1lbnQuIEF4aW9tIG9idGFpbnMgdGhlCi1m
cmFjdGlvbmFsIHBhcnRvZiAkeCQgdXNpbmcgJHggLSB0cnVuY2F0ZSh4KSQ6CitmcmFjdGlvbmFs
IHBhcnQgb2YgJHgkIHVzaW5nICR4IC0gdHJ1bmNhdGUoeCkkOgogCiBcaW5kZXh7cm91bmR9CiBc
c3BhZGNvbW1hbmR7cm91bmQoMy43NzYyMyl9CkBAIC0yMzA3LDcgKzIzMDcsNyBAQCAkJAogXGlu
ZGV4ezsgb3V0cHV0IHN1cHByZXNzaW9ufQogTm90ZSB0aGF0IHRoZSBzZW1pY29sb24gYGA7Jycg
aW4gdGhlIGV4YW1wbGVzIGFib3ZlIGFsbG93cyBzZXZlcmFsCiBleHByZXNzaW9ucyB0byBiZSBl
bnRlcmVkIG9uIG9uZSBsaW5lLiBUaGUgcmVzdWx0IG9mIHRoZSBsYXN0IGV4cHJlc3Npb24KLWlz
IGRpc3BsYXllZC4gcmVtZW1iZXIgYWxzbyB0aGF0IHRoZSBwZXJjZW50IHN5bWJvbCBgYFwlJycg
aXMgdXNlZCB0bworaXMgZGlzcGxheWVkLiBSZW1lbWJlciBhbHNvIHRoYXQgdGhlIHBlcmNlbnQg
c3ltYm9sIGBgXCUnJyBpcyB1c2VkIHRvCiByZXByZXNlbnQgdGhlIHJlc3VsdCBvZiBhIHByZXZp
b3VzIGNhbGN1bGF0aW9uLgogCiBUbyBkaXNwbGF5IHJhdGlvbmFsIG51bWJlcnMgaW4gYSBiYXNl
IG90aGVyIHRoYW4gMTAgdGhlIGZ1bmN0aW9uIHtcYmYgcmFkaXh9CkBAIC0yMzg3LDcgKzIzODcs
NyBAQCBpcyBhdmFpbGFibGUgYW5kIHJldHVybnMgYSBwYXJ0aWFsIGZyYWN0aW9uIG9mIG9uZSB0
ZXJtLiBUbyBkZWNvbXBvc2UgdGhpcwogZnVydGhlciB0aGUgbnVtZXJhdG9yIGNhbiBiZSBvYnRh
aW5lZCB1c2luZyB7XGJmIGZpcnN0TnVtZXJ9IGFuZCB0aGUgCiBkZW5vbWluYXRvciB3aXRoIHtc
YmYgZmlyc3REZW5vbX0uIFRoZSB3aG9sZSBwYXJ0IG9mIGEgcGFydGlhbCBmcmFjdGlvbiBjYW4K
IGJlIHJldHJpZXZlZCB1c2luZyB7XGJmIHdob2xlUGFydH0gYW5kIHRoZSBudW1iZXIgb2YgZnJh
Y3Rpb25hbCBwYXJ0cyBjYW4KLWJlIGZvdW5kIHVzaW5nIHRoZSBmdW5jdGlvbiB7XGJmIG51bWJl
ck9mIEZyYWN0aW9uYWxUZXJtc306CitiZSBmb3VuZCB1c2luZyB0aGUgZnVuY3Rpb24ge1xiZiBu
dW1iZXJPZkZyYWN0aW9uYWxUZXJtc306CiAKIFxzcGFkY29tbWFuZHt0IDo9IHBhcnRpYWxGcmFj
dGlvbigyMzQsNDApfQogJCQKQEAgLTI1NjEsNyArMjU2MSw3IEBAIGluY2x1ZGUgdGhlbSBpbiB0
aGUgb2JqZWN0IGZpbGVzIHByb2R1Y2VkIGFuZCBtYWtlIHRoZW0gYXZhaWxhYmxlIHRvIHRoZQog
ZW5kIHVzZXIgZm9yIGRvY3VtZW50YXRpb24gcHVycG9zZXMuCiAKIEEgZGVzY3JpcHRpb24gaXMg
cGxhY2VkIHtcYmYgYmVmb3JlfSBhIGNhbGN1bGF0aW9uIGJlZ2lucyB3aXRoIHRocmVlCi1gYCsr
KycnIHNpZ25zIGFuZCBhIGRlc2NyaXB0aW9uIHBsYWNlZCBhZnRlciBhIGNhbGN1bGF0aW9uIGJl
Z2lucyB3aXRoCitgYCsnJyBzaWducyBhbmQgYSBkZXNjcmlwdGlvbiBwbGFjZWQgYWZ0ZXIgYSBj
YWxjdWxhdGlvbiBiZWdpbnMgd2l0aAogdHdvIHBsdXMgc2lnbnMgYGArKycnLiBUaGUgc28tY2Fs
bGVkIGBgcGx1cyBwbHVzJycgY29tbWVudHMgYXJlIHVzZWQKIHdpdGhpbiB0aGUgYWxnZWJyYSBm
aWxlcyBhbmQgYXJlIHByb2Nlc3NlZCBieSB0aGUgY29tcGlsZXIgdG8gYWRkCiB0byB0aGUgZG9j
dW1lbnRhdGlvbi4gVGhlIHNvLWNhbGxlZCBgYG1pbnVzIG1pbnVzJycgY29tbWVudHMgYXJlIGln
bm9yZWQKQEAgLTQxNjEsNyArNDE2MSw3IEBAIHN0YXRlbWVudCBsZWF2ZXMgdGhlIGN1cnJlbnQg
ZnVuY3Rpb24uCiAKIFxpbmRleHtpdGVyYXRlfQogVG8gc2tpcCB0aGUgcmVzdCBvZiBhIGxvb3Ag
Ym9keSBhbmQgY29udGludWUgdGhlIG5leHQgaXRlcmF0aW9uIG9mIHRoZSBsb29wCi11c2UgdGhl
IHtcYmYgaXRlcmF0ZX0gc3RhdGVtZW50ICh0aGUgLS0gc3RhcnRzIGEgY29tbWVudCBpbiBBeGlv
bSkKK3VzZSB0aGUge1xiZiBpdGVyYXRlfSBzdGF0ZW1lbnQgKHRoZSB7XHR0IC0tfSBzdGFydHMg
YSBjb21tZW50IGluIEF4aW9tKQogXGJlZ2lue3ZlcmJhdGltfQogaSA6PSAwCiByZXBlYXQKQEAg
LTQ0NjUsOCArNDQ2NSw4IEBAIGZvciB3IGluIFsiVGhpcyIsICJpcyIsICJ5b3VyIiwgImxpZmUh
Il0gcmVwZWF0CiBUaGUgc2Vjb25kIGZvcm0gb2YgdGhlIHtcYmYgZm9yfSBsb29wIHN5bnRheCBp
bmNsdWRlcyBhIGBge1xiZiBzdWNoIHRoYXR9JycKIGNsYXVzZSB3aGljaCBtdXN0IGJlIG9mIHR5
cGUge1xiZiBCb29sZWFufToKIFxiZWdpbntjZW50ZXJ9Ci1mb3Ige1xzbCB2YXJ9IHwge1xzbCBC
b29sRXhwcn0gaW4ge1xzbCBzZWd9IHJlcGVhdCB7XHNsIGxvb3BCb2R5fVxcCi1mb3Ige1xzbCB2
YXJ9IHwge1xzbCBCb29sRXhwcn0gaW4ge1xzbCBsaXN0fSByZXBlYXQge1xzbCBsb29wQm9keX0K
K2ZvciB7XHNsIHZhcn0gaW4ge1xzbCBzZWd9IFx0ZXh0YmFyXCB7XHNsIEJvb2xFeHByfSByZXBl
YXQge1xzbCBsb29wQm9keX1cXAorZm9yIHtcc2wgdmFyfSBpbiB7XHNsIGxpc3R9IFx0ZXh0YmFy
XCB7XHNsIEJvb2xFeHByfSByZXBlYXQge1xzbCBsb29wQm9keX0KIFxlbmR7Y2VudGVyfQogV2Ug
Y2FuIGl0ZXJhdGUgb3ZlciBhIHNlZ21lbnQKIFxiZWdpbnt2ZXJiYXRpbX0KQEAgLTQ2NzIsNyAr
NDY3Miw3IEBAICQkCiAkJAogXHJldHVyblR5cGV7VHlwZTogRnJhY3Rpb24gSW50ZWdlcn0KIAot
VG8gZmFjdG9yIGZyYWN0aW9ucywgeW91IGhhdmUgdG8gcG1hcCB7XGJmIGZhY3Rvcn0gb250byB0
aGUgbnVtZXJhdG9yCitUbyBmYWN0b3IgZnJhY3Rpb25zLCB5b3UgaGF2ZSB0byBtYXAge1xiZiBm
YWN0b3J9IG9udG8gdGhlIG51bWVyYXRvcgogYW5kIGRlbm9taW5hdG9yLgogCiBcaW5kZXh7bWFw
fQpAQCAtNTI0NSw3ICs1MjQ1LDcgQEAgcmV0dXJucyB0aGUgbWF4aW11bSBlbGVtZW50IG9mIHRo
ZSBoZWFwLCBhZnRlciBkZXN0cnVjdGl2ZWx5IHJlbW92aW5nCiB0aGF0IGVsZW1lbnQgYW5kIHJl
b3JnYW5pemluZyB0aGUgaGVhcCBzbyB0aGF0IHRoZSBuZXh0IG1heGltdW0KIGVsZW1lbnQgaXMg
cmVhZHkgdG8gYmUgZGVsaXZlcmVkLgogCi1BbiBlYXN5IHdheSB0byBjcmVhdGUgYSBoZWFwIGlz
IHRvIGFwcGx5IHRoZSBvcGVyYXRpb24ge1xpdCBoZWFwfQorQW4gZWFzeSB3YXkgdG8gY3JlYXRl
IGEgaGVhcCBpcyB0byBhcHBseSB0aGUgb3BlcmF0aW9uIHtcYmYgaGVhcH0KIHRvIGEgbGlzdCBv
ZiB2YWx1ZXMuCiBcaW5kZXh7aGVhcH0KIFxzcGFkY29tbWFuZHtoIDo9IGhlYXAgWy00LDcsMTEs
Myw0LC03XX0KQEAgLTUzMTgsNyArNTMxOCw3IEBAIGNvcnJlc3BvbmRpbmcgc3RydWN0dXJlIGxp
a2Ugc3RyZWFtcyBmb3IgaW5maW5pdGUgY29sbGVjdGlvbnMuCiBDcmVhdGUgc2V0cyB1c2luZyBi
cmFjZXMgYGBce2BgIGFuZCBgYFx9JycgcmF0aGVyIHRoYW4gYnJhY2tldHMuCiAKIFxpbmRleHtz
ZXR9Ci1cc3BhZGNvbW1hbmR7ZnMgOj0gc2V0WzEvMyw0LzUsLTEvMyw0LzVdfQorXHNwYWRjb21t
YW5ke2ZzIDo9IHNldCBbMS8zLDQvNSwtMS8zLDQvNV19CiAkJAogXGxlZnRcewogLXsxIFxvdmVy
IDN9LCAgezEgXG92ZXIgM30sICB7NCBcb3ZlciA1fSAK
--001636ed67822270a1047b0d51ef--

\start
Date: Sat, 19 Dec 2009 10:19:29 -0500
From: Tim Daly
To: Lee Duhem
Subject: Re: [PATCH] Fix some typo and formatting problems in books/bookvol0.pamphlet and books/bookvol1.pamphlet

Lee Duhem wrote:
> Hi,
>
> I have found some typo and formatting problems in
> books/bookvol0.pamphlet and books/bookvol1.pamphlet,
> this is the fix. You may want take a look.
>
> lee

Lee,

Thanks for the patches. They have been applied.
I also added 2 new sections and cleaned up the dangling
references. The changes should be available after the next
system build.

\start
Date: Sun, 20 Dec 2009 00:12:08 +0800
From: Lee Duhem
To: Tim Daly
Subject: Re: [PATCH] Fix some typo and formatting problems in books/bookvol0.pamphlet and books/bookvol1.pamphlet

On Sat, Dec 19, 2009 at 11:19 PM, Tim Daly wrote:
> Lee,
> Thanks for the patches. They have been applied.

I'm glad that I can help.

\start
Date: Sun, 20 Dec 2009 00:48:56 +0800
From: Lee Duhem
To: Tim Daly
Subject: Re: [PATCH] Fix some typo and formatting problems in books/bookvol0.pamphlet and books/bookvol1.pamphlet

On Sat, Dec 19, 2009 at 11:19 PM, Tim Daly wrote:
> Lee,
> Thanks for the patches. They have been applied.

BTW, there are two typo fixes lost in the applied patches.

lee

--0016368e230edccc8f047b17a165

ZGlmZiAtLWdpdCBhL2Jvb2tzL2Jvb2t2b2wwLnBhbXBobGV0IGIvYm9va3MvYm9va3ZvbDAucGFt
cGhsZXQKaW5kZXggYmUzZDI4OC4uNDUwOTgwNiAxMDA2NDQKLS0tIGEvYm9va3MvYm9va3ZvbDAu
cGFtcGhsZXQKKysrIGIvYm9va3MvYm9va3ZvbDAucGFtcGhsZXQKQEAgLTE2NDIsNyArMTY0Miw3
IEBAIEdpdmVuIHRoYXQgd2UgY2FuIGRlZmluZSBleHByZXNzaW9ucyBpbnZvbHZpbmcgc3ltYm9s
cywgaG93IGRvIHdlIGFjdHVhbGx5CiBjb21wdXRlIHRoZSByZXN1bHQgd2hlbiB0aGUgc3ltYm9s
cyBhcmUgYXNzaWduZWQgdmFsdWVzPyBUaGUgYW5zd2VyIGlzIHRvCiB1c2UgdGhlIHtcYmYgZXZh
bH0gZnVuY3Rpb24gd2hpY2ggdGFrZXMgYW4gZXhwcmVzc2lvbiBhcyBpdHMgZmlyc3QgYXJndW1l
bnQKIGZvbGxvd2VkIGJ5IGEgbGlzdCBvZiBhc3NpZ25tZW50cy4gRm9yIGV4YW1wbGUsIHRvIGV2
YWx1YXRlIHRoZSBleHByZXNzaW9ucwote1xiZiBYRHVtbXl9IGFuZCB7XGJmIHh5RHVtbXl9IHJl
c3VsdGluZyBmcm9tIHRoZWlyIHJlc3BlY3RpdmUgYXNzaWdubWVudHMgCit7XHNsIHhEdW1teX0g
YW5kIHtcc2wgeHlEdW1teX0gcmVzdWx0aW5nIGZyb20gdGhlaXIgcmVzcGVjdGl2ZSBhc3NpZ25t
ZW50cyAKIGFib3ZlIHdlIHR5cGU6CiAKIFxzcGFkY29tbWFuZHtldmFsKHhEdW1teSx4PTMpfQpk
aWZmIC0tZ2l0IGEvYm9va3MvYm9va3ZvbDEucGFtcGhsZXQgYi9ib29rcy9ib29rdm9sMS5wYW1w
aGxldAppbmRleCA1MjgxMDk4Li4yOTYyYzRlIDEwMDY0NAotLS0gYS9ib29rcy9ib29rdm9sMS5w
YW1waGxldAorKysgYi9ib29rcy9ib29rdm9sMS5wYW1waGxldApAQCAtMjE2Niw3ICsyMTY2LDcg
QEAgR2l2ZW4gdGhhdCB3ZSBjYW4gZGVmaW5lIGV4cHJlc3Npb25zIGludm9sdmluZyBzeW1ib2xz
LCBob3cgZG8gd2UgYWN0dWFsbHkKIGNvbXB1dGUgdGhlIHJlc3VsdCB3aGVuIHRoZSBzeW1ib2xz
IGFyZSBhc3NpZ25lZCB2YWx1ZXM/IFRoZSBhbnN3ZXIgaXMgdG8KIHVzZSB0aGUge1xiZiBldmFs
fSBmdW5jdGlvbiB3aGljaCB0YWtlcyBhbiBleHByZXNzaW9uIGFzIGl0cyBmaXJzdCBhcmd1bWVu
dAogZm9sbG93ZWQgYnkgYSBsaXN0IG9mIGFzc2lnbm1lbnRzLiBGb3IgZXhhbXBsZSwgdG8gZXZh
bHVhdGUgdGhlIGV4cHJlc3Npb25zCi17XHNsIFhEdW1teX0gYW5kIHtcc2wgeHlEdW1teX0gcmVz
dWx0aW5nIGZyb20gdGhlaXIgcmVzcGVjdGl2ZSAKK3tcc2wgeER1bW15fSBhbmQge1xzbCB4eUR1
bW15fSByZXN1bHRpbmcgZnJvbSB0aGVpciByZXNwZWN0aXZlIAogYXNzaWdubWVudHMgYWJvdmUg
d2UgdHlwZToKIAogXGluZGV4e2V2YWx9Cg==
--0016368e230edccc8f047b17a165--

\start
Date: Sun, 20 Dec 2009 05:47:06 -0500
From: Tim Daly
To: Lee Duhem
Subject: Re: [PATCH] Fix some typo and formatting problems in books/bookvol0.pamphlet and books/bookvol1.pamphlet

Lee Duhem wrote:
> On Sat, Dec 19, 2009 at 11:19 PM, Tim Daly wrote:
>   
>> Lee,
>> Thanks for the patches. They have been applied.
>>     
>
> BTW, there are two typo fixes lost in the applied patches.
>
> lee
>   

Fixed. Thanks.
I also applied your patches to the HTML version of the book.

\start
Date: Tue, 29 Dec 2009 11:18:14 -0500
From: Tim Daly
To: list
Subject: [Fwd: ITP 2010 - Third Call for Papers]

-------- Original Message --------

                          Call for Papers
        ITP 2010: Conference on Interactive Theorem Proving
                11-14 July 2010, Edinburgh, Scotland
             http://www.floc-conference.org/ITP-cfp.html

                               -----

ITP brings together researchers working in all areas of interactive
theorem proving.  It combines the communities of two venerable
meetings: the TPHOLs conference and the ACL2 workshop.  The inaugural
meeting of ITP will be held on 11-14 July 2010 in Edinburgh, Scotland,
as part of the Federated Logic Conference (FLoC, 9-21 July 2010),
co-located with the other FLoC conferences (CAV, ICLP, IJCAR, LICS,
RTA, SAT) and workshops.

The program committee welcomes submissions on all aspects of
interactive theorem proving and its applications.  Examples of typical
topics include formal aspects of hardware or software (specification,
verification, semantics, synthesis, refinement, compilation, etc.);
formalization of significant bodies of mathematics; advances in
theorem prover technology (automation, decision procedures, induction,
combinations of systems and tools, etc.); other topics including those
relating to user interfaces, education, comparisons of systems, and
mechanizable logics; and concise and elegant worked examples ("Proof
Pearls").

Submission details:

All papers must be submitted electronically, via EasyChair:

 http://www.easychair.org/conferences/?conf=itp10

Papers may be no longer than 16 pages and are to be submitted in PDF
using the Springer "llncs" format.  Instructions may be found at
ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/instruct/authors/typeinst.pdf
with Latex source file typeinst.tex in the same directory.
Submissions must describe original unpublished work not submitted for
publication elsewhere, presented in a way that users of other systems
can understand.  The proceedings will be published as a volume in the
Lecture Notes in Computer Science series and will be available to
participants at the conference.

In addition to regular submissions, described above, there will be a
"rough diamonds" section.  Rough diamond submissions are limited to
four pages and may consist of an extended abstract.  They will be
refereed: they will be expected to present innovative and promising
ideas, possibly in an early form and without supporting evidence.
Accepted diamonds will be published in the main proceedings.  They
will be presented at the conference venue in a poster session.

Authors of accepted papers are expected to present their papers at the
conference, and will be required to sign copyright release forms. 
All submissions must be written in English.

Important dates (midnight GMT):

 Abstract submission deadline:         15 January 2010
 Paper submission deadline:            22 January 2010
 Notification of paper decisions:        15 March 2010
 Camera-ready papers due from authors:    9 April 2010
 Conference dates:                     11-14 July 2010

Web page:

 http://www.floc-conference.org/ITP-cfp.html

Conference co-chairs:

 Matt Kaufmann, University of Texas at Austin, USA
 Larry Paulson, University of Cambridge, United Kingdom

Program Committee:

 Thorsten Altenkirch, Nottingham University, United Kingdom
 David Aspinall, Edinburgh University, United Kingdom
 Jeremy Avigad, Carnegie Mellon University, USA
 Gilles Barthe, IMDEA, Spain
 Jens Brandt, University of Kaiserslautern, Germany
 Thierry Coquand, Chalmers University, Sweden
 Ruben Gamboa, University of Wyoming, USA
 Georges Gonthier, Microsoft Research, United Kingdom
 David Greve, Rockwell Collins Inc., USA
 Elsa Gunter, University of Illinois at Urbana-Champaign, USA
 John Harrison, Intel Corporation, USA
 Joe Hurd, Galois Inc., USA
 Matt Kaufmann, University of Texas at Austin, USA
 Gerwin Klein, NICTA, Australia
 Xavier Leroy, INRIA, France
 Assia Mahboubi, INRIA, France
 Panagiotis Manolios, Northeastern University, USA
 John Matthews, Galois Inc., USA
 J Moore, University of Texas at Austin, USA
 Cesar Munoz, NASA, USA
 Tobias Nipkow, TU Muenchen, Germany
 Michael Norrish, NICTA, Australia
 David Pichardie, INRIA Rennes, France
 Brigitte Pientka, McGill University, Canada
 Lee Pike, Galois Inc., USA
 Sandip Ray, University of Texas at Austin, USA
 Jose Luis Ruiz-Reina, Universidad de Sevilla, Spain
 Larry Paulson, University of Cambridge, United Kingdom
 David Russinoff, Advanced Micro Devices Inc., USA
 Peter Sewell, University of Cambridge, United Kingdom
 Konrad Slind, Rockwell Collins Inc., USA
 Sofiene Tahar, Concordia University, Canada
 Christian Urban, TU Muenchen, Germany

Workshop Chair:

 Michael Norrish, NICTA, Australia

Local Arrangements:

 David Aspinall, Edinburgh University, United Kingdom





