\documentclass{book}
%\newcommand{\VolumeName}{Volume 2: Axiom Users Guide}
%\input{bookheader.tex}
\pagenumbering{arabic}
\mainmatter
\setcounter{chapter}{0} % Chapter 1

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Fri, 01 Apr 2005 04:58:07 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [recurrence relation operator] (nouveau) 

Here is a simple implemention of a recurrence relation operator. It is far 
from finished, but might serve as a starting point. I experienced the following 
difficulties:

 - The operator model in Axiom is quite restrictive: all arguments have to be 
   from the same domain. This leads to problems elsewhere, too. I don't think 
   that the following can be justified mathematically:

\begin{axiom}
sum(k,k=1.0..2.5)
\end{axiom}

  - dummy variables are only supported in a very limited fashion: for the 
    recurrence relation operator it would be good to have also "dummy operators"...

Things to 
do:

  - a proper operation analogous to 'sum', 'rootOf' or the like needs to be written.
    The operation 'evalRec' is just for a start

  - evalRec needs to be speeded up

\begin{axiom}
)abbrev package RECOP RecurrenceOperator
RecurrenceOperator(R, F): Exports == Implementation where
  R: Join(OrderedSet, IntegralDomain, RetractableTo Integer)
  F: FunctionSpace R

  Exports == with

    evalRec: (BasicOperator, Symbol, F, F, F, List F) -> F

  Implementation == add

    ddrec: List F -> OutputForm
    ddrec l ==
      k := kernels(l.4)
      op := operator(k.1)::OutputForm
      values := reverse l

      vals: List OutputForm
           := cons(elt(op, [(l.3)::OutputForm]) = eval(l.1, l.2, l.3)::OutputForm,
                   [elt(op, [i::OutputForm]) = (values.i)::OutputForm
                    for i in 1..#values-4])

      bracket(hconcat([operator(k.1)(l.3)::OutputForm,
                       ": ",
                       commaSeparate vals]))


    oprecur := operator("rootOfRec"::Symbol)$BasicOperator

    setProperty(oprecur, "%specialDisp", 
                ddrec@(List F -> OutputForm) pretend None)

    setProperty(oprecur, "%dummyVar", 2 pretend None)

-- this implies that the second and third arguments of oprecur are dummy
-- variables and affects tower$ES:
-- the second argument will not appear in tower$ES, if it does not appear in
-- any argument but the first and second.
-- the third argument will not appear in tower$ES, if it does not appear in any
-- other argument. (%defsum is a good example)

-- The arguments of rootOfRec are as follows:
-- 1. next, i.e., f(dummy+1)
-- 2. dummy
-- 3. variable, i.e., for display              
-- 4. operatorname(argument)
-- 5.- values in reversed order
-- maybe "values" should be preceded by the index of the first given
-- value. Currently, the last value is interpreted as f(1)

    evalRec (op, argsym, argdisp, arg, next, values) ==
      if ((n := retractIfCan(arg)@Union(Integer, "failed")) case "failed")
         or (n < 1)
      then
        kernel(oprecur, 
               append([next, argsym::F, argdisp, op(arg)], values))
      else 
        len := #values
        if n <= len
        then values.(len-n+1)
        else
          nextval := eval(next, argsym::F, (len+1)::F)
          newval := eval(nextval, op, 
                         evalRec(op, argsym, argdisp, #1, next, values))
          evalRec(op, argsym, argdisp, arg, next, cons(newval, values))

    irecur: List F -> F
-- This is just a wrapper that allows us to write a recurrence relation as an
-- operator.
    irecur l ==
      k := kernels(l.4)
      evalRec(operator(k.1),
              retract(l.2)@Symbol, l.3,
              argument(k.1).1, l.1, rest(l, 4))

    evaluate(oprecur, irecur)$BasicOperatorFunctions1(F)
\end{axiom}

Here is an example:

\begin{axiom}
argsym := new()$Symbol;
argexp := argsym::Expression Integer;
op := operator new()$Symbol;
ne := elt(op, argexp - 1) + elt(op, argexp - 2::Expression Integer);
r:=evalRec(op, argsym, a::Expression Integer, a::Expression Integer, ne, [1,1])
         $RecurrenceOperator(Integer, Expression Integer)
eval(r, a=7)
\end{axiom}

\start
Date: Fri, 01 Apr 2005 05:43:59 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [RationalInterpolation] 

    contains something useful. In particular, in my package [Guess],
    in 'guessRat' and 'guessExpRat' I generate interpolating
    polynomials for all possible degrees of numerator and
    denominator. The above article contains an algorithm that does
    this in time $O(n^2)$, which would be quite nice. Currently, I
    need $O(n^2)$ operations for *each* degree!

    only $O(n\log(n)^2\log\log(n))$ operations. It can be found in van
    zur Gathen's book "Modern computer algebra", chapter 10.

\start
Date: Fri, 01 Apr 2005 16:59:20 -0600
From: MathAction (unknown)
To: MathAction
Subject: [#138 asin(complex(1.0,0.0))] 

This and the log(i)-log(-i) bug can be fixed by using GCL's asin and log here.  I tried 

     if $ has Field and $ has sqrt: $ -> $ then
--       asin x == atan(x/sqrt(1-x**2))
       asin x == ASIN(COMPLEX(real x,imag x)$Lisp)$Lisp

but the form of x when complex in axiom is not that of lisp, i.e. asin gets passed a non-number:

   >> System error:
   ((1 . 0) 0 . 0) is not of type NUMBER.


In general, I think it a good idea to avoid having to duplicate the functionality of the standard lisp functions in axiom, but there may be some philosophical reason for doing this due to the domain structures or some such.  If one needs the correct logic for a duplicate implementation, one can look at the gcl_numlib.lsp file in the lsp/ subdirectory.

\start
Date: Fri, 01 Apr 2005 18:10:50 -0600
From: MathAction (unknown)
To: MathAction
Subject: [#138 asin(complex(1.0,0.0))] ...

No, here it is a Complex(Float), the implementation of float allow arbitrary precision, Common Lisp no.
Morever, it'a generic implementation (in a category)

\start
Date: Fri, 01 Apr 2005 20:11:51 -0600
From: MathAction (unknown)
To: MathAction
Subject: [#138 asin(complex(1.0,0.0))] 

OK, then what we want is something like:

       asin x == - %i * log( %i * x + sqrt(1 - x*x))

but this does not appear to be used when put into trigcat.spad.pamphlet and recompiling.  Perhaps someone could explain?

Secondly, perhaps ist is of use to bring forward GMP/mpfr optimized multi-precision floating point in GCL for use by axiom here?

I understand the multi-precision argument, but is there a difference between a 'generic imlementation' and the lisp one where the category of the domain coincides precisely with the lisp type?

Lastly, do we have to use this difficult interface as opposed to the developer email list?

\start
Date: Fri, 01 Apr 2005 20:48:10 -0600
From: MathAction (unknown)
To: MathAction
Subject: [#138 asin(complex(1.0,0.0))] ...

'take care' ... Yes I think it's a good idea to add mpfr to gcl
<br />
Regards

\start
Date: Sat, 02 Apr 2005 03:21:46 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#138 asin(complex(1.0,0.0))] 

I believe furthermore, that the problem with 'argument' as described in bug #47 will persist if we fix it this way.

I think that a lot of care has to be taken if we use Lisp functions instead of "homegrown" ones.

Concerning the place of discussion: I too think that it would be better to:

  - ask on axiom-developer whether it is really an issue, if this is not clear
  - signal the issue on IssueTracker
  - discuss it on axiom-developer
  - add proposed fixes on IssueTracker.

Since any change on IssueTracker will notify axiom-developer, there is no danger of missing anything.

\start
Date: Sat, 02 Apr 2005 04:07:14 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#138 asin(complex(1.0,0.0))] 

I think that the following definition would 
work::

       asin x == if x = 1 then pi()/2::$ else atan(x/sqrt(1-x**2))

There is one thing that puzzles me, though. Also in 'TRANFUN', the following definition is given for 'pi()'::

       pi()   == 2*asin(1)

which seems to be asking for trouble. However, I couldn't find a domain that would use this definition for 'pi()'. Maybe it should be rather defined in terms of 'atan'?

\start
Date: Sat, 02 Apr 2005 08:13:27 -0600
From: MathAction (unknown)
To: MathAction
Subject: [recurrence relation operator] 

  *  I don't think that the following can be justified mathematically:

\begin{axiom}
sum(k,k=1.0..2.5)
\end{axiom}

In the absence of a delta, what do you expect? Axiom simply apply the general formula for

\begin{axiom}
sum(k,k=1..n)
subst(%,n=2.5)
\end{axiom}

\start
Date: Sat, 02 Apr 2005 11:44:11 -0600
From: MathAction (unknown)
To: MathAction
Subject: [#141 atan(tan(3)) => 3] ElementaryFunction

It's iatan in ElementaryFunction
\begin{axiom}
)tr EF_;iatan
atan(tan(3))
\end{axiom}

\start
Date: Sat, 2 Apr 2005 21:10:44 -0500
From: Tim Daly
To: list
Subject: April 2005 release

The April 2005 release of Axiom is up on the servers:

http://page.axiom-developer.org/zope/mathaction/AxiomDownload (files)
http://sourceforge.net/projects/axiom (CVS and files)
http://savannah.nongnu.org/projecs/axiom (CVS)

The current arch version is --patch-32 but is about to be open for
changes for the May release. Explicitly ask for 
  tla get axiom--main--1--patch-32
if you want the April release code.

The main changes are a move from GCL-2.6.5 to GCL-2.6.6,
new documentation for some domains, and fixes to C compile
time warnings.

Significant time has been spent getting the Axiom conference organized.
Hope to see some of you there. (http://www.caissny.org)
There will be a sprint day before the actual conference where we will
discuss future directions followed by cleanup work on open Issues.


The CHANGELOG reads:

20050320 tpd --patch-32
20050320 tpd Makefile revert VERSION to 3.4
20050320 tpd src/input/Makefile add ALGEBRA variable for documentation tests
20050320 tpd src/algebra/numtheory.spad build test case for INTHEORY
20050320 tpd src/algebra/Makefile add test case for INTHEORY
20050320 tpd src/Makefile make int/input directory during algebra step
20050320 tpd src/algebra/numtheory.spad document INTHEORY/chineseRemainder
20050320 tpd src/algebra/numtheory.spad document INTHEORY/inverse
20050318 tpd lsp/gcl-2.6.6/cmpnew/gcl_cmpflet.lsp redo tail-recursive patch
20050318 tpd src/lib/cfuns-c.c in make_path_from_file, initialize pos
20050318 tpd src/lib/wct.c coerce pwct->fsize to int in skim1Wct
20050318 tpd src/lib/sockio-c.c initialize code to -1
20050318 tpd src/lib/pixmap.c remove attr, xireturn unused variables
20050318 tpd Makefile latex fixes
20050318 tpd Makefile add <<GCLOPTS-LOCBFD>>
20050318 tpd src/hyper/Makefile Issue #125 htadd bare fixed
20050318 tpd --patch-31
20050314 tpd gcl-2.6.6.h.linux.h.patch add run-process to GCL
20050314 tpd zip/ccl.tgz added
20050314 tpd src/algebra/Makefile reduce build noise
20050314 tpd Makefile change VERSION to "Axiom 5.4 (April 2005)"
20050314 tpd lsp/Makefile handle gcl-2.6.6
20050314 tpd zips/gcl-2.6.6.tgz added
20050213 tpd Makefile change the VERSION string to March 2005
20050213 tpd src/interp/nocompil.lisp #+:ccl protected-symbol-warn msg
20050213 tpd bug 89 Types in the full book fixed

\start
Date: Sat, 2 Apr 2005 21:16:02 -0500
From: Tim Daly
To: Bill Page
Subject: AxiomDownload

Bill, on 

http://page.axiom-developer.org/zope/mathaction/AxiomDownload 

The page links used to read something like:

http:Mirror?go=http://.......

When you clicked on those links you ended up going to "BigMirrors.com".
I changed these links. But I suspect I might have broken something 
thru a lack of understanding. 

In any case, I thought I'd mention it.

\start
Date: Sat, 02 Apr 2005 21:51:32 -0500
From: Bill Page
To: Tim Daly
Subject: Re: AxiomDownload

Tim,

The links like

 http:Mirror?go=http://...

are intended to lead to a page on MathAction called Mirror.
That page contains a solicitation to people who download
something to contribute something in return and then let
them pass with one more click to complete the download.
When I implemented this last week it seemed to be working
fine for me using both the FireFox and Microsoft explorer
browsers on Windows and FireFox on linux.

I have no idea what "bigMirrors.com" is but this may be
happening because of a limitation of the browser that you
are using. What browser are you using??

A link like "http:Mirror" is supposed to be relative to the
page on which it is located, so it should be interpreted as
a page on the same server, ie. MathAction. But I do vaguely
recall that some old browser versions did not do this
correctly.

I have reverted the links to refer to the MathAction Mirror
page again, but this time I wrote out the full absolute url
so it should work no matter what  version of browser you
are using.

Let me know if this still is not working for you.

BTW: Thanks for your work on the April release!

Cheers,
Bill Page.


root wrote:

>Bill, on 
>
>http://page.axiom-developer.org/zope/mathaction/AxiomDownload 
>
>The page links used to read something like:
>
>http:Mirror?go=http://.......
>
>When you clicked on those links you ended up going to "BigMirrors.com".
>I changed these links. But I suspect I might have broken something 
>thru a lack of understanding. 
>
>In any case, I thought I'd mention it.

\start
Date: Sat, 02 Apr 2005 22:03:17 -0500
From: William Sit
To: Tim Daly
Subject: hyperdoc source links are often wrong

Tim:

The hyperdoc and )show commands associate the source file of a package with
abbreviation xxx to xxx.spad.  This is not correct and sometimes the xxx is not
even close to the correct file name. Please note that one spad file may contain
many domains and packages. So most clicks in hyperdoc on the source file results
in file not found and it is a guessing game what the right file is.

An example is SOLVETRA package where the spad file is
transsolve.spad; another is EF where the file is elemntry.spad.
The NAG version is correct, so something in the OpenSource version is
responsible for the change.

Thanks for the April release.

\start
Date: Sun, 3 Apr 2005 00:25:04 -0300
From: Henry Lenzi
To: list
Subject: Axiom does not configure/build on OpenBSD

Hello ---

 Axiom fail to configure and build on OpenBSD.
 AFAIK, OpenBSD would have all the requirements, with the exception of
GCL, which is a Lisp build from C code (so it should be no problem
/and/ its included in Axiom anyways): gcc, GNUMake, etc. It's even
possible to have Linux emulation (with RedHat 8.0 binaries, as of now,
or FreeBSD 4.0 library emulation).
 I'm not yet a good Unix, just a newbie, but from what I've seen, you
make too much assumptions about a Linux system, instead of just
assuming Unix (a bigger set, include Linux).
 Why does the configure script, for instance, bork with a Unix that's
not one of those included? I don't see anything in the Makefile that
implies that using system() is a necessary condition. I might be
wrong, though :-)
 I would like to help having Axiom on yet-another-open-source-unix, a
BSD at least. I like OpenBSD. It's a very secure system, very well
programmed (fewer mistakes in C than average) and it's growing in
packages and ports of applications. What can I do to help?

\start
Date: Sat, 02 Apr 2005 22:29:13 -0500
From: Bill Page
To: William Sit
Subject: Re: hyperdoc source links are often wrong

William and Tim,

The problem to which William is referring is caused by
the way Tim has re-organized the original *.spad source
files into *.spad.pamphlet files. The mapping is many-to-
one where there used to be 1000+ *.spad files there are
now only 300+ *.spad.pamphlet files. The new OpenSource
makefile extracts the individual *.spad files as intermediate
files as needed by the rest of the build, but these are not
the ones passed on to the 'mnt' release directory. Instead
the current makefile extracts the merged *.spad.pamphlet
files and calls them *.spad files in the 'mnt' directory,
but these correspond to the 300+ *.spad.pamphlet files
not the 1000+ original *.spad files. I agree that the fact
that these appear with the suffix ".spad" is confusing because
the names because these are not the original *.spad
files.

I think one reason that Tim may have done that was to keep
these source files in sync with the corresponding *.dvi
documentation files - that is a good thing. But unfortunately
it breaks Axiom's original method of referring to the
appropriate source.

Perhaps the *.spad files extracted as intermediate files
could just be copied into the 'mnt' directory instead of
the re-packaged versions. That would at least make Axim
work the way it used to. But in the new system of
code+documentation in pamphlet files really one is not
supposed to be editing the *.spad files directly, rather it
is the pamphlet file that is should to be changed - both
code and associated documentation.

So I suppose really Axiom should be supplying the new
*.spad.pamphlet file names. This might be a little difficult
since currently Axiom itself does not understand the
mapping of spad to pamphlet files. I think that something
would have to be changed in the Axiom database files.

Regards,
Bill Page.

William Sit wrote:

>Tim:
>
>The hyperdoc and )show commands associate the source file of a package with
>abbreviation xxx to xxx.spad.  This is not correct and sometimes the xxx is not
>even close to the correct file name. Please note that one spad file may contain
>many domains and packages. So most clicks in hyperdoc on the source file results
>in file not found and it is a guessing game what the right file is.
>
>An example is SOLVETRA package where the spad file is
>transsolve.spad; another is EF where the file is elemntry.spad.
>The NAG version is correct, so something in the OpenSource version is
>responsible for the change.
>
>Thanks for the April release.

\start
Date: Sun, 3 Apr 2005 00:36:30 -0500
From: Tim Daly
To: Bill Page
Subject: Re: AxiomDownload

Bill,

The absolute URL version works.

\start
Date: Sun, 03 Apr 2005 03:57:09 -0400
From: William Sit
To: Bill Page
Subject: Re: hyperdoc source links are often wrong

Dear Bill:

Thanks for your comments. 

Perhaps it's a good idea to associate each constructor with its own
spad file, but I am not convinced. Historically, I believe that is not
the case. Many authors write one large spad file containing multiple
constructors (related, of course) -- one reason may be to save
duplication of macros. It is also easier to follow a constructor if
related ones are nearby. When extracting spad files for individual
constructors, care should be taken to include all global macros in the
file.

The old (NAG) hyperdoc is able to jump to the constructor even though
there may be several in the same file, much like the local html
name=xx and #xx references. This feature is no longer available in the
new hyperdoc (at least until the files are broken up, which kind of
defeats the purpose of Tim's reorganization). So perhaps a solution
would be that the hyperdoc links are not file names, but are global
name tags, by which the location of a constructor (file and tag) can
be obtained from a database or table.

\start 
Date: Sun, 03 Apr 2005 09:05:04 -0500 
From: MathAction (anonymous) 
To: MathAction 
Subject: [#144 Domain abbreviation is no longer associated with filename] 

The hyperdoc and )show commands associate the source file of a package
with abbreviation xxx to xxx.spad.  This is not correct and sometimes
the xxx is not even close to the correct file name. Please note that
one spad file may contain many domains and packages. So most clicks in
hyperdoc on the source file results in file not found and it is a
guessing game what the right file is.

An example is SOLVETRA package where the spad file is
transsolve.spad; another is EF where the file is elemntry.spad.
The NAG version is correct, so something in the OpenSource version is
responsible for the change.

\start
Date: Sun, 3 Apr 2005 10:46:46 -0400
From: Tim Daly
To: William Sit
Subject: Re: hyperdoc source links are often wrong

Yes, I'm aware of the problem and its cause. I've added Issue #144 to
IssueTracker.

The problem is that previously the compiler compiled all of the files
in a file (containing many domains) and created individual domains. 
Now the compiler is invoked on the individual domains in the file. 

\start
Date: Sun, 3 Apr 2005 11:02:26 -0400
From: Tim Daly
To: Henry Lenzi
Subject: Re: Axiom does not configure/build on OpenBSD
Cc: Charles Miller

Henry,

>  Axiom fail to configure and build on OpenBSD.

Yes, that's true. In fact at the moment Axiom will not build on any
of the BSD systems.

>  AFAIK, OpenBSD would have all the requirements, with the exception of
> GCL, which is a Lisp build from C code (so it should be no problem
> /and/ its included in Axiom anyways): gcc, GNUMake, etc. It's even
> possible to have Linux emulation (with RedHat 8.0 binaries, as of now,
> or FreeBSD 4.0 library emulation).

Well, there is no such thing as a simple job. It only takes one simple
difference to stop the build which consists of thousands of steps. Even
a 1 character difference in a file (SIGCHLD vs SIGCLD) causes the build
to fail. 

>  I'm not yet a good Unix, just a newbie, but from what I've seen, you
> make too much assumptions about a Linux system, instead of just
> assuming Unix (a bigger set, include Linux).

Since I don't have a BSD system I can use I'm working blind and
depend on others for fixes.

>  Why does the configure script, for instance, bork with a Unix that's
> not one of those included? I don't see anything in the Makefile that
> implies that using system() is a necessary condition. I might be
> wrong, though :-)

The configure script is written to figure out options on systems where
Axiom can run. It is a hard problem to write system-dependent code (such
as figuring out the system name, version, and release) on a system that
Axiom has never seen.

>  I would like to help having Axiom on yet-another-open-source-unix, a
> BSD at least. I like OpenBSD. It's a very secure system, very well
> programmed (fewer mistakes in C than average) and it's growing in
> packages and ports of applications. What can I do to help?

There are 3 people who have expressed an interest in *BSD systems:
Chuck Miller Charles Miller  (BSD on the MAC OSX)
Pierre Doucy (BSD on the MAC OSX)
Mark Murray  Mark Murray       (FreeBSD)

Visit http://arch.axiom-developer.org, follow the instructions under
"If you need write access to the archive" (toward the bottom of the page)
and become an active developer.

If you don't want to be a developer you can help by trying to build Axiom,
sending the failing console output to this list, and either suggesting
fixes or testing fixes I suggest. This effectvely makes you my remote
hand and eyes. It's a slow process and requires a lot of patience but it
is still an effective way to work. 

You can also be very effective by posting good bug reports on IssueTracker
http://page.axiom-developer.org/zope/mathaction/IssueTracker

Mark Murray has sent me a whole set of changes for FreeBSD, most of which
I have merged into the version of the system planned for the May target.
The hope is to get the system able to build on FreeBSD by then. 

\start
Date: Sun, 3 Apr 2005 11:14:31 -0400
From: Tim Daly
To: William Sit
Subject: Re: hyperdoc source links are often wrong

> Perhaps it's a good idea to associate each constructor with its own
> spad file, but I am not convinced. Historically, I believe that is not
> the case. Many authors write one large spad file containing multiple
> constructors (related, of course) -- one reason may be to save
> duplication of macros. It is also easier to follow a constructor if
> related ones are nearby. When extracting spad files for individual
> constructors, care should be taken to include all global macros in the
> file.

In many cases it is not possible to split the individual spad files into
a one-[domain|package|category]-per-file, at least not with the current
algebra organization.

> The old (NAG) hyperdoc is able to jump to the constructor even though
> there may be several in the same file, much like the local html
> name=xx and #xx references. This feature is no longer available in the
> new hyperdoc (at least until the files are broken up, which kind of
> defeats the purpose of Tim's reorganization). So perhaps a solution
> would be that the hyperdoc links are not file names, but are global
> name tags, by which the location of a constructor (file and tag) can
> be obtained from a database or table.

This is not a hard problem to fix but it just takes time.

Time has been severely limited because I no longer work on Axiom in work.
Since February Axiom has been a strictly off-hours effort. This impacted
the March release (there was none) but I've gotten my development work
back on track.

\start
Date: Sun, 3 Apr 2005 11:05:55 -0400
From: Tim Daly
To: Bill Page
Subject: Re: hyperdoc source links are often wrong

> So I suppose really Axiom should be supplying the new
> *.spad.pamphlet file names. This might be a little difficult
> since currently Axiom itself does not understand the
> mapping of spad to pamphlet files. I think that something
> would have to be changed in the Axiom database files.

Yes, this needs to be done but has not yet been done.
There are other breakages that have to be fixed. For instance,
)compile should accept a pamphlet file and properly update the
documentation as well as compile the file.


\start
Date: Sun, 3 Apr 2005 12:19:17 -0400
From: Tim Daly
To: Henry Lenzi
Subject: Doyen project

Henry,

>  I became interested in Axiom because of a post, by you, in a
> mailing-list, in which you defended the proposition that the gap
> between programming and writing mathematics in paper ought to be
> merged, a "system for 30 years." Extremely interesting and visionary!
>  By the way, may I suggest that you put that mail with your vision
> somewhere in the Axiom site? I think this sets it apart from others
...[snip]...

Look at http://daly.axiom-developer.org/doyen

The Doyen idea is very simple. When you present your paper at a science
conference you give out a URL. Everyone in the audience has a Doyen "Live CD"
that was given out with the conference materials. If they boot the "Live CD"
(it doesn't touch their hard drive so it won't affect their machines)
then they can "drag and drop" your literate paper (which includes the
source code) onto their machine and run your results while you give
your talk.

The means that everyone in the audience has your program as well as
your paper and can reproduce your results. Isn't that the definition
of a science? And it works for every branch of science that uses a
computer.

The Doyen project is actually a generalization of the ideas for Axiom.
It addresses the problem that we, as computational mathematicians, are
not making our fundamental results (programs) available in sharable and
archivable form. I've seen hundreds of presentations where reference is
made to the software that supports results but I can't get or use the 
software. 

\start
Date: Sun, 03 Apr 2005 17:06:21 +0100
From: Mark Murray
To: Tim Daly
Subject: Re: Doyen project 
Cc: Henry Lenzi

root writes:
> The means that everyone in the audience has your program as well as
> your paper and can reproduce your results. Isn't that the definition
> of a science? And it works for every branch of science that uses a
> computer.

It also means that everyone in the audience is reproducing any errors.

Isn't the essence of reproducing an experiment to start with the theory 
and construct the experiment yourself, rather that pushing the "GO" 
button in the original scientist's laboratory?

> The Doyen project is actually a generalization of the ideas for Axiom.
> It addresses the problem that we, as computational mathematicians, are
> not making our fundamental results (programs) available in sharable and
> archivable form. I've seen hundreds of presentations where reference is
> made to the software that supports results but I can't get or use the 
> software. 

I partially agree with this, but access to the original software should 
only really be for checking purposes.

Of course, certain classes of research need to be less stringent on 
this; theoretical compiler design would be an example.

\start
Date: Sun, 03 Apr 2005 15:55:18 -0400
From: Bill Page
To: William Sit
Subject: Re: hyperdoc source links are often wrong

William Sit wrote:

>Perhaps it's a good idea to associate each constructor with it own
 spad file,but I am not convinced. Historically, I believe that is not
 the case. Many authors write one large spad file containing multiple
 constructors (related, of course) -- one reason may be to save
 duplication of macros. It is also easier to follow a constructor if
 related ones are nearby.

I agree. In fact Tim's reorganization from 1000+ *.spad files (some of
which already included multiple constructors) into the 300+
*.spad.pamphlet files effectively combines even more constructors into a
smaller number of (hopefully) logically related groups. I think that for
the most part the original groupings of constructors into spad files is
retained in the <<chunk>> structure of the pamphlet files. But perhaps
in some cases Tim may have also broken some original spad files into
multiple chunks. (Is that right Tim?) In any case, the way the current
build works is that there is a spad file internally created by running
'tangle' for each spad <<chunk>> for the *.spad.pamphlet files. It is
these file names that end up in Axiom's database and show up in hypertex
and in ')show constructor'.

I think it seems mentally and physically more feasible to document some
300 groups of related constructors rather than over a 1000! So mostly
this reorganization is a good thing.

>When extracting spad files for individual constructors, care should
 be taken to include all global macros in the file.

Yes, this is done in the current build process.

>The old (NAG) hyperdoc is able to jump to the constructor even though
 there may be several in the same file, much like the local html
 name=xx and #xx references. This feature is no longer available in
 the new hyperdoc (at least until the files are broken up, which kind
 of defeats the purpose of Tim's reorganization).

I think this happens when ')compile xxx.spad' is called. The file name
xxx.spad is associated in the database with each of the constructors in
the spad file. Unfortunately files with these names only exist
"internally" in the build (i.e. in the 'int' directory) and do not find
their way into the 'mnt' directory.

If the purpose was only to be able to view the spad source without the
associated documentation in the pamphlet file, then I think including
these files in a "read-only" manner in the distribution would probably
not compromise too much the original intention of the re-organization.
But perhaps the temptation to edit these files might prove irresistible :)

>So perhaps a solution would be that the hyperdoc links are not file names, but are global name tags, by which the location of a constructor (file and tag) can be obtained from a database or table.
>  
>
Yes, I think this might be possible. As I said above, these hyperdoc
links are actually associated with the spad <<chunk>> names in the new
*.spad.pamphlet files. In principle it should not be too difficult to
use this information together with both 'tangle' and 'weave' to find the
associated code and documentation. Ideally one might want a text editor
that understands the structure of the pamphlet files and lets you create
both code and documentation in an integrated manner. But failling that,
perhaps we could develope some command line tools to interface with
'notangle' and 'noweave'. Tim already has something like this in the
'document' script.

Maybe hyperdoc can be extended to understand the structure of pamphlet
files so that at least in that context the appropriate code and
documentation could be displayed. (Tim, is that part of your current
re-design of hyperdoc?)

\start
Date: Sun, 03 Apr 2005 15:18:04 -0400
From: Bill Page
To: Tim Daly
Subject: Re: Doyen project
Cc: Henry Lenzi

Tim,

You also have the Doyen page on MathAction

  http://page.axiom-developer.org/zope/mathaction/Doyen

should the contents of your new web page be merged with
this or do you want to keep them separate?

Regards,
Bill Page.

root wrote:

>...[snip]...
>
>Look at http://daly.axiom-developer.org/doyen

\start
Date: Sun, 03 Apr 2005 20:21:53 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#145 piping commands to sman does not work] (new) 

Sending commands to sman via a pipe does not work.

This method is currently used on MathAction and in the TexMacs
interface to send commands to AXIOMsys with no problems. In order
to get Axiom graphics running on MathAction and under TexMacs , we
will need to start sman instead of AXIOMsys in order to setup the
process handling for graphics. But when I try to pipe commands to
sman, even with the -noht -noclef options, sman just issues two
prompts and waits. It does not seem to try to read from stdin. If
I try to key in )quit and yes, etc. there is no reaction and I must
eventually kill the process(es).

\start
Date: Fri, 08 Apr 2005 06:49:06 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#147 axiom-Apr2005-src.tgz fails on fedora 3]	(new) 

After changing my shell to bash, "make" and "make install" report no problems.
But the install script in Makefile needs fixing; it creates the first two lines of the axiom script in the in the wrong order:

  AXIOM=/usr/local/axiom/mnt/fedora3
  #!/bin/sh

And even after fixing this, axiom does not run; it aborts after error messages:
lc[12:21am]~ [7] axiom
/bin/sh: /lib/session: No such file or directory
/bin/sh: line 0: exec: /lib/session: cannot execute: No such file or directory
/bin/sh: /bin/clef: No such file or directory
/bin/sh: line 0: exec: /bin/clef: cannot execute: No such file or directory
/bin/sh: /bin/hypertex: No such file or directory
/bin/sh: line 0: exec: /bin/hypertex: cannot execute: No such file or directory
/bin/sh: /lib/viewman: No such file or directory
/bin/sh: line 0: exec: /lib/viewman: cannot execute: No such file or directory
                        AXIOM Computer Algebra System
                       Version: Axiom 3.4 (April 2005)
               Timestamp: Thursday April 7, 2005 at 19:50:15
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------

   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase
(1) -> lc[12:21am]~ [8]

--Walter Neumann

\start
Date: Fri, 08 Apr 2005 10:04:33 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [StructuredText] 

++added:
Structured Text rules

   0. don't bother trying to learn all the text formatting rules and 
      their interactions. Mimic the text around you;
      when STX doesn't do what you want, tweak it until it looks right.
      Note STX usually does not support non-latin characters.
      Go to the "docs":TextFormattingRules or "ask for help":UserDiscussion#bottom
      when you get really stuck or curious.

   0. text emphasis::

       *italic*
       **bold**
       _underlined_
       'monospaced'

   0. linking (see link types above)::

      WikiName
      [bracketed free-form name]
      ZWiki:RemoteWikiLink
      http://bare/url
      <a href="http://some/where">html link</a>
      "Structured Text link":http://some/where
      [1] (structured text footnote)

   0. separate paragraphs with blank lines

   0. a one-line paragraph becomes a heading when followed by a 
      more-indented paragraph (all indented, or just the first line).
      A more-indented heading becomes a subheading.

   0. a paragraph beginning with - or * or a number followed by a space
      makes a bullet or numbered list item. A more-indented list item starts
      a sub-list.

   0. HTML tags may be used if necessary; on sites which permit it,
      DTML (server-side code) may also be used

   0. to quote text, avoiding all the above: indent it after a paragraph 
      ending with a double colon::

       parent paragraph::

         This is the only reliable way to quote WikiLinks, <HTML tags>
         and &dtml-code; or preserve fixed-width formatting. Use this
         eg when posting zope tracebacks.
          
\start
Date: Fri, 08 Apr 2005 10:01:06 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#147 axiom-Apr2005-src.tgz fails on fedora 3]	input format for issuetracker

The default input format for issuetracker (and in fact for all
pages on the wiki) is called StructuredText although some pages
used HTML and some are just PlainText). StructuredText some
fairly simple rules which allow pages to be formatted in an
"intellegent" manner.

Verbatim text should be entered indented after a double colon
like this::

  Like this::

    Text is indented to show that it is part of the
    verbatim group.

\start
Date: Mon, 18 Apr 2005 11:02:55 -0400
From: Bill Page
To: list
Subject: Re: Tools for mathematical calculations and graphical output

Ing. Martin Ranftler wrote:

>Ladies and gentlemen,
>
>I am a postgradual student at the
>
>   Hochschule Mittweida
>   University of Applied Sciences
>   Mittweida, Germany
>
>  Signals and Systems, Prof. Dr.-Ing. habil Reinhard Sporbert
>
>where I work on a comparison of mathematical tools in order to make a
>recommendation for the future use in some disciplines of the a.m.
>University.
>
>Please find my comparison attached.
>I visited your websites and as far as I was enabled, I tested your products.
>All listed prices are from the original websites which are typed in the
>attached document, dated now (April 2005).
>
>To avoid misunderstandings and mistakes of myself I ask you to check
>carefully what I have found out about your products and to comment it
>finally.
>
>Main topics are:
>   Price
>   Platform, Windows / Linux
>   Input in a form or Input at a "line"
>   Usability of scripts..
>   Format of graphical output (jpg, postscript..), 2D, 3D,
>
>The result will be printed and distributed by myself as a recommendation,
>decision will be made afterwards by the teachers of the university.
>
>So I hope to get an answer from yourselve until Friday, April
>22nd,considering the a.m. topics.
>
>Thank you,
>with best regards
>
>Martin Ranftler

--------------090802010006030400040109
	name="Mathematikprogramme_2005_04.ppt"
 filename="Mathematikprogramme_2005_04.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAA
AAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////9////LgAAAP7///8EAAAABQAAAAYAAAAHAAAA
WgAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUA
AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAA
IwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAD+/////v///zAA
AAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAA
PgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsA
AABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAA
WQAAAP7///9bAAAAXAAAAP7/////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////1IA
bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAWAAUA//////////8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAMBl
GjziQ8UBAwAAAEAPAAAAAAAAUABpAGMAdAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH/////BQAAAP////8AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZwkAAAAAAABQAG8AdwBlAHIAUABvAGkA
bgB0ACAARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf//
//8EAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAACySwAA
AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAoAAIBAQAAAAIAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAALwAAAABVAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgA
AAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA
FgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMA
AAAkAAAAJQAAAP7///8nAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAA
MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAAP7///88AAAA/v//////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////+gRh3w
XwkAAIX6NJxe3EIWmfc/g4zAeNL//9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMD
AwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsKCwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIU
FRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
FBQUFBQUFBQUFBQUFBQUFBT/wAARCABZADwDASIAAhEBAxEB/8QAGwAAAgMBAQEAAAAAAAAA
AAAABwgABAkGAgX/xABDEAABAwMCAwIICQoHAAAAAAABAgMEAAUGBxEIEiETMQkiN0FRc4Gx
FBUyNDU4cXWzIzNhcnR2kqGytBYXQlKDpMH/xAAaAQADAQEBAQAAAAAAAAAAAAACBQYEAwAB
/8QANhEAAQIDBQUECQUBAAAAAAAAAQIDAAQRBSExUWEGEhNBcTSBsdEUIkJDUqGyweEjMjNy
gpH/2gAMAwEAAhEDEQA/ANLalSpWuOUczqblruCafZDkTEdEp62QnJKGXFFKVlIJAJHmrP8A
vHHDqtcpanY10g2lo9zESA2pI9rgWf508XEV5DM6+6X/AOk1lDVzs9KMPtLW6gKINLxXlEhb
Uw806lLayBTldzh0uGri+zbOtSbNiWRNwLjHuJcT8MQz2LzZS0te/inlI8TbblHf306qR31l
1wgfWLw31sj+2drUalO0Eu1LzKUspCQU1u6mN9jPOPMKLiqkHn0ESpUqVMw9gS8QGuiNCbPZ
bo/aVXaNNmGK6ht7s1oHIpXMncEE+L3Hb7a4GPx96bOxg45FvrDm25ZVEQVb+jcObfzr4fhE
PJ1jH3qfwV0hdXllWRKzkol10HeqcDrElaFpTEtMqbbN13LSH3uvErB120w1YhWuzyLdb7ZY
lOofluJLrpXzDqhO4SBy/wC499IRR74cfJfrf+7yfe5QEqis6XblVvNNCgBH0iEk4+uYS244
akg+Jgw8ISuTiJw9R7g5IP8A1naNmUeEUmNz3WrFh7CY7aykO3GUVLWB5+VAAT/EaCPCN9YX
Ef15P9q7QmmfO3/WK95oXpGXnJxRfTXdSmmPMq8oJqaelpYBpVKqNe4Jhy8R8IjLk3NiNfsP
ZLDzgR21ulkKRudt+RYIV/EKdZJ5gD6axjs/0tC9ej+oVs238hP2CpG35KXk1NlhNN6tceVI
o7GmnpkLDqq0pT5wp/hEm1I06xjcdPjU9f8AhXSE1pHxr3vGLNhNgGV487kFufuJbAjTFRno
6uyUe0QQCCdtxsobdaUlqHw8PAPLuGfx9+vwbsYiiP0c3/tPbDmC3IpBQTebwK8+vjCi1Wgu
bUQoDDHpF7hx8l+t/wC7yfe5QEpvNJ8l0y/y81YZsGMXiLZI1obE2ZKnJVPmIWtSQkDYtt7b
+YHv9lBhGqmDW3du36T2p1gdOe63KVIeV+klKkJHsTTGWeWXniGzeRl8I1jA82nhtgrGBzzO
kXeD/wCsZhvrZH9s7QluP0hK9ar3mmg4bM3wDI9acZEbAlYzf0rfVHlWu5OORlnsHOYLad3I
HLzbcqu/bzUP3dW9PMckvM2TSqDcgFqCpuSTXJLrvU9eRPKhHsokvOelLIaNd1Pw5q1jxbRw
E1WMVZ5J0gOQ+ktn9dPvraBr80j7BWYUXVHTnKprEa+aWxbUXHEoTNxue5Hca69D2a+ZCvbt
WnzewQnbu2FS20jil8IKQU/uxppkTFDYSAnibqgcM9c4VTwi/k4xf72P4K6QSn78IuNtOMX+
9j+CukEqg2f7AnqfGE1r9sV3eEG/QjyQ63fc0X8c0D6PHD0N9KNcPuJr8RVAimcv/O+NR9KY
wOj9Ns6H6jBg4RE83EPiA3A3XJ7/ANldoSzfnj/rFe80V+Ef6xGF/tDv4DlCq4/SEr1qveaJ
Ha1/1T4rj4rs6eqvBMe7P9LQvXo/qFbNt/IT9grF6H87Z/XT762ga/NI+wVIbU+5/wBfaKXZ
/wB73feOY1R0lxnV6xN2rJ4a5UZlztmVNPKaW0vYjmBB9BPQ7j9FAhzweOnqnytN+yFDZO/Z
h9g7D0b9lTUEAjY9RSrDiD1D+MXoq7LDbbjIubi5BhL5XgmJJeh8njd4VGUlfp3G229T8g7P
bqkyzlAOVevlDacRKBQL6Kk6QR8X4WcAxDEL7j1tjS22b4wI0+UuUVPutg7gbnxU957kjvq1
aeF3SezxEx2sMtj6U/65YU+s/apZJr5NjyDUPIclXCRd7TBirx+LeEFdlWspce50lonthvyl
G/m+UBsO88bdNYtULJieIXBqBbr3PyK3yJqWWrctlMZbIaeU2r8orfmZD4B6bq5enQ79Qmdc
UUh+84+sRyrf3COW/KISCWrhoM/M/OCNaeGLTnHc0teU2S0fE11t7inG/gj6g0vdCkkKQokb
bKPdtVLHeEzSvHWVJ/wzHur69yuRc1qfWs+nYnlHsArj8W1zy285ZZ4txMC1QrjAauLMdyFs
6tLrz/I3uXB43Zoa32B6qPSqVi4h8udvVjFwjwfgz8S1yJMBu3O9s4h9DqpTyFheyEshtKiF
A9Fbbg7UZZtG8cU3Ae0cL6ffSBS9I3Hh88hp+I7nJeEXSvJGthjTVqfHVEi1uKYUk+nlBKT7
UmjMlQCQCkKIG25oT6B6oXjUWFeBf7aq2XCO63IjtKiOR94jyOZrovqoghaSodDy7jvorUqm
1TAVwn1E7utccoaSwZKeKykDe0phFilmkYjrMxkObSoc2clic1dU2lKp4UhtZcQY26VuFKN0
c/ZqQkFJ+X02NMzUoJeZMvWiQa5iseeYD9KkimULZfce1Sfxe5ps4ySG2boHbdCl3Bp2aGRE
5VJedEhJ5FP7lOzhKehKSOlWrpjmq1yy64ht26RYEy0ushwT0JZhyDCAQpopc8c9uPO0kg7q
5ynYUw1StItBQ9hP/OmukZvQU/Grlzyr5wqLeI66yLNf1z5U8yn4HwyIzEnpSpuS/IYK4wIc
HRltpzY8wH5RWx610F4xvU1/HOytKb3DfOPzmQH5wS6JqpbJZPjSXjzdkHNldoQBuPF35aY6
vC/NRm0lkj1E3GuH5j4mQQK+uq8Uxgc6Mwc1gxskTmzhfmG5lMR5LgU27HSy0gOISCeQLUla
yjpsVGiJUqUudc4qysgDphDFtvhICAa9Y//ZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/
AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQ
k5cIACss+a4IAgAAxAEAABAAAAABAAAAiAAAAAMAAACQAAAADwAAALAAAAAEAAAAwAAAAAYA
AADIAAAABwAAANAAAAAIAAAADwDoAyoIAAABAOkDKAAAAIAWAADgEAAAuBAAAGAYAAAFAAAA
CgAAAAIAAAADAAAAAQAAAAAAAAEPAAkETAMAAAAACgQEAAAANQAAAA8A1w9kAAAAAADTDwQA
AAAbAAAAAAC6DxwAAAB3AHcAdwAuAG8AYwB0AGEAdgBlAC4AbwByAGcAEAC6DywAAABoAHQA
dABwADoALwAvAHcAdwB3AC4AbwBjAHQAYQB2AGUALgBvAHIAZwAvAA8A1w9oAAAAAADTDwQA
AAAeAAAAAAC6Dx4AAAB3AHcAdwAuAG0AYQB0AGgAYwBhAGQALgBjAG8AbQAQALoPLgAAAGgA
dAB0AHAAOgAvAC8AdwB3AHcALgBtAGEAdABoAGMAYQBkAC4AYwBvAG0ALwAPANcPegAAAAAA
0w8EAAAAIQAAAAAAug8oAAAAZwBlAHIAbQBhAG4AeQBAAG0AYQB0AGgAcwBvAGYAdAAuAGMA
bwBtABAAug82AAAAbQBhAGkAbAB0AG8AOgBnAGUAcgBtAGEAbgB5AEAAbQBhAHQAaABzAG8A
ZgB0AC4AYwBvAG0ADwDXD4AAAAAAANMPBAAAACMAAAAAALoPKgAAAHcAdwB3AC4AZABlAHIA
aQB2AGUALQBlAHUAcgBvAHAAZQAuAGMAbwBtABAAug86AAAAaAB0AHQAcAA6AC8ALwB3AHcA
dwAuAGQAZQByAGkAdgBlAC0AZQB1AHIAbwBwAGUALgBjAG8AbQAvAA8A1w9wAAAAAADTDwQA
AAAkAAAAAAC6DyIAAAB3AHcAdwAuAG0AYQB0AGgAdwBvAHIAawBzAC4AYwBvAG0AEAC6DzIA
AABoAHQAdABwADoALwAvAHcAdwB3AC4AbQBhAHQAaAB3AG8AcgBrAHMALgBjAG8AbQAvAA8A
1w9oAAAAAADTDwQAAAAmAAAAAAC6Dx4AAAB3AHcAdwAuAHcAbwBsAGYAcgBhAG0ALgBjAG8A
bQAQALoPLgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgB3AG8AbABmAHIAYQBtAC4AYwBvAG0A
LwAPANcPagAAAAAA0w8EAAAAJwAAAAAAug8gAAAAaQBuAGYAbwBAAHcAbwBsAGYAcgBhAG0A
LgBjAG8AbQAQALoPLgAAAG0AYQBpAGwAdABvADoAaQBuAGYAbwBAAHcAbwBsAGYAcgBhAG0A
LgBjAG8AbQAPAPIDFAEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB0wAAAAAALcPRAAAAEEA
cgBpAGEAbAAAAAgAAAAAAAAAqLkTAKi5EwAQO1cBKLgTABC4EwCh0AcwCAAAAAAAAAAouBMA
OkEJMCC4EwAAAAQAAACkDwgAAACAAEAAAAD//wAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoA
AAAHAAAAAgAHDAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8AAGQAAAAAAAAAAABAAgAA
AAAHAAAA///vAAAAAAD///////8SAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAF
AABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwT0AAAADwAA8OwAAAAAAAbwSAAAAAMcAAAIAAAA
VAAAAAUAAAABAAAACgAAAAIAAABvAAAAAwAAAAYAAAAEAAAADgAAAAUAAAAIAAAABgAAAFkA
AAAAAAAAAwAAAB8AAfAsAAAAUgAH8CQAAAAFBYX6NJxe3EIWmfc/g4zAeNL/AGcJAAABAAAA
AAAAAAAAAACDAAvwMAAAAIEBBAAACIMBAAAACIZBAAAAAL8BEAAQAMABAQAACMVBAAAAAP8B
CAAIAAECAgAACEAAGvEQAAAAMzPMAAD/mQAAzJkAM8zMAEAAHvEQAAAABAAACAEAAAgCAAAI
9wAAEB8A8A8cAAAAAADzAxQAAAAEAAAABAAAAAAAAAAAAACAAAAAAA8A0AeiAQAAHwAUBBwA
AAAAABUEFAAAALqTsPYAypo7rQeUxwDKmjsBAQAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0
AAAAawAAAGQAAABrAAAAZAAAAAgAAAAAAAAAQLgTADpBCTAAAAAAAAAAAKz///+C////AQAT
AHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwATBDwAAAAAAP0DNAAAAGQAAABk
AAAAZAAAAGQAAABsuBMA6iQJMKi5EwDoOlcBAAAAAAAAAAAAAAAAAAAAAAABEwAfAPoDZwAA
AAAA/gMDAAAAAAEAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAACAAAAAAAAABAuBMAOkEJMAAA
AAAAAAAAIPj//4j///8BABMAcAD7AwgAAAAAAAAAMAwAAHAA+wMIAAAAAQAAAFwIAAAfAP8D
FAAAAAIAAAQMAAAAAAAAAAAAAAACAAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8A
UABQAFQAMQAwAAAAixMQAAAAAAANBAgAAAC4WgAAuFoAAA8A8A+wAAAAAADzAxQAAAAFAAAA
BAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqg8KAAAAAQAAAAEAAAAAABAAnw8EAAAA
BQAAAAAAqg8KAAAAAQAAAAEAAAAAAAAA8wMUAAAABgAAAAQAAAACAAAAAQEAAAAAAAAAAJ8P
BAAAAAYAAAAAAKoPCgAAAAEAAAABAAAAAAAQAJ8PBAAAAAUAAAAAAKoPCgAAAAEAAAABAAAA
AAAAAOoDAAAAAA8A+ANWCQAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAAEwBgAPAH
IAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAAYADwByAAAAD///8AAAAAAJaW
lgAAAAAA+99TAP+ZZgDMMwAAmWYAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAJnM/wDMzP8A
MzPMAK9n/wBgAPAHIAAAAN728QAAAAAAlpaWAAAAAAD///8Ajcb/AABmzAAAqAAAYADwByAA
AAD//9kAAAAAAHd3dwAAAAAA///3ADPMzAD/UFAA/5kAAGAA8AcgAAAAAICAAP///wAAWlgA
//+ZAABkYgBtb8cAAP//AAD/AABgAPAHIAAAAIAAAAD///8AXB8AAN/SkwDMMwAAvnlgAP//
mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM//8AM2bMAACwAABmzP8A/+cBAGAA8AcgAAAA
AAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDlAABgAPAHIAAAAGhrXQD///8Ad3d3ANHR
ywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA////AD4+XAD///8AYFl7AGZm/wCZzP8A
//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8AzLQAAIyeoAAAAKMPPgAAAAEA
//0/AAAAIiAAAGQAAAAA/wEAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////xgA
AAAAAwAAEACjD3wAAAAFAP/9PwABACIgAABkAAAAAP8AAGQAFAAAANgAAABAAgAAAAAHAAAA
///vAAAAAAD///////8gAAAAAAEAAIAFAAATINQBIAEAAAIAHACABQAAIiDQAkACAAACABgA
gAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIgAABkAAAA
AP8AAGQAHgAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8MAAAAAAEAAAAFAAAgASAB
AAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJ
AAAAAAEAAAAAAAAAAQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJAAAAAAEA
YAMAAAAABAABCQAAAAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAA
AAAAAAAAAgAcAAEAAAAAAAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAAAAAA
AgASAIAAow8+AAAABQAAAAAAAAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAA
AAAAAAIAEAAEAAAAAAAAAAIAEAAPAAwEiAQAAA8AAvCABAAAEAAI8AgAAAAGAAAACQQAAA8A
A/AYBAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAA
DwAE8AIBAAASAArwCAAAAAQEAAAACgAAgwAL8DAAAAB/AAEABQCAADhiVwGBAQQAAAiDAQAA
AAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAF4PIAFdCooQDwAR8BAAAAAAAMML
CAAAAAIAAAAHAVcBDwAN8IoAAAAAAJ8PBAAAAAQAAAAAAKgPJgAAADIwMDUtMDQsIE0uIFJh
bmZ0bGVyLCBtcmFuZnRsZUBodHdtLmRlAAChDxQAAAAnAAAAAAAAAAAAJwAAAAAAAgAOAAAA
qg8sAAAADAAAAAAAAAAIAAAAAQAAAAMAAgAAAAAAAAAQAAAAAQAAAAMAAQAAAAAAAAAPAATw
uAAAABIACvAIAAAABQQAAAAKAACDAAvwMAAAAH8AAQAFAIAA+GhXAYEBBAAACIMBAAAACL8B
AQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAXg+wB9AOihAPABHwEAAAAAAAwwsIAAAA
AwAAAAkCVwEPAA3wQAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAI
AAABAAIAAAAAAAIADgAAAPoPBAAAAAAAAAAPAATwuAAAABIACvAIAAAABgQAAAAKAACDAAvw
MAAAAH8AAQAFAIAAiG5XAYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA
EPAIAAAAXg8gEGAVihAPABHwEAAAAAAAwwsIAAAABAAAAAgCVwEPAA3wQAAAAAAAnw8EAAAA
BAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADgAAANgPBAAAAAAA
AAAPAATwYAAAALIECvAIAAAABwQAAAAKAABDAAvwKgAAAH8AgACAAARBAQAAAAXBEgAAAAYB
AQAAAGkAbQBhAGcAZQAwADAAOQAAABMAIvEGAAAAvwMABAAEAAAQ8AgAAACOALITqxV6Aw8A
BPDuAAAAogwK8AgAAAAJBAAAAAoAAIMAC/AwAAAAgADIZ1cBvwACAAIAgQEEAAAIgwEAAAAI
vwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AwAEAAQAABDwCAAAAOgAJwHfEqIC
DwAN8IAAAAAAAJ8PBAAAAAQAAAAAAKgPSgAAAFVudGVyc3VjaHVuZ2VuIHp1ciBHZXN0YWx0
dW5nIGVpbmVzIENCVCALaW0gTGVocmdlYmlldCBTaWduYWxlIHVuZCBTeXN0ZW1lAAChDxoA
AABLAAAAAAAAIAAAMgBLAAAAAAAGABQAAAAAAw8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMA
C/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEA
EADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAA
AAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAnDrFAdDp05wgALoP
HAAAAEQAZQBmAGEAdQBsAHQAIABEAGUAcwBpAGcAbgAPAPADGgYAAAEA8QMIAAAAAAAAgAAA
CjAPAAwEmgUAAA8AAvCSBQAAUAAI8AgAAAAHAAAABxQAAA8AA/AqBQAADwAE8CgAAAABAAnw
EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAUAAAFAAAADwAE8NAAAAASAArwCAAAAAIU
AAAACgAAgwAL8DAAAAB/AAEABQCAALRdSwGBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEA
CQABAgIAAAgAABDwCAAAAAAAAAA/BzgBDwAR8BAAAAAAAMMLCAAAAAAAAAAKAkwBDwAN8FgA
AAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAMAAAA
+Q8EAAAAAAAAAAAAqg8SAAAAAQAAAAEAAAAAAAEAAAAAAAAADwAE8NIAAAASAArwCAAAAAMU
AAAACgAAgwAL8DAAAAB/AAEABQCAADT6SwGBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEA
CQABAgIAAAgAABDwCAAAAAAAeAm3EDgBDwAR8BAAAAAAAMMLCAAAAAEAAAAHAEsBDwAN8FoA
AAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwA
AAD4DwQAAAAAAAAAAACqDxIAAAABAAAAAQAAAAAAAQAAAAAAAAAPAATwZAAAABIACvAIAAAA
BBQAAAAKAABjAAvwJAAAAH8ABAEEAYcAAQAAAH8BAAABAL8BEQARAP8BCAAJAD8CAQABAAAA
EPAIAAAA1AFEAnQO+AoPABHwEAAAAAAAwwsIAAAAAgAAAAUASwEPAATwFgEAABIACvAIAAAA
BRQAAAAKAACDAAvwMAAAAH8AAQAFAIAA+P1LAYEBBAAACIMBAAAACL8BAQARAMABAQAACP8B
AQAJAAECAgAACAAAEPAIAAAAlAusAQwPjBYPABHwEAAAAAAAwwsIAAAAAwAAAAYCSwEPAA3w
ngAAAAAAnw8EAAAAAgAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHls
ZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAA
og8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAA
DwAE8NYAAAASAArwCAAAAAYUAAAACgAAkwAL8DYAAAB/AAEABQCAAKBJnwCHAAIAAACBAQQA
AAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAACcXAAA/B18YDwAR8BAA
AAAAAMMLCAAAAAQAAAAJAksBDwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxQA
AAACAAAAAAAAAAAAAgAAAAAAAgAMAAAA+g8EAAAAAAAAAAAAqg8SAAAAAQAAAAEAAAAAAAEA
AAAAAAAADwAE8NgAAAASAArwCAAAAAcUAAAACgAAkwAL8DYAAAB/AAEABQCAAGhInwCHAAIA
AACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAACcXeAm3EF8Y
DwAR8BAAAAAAAMMLCAAAAAUAAAAIAksBDwAN8FoAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoA
AAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAADYDwQAAAAAAAAAAACqDxIAAAABAAAA
AQAAAAAAAQAAAAAAAAAPAATwSAAAABIACvAIAAAAARQAAAAMAACDAAvwMAAAAIEBAAAACIMB
BQAACJMB0sVnAJQBHkCXAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAA
AACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8A
XwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAJ06xQEA0+JLDwDJDxgEAAAPAAwEqAMAAA8A
AvCgAwAAMAAI8AgAAAAFAAAABQwAAA8AA/A4AwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA
AAAAAAAAAAACAArwCAAAAAAMAAAFAAAADwAE8LYAAAASAArwCAAAAAIMAAAACgAAgwAL8DAA
AAB/AAEABQCAAJRenwCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDw
CAAAAAAAAAA/BzgBDwAR8BAAAAAAAMMLCAAAAAAAAAAKAp8ADwAN8D4AAAAAAJ8PBAAAAAQA
AAAAAKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAMAAAA+Q8EAAAAAAAAAA8A
BPC4AAAAEgAK8AgAAAADDAAAAAoAAIMAC/AwAAAAfwABAAUAgADcYp8AgQEEAAAIgwEAAAAI
vwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAAAAAHgJtxA4AQ8AEfAQAAAAAADDCwgA
AAABAAAABwKfAA8ADfBAAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAA
AAgAAAIAAgAAAAAAAgAMAAAA+A8EAAAAAAAAAA8ABPC8AAAAEgAK8AgAAAAEDAAAAAoAAJMA
C/A2AAAAfwABAAUAgACIZ58AhwACAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkA
AQICAAAIAAAQ8AgAAAAnFwAAPwdfGA8AEfAQAAAAAADDCwgAAAACAAAACQKfAA8ADfA+AAAA
AACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADAAAAPoP
BAAAAAAAAAAPAATwvgAAABIACvAIAAAABQwAAAAKAACTAAvwNgAAAH8AAQAFAIAA9GufAIcA
AgAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAJxd4CbcQ
XxgPABHwEAAAAAAAwwsIAAAAAwAAAAgCnwAPAA3wQAAAAAAAnw8EAAAABAAAAAAAoA8CAAAA
KgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADAAAANgPBAAAAAAAAAAPAATwSAAAABIA
CvAIAAAAAQwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB0sVnAJQBHkCXAL8BEgASAP8B
AAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnM
AAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsu
CAAAAJ06xQFglytIDwDuA5kWAAACAO8DGAAAAAAAAAAPEAAAAAAAAAAAAIAAAAAABwATAA8A
DAQJFgAADwAC8AEWAAAgAAjwCAAAABkAAABuCAAADwAD8JkVAAAPAATwKAAAAAEACfAQAAAA
AAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAgAAAUAAAAPAATw2gAAAKIMCvAIAAAABQgAAAAK
AACDAAvwMAAAAIAAxEdMAb8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAEC
AgAACAAAEPAIAAAAegM9AbsUYQQPAA3wegAAAAAAnw8EAAAABAAAAAAAqA8mAAAATWF0aGVt
YXRpa3Byb2dyYW1tZSwg3GJlcnNpY2h0IDIwMDUtMDQAAKEPIgAAACcAAAAAAAAgAAAyACYA
AAAFAAQABQAzM8z+AQAAAAAAAAAAAKYPDgAAAPgAAADYAPgBGAM4BFgFDwAD8NoTAAAPAATw
cAAAAAEACfAQAAAAJwEAALcEAACeFQAAow4AAAIACvAIAAAAbggAAAECAAATAAvwBgAAAH8A
AAEAASMAIvEiAAAAnwMBAAAAoMMWAAAABAAEAAQA4wAAAJgBAACrAQAAqwEAAAAAEPAIAAAA
twQnAZ4Vow4PAATw5AEAABIACvAIAAAAEggAAAIKAACjAAvwPAAAAH8AAAAEAIAANPJMAb8A
AAACAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BAAAIAAECAgAACD8CAAACABMAIvEGAAAA
vwEAAGAAAAAP8BAAAABHCgAA6gsAAJ4VAACjDgAADwAN8GIBAAAAAJ8PBAAAAAcAAAAAAKAP
5gAAAEYAbwByAG0AdQBsAGEAcgBlAGkAbgBnAGEAYgBlACwADQBWAGUAcgBhAHIAYgBlAGkA
dAB1AG4AZwAgAGkAbgAgAGQAZQBuACAARwByAGEAZgBpAGsAZQBuACAAZAB1AHIAYwBoACAA
HiBBAGsAdABpAHYAaQBlAHIAZQBuABwgIABkAGUAcgAgAEEAbABnAGUAYgByAGEAaQBzAGMA
aABlAG4AIABFAGkAbgBnAGEAYgBlAG4ADQBHAHIAYQBmAGkAawBmAG8AcgBtAGEAdABlADoA
IABqAHAAZwAgAHUALgBhAC4AAAChDxYAAAB0AAAAAAABAAAAAAB0AAAAAAACAA4AAACqDywA
AABrAAAAAAAAAAMAAAABAAAAAwABAAAAAAAAAAMAAAABAAAAAwACAAAAAAAAAAAApg8OAAAA
+AAAAAAAIAFAAmADgAQPAATwUgEAABIACvAIAAAAEQgAAAIKAACjAAvwPAAAAH8AAAAEAIAA
9HZLAb8AAAACAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BAAAIAAECAgAACD8CAAACABMA
IvEGAAAAvwEAAGAAAAAP8BAAAAC7BgAA6gsAAEcKAACjDgAADwAN8NAAAAAAAJ8PBAAAAAcA
AAAAAKAPXAAAAFMAdAB1AGQAZQBuAHQAcwAgAKwgIAAxADEAMwANAEEAbgBuAHUAYQBsACAA
IAAgACAArCAgACAAIAA0ADUADQBTAGUAbQBlAHMAdABlAHIAIACsICAAIAAyADkAAAChDxYA
AAAvAAAAAAABAAAAAAAvAAAAAAACAA4AAACqDyQAAAAIAAAAAQAAAAMABwAAAAAAAAAGAAAA
AQAAAAMAGgAAAAAAAAAAAKYPDgAAAPgAAAAAACABQAJgA4AEDwAE8MMBAAASAArwCAAAABAI
AAACCgAAowAL8DwAAAB/AAAABACAAPiQSwG/AAAAAgCBAQQAAAiDAQAAAAi/AQkAHwDAAQEA
AAj/AQAACAABAgIAAAg/AgAAAgATACLxBgAAAL8BAABgAAAAD/AQAAAAJwEAAOoLAAC7BgAA
ow4AAA8ADfBBAQAAAACfDwQAAAAHAAAAAACoD0MAAABNYXRoZW1hdGljYSA1DXd3dy53b2xm
cmFtLmNvbQ1pbmZvQHdvbGZyYW0uY29tDXN1cHBvcnRAd29sZnJhbS5jb20NAAChDyAAAABE
AAAAAAABAAAAAAAeAAAAAAACAA4AJgAAAAAAAgAKAAAAqg9EAAAACwAAAAEAAAADAAMAAAAA
AAAADwAAAAAAAAABAAAAAAAAABAAAAAAAAAAAQAAAAAAAAATAAAAAQAAAAMAAgAAAAAAAAAP
APIPGAAAAAAA8w8QAAAAAAAAACYAAAAEAAAACEIKMAAA3w8IAAAADgAAAB0AAAAPAPIPGAAA
AAAA8w8QAAAAAAAAACcAAAAEAAAACEIKMAAA3w8IAAAAHgAAAC4AAAAAAKYPDgAAAPgAAAAA
ACABQAJgA4AEDwAE8O4BAAASAArwCAAAAA8IAAACCgAAowAL8DwAAAB/AAAABACAADCjSwG/
AAAAAgCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/AQAACAABAgIAAAg/AgAAAgATACLxBgAA
AL8BAABgAAAAD/AQAAAARwoAAMIIAACeFQAA6gsAAA8ADfBsAQAAAACfDwQAAAAHAAAAAACo
D7oAAABCZWZlaGxzemVpbGVuZWluZ2FiZSwgZ3Jv32VyIEJlZmVobHN1bWZhbmcsIFp1c2F0
enBha2V0ZSBm/HIgdmVyc2NoaWVkZW5lIEZhY2hyaWNodHVuZ2VuIA0ubSBTY3JpcHRzDVZv
cmxhZ2UgZvxyIHZlcnNjaGllZGVuZSBGcmVld2FyZQ1HcmFmaWtmb3JtYXRlOiBwb3N0c2Ny
aXB0LCBlbWYsIGR4ZiwgbGF0ZXggdS52LmEubS4AAKEPFgAAALsAAAAAAAEAAAAAALsAAAAA
AAIADgAAAKoPYgAAAJYAAAAAAAAACgAAAAEAAAADAAIAAAAAAAAAAwAAAAEAAAADAAIAAAAA
AAAAAwAAAAEAAAADAAIAAAAAAAAABQAAAAEAAAADAAEAAAAAAAAABwAAAAEAAAADAAIAAAAA
AAAAAACmDw4AAAD4AAAAAAAgAUACYAOABA8ABPD+AAAAEgAK8AgAAAAOCAAAAgoAAKMAC/A8
AAAAfwAAAAQAgAA4pUsBvwAAAAIAgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEAAAgAAQIC
AAAIPwIAAAIAEwAi8QYAAAC/AQAAYAAAAA/wEAAAALsGAADCCAAARwoAAOoLAAAPAA3wfAAA
AAAAnw8EAAAABwAAAAAAoA8aAAAAUwB0AHUAZABlAG4AdABzACAArCAgADcAMAAAAKEPFgAA
AA4AAAAAAAEAAAAAAA4AAAAAAAIADgAAAKoPEgAAAAgAAAABAAAAAwAGAAAAAAAAAAAApg8O
AAAA+AAAAAAAIAFAAmADgAQPAATwZgEAABIACvAIAAAADQgAAAIKAACjAAvwPAAAAH8AAAAE
AIAA7LdLAb8AAAACAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BAAAIAAECAgAACD8CAAAC
ABMAIvEGAAAAvwEAAGAAAAAP8BAAAAAnAQAAwggAALsGAADqCwAADwAN8OQAAAAAAJ8PBAAA
AAcAAAAAAKgPMAAAAE1BVExBQiA3DXd3dy5tYXRod29ya3MuY29tDWFkZHJlc3NAbWF0aHdv
cmtzLmNvbQAAoQ8gAAAAMQAAAAAAAQAAAAAAGwAAAAAAAgAOABYAAAAAAAIACgAAAKoPKgAA
AAkAAAAAAAAAEQAAAAAAAAABAAAAAAAAABUAAAABAAAAAwABAAAAAAAAAA8A8g8YAAAAAADz
DxAAAAAAAAAAJAAAAAQAAAAIQgowAADfDwgAAAAJAAAAGgAAAAAApg8OAAAA+AAAAAAAIAFA
AmADgAQPAATweAEAABIACvAIAAAADAgAAAIKAACjAAvwPAAAAH8AAAAEAIAAbMJLAb8AAAAC
AIEBBAAACIMBAAAACL8BAQAVAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAARwoA
AJoFAACeFQAAwggAAA8ADfAEAQAAAACfDwQAAAAHAAAAAACoD7wAAABGb3JtdWxhcmVpbmdh
YmUsIA1adXNhdHpwYWtldGUgZvxyIHZlcnNjaGllZGVuZSBGYWNocmljaHR1bmdlbg1kaXJl
a3RlIFZlcmFyYmVpdHVuZyBkZXIgQWxnZWJyYSBpbSBGb3JtdWxhciB1bmQgaW4gZGVuIGFi
Z2VsZWl0ZXRlbiBHcmFmaWtlbg1HcmFmaWtmb3JtYXQ6IGltIEZvcm11bGFyLCBLb3BpZXJl
biB1LiBFaW5m/GdlbgAAoQ8WAAAAvQAAAAAAAQAAAAAAvQAAAAAAAgAOAAAApg8OAAAA+AAA
AAAAIAFAAmADgAQPAATwxwAAABIACvAIAAAACwgAAAIKAACjAAvwPAAAAH8AAAAEAIAAnMRL
Ab8AAAACAIEBBAAACIMBAAAACL8BAQAVAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQ
AAAAuwYAAJoFAABHCgAAwggAAA8ADfBTAAAAAACfDwQAAAAHAAAAAACoDwsAAABjYS4gMTIw
MCAkDQAAoQ8WAAAADAAAAAAAAQAAAAAADAAAAAAAAgAOAAAApg8OAAAA+AAAAAAAIAFAAmAD
gAQPAATwngEAABIACvAIAAAACggAAAIKAACjAAvwPAAAAH8AAAAEAIAAsNhLAb8AAAACAIEB
BAAACIMBAAAACL8BAQAVAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAJwEAAJoF
AAC7BgAAwggAAA8ADfAqAQAAAACfDwQAAAAHAAAAAACoDzAAAABNYXRoY2FkIDEyDXd3dy5t
YXRoY2FkLmNvbQ1nZXJtYW55QG1hdGhzb2Z0LmNvbSAAAKEPLAAAADEAAAAAAAEAAAAAABsA
AAAAAAIADgAUAAAAAQACAAEACgACAAAAAAACAAoAAACqDzQAAAAHAAAAAQAAAAMABAAAAAAA
AAAPAAAAAAAAAAEAAAAAAAAAFAAAAAEAAAADAAIAAAAAAAAADwDyDxgAAAAAAPMPEAAAAAAA
AAAeAAAABAAAAAhCCjAAAN8PCAAAAAsAAAAaAAAADwDyDxgAAAAAAPMPEAAAAAAAAAAhAAAA
BAAAAAhCCjAAAN8PCAAAABsAAAAvAAAAAACmDw4AAAD4AAAAAAAgAUACYAOABA8ABPDHAAAA
EgAK8AgAAAAJCAAAAgoAAKMAC/A8AAAAfwAAAAQAgADY4UsBvwAAAAIAgQEEAAAIgwEAAAAI
vwEBABUAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAABHCgAAtwQAAJ4VAACaBQAA
DwAN8FMAAAAAAJ8PBAAAAAcAAAAAAKgPCQAAAEJlbWVya3VuZwAAoQ8YAAAACgAAAAAAAQAA
AAAACgAAAAEAAgABAA4AAACmDw4AAAD4AAAAAAAgAUACYAOABA8ABPDDAAAAEgAK8AgAAAAI
CAAAAgoAAKMAC/A8AAAAfwAAAAQAgAA86ksBvwAAAAIAgQEEAAAIgwEAAAAIvwEBABUAwAEB
AAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAAC7BgAAtwQAAEcKAACaBQAADwAN8E8AAAAA
AJ8PBAAAAAcAAAAAAKgPBQAAAFByZWlzAAChDxgAAAAGAAAAAAABAAAAAAAGAAAAAQACAAEA
DgAAAKYPDgAAAPgAAAAAACABQAJgA4AEDwAE8MYAAAASAArwCAAAAAcIAAACCgAAowAL8DwA
AAB/AAAABACAAAT0SwG/AAAAAgCBAQQAAAiDAQAAAAi/AQEAFQDAAQEAAAj/AQAACAABAgIA
AAg/AgAAAgAAAA/wEAAAACcBAAC3BAAAuwYAAJoFAAAPAA3wUgAAAAAAnw8EAAAABwAAAAAA
qA8IAAAAUHJvZ3JhbW0AAKEPGAAAAAkAAAAAAAEAAAAAAAkAAAABAAIAAQAOAAAApg8OAAAA
+AAAAAAAIAFAAmADgAQPAATwYAAAAEIBCvAIAAAAGQgAAAIKAACDAAvwMAAAAL8BAAAQAMAB
AQAACMsBn28AANcBAQAAAP8BCAAKAAECAgAACD8CAAACAL8CAAAIAAAAD/AQAAAAJwEAALcE
AACeFQAAtwQAAA8ABPBaAAAAQgEK8AgAAAAaCAAAAgoAAHMAC/AqAAAAvwEAABAAwAEBAAAI
ywGcMQAA/wEIAAoAAQICAAAIPwIAAAIAvwIAAAgAAAAP8BAAAAAnAQAAmgUAAJ4VAACaBQAA
DwAE8FoAAABCAQrwCAAAABsIAAACCgAAcwAL8CoAAAC/AQAAEADAAQEAAAjLAZwxAAD/AQgA
CgABAgIAAAg/AgAAAgC/AgAACAAAAA/wEAAAACcBAADCCAAAnhUAAMIIAAAPAATwWgAAAEIB
CvAIAAAAHAgAAAIKAABzAAvwKgAAAL8BAAAQAMABAQAACMsBnDEAAP8BCAAKAAECAgAACD8C
AAACAL8CAAAIAAAAD/AQAAAAJwEAAOoLAACeFQAA6gsAAA8ABPBgAAAAQgEK8AgAAAAfCAAA
AgoAAIMAC/AwAAAAvwEAABAAwAEBAAAIywGfbwAA1wEBAAAA/wEIAAoAAQICAAAIPwIAAAIA
vwIAAAgAAAAP8BAAAAAnAQAAow4AAJ4VAACjDgAADwAE8GAAAABCAQrwCAAAACAIAAACCgAA
gwAL8DAAAAC/AQAAEADAAQEAAAjLAZ9vAADXAQEAAAD/AQgACgABAgIAAAg/AgAAAgC/AgAA
CAAAAA/wEAAAACcBAAC3BAAAJwEAAKMOAAAPAATwWgAAAEIBCvAIAAAAIQgAAAIKAABzAAvw
KgAAAL8BAAAQAMABAQAACMsBnDEAAP8BCAAKAAECAgAACD8CAAACAL8CAAAIAAAAD/AQAAAA
uwYAALcEAAC7BgAAow4AAA8ABPBaAAAAQgEK8AgAAAAiCAAAAgoAAHMAC/AqAAAAvwEAABAA
wAEBAAAIywGcMQAA/wEIAAoAAQICAAAIPwIAAAIAvwIAAAgAAAAP8BAAAABHCgAAtwQAAEcK
AACjDgAADwAE8GAAAABCAQrwCAAAACMIAAACCgAAgwAL8DAAAAC/AQAAEADAAQEAAAjLAZ9v
AADXAQEAAAD/AQgACgABAgIAAAg/AgAAAgC/AgAACAAAAA/wEAAAAJ4VAAC3BAAAnhUAAKMO
AAAPAATwnQAAAKIMCvAIAAAANwgAAAAKAACDAAvwMAAAAIAAiANLAb8AAgACAIEBBAAACIMB
AAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAcA85E4YVHRAPAA3wPQAAAAAA
nw8EAAAABAAAAAAAqA8JAAAAU2VpdGUgMS8yAAChDxgAAAAKAAAAAAAAIAAAMgAKAAAAAQAC
AAEADAAPAATwSAAAABIACvAIAAAAAQgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+L
AJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAA
ALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAx
ADAAAACLExAAAAAAAOsuCAAAAJw6xQHQWtacDwDuA+8YAAACAO8DGAAAAAAAAAAPEAAAAAAA
AAAAAIAAAAAABwATAA8ADARfGAAADwAC8FcYAABgAAjwCAAAACIAAABYGAAADwAD8O8XAAAP
AATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABgAAAUAAAAPAAPwKhUA
AA8ABPBwAAAAAQAJ8BAAAABUAQAAoQQAAMsVAADrDAAAAgAK8AgAAABYGAAAAQIAABMAC/AG
AAAAfwAAAQABIwAi8SIAAACfAwEAAACgwxYAAAAEAAQABADjAAAAmAEAAKsBAACrAQAAAAAQ
8AgAAAChBFQByxXrDA8ABPDiAQAAEgAK8AgAAABAGAAAAgoAAKMAC/A8AAAAfwAAAAQAgAA4
IkwBvwAAAAIAgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAEwAi
8QYAAAC/AQAAYAAAAA/wEAAAAHQKAABJCgAAyxUAAOsMAAAPAA3wYAEAAAAAnw8EAAAABwAA
AAAAqA94AAAAQmVmZWhsc3plaWxlbmVpbmdhYmUNTUFUTEFCLVN5bnRheCwgV2luZG93cyB1
bmQgTGludXggIA0ubSAtIHNjcmlwdHMNR3JhZmlrZm9ybWF0ZTogcG9zdHNjcmlwdCwgZW1m
LCBkeGYsIGxhdGV4IHUudi5hLm0uAAChDxYAAAB5AAAAAAABAAAAAAB5AAAAAAACAA4AAACq
D5gAAAAVAAAAAAAAAA0AAAABAAAAAwAOAAAAAAAAAAUAAAABAAAAAwAIAAAAAAAAAAcAAAAB
AAAAAwAQAAAAAAAAAAoAAAABAAAAAwACAAAAAAAAAAMAAAABAAAAAwACAAAAAAAAAAMAAAAB
AAAAAwACAAAAAAAAAAUAAAABAAAAAwABAAAAAAAAAAcAAAABAAAAAwACAAAAAAAAAAAApg8O
AAAA+AAAAAAAIAFAAmADgAQPAATw0gAAABIACvAIAAAAPhgAAAIKAACjAAvwPAAAAH8AAAAE
AIAA6KtMAb8AAAACAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BAAAIAAECAgAACD8CAAAC
ABMAIvEGAAAAvwEAAGAAAAAP8BAAAADoBgAASQoAAHQKAADrDAAADwAN8FAAAAAAAJ8PBAAA
AAcAAAAAAKgPCAAAAEZyZWV3YXJlAAChDxYAAAAJAAAAAAABAAAAAAAJAAAAAAACAA4AAACm
Dw4AAAD4AAAAAAAgAUACYAOABA8ABPBmAQAAEgAK8AgAAAA8GAAAAgoAAKMAC/A8AAAAfwAA
AAQAgADAuEwBvwAAAAIAgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEAAAgAAQICAAAIPwIA
AAIAEwAi8QYAAAC/AQAAYAAAAA/wEAAAAFQBAABJCgAA6AYAAOsMAAAPAA3w5AAAAAAAnw8E
AAAABwAAAAAAqA8mAAAAT2N0YXZlIDINd3d3Lm9jdGF2ZS5vcmcNandlQG9jdGF2ZS5vcmcA
AKEPIAAAACcAAAAAAAEAAAAAABgAAAAAAAIADgAPAAAAAAACAAoAAACqDzQAAAAGAAAAAQAA
AAMAAwAAAAAAAAAOAAAAAAAAAAEAAAAAAAAADgAAAAEAAAADAAEAAAAAAAAADwDyDxgAAAAA
APMPEAAAAAAAAAAbAAAABAAAAAhCCjAAAN8PCAAAAAkAAAAXAAAAAACmDw4AAAD4AAAAAAAg
AUACYAOABA8ABPDeAAAAEgAK8AgAAAANGAAAAgoAAKMAC/A8AAAAfwAAAAQAgADgwUwBvwAA
AAIAgQEEAAAIgwEAAAAIvwEJAB8AwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAEwAi8QYAAAC/
AQAAYAAAAA/wEAAAAHQKAAB2CAAAyxUAAEkKAAAPAA3wXAAAAAAAnw8EAAAABwAAAAAAqA8U
AAAAQmVmZWhsc3plaWxlbmVpbmdhYmUAAKEPFgAAABUAAAAAAAEAAAAAABUAAAAAAAIADgAA
AKYPDgAAAPgAAAAAACABQAJgA4AEDwAE8NIAAAASAArwCAAAAA4YAAACCgAAowAL8DwAAAB/
AAAABACAAMDDTAG/AAAAAgCBAQQAAAiDAQAAAAi/AQkAHwDAAQEAAAj/AQAACAABAgIAAAg/
AgAAAgATACLxBgAAAL8BAABgAAAAD/AQAAAA6AYAAHYIAAB0CgAASQoAAA8ADfBQAAAAAACf
DwQAAAAHAAAAAACoDwgAAABGcmVld2FyZQAAoQ8WAAAACQAAAAAAAQAAAAAACQAAAAAAAgAO
AAAApg8OAAAA+AAAAAAAIAFAAmADgAQPAATwTQEAABIACvAIAAAADxgAAAIKAACjAAvwPAAA
AH8AAAAEAIAASNhMAb8AAAACAIEBBAAACIMBAAAACL8BCQAfAMABAQAACP8BAAAIAAECAgAA
CD8CAAACABMAIvEGAAAAvwEAAGAAAAAP8BAAAABUAQAAdggAAOgGAABJCgAADwAN8MsAAAAA
AJ8PBAAAAAcAAAAAAKgPNwAAAEFYSU9NDXBhZ2UuYXhpb20tZGV2ZWxvcGVyLm9yZw1wYWdl
QGF4aW9tLWRldmVsb3Blci5vcmcAAKEPLgAAADgAAAAAAAEAAAAAAAYAAAAAAAIADgAZAAAA
AAAGAA4AM8zM/hkAAAAAAAIACgAAAKoPLAAAAAYAAAAAAAAAGAAAAAEAAAADAAEAAAAAAAAA
GAAAAAEAAAADAAEAAAAAAAAAAACmDw4AAAD4AAAAAAAgAUACYAOABA8ABPCpAQAAEgAK8AgA
AAAQGAAAAgoAAKMAC/A8AAAAfwAAAAQAgAC0xUwBvwAAAAIAgQEEAAAIgwEAAAAIvwEJAB8A
wAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAEwAi8QYAAAC/AQAAYAAAAA/wEAAAAHQKAACEBQAA
yxUAAHYIAAAPAA3wJwEAAAAAnw8EAAAABwAAAAAAqA/fAAAARm9ybXVsYXLkaG5saWNoZSBC
ZWZlaGxzemVpbGVuZWluZ2FiZSwgRWluIFNjaHdlcnB1bmt0IGxpZWd0IGF1ZiBkZXIgS29t
bXVuaWthdGlvbiBtaXQgVGV4YXMtSW5zdHJ1bWVudHMgU2NodWxyZWNobmVybg1FaW5iaW5k
dW5nIHZvbiBHcmFmaWtlbiBuYWNoIGlocmVyIEVyc3RlbGx1bmcgaW4gZGFzIEZvcm11bGFy
IG32Z2xpY2gsIGFiZXIga2VpbmUgZGlyZWt0ZSBWZXJhcmJlaXR1bmcgIAAAoQ8WAAAA4AAA
AAAAAQAAAAAA4AAAAAAAAgAOAAAApg8OAAAA+AAAAAAAIAFAAmADgAQPAATwAAEAABIACvAI
AAAAERgAAAIKAACjAAvwPAAAAH8AAAAEAIAAtORMAb8AAAACAIEBBAAACIMBAAAACL8BCQAf
AMABAQAACP8BAAAIAAECAgAACD8CAAACABMAIvEGAAAAvwEAAGAAAAAP8BAAAADoBgAAhAUA
AHQKAAB2CAAADwAN8H4AAAAAAJ8PBAAAAAcAAAAAAKAPHAAAAFMAdAB1AGQAZQBuAHQAcwAg
AKwgIAA5ADkAIAAAAKEPFgAAAA8AAAAAAAEAAAAAAA8AAAAAAAIADgAAAKoPEgAAAAgAAAAB
AAAAAwAHAAAAAAAAAAAApg8OAAAA+AAAAAAAIAFAAmADgAQPAATweAEAABIACvAIAAAAEhgA
AAIKAACjAAvwPAAAAH8AAAAEAIAAzNJMAb8AAAACAIEBBAAACIMBAAAACL8BCQAfAMABAQAA
CP8BAAAIAAECAgAACD8CAAACABMAIvEGAAAAvwEAAGAAAAAP8BAAAABUAQAAhAUAAOgGAAB2
CAAADwAN8PYAAAAAAJ8PBAAAAAcAAAAAAKgPOAAAAERlcml2ZSA2DXd3dy5kZXJpdmUtZXVy
b3BlLmNvbQ1jb250YWN0QGRlcml2ZS1ldXJvcGUuY29tAAChDyAAAAA5AAAAAAABAAAAAAAf
AAAAAAACAA4AGgAAAAAAAgAKAAAAqg80AAAABgAAAAEAAAADAAMAAAAAAAAAFQAAAAAAAAAB
AAAAAAAAABkAAAABAAAAAwABAAAAAAAAAA8A8g8YAAAAAADzDxAAAAAAAAAAIwAAAAQAAAAI
QgowAADfDwgAAAAJAAAAHgAAAAAApg8OAAAA+AAAAAAAIAFAAmADgAQPAATwxwAAABIACvAI
AAAAExgAAAIKAACjAAvwPAAAAH8AAAAEAIAABKBMAb8AAAACAIEBBAAACIMBAAAACL8BAQAV
AMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAdAoAAKEEAADLFQAAhAUAAA8ADfBT
AAAAAACfDwQAAAAHAAAAAACoDwkAAABCZW1lcmt1bmcAAKEPGAAAAAoAAAAAAAEAAAAAAAoA
AAABAAIAAQAOAAAApg8OAAAA+AAAAAAAIAFAAmADgAQPAATwwwAAABIACvAIAAAAFBgAAAIK
AACjAAvwPAAAAH8AAAAEAIAA3EJMAb8AAAACAIEBBAAACIMBAAAACL8BAQAVAMABAQAACP8B
AAAIAAECAgAACD8CAAACAAAAD/AQAAAA6AYAAKEEAAB0CgAAhAUAAA8ADfBPAAAAAACfDwQA
AAAHAAAAAACoDwUAAABQcmVpcwAAoQ8YAAAABgAAAAAAAQAAAAAABgAAAAEAAgABAA4AAACm
Dw4AAAD4AAAAAAAgAUACYAOABA8ABPDGAAAAEgAK8AgAAAAVGAAAAgoAAKMAC/A8AAAAfwAA
AAQAgABYNUwBvwAAAAIAgQEEAAAIgwEAAAAIvwEBABUAwAEBAAAI/wEAAAgAAQICAAAIPwIA
AAIAAAAP8BAAAABUAQAAoQQAAOgGAACEBQAADwAN8FIAAAAAAJ8PBAAAAAcAAAAAAKgPCAAA
AFByb2dyYW1tAAChDxgAAAAJAAAAAAABAAAAAAAJAAAAAQACAAEADgAAAKYPDgAAAPgAAAAA
ACABQAJgA4AEDwAE8GAAAABCAQrwCAAAABYYAAACCgAAgwAL8DAAAAC/AQAAEADAAQEAAAjL
AZ9vAADXAQEAAAD/AQgACgABAgIAAAg/AgAAAgC/AgAACAAAAA/wEAAAAFQBAAChBAAAyxUA
AKEEAAAPAATwYAAAAEIBCvAIAAAAFxgAAAIKAACDAAvwMAAAAL8BAAAQAMABAQAACMsBnDEA
ANcBAAAAAP8BCAAKAAECAgAACD8CAAACAL8CAAAIAAAAD/AQAAAAVAEAAIQFAADLFQAAhAUA
AA8ABPBgAAAAQgEK8AgAAAAYGAAAAgoAAIMAC/AwAAAAvwEAABAAwAEBAAAIywGcMQAA1wEA
AAAA/wEIAAoAAQICAAAIPwIAAAIAvwIAAAgAAAAP8BAAAABUAQAAdggAAMsVAAB2CAAADwAE
8GAAAABCAQrwCAAAABwYAAACCgAAgwAL8DAAAAC/AQAAEADAAQEAAAjLAZ9vAADXAQEAAAD/
AQgACgABAgIAAAg/AgAAAgC/AgAACAAAAA/wEAAAAFQBAADrDAAAyxUAAOsMAAAPAATwWgAA
AEIBCvAIAAAAHhgAAAIKAABzAAvwKgAAAL8BAAAQAMABAQAACMsBnDEAAP8BCAAKAAECAgAA
CD8CAAACAL8CAAAIAAAAD/AQAAAA6AYAAKEEAADoBgAAhAUAAA8ABPBaAAAAQgEK8AgAAAAf
GAAAAgoAAHMAC/AqAAAAvwEAABAAwAEBAAAIywGcMQAA/wEIAAoAAQICAAAIPwIAAAIAvwIA
AAgAAAAP8BAAAAB0CgAAoQQAAHQKAACEBQAADwAE8GAAAABCAQrwCAAAAC4YAAACCgAAgwAL
8DAAAAC/AQAAEADAAQEAAAjLAZ9vAADXAQAAAAD/AQgACgABAgIAAAg/AgAAAgC/AgAACAAA
AA/wEAAAAFQBAACEBQAAVAEAAHYIAAAPAATwYAAAAEIBCvAIAAAAHRgAAAIKAACDAAvwMAAA
AL8BAAAQAMABAQAACMsBn28AANcBAQAAAP8BCAAKAAECAgAACD8CAAACAL8CAAAIAAAAD/AQ
AAAAVAEAAKEEAABUAQAAhAUAAA8ABPBgAAAAQgEK8AgAAAAvGAAAAgoAAIMAC/AwAAAAvwEA
ABAAwAEBAAAIywGfbwAA1wEBAAAA/wEIAAoAAQICAAAIPwIAAAIAvwIAAAgAAAAP8BAAAABU
AQAAdggAAFQBAADrDAAADwAE8GAAAABCAQrwCAAAADAYAAACCgAAgwAL8DAAAAC/AQAAEADA
AQEAAAjLAZwxAADXAQAAAAD/AQgACgABAgIAAAg/AgAAAgC/AgAACAAAAA/wEAAAAOgGAACE
BQAA6AYAAHYIAAAPAATwWgAAAEIBCvAIAAAAMRgAAAIKAABzAAvwKgAAAL8BAAAQAMABAQAA
CMsBnDEAAP8BCAAKAAECAgAACD8CAAACAL8CAAAIAAAAD/AQAAAA6AYAAHYIAADoBgAA6wwA
AA8ABPBgAAAAQgEK8AgAAAA0GAAAAgoAAIMAC/AwAAAAvwEAABAAwAEBAAAIywGcMQAA1wEA
AAAA/wEIAAoAAQICAAAIPwIAAAIAvwIAAAgAAAAP8BAAAAB0CgAAhAUAAHQKAAB2CAAADwAE
8FoAAABCAQrwCAAAADUYAAACCgAAcwAL8CoAAAC/AQAAEADAAQEAAAjLAZwxAAD/AQgACgAB
AgIAAAg/AgAAAgC/AgAACAAAAA/wEAAAAHQKAAB2CAAAdAoAAOsMAAAPAATwYAAAAEIBCvAI
AAAANhgAAAIKAACDAAvwMAAAAL8BAAAQAMABAQAACMsBn28AANcBAAAAAP8BCAAKAAECAgAA
CD8CAAACAL8CAAAIAAAAD/AQAAAAyxUAAIQFAADLFQAAdggAAA8ABPBgAAAAQgEK8AgAAAAg
GAAAAgoAAIMAC/AwAAAAvwEAABAAwAEBAAAIywGfbwAA1wEBAAAA/wEIAAoAAQICAAAIPwIA
AAIAvwIAAAgAAAAP8BAAAADLFQAAoQQAAMsVAACEBQAADwAE8GAAAABCAQrwCAAAADcYAAAC
CgAAgwAL8DAAAAC/AQAAEADAAQEAAAjLAZ9vAADXAQEAAAD/AQgACgABAgIAAAg/AgAAAgC/
AgAACAAAAA/wEAAAAMsVAAB2CAAAyxUAAOsMAAAPAATwWgAAAEIBCvAIAAAAPRgAAAIKAABz
AAvwKgAAAL8BAAAQAMABAQAACMsBnDEAAP8BCAAKAAECAgAACD8CAAACAL8CAAAIAAAAD/AQ
AAAAVAEAAEkKAADLFQAASQoAAA8ABPCdAAAAogwK8AgAAAAhGAAAAAoAAIMAC/AwAAAAgABk
PEwBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABw
DzkThhUdEA8ADfA9AAAAAACfDwQAAAAEAAAAAACoDwkAAABTZWl0ZSAyLzIAAKEPGAAAAAoA
AAAAAAAgAAAyAAoAAAABAAIAAQAMAA8ABPDaAAAAogwK8AgAAAA7GAAAAAoAAIMAC/AwAAAA
gADAY0sBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgA
AAB6Az0BuxRhBA8ADfB6AAAAAACfDwQAAAAEAAAAAACoDyYAAABNYXRoZW1hdGlrcHJvZ3Jh
bW1lLCDcYmVyc2ljaHQgMjAwNS0wNAAAoQ8iAAAAJwAAAAAAACAAADIAJgAAAAUABAAFADMz
zP4BAAAAAAAAAAAApg8OAAAA+AAAANgA+AEYAzgEWAUPAATw/gAAAKIMCvAIAAAATRgAAAAK
AACDAAvwMAAAAIAANGdLAb8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAEC
AgAACAAAEPAIAAAAMg4nAZ4V8g4PAA3wngAAAAAAnw8EAAAABAAAAAAAqA8uAAAATWFjU3lt
YSwgQ2F5bGV5LCBNYWdtYSBpbSB3d3cgbmljaHQgYXVmZmluZGJhcgAAoQ8WAAAALwAAAAAA
ACAAADIALwAAAAAAAgAOAAAAqg82AAAABwAAAAEAAAADAAIAAAAAAAAABgAAAAEAAAADAAsA
AAAAAAAAAwAAAAEAAAADABIAAAAAAAAADwAE8EgAAAASAArwCAAAAAEYAAAADAAAgwAL8DAA
AACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAH
IAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAA
ug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAACcOsUB0FrWnAAAchccAAAA
AQBgAAAAAACQEQAAshcAADIIAADSGwAAczIAAAAA9Q8cAAAAAAEAAG0QAAMAAAAAaksAAAEA
AAAHAAAAAQAiBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMA
dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIA////////
////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgAAACgFAAAAAAAA
QwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA7AAAAfQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAA
0FQAAAsAAAABAAAAYAAAAAIAAABoAAAABAAAAHgAAAAIAAAAoAAAAAkAAADIAAAAEgAAANQA
AAAKAAAA9AAAAAwAAAAAAQAADQAAAAwBAAAPAAAAGAEAABEAAAAgAQAAAgAAAOQEAAAeAAAA
CAAAAFNsaWRlIDEAHgAAACAAAABSQU5GVExFUiBNQVJUSU4gSFlEUk8tQVQuR0gtRVQzAB4A
AAAgAAAAUkFORlRMRVIgTUFSVElOIEhZRFJPLUFULkdILUVUMwAeAAAAAwAAADE2AEYeAAAA
FQAAAE1pY3Jvc29mdCBQb3dlclBvaW50AC1BVEAAAAAAAAAAAAAAAEAAAABw+x8qnjrFAUAA
AADAMA484kPFAQMAAACaAAAARwAAAKhTAAD/////AwAAAAgAiRBnDAAAAQAJAAADzCkAAAEA
oScAAAAABAAAAAMBCAAFAAAACwIAAAAABQAAAAwC0QLBAwkCAAD3AAADAgEAAAAAgAAAAACA
AACAgAAAAACAAIAAgAAAgIAAwMDAAMDcwACmyvAABAQEAAgICAAMDAwAERERABYWFgAcHBwA
IiIiACkpKQBVVVUATU1NAEJCQgA5OTkA/3yAAP9QUADWAJMAzOz/AO/WxgDn59YAramQADMA
AABmAAAAmQAAAMwAAAAAMwAAMzMAAGYzAACZMwAAzDMAAP8zAAAAZgAAM2YAAGZmAACZZgAA
zGYAAP9mAAAAmQAAM5kAAGaZAACZmQAAzJkAAP+ZAAAAzAAAM8wAAGbMAACZzAAAzMwAAP/M
AABm/wAAmf8AAMz/AAAAADMAMwAzAGYAMwCZADMAzAAzAP8AMwAAMzMAMzMzAGYzMwCZMzMA
zDMzAP8zMwAAZjMAM2YzAGZmMwCZZjMAzGYzAP9mMwAAmTMAM5kzAGaZMwCZmTMAzJkzAP+Z
MwAAzDMAM8wzAGbMMwCZzDMAzMwzAP/MMwAz/zMAZv8zAJn/MwDM/zMA//8zAAAAZgAzAGYA
ZgBmAJkAZgDMAGYA/wBmAAAzZgAzM2YAZjNmAJkzZgDMM2YA/zNmAABmZgAzZmYAZmZmAJlm
ZgDMZmYAAJlmADOZZgBmmWYAmZlmAMyZZgD/mWYAAMxmADPMZgCZzGYAzMxmAP/MZgAA/2YA
M/9mAJn/ZgDM/2YA/wDMAMwA/wAAmZkAmTOZAJkAmQDMAJkAAACZADMzmQBmAJkAzDOZAP8A
mQAAZpkAM2aZAGYzmQCZZpkAzGaZAP8zmQAzmZkAZpmZAJmZmQDMmZkA/5mZAADMmQAzzJkA
ZsxmAJnMmQDMzJkA/8yZAAD/mQAz/5kAZsyZAJn/mQDM/5kA//+ZAAAAzAAzAJkAZgDMAJkA
zADMAMwAADOZADMzzABmM8wAmTPMAMwzzAD/M8wAAGbMADNmzABmZpkAmWbMAMxmzAD/ZpkA
AJnMADOZzABmmcwAmZnMAMyZzAD/mcwAAMzMADPMzABmzMwAmczMAMzMzAD/zMwAAP/MADP/
zABm/5kAmf/MAMz/zAD//8wAMwDMAGYA/wCZAP8AADPMADMz/wBmM/8AmTP/AMwz/wD/M/8A
AGb/ADNm/wBmZswAmWb/AMxm/wD/ZswAAJn/ADOZ/wBmmf8AmZn/AMyZ/wD/mf8AAMz/ADPM
/wBmzP8Amcz/AMzM/wD/zP8AM///AGb/zACZ//8AzP//AP9mZgBm/2YA//9mAGZm/wD/Zv8A
Zv//AKUAIQBfX18Ad3d3AIaGhgCWlpYAy8vLALKysgDX19cA3d3dAOPj4wDq6uoA8fHxAPj4
+AD/+/AAoKCkAICAgAD/AAAAAP8AAP//AAAAAP8A/wD/AP///wAAAAAAMAAwAKACFQAEAAAA
NAIAAAQAAAAHAQMAoScAAEELIADMAHgAoAAAAAAA0ALAAwAAAAAoAAAAoAAAAHgAAAABAAgA
AAAAAABLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDA
wADA3MAA8MqmAAQEBAAICAgADAwMABEREQAWFhYAHBwcACIiIgApKSkAVVVVAE1NTQBCQkIA
OTk5AIB8/wBQUP8AkwDWAP/szADG1u8A1ufnAJCprQAAADMAAABmAAAAmQAAAMwAADMAAAAz
MwAAM2YAADOZAAAzzAAAM/8AAGYAAABmMwAAZmYAAGaZAABmzAAAZv8AAJkAAACZMwAAmWYA
AJmZAACZzAAAmf8AAMwAAADMMwAAzGYAAMyZAADMzAAAzP8AAP9mAAD/mQAA/8wAMwAAADMA
MwAzAGYAMwCZADMAzAAzAP8AMzMAADMzMwAzM2YAMzOZADMzzAAzM/8AM2YAADNmMwAzZmYA
M2aZADNmzAAzZv8AM5kAADOZMwAzmWYAM5mZADOZzAAzmf8AM8wAADPMMwAzzGYAM8yZADPM
zAAzzP8AM/8zADP/ZgAz/5kAM//MADP//wBmAAAAZgAzAGYAZgBmAJkAZgDMAGYA/wBmMwAA
ZjMzAGYzZgBmM5kAZjPMAGYz/wBmZgAAZmYzAGZmZgBmZpkAZmbMAGaZAABmmTMAZplmAGaZ
mQBmmcwAZpn/AGbMAABmzDMAZsyZAGbMzABmzP8AZv8AAGb/MwBm/5kAZv/MAMwA/wD/AMwA
mZkAAJkzmQCZAJkAmQDMAJkAAACZMzMAmQBmAJkzzACZAP8AmWYAAJlmMwCZM2YAmWaZAJlm
zACZM/8AmZkzAJmZZgCZmZkAmZnMAJmZ/wCZzAAAmcwzAGbMZgCZzJkAmczMAJnM/wCZ/wAA
mf8zAJnMZgCZ/5kAmf/MAJn//wDMAAAAmQAzAMwAZgDMAJkAzADMAJkzAADMMzMAzDNmAMwz
mQDMM8wAzDP/AMxmAADMZjMAmWZmAMxmmQDMZswAmWb/AMyZAADMmTMAzJlmAMyZmQDMmcwA
zJn/AMzMAADMzDMAzMxmAMzMmQDMzMwAzMz/AMz/AADM/zMAmf9mAMz/mQDM/8wAzP//AMwA
MwD/AGYA/wCZAMwzAAD/MzMA/zNmAP8zmQD/M8wA/zP/AP9mAAD/ZjMAzGZmAP9mmQD/ZswA
zGb/AP+ZAAD/mTMA/5lmAP+ZmQD/mcwA/5n/AP/MAAD/zDMA/8xmAP/MmQD/zMwA/8z/AP//
MwDM/2YA//+ZAP//zABmZv8AZv9mAGb//wD/ZmYA/2b/AP//ZgAhAKUAX19fAHd3dwCGhoYA
lpaWAMvLywCysrIA19fXAN3d3QDj4+MA6urqAPHx8QD4+PgA8Pv/AKSgoACAgIAAAAD/AAD/
AAAA//8A/wAAAP8A/wD//wAA////AP//////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////AP//////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////AP8A/wD/AAD/AP//AP8AAP8AAAAA/wD/AAAA/wAA/wAA/wD/
AP8AAAD/AP8AAP8AAAAAAP8A/wD/////////////////////////////////////////////
//////////////////////////////////////////////////8AAAD/AAD/////AP//////
/////////////////////wD/AP8A/wD/AAD/////AP///wAAAP///wAAAP////////8A////
AAAA/wAAAP//AP//////AP8A////////////////////////////////////////////////
////////////////////////////////////////////////AP8A/wAA//8AAAAA////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////////////wD/
/////////////////////////////////////////////////wD/////////////////////
////////////AP//////////////////////////////////////////////////////////
//////////////////////////////////////////////8A//////////////////8A////
//////////////////////////////////////////////8A////////////////////////
/////////wD/////////////////////////////////////////////////////////////
////////////////////////////////////////////AP//////////////////AP//////
////////////////////////////////////////////AP//////////////////////////
//////8A/////////////////////////////wD//wD/////////////////////////////
/////////////////////////////////////////wD//////////////////wD/////////
/////////////////////////////////////////wD/////////////////////////////
////AP8AAAAA/wAAAP8AAAAAAP8A/wAA//8AAAAA/wD/AAD/AP//////////////////////
//////////////////////////////////////8A//////////////////8A////////////
//////////////////////////////////////8A////////////////////////////////
/wD/AAD/AP8AAP//AAD/////AP8AAP8AAP//AP////8A////////////////////////////
////////////////////////////////////AP//////////////////AP8AAAAAAP8AAAAA
AP8A/wAAAP8AAAAA////////////////////AP////////////////////////////////8A
////////////////////////////////////////////////////////////////////////
/////////////////////////////////wD//////////////////wD/////////////////
/////////////////////////////////wD/////////////////////////////////AP//
////////////////////////////////////////////////////////////////////////
//////////////////////////////8A//////////////////8A////////////////////
//////////////////////////////8A/wAAAP8AAP8A/wD/AP8A/wD//wD/AP///wD/////
AP////////////////////////////8A////////////////////////////////////////
////////////////////////////AP//////////////////AP+BgYGBgYGBgYGBgYGBgYGB
gYH/////////////////////////AP8A/wD/////AP8A/wD///8A//8A/wAA//8A/wAAAAD/
AP8AAAAAAAAA/wD/AP8A//8AAAD/AAD/AAAA/wD/////////////////////////////////
/////////////////////////wD//////////////////wD/////////////////////////
/////////////////////////wD/////////////////////////////////AP///wAA/wD/
////AAAAAP///wD/////AAD//wAA////AP//////////////////////////////////////
//////////////////////8A//////////////////8A/4GBgYGBgYGBgYGBgYGBgYGBgYGB
gYGBgYGB//////////////8A/////////////////////////////////wD/////////////
//////////8A////////////////////////////////////////////////////////////
////////////////////AP//////////////////AP+BgYGBgYGBgYGBgYGBgYH/gYH/gYH/
gYGB////////////////AP8AAAD/AP8A/wD/AP///wD//////wAA//8A////AP8AAP8AAAAA
/wAA/wD/AP8AAP//AAD/AP//AAAAAP8AAP8A/wD/AP8A/wAAAP///wAAAP8AAP8A/wAA/wD/
/wD/AP8A/////////wD//////////////////wD/////////////gf+Bgf+B//////+B/4H/
/////////////////wD///////////8A/wD///8A//////8A////AP8AAAD//wD/////AP8A
AP///wD/AP///wAA/////wAA/wD/AAD/AP///wD/////AP//////////AP//AP//AP////8A
/wD///////////8A//////////////////8A////////////////////////////////////
//////////////8A/////////////////////////////////wD/////////////////////
////////////////////////////////////////////////////////////////////////
////////////AP//////////////////AP//////////////////////////////////////
////////////AP////////////////////////////////8A////////////////////////
////////////////////////////////////////////////////////////////////////
/////////wD//////////////////wD/////////////////////////////////////////
/////////wD/////////////////////////////////AP///////////////////////wD/
////////////////////////////////////////////////////////////////////////
//////8A//////////////////8A/wAA/wD/AAD/AAAA/wD/AAD/AP8AAP//////////////
//////8A/wAAAAD/AP8A/wD/AP//AP//////AAD//wD/AP8AAAAAAP8A/wD/AAD/AAAA/wD/
AAD/AP//////////////////////////////////////////////////////////////////
////AP//////////////////AP8A//8A/wD//wD///8A/wAA/wD/AP//////////////////
////AP8A/wD//wD/AP///wD//wD/AP8A/wD///8A/wD/AP////////8A//8A/wD/AP8A//8A
////////////////////////////////////////////////////////////////////////
/wD//////////////////wD/////////////////////////////////////////////////
/wD/////////////////////////////////AP//////////////////////////////////
//////////////////////////////////////////////////////////////////////8A
//////////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//
////////////////AP//////////////////////////////////////////////////AP//
//////////////////////////////8A////////////////////////////////////////
/////////////////////////////////////////////////////////////////wD/////
/////////////wD//////////////////////////////////////////////////wD/////
////////////////////////////AP8AAAAA/wAAAP8AAAAAAP8A/wAA//8AAAAA/wAAAP8A
AAAAAAAA/wAA/wAAAP8A/wD/AAD/AP8A/wD/AAD/AP8AAAD/AP////////////8A////////
//////////8A//////////////////////////////////////////////////8A////////
/////////////////////////wD/AAD/AP8AAP//AAD/////AP8AAP8A//8AAP8AAAD//wD/
/wD/AP////8A/wD///8A/wAA/wD//////////wD/////////////////////AP//////////
////////AP//////////////////////////////////////////////////AP//////////
//////////////////////8A////////////////////////////////////////////////
/////////////////////////////////////////////////////////wD/////////////
/////wD//////////////////////////////////////////////////wD/////////////
////////////////////AP//////////////////////////////////////////////////
//////////////////////////////////////////////////////8A////////////////
//8A//////////////////////////////////////////////////8A////////////////
/////////////////wD///////////8A////////////////////////////////////////
////////////////////////////////////////////////////AP//////////////////
AP//////////////////////////////////////////////////AP//////////////////
//////////////8A////AAAAAAD/AP8A/wAA/wD/AAD/AAAA/wD/AAAA/wD/AAD//wD/AAD/
AP8AAAD/AP///////////////////////////////////////wD//////////////////wD/
/////////////////////////////////////////////////wD/////////////////////
////////////AP8AAAD//wAA/wD/AP8A//////8A//8AAP///wAAAP8A//8A//8A//8A/wD/
//8A/wD///////////////////////////////////////8A//////////////////8A////
//////////////////////////////////////////////8A////////////////////////
/////////wD/////////////////////////////////////////////////////////////
////////////////////////////////////////////AP//////////////////AP//////
////////////////////////////////////////////AP//////////////////////////
//////8A////////////////////////////////////////////////////////////////
/////////////////////////////////////////wD//////////////////wD/////////
/////////////////////////////////////////wD/////////////////////////////
////AP8AAAD//wAAAP8AAAAAAP//////////////////////////////////////////////
//////////////////////////////////////8A//////////////////8A/wAAAP8AAAAA
AAAAAAAA/wAA/wAA/wAAAAD///////////////8A////////////////////////////////
/wD///////8A/wD//wD/AAD/////////////////////////////////////////////////
////////////////////////////////////AP//////////////////AP//////////////
////////////////////////////////////AP////////////////////////////////8A
////////////////////////////////////////////////////////////////////////
/////////////////////////////////wD//////////////////wD/gYGBgYGBgYGBgYGB
gYGBgYGBgYGBgYGBgYGBgYGB/////////wD/////////////////////////////////AP//
////////////////////////////////////////////////////////////////////////
//////8A//////////////////////8A//////////////////8A/4GBgYGBgYGBgf+B/4GB
/4GBgYGBgf+BgYH/gYGB//////////8A/////////////////////////////////wD/AP8A
/wD/AP8A/wAAAAD/AP8AAP8AAP8AAP8A/wAAAP8A/wD/AP8A/wAA//8A/wAA/wD/AAD/AP8A
AAD/AP8A/wD/////////////////AP//////////////////AP//////////////gf+B////
/4H/////gf+B/4H/////////////AP////////////////////////////////8A/wD///8A
/wD/AP///wD//wD/AAD/AP//////AP//AAD///8A/wD/AP//AP//AP8AAP////8A////AP//
/wD/AP///////////////////wD//////////////////wD/////////////////////////
/////////////////////////wD/////////////////////////////////AP//////////
////////////////////////////////////////////////////////////////////////
//////////////////////8A//////////////////8A////////////////////////////
//////////////////////8A/////////////////////////////////wD/////////////
//////////////////8A//////////8A/////////////////////////////////////wD/
////////////////////AP//////////////////AP8AAP8AAP//AP8AAAAA/wD/////////
////////////////////AP8AAAAA/wD/AP8A/wD//wD/AP8A//////8A/wAAAP8AAP8A/wD/
AP8AAAAAAP8A/wAAAP8A/wAA/wD/AP8AAAD/AP8A/wAAAP8AAAD/AAAA/wAA/wD/AP8A/wD/
/////////////////wD//////////////////wD/AP////8A/wD///8AAP8A////////////
/////////////////wD/AP8A//8A/wD///8A//8A/wD/AP//////AP8AAAD/AAD///8A/wD/
AAAAAP//AP8A/wD/AP//AP///wD//wD/AAD///8AAAD/AAD//wAA//////8A////AP//////
//////////////8A//////////////////8A////////////////////////////////////
//////////////8A/////////////////////////////////wD/////////////////////
////////////////////////////////////////////////////////////////////////
////////////AP//////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD//////////////////wD/////////////////////////////////////////
/////////wD/////////////////////////////////AP//////////////////////////
/////////////////////////////////////////////////////////wD/////////////
//////8A//////////////////8A////////////////////////////////////////////
//////8A/////////////////////////////////wD/AAAAAP8AAAD/AAAAAAD/AP8A/wAA
AP//AP8AAAAA/wD/AP8AAP8AAAAAAAAA/wAAAP//AP8A/wD/AP8AAP8AAP8A////////////
////AP//////////////////AP//////////////////////////////////////////////
////AP////////////////////////////////8A/wAA/wD/AAD//wAA/////wD/AAAA////
/wD/AP///////wD/////AP8A//8AAP//AP////////8A/wD/AP//AAD/////////////////
/wD//////////////////wD/////////////////////////////////////////////////
/wD/////////////////////////////////AP//////////////////////////////////
//////////////////////////////////////////////////////////////////////8A
//////////////////8A//////////////////////////////////////////////////8A
/////////////////////////////////wD/////////////////////////////////////
////////////////////////////////////////////////////////////////////AP//
////////////////AP//////////////////////////////////////////////////AP//
//////////////////////////////8A//////////////8A////////////////////////
/////////////////////////////////////////////////////////////////wD/////
/////////////wD//////////////////////////////////////////////////wD/////
////////////////////////////AP8A/wD/AP//AAAAAP8A/wD/AAAAAAD/AP//AAAAAP8A
AP8AAP////////////////////////////////////////////////////////8A////////
//////////8A//////////////////////////////////////////////////8A////////
/////////////////////////wD/AP8A/////wD//wD/AP8A/wAAAAAA/////wAA/wD/AP//
AP//////////////////////////////////////////////////////////AP//////////
////////AP//////////////////////////////////////////////////AP//////////
//////////////////////8A////////////////////////////////////////////////
/////////////////////////////////////////////////////////wD/////////////
/////wD//////////////////////////////////////////////////wD/////////////
////////////////////AP////////////////////////////////////8A////////////
/wD///////////////////////////////////////////////////8A////////////////
//8A//////////////////////////////////////////////////8A////////////////
/////////////////wD/AP8AAAD/AP8A/////wD/AAD/AAAA/wAA/wD/AP8A/wD/AP8AAAAA
AP8AAAAA/wAAAP//AAAAAAAA/wAAAP8A/wAA/wD//wD/////////AP//////////////////
AP+BgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGB////////////////AP//////////////////
//////////////8A/wD/AP8A////AP//AAAA//8A////AP8AAP///wD/AP8A//////8AAAD/
////AP8A/////wAA////////AAD///////8A//8A/////////wD//////////////////wD/
/////////////////////////////////////////////////wD/////////////////////
////////////AP//////////////////////////////////////////////////////////
//////////////////////////////////////////////8A//////////////////8A/4GB
gYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgf////////////8A////////////////////////
/////////wD/////////////////////////////////////////////////////////////
////////////////////AP//////////////////////AP//////////////////AP+BgYGB
gYGBgYH/gf+Bgf+B/4GB/4GB/4GBgf//////////////AP//////////////////////////
//////8A/wD/AP8A/wD/AP8AAAAA/wD/AAD/AAD/AAD/AP8AAAD/AP8A/wD/AP8AAP//AP8A
AP8A/wAA/wD/AAAA/wD/AP8A/////////////////wD//////////////////wD/////////
/////4H/gf//gf+Bgf//gf+B/////////////////wD/////////////////////////////
////AP8A////AP8A/wD///8A//8A/wAA/wD//////wD//wAA////AP8A/wD//wD//wD/AAD/
////AP///wD///8A/wD///////////////////8A//////////////////8A////////////
//////////////////////////////////////8A////////////////////////////////
/wD/////////////////////////////////////////////////////////////////////
////////////////////////////////////AP//////////////////AP//////////////
////////////////////////////////////AP////////////////////////////////8A
////////////////////////////////////////////////////////////////////////
/////////////////////////////////wD//////////////////wD/////////////////
/////////////////////////////////wD/////////////////////////////////AP//
/////////////////////wD/////////////////////////////////////////////////
//////////////////////////////8A//////////////////8A/wAA/wD/AAAA/wD/AP//
/wD///////////////////////////8A/wD/AP8A//8A/wD/AP8AAP///////////wD/AP8A
AAAAAP8A/wD/AAD/AAAA/wD/AAD/AP//////////////////////////////////////////
////////////////////////////AP//////////////////AP8A//8A/wD/AP8A/wD/AP8A
////////////////////////////AP8A/wD///8AAP8A/wD/AP////////////8A/wD/AP//
//////8A//8A/wD/AP8A//8A////////////////////////////////////////////////
/////////////////////////wD//////////////////wD/////////////////////////
/////////////////////////wD/////////////////////////////////AP//////////
////////////////////////////////////////////////////////////////////////
//////////////////////8A//////////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAP//////////////////AP//////////////////////////////
////////////////////AP////////////////////////////////8A////////////////
////////////////////////////////////////////////////////////////////////
/////////////////wD//////////////////wD///////8A////////////////////////
/////////////////wD/////////////////////////////////AP//////////////////
////AP//////////////////////////////////////////////////////////////////
//////////////8A//////////////////8A/wD/AAAAAAAAAP8AAP8AAP//////////////
//////////////8A/wD/AAD/AP8A/////////////////////wD/AP8A/wAA/wD/AAD/AAAA
AAAA////////////////////////////////////////////////////////////////////
////////////AP//////////////////AP8AAAD//wAAAAD/AP//AP//////////////////
////////////AP8AAAAA/wAA//////////////////////8A/wAAAP8A//8A/wAAAAAAAP8A
AP//////////////////////////////////////////////////////////////////////
/////////wD//////////////////wD/////////////////////////////////////////
/////////wD/////////////////////////////////AP//////////////////////////
////////////////////////////////////////////////////////////////////////
//////8A//////////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAP//////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////+np6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en
p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en////////////////////
////////////////////////////////////////////////////////////////////////
////////////////p6f/p6enp///p6enp///p6enp6enp/+n/6f//6enp/+np6en//+np///
p6en/6f//6f/p6en/6enp6enp///p/+np6enp6f/p6f/p6f/p///////////////////////
////////////////////////////////////////////////////////////////////////
/////////////6en/6enp6f//6enp6f//6enp6enp6f/p/+n//+n/6f/p6enp///p6f//6en
//+n/6en/6enp/+np6en/6f//6f//6enp6en/6en/6enp6f/////////////////////////
////////////////////////////////////////////////////////////////////////
//////////+n/6f//6en/////////////6enp///////////////////////////////////
p/+np/////////+n//+n//+n/6enp6enp/+np/+np/+n////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////D/+LD3v/e4v/iw97/////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////+Ld3cLdwrzc3bzd4sP/////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////97Cu7u7vNe71ru73d7/////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////D3LvX3Lu7u7Xctbvi////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////3uK83bzdvN283Lzew97/////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////97CvNzC3cLd3d3C3eLe////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////dtbS0tbrWuru1tLW74v//////////////////////////////////
/////wAA/////////////////////wAA////////////////////////////AP//////////
////////////////////////////////////////////////////////////////////////
////////////////u4uLkM/Pi62RrZCttP//////////////////////AAAA//8A//8AAAD/
/wAAAP8AAAAAAP8AAAD/AAD/AP8AAAD//wAAAAAA//8AAAD//wAA/wAA/wD/AAAA/wAA/wAA
/wAA////////////////////////////////////////////////////////////////////
/////////////9ytiq2zrYrPs62ni7Te/////////////////////wAAAAD/AP//AAAAAP8A
AAD/AAAAAAD/AAAA//8A/wD/AAAAAP8AAAAAAP//AP8AAP8AAP//AP8AAAD/AP8AAP8AAAAA
AP//////////////////////////////////////////////////////////////////////
//////////+7i4utka2Li7OQioqR3f////////////////////8A/////wD/////AP//////
////AP8A////AP8AAP8A//////////8A////////////////AAD//////wD/////////////
////////////////////////////////////////////////////////////////////////
////////u62QrbStp63Pi6ytteL/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////7zPkc+0tJG0tM+0kbXi////////////////////////////////////////////////
//////8AAP///////////////////////////////////////////wAA////////////////
////////////////////////////////////////////////////////////////////////
//+8ra2ztM+tkLSQra20w/////////////////////8AAP8A/wAAAP8AAAD/AAAAAAD//wAA
AP//AAAAAP8A//8A//8AAAD//wAAAAAAAAD/AAAAAAD/AAAA//8AAP8AAAD/AP8AAP8AAP8A
AAAAAP//////////////////////////////////////////////////////////////////
3Iusi5CzipCti62LtN3/////////////////////AP8AAAAAAAD/AAD//wD/AAAAAP8A/wAA
/wAAAAD/AAD//wD/AP8A//8A//8AAAD//wAAAAAA/wD/AAD/AAD/AAAA/wAAAAD/AP//AP//
AAD//wD//////////////////////////////////////////////////////////////7WL
hovPkYuLka2Ki5Hi/////////////////////wD/AP//AP//////////////AP//////////
////////////////////AAAA//////8A//8AAP//////////////AP///////////wAA/wAA
//8A//////////////////////////////////////////////////////////////+7s4uz
s8+src+LrIu04v//////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////3bS1tLWQ
i66RtZHPu///////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////93d4t3Ws4at
tLzcvN7/////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////i/8Piu7OLi7vd
/+Liw///////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////4v/e4t2Rp6204t7D
3v//////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////97/w+LdtbO0vN7i/+L/
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////wMA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYAAAACQAAAOAA
AAAKAAAA6AAAABcAAADwAAAACwAAAPgAAAAQAAAAAAEAABMAAAAIAQAAFgAAABABAAANAAAA
GAEAAAwAAABVAQAAAgAAAOQEAAAeAAAAFwAAAEJpbGRzY2hpcm1wcuRzZW50YXRpb24AAB4A
AAAHAAAAVkFURUNIAGkDAAAAGVUAAAMAAAA4AAAAAwAAAAIAAAADAAAAAAAAAAMAAAAAAAAA
AwAAAAAAAAADAAAAexAKAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAQA
AAAGAAAAQXJpYWwADwAAAERlZmF1bHQgRGVzaWduAAgAAABGb2xpZSAxAAgAAABGb2xpZSAy
AAwQAAAGAAAAHgAAABgAAABWZXJ3ZW5kZXRlIFNjaHJpZnRhcnRlbgADAAAAAQAAAB4AAAAQ
AAAARW50d3VyZnN2b3JsYWdlAAMAAAABAAAAHgAAAAwAAABGb2xpZW50aXRlbAADAAAAAgAA
AAAAACADAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9I
TElOS1MAAgAAAOQEAABBAAAA2AIAACoAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAA
BwAAAB8AAAAXAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAG8AYwB0AGEAdgBlAC4AbwByAGcA
LwAAAAAAHwAAAAEAAAAAAAAAAwAAAAcAAAADAAAABgAAAAMAAAAAAAAAAwAAAAcAAAAfAAAA
GAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBtAGEAdABoAGMAYQBkAC4AYwBvAG0ALwAAAB8A
AAABAAAAAAAAAAMAAAAHAAAAAwAAAAYAAAADAAAAAAAAAAMAAAAHAAAAHwAAABwAAABtAGEA
aQBsAHQAbwA6AGcAZQByAG0AYQBuAHkAQABtAGEAdABoAHMAbwBmAHQALgBjAG8AbQAAAB8A
AAABAAAAAAAAAAMAAAAHAAAAAwAAAAYAAAADAAAAAAAAAAMAAAAHAAAAHwAAAB4AAABoAHQA
dABwADoALwAvAHcAdwB3AC4AZABlAHIAaQB2AGUALQBlAHUAcgBvAHAAZQAuAGMAbwBtAC8A
AAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAAAaAAAA
aAB0AHQAcAA6AC8ALwB3AHcAdwAuAG0AYQB0AGgAdwBvAHIAawBzAC4AYwBvAG0ALwAAAB8A
AAABAAAAAAAAAAMAAAAHAAAAAwAAAAYAAAADAAAAAAAAAAMAAAAHAAAAHwAAABgAAABoAHQA
dABwADoALwAvAHcAdwB3AC4AdwBvAGwAZgByAGEAbQAuAGMAbwBtAC8AAAAfAAAAAQAAAAAA
AAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAAAYAAAAbQBhAGkAbAB0AG8A
OgBpAG4AZgBvAEAAdwBvAGwAZgByAGEAbQAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAD2DzcAAAAUAAAAX8CR445LAAAfAPQDAwBXAVJBTkZUTEVS
IE1BUlRJTiBIWURSTy1BVC5HSC1FVDMIAAAAUgBBAE4ARgBUAEwARQBSACAATQBBAFIAVABJ
AE4AIABIAFkARABSAE8ALQBBAFQALgBHAEgALQBFAFQAMwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAA=
--------------090802010006030400040109--

\start
Date: Tue, 19 Apr 2005 10:21:34 -0500
From: MathAction (mdc)
To: MathAction
Subject: [#148 Down-arrow button in examples can crash session] (new) Down-arrow button in examples can crash session

Axiom 3.4 (April 2005), compiled and running under SuSE 9,2,

This is an intermittent fault, happening more than half the time. Occurs 
when logged in at console, also when logged in by ssh with X-forwarding 
(from SuSE 9.1), and from a Win PC by Hummingbird exceed. Nothing is 
logged in .xsession-errors.

Details:
Axiom is
______________________________________________________________________

                        AXIOM Computer Algebra System 
                       Version: Axiom 3.4 (April 2005)
               Timestamp: Tuesday April 19, 2005 at 13:46:32 
______________________________________________________________________
O/S is
_______________________________________________________________________
mdc@bmnew:~> uname -a
Linux bmnew 2.6.8-24.14-smp #1 SMP Tue Mar 29 09:27:43 UTC 2005 i686 i686 
i386 GNU/Linux
mdc@bmnew:~> cat /etc/SuSE-release 
SuSE Linux 9.2 (i586)
VERSION = 9.2
______________________________________________________________________
Environment is
______________________________________________________________________
mdc@bmnew:~> echo $AXIOM
/usr/local/axiom/mnt/linux
mdc@bmnew:~> export PATH=${AXIOM}/bin:$PATH
______________________________________________________________________
And a run looks like...
______________________________________________________________________
mdc@bmnew:~> axiom
                        AXIOM Computer Algebra System 
                       Version: Axiom 3.4 (April 2005)
               Timestamp: Tuesday April 19, 2005 at 13:46:32 
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------
 
   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase
(1) -> 
(1) -> )q
   Please enter y or yes if you really want to leave the interactive 
      environment and return to the operating system:
y


mdc@bmnew:~> 
__________________________________________________________________________
Actions to reproduce fault:
1) Start axiom, as above.
2) In HyperDoc window, click on "Examples", then in next window on 
"Graphics", then on "Assorted Examples". Now click on the first down-arrow 
icon, following "Function of two variables: z=f(x,y)". (Also happens for 
other examples, of course.)

More than half the time, all windows vanish, except for the initial 
terminal window (in which one typed "axiom").

There are no error messages.

HOWEVER: If instead of clicking on the down-arrow, one clicks on the 
"draw" command next to it, the command executes in a new terminal window 
without problem. Clicking on the down-arrow subsequently displays the 
graph in-line, with no crash.

Also, typing that draw command into the original terminal window, one gets 
a plausible graph. 
__________________________________________________________________________

Have fun,
	Cheers, Mark.


+---------------------------------------------------------------------------+
|  Dr M.D. Cahill, Dept. of Computer Science, Tel. +44 (0)1225 383084       |
|  University of Bath, BATH, BA2 7AY.         Fax. +44 (0)1225 383493       |
|  Mark Cahill                                  |
+---------------------------------------------------------------------------+

\start
Date: Sun, 24 Apr 2005 18:18:58 +0200
From: Gregory Vanuxem
To: list
Subject: page.axiom-developer.org not resolved (DNS)

Hi,

In a shell (and in any browser too):

greg@ellipse:~$ host page.axiom-developer.org
Host page.axiom-developer.org not found: 2(SERVFAIL)

Am I alone with this problem ?

\start
Date: Mon, 25 Apr 2005 11:25:47 -0400
From: Bill Page
To: Greg Vanuxem
Subject: Re: page.axiom-developer.org not resolved (DNS)

Vanuxem Gregory

http://page.axiom-developer.org seems to be working fine for me this 
morning.
Perhaps it was an intermittant problem or maybe you have a local domain name
server configuration problem on your network?

Regards,
Bill Page.

Vanuxem Gregory wrote:

>Hi,
>
>In a shell (and in any browser too):
>
>greg@ellipse:~$ host page.axiom-developer.org
>Host page.axiom-developer.org not found: 2(SERVFAIL)
>
>Am I alone with this problem ?

\start
Date: Tue, 26 Apr 2005 09:00:44 -0500
From: MathAction (loli)
To: MathAction
Subject: [#149 filling in templates] (new) 

I installed April Sources in two PC using Suse 9.2.
In one of them I can use AXIOM Hyperdoc Top Level facilities, Basic Commands, ...   filling in templates, changing what is offered there and everythig works rigth; in the other I cant fill in templates.
Can you help me how to search where the problem is? 
I am a very new AXIOM's user but I already beleive AXIOM is great.

\start
Date: 26 Apr 2005 10:16:23 -0400
From: Camm Maguire
To: Tim Daly
Subject: Possible GCL 2.6.7 for axiom
Cc: Mike Thomas

Hi Tim!  Great conference!

Here's my take home understanding of the remaining issues re:
gcl/axiom:

1) reenable run-process
2) display images in tcl/tk
3) tcl/tk working in windows
4) Windows socket workaround for sman/hypertex/graphics

These might go into a quick 2.6.7 GCL release.

5) axiom configure script

There are a few math bugs in addition for which I'd like to propose
fixes and test.  Should I make a tla branch?  If so, what should it be
called? 

\start
Date: Tue, 26 Apr 2005 16:36:37 +0200
From: Martin Rubey
To: Camm Maguire
Subject: Re: conference

Camm Maguire writes:
 > Hi Tim!  Great conference!

So, what happened?

 > There are a few math bugs in addition for which I'd like to propose fixes
 > and test.  

\start
Date: 26 Apr 2005 11:04:15 -0400
From: Camm Maguire
To: Tim Daly
Subject: Website edit notifications

Greetings!  May I please suggest that we create a special list for
these automated wiki edit notifications?  Perhaps axiom-wiki?

The wiki is magnificent!  Great work all!

\start
Date: Tue, 26 Apr 2005 11:58:44 -0500
From: MathAction (Page, Bill)
To: MathAction
Subject: RE: conference

On Tuesday, April 26, 2005 10:37 AM Martin Rubey wrote:

>Camm Maguire writes:
> > Hi Tim!  Great conference!
>
> So, what happened?

I attended both the pre-conference (sprint) day and the main
conference. The two days seemed to go by very quickly which
for me usually means that it was interesting, worthwhile, but
that there was too much to do in too little time. While it is
still fresh in my mind I will try to list below some of the
things that stood out for me and I hope other participants
will add their comments as well. 

I will let Tim report on the actual statistics, but I think
the conference was quite well attended, considering that it
was the first ever meeting about the new open source version
of Axiom. We had about 7 or 8 people the first day and somewhere
between 30-50 people the second day.

The City College campus was a great venue. The apple and cherry
blossoms highlighted the wonderfully maintained historical
buildings which seemed to me to blend well with those of more
modern architecture and the distant backdrop of New York city
skyscrapers ... (there that is the extent of my capacity for
poetic imagery :). Plus I would like to say thank you to
Gilbert Baumslag and Bernice Ravitz for their generous
hospitality.

The discussion on the sprint day was lead by Tim Daly and
revolved around future directions and the larger, longer term
context in which open source Axiom will develop. For those
people who have been following the discussion here on the
Axiom-developer list for the last two years, much of what we
discussed would have seemed familiar. We talked about many
things, but here as some that come immediately to mind:

- literate programming and documentation, pamphlet format
  files (noweb) and implementation on the web

- mathematical versus program correctness and relationship
  to proof systems like ACL2,

- user interfaces, both desktop and web-based; and their
  integration (the doyen project)

I am sure we can add other things to this list. It did seem to
me however that (as usual and normal in an open source project)
we did not really make any firm decisions. We have many more
ideas for projects and research than there are available
resources.

During the latter part of the day we spent some time on more
technical issues such as the role of GCL in support of platform
independent graphics (for both Linux/Unix and Windows). Tim
demonstrated a possible Java-based solution but I think the
idea of adding a Java dependency to Axiom motivated all of us
to think of ways that this could be achieved more directly with
GCL and tcl/tk.

I also helped set up a Windows development environment for
Axiom on one of the workstations in the open source development
lab. Tim and I worked (without a complete resolution) on a
problem of building the new Axiom book volumes from the tla
archives in the Windows environment. There seems to be an
issue with noweb even though it works properly for building
Axiom from source on Windows.

The main conference day was to be devoted to applications of
Axiom. Perhaps there was not enough discussion of actually
applications, however William Sit did give some examples of the
using Axiom "for both fun and research" and during part of my
talk (which was mainly about the MathAction website and how it
supports both Axiom development and Axiom users) I did point
out the work on "guessing integer sequences" that Martin Rubey
has posted on www.axiom-developer.org

Tim Daly opened the conference with an overview of Axiom and
the concept of the "30 Horizon": 30 years back from a historical
perspective and 30 years forward. He gave reasons why we might
believe that Axiom will still be actively used and developed
30 years from now and what we might be able to do now to help
ensure this.

Richard Fateman discussed the "state-of-the-art" in what one
might call the "artificial intelligence view" of computer algebra
systems, he pointed out that although current systems like Axiom,
Maxima and commercial systems like Mathematica and Maple are
useful for symbolic computation, they are still a long way from
being "artificial mathematicians". I think also that with his
analogy of a "mathematical golem", Richard might have also been
trying to suggest that the goal of creating artificial
mathematicians might not be such a good idea. :)

Camm Maquire gave a talk on the history and potential of open
source software. To me this was a bit of a surprise given Camm's
specific and detailed technical contributions to both GCL and
Axiom, but at a conference focused on **applications** I think
these are issues that need to be addressed. How can we convince
academic and commercial budget managers that open source can
compete effectively with commercial products when the economics
and motivations are so different?

In all of the talks there seemed to be a common thread of the
need for collaboration - between Axiom developers; among Axiom
users and between mathematicians and the Axiom system. I think
there was a general agreement that in the open source Axiom
project so far we have achieved some significant steps in the
right direction but that there remains a lot more to do.

Finally, I want to add a special personal thanks to Richard
Fateman for solving a last minute technical problem with
network access to the axiom-developer.org website by the
loan of his laptop computer and wireless Internet connection.
Without his help I don't think I could have given a particularly
convincing verbal demonstration of the potential for the
MathAction website to support the kinds of collaboration that
Axiom needs.

\start
Date: Tue, 26 Apr 2005 22:51:21 +0200
From: Gregory Vanuxem
To: list
Subject: Re: page.axiom-developer.org not resolved (DNS)

Hi,

That seems right now, thanks.

Le dimanche 24 avril 2005 =E0 18:18 +0200, Vanuxem Gr=E9gory a =E9crit :
> Hi,
> 
> In a shell (and in any browser too):
> 
> greg@ellipse:~$ host page.axiom-developer.org
> Host page.axiom-developer.org not found: 2(SERVFAIL)
> 
> 
> Am I alone with this problem ?

\start
Date: Tue, 26 Apr 2005 20:45:50 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Possible GCL 2.6.7 for axiom
Cc: Mike Thomas

On Tuesday, April 26, 2005 10:16 AM Camm Maguire wrote:

> Hi Tim!  Great conference!

I second that!

> Here's my take home understanding of the remaining issues
> re: gcl/axiom:
>
> 1) reenable run-process
> 2) display images in tcl/tk
> 3) tcl/tk working in windows
> 4) Windows socket workaround for sman/hypertex/graphics

This is consistent with my recollection of our discussions
during the Axiom sprint session. And I am willing to help
with testing and debugging on the Windows platform.

But we should be clear I think, that this is not necessarily
the shortest path to a fully functioning version of Axiom on
Windows. The linux version of Axiom does not now use tcl/tk
for Graphics and Hypertex, i.e. those parts of Axiom that are
not already ported to Microsoft Windows. Instead these currently
depend directly on the X windows libraries. These should perhaps
be re-implemented in tcl/tk linux first before attempting the
port to Windows.

Because of this X windows dependency the shortest path,
though admittedly not necessarily the best path, for fully
implementing Axiom on Windows would probably be to use Cygwin.
Currently GCL on windows uses MinGW instead of Cygwin to
compile to native Windows but unlike Cygwin MinGW does not
provided an X windows compatible environment.

I think using native Windows applications on Windows is a
wothwhile target but it is sometimes hard for applications
that originate on linux/Unix.

In principle it is possible to continue to compile AXIOMsys
as a native Windows application and to run the Hypertex and
Graphics components of Axiom under Cygwin. This would make
it unnecessary to convert any already working code to tcl/tk.
As I understand it, these additional components of Axiom
currently only require a Unix-compatible C programming
environment. So all we would need for this alternative is
step 4) above - socket compatibility between the current
native Windows version of GCL and the additional C code
compiled under Cygwin.

Of course there are drawbacks. Using *both* MSYS/MinGW and
Cygwin under Windows would further complicate the Windows
build environment for Axiom. Currently there is no Cygwin
version of GCL. Further, the X windows user interface under
Cygwin might seem a little awkward for some Microsoft
Windows users. But it should still be possible to prepare an
auto-installation binary distribution that would make much
of this transparent for users who are not interested in
building Axiom from source.

>
> These might go into a quick 2.6.7 GCL release.

However perhaps there are other reasons which would also
motivate the development of GCL tcl/tk on Microsoft Windows.

> 
> 5) axiom configure script
> 

Yes! I think that would be a great step forward. I think
Axiom should conform more closely to the de facto norm
for building open source software.

> There are a few math bugs in addition for which I'd like
> to propose fixes and test.  Should I make a tla branch?
> If so, what should it be called?

I don't think a special tla branch would be necessary
unless you contemplate drastic changes to Axiom's algebra.
(I think there is already a tla branch for that purpose.
See http://page.axiom-developer.org/zope/mathaction/ArchUsage )

If you are just testing and proposing fixes you can do that
on a local copy of Axiom and then post them to IssueTracker
on www.axiom-developer.org This would allow other people to
test them and then they could be incorporated into the main
distribution.

\start
Date: Tue, 26 Apr 2005 18:39:21 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Possible GCL 2.6.7 for axiom
Cc: Mike Thomas

--- Bill Page wrote:
> But we should be clear I think, that this is not necessarily
> the shortest path to a fully functioning version of Axiom on
> Windows. The linux version of Axiom does not now use tcl/tk
> for Graphics and Hypertex, i.e. those parts of Axiom that are
> not already ported to Microsoft Windows. Instead these currently
> depend directly on the X windows libraries. These should perhaps
> be re-implemented in tcl/tk linux first before attempting the
> port to Windows.

I wasn't able to attend the conference :-(, and in discussing this
possibility I'm admittedly skating on vapor trails and assuming skills
I don't currently have, but if at some point in the future a QT4
backend was written for McCLIM and somebody (me for the sake of
discussion anyway) implimented a GUI CAS interface in it, would that be
of interest to Axiom?  QT4 will be available as GPL for both Windows
and Linux, which will make it an attractive target for an McCLIM
backend.  (GTK is available but I find myself drawn more toward QT.  Of
course, this doesn't rule out a GTK backend either.  Hehe - maybe one
could write one program with a native look on BOTH KDE and Gnome :-D.) 
I am pondering undertaking a backend attempt once QT4 comes out for the
sake of creating a Maxima GUI which is a) lisp based and b) cross
platform.  If Scigraph can be made to work and be extended as needed,
this would also provide lisp based graphics in a cross platform manner.
 The half-mythical Stix fonts may also be out by then (at long last
their site was updated - drool.) Logically much of this should
translate relatively easily to Axiom - in fact it should mainly be an
issue of translating between McCLIM constructs and Axiom syntax, with
the added non-trivial wrinkle of line breaking.  (Who knows -
McCLIM+QT4 might just become the best thing for cross platform native
GUI programming since Java, if the planets align right :-).  Lisp will
rise once more!)

I suppose I'm biased against tcl/tk but the Maxima experience with it
has not been terribly positive, and it's not what I tend to think of
when I think robust graphics.  Perhaps this is just my lack of
knowledge.
 
> Because of this X windows dependency the shortest path,
> though admittedly not necessarily the best path, for fully
> implementing Axiom on Windows would probably be to use Cygwin.
> Currently GCL on windows uses MinGW instead of Cygwin to
> compile to native Windows but unlike Cygwin MinGW does not
> provided an X windows compatible environment.

True.  MinGW is the best available free solution for stand alone
Windows binaries though, at least to my knowledge.  And Windows users +
X applications, in my experience, does not a happy mix make.

> I think using native Windows applications on Windows is a
> wothwhile target but it is sometimes hard for applications
> that originate on linux/Unix.

Amen.  To both.

[snip partial cygwin solution]

> Of course there are drawbacks. Using *both* MSYS/MinGW and
> Cygwin under Windows would further complicate the Windows
> build environment for Axiom. Currently there is no Cygwin
> version of GCL. Further, the X windows user interface under
> Cygwin might seem a little awkward for some Microsoft
> Windows users. But it should still be possible to prepare an
> auto-installation binary distribution that would make much
> of this transparent for users who are not interested in
> building Axiom from source.
 
It will be HUGE, but yes, that might be workable.  I can't imagine how
Windows users would react to an Xlib base GUI - GTK is bad enough. 
Still, it's a case of any GUI being much better than none, and recent
versions of Cygwin X can at least operate on a per-window basis rathern
than desktop only, so in theory it should work.

[snip]

> Yes! I think that would be a great step forward. I think
> Axiom should conform more closely to the de facto norm
> for building open source software.

I'll second that!  The make install process still goes wonky for me on
Gentoo, and I have seen a second report of the same behavior so it's
probably not just my screwed up system.
 
\start
Date: Tue, 26 Apr 2005 21:39:24 -0500
From: MathAction (unknown)
To: MathAction
Subject: [DesignIssues] Expression Integer type

I tried to put this on my wiki home page, but I have no idea if it was successful or not.

Why do the following have Expression Integer type when they aren't integers:

\begin{axiom}
sin(x)
\end{axiom}

\begin{axiom}
asin(1)
\end{axiom}

\begin{axiom}
sqrt(%pi)
\end{axiom}

\start
Date: Tue, 26 Apr 2005 21:55:04 -0500
From: Tim Daly
To: list
Subject: axiom graphics and porting

I've tried 3 paths so far.

First I tried to find an X library that runs natively on windows
without success. So I started working on one and realized that I
didn't know enough of the Microsoft C API to manage it.

Second I tried to use TK as the front end. I was unable to get
the TK front end to display graphics and was unable to find the
source code (since remedied by Camm).

Third I tried to use McClim. I want to use a lisp-based front end
and this was my best hope. Unfortunately I was unable to get it to 
work. 

Finally I wrote a TK-equivalent program in Java. Since it is cross
platform it will run on linux and windows. I have a small working
demonstration for the browser.

The plan is to rewrite the browser and graphics in common lisp and
use a socket based message passing to communicate. The common lisp
rewrite would make it so much easier to port. And the command 
language for the front end could be easily modified to fit the 
choice of front end (TK, Java, McClim).

I'm unhappy about the need for Java and would much prefer McClim.

GCL does not seem to handle run-process correctly so I've been using
CLISP. The browser and the graphics run in their own process anyway
so Axiom under GCL can talk to McClim under CLISP.

\start
Date: Wed, 27 Apr 2005 14:13:44 +1000
From: Mike Thomas
To: Tim Daly
Subject: RE: axiom graphics and porting

Hi Tim and Bill.

Several things:

| GCL does not seem to handle run-process correctly

Could you please give us more details?

Without wishing to tell Bill or yourself what to do with your own project
regarding X and/or Cygwin, I think it would be a major mistake to follow
that route for the reasons outlined here:

  http://www.math.utexas.edu/pipermail/maxima/2004/006716.html

I really can't emphasize my personal lack of interest in such a course of
action enough without actually walking off the GCL Windows job (although I
have no such intention thereof at present).

Be aware also that for a couple of years a GCL binding to the Java GUI
library (JAPI) has existed in our CVS and although only ever tested by me on
Windows, should be fine on Unix as JAPI is cross-platform itself.  I've
inserted below an example program from the GCL source tree to give you a
feel for the way it works - it does various graphics and text things
including a simple mandelbrot display and the (extremely) bare bones of a
text editor.  This program is the only Lisp binding documentation in
existence for the library.  The JAPI binding is included in every Windows
GCL binary release.

Having said that, Camm has always been very enthusiastic about GCL/Tk and it
seems to me that it is a good way to go for that reason alone.  Another
(negative) argument in its favour is that JAPI seems to be moribund whereas
TCL/Tk is, of course, very active.

===== japitest.lsp ==========

;;; Japi is a cross-platform, easy to use (rough and ready) Java based
;;; GUI library Download a library and headers for your platform, and
;;; get the C examples and documentation from: http://www.japi.de/
;;; This file shows how to use some of the available functions.  You
;;; may assume that the only functions tested so far in the binding
;;; are those which appear below, as this file doubles as the test
;;; program.  The binding is so simple however that so far no binding
;;; (APART FROM J_PRINT) has gone wrong of those tested so far!  HOW
;;; TO USE THIS FILE (compile-file "c:/cvs/gcl/japitest.lsp") (load
;;; "c:/cvs/gcl/japitest.o") Requires either "java" or "jre" in the
;;; path to work.

(in-package :japi-primitives)

;; Start up the Japi server (needs to find either "java" or "jre" in your
path
(defmacro with-server ((app-name debug-level) . body)
  (multiple-value-bind (ds b)
		       (si::find-declarations body)
		       `(if (= 0 (jpr::j_start))
			    (format t (format nil "~S can't connect to the Japi GUI server."
,app-name))
			  (progn
			    (j_setdebug ,debug-level)
			    ,@ds
			    (unwind-protect
				(progn ,@b)
			      (j_quit))))))

;; Use a frame and clean up afterwards even if trouble ensues
(defmacro with-frame ((frame-var-name title) . body)
  (multiple-value-bind (ds b)
		       (si::find-declarations body)
		       `(let ((,frame-var-name (j_frame ,title)))
			  ,@ds
			  (unwind-protect
			      (progn ,@b)
			    (j_dispose ,frame-var-name)))))

;; Use a canvas and clean up afterwards even if trouble ensues
(defmacro with-canvas ((canvas-var-name frame-obj x-size y-size) . body)
  (multiple-value-bind (ds b)
		       (si::find-declarations body)
		       `(let ((,canvas-var-name (j_canvas ,frame-obj ,x-size ,y-size)))
			  ,@ds
			  (unwind-protect
			      (progn ,@b)
			    (j_dispose ,canvas-var-name)))))

;; Use a text area and clean up afterwards even if trouble ensues
(defmacro with-text-area ((text-area-var-name panel-obj x-size y-size) .
body)
  (multiple-value-bind (ds b)
		       (si::find-declarations body)
		       `(let ((,text-area-var-name (j_textarea ,panel-obj ,x-size
,y-size)))
			  ,@ds
			  (unwind-protect
			      (progn ,@b)
			    (j_dispose ,text-area-var-name)))))

;; Use a pulldown menu bar and clean up afterwards even if trouble ensues
(defmacro with-menu-bar ((bar-var-name frame-obj) . body)
  (multiple-value-bind (ds b)
		       (si::find-declarations body)
		       `(let ((,bar-var-name (j_menubar ,frame-obj)))
			  ,@ds
			  (unwind-protect
			      (progn ,@b)
			    (j_dispose ,bar-var-name)))))

;; Add a pulldown menu and clean up afterwards even if trouble ensues
(defmacro with-menu ((menu-var-name bar-obj title) . body)
  (multiple-value-bind (ds b)
		       (si::find-declarations body)
		       `(let ((,menu-var-name (j_menu ,bar-obj ,title)))
			  ,@ds
			  (unwind-protect
			      (progn ,@b)
			    (j_dispose ,menu-var-name)))))

;; Add a pulldown menu item and clean up afterwards even if trouble ensues
(defmacro with-menu-item ((item-var-name menu-obj title) . body)
  (multiple-value-bind (ds b)
		       (si::find-declarations body)
		       `(let ((,item-var-name (j_menuitem ,menu-obj ,title)))
			  ,@ds
			  (unwind-protect
			      (progn ,@b)
			    (j_dispose ,item-var-name)))))

;; Add a mouse listener and clean up afterwards even if trouble ensues
(defmacro with-mouse-listener ((var-name obj type) . body)
  (multiple-value-bind (ds b)
		       (si::find-declarations body)
		       `(let ((,var-name (j_mouselistener ,obj ,type)))
			  ,@ds
			  (unwind-protect
			      (progn ,@b)
			    (j_dispose ,var-name)))))

;; Use a panel and clean up afterwards even if trouble ensues
(defmacro with-panel ((panel-var-name frame-obj) . body)
  (multiple-value-bind (ds b)
		       (si::find-declarations body)
		       `(let ((,panel-var-name (j_panel ,frame-obj)))
			  ,@ds
			  (unwind-protect
			      (progn ,@b)
			    (j_dispose ,panel-var-name)))))

;; Get a pointer to an array of ints
(defCfun "static void* inta_ptr(object s)" 0
  " return(s->fixa.fixa_self);")
(defentry inta-ptr (object) (int "inta_ptr"))

;; Draw function
(defun drawgraphics (drawable xmin ymin xmax ymax)
  (let* ((fntsize 10)
	 (tmpstrx (format nil "XMax = ~D" xmax))
	 (tmpstry (format nil "YMax = ~D" ymax))
	 (tmpstrwidx (j_getstringwidth drawable tmpstrx)))
    (j_setfontsize drawable fntsize)
    (j_setnamedcolor drawable J_RED)

    (j_drawline drawable xmin ymin        (- xmax 1)      (- ymax 1))
    (j_drawline drawable xmin (- ymax 1)  (- xmax 1)      ymin)
    (j_drawrect drawable xmin ymin        (- xmax xmin 1) (- ymax xmin 1))

    (j_setnamedcolor drawable J_BLACK)
    (j_drawline drawable xmin (- ymax 30) (- xmax 1)      (- ymax 30))
    (j_drawstring drawable (- (/ xmax 2) (/ tmpstrwidx 2)) (- ymax 40)
tmpstrx)

    (j_drawline drawable (+ xmin 30) ymin (+ xmin 30) (- ymax 1))
    (j_drawstring drawable (+ xmin 50) 40 tmpstry)

    (j_setnamedcolor drawable J_MAGENTA)
    (loop for i from 1 to 10
	  do (j_drawoval drawable
			 (+ xmin (/ (- xmax xmin) 2))
			 (+ ymin (/ (- ymax ymin) 2))
			 (* (/ (- xmax xmin) 20) i)
			 (* (/ (- ymax ymin) 20) i)))

    (j_setnamedcolor drawable J_BLUE)
    (let ((y ymin)
	  (teststr "JAPI Test Text"))
      (loop for i from 5 to 21 do
	    (j_setfontsize drawable i)
	    (let ((x (- xmax (j_getstringwidth drawable teststr))))
	      (setf y (+ y (j_getfontheight drawable)))
	      (j_drawstring drawable x y teststr))))))



;; Run a five second frame in a Japi server
(with-server ("GCL Japi library test GUI 1" 0)
	     (with-frame (frame "Five Second Blank Test Frame")
			 (j_show frame)
			 (j_sleep 5000)))


;; Run some more extensive tests
(with-server
 ("GCL Japi library test GUI 2" 0)
 (with-frame
  (frame "Draw")
  (j_show frame)
  (let ((alert (j_messagebox frame "Two second alert box" "label")))
    (j_sleep 2000)
    (j_dispose alert))
  (let ((result1 (j_alertbox frame "label1" "label2" "OK"))
	(result2 (j_choicebox2 frame "label1" "label2" "Yes" "No"))
	(result3 (j_choicebox3 frame "label1" "label2" "Yes" "No" "Cancel")))
    (format t "Requestor results were: ~D, ~D, ~D~%" result1 result2
result3))
  (j_setborderlayout frame)
  (with-menu-bar
   (menubar frame)
   (with-menu
    (file menubar "File")
    (with-menu-item
     (print file "Print")
     (with-menu-item
      (save file "Save BMP")
      (with-menu-item
       (quit file "Quit")
       (with-canvas
	(canvas frame 400 600)
	(j_pack frame)
	(drawgraphics canvas 0 0 (j_getwidth canvas) (j_getheight canvas))
	(j_show frame)
	(do ((obj (j_nextaction) (j_nextaction)))
	    ((or (= obj frame) (= obj quit)) t)
	    (when (= obj canvas)
	      (j_setnamedcolorbg canvas J_WHITE)
	      (drawgraphics canvas 10 10
			    (- (j_getwidth canvas) 10)
			    (- (j_getheight canvas) 10)))
	    (when (= obj print)
	      (let ((printer (j_printer frame)))
		(when (> 0 printer)
		  (drawgraphics printer 40 40
				(- (j_getwidth printer) 80)
				(- (j_getheight printer) 80))
		  (j_print printer))))
	    (when (= obj save)
	      (let ((image (j_image 600 800)))
		(drawgraphics image 0 0 600 800)
		(when (= 0 (j_saveimage image "test.bmp" J_BMP))
		  (j_alertbox frame "Problems" "Can't save the image" "OK")))))))))))))

;; Try some mouse handling
(with-server
 ("GCL Japi library test GUI 3" 0)
 (with-frame
  (frame "Move and drag the mouse")
  (j_setsize frame 430 240)
  (j_setnamedcolorbg frame J_LIGHT_GRAY)
  (with-canvas
   (canvas1 frame 200 200)
   (with-canvas
    (canvas2 frame 200 200)
    (j_setpos canvas1 10 30)
    (j_setpos canvas2 220 30)
    (with-mouse-listener
     (pressed canvas1 J_PRESSED)
     (with-mouse-listener
      (dragged canvas1 J_DRAGGED)
      (with-mouse-listener
       (released canvas1 J_RELEASED)
       (with-mouse-listener
	(entered canvas2 J_ENTERERD)
	(with-mouse-listener
	 (moved canvas2 J_MOVED)
	 (with-mouse-listener
	  (exited canvas2 J_EXITED)
	  (j_show frame)
          ;; Allocate immovable storage for passing data back from C land.
	  ;; Uses the GCL only make-array keyword :static
	  (let* ((xa (make-array 1 :initial-element 0 :element-type 'fixnum :static
t))
		 (ya (make-array 1 :initial-element 0 :element-type 'fixnum :static t))
		 (pxa (inta-ptr xa))
		 (pya (inta-ptr ya))
		 (x 0)
		 (y 0)
		 (get-mouse-xy (lambda (obj)
				 (progn (j_getmousepos obj pxa pya)
					(setf x (aref xa 0))
					(setf y (aref ya 0)))))
		 (startx 0)
		 (starty 0))
	    (do ((obj (j_nextaction) (j_nextaction)))
		((= obj frame) t)
		(when (= obj pressed)
		  (funcall get-mouse-xy pressed)
		  (setf startx x)
		  (setf starty y))
		(when (= obj dragged)
		  (funcall get-mouse-xy dragged)
		  (j_drawrect canvas1 startx starty (- x startx) (- y starty)))
		(when (= obj released)
		  (funcall get-mouse-xy released)
		  (j_drawrect canvas1 startx starty (- x startx) (- y starty)))
		(when (= obj entered)
		  (funcall get-mouse-xy entered)
		  (setf startx x)
		  (setf starty y))
		(when (= obj moved)
		  (funcall get-mouse-xy moved)
		  (j_drawline canvas2 startx starty x y))
		(setf startx x)
		(setf starty y)
		(when (= obj exited)
		  (funcall get-mouse-xy exited)
		  (j_drawline canvas2 startx starty x y))))))))))))))

;; Text editor demo
(with-server
 ("GCL Japi library test text editor" 0)
 (with-frame
  (frame "A simple editor")
  (j_setgridlayout frame 1 1)
  (with-panel
   (panel frame)
   (j_setgridlayout panel 1 1)
   (with-menu-bar
    (menubar frame)
    (with-menu
     (file-mi menubar "File")
     (with-menu-item
      (new-mi file-mi "New")
      (with-menu-item
       (save-mi file-mi "Save")
       (j_seperator file-mi)
       (with-menu-item
	(quit-mi file-mi "Quit")

	(with-menu
	 (edit-mi menubar "Edit")
	 (with-menu-item
	  (select-all-mi edit-mi "Select All")
	  (j_seperator edit-mi)
	  (with-menu-item
	   (cut-mi edit-mi "Cut")
	   (with-menu-item
	    (copy-mi edit-mi "Copy")
	    (with-menu-item
	     (paste-mi edit-mi "Paste")

	     (with-text-area
	      (text panel 15 4)
	      (j_setfont text J_DIALOGIN J_BOLD 18)
	      (let ((new-text (format nil "JAPI (Java Application~%Programming
Interface)~%a platform and language~%independent API")))
		(j_settext text new-text)
		(j_show frame)
		(j_pack frame)
		(j_setrows text 4)
		(j_setcolumns text 15)
		(j_pack frame)
		;; Allocate immovable storage for passing data back from C land.
		;; Uses the GCL only make-array keyword :static
		(let* ((xa (make-array 1 :initial-element 0 :element-type 'fixnum :static
t))
		       (ya (make-array 1 :initial-element 0 :element-type 'fixnum :static
t))
		       (pxa (inta-ptr xa))
		       (pya (inta-ptr ya))
		       (x 0)
		       (y 0)
		       (get-mouse-xy (lambda (obj)
				       (progn (j_getmousepos obj pxa pya)
					      (setf x (aref xa 0))
					      (setf y (aref ya 0)))))
		       (startx 0)
		       (starty 0)
		       (selstart 0)
		       (selend 0)
		       (text-buffer (make-array 64000 :initial-element 0 :element-type
'character :static t))
					;	      (text-buffer (make-string 64000 :initial-element #\0))
		       (p-text-buffer (inta-ptr text-buffer)))
		  (do ((obj (j_nextaction) (j_nextaction)))
		      ((or (= obj frame) (= obj quit-mi))t)
		      (when (= obj panel)
			(format t "Size changed to ~D rows ~D columns~%" (j_getrows text)
(j_getcolumns text))
			(format t "Size changed to ~D x ~D pixels~%" (j_getwidth text)
(j_getheight text)))
		      (when (= obj text) (format t "Text changed (len=~D)~%" (j_getlength
text) ))
		      (when (= obj new-mi) (j_settext new-text))
		      (when (= obj save-mi) (j_gettext text text-buffer))
		      (when (= obj select-all-mi) (j_selectall text))
		      (when (or (= obj cut-mi)
				(= obj copy-mi)
				(= obj paste-mi))
			(setf selstart (1- (j_getselstart text)))
			(setf selend (1- (j_getselend text))))
		      (when (= obj cut-mi)
			(j_getseltext text p-text-buffer)
			(j_delete text (1- (j_getselstart text)) (1- (j_getselend text)))
			(setf selend selstart))
		      (when (= obj copy-mi)
			(j_getseltext text p-text-buffer))
		      (when (= obj paste-mi)
			(if (= selstart selend)
			    (j_inserttext text p-text-buffer (1- (j_getcurpos text)))
			  (j_replacetext text p-text-buffer (1- (j_getselstart text)) (1-
(j_getselend text))))
			))))))))))))))))))

(defun mandel (drawable min_x max_x min_y max_y step_x step_y)
  (let* ((scale_x (/ 1 step_x))
	 (scale_y (/ 1 step_y)))
    (loop for y from min_y to max_y by step_y do
	  (loop for x from min_x to max_x by step_x do
		(let* ((c 255)
		       (z (complex x y))
		       (a z))
		  (loop while (and (< (abs
				       (setq z (+ (* z z) a)))
				      2)
				   (>= (decf c) 0)))
		  (j_setcolor drawable c c c)
		  (j_drawpixel drawable (* scale_x (+ (abs min_x) x)) (* scale_y (+ (abs
min_y) y)) ))))))

;;; Monochrome Mandelbrot
(with-server
 ("GCL Japi library test GUI 4" 0)
 (let* ((min_x -2)
	(max_x  1)
	(min_y -1)
	(max_y  1.1)
	(step_x 0.01)
	(step_y 0.01)
	(size_x (+ 1 (/ (- max_x min_x) step_x)))
	(size_y (+ 1 (/ (- max_y min_y) step_y))))
   (with-frame
    (frame "Mandelbrot")
    (j_setsize frame size_x size_y)
    (j_setborderlayout frame)
    (with-menu-bar
     (menubar frame)
     (with-menu
      (file menubar "File")
      (with-menu-item
       (save file "Save BMP")
       (with-menu-item
	(quit file "Quit")
	(with-canvas
	 (canvas1 frame size_x size_y)
	 (j_pack frame)
	 (j_show frame)
	 (j_show canvas1)
	 (mandel canvas1  min_x max_x min_y max_y step_x step_y)
	 (do ((obj (j_nextaction) (j_nextaction)))
	     ((or (= obj frame) (= obj quit)) t)
	     (when (= obj save)
	       (let ((image (j_getimage canvas1)))
		 (when (= 0 (j_saveimage image "mandel.bmp" J_BMP))
		   (j_alertbox frame "Problems" "Can't save the image" "OK"))
		 (j_dispose image) )))))))))))



\start
Date: Wed, 27 Apr 2005 14:31:39 +1000
From: Mike Thomas
To: Camm Maguire, Tim Daly
Subject: RE: [Gcl-devel] Possible GCL 2.6.7 for axiom

Hi Camm.

| Hi Tim!  Great conference!

Sometimes living a long way from "the action" can be frustrating.

| Here's my take home understanding of the remaining issues re:
| gcl/axiom:
|
| 1) reenable run-process
| 2) display images in tcl/tk
| 3) tcl/tk working in windows
| 4) Windows socket workaround for sman/hypertex/graphics

I am aware of the following two items as well:

  5) Something has recently broken the path handling on Windows so the CVS
HEAD GCL build lisp compilation fails.

  6) On Windows (at least) GCL 2.6.6 Axiom (not 2.6.5) has a problem with
equation system solutions:
===========================================
(1) -> solve([3*x**3+y+1,y**2-4],[x,y])
   Loading C:/Program Files/axiom/mnt/windows/algebra/UPMP.o for
      package UnivariatePolynomialMultiplicationPackage

   >> System error:
   The function SYSTEM::DEBUGGER is undefined.

protected-symbol-warn called with (NIL)
(1) -> solve([3*x**3+y+1,y**2-4],[x,y])

   >> System error:
   Arg or result mismatch in call to  |devaluateList|

protected-symbol-warn called with (NIL)

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

\start
Date: Tue, 26 Apr 2005 22:06:49 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: axiom graphics and porting

--- Tim Daly wrote:
>
> Third I tried to use McClim. I want to use a lisp-based front end
> and this was my best hope. Unfortunately I was unable to get it to 
> work. 

Was this a GCL limitation?  Did you happen to save a record of the
issues you ran into?  I doubt I can succeed where you weren't able to
but it would be interesting to take a look at.  (Sorry, I think I might
have asked this before but I can't find the reply.)
 
> I'm unhappy about the need for Java and would much prefer McClim.
> 
> GCL does not seem to handle run-process correctly so I've been using
> CLISP. The browser and the graphics run in their own process anyway
> so Axiom under GCL can talk to McClim under CLISP.

So run-process is the man McCLIM issue?  I've been hoping as GCL gets
closer to ANSI problems with McCLIM would dimish, but perhaps there
will be some more work to do.  Of course, this still leaves writing the
Windows backend, or if QT comes through perhaps a QT4 backend will do. 
Possibly the attempts to write a MacOSX backend (Beagle) will be a good
starting point.  (Me disgustedly ponders the irony of having to get a
Windows box at some point after all ;-).

\start
Date: 27 Apr 2005 09:30:41 -0400
From: Camm Maguire
To: Mike Thomas
Subject: Re: [Gcl-devel] Possible GCL 2.6.7 for axiom

Greetings!

Mike Thomas writes:

> Hi Camm.
> 
> | Hi Tim!  Great conference!
> 
> Sometimes living a long way from "the action" can be frustrating.
> 

Needless to say, your spirit was there in force!

> | Here's my take home understanding of the remaining issues re:
> | gcl/axiom:
> |
> | 1) reenable run-process
> | 2) display images in tcl/tk
> | 3) tcl/tk working in windows
> | 4) Windows socket workaround for sman/hypertex/graphics
> 
> I am aware of the following two items as well:
> 
>   5) Something has recently broken the path handling on Windows so the CVS
> HEAD GCL build lisp compilation fails.
> 

OK, more detail here would be helpful, but this is not relevant to
2.6.x for axiom, no?


>   6) On Windows (at least) GCL 2.6.6 Axiom (not 2.6.5) has a problem with
> equation system solutions:
> ===========================================
> (1) -> solve([3*x**3+y+1,y**2-4],[x,y])
>    Loading C:/Program Files/axiom/mnt/windows/algebra/UPMP.o for
>       package UnivariatePolynomialMultiplicationPackage
> 
>    >> System error:
>    The function SYSTEM::DEBUGGER is undefined.
> 
> protected-symbol-warn called with (NIL)
> (1) -> solve([3*x**3+y+1,y**2-4],[x,y])
> 
>    >> System error:
>    Arg or result mismatch in call to  |devaluateList|
> 
> protected-symbol-warn called with (NIL)
> 


This is quite odd.  I cannot reproduce on my 2.6.6 axiom 20050201:

=============================================================================
camm@intech19:/fix/t1/camm/scalapack-1.7$ axiom
GCL (GNU Common Lisp)  2.6.6 CLtL1    Jan 18 2005 00:13:38
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
                        AXIOM Computer Algebra System 
                   Version: Axiom 3.0 Beta (February 2005)
              Timestamp: Monday February 21, 2005 at 20:01:15 
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------
 
   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase
(1) -> 
(1) -> solve([3*x**3+y+1,y**2-4],[x,y])
   Loading /usr/lib/axiom-20050201/algebra/UPMP.o for package 
      UnivariatePolynomialMultiplicationPackage 
   Loading /usr/lib/axiom-20050201/algebra/LIST2.o for package 
      ListFunctions2 
   Loading /usr/lib/axiom-20050201/algebra/FLAGG2.o for package 
      FiniteLinearAggregateFunctions2 
   Loading /usr/lib/axiom-20050201/algebra/OVAR.o for domain 
      OrderedVariableList 
   Loading /usr/lib/axiom-20050201/algebra/SYSSOLP.o for package 
      SystemSolvePackage 
   Loading /usr/lib/axiom-20050201/algebra/DMP.o for domain 
      DistributedMultivariatePolynomial 
   Loading /usr/lib/axiom-20050201/algebra/DIRPROD.o for domain 
      DirectProduct 
   Loading /usr/lib/axiom-20050201/algebra/VECTCAT-.o for domain 
      VectorCategory& 
   Loading /usr/lib/axiom-20050201/algebra/PUSHVAR.o for package 
      PushVariables 
   Loading /usr/lib/axiom-20050201/algebra/GDMP.o for domain 
      GeneralDistributedMultivariatePolynomial 
   Loading /usr/lib/axiom-20050201/algebra/DIRPCAT-.o for domain 
      DirectProductCategory& 
   Loading /usr/lib/axiom-20050201/algebra/GROEBSOL.o for package 
      GroebnerSolve 
   Loading /usr/lib/axiom-20050201/algebra/POLTOPOL.o for package 
      PolToPol 
   Loading /usr/lib/axiom-20050201/algebra/HDP.o for domain 
      HomogeneousDirectProduct 
   Loading /usr/lib/axiom-20050201/algebra/HDMP.o for domain 
      HomogeneousDistributedMultivariatePolynomial 
   Loading /usr/lib/axiom-20050201/algebra/GB.o for package 
      GroebnerPackage 
   Loading /usr/lib/axiom-20050201/algebra/GBINTERN.o for package 
      GroebnerInternalPackage 
   Loading /usr/lib/axiom-20050201/algebra/PGCD.o for package 
      PolynomialGcdPackage 
   Loading /usr/lib/axiom-20050201/algebra/LGROBP.o for package 
      LinGroebnerPackage 
   Loading /usr/lib/axiom-20050201/algebra/MATRIX.o for domain Matrix 
   Loading /usr/lib/axiom-20050201/algebra/IIARRAY2.o for domain 
      InnerIndexedTwoDimensionalArray 
   Loading /usr/lib/axiom-20050201/algebra/MATCAT-.o for domain 
      MatrixCategory& 
   Loading /usr/lib/axiom-20050201/algebra/ARR2CAT-.o for domain 
      TwoDimensionalArrayCategory& 
   Loading /usr/lib/axiom-20050201/algebra/GENMFACT.o for package 
      GeneralizedMultivariateFactorize 
   Loading /usr/lib/axiom-20050201/algebra/MPCPF.o for package 
      MPolyCatPolyFactorizer 
   Loading /usr/lib/axiom-20050201/algebra/MULTFACT.o for package 
      MultivariateFactorize 
   Loading /usr/lib/axiom-20050201/algebra/COMPLEX.o for domain Complex
      
   Loading /usr/lib/axiom-20050201/algebra/INNMFACT.o for package 
      InnerMultFact 
   Loading /usr/lib/axiom-20050201/algebra/MULTSQFR.o for package 
      MultivariateSquareFree 
   Loading /usr/lib/axiom-20050201/algebra/UPSQFREE.o for package 
      UnivariatePolynomialSquareFree 
   Loading /usr/lib/axiom-20050201/algebra/HEUGCD.o for package HeuGcd 
   Loading /usr/lib/axiom-20050201/algebra/INMODGCD.o for package 
      InnerModularGcd 
   Loading /usr/lib/axiom-20050201/algebra/EMR.o for domain 
      EuclideanModularRing 
   Loading /usr/lib/axiom-20050201/algebra/MDDFACT.o for package 
      ModularDistinctDegreeFactorizer 
   Loading /usr/lib/axiom-20050201/algebra/MODRING.o for domain 
      ModularRing 
   Loading /usr/lib/axiom-20050201/algebra/GENUFACT.o for package 
      GenUFactorize 
   Loading /usr/lib/axiom-20050201/algebra/GALFACT.o for package 
      GaloisGroupFactorizer 
   Loading /usr/lib/axiom-20050201/algebra/FSAGG-.o for domain 
      FiniteSetAggregate& 
   Loading /usr/lib/axiom-20050201/algebra/FLASORT.o for package 
      FiniteLinearAggregateSort 
   Loading /usr/lib/axiom-20050201/algebra/DIAGG-.o for domain 
      Dictionary& 
   Loading /usr/lib/axiom-20050201/algebra/DIOPS-.o for domain 
      DictionaryOperations& 
   Loading /usr/lib/axiom-20050201/algebra/SETAGG-.o for domain 
      SetAggregate& 
   Loading /usr/lib/axiom-20050201/algebra/BGAGG-.o for domain 
      BagAggregate& 
   Loading /usr/lib/axiom-20050201/algebra/GALPOLYU.o for package 
      GaloisGroupPolynomialUtilities 
   Loading /usr/lib/axiom-20050201/algebra/BRILL.o for package 
      BrillhartTests 
   Loading /usr/lib/axiom-20050201/algebra/FLOAT.o for domain Float 
   Loading /usr/lib/axiom-20050201/algebra/GALFACTU.o for package 
      GaloisGroupFactorizationUtilities 
   Loading /usr/lib/axiom-20050201/algebra/FPS-.o for domain 
      FloatingPointSystem& 
   Loading /usr/lib/axiom-20050201/algebra/RNS-.o for domain 
      RealNumberSystem& 
   Loading /usr/lib/axiom-20050201/algebra/TRANFUN-.o for domain 
      TranscendentalFunctionCategory& 
   Loading /usr/lib/axiom-20050201/algebra/ELEMFUN-.o for domain 
      ElementaryFunctionCategory& 
   Loading /usr/lib/axiom-20050201/algebra/HYPCAT-.o for domain 
      HyperbolicFunctionCategory& 
   Loading /usr/lib/axiom-20050201/algebra/ATRIG-.o for domain 
      ArcTrigonometricFunctionCategory& 
   Loading /usr/lib/axiom-20050201/algebra/TRIGCAT-.o for domain 
      TrigonometricFunctionCategory& 
   Loading /usr/lib/axiom-20050201/algebra/RADCAT-.o for domain 
      RadicalCategory& 
   Loading /usr/lib/axiom-20050201/algebra/GALUTIL.o for package 
      GaloisGroupUtilities 
   Loading /usr/lib/axiom-20050201/algebra/IROOT.o for package 
      IntegerRoots 
   Loading /usr/lib/axiom-20050201/algebra/UPDECOMP.o for package 
      UnivariatePolynomialDecompositionPackage 
   Loading /usr/lib/axiom-20050201/algebra/UPDIVP.o for package 
      UnivariatePolynomialDivisionPackage 
   Loading /usr/lib/axiom-20050201/algebra/UNISEG.o for domain 
      UniversalSegment 
   Loading /usr/lib/axiom-20050201/algebra/BASTYPE-.o for domain 
      BasicType& 
   Loading /usr/lib/axiom-20050201/algebra/GHENSEL.o for package 
      GeneralHenselPackage 
   Loading /usr/lib/axiom-20050201/algebra/VOID.o for domain Void 
   Loading /usr/lib/axiom-20050201/algebra/INTFACT.o for package 
      IntegerFactorizationPackage 
   Loading /usr/lib/axiom-20050201/algebra/IDPOAMS.o for domain 
      IndexedDirectProductOrderedAbelianMonoidSup 
   Loading /usr/lib/axiom-20050201/algebra/IDPOAM.o for domain 
      IndexedDirectProductOrderedAbelianMonoid 
   Loading /usr/lib/axiom-20050201/algebra/POLY2.o for package 
      PolynomialFunctions2 
   Loading /usr/lib/axiom-20050201/algebra/POLYLIFT.o for package 
      PolynomialCategoryLifting 
   Loading /usr/lib/axiom-20050201/algebra/MPRFF.o for package 
      MPolyCatRationalFunctionFactorizer 
   Loading /usr/lib/axiom-20050201/algebra/EQ.o for domain Equation 

                         2                     3
   (1)  [[x= - 1,y= 2],[x  - x + 1= 0,y= 2],[3x  - 1= 0,y= - 2]]
                         Type: List List Equation Fraction Polynomial Integer
(2) -> )quit
   Please enter y or yes if you really want to leave the interactive 
      environment and return to the operating system:
y


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

Didn't we move, at your request if I recall, si::debug to si::debugger
in cvs head (only)?  I've forgotten the details.  Perhaps you could
get some kind of backtrace to see from where your build is referring
to si::debugger.   Tim likely knows how to do this, or, as I've been
recently told, such details can be found in the fourth volume of the
axiom book, targettetd at developers, which can be found somewhere in
tla. 

\start
Date: 27 Apr 2005 09:48:10 -0400
From: Camm Maguire
To: "Bill Page \(E-mail\)" <Bill Page>
Subject: Re: [Gcl-devel] RE: Possible GCL 2.6.7 for axiom
Cc: Mike Thomas

Greetings!

Bill Page writes:

> On Tuesday, April 26, 2005 10:16 AM Camm Maguire wrote:
> 
> > Hi Tim!  Great conference!
> 
> I second that!
> 
> > Here's my take home understanding of the remaining issues
> > re: gcl/axiom:
> >
> > 1) reenable run-process
> > 2) display images in tcl/tk
> > 3) tcl/tk working in windows
> > 4) Windows socket workaround for sman/hypertex/graphics
> 
> This is consistent with my recollection of our discussions
> during the Axiom sprint session. And I am willing to help
> with testing and debugging on the Windows platform.
> 

Great!

> But we should be clear I think, that this is not necessarily
> the shortest path to a fully functioning version of Axiom on
> Windows. The linux version of Axiom does not now use tcl/tk
> for Graphics and Hypertex, i.e. those parts of Axiom that are
> not already ported to Microsoft Windows. Instead these currently
> depend directly on the X windows libraries. These should perhaps
> be re-implemented in tcl/tk linux first before attempting the
> port to Windows.
> 

Good point.  While I haven't looked recently at the code, my
understanding is that sman and its subprocesses are written in C.  The
shortest path, then, IMHO, is simply to translate the xlib calls
therein into equivalent versions on native windows, presuming we have
the expertise somewhere.  Next, I would say, is the cygwin idea you
propose below.  If either of these can be worked out, this would give
us breathing space to later do all of this from within lisp in
whatever fashion appears best.

Let me go on record that I defer completely to Mike Thomas' opinions
as to the superiority of the existing mingw work over cygwin from a
technical point of view.  And there is a lot to be said for unity,
epsecially when resources are so limited.  So I much prefer the xlib
translation route described above.  We could even use such work in
xgcl, a lisp interface to xlib included in the distribution.

With all this said, GCL on cygwin is likely quite easy -- the biggest
obstacles are that I will not allow anyone to bother Mike Thomas about
this (:-)), and no other serious GCL developer works on Windows at the
moment.  It would therefore require a dedicated volunteer to patiently
document the progress of the port on gcl-devel@gnu.org, and respond to
remote email help/instructions, most likely from me.  The only real
advantages of cygwin are 1) quite a few people seem to use it and 2)
it presents a simpler migration path from Linux.  But we should again
only turn here if no one knows how to write C graphics on windows.



> Because of this X windows dependency the shortest path,
> though admittedly not necessarily the best path, for fully
> implementing Axiom on Windows would probably be to use Cygwin.
> Currently GCL on windows uses MinGW instead of Cygwin to
> compile to native Windows but unlike Cygwin MinGW does not
> provided an X windows compatible environment.
> 
> I think using native Windows applications on Windows is a
> wothwhile target but it is sometimes hard for applications
> that originate on linux/Unix.
> 
> In principle it is possible to continue to compile AXIOMsys
> as a native Windows application and to run the Hypertex and
> Graphics components of Axiom under Cygwin. This would make
> it unnecessary to convert any already working code to tcl/tk.
> As I understand it, these additional components of Axiom
> currently only require a Unix-compatible C programming
> environment. So all we would need for this alternative is
> step 4) above - socket compatibility between the current
> native Windows version of GCL and the additional C code
> compiled under Cygwin.
> 
> Of course there are drawbacks. Using *both* MSYS/MinGW and
> Cygwin under Windows would further complicate the Windows
> build environment for Axiom. Currently there is no Cygwin
> version of GCL. Further, the X windows user interface under
> Cygwin might seem a little awkward for some Microsoft
> Windows users. But it should still be possible to prepare an
> auto-installation binary distribution that would make much
> of this transparent for users who are not interested in
> building Axiom from source.
> 
> >
> > These might go into a quick 2.6.7 GCL release.
> 
> However perhaps there are other reasons which would also
> motivate the development of GCL tcl/tk on Microsoft Windows.
> 

Yes, these broader lisp graphics questions I'll defer to my next
post. 


> > 
> > 5) axiom configure script
> > 
> 
> Yes! I think that would be a great step forward. I think
> Axiom should conform more closely to the de facto norm
> for building open source software.

\start
Date: 27 Apr 2005 11:09:23 -0400
From: Camm Maguire
To: Cliff Yapp
Subject: Re: [Gcl-devel] RE: Possible GCL 2.6.7 for axiom
Cc: Mike Thomas

Greetings!

Cliff Yapp writes:

> --- Bill Page wrote:
> > But we should be clear I think, that this is not necessarily
> > the shortest path to a fully functioning version of Axiom on
> > Windows. The linux version of Axiom does not now use tcl/tk
> > for Graphics and Hypertex, i.e. those parts of Axiom that are
> > not already ported to Microsoft Windows. Instead these currently
> > depend directly on the X windows libraries. These should perhaps
> > be re-implemented in tcl/tk linux first before attempting the
> > port to Windows.
> 
> I wasn't able to attend the conference :-(, and in discussing this
> possibility I'm admittedly skating on vapor trails and assuming skills
> I don't currently have, but if at some point in the future a QT4
> backend was written for McCLIM and somebody (me for the sake of
> discussion anyway) implimented a GUI CAS interface in it, would that be
> of interest to Axiom?  

Wonderful initiative!

These are just my simple thoughts on these broader questions:

1) I worry a lot that concern over graphics, as valuable as it is,
   detracts seriously from developer attention to the core math
   abilities of these systems.

2) In keeping with the above, there seems to be a well-intentioned
   desire to try to attract mass market users with dazzling eye candy.
   My only quibble is one of priority -- what are these attracted
   users going to contribute back to the community?  If we did attract
   them now, are we ready to respond to a deluge of feature requests
   and complaints?  If not, will these users turn against the project
   when their desires are not immediately gratified and the latest
   alternative toy becomes available?

3) I also worry that we are not mass marketing specialists, and that
   we cannot design a system based on what we imagine 'those users out
   there' want.  What we can do is develop the system so that it
   presents real value to the work *we actually do*, fix the bugs that
   bother us, add what we think is imperative for us to be able to
   rely on the system ourselves, etc.  If we do this, others like us
   are bound to see the value too, and some of them will join us.  If
   and when we get a large enough team intimately familiar with the
   system, we can then try to reach out little by little to the mass
   market, who are most likely to be 'takers' rather than 'givers' by
   simple necessity of the overwhelming complexity of these systems. 

4) To the extent that we adopt this perspective, the only critical
   need for graphics in these systems is the ability to plot and print
   mathematical functions, IMHO.  At this early stage in its open
   source life, I would recommend axiom adopt the simplest and most
   portable system with a sizable user base, preferably maintained and
   developed externally, and to then move on to the algorithms.
   Maxima has adopted gnuplot, which I think is a wonderful and
   powerful choice.  We have a working alternative system now and
   there is no need to throw this away, but if we ever feel the need
   to do something new in this area (for example, because our existing
   graphics does not yet work on Windows), this is the direction I
   would recommend for now.

5) In the longer term, lisp graphics is certainly very interesting,
   and some beautiful work from a programming point of view has been
   done, notably the McCLIM to which you refer.  The only problem here
   which is nonetheless quite serious is the lack of unity or
   consensus.  No one can afford to invest the time in putting
   something together if they run the extremely high risk that it will
   be abandoned later due to the extraordinary degree of fractiousness
   in this area.  People need to see the payback measured in terms of
   user contributions in the future -- in this way they lever their
   own efforts.  Ask the question, "If I do this, what new user
   contributions will I likely trigger?"

6) Here is a list of lisp graphics options of which I am aware, all of
   which are workable with possible modest effort within GCL, but none
   of which appear to have any serious use by any existing
   applications.  (Please correct me if I am mistaken:)

        a) xgcl -- http://www.cs.utexas.edu/users/novak/cgi/xgcldemo.cgi
        b) gcl-tk -- (tk::connect)(load "...gcl-tk/demos/widget.lsp")
        c) ltk  -- another tk binding
        d) gtk-based -- cl-gtk, lgtk, http://www.cliki.net/Gtk
        e) garnet -- http://garnetlisp.sourceforge.net/
        f) clx, clue, clio, clim, mcclim
        g) cells/cello -- comp.lang.lisp
        h) Java based japi -- lsp/gcl_japi.lsp

7) In deciding among these longer term options, please let me
   emphasize that any are likely workable, but it is very important
   IMHO that we pick at most one if we are to avoid wasting our
   lives.  I also think it important that we

        a) choose a purely open source option

        b) cross-platform

        c) wide user base -- this effectively means a huge C user base
        with a smaller user base of tight lisp bindings

        d) robust

        e) actively developed elsewhere

        f) comes with a graphical interface builder -- as attractive as
        graphical programming in lisp might be, even though it is lisp,
        it is still much less efficient IMHO than using a tool like
        glade.  I've used this myself in C, and I haven't had to write
        a single gtk call.

        g) LGPL is preferable to GPL if we're doing a general
        interface, but I have no problems with GPL myself.

   All of this would appear to argue in favor of cl-gtk or the like.
   Tim Daly Jr. has worked on it, and he indicates it would probably
   take a week's work to get running under GCL.  We need to know how
   good the Windows and MacOSX ports are.  *If we all agree* that this
   is the way forward, I'll be happy to donate a few cycles to moving
   it along.

> QT4 will be available as GPL for both Windows
> and Linux, which will make it an attractive target for an McCLIM
> backend.  (GTK is available but I find myself drawn more toward QT.  Of
> course, this doesn't rule out a GTK backend either.  Hehe - maybe one
> could write one program with a native look on BOTH KDE and Gnome :-D.) 
> I am pondering undertaking a backend attempt once QT4 comes out for the
> sake of creating a Maxima GUI which is a) lisp based and b) cross
> platform.  If Scigraph can be made to work and be extended as needed,
> this would also provide lisp based graphics in a cross platform manner.
>  The half-mythical Stix fonts may also be out by then (at long last
> their site was updated - drool.) Logically much of this should
> translate relatively easily to Axiom - in fact it should mainly be an
> issue of translating between McCLIM constructs and Axiom syntax, with
> the added non-trivial wrinkle of line breaking.  (Who knows -
> McCLIM+QT4 might just become the best thing for cross platform native
> GUI programming since Java, if the planets align right :-).  Lisp will
> rise once more!)

I think this is wonderful!  If you have the time to take this ball and
lead with it, I'll be happy to support.  As stated above, I think gtk
is a slightly better choice than QT, but *whatever draws consensus* is
the best!


> 
> I suppose I'm biased against tcl/tk but the Maxima experience with it
> has not been terribly positive, and it's not what I tend to think of
> when I think robust graphics.  Perhaps this is just my lack of
> knowledge.
>  

This is well founded, I think.  tk is quick and portable, not
necessarily 'robust and polished'.  The importance of the latter for
these considerations is questionable.  Can you describe the maxima
experience?  


> > Because of this X windows dependency the shortest path,
> > though admittedly not necessarily the best path, for fully
> > implementing Axiom on Windows would probably be to use Cygwin.
> > Currently GCL on windows uses MinGW instead of Cygwin to
> > compile to native Windows but unlike Cygwin MinGW does not
> > provided an X windows compatible environment.
> 
> True.  MinGW is the best available free solution for stand alone
> Windows binaries though, at least to my knowledge.  And Windows users +
> X applications, in my experience, does not a happy mix make.
> 
> > I think using native Windows applications on Windows is a
> > wothwhile target but it is sometimes hard for applications
> > that originate on linux/Unix.
> 
> Amen.  To both.
> 
> [snip partial cygwin solution]
> 
> > Of course there are drawbacks. Using *both* MSYS/MinGW and
> > Cygwin under Windows would further complicate the Windows
> > build environment for Axiom. Currently there is no Cygwin
> > version of GCL. Further, the X windows user interface under
> > Cygwin might seem a little awkward for some Microsoft
> > Windows users. But it should still be possible to prepare an
> > auto-installation binary distribution that would make much
> > of this transparent for users who are not interested in
> > building Axiom from source.
>  
> It will be HUGE, but yes, that might be workable.  I can't imagine how
> Windows users would react to an Xlib base GUI - GTK is bad enough. 

Here too -- what are your misgivings concerning gtk on Windows?

Take care,

> Still, it's a case of any GUI being much better than none, and recent
> versions of Cygwin X can at least operate on a per-window basis rathern
> than desktop only, so in theory it should work.
> 
> [snip]
> 
> > Yes! I think that would be a great step forward. I think
> > Axiom should conform more closely to the de facto norm
> > for building open source software.
> 
> I'll second that!  The make install process still goes wonky for me on
> Gentoo, and I have seen a second report of the same behavior so it's
> probably not just my screwed up system.

\start
Date: 27 Apr 2005 11:55:18 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: axiom graphics and porting

Greetings!

Tim Daly writes:

> I've tried 3 paths so far.
> 
> First I tried to find an X library that runs natively on windows
> without success. So I started working on one and realized that I
> didn't know enough of the Microsoft C API to manage it.
> 

Such ambition!

> Second I tried to use TK as the front end. I was unable to get
> the TK front end to display graphics and was unable to find the
> source code (since remedied by Camm).
> 

More here later.

> Third I tried to use McClim. I want to use a lisp-based front end
> and this was my best hope. Unfortunately I was unable to get it to 
> work. 
> 

My understanding is that this will need a backend on Windows anyway.
I *think* it is conventionally built atop clx, which works just about
'out of the box' on gcl, but everyone these days wants something
higher up than raw xlib.

> Finally I wrote a TK-equivalent program in Java. Since it is cross
> platform it will run on linux and windows. I have a small working
> demonstration for the browser.
> 
> The plan is to rewrite the browser and graphics in common lisp and
> use a socket based message passing to communicate. The common lisp
> rewrite would make it so much easier to port. And the command 
> language for the front end could be easily modified to fit the 
> choice of front end (TK, Java, McClim).
> 
> I'm unhappy about the need for Java and would much prefer McClim.

Me too!  Thankfully, this is not hard.

> 
> GCL does not seem to handle run-process correctly so I've been using
> CLISP. The browser and the graphics run in their own process anyway
> so Axiom under GCL can talk to McClim under CLISP.
> 

This is a simple missing define:

=============================================================================
--- h/protoize.h	2005-01-16 00:36:20.000000000 +0000
+++ ../gclcvs-2.7.0/h/protoize.h	2005-04-09 13:16:40.000000000 +0000
@@ -604,6 +604,9 @@
 gcl_init_symbol_function(void);
 
 void
+gcl_init_socket_function(void);
+
+void
 gcl_init_hash(void);
 
 void
--- o/run_process.c	2003-09-14 02:30:45.000000000 +0000
+++ ../gclcvs-2.7.0/o/run_process.c	2005-04-14 21:55:45.000000000 +0000
@@ -16,12 +16,15 @@
 
 */
 
-
+#include <string.h>
 
 #define IN_RUN_PROCESS
 #include "include.h"
 #ifdef RUN_PROCESS
 
+void setup_stream_buffer(object);
+object make_two_way_stream(object, object);
+
 #ifdef __MINGW32__
 
 #include<windows.h>
@@ -29,7 +32,6 @@
 #define PIPE_BUFFER_SIZE 2048
 
 void DisplayError ( char *pszAPI );
-void setup_stream_buffer ( object x );
 void PrepAndLaunchRedirectedChild ( HANDLE hChildStdOut,
     HANDLE hChildStdIn,
     HANDLE hChildStdErr,
@@ -425,7 +427,8 @@
 	return(stream);
 }
 
-object make_socket_stream(host_l,port)
+object
+make_socket_stream(host_l,port)
 object	host_l;
 object	port;
 {
@@ -445,7 +448,7 @@
 }
 
 void
-siLmake_socket_stream()
+FFN(siLmake_socket_stream)()
 {
   check_arg(2);
   vs_base[0] = make_socket_stream(vs_base[0], vs_base[1]);
@@ -462,7 +465,6 @@
   int sockets_in[2];
   int sockets_out[2];
   FILE *fp1, *fp2;
-  int pid;
   object stream_in, stream_out, stream;
 
   if (socketpair(AF_UNIX, SOCK_STREAM, 0, sockets_in) < 0)
@@ -473,11 +475,12 @@
   fp2 = fdopen(sockets_out[0], "w");
 
 #ifdef OVM_IO
+  {int pid;
   pid = getpid();
   ioctl(sockets_in[0], SIOCSPGRP, (char *)&pid);
   if( fcntl(sockets_in[0], F_SETFL, FASYNC | FNDELAY) == -1)
     perror("Couldn't control socket");
-
+  }
 #endif
 
 
@@ -502,7 +505,7 @@
  * with "C" type streams.
  */
 
-
+void
 spawn_process_with_streams(istream, ostream, pname, argv)
 object istream;
 object ostream;
@@ -531,12 +534,10 @@
 	}
     }
 
-
-
-  
 }
     
       
+void
 run_process(filename, argv)
 char *filename;
 char **argv;
@@ -550,7 +551,8 @@
   vs_top = vs_base + 2;
 }
     
-siLrun_process()
+void
+FFN(siLrun_process)()
 {
   int i;
   object arglist;
@@ -567,7 +569,7 @@
 }
 
 void
-siLmake_socket_pair()
+FFN(siLmake_socket_pair)()
 {
   make_socket_pair();
 }
--- h/linux.h	2005-04-27 15:44:19.000000000 +0000
+++ ../gclcvs-2.7.0/h/linux.h	2005-03-07 23:12:07.000000000 +0000
@@ -93,7 +93,7 @@
     result = (current_mask & sigmask(m) ? signal_mask(m) : 0) \
       | (current_mask & sigmask(n) ? signal_mask(n) : 0);
 
-#undef RUN_PROCESS
+#define RUN_PROCESS
 
 #define	IEEEFLOAT
        
=============================================================================
GCL (GNU Common Lisp)  2.6.6 CLtL1    Apr 27 2005 15:47:01
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

>(let ((s (si::run-process "echo" (list "hello" "there")))) (values (read s) (read s)))

***** Spawning process echo 
HELLO
THERE

>(by)
=============================================================================


So you're ready to go here.  Will post this to the errata page for
inclusion in 2.6.7 if any.  We still need to decide on a
cross-platform graphics to talk *to*.  I feel pretty confident we can
get images displayed in gcl-tk in a cross platform manner.  As
discussed elsewhere, this entails a graphics rewrite and is hence a
longer term solution, for which gtk might be a still better option.
Short term, why not just recode the sman C graphics in Windows?
Anyone? 

\start
Date: 27 Apr 2005 11:57:48 -0400
From: Camm Maguire
To: Mike Thomas
Subject: Re: axiom graphics and porting

Greetings!

Mike Thomas writes:

> Hi Tim and Bill.
> 
> Several things:
> 
> | GCL does not seem to handle run-process correctly
> 
> Could you please give us more details?
> 
> Without wishing to tell Bill or yourself what to do with your own project
> regarding X and/or Cygwin, I think it would be a major mistake to follow
> that route for the reasons outlined here:
> 
>   http://www.math.utexas.edu/pipermail/maxima/2004/006716.html
> 
> I really can't emphasize my personal lack of interest in such a course of
> action enough without actually walking off the GCL Windows job (although I
> have no such intention thereof at present).
> 

Thankfully!!  How hard is it to recode the exisiting C graphics in
Windows?

> Be aware also that for a couple of years a GCL binding to the Java GUI
> library (JAPI) has existed in our CVS and although only ever tested by me on
> Windows, should be fine on Unix as JAPI is cross-platform itself.  I've
> inserted below an example program from the GCL source tree to give you a
> feel for the way it works - it does various graphics and text things
> including a simple mandelbrot display and the (extremely) bare bones of a
> text editor.  This program is the only Lisp binding documentation in
> existence for the library.  The JAPI binding is included in every Windows
> GCL binary release.
> 
> Having said that, Camm has always been very enthusiastic about GCL/Tk and it
> seems to me that it is a good way to go for that reason alone.  Another
> (negative) argument in its favour is that JAPI seems to be moribund whereas
> TCL/Tk is, of course, very active.
> 

Not to mention that java is far from open source.


> ===== japitest.lsp ==========
> 
> ;;;
> ;;; Japi is a cross-platform, easy to use (rough and ready) Java based GUI
> library
> ;;; Download a library and headers for your platform, and get the C examples
> ;;; and documentation from:
> ;;;
> ;;;     http://www.japi.de/
> ;;;
> ;;; This file shows how to use some of the available functions.  You may
> assume
> ;;; that the only functions tested so far in the binding are those which
> appear
> ;;; below, as this file doubles as the test program.  The binding is so
> simple
> ;;; however that so far no binding (APART FROM J_PRINT) has gone wrong of
> those
> ;;; tested so far!
> ;;;
> ;;;
> ;;; HOW TO USE THIS FILE
> ;;;
> ;;; (compile-file "c:/cvs/gcl/japitest.lsp") (load "c:/cvs/gcl/japitest.o")
> ;;;
> ;;; Requires either "java" or "jre" in the path to work.
> ;;;
> 
> (in-package :japi-primitives)
> 
> ;; Start up the Japi server (needs to find either "java" or "jre" in your
> path
> (defmacro with-server ((app-name debug-level) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(if (= 0 (jpr::j_start))
> 			    (format t (format nil "~S can't connect to the Japi GUI server."
> ,app-name))
> 			  (progn
> 			    (j_setdebug ,debug-level)
> 			    ,@ds
> 			    (unwind-protect
> 				(progn ,@b)
> 			      (j_quit))))))
> 
> ;; Use a frame and clean up afterwards even if trouble ensues
> (defmacro with-frame ((frame-var-name title) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,frame-var-name (j_frame ,title)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,frame-var-name)))))
> 
> ;; Use a canvas and clean up afterwards even if trouble ensues
> (defmacro with-canvas ((canvas-var-name frame-obj x-size y-size) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,canvas-var-name (j_canvas ,frame-obj ,x-size ,y-size)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,canvas-var-name)))))
> 
> ;; Use a text area and clean up afterwards even if trouble ensues
> (defmacro with-text-area ((text-area-var-name panel-obj x-size y-size) .
> body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,text-area-var-name (j_textarea ,panel-obj ,x-size
> ,y-size)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,text-area-var-name)))))
> 
> ;; Use a pulldown menu bar and clean up afterwards even if trouble ensues
> (defmacro with-menu-bar ((bar-var-name frame-obj) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,bar-var-name (j_menubar ,frame-obj)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,bar-var-name)))))
> 
> ;; Add a pulldown menu and clean up afterwards even if trouble ensues
> (defmacro with-menu ((menu-var-name bar-obj title) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,menu-var-name (j_menu ,bar-obj ,title)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,menu-var-name)))))
> 
> ;; Add a pulldown menu item and clean up afterwards even if trouble ensues
> (defmacro with-menu-item ((item-var-name menu-obj title) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,item-var-name (j_menuitem ,menu-obj ,title)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,item-var-name)))))
> 
> ;; Add a mouse listener and clean up afterwards even if trouble ensues
> (defmacro with-mouse-listener ((var-name obj type) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,var-name (j_mouselistener ,obj ,type)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,var-name)))))
> 
> ;; Use a panel and clean up afterwards even if trouble ensues
> (defmacro with-panel ((panel-var-name frame-obj) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,panel-var-name (j_panel ,frame-obj)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,panel-var-name)))))
> 
> ;; Get a pointer to an array of ints
> (defCfun "static void* inta_ptr(object s)" 0
>   " return(s->fixa.fixa_self);")
> (defentry inta-ptr (object) (int "inta_ptr"))
> 
> ;; Draw function
> (defun drawgraphics (drawable xmin ymin xmax ymax)
>   (let* ((fntsize 10)
> 	 (tmpstrx (format nil "XMax = ~D" xmax))
> 	 (tmpstry (format nil "YMax = ~D" ymax))
> 	 (tmpstrwidx (j_getstringwidth drawable tmpstrx)))
>     (j_setfontsize drawable fntsize)
>     (j_setnamedcolor drawable J_RED)
> 
>     (j_drawline drawable xmin ymin        (- xmax 1)      (- ymax 1))
>     (j_drawline drawable xmin (- ymax 1)  (- xmax 1)      ymin)
>     (j_drawrect drawable xmin ymin        (- xmax xmin 1) (- ymax xmin 1))
> 
>     (j_setnamedcolor drawable J_BLACK)
>     (j_drawline drawable xmin (- ymax 30) (- xmax 1)      (- ymax 30))
>     (j_drawstring drawable (- (/ xmax 2) (/ tmpstrwidx 2)) (- ymax 40)
> tmpstrx)
> 
>     (j_drawline drawable (+ xmin 30) ymin (+ xmin 30) (- ymax 1))
>     (j_drawstring drawable (+ xmin 50) 40 tmpstry)
> 
>     (j_setnamedcolor drawable J_MAGENTA)
>     (loop for i from 1 to 10
> 	  do (j_drawoval drawable
> 			 (+ xmin (/ (- xmax xmin) 2))
> 			 (+ ymin (/ (- ymax ymin) 2))
> 			 (* (/ (- xmax xmin) 20) i)
> 			 (* (/ (- ymax ymin) 20) i)))
> 
>     (j_setnamedcolor drawable J_BLUE)
>     (let ((y ymin)
> 	  (teststr "JAPI Test Text"))
>       (loop for i from 5 to 21 do
> 	    (j_setfontsize drawable i)
> 	    (let ((x (- xmax (j_getstringwidth drawable teststr))))
> 	      (setf y (+ y (j_getfontheight drawable)))
> 	      (j_drawstring drawable x y teststr))))))
> 
> 
> 
> ;; Run a five second frame in a Japi server
> (with-server ("GCL Japi library test GUI 1" 0)
> 	     (with-frame (frame "Five Second Blank Test Frame")
> 			 (j_show frame)
> 			 (j_sleep 5000)))
> 
> 
> ;; Run some more extensive tests
> (with-server
>  ("GCL Japi library test GUI 2" 0)
>  (with-frame
>   (frame "Draw")
>   (j_show frame)
>   (let ((alert (j_messagebox frame "Two second alert box" "label")))
>     (j_sleep 2000)
>     (j_dispose alert))
>   (let ((result1 (j_alertbox frame "label1" "label2" "OK"))
> 	(result2 (j_choicebox2 frame "label1" "label2" "Yes" "No"))
> 	(result3 (j_choicebox3 frame "label1" "label2" "Yes" "No" "Cancel")))
>     (format t "Requestor results were: ~D, ~D, ~D~%" result1 result2
> result3))
>   (j_setborderlayout frame)
>   (with-menu-bar
>    (menubar frame)
>    (with-menu
>     (file menubar "File")
>     (with-menu-item
>      (print file "Print")
>      (with-menu-item
>       (save file "Save BMP")
>       (with-menu-item
>        (quit file "Quit")
>        (with-canvas
> 	(canvas frame 400 600)
> 	(j_pack frame)
> 	(drawgraphics canvas 0 0 (j_getwidth canvas) (j_getheight canvas))
> 	(j_show frame)
> 	(do ((obj (j_nextaction) (j_nextaction)))
> 	    ((or (= obj frame) (= obj quit)) t)
> 	    (when (= obj canvas)
> 	      (j_setnamedcolorbg canvas J_WHITE)
> 	      (drawgraphics canvas 10 10
> 			    (- (j_getwidth canvas) 10)
> 			    (- (j_getheight canvas) 10)))
> 	    (when (= obj print)
> 	      (let ((printer (j_printer frame)))
> 		(when (> 0 printer)
> 		  (drawgraphics printer 40 40
> 				(- (j_getwidth printer) 80)
> 				(- (j_getheight printer) 80))
> 		  (j_print printer))))
> 	    (when (= obj save)
> 	      (let ((image (j_image 600 800)))
> 		(drawgraphics image 0 0 600 800)
> 		(when (= 0 (j_saveimage image "test.bmp" J_BMP))
> 		  (j_alertbox frame "Problems" "Can't save the image" "OK")))))))))))))
> 
> ;; Try some mouse handling
> (with-server
>  ("GCL Japi library test GUI 3" 0)
>  (with-frame
>   (frame "Move and drag the mouse")
>   (j_setsize frame 430 240)
>   (j_setnamedcolorbg frame J_LIGHT_GRAY)
>   (with-canvas
>    (canvas1 frame 200 200)
>    (with-canvas
>     (canvas2 frame 200 200)
>     (j_setpos canvas1 10 30)
>     (j_setpos canvas2 220 30)
>     (with-mouse-listener
>      (pressed canvas1 J_PRESSED)
>      (with-mouse-listener
>       (dragged canvas1 J_DRAGGED)
>       (with-mouse-listener
>        (released canvas1 J_RELEASED)
>        (with-mouse-listener
> 	(entered canvas2 J_ENTERERD)
> 	(with-mouse-listener
> 	 (moved canvas2 J_MOVED)
> 	 (with-mouse-listener
> 	  (exited canvas2 J_EXITED)
> 	  (j_show frame)
>           ;; Allocate immovable storage for passing data back from C land.
> 	  ;; Uses the GCL only make-array keyword :static
> 	  (let* ((xa (make-array 1 :initial-element 0 :element-type 'fixnum :static
> t))
> 		 (ya (make-array 1 :initial-element 0 :element-type 'fixnum :static t))
> 		 (pxa (inta-ptr xa))
> 		 (pya (inta-ptr ya))
> 		 (x 0)
> 		 (y 0)
> 		 (get-mouse-xy (lambda (obj)
> 				 (progn (j_getmousepos obj pxa pya)
> 					(setf x (aref xa 0))
> 					(setf y (aref ya 0)))))
> 		 (startx 0)
> 		 (starty 0))
> 	    (do ((obj (j_nextaction) (j_nextaction)))
> 		((= obj frame) t)
> 		(when (= obj pressed)
> 		  (funcall get-mouse-xy pressed)
> 		  (setf startx x)
> 		  (setf starty y))
> 		(when (= obj dragged)
> 		  (funcall get-mouse-xy dragged)
> 		  (j_drawrect canvas1 startx starty (- x startx) (- y starty)))
> 		(when (= obj released)
> 		  (funcall get-mouse-xy released)
> 		  (j_drawrect canvas1 startx starty (- x startx) (- y starty)))
> 		(when (= obj entered)
> 		  (funcall get-mouse-xy entered)
> 		  (setf startx x)
> 		  (setf starty y))
> 		(when (= obj moved)
> 		  (funcall get-mouse-xy moved)
> 		  (j_drawline canvas2 startx starty x y))
> 		(setf startx x)
> 		(setf starty y)
> 		(when (= obj exited)
> 		  (funcall get-mouse-xy exited)
> 		  (j_drawline canvas2 startx starty x y))))))))))))))
> 
> ;; Text editor demo
> (with-server
>  ("GCL Japi library test text editor" 0)
>  (with-frame
>   (frame "A simple editor")
>   (j_setgridlayout frame 1 1)
>   (with-panel
>    (panel frame)
>    (j_setgridlayout panel 1 1)
>    (with-menu-bar
>     (menubar frame)
>     (with-menu
>      (file-mi menubar "File")
>      (with-menu-item
>       (new-mi file-mi "New")
>       (with-menu-item
>        (save-mi file-mi "Save")
>        (j_seperator file-mi)
>        (with-menu-item
> 	(quit-mi file-mi "Quit")
> 
> 	(with-menu
> 	 (edit-mi menubar "Edit")
> 	 (with-menu-item
> 	  (select-all-mi edit-mi "Select All")
> 	  (j_seperator edit-mi)
> 	  (with-menu-item
> 	   (cut-mi edit-mi "Cut")
> 	   (with-menu-item
> 	    (copy-mi edit-mi "Copy")
> 	    (with-menu-item
> 	     (paste-mi edit-mi "Paste")
> 
> 	     (with-text-area
> 	      (text panel 15 4)
> 	      (j_setfont text J_DIALOGIN J_BOLD 18)
> 	      (let ((new-text (format nil "JAPI (Java Application~%Programming
> Interface)~%a platform and language~%independent API")))
> 		(j_settext text new-text)
> 		(j_show frame)
> 		(j_pack frame)
> 		(j_setrows text 4)
> 		(j_setcolumns text 15)
> 		(j_pack frame)
> 		;; Allocate immovable storage for passing data back from C land.
> 		;; Uses the GCL only make-array keyword :static
> 		(let* ((xa (make-array 1 :initial-element 0 :element-type 'fixnum :static
> t))
> 		       (ya (make-array 1 :initial-element 0 :element-type 'fixnum :static
> t))
> 		       (pxa (inta-ptr xa))
> 		       (pya (inta-ptr ya))
> 		       (x 0)
> 		       (y 0)
> 		       (get-mouse-xy (lambda (obj)
> 				       (progn (j_getmousepos obj pxa pya)
> 					      (setf x (aref xa 0))
> 					      (setf y (aref ya 0)))))
> 		       (startx 0)
> 		       (starty 0)
> 		       (selstart 0)
> 		       (selend 0)
> 		       (text-buffer (make-array 64000 :initial-element 0 :element-type
> 'character :static t))
> 					;	      (text-buffer (make-string 64000 :initial-element #\0))
> 		       (p-text-buffer (inta-ptr text-buffer)))
> 		  (do ((obj (j_nextaction) (j_nextaction)))
> 		      ((or (= obj frame) (= obj quit-mi))t)
> 		      (when (= obj panel)
> 			(format t "Size changed to ~D rows ~D columns~%" (j_getrows text)
> (j_getcolumns text))
> 			(format t "Size changed to ~D x ~D pixels~%" (j_getwidth text)
> (j_getheight text)))
> 		      (when (= obj text) (format t "Text changed (len=~D)~%" (j_getlength
> text) ))
> 		      (when (= obj new-mi) (j_settext new-text))
> 		      (when (= obj save-mi) (j_gettext text text-buffer))
> 		      (when (= obj select-all-mi) (j_selectall text))
> 		      (when (or (= obj cut-mi)
> 				(= obj copy-mi)
> 				(= obj paste-mi))
> 			(setf selstart (1- (j_getselstart text)))
> 			(setf selend (1- (j_getselend text))))
> 		      (when (= obj cut-mi)
> 			(j_getseltext text p-text-buffer)
> 			(j_delete text (1- (j_getselstart text)) (1- (j_getselend text)))
> 			(setf selend selstart))
> 		      (when (= obj copy-mi)
> 			(j_getseltext text p-text-buffer))
> 		      (when (= obj paste-mi)
> 			(if (= selstart selend)
> 			    (j_inserttext text p-text-buffer (1- (j_getcurpos text)))
> 			  (j_replacetext text p-text-buffer (1- (j_getselstart text)) (1-
> (j_getselend text))))
> 			))))))))))))))))))
> 
> (defun mandel (drawable min_x max_x min_y max_y step_x step_y)
>   (let* ((scale_x (/ 1 step_x))
> 	 (scale_y (/ 1 step_y)))
>     (loop for y from min_y to max_y by step_y do
> 	  (loop for x from min_x to max_x by step_x do
> 		(let* ((c 255)
> 		       (z (complex x y))
> 		       (a z))
> 		  (loop while (and (< (abs
> 				       (setq z (+ (* z z) a)))
> 				      2)
> 				   (>= (decf c) 0)))
> 		  (j_setcolor drawable c c c)
> 		  (j_drawpixel drawable (* scale_x (+ (abs min_x) x)) (* scale_y (+ (abs
> min_y) y)) ))))))
> 
> ;;; Monochrome Mandelbrot
> (with-server
>  ("GCL Japi library test GUI 4" 0)
>  (let* ((min_x -2)
> 	(max_x  1)
> 	(min_y -1)
> 	(max_y  1.1)
> 	(step_x 0.01)
> 	(step_y 0.01)
> 	(size_x (+ 1 (/ (- max_x min_x) step_x)))
> 	(size_y (+ 1 (/ (- max_y min_y) step_y))))
>    (with-frame
>     (frame "Mandelbrot")
>     (j_setsize frame size_x size_y)
>     (j_setborderlayout frame)
>     (with-menu-bar
>      (menubar frame)
>      (with-menu
>       (file menubar "File")
>       (with-menu-item
>        (save file "Save BMP")
>        (with-menu-item
> 	(quit file "Quit")
> 	(with-canvas
> 	 (canvas1 frame size_x size_y)
> 	 (j_pack frame)
> 	 (j_show frame)
> 	 (j_show canvas1)
> 	 (mandel canvas1  min_x max_x min_y max_y step_x step_y)
> 	 (do ((obj (j_nextaction) (j_nextaction)))
> 	     ((or (= obj frame) (= obj quit)) t)
> 	     (when (= obj save)
> 	       (let ((image (j_getimage canvas1)))
> 		 (when (= 0 (j_saveimage image "mandel.bmp" J_BMP))
> 		   (j_alertbox frame "Problems" "Can't save the image" "OK"))
> 		 (j_dispose image) )))))))))))
> 

\start
Date: 27 Apr 2005 12:04:41 -0400
From: Camm Maguire
To: Mike Thomas
Subject: Re: axiom graphics and porting

Greetings!

Mike, separately, your comments on the following would be most
helpful:

1) How good is gtk (as opposed to tk) on Windows?
2) I remember us discussing the gcl-tk issues on Windows, but cannot
   find the thread at the moment.  My understanding is that the issue
   lies in the socket emulation.  How difficult is this to fix?  Do
   you have an estimate in terms of time?  What could I do from the
   Linux side to assist?
3) Is there an easy analog for an xgcl type interface on Windows?
4) Does the recent patch I just posted on run-process work for
   windows? 

Take care,

Mike Thomas writes:

> Hi Tim and Bill.
> 
> Several things:
> 
> | GCL does not seem to handle run-process correctly
> 
> Could you please give us more details?
> 
> Without wishing to tell Bill or yourself what to do with your own project
> regarding X and/or Cygwin, I think it would be a major mistake to follow
> that route for the reasons outlined here:
> 
>   http://www.math.utexas.edu/pipermail/maxima/2004/006716.html
> 
> I really can't emphasize my personal lack of interest in such a course of
> action enough without actually walking off the GCL Windows job (although I
> have no such intention thereof at present).
> 
> Be aware also that for a couple of years a GCL binding to the Java GUI
> library (JAPI) has existed in our CVS and although only ever tested by me on
> Windows, should be fine on Unix as JAPI is cross-platform itself.  I've
> inserted below an example program from the GCL source tree to give you a
> feel for the way it works - it does various graphics and text things
> including a simple mandelbrot display and the (extremely) bare bones of a
> text editor.  This program is the only Lisp binding documentation in
> existence for the library.  The JAPI binding is included in every Windows
> GCL binary release.
> 
> Having said that, Camm has always been very enthusiastic about GCL/Tk and it
> seems to me that it is a good way to go for that reason alone.  Another
> (negative) argument in its favour is that JAPI seems to be moribund whereas
> TCL/Tk is, of course, very active.
> 
> Cheers
> 
> Mike Thomas.
> 
> 
> 
> ===== japitest.lsp ==========
> 
> ;;;
> ;;; Japi is a cross-platform, easy to use (rough and ready) Java based GUI
> library
> ;;; Download a library and headers for your platform, and get the C examples
> ;;; and documentation from:
> ;;;
> ;;;     http://www.japi.de/
> ;;;
> ;;; This file shows how to use some of the available functions.  You may
> assume
> ;;; that the only functions tested so far in the binding are those which
> appear
> ;;; below, as this file doubles as the test program.  The binding is so
> simple
> ;;; however that so far no binding (APART FROM J_PRINT) has gone wrong of
> those
> ;;; tested so far!
> ;;;
> ;;;
> ;;; HOW TO USE THIS FILE
> ;;;
> ;;; (compile-file "c:/cvs/gcl/japitest.lsp") (load "c:/cvs/gcl/japitest.o")
> ;;;
> ;;; Requires either "java" or "jre" in the path to work.
> ;;;
> 
> (in-package :japi-primitives)
> 
> ;; Start up the Japi server (needs to find either "java" or "jre" in your
> path
> (defmacro with-server ((app-name debug-level) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(if (= 0 (jpr::j_start))
> 			    (format t (format nil "~S can't connect to the Japi GUI server."
> ,app-name))
> 			  (progn
> 			    (j_setdebug ,debug-level)
> 			    ,@ds
> 			    (unwind-protect
> 				(progn ,@b)
> 			      (j_quit))))))
> 
> ;; Use a frame and clean up afterwards even if trouble ensues
> (defmacro with-frame ((frame-var-name title) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,frame-var-name (j_frame ,title)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,frame-var-name)))))
> 
> ;; Use a canvas and clean up afterwards even if trouble ensues
> (defmacro with-canvas ((canvas-var-name frame-obj x-size y-size) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,canvas-var-name (j_canvas ,frame-obj ,x-size ,y-size)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,canvas-var-name)))))
> 
> ;; Use a text area and clean up afterwards even if trouble ensues
> (defmacro with-text-area ((text-area-var-name panel-obj x-size y-size) .
> body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,text-area-var-name (j_textarea ,panel-obj ,x-size
> ,y-size)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,text-area-var-name)))))
> 
> ;; Use a pulldown menu bar and clean up afterwards even if trouble ensues
> (defmacro with-menu-bar ((bar-var-name frame-obj) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,bar-var-name (j_menubar ,frame-obj)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,bar-var-name)))))
> 
> ;; Add a pulldown menu and clean up afterwards even if trouble ensues
> (defmacro with-menu ((menu-var-name bar-obj title) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,menu-var-name (j_menu ,bar-obj ,title)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,menu-var-name)))))
> 
> ;; Add a pulldown menu item and clean up afterwards even if trouble ensues
> (defmacro with-menu-item ((item-var-name menu-obj title) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,item-var-name (j_menuitem ,menu-obj ,title)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,item-var-name)))))
> 
> ;; Add a mouse listener and clean up afterwards even if trouble ensues
> (defmacro with-mouse-listener ((var-name obj type) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,var-name (j_mouselistener ,obj ,type)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,var-name)))))
> 
> ;; Use a panel and clean up afterwards even if trouble ensues
> (defmacro with-panel ((panel-var-name frame-obj) . body)
>   (multiple-value-bind (ds b)
> 		       (si::find-declarations body)
> 		       `(let ((,panel-var-name (j_panel ,frame-obj)))
> 			  ,@ds
> 			  (unwind-protect
> 			      (progn ,@b)
> 			    (j_dispose ,panel-var-name)))))
> 
> ;; Get a pointer to an array of ints
> (defCfun "static void* inta_ptr(object s)" 0
>   " return(s->fixa.fixa_self);")
> (defentry inta-ptr (object) (int "inta_ptr"))
> 
> ;; Draw function
> (defun drawgraphics (drawable xmin ymin xmax ymax)
>   (let* ((fntsize 10)
> 	 (tmpstrx (format nil "XMax = ~D" xmax))
> 	 (tmpstry (format nil "YMax = ~D" ymax))
> 	 (tmpstrwidx (j_getstringwidth drawable tmpstrx)))
>     (j_setfontsize drawable fntsize)
>     (j_setnamedcolor drawable J_RED)
> 
>     (j_drawline drawable xmin ymin        (- xmax 1)      (- ymax 1))
>     (j_drawline drawable xmin (- ymax 1)  (- xmax 1)      ymin)
>     (j_drawrect drawable xmin ymin        (- xmax xmin 1) (- ymax xmin 1))
> 
>     (j_setnamedcolor drawable J_BLACK)
>     (j_drawline drawable xmin (- ymax 30) (- xmax 1)      (- ymax 30))
>     (j_drawstring drawable (- (/ xmax 2) (/ tmpstrwidx 2)) (- ymax 40)
> tmpstrx)
> 
>     (j_drawline drawable (+ xmin 30) ymin (+ xmin 30) (- ymax 1))
>     (j_drawstring drawable (+ xmin 50) 40 tmpstry)
> 
>     (j_setnamedcolor drawable J_MAGENTA)
>     (loop for i from 1 to 10
> 	  do (j_drawoval drawable
> 			 (+ xmin (/ (- xmax xmin) 2))
> 			 (+ ymin (/ (- ymax ymin) 2))
> 			 (* (/ (- xmax xmin) 20) i)
> 			 (* (/ (- ymax ymin) 20) i)))
> 
>     (j_setnamedcolor drawable J_BLUE)
>     (let ((y ymin)
> 	  (teststr "JAPI Test Text"))
>       (loop for i from 5 to 21 do
> 	    (j_setfontsize drawable i)
> 	    (let ((x (- xmax (j_getstringwidth drawable teststr))))
> 	      (setf y (+ y (j_getfontheight drawable)))
> 	      (j_drawstring drawable x y teststr))))))
> 
> 
> 
> ;; Run a five second frame in a Japi server
> (with-server ("GCL Japi library test GUI 1" 0)
> 	     (with-frame (frame "Five Second Blank Test Frame")
> 			 (j_show frame)
> 			 (j_sleep 5000)))
> 
> 
> ;; Run some more extensive tests
> (with-server
>  ("GCL Japi library test GUI 2" 0)
>  (with-frame
>   (frame "Draw")
>   (j_show frame)
>   (let ((alert (j_messagebox frame "Two second alert box" "label")))
>     (j_sleep 2000)
>     (j_dispose alert))
>   (let ((result1 (j_alertbox frame "label1" "label2" "OK"))
> 	(result2 (j_choicebox2 frame "label1" "label2" "Yes" "No"))
> 	(result3 (j_choicebox3 frame "label1" "label2" "Yes" "No" "Cancel")))
>     (format t "Requestor results were: ~D, ~D, ~D~%" result1 result2
> result3))
>   (j_setborderlayout frame)
>   (with-menu-bar
>    (menubar frame)
>    (with-menu
>     (file menubar "File")
>     (with-menu-item
>      (print file "Print")
>      (with-menu-item
>       (save file "Save BMP")
>       (with-menu-item
>        (quit file "Quit")
>        (with-canvas
> 	(canvas frame 400 600)
> 	(j_pack frame)
> 	(drawgraphics canvas 0 0 (j_getwidth canvas) (j_getheight canvas))
> 	(j_show frame)
> 	(do ((obj (j_nextaction) (j_nextaction)))
> 	    ((or (= obj frame) (= obj quit)) t)
> 	    (when (= obj canvas)
> 	      (j_setnamedcolorbg canvas J_WHITE)
> 	      (drawgraphics canvas 10 10
> 			    (- (j_getwidth canvas) 10)
> 			    (- (j_getheight canvas) 10)))
> 	    (when (= obj print)
> 	      (let ((printer (j_printer frame)))
> 		(when (> 0 printer)
> 		  (drawgraphics printer 40 40
> 				(- (j_getwidth printer) 80)
> 				(- (j_getheight printer) 80))
> 		  (j_print printer))))
> 	    (when (= obj save)
> 	      (let ((image (j_image 600 800)))
> 		(drawgraphics image 0 0 600 800)
> 		(when (= 0 (j_saveimage image "test.bmp" J_BMP))
> 		  (j_alertbox frame "Problems" "Can't save the image" "OK")))))))))))))
> 
> ;; Try some mouse handling
> (with-server
>  ("GCL Japi library test GUI 3" 0)
>  (with-frame
>   (frame "Move and drag the mouse")
>   (j_setsize frame 430 240)
>   (j_setnamedcolorbg frame J_LIGHT_GRAY)
>   (with-canvas
>    (canvas1 frame 200 200)
>    (with-canvas
>     (canvas2 frame 200 200)
>     (j_setpos canvas1 10 30)
>     (j_setpos canvas2 220 30)
>     (with-mouse-listener
>      (pressed canvas1 J_PRESSED)
>      (with-mouse-listener
>       (dragged canvas1 J_DRAGGED)
>       (with-mouse-listener
>        (released canvas1 J_RELEASED)
>        (with-mouse-listener
> 	(entered canvas2 J_ENTERERD)
> 	(with-mouse-listener
> 	 (moved canvas2 J_MOVED)
> 	 (with-mouse-listener
> 	  (exited canvas2 J_EXITED)
> 	  (j_show frame)
>           ;; Allocate immovable storage for passing data back from C land.
> 	  ;; Uses the GCL only make-array keyword :static
> 	  (let* ((xa (make-array 1 :initial-element 0 :element-type 'fixnum :static
> t))
> 		 (ya (make-array 1 :initial-element 0 :element-type 'fixnum :static t))
> 		 (pxa (inta-ptr xa))
> 		 (pya (inta-ptr ya))
> 		 (x 0)
> 		 (y 0)
> 		 (get-mouse-xy (lambda (obj)
> 				 (progn (j_getmousepos obj pxa pya)
> 					(setf x (aref xa 0))
> 					(setf y (aref ya 0)))))
> 		 (startx 0)
> 		 (starty 0))
> 	    (do ((obj (j_nextaction) (j_nextaction)))
> 		((= obj frame) t)
> 		(when (= obj pressed)
> 		  (funcall get-mouse-xy pressed)
> 		  (setf startx x)
> 		  (setf starty y))
> 		(when (= obj dragged)
> 		  (funcall get-mouse-xy dragged)
> 		  (j_drawrect canvas1 startx starty (- x startx) (- y starty)))
> 		(when (= obj released)
> 		  (funcall get-mouse-xy released)
> 		  (j_drawrect canvas1 startx starty (- x startx) (- y starty)))
> 		(when (= obj entered)
> 		  (funcall get-mouse-xy entered)
> 		  (setf startx x)
> 		  (setf starty y))
> 		(when (= obj moved)
> 		  (funcall get-mouse-xy moved)
> 		  (j_drawline canvas2 startx starty x y))
> 		(setf startx x)
> 		(setf starty y)
> 		(when (= obj exited)
> 		  (funcall get-mouse-xy exited)
> 		  (j_drawline canvas2 startx starty x y))))))))))))))
> 
> ;; Text editor demo
> (with-server
>  ("GCL Japi library test text editor" 0)
>  (with-frame
>   (frame "A simple editor")
>   (j_setgridlayout frame 1 1)
>   (with-panel
>    (panel frame)
>    (j_setgridlayout panel 1 1)
>    (with-menu-bar
>     (menubar frame)
>     (with-menu
>      (file-mi menubar "File")
>      (with-menu-item
>       (new-mi file-mi "New")
>       (with-menu-item
>        (save-mi file-mi "Save")
>        (j_seperator file-mi)
>        (with-menu-item
> 	(quit-mi file-mi "Quit")
> 
> 	(with-menu
> 	 (edit-mi menubar "Edit")
> 	 (with-menu-item
> 	  (select-all-mi edit-mi "Select All")
> 	  (j_seperator edit-mi)
> 	  (with-menu-item
> 	   (cut-mi edit-mi "Cut")
> 	   (with-menu-item
> 	    (copy-mi edit-mi "Copy")
> 	    (with-menu-item
> 	     (paste-mi edit-mi "Paste")
> 
> 	     (with-text-area
> 	      (text panel 15 4)
> 	      (j_setfont text J_DIALOGIN J_BOLD 18)
> 	      (let ((new-text (format nil "JAPI (Java Application~%Programming
> Interface)~%a platform and language~%independent API")))
> 		(j_settext text new-text)
> 		(j_show frame)
> 		(j_pack frame)
> 		(j_setrows text 4)
> 		(j_setcolumns text 15)
> 		(j_pack frame)
> 		;; Allocate immovable storage for passing data back from C land.
> 		;; Uses the GCL only make-array keyword :static
> 		(let* ((xa (make-array 1 :initial-element 0 :element-type 'fixnum :static
> t))
> 		       (ya (make-array 1 :initial-element 0 :element-type 'fixnum :static
> t))
> 		       (pxa (inta-ptr xa))
> 		       (pya (inta-ptr ya))
> 		       (x 0)
> 		       (y 0)
> 		       (get-mouse-xy (lambda (obj)
> 				       (progn (j_getmousepos obj pxa pya)
> 					      (setf x (aref xa 0))
> 					      (setf y (aref ya 0)))))
> 		       (startx 0)
> 		       (starty 0)
> 		       (selstart 0)
> 		       (selend 0)
> 		       (text-buffer (make-array 64000 :initial-element 0 :element-type
> 'character :static t))
> 					;	      (text-buffer (make-string 64000 :initial-element #\0))
> 		       (p-text-buffer (inta-ptr text-buffer)))
> 		  (do ((obj (j_nextaction) (j_nextaction)))
> 		      ((or (= obj frame) (= obj quit-mi))t)
> 		      (when (= obj panel)
> 			(format t "Size changed to ~D rows ~D columns~%" (j_getrows text)
> (j_getcolumns text))
> 			(format t "Size changed to ~D x ~D pixels~%" (j_getwidth text)
> (j_getheight text)))
> 		      (when (= obj text) (format t "Text changed (len=~D)~%" (j_getlength
> text) ))
> 		      (when (= obj new-mi) (j_settext new-text))
> 		      (when (= obj save-mi) (j_gettext text text-buffer))
> 		      (when (= obj select-all-mi) (j_selectall text))
> 		      (when (or (= obj cut-mi)
> 				(= obj copy-mi)
> 				(= obj paste-mi))
> 			(setf selstart (1- (j_getselstart text)))
> 			(setf selend (1- (j_getselend text))))
> 		      (when (= obj cut-mi)
> 			(j_getseltext text p-text-buffer)
> 			(j_delete text (1- (j_getselstart text)) (1- (j_getselend text)))
> 			(setf selend selstart))
> 		      (when (= obj copy-mi)
> 			(j_getseltext text p-text-buffer))
> 		      (when (= obj paste-mi)
> 			(if (= selstart selend)
> 			    (j_inserttext text p-text-buffer (1- (j_getcurpos text)))
> 			  (j_replacetext text p-text-buffer (1- (j_getselstart text)) (1-
> (j_getselend text))))
> 			))))))))))))))))))
> 
> (defun mandel (drawable min_x max_x min_y max_y step_x step_y)
>   (let* ((scale_x (/ 1 step_x))
> 	 (scale_y (/ 1 step_y)))
>     (loop for y from min_y to max_y by step_y do
> 	  (loop for x from min_x to max_x by step_x do
> 		(let* ((c 255)
> 		       (z (complex x y))
> 		       (a z))
> 		  (loop while (and (< (abs
> 				       (setq z (+ (* z z) a)))
> 				      2)
> 				   (>= (decf c) 0)))
> 		  (j_setcolor drawable c c c)
> 		  (j_drawpixel drawable (* scale_x (+ (abs min_x) x)) (* scale_y (+ (abs
> min_y) y)) ))))))
> 
> ;;; Monochrome Mandelbrot
> (with-server
>  ("GCL Japi library test GUI 4" 0)
>  (let* ((min_x -2)
> 	(max_x  1)
> 	(min_y -1)
> 	(max_y  1.1)
> 	(step_x 0.01)
> 	(step_y 0.01)
> 	(size_x (+ 1 (/ (- max_x min_x) step_x)))
> 	(size_y (+ 1 (/ (- max_y min_y) step_y))))
>    (with-frame
>     (frame "Mandelbrot")
>     (j_setsize frame size_x size_y)
>     (j_setborderlayout frame)
>     (with-menu-bar
>      (menubar frame)
>      (with-menu
>       (file menubar "File")
>       (with-menu-item
>        (save file "Save BMP")
>        (with-menu-item
> 	(quit file "Quit")
> 	(with-canvas
> 	 (canvas1 frame size_x size_y)
> 	 (j_pack frame)
> 	 (j_show frame)
> 	 (j_show canvas1)
> 	 (mandel canvas1  min_x max_x min_y max_y step_x step_y)
> 	 (do ((obj (j_nextaction) (j_nextaction)))
> 	     ((or (= obj frame) (= obj quit)) t)
> 	     (when (= obj save)
> 	       (let ((image (j_getimage canvas1)))
> 		 (when (= 0 (j_saveimage image "mandel.bmp" J_BMP))
> 		   (j_alertbox frame "Problems" "Can't save the image" "OK"))
> 		 (j_dispose image) )))))))))))
> 

\start
Date: Wed, 27 Apr 2005 11:41:25 -0700 (PDT)
From: Cliff Yapp
To: Camm Maguire
Subject: Re: [Gcl-devel] RE: Possible GCL 2.6.7 for axiom
Cc: Mike Thomas Mike Thomas,

--- Camm Maguire wrote:
>
> Wonderful initiative!
> 
> These are just my simple thoughts on these broader questions:
> 
> 1) I worry a lot that concern over graphics, as valuable as it is,
>    detracts seriously from developer attention to the core math
>    abilities of these systems.

Only if it is true that effort by people working on graphics could be
used to do mathematical work.  The skills are somewhat different. 
Currently this may be true, since we have relatively small development
teams on both Maxima and Axiom, but to be fair on both projects the
core functionality (and code cleanup) is much higher priority.  Maxima
as a project hasn't devoted much energy to this since the gnuplot/plot
improvements - wxMaxima is an improvement over Xmaxima, but is being
worked on as a separate project. 

I can safely discuss this because I'm not sufficiently skilled (at
least at this point) to be tinkering with the core mathematical code. 
My most ambitious project to date has been teaching Maxima about units,
which has its wrinkles but can't be considered serious core
functionality.  So I'm not much of a loss on core math issues :-).

> 2) In keeping with the above, there seems to be a well-intentioned
>    desire to try to attract mass market users with dazzling eye 
>    candy.

Well, I like pretty pictures too ;-) but yes I guess that's the case.

>    My only quibble is one of priority -- what are these attracted
>    users going to contribute back to the community?  

If you mean by directly working on the code, no.  But they will help
build the momentum of the project, and its relevance to people other
than its current developers.

> If we did attract them now, are we ready to respond to a deluge of 
> feature requests and complaints?

Clearly we aren't, in the sense that everything else we want to take
care of is done.

>  If not, will these users turn against the project
>    when their desires are not immediately gratified and the latest
>    alternative toy becomes available?

Possibly.  But what alternative toys are you thinking of?  I doubt
Axiom and Maxima have any serious free competition at the moment -
there is too much work involved building up systems to their current
levels of ability.  I hope Maxima and Axiom can someday both make use
of the same lisp UI code - this will help both projects and enable end
users to use both systems more easily, since they will be using the
same basic GUI and only need to adjust to quirks associated with each
system's unique features and syntax.  I always viewed Maxima as the
"free Mathematica but better" project, and Axiom as something new
focused on theoretical purity and correctness above all else.  I think
these tools are complimentary more than they are competitive, and it
never hurts to have another system to check results in :-).

> 3)I also worry that we are not mass marketing specialists, and that
>   we cannot design a system based on what we imagine 'those users
>   out there' want.  What we can do is develop the system so that it
>   presents real value to the work *we actually do*, fix the bugs that
>   bother us, add what we think is imperative for us to be able to
>   rely on the system ourselves, etc.  If we do this, others like us
>   are bound to see the value too, and some of them will join us.  If
>   and when we get a large enough team intimately familiar with the
>   system, we can then try to reach out little by little to the mass
>   market, who are most likely to be 'takers' rather than 'givers' by
>   simple necessity of the overwhelming complexity of these systems. 

I don't mind the "takers" so much, since if nothing else they are
involuntary bug testers.  And every "taker" who uses the program
spreads the word.  But I agree a robust system is a better platform to
work from.  Probably what will happen (and is probably already
happening) is that potential takers are downloading and trying out the
system all the time (I think the download figures suggest this,
actually - I remember Tim Daly wondering who all those downloaders
were.)  There are lots of non-serious but curious folk out there, and
even they are good for spreading the word.  We dont' need to advertise
until we feel the system is "ready" but people are of course free to
check it out, so matters will evolve naturally.  

> 4) To the extent that we adopt this perspective, the only critical
>    need for graphics in these systems is the ability to plot and
>    print mathematical functions, IMHO.  At this early stage in its 
>    open source life, I would recommend axiom adopt the simplest and 
>    most portable system with a sizable user base, preferably 
>    maintained and developed externally, and to then move on to the
>    algorithms.

I'll agree here, with the hope that expedience can be substituted for
"the right way" at some point in the future when the math is robust
enough.

>    Maxima has adopted gnuplot, which I think is a wonderful and
>    powerful choice.  We have a working alternative system now and
>    there is no need to throw this away, but if we ever feel the need
>    to do something new in this area (for example, because our
>    existing graphics does not yet work on Windows), this is the 
>    direction I would recommend for now.

Probably a decent idea.  I'm not sure how "wonderful" I'd say gnuplot
is (ask Jim what he thinks about it sometime :-), but it does get the
job done reasonably well and it's clearly the best current free
solution.
 
> 5) In the longer term, lisp graphics is certainly very interesting,
>    and some beautiful work from a programming point of view has been
>    done, notably the McCLIM to which you refer.  The only problem
>    here which is nonetheless quite serious is the lack of unity or
>    consensus.  No one can afford to invest the time in putting
>    something together if they run the extremely high risk that it
>    will be abandoned later due to the extraordinary degree of
>    fractiousness in this area.  People need to see the payback 
>    measured in terms of user contributions in the future -- in this 
>    way they lever their own efforts.  Ask the question, "If I do 
>    this, what new user contributions will I likely trigger?"

Unknown, and unknowable currently, for whichever system you might
consider.  :-/.  This has been the primary reason I've not discussed
this more on the Maxima list - I've been waiting to see where the
various toolkits go and what the possibilities are.  We don't need to
make a final choice for quite a while since, as you noted earlier,
there are much more urgent matters to attend to.

> 6) Here is a list of lisp graphics options of which I am aware, all
> of which are workable with possible modest effort within GCL, but
> none of which appear to have any serious use by any existing
> applications.  (Please correct me if I am mistaken:)
> 
>         a) xgcl --
> http://www.cs.utexas.edu/users/novak/cgi/xgcldemo.cgi

Don't know much about this one - my initial reaction is it is too low
level to be attractive for this type of work, assuming it is an
interface to xlib.

>         b) gcl-tk -- (tk::connect)(load "...gcl-tk/demos/widget.lsp")

Has the advantage of being more active, but my tk bias kicks in here so
I'm disqualified. 

>         c) ltk  -- another tk binding

I think Tim said this looked like the best bet to get things working
quickly?  tk bias again rules me out here.

>         d) gtk-based -- cl-gtk, lgtk, http://www.cliki.net/Gtk

This is promising, but I don't know enough about how "good" these
bindings are to comment.

>         e) garnet -- http://garnetlisp.sourceforge.net/

Ah yes, garnet.  I set up the sourceforge site before I was really
aware of McCLIM, and I still like it as a toolkit, but between it's not
using CLOS and needing a serious modernization of its look and feel... 
Someday it may rise again, but for now I don't think this is the best
choice since it has no active development team to speak of.  This one
will bug me indefinitely because I think it SHOULD be modernized - it
deserves it.  But I can't recommend it at this point.

>         f) clx, clue, clio, clim, mcclim

McCLIM to my mind is the best choice right now, for the following
reasons:

1)  Active development team (we wouldn't have to maintain toolkit and
CAS.)
2)  CLIM is as close to a GUI "standard" as the lisp world gets.
3)  With different backends we might be able to get native look and
feel on a wide variety of platforms - for instance, gtk and QT backends
might let us fit nicely on both Gnome and KDE desktops with one set of
code.

With the exception of Garnet, which was used in some special purpose
apps long ago, McCLIM is the only of these toolkits where I do know of
a program written using it - Gsharp.  There was also the Closure web
browser, although I don't know if that has been maintained.  

>         g) cells/cello -- comp.lang.lisp

Can't comment much on this one - haven't figured it out.

>         h) Java based japi -- lsp/gcl_japi.lsp

I would prefer not to rely on Java, but that's just a personal
preference.

> 7) In deciding among these longer term options, please let me
>    emphasize that any are likely workable, but it is very important
>    IMHO that we pick at most one if we are to avoid wasting our
>    lives.  I also think it important that we
> 
>    a) choose a purely open source option

On most of the lisp alternatives we should be in the clear as far as
that goes.

>    b) cross-platform

There is no simple solution here, particularly from a lisp based
standpoint - my favorite idea is to wait for QT4, which will have GPL
versions both on Windows and Linux, and create an McCLIM backend for
that.

>    c) wide user base -- this effectively means a huge C user
>       base with a smaller user base of tight lisp bindings

Um.  You mean lisp bindings to a popular toolkit?

>    d) robust

This will probably come only with time and extensive testing.
 
>    e) actively developed elsewhere

This puts McCLIM at the front of the class in the Lisp GUI department,
as far as I know.
 
>    f) comes with a graphical interface builder -- as attractive
>       as graphical programming in lisp might be, even though it is
>       lisp, it is still much less efficient IMHO than using a tool
>       like glade.  I've used this myself in C, and I haven't had to
>       write a single gtk call.

Garnet I know had an interface builder, but I was never able to get it
to work reliably.  Not sure if McCLIM has one, but it is a VERY good
idea.  

>         g) LGPL is preferable to GPL if we're doing a general
>         interface, but I have no problems with GPL myself.

Maxima is LGPL, and Garnet is public domain - not sure about the
others.

>    All of this would appear to argue in favor of cl-gtk or the like.
>    Tim Daly Jr. has worked on it, and he indicates it would probably
>    take a week's work to get running under GCL.  We need to know how
>    good the Windows and MacOSX ports are.  *If we all agree* that
>    this is the way forward, I'll be happy to donate a few cycles to 
>    moving it along.

Well, I don't really get to say anything substantial unless I actually
show code, so don't worry about me.


> I think this is wonderful!  If you have the time to take this ball
> and lead with it, I'll be happy to support.  As stated above, I 
> think gtk is a slightly better choice than QT, but *whatever draws 
> consensus* is the best!

That's one of the reasons I favor McCLIM - it makes the GTK vs. QT
choice not an either/or proposition.

I'm not sure whether I can become skilled enough to do a good set of
bindings, but it would certainly be a challenge.

> This is well founded, I think.  tk is quick and portable, not
> necessarily 'robust and polished'.  The importance of the latter for
> these considerations is questionable.  Can you describe the maxima
> experience?  

Essentially the problems stem from us having to fix problems in the
Xmaxima code.  The "included" openmath plots was an odd affair that
never behaved reasonably when scrolled, and getting things working on
Windows was always a challenge for any given release.  I never was able
to figure out the TCL/TK code myself - I know Jim (our project leader)
really didn't want to mess with it.  We did finally get someone who was
knowledgeable to clean it up, but given Maxima is a lisp project we
were of the general opinion it was annoying to have to maintain a UI in
another language.  I'm only one (biased) source though, so I recommend
checking the list archvies for Xmaxima issues.  My memory may be making
it sound worse than it was. 
 
My GTK on Windows misgivings stem mainly from my own experiences with
it - GTK doesn't really "feel" like a native Windows interface.  QT I
know Trolltech supports on Windows as one of their most significant
platforms, and I'm guessing they will do their best to ensure QT apps
look and behave like normal Windows programs.  GTK is workable too, and
I wouldn't be at all opposed to seeing McCLIM+GTK, but my personal
preference would be QT to try and avoid the "this doesn't act like a
regular Windows program" phenomena.  This might have been fixed over
time though, so my reaction could be quite dated.  I haven't used
Windows in a significant way in quite a while, so I have no recent
experience.

\start
Date: Wed, 27 Apr 2005 15:22:12 -0400
From: Bill Page
To: list
Subject: RE: axiom graphics and porting
Cc: Camm Maguire

In the context of this discussion let me recall a much earlier
email from Mike Dewar:

http://lists.gnu.org/archive/html/axiom-developer/2002-11/msg00151.html


On Thu, Nov 28, 2002 at 10:35:20AM -0500, Tim Daly wrote:
<snip> 
> Mike Dewar wrote:
> > 1. Graphics: On Unix this is done with a combination of bespoke
> > Axiom data structures and some pretty convoluted X-Windows code.
> > On Windows we added facilities to create OpenInventor data structures
> > (OpenInventor is the basis for VRML - the virtual reality markup
> > language).  The Inventor geometries were then exported to a little
> > application we wrote based on the standard SceneViewer application
> > you get with many OpenInventor toolkits.  The results were definitely
> > superior to the Unix version.
> 
> Is the "little application" in the code we have? If not, would NAG
> be willing to share it?

No and no :-(  As I said its based on something which was part of the
Inventor toolkit we were using and that is a commercial product which
we were licensing.  However it shouldn't be too difficult to find a
free VRML viewer and adapt that.  

> I'm happy to hear that work was done to make the graphics more open.
> One of the stated goals on the homepage is to "give away" the graphics.
> I was planning to enhance the abilities of some other open source
> product (like GNUPlot) with the facilities available in Axiom. That
> way they gain with new function and we gain because we don't have to
> support the graphics any more.

I think we looked at GNUPlot and decided it wasn't good enough because
it lacked many of the features for manipulating 3D images that were in
the Unix version.  Using Open Inventor/VRML means you can export images
to industrial-strength visualisation packages which was important to us.
After we released Axiom under Windows, Maple moved their graphics onto
OpenGL (the toolkit Open Inventor is built on) so we're not the only
people who think that this is a good approach :-) Of course GNUplot has
probably come a long way since we looked at it and may be suitable for
your needs, but I doubt its as good as Mathematica and Maple's
offerings.

> The graphics facility is useful and necessary but the expertise
> needed to do it right is a whole other field of research. Scott
> Morrison did the graphics and he's no longer following computer
> algebra.

Don't underestimate the importance of visualisation and computer
algebra.  Over the years I've met a number of users who chose Axiom
primarily because of its graphics.
 
> If you happen to have some useful web and/or book references I'd
> appreciate it if you mention them to the group.

http://www.web3d.org/vrml/vrml.htm seems to be a good place to start
investigating VRML.

...

-----------

In the meantime VRML has evolved into X3D. See

http://www.web3d.org/x3d/overview.html

And OpenInventor is now available as open source

http://oss.sgi.com/projects/inventor

and is apparently also available for native Windows

http://www.studierstube.org/openinventor

I think the concepts discussed here by Tim and Mike still apply,
maybe even more so. If Axiom graphics needs to be re-written
and/or modified to be more portable between linux and Windows
then I definitely think that consideration should be given
to compatibility with the web as well. X3D/VRML seems to me
to be a good approach. This looks especially attractive in
the context of the MathAction website since it would allow
Axiom graphics to be served in a compatible manner between
the desktop and a remote graphics browser. This is also
obviously important for the Doyen project.

It seems quite clear that what we called "computer graphics"
yesterday is just going to be some limited form of virtual
reality display in the near future. From my point of view,
if we have to invest significant effort in re-developing
things, then we should aim as high as is practical. Otherwise
it would be better I think to just take the shorter path
(involving Cygwin as described previously).

As far as I can tell right now the only cross-platform
desktop X3G browser is dependent on java

http://www.xj3d.org

but that might change in the next few months as more
options become available.

In any case, perhaps we should seriously consider trying
to recover NAG's work on OpenInventor in Axiom graphics.

\start
Date: Wed, 27 Apr 2005 16:15:19 -0400
From: Bill Page
To: list
Subject: RE: Axiom HyperTex browser and porting
Cc: Camm Maguire

Here is part of another related discussion between Tim and Mike Dewar:

http://lists.gnu.org/archive/html/axiom-developer/2002-11/msg00143.html

...
> Mike Dewar wrote: 
> I wouldn't try porting the X-based graphics to Windows but would
> either use the OpenInventor stuff and one of the free VRML viewers
> or use the same approach with a different standard format.  For 3D
> graphics the OI stuff worked pretty-much out-of-the-box, we just
> added menus for axes, scales etc.  For 2D plots we had to add some
> extra code but that wasn't too hard.

I'll take that advice. Do you happen to know of compatible VRML
viewers that work on both Windows and Unix?
 
> 2. The Browser: This is the part of HyperTex which allows you to
> look up domains, categories, operations etc. as opposed to the whole
> HyperTex environment.  For the Windows version we pushed a lot of
> the code which was in the HyperTex application or used Unix scripts
> into either the interpreter (via boot code) or in some cases into
> the underlying Lisp (I added a grep function based on some existing
> NAG code for example). Incidentally this kind of thing will probably
> give you problems when you try using different lisps ...

The browser was a piece of the system that was leading edge
for its time (the web and browsers didn't exist yet). The stated
plan is to "give away" the browser. In this case what that implies
is rewriting the system so it uses a real browser instead of our
home-grown one.

... I AM glad that you pushed the scripts and other cruft into lisp.
 
> The upshot of this is that all you require from the front end
> is a simple forms interface and everything else can be done by
> the interpreter, all the old stuff using scripts and C code is
> obsolete.

This is good news.

---------

Tim,

Is it correct that the current release of Axiom on linux
includes only this "old stuff"? If so, what are the prospects
for implementing HyperTex using a "real browser" as you
seemed to be planning back in 2002? As I understand it,
that would mean providing a simple web server interface to
Axiom, calling the boot functions written by NAG and running
a standard web browser on the desktop.

All of this sound much easier than porting a low level graphics
application (or even re-writing it to some more portable higher
level GUI like Gtk).

Persumably this approach would also be applicable to the
MathAction interface to Axiom and would provide yet another
thing that could be integrated between desktop and remote
web server for the Doyen project.

\start
Date: Wed, 27 Apr 2005 14:15:01 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Axiom HyperTex browser and porting
Cc: Camm Maguire

If VRML is still of interest perhaps this would be useful?

http://www.openvrml.org/

\start
Date: Thu, 28 Apr 2005 11:43:53 +1000
From: Mike Thomas
To: Camm Maguire
Subject: RE: [Gcl-devel] Re: axiom graphics and porting

Hi Camm.

| 1) How good is gtk (as opposed to tk) on Windows?

I haven't used it to write software.  It was ported by Tor Lillqvist to
port the GIMP to Windows.

In terms of end user experience with the GIMP on Windows it seems to be
entirely usable if somewhat clunky and very large and intrusive (you
apparently have to install GTK separately, taking multi-megabytes for all of
the emulation machinery).

I note that the GHC and Moscow ML Glib/GTK bindings each seem to be fairly
sleepy if not dead on Windows - presumably lack of interest or technical
issues or both.


| 2) I remember us discussing the gcl-tk issues on Windows, but cannot
|    find the thread at the moment.  My understanding is that the issue
|    lies in the socket emulation.

Yes, or at least the interprocess communication at some level.


|  How difficult is this to fix?

Relatively simple - I would happily support such a move for 2.7 or even
2.6.7.

|  Do
|    you have an estimate in terms of time?

No.

|  What could I do from the
|    Linux side to assist?

The usual well received debugging/moral support I suppose.

| 3) Is there an easy analog for an xgcl type interface on Windows?

No.

| 4) Does the recent patch I just posted on run-process work for
|    windows?

No; not because of the patch which applies and compiles, but because of
pre-existing problems which I will try to address later this week.

\start
Date: Thu, 28 Apr 2005 11:14:47 -0500
From: MathAction (loli)
To: MathAction
Subject: [#150 To create a function from an expresion] (new) 

I don't now how ...
If I enter:
---------------------
expr:= 3*x
f(x) == expr
f(5)
---------------------
I get an otput of 3x; I would like an otput of  15.
Is there a way to do it rigth? 

\start
Date: Thu, 28 Apr 2005 11:50:07 -0500
From: MathAction (Martin Rubey)
To: MathAction
Subject: [#150 To create a function from an expresion]

\begin{axiom}
expr := 3*x
function(expr, f, x)
f(5)
\end{axiom}

\start
Date: Thu, 28 Apr 2005 12:37:54 -0500
From: Tim Daly
To: Mike Thomas, Camm Maguire, Cliff Yapp, Bill Page
Subject: axiom porting

Lots of discussion and interest on this subject I see...

My current thinking on the matter is that the first priority will
be to just get it working the way it was. This has several dimensions.

The code is now in C/X11, neither of which is very portable. C has
more ifdefs than code and X11 won't work on windows. 

The cygwin path could potentially allow a direct port but is not of
interest for other reasons. I've tried cygwin before as the initial
porting platform and it was painful. Plus, having both cygwin and msys
would be a bit much. So this rules out the X11-on-windows version.

Which implies a rewrite to use a different code base and a
different windowing scheme.

With respect to a code rewrite I've decided to rebuild the code in
common lisp for several reasons. First, it is easier to port. Second,
it is a language I know well. Third, it will allow us to "lift" the
windowing functions up into the axiom system proper so other people
can create windows in their code. Fourth, it will allow the unification
of windowing/graphing data structures and spad data structures.

With respect to the windowing scheme we are confronted with a large
variety of front-end mechanisms. In any of the proposed mechanisms
we need a working example of, for instance, the first page of the
hyperdoc browser. That will ground the proposals in reality. For example,
http://daly.axiom-developer.org/TimothyDaly_files/pamphlets/jman.pamphlet

The current plan is to have some sort of dumb front-end that implements
some low-level graphics API and move the rest of the code into lisp.
The graphics API needs to cover both the browser and graphics abilities.

As I've mentioned I've tried various paths. Camm, Bill, and I had a 
discussion about these during the sprint day. Camm pointed me at the
sources for TK. I've already written a piece of a TK replacement in Java.

TK might work. I'm going to the bookstore today to get educated about
the details. Since both TK and my Java code use sockets it would seem
that we could use a common syntax. Such an approach would make it easy
to shift between the two front ends. I'm not sure how feasible this is.

I've looked at GNUPLOT but their license does not seem to allow me to
modify and distribute. And their code has more ifdefs than C code which
is a sure sign of a porting headache.

I've looked at McClim which is a path I'd dearly love to take but so
far I've not gotten it to work. If someone could reproduce the first
page of the browser (a few buttons, an image) in McClim that might be
enough to get me over the hurdle. A pure lisp solution is preferred.

The graphics and browser run in separate threads using sockets to
communicate to the algebra. Due to the run-process issue in GCL the
front end is being done using CLISP but nothing in the code cares
which lisp is used.

I've spoken to Tim Daly Jr. about the lisp-gtk work and he believes
it is not ready for production use.

The SVG, VRML, CSG, and Flash enhancements would be nice but are
definitely in the future development categories. There is still a
huge amount of algebra work to be done before any work gets applied
to enhancing the graphics.

Of course, it's all open to discussion.

\start
Date: Thu, 28 Apr 2005 11:10:01 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Bill Page
Subject: Re: axiom porting

--- Tim Daly wrote:

> With respect to the windowing scheme we are confronted with a large
> variety of front-end mechanisms. In any of the proposed mechanisms
> we need a working example of, for instance, the first page of the
> hyperdoc browser. That will ground the proposals in reality. 

Tim, by working you mean something that communitcates with Axiom?

[snip]

> I've looked at McClim which is a path I'd dearly love to take but so
> far I've not gotten it to work. If someone could reproduce the first
> page of the browser (a few buttons, an image) in McClim that might be
> enough to get me over the hurdle. A pure lisp solution is preferred.

Well, since I'm the McCLIM advocate I'll see what I can come up with.
(Gulp.)  You might ask the McCLIM developer list about specific
problems/issues - they tend to be very helpful.

\start
Date: Thu, 28 Apr 2005 14:07:13 -0400
From: William Sit
To: list
Subject: [Fwd: IAMC'05 : CALL for PAPERS and DEMOS]

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

Dear colleague,

You'll find below the call for papers for IAMC'05, a 1-day workshop
dedicated to Internet Accessible Mathematical Computation.

IAMC'05 will be held at ISSAC'05 in Beijing (China) on July 24, 2005
as a pre-conference event.

For up-to-date information, please visit :
   http://www.symbolicnet.org/conferences/iamc05

Best regards,
-- Dr. Norbert Kajler

..............................................................................

              Internet Accessible Mathematical Computation

                        a Workshop at ISSAC 2005

                          Sunday July 24 2005
                    Academia Sinica, Beijing, China


                   ---------------------------------
                    C A L L    F O R    P A P E R S

                    &  S O F T W A R E    D E M O S
                   ---------------------------------


The Internet Accessible Mathematical Computation 2005 Workshop (IAMC 2005)
is being co-organized by Laureano Gonzalez of University of Cantabria
(Spain), Norbert Kajler of Ecole des Mines de Paris (France), Dongdai Lin
of Institute of Software Chinese Academy of Sciences (China), Andrew
Solomon of IT, UTS (Australia), and Paul Wang of Kent State
Univ. (USA). The workshop is part of ISSAC'05 with the support of ISSAC'05
co-chairs Xiao-shan Gao (MMRC, Academia Scinica, China) and George Labahn
(University of Waterloo, Canada).

IAMC'05 will involve invited talks, contributed papers, and software
demonstrations. This is the sixth IAMC workshop following IAMC'99, IAMC'01,
IAMC'02, IAMC'03, and IAMC'04.

The workshop is free for all ISSAC'05 participants.

Everyone with an interest in the many aspects of making mathematical
computation or information accessible on the Web/Internet is welcome to
attend. Topics of the workshop include, but are not limited to:
- Remote access to mathematical software over the Internet.
- Encoding of mathematical expressions (including text-based encoding,
  for E-mail and HTML embedding, and binary-based encoding for efficient
  communication between scientific applications).
- Interoperability between software that create/transform/display mathematical
  expressions (e.g. symbolic, numeric, graphics, text-processing packages)
  via ad hoc communication protocols and software architectures.
- Web-based mathematics education.
- Access to and interoperability of mathematical knowledge bases.
- Protocols, APIs, URL schemes, metadata, and other mechanisms for system
  interoperability, parallel/distributed computing, and standardization.
- Application of IAMC for practical purposes such as scientific publishing
  and archiving, distributed problem solving, ...

INVITED SPEAKER

Prof. Hai Jin, Professor, Director, Cluster and Grid Computing Lab, Vice-Dean,
School of Computer, Huazhong University of Science and Technology, Wuhan, China

Title and Abstract: to be posted

Prof. Stephen M. Watt, Dept. of Computer Science, U. Western Ontario,
Director, Ontario Research Center for Computer Algebra, Canada

Title and Abstract: to be posted

CONTRIBUTED PAPERS

Authors are invited to send a one or two-pages abstract in PDF to the
organizers by 10 June 2005. Submissions will be reviewed by the workshop
organizers based on relevance to the workshop, originality, and scientific
interest.  Authors will be notified by E-mail around 20 June 2005 so please
include a contact E-mail address in the paper. The full-length paper (in PDF)
is due 10 July 2005.

ELECTRONIC PROCEEDINGS

The Workshop proceedings will be published on the Web and maintained by the
Institute for Computational Mathematics (ICM), Kent State Univ.

SYSTEM DEMONSTRATIONS

If you have an IAMC related system to demonstrate, please let us know as
early as possible (by 5 July 2005), your name and affiliation, the name of
the system(s) to demo, and your equipment request.  We'll then announce all
the demos on the IAMC website.

IMPORTANT DATES

      10 June   2005 --- Deadline for submitting papers/abstracts
      20 June   2005 --- Notification of acceptance and Call for Participation
       5 July   2005 --- Deadline for submitting software demos
      10 July   2005 --- Full-length paper due
      24 July   2005 --- IAMC'05 Workshop

WORKSHOP REGISTRATION

The IAMC Workshop is part of ISSAC'2005. Participants should register with
the ISSAC'2005 conference and select the IAMC workshop.  Although we
encourage everyone to attend the complete ISSAC + IAMC sessions, a reduced
fee (US5) is available for those attending IAMC only.

Information for travel and accomodation (at conference rates) are available
from the ISSAC05 site It is advisable to make hotel reservations early. The
student dorms are easy to afford and close to the meeting.  The hotel is not
obligated to extend the same discount for ISSAC to IAMC-only participants.

SUPPORT FOR STUDENTS

IAMC recognizes the importance of student participation and is planning to
support qualified students attending IAMC'05 with a stipend of up to US
00. We have applied for funding to the US National Science Foundation
and, if funded, will be able to support graduate students from US-based
institutions.

ORGANIZERS

Laureano Gonzalez (Univ. of Cantabria, Spain) -- laureano.gonzalez@unican.es
Norbert Kajler (Ecole des Mines de Paris, France) -- kajler@ensmp.fr
Dongdai Lin (Chinese Academy of Sciences, China) -- ddlin@is.iscas.ac.cn
Andrew Solomon (Faculty of IT, UTS Australia) -- andrews@it.uts.edu.au
Paul S. Wang (ICM, Kent State University, USA) -- pwang@cs.kent.edu

If you are interested please contact one of the organizers. Other details
of this workshop will be forthcoming and will be available on both the
ISSAC'05 official site and on SymbolicNet.

IAMC URL:
  http://www.symbolicnet.org/conferences/iamc05/

ISSAC URL :
  http://www.mmrc.iss.ac.cn/issac2005/

SPONSORS

The IAMC 2005 workshop is sponsored by the Institute for Computational
Mathematics (ICM), Department of Mathematical Sciences and Department of
Computer Science, Kent State University, Kent, Ohio, USA.

The organizers are seeking funding and other sponsors for financial support
of the workshop.

ACKNOWLEDGEMENT

This project has been supported in part by the National Science Foundation
under Grant CCR-0201772

\start
Date: Thu, 28 Apr 2005 13:45:14 -0500
From: Tim Daly
To: Mike Thomas, Camm Maguire, Cliff Yapp, Bill Page, Tim Daly Jr
Subject: axiom porting


> > With respect to the windowing scheme we are confronted with a large
> > variety of front-end mechanisms. In any of the proposed mechanisms
> > we need a working example of, for instance, the first page of the
> > hyperdoc browser. That will ground the proposals in reality. 
> 
> Tim, by working you mean something that communitcates with Axiom?

Nope. Just something that communicates with lisp as a back end and
some drawing front end. 
 
> > I've looked at McClim which is a path I'd dearly love to take but so
> > far I've not gotten it to work. If someone could reproduce the first
> > page of the browser (a few buttons, an image) in McClim that might be
> > enough to get me over the hurdle. A pure lisp solution is preferred.
> 
> Well, since I'm the McCLIM advocate I'll see what I can come up with.
> (Gulp.) You might ask the McCLIM developer list about specific
> problems/issues - they tend to be very helpful.

I asked a few questions there but I'm too much of a newbie. My questions
make it look like I'm asking them to write the code (which I'm not).
Once I have a simple working example I can reverse-engineer the rest
of it.

\start
Date: 28 Apr 2005 14:52:28 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: [Gcl-devel] Simple web server code for GCL	for Windows

Greetings!  Here's a quick way to get started:

=============================================================================
camm@intech19:/fix/t1/camm/debian/gcl/gcl-2.6.6$ diff -u ../gcl-2.6.5/o/file.d o/file.d
--- ../gcl-2.6.5/o/file.d	2004-05-07 21:48:58.000000000 +0000
+++ o/file.d	2005-04-28 16:21:33.000000000 +0000
@@ -1200,11 +1200,19 @@
 	switch (strm->sm.sm_mode) {
 #ifdef HAVE_NSOCKET
 	case smm_socket:
-	  { int ch  = getCharGclSocket(strm,Cnil);
-	   if (ch == EOF) return FALSE;
-	   else unreadc_stream(ch,strm);
-	   return TRUE;
+	  {
+	    fd_set fds;
+	    struct timeval tv;
+	    FD_ZERO(&fds);
+	    FD_SET(SOCKET_STREAM_FD(strm),&fds);
+	    memset(&tv,0,sizeof(tv));
+	    return select(SOCKET_STREAM_FD(strm)+1,&fds,NULL,NULL,&tv)>0 ? TRUE : FALSE;
 	  }
+/* 	  { int ch  = getCharGclSocket(strm,Cnil); */
+/* 	   if (ch == EOF) return FALSE; */
+/* 	   else unreadc_stream(ch,strm); */
+/* 	   return TRUE; */
+/* 	  } */
 #endif	   
 
 	case smm_input:
@@ -2302,6 +2310,42 @@
    
 @)
 
+#ifndef __MINGW32__
+#  include <sys/socket.h>
+#  include <netinet/in.h>
+#  include <arpa/inet.h>
+#else
+#  include <windows.h>
+#  include <winsock2.h>
+#endif
+#include <errno.h>
+
+@(static defun accept (x)
+int fd,n;
+struct sockaddr_in addr;
+object server,host,port;
+@
+  if (type_of(x) != t_stream)
+    FEerror("~S is not a steam~%",1,x);
+  if (x->sm.sm_mode!=smm_two_way)
+    FEerror("~S is not a two-way steam~%",1,x);
+  fd=accept(SOCKET_STREAM_FD(STREAM_INPUT_STREAM(x)),(struct sockaddr *)&addr, &n);
+  if (fd <0) {
+    FEerror("Error ~S on accepting connection to ~S~%",1,make_simple_string(strerror(errno)),x);
+    x=Cnil;
+  } else {
+    server=STREAM_INPUT_STREAM(x)->sm.sm_object0->c.c_car;
+    host=STREAM_INPUT_STREAM(x)->sm.sm_object0->c.c_cdr->c.c_car;
+    port=STREAM_INPUT_STREAM(x)->sm.sm_object0->c.c_cdr->c.c_cdr->c.c_car;
+    x = make_two_way_stream
+      (make_socket_stream(fd,gcl_sm_input,server,host,port,Cnil),
+       make_socket_stream(fd,gcl_sm_output,server,host,port,Cnil));
+  }
+  @(return `x`);
+
+   
+@)
+
 DEF_ORDINARY("MYADDR",sKmyaddr,KEYWORD,"");
 DEF_ORDINARY("MYPORT",sKmyport,KEYWORD,"");
 DEF_ORDINARY("ASYNC",sKasync,KEYWORD,"");
@@ -2441,6 +2485,7 @@
 	make_si_function("FREAD",Lfread);
 #ifdef HAVE_NSOCKET
 	make_si_function("SOCKET",Lsocket);
+	make_si_function("ACCEPT",Laccept);
 #endif
 	make_function("STREAMP", Lstreamp);
 	make_function("INPUT-STREAM-P", Linput_stream_p);
=============================================================================
Starting program: /fix/t1/camm/debian/gcl/gcl-2.6.6/unixport/saved_gcl .
GCL (GNU Common Lisp)  2.6.6 CLtL1    Apr 28 2005 17:10:11
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

>(defun foo (s) 
  (let* ((get (read s nil 'eof)) 
	 (fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
	 (fn (when (probe-file fn) fn)))
    (format s "HTTP/1.1 ~S~%~%" (if fn 404 500))
    (when fn
      (if (pathname-name (pathname fn))
	  (with-open-file (q fn) (si::copy-stream q s))
	(dolist (l (directory fn)) (format s "~a~%" (namestring l)))))
    (close s)))

>(defun bar (p fn) 
  (let ((s (si::socket p :server fn))) 
        (tagbody l 
                (when (si::listen s) 
                        (let ((w (si::accept s))) 
                                (foo w))) 
                (sleep 3) 
                (go l))))

>(bar 8080 #'foo)
=============================================================================

Then point your browser to localhost:8080.  You should be able to get
directory listings and files.  There is obviously no protocol nor
error implementation here, but that should be straightforward for the
web gurus.

This will accept multiple simultaneous connections and process them
one at a time.  The delay mechanism can obviously be adjusted.  Each
connection is stateless -- a multiplexing solution for persistent
connections can be implemented in like manner.  Also, all connections
are in the same process.  It is trivial to fork() in linux for each
connection, but don't know how this would be done on Windows.
Speaking of which, does MS have select?  There are other hooks for
allowing work in the image while connections are handled in the
background, e.g. SIGIO, but don't know the portable nor most desirable
way of doing this.

Anything can be done here that one wishes -- my question is, what is
the advantage vis a vis an external server like apache?  Presumably,
axiom could spit out results directly instead of being called in a
cgi, which is of some value.  Anyway, more discussion on where and why
this should go if anywhere would be great!

Take care,


Bill Page writes:

> GCL Gurus,
> 
> Does anyone know of a simple web server program in lisp that
> works (or should work) under GCL on both linux and Windows?
> I am correct to assume that with socket support working properly
> this should be quite easy (say 20 or 30 lines of code)?
> 
> If an example code exists that works on linux, I would like to
> try it under Windows. If there are problems I would be glad to
> help try debugging it.

\start
Date: Thu, 28 Apr 2005 16:40:42 -0400
From: Bill Page
To: Camm Maguire
Subject: Re: [Gcl-devel] Simple web server code for GCL	for Windows

Camm Maguire wrote:

>Greetings!  Here's a quick way to get started:
>
>=============================================================================
>camm@intech19:/fix/t1/camm/debian/gcl/gcl-2.6.6$ diff -u ../gcl-2.6.5/o/file.d o/file.d
>
Thanks Camm!

The diff command suggests that this code is already in GCL 2.6.6.
Is that correct?

Should I expect the code below to work "out of the box" with the
Windows version of GCL 2.6.6?

>>(defun foo (s) 
>>    
>>
>  (let* ((get (read s nil 'eof)) 
>	 (fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
>	 (fn (when (probe-file fn) fn)))
>    (format s "HTTP/1.1 ~S~%~%" (if fn 404 500))
>    (when fn
>      (if (pathname-name (pathname fn))
>	  (with-open-file (q fn) (si::copy-stream q s))
>	(dolist (l (directory fn)) (format s "~a~%" (namestring l)))))
>    (close s)))
>
>  
>
>>(defun bar (p fn) 
>>    
>>
>  (let ((s (si::socket p :server fn))) 
>        (tagbody l 
>                (when (si::listen s) 
>                        (let ((w (si::accept s))) 
>                                (foo w))) 
>                (sleep 3) 
>                (go l))))
>
>  
>
>>(bar 8080 #'foo)
>>    
>>
>=============================================================================
>
>Then point your browser to localhost:8080.  You should be able to get
>directory listings and files.  There is obviously no protocol nor
>error implementation here, but that should be straightforward for the
>web gurus.
>
>  
>
Great, that is exactly what I was looking for.

>This will accept multiple simultaneous connections and process them
>one at a time.  The delay mechanism can obviously be adjusted.  Each
>connection is stateless -- a multiplexing solution for persistent
>connections can be implemented in like manner.  Also, all connections
>are in the same process.  It is trivial to fork() in linux for each
>connection, but don't know how this would be done on Windows.
>Speaking of which, does MS have select?  There are other hooks for
>allowing work in the image while connections are handled in the
>background, e.g. SIGIO, but don't know the portable nor most desirable
>way of doing this.
>
>Anything can be done here that one wishes -- my question is, what is
>the advantage vis a vis an external server like apache?  Presumably,
>axiom could spit out results directly instead of being called in a
>cgi, which is of some value.
>
Yes! It is a very significant value if one were to try to implement Axiom's
HyperTex browser in a "real browser" as per my previous email and
discussed by Mike Dewar and Tim Daly.

>  Anyway, more discussion on where and why
>this should go if anywhere would be great!
>  
>
My short term objective is to have a simple way to "prove" the
portability of socket connections in GCL, specifically HTTP
access, between Linux and Windows.

My goal is to be in a reasonable position to argue for the following:

I think that using a browser to implement the Axiom gui would be
an excellent way to solve the problem of porting Axiom HyperTex
and Graphics. It seems an extreme waste of scarce resources to
spend time on re-implementing something based on a model that
is now more than 10 years old - that's ancient given the rate at
which this technology is developing. A browser interface would
also be automatically compatible with the web and easily integrated
into web server applications like MathAction.

I have played with HyperTex as now implemented in the most
recent release of open source Axiom and frankly in comparison
to modern browser interfaces, it looks primitive and awkward.
Except for it's ability to simply navigate Axiom's algebra library,
I doubt that it can have much appeal to current computer users.

NAG did a lot of work on Axiom to make it compatible with
Techexplorer on Windows and to replace the old (even then!)
HyperTex browser with something newer and more powerful.
This included adding special code to Axiom to navigate the
Axiom library that was intended to work with a "real browser".
(Techexplorer was essentially IBM's first entry as a mathematics
capable web browser. It is still available in another commercial
incarnation but unfortunately not as part of open source Axiom.)

NAG also apparently did a lot of work on porting Axiom graphics
to OpenInventor. OpenInventor lead to VRML and is now known
as X3D. Since OpenInventor is now open source, I think we are in
an excellent position to take advantage of this work. VRML is also
well adapted to integration with web applications.

The down side is that as far as I know very little documentation is
available for the work that was done by NAG. I am also not certain
exactly how much of this code was in the source package that was
originally delivered to Tim Daly from NAG. My hope is that someone
like Mike Dewar would be willing to work with us develop the
necessary documentation so that we could adapt that work to
currently available open source software.

The benefits of open source and free aside, if Axiom must compete
with commercial products like Mathematica and Maple for a share
of the academic symbolic computer market, then I think we must
aim a little higher than simply providing Axiom as it existed 10 years
ago. And aside from it's superiority in supporting research in new
mathematical algorithms, there are other features of Axiom (especially
Axiom's graphics) that potentially place it still somewhat ahead of
what is available in the commercial M&M's. I think the sooner we
can make these features available in the open source version of
Axiom, the better chance we will have of attracting some serious
interest.

\start
Date: 28 Apr 2005 17:56:30 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: [Gcl-devel] Simple web server code for GCL	for Windows

Greetings!

Bill Page writes:

> Camm Maguire wrote:
> 
> >Greetings!  Here's a quick way to get started:
> >
> >=============================================================================
> >camm@intech19:/fix/t1/camm/debian/gcl/gcl-2.6.6$ diff -u ../gcl-2.6.5/o/file.d o/file.d
> >
> Thanks Camm!
> 
> The diff command suggests that this code is already in GCL 2.6.6.
> Is that correct?
> 
> Should I expect the code below to work "out of the box" with the
> Windows version of GCL 2.6.6?
> 

The small patch needs to be applied (to o/file.d) and saved_gcl
recompiled.  If this is an obstacle, please let me know.  I could
provide a loadable accept if needed.


> >> (defun foo (s)
> >  (let* ((get (read s nil 'eof)) 	 (fn (and (eq get 'get)
> > (string-downcase (read s nil 'eof))))
> >	 (fn (when (probe-file fn) fn)))
> >    (format s "HTTP/1.1 ~S~%~%" (if fn 404 500))
> >    (when fn
> >      (if (pathname-name (pathname fn))
> >	  (with-open-file (q fn) (si::copy-stream q s))
> >	(dolist (l (directory fn)) (format s "~a~%" (namestring l)))))
> >    (close s)))
> >
> >
> >> (defun bar (p fn)
> >  (let ((s (si::socket p :server fn)))        (tagbody l
> > (when (si::listen s)                        (let ((w (si::accept
> > s)))                                (foo w)))                (sleep
> > 3)                (go l))))
> >
> >
> >>(bar 8080 #'foo)
> >>
> >=============================================================================
> >
> >Then point your browser to localhost:8080.  You should be able to get
> >directory listings and files.  There is obviously no protocol nor
> >error implementation here, but that should be straightforward for the
> >web gurus.
> >
> >
> Great, that is exactly what I was looking for.
> 
> >This will accept multiple simultaneous connections and process them
> >one at a time.  The delay mechanism can obviously be adjusted.  Each
> >connection is stateless -- a multiplexing solution for persistent
> >connections can be implemented in like manner.  Also, all connections
> >are in the same process.  It is trivial to fork() in linux for each
> >connection, but don't know how this would be done on Windows.
> >Speaking of which, does MS have select?  There are other hooks for
> >allowing work in the image while connections are handled in the
> >background, e.g. SIGIO, but don't know the portable nor most desirable
> >way of doing this.
> >
> >Anything can be done here that one wishes -- my question is, what is
> >the advantage vis a vis an external server like apache?  Presumably,
> >axiom could spit out results directly instead of being called in a
> >cgi, which is of some value.
> >
> Yes! It is a very significant value if one were to try to implement Axiom's
> HyperTex browser in a "real browser" as per my previous email and
> discussed by Mike Dewar and Tim Daly.
> 

This obviously has advantages in portability and features -- nice
suggestion!  The memory footprint might be quite high, but one
doesn't have to use the browser, I suppose.  And I hope we don't have
to get into issues of conflicting browser capabilities, etc.   I
suppose it is important that the help browser offer dynamic content,
as it does currently.  Otherwise, with static examples, one could just
launch a separate browser process pointed at an html documentation
tree.  For dynamic content, your idea above is the way to go.

We will have to address the following at some point should we go down
this road:

1) axiom hyperdoc forks on each connection -- this leaves the
   controlling terminal free to pursue other work, but any changes
   therein after the browser was launched would be invisible to the
   borwser process.  Might need to watch the number of connections
   here. 

2) The axiom read loop spends a fraction of its time polling for
   activity on the hyperdoc channel, and processes it immediately and
   serially when present.

3) The user locks the controlling terminal with the browser server
   function, which is terminated when the browser is shut down.

Also we have the issues of

4) persistent connections, or we write an involved state machine with
   cookies, etc. 

5) connecting the hyperdoc documentation to the pamphlet files in a
   seemless fashion -- would be wonderful to be able to inline the
   examples here.

And I thought I'd mention

6)  I have code which implements an SSL encryption over-layer should
    we ever need this, though I can't imagine why we would.


> >  Anyway, more discussion on where and why
> >this should go if anywhere would be great!
> >
> My short term objective is to have a simple way to "prove" the
> portability of socket connections in GCL, specifically HTTP
> access, between Linux and Windows.
> 

Then I think we need either you or Mike Thomas to test this little
example.  There may be unresolved socket issues on Windows remaining,
though we have sucessfully tested little netcat examples earlier as
posted to gcl-devel.  Please let me know of any difficulties.

> My goal is to be in a reasonable position to argue for the following:
> 
> I think that using a browser to implement the Axiom gui would be
> an excellent way to solve the problem of porting Axiom HyperTex
> and Graphics. It seems an extreme waste of scarce resources to
> spend time on re-implementing something based on a model that
> is now more than 10 years old - that's ancient given the rate at
> which this technology is developing. A browser interface would
> also be automatically compatible with the web and easily integrated
> into web server applications like MathAction.
> 
> I have played with HyperTex as now implemented in the most
> recent release of open source Axiom and frankly in comparison
> to modern browser interfaces, it looks primitive and awkward.
> Except for it's ability to simply navigate Axiom's algebra library,
> I doubt that it can have much appeal to current computer users.
> 
> NAG did a lot of work on Axiom to make it compatible with
> Techexplorer on Windows and to replace the old (even then!)
> HyperTex browser with something newer and more powerful.
> This included adding special code to Axiom to navigate the
> Axiom library that was intended to work with a "real browser".
> (Techexplorer was essentially IBM's first entry as a mathematics
> capable web browser. It is still available in another commercial
> incarnation but unfortunately not as part of open source Axiom.)
> 
> NAG also apparently did a lot of work on porting Axiom graphics
> to OpenInventor. OpenInventor lead to VRML and is now known
> as X3D. Since OpenInventor is now open source, I think we are in
> an excellent position to take advantage of this work. VRML is also
> well adapted to integration with web applications.
> 
> The down side is that as far as I know very little documentation is
> available for the work that was done by NAG. I am also not certain
> exactly how much of this code was in the source package that was
> originally delivered to Tim Daly from NAG. My hope is that someone
> like Mike Dewar would be willing to work with us develop the
> necessary documentation so that we could adapt that work to
> currently available open source software.
> 
> The benefits of open source and free aside, if Axiom must compete
> with commercial products like Mathematica and Maple for a share
> of the academic symbolic computer market, then I think we must
> aim a little higher than simply providing Axiom as it existed 10 years
> ago. And aside from it's superiority in supporting research in new
> mathematical algorithms, there are other features of Axiom (especially
> Axiom's graphics) that potentially place it still somewhat ahead of
> what is available in the commercial M&M's. I think the sooner we
> can make these features available in the open source version of
> Axiom, the better chance we will have of attracting some serious
> interest.
> 

All extremely well taken!  

Two thoughts:

1)  There are so many ??ML variants that appear to come and go in a
    quasi-faddish manner, at least to an outsider like me.  Would be
    great if we can stick to something simple, universal, and eternal
    :-).  

2)  I'm wondering if a browser interface like this might also be able
    to provide some kind of integrated 'inlined-notebook' that at
    least the old mathematica versions had.  Math, text, TeX, and
    graphics all inlined in the sequence in which one works.  Like
    texmacs, I suppose, or imaxima for maxima using my favorite
    program -- emacs :-).  Can we centralize on one interface?  Would
    this be advisable?

\start
Date: 28 Apr 2005 18:18:03 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: axiom porting
Cc: Mike Thomas, Bill Page, Tim Daly Jr

Hi Tim!

Tim Daly writes:

> Lots of discussion and interest on this subject I see...
> 
> My current thinking on the matter is that the first priority will
> be to just get it working the way it was. This has several dimensions.
> 

I think this is great!

> The code is now in C/X11, neither of which is very portable. C has
> more ifdefs than code and X11 won't work on windows. 
> 
> The cygwin path could potentially allow a direct port but is not of
> interest for other reasons. I've tried cygwin before as the initial
> porting platform and it was painful. Plus, having both cygwin and msys
> would be a bit much. So this rules out the X11-on-windows version.
> 
> Which implies a rewrite to use a different code base and a
> different windowing scheme.
> 

But here we're doing something new upfront, no?  Would a small initial
stage project of rewriting the xlib calls to MS equivalents in the
hypertex C code give us a little more time to evaluate different lisp
options?  After all, this only need be done on one port, Windows.

> With respect to a code rewrite I've decided to rebuild the code in
> common lisp for several reasons. First, it is easier to port. Second,
> it is a language I know well. Third, it will allow us to "lift" the
> windowing functions up into the axiom system proper so other people
> can create windows in their code. Fourth, it will allow the unification
> of windowing/graphing data structures and spad data structures.
> 

This is a terrific goal.  Might take some time, but as you say -- we
have thirty years!  

> With respect to the windowing scheme we are confronted with a large
> variety of front-end mechanisms. In any of the proposed mechanisms
> we need a working example of, for instance, the first page of the
> hyperdoc browser. That will ground the proposals in reality. For example,
> http://daly.axiom-developer.org/TimothyDaly_files/pamphlets/jman.pamphlet
> 

Are you primarily aiming at the graphics, or the hypertex, or both?
What do you think of Bill Page's idea using a system browser for the
latter, as I assume it could not handle the former?

> The current plan is to have some sort of dumb front-end that implements
> some low-level graphics API and move the rest of the code into lisp.
> The graphics API needs to cover both the browser and graphics abilities.
> 
> As I've mentioned I've tried various paths. Camm, Bill, and I had a 
> discussion about these during the sprint day. Camm pointed me at the
> sources for TK. I've already written a piece of a TK replacement in Java.
> 
> TK might work. I'm going to the bookstore today to get educated about
> the details. Since both TK and my Java code use sockets it would seem
> that we could use a common syntax. Such an approach would make it easy
> to shift between the two front ends. I'm not sure how feasible this is.
> 

Well, run-process will talk to any external windowing program.  The
trick is in abstracting all the options to one lisp api, and this
would appear hopeless.  My opinion is that we need to choose one that
will last us at least ten of the next thiry years, and make it work
well.  

Let me just briefly bring up the issue of performance, which is likely
of little concern to us.  Talking down a pipe to an external program
will never be as fast as making the windowing calls directly from the
image, which is also possible.  Unless we're contemplating animation,
I don't think we'll ever see the difference.

> I've looked at GNUPLOT but their license does not seem to allow me to
> modify and distribute. And their code has more ifdefs than C code which
> is a sure sign of a porting headache.
> 

gnuplot is completely free software -- it passes the widely accepted
definitions found in the Debian Free Software Guidelines, and is thus
in Debian's main (not non-free or contrib) archive.  You can
distribute any modifications you wish in the form of patches.

As to portability, this is perhaps the most widely portable option at
the present moment.  It might not have been an easy job, but someone
else already has done it, and is continuing to do so, which appears to
me highly attractive from axiom's vantage point.

> I've looked at McClim which is a path I'd dearly love to take but so
> far I've not gotten it to work. If someone could reproduce the first
> page of the browser (a few buttons, an image) in McClim that might be
> enough to get me over the hurdle. A pure lisp solution is preferred.
> 
> The graphics and browser run in separate threads using sockets to
> communicate to the algebra. Due to the run-process issue in GCL the
> front end is being done using CLISP but nothing in the code cares
> which lisp is used.
> 

Did you get my fix for this posted yesterday?


> I've spoken to Tim Daly Jr. about the lisp-gtk work and he believes
> it is not ready for production use.
> 

Perhaps, but all the solutions will require work, alas, and what one
gets with gtk is glade.  Please take a moment and play with the
program.  The entire interface is generated graphically, with no
coding in any language, and dumped as a purely portable xml file.
There is cl-glade which loads this interface into acl.  I've
downloaded it, and it can be made to work in GCL, but I'll refrain
from spending time here unless we are sure this is the way we'd like
to go. 

> The SVG, VRML, CSG, and Flash enhancements would be nice but are
> definitely in the future development categories. There is still a
> huge amount of algebra work to be done before any work gets applied
> to enhancing the graphics.
> 

Agreed!

> Of course, it's all open to discussion.
> 

Thank you so much for your work here and everywhere, Tim!

\start
Date: Fri, 29 Apr 2005 08:31:17 +1000
From: Mike Thomas
To: Camm Maguire
Subject: RE: [Gcl-devel] Possible GCL 2.6.7 for axiom

Hi Camm.

| > | 1) reenable run-process

I checked into HEAD yesterday a fix which works with the test snippet you
provided in a separate email to Tim.  I note that the interface (on Unix
also I believe) is not robust in the sense that it doesn't check the type or
number of arguments to the function, but otherwise it looks fine.


| >   5) Something has recently broken the path handling on Windows
| so the CVS
| > HEAD GCL build lisp compilation fails.
| >
|
| OK, more detail here would be helpful, but this is not relevant to
| 2.6.x for axiom, no?

No, but for the record it's caused by the following change:

http://savannah.gnu.org/cgi-bin/viewcvs/gcl/gcl/pcl/defsys.lisp.diff?r1=1.4&
r2=1.5

the purpose of which escapes me.  The problem is that on Windows the name of
the file being passed to COMPILE-FILE in "pcl/defsys.lisp" is incomplete
when that new version of the file is used.

Reversing that change then leads to a further problem which I have yet to
investigate.

\start
Date: 28 Apr 2005 18:20:46 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: axiom porting
Cc: Mike Thomas, Bill Page, Tim Daly Jr

Greetings!

Tim Daly writes:

> > > With respect to the windowing scheme we are confronted with a large
> > > variety of front-end mechanisms. In any of the proposed mechanisms
> > > we need a working example of, for instance, the first page of the
> > > hyperdoc browser. That will ground the proposals in reality. 
> > 
> > Tim, by working you mean something that communitcates with Axiom?
> 
> Nope. Just something that communicates with lisp as a back end and
> some drawing front end. 
>  
> > > I've looked at McClim which is a path I'd dearly love to take but so
> > > far I've not gotten it to work. If someone could reproduce the first
> > > page of the browser (a few buttons, an image) in McClim that might be
> > > enough to get me over the hurdle. A pure lisp solution is preferred.
> > 
> > Well, since I'm the McCLIM advocate I'll see what I can come up with.
> > (Gulp.) You might ask the McCLIM developer list about specific
> > problems/issues - they tend to be very helpful.
> 

If anyone pursues this, please let me know of any issues on GCL and
I'll make them go away :-).  clx, on which mcclim rests, worked on gcl
out of the box last time I checked, but no one is using it at
present. 

\start
Date: Fri, 29 Apr 2005 08:53:40 +1000
From: Mike Thomas
To: Camm Maguire, Tim Daly
Subject: RE: [Gcl-devel] Re: axiom porting
Cc: Bill Page, Tim Daly Jr

Hi all.

| > The graphics and browser run in separate threads using sockets to
| > communicate to the algebra. Due to the run-process issue in GCL the
| > front end is being done using CLISP but nothing in the code cares
| > which lisp is used.
| >
|
| Did you get my fix for this posted yesterday?

In case my other email is swamped by the volume on this family of issues,
note also that a fix for Windows is now in GCL CVS HEAD.

| > I've spoken to Tim Daly Jr. about the lisp-gtk work and he believes
| > it is not ready for production use.
| >
|
| Perhaps, but all the solutions will require work, alas, and what one
| gets with gtk is glade.  Please take a moment and play with the
| program.  The entire interface is generated graphically, with no
| coding in any language, and dumped as a purely portable xml file.

That is actually very interesting.  Note however that GTK on Windows is  not
as stable as it is on Unix.

\start
Date: 28 Apr 2005 19:09:35 -0400
From: Camm Maguire
To: Mike Thomas
Subject: Re: [Gcl-devel] Possible GCL 2.6.7 for axiom

Greetings!

Mike Thomas writes:

> Hi Camm.
> 
> | > | 1) reenable run-process
> 
> I checked into HEAD yesterday a fix which works with the test snippet you
> provided in a separate email to Tim.  I note that the interface (on Unix
> also I believe) is not robust in the sense that it doesn't check the type or
> number of arguments to the function, but otherwise it looks fine.
> 

Thanks!  Had forgotten there was so much difference with mingw here,
but at least this appears to imply that there is some windows version
of fork() :-).  At some point, perhaps we can boil the ifdefs down to
a minimal set of primitives.

> 
> | >   5) Something has recently broken the path handling on Windows
> | so the CVS
> | > HEAD GCL build lisp compilation fails.
> | >
> |
> | OK, more detail here would be helpful, but this is not relevant to
> | 2.6.x for axiom, no?
> 
> No, but for the record it's caused by the following change:
> 
> http://savannah.gnu.org/cgi-bin/viewcvs/gcl/gcl/pcl/defsys.lisp.diff?r1=1.4&
> r2=1.5

OK, this was along the path of supporting unique init function names
for our profiling users.  When gprof is enabled, the patch (yet
committed in entirety) will place the full filename in the C init
function name, so that ld will not complain of duplication.  This
obviously poses a challenge for the likes of unixport/sys_foo.c in
attempting to find the init function name, so I was trying to
centralize all GCL supplied system files with a pathname-directory of
nil passed to compile file.  This boils down to the current directory
on Linux, but I guess not on Windows.  Can you see why not?  Is there
anyway to make this behavior identical?

> 
> the purpose of which escapes me.  The problem is that on Windows the name of
> the file being passed to COMPILE-FILE in "pcl/defsys.lisp" is incomplete
> when that new version of the file is used.
> 
> Reversing that change then leads to a further problem which I have yet to
> investigate.

Thanks as always for your tremendous contributions!

\start
Date: Thu, 28 Apr 2005 18:17:08 -0500
From: Tim Daly
To: Mike Thomas, Camm Maguire, Cliff Yapp, Bill Page
Subject: axiom porting

I'm a bit overwhelmed by the volume of suggestions.

The browser idea has promise except that I don't see how to handle
the graphics. I also don't see how to "command" a browser
through a socket to do things like open a new tab. 

But it does give us the advantage of an already portable front
end. The dynamic content doesn't seem to be much of an issue.
There is an asq command that can compute answers to database queries.
And if Axiom could handle server requests it would be easy to
serve up algebra (might even be a reason to send Bill to China).

I've been clinging to reproducing the prior work as it gives me a
fixed target to achieve. Otherwise it becomes an open-ended design
problem and it will never be finished. Perhaps this is misguided.

I actually have no idea what gtk is despite the fact that my son was
involved in developing it. And I'm not sure what glade is.

I did try to "rewrite the xlib calls to MS equivalents" but the model
for graphics is wildly different. I suppose this is why no one has 
taken this path.

I did get the run-process patch you sent but have not yet applied it.
I'm still working on merging the BSD patches which have been hanging-fire
behind the axiom conference work. Hopefully I'll complete that tonight.

Then I need to look at the GUESS domain and see what it will take to
merge that.

THEN I'll look at the G/B (graphics/browser) issue. Since I'm not
actively coding this is a good time to debate the issue.

\start
Date: 28 Apr 2005 19:12:03 -0400
From: Camm Maguire
To: Mike Thomas
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Bill Page, Tim Daly Jr

Greetings!

Mike Thomas writes:

> Hi all.
> 
> | > The graphics and browser run in separate threads using sockets to
> | > communicate to the algebra. Due to the run-process issue in GCL the
> | > front end is being done using CLISP but nothing in the code cares
> | > which lisp is used.
> | >
> |
> | Did you get my fix for this posted yesterday?
> 
> In case my other email is swamped by the volume on this family of issues,
> note also that a fix for Windows is now in GCL CVS HEAD.
> 
> | > I've spoken to Tim Daly Jr. about the lisp-gtk work and he believes
> | > it is not ready for production use.
> | >
> |
> | Perhaps, but all the solutions will require work, alas, and what one
> | gets with gtk is glade.  Please take a moment and play with the
> | program.  The entire interface is generated graphically, with no
> | coding in any language, and dumped as a purely portable xml file.
> 
> That is actually very interesting.  Note however that GTK on Windows is  not
> as stable as it is on Unix.
> 

OK, but how bad is bad?  And how temporary might this be?  Anyway to
try a quick glade example on Windows to get a 30min idea of where the
issues are?

\start
Date: Fri, 29 Apr 2005 09:37:57 +1000
From: Mike Thomas
To: Camm Maguire, Bill Page
Subject: re: [Gcl-devel] Simple web server code for	GCLfor Windows

Hi Camm/Bill

Camm wrote:

| Greetings!  Here's a quick way to get started:
|
| ==================================================================
| ===========
| camm@intech19:/fix/t1/camm/debian/gcl/gcl-2.6.6$ diff -u
| ../gcl-2.6.5/o/file.d o/file.d
| --- ../gcl-2.6.5/o/file.d	2004-05-07 21:48:58.000000000 +0000
| +++ o/file.d	2005-04-28 16:21:33.000000000 +0000

...
blah blah...
...

|
| >(bar 8080 #'foo)
| ==================================================================
| ===========
|
| Then point your browser to localhost:8080.  You should be able to get
| directory listings and files.

I modified the test program to print stuff out and using port 8085 to get
around IIS I was able to get a web page back with the following text:

  /TMP /win32app /WINDOWS

from the following input into my browser:

  http://localhost:8085/dir

So it looks like your patch works on Windows Camm to a first approximation -
you truly are a wunderkind Camm!


|  It is trivial to fork() in linux for each
| connection, but don't know how this would be done on Windows.

Threads.

| Speaking of which, does MS have select?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win
sock/select_2.asp

but you should be warned that Windows socket functions are often different
to the original Berkeley APIs and select is not able to handle the range of
fd types used in Unix.

|  There are other hooks for
| allowing work in the image while connections are handled in the
| background, e.g. SIGIO, but don't know the portable nor most desirable
| way of doing this.

Signals are a mistake for portability to Windows.

\start
Date: Fri, 29 Apr 2005 10:20:19 +1000
From: Mike Thomas
To: Camm Maguire
Subject: RE: [Gcl-devel] Possible GCL 2.6.7 for axiom

Hi Camm.

| Thanks!  Had forgotten there was so much difference with mingw here,
| but at least this appears to imply that there is some windows version
| of fork() :-).

Not mingw, rather Windows.  Also definitely not fork() per se - just the
ability to spawn a separate process with stdio redirected via CreateProcess
() per the Unix fork()/exec() idiom.

|  At some point, perhaps we can boil the ifdefs down to
| a minimal set of primitives.

There certainly is some room for that yet to be done quite trivially.

\start
Date: Fri, 29 Apr 2005 11:49:16 +1000
From: Mike Thomas
To: Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: list, Bill Page, Tim Daly Jr

Hi Camm.

| > That is actually very interesting.  Note however that GTK on
| Windows is  not
| > as stable as it is on Unix.
| >
|
| OK, but how bad is bad?

Here are some examples.

Apart from the slowness of launching GIMP (by far the slowest to launch on
my system) as the vast quantity of Unix emulation dlls and other GTK
machinery loads, common items such as the file selectors are completely
foreign to Windows users and considerably less usable than their Windows
equivalents.  Occasionally one ends up with menus which somehow become
detached from the parent program and which can't be closed and which
simultaneously lock the parent so that the program has to be killed through
the process manager - perhaps fixed now, I am certainly out of date, but
then again, what a hassle to continually update and harmonise stuff I don't
want to know about.


|  And how temporary might this be?

Who would know?  Probably a long time.  The only major GTK applications I'm
aware of on Windows are Glade and the GIMP which means that a large segment
of GTK is presumably largely untested on Windows.

Here is a link:

  http://www.gimp.org/~tml/gimp/win32/

Added to this is the issue of potential clashes between various application
builds and the currently installed version of GTK, which is the reason

|  Anyway to
| try a quick glade example on Windows to get a 30min idea of where the
| issues are?

Not at the moment as I suspect it will clash with my version of GTK and
GIMP!  Perhaps over the weekend.  Hopefully you can see roughly where it's
at from the comments above.

Although Glade definitely sounds like a very big plus, it also seems there
is a lot more work involved with GTK than just getting GCL/Tk up on Windows
both for developers and end users.

\start
Date: Fri, 29 Apr 2005 11:57:54 +1000
From: Mike Thomas
To: Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Bill Page, Tim Daly Jr

Hi again.

A quick postscript:

|  Anyway to
| try a quick glade example on Windows to get a 30min idea of where the
| issues are?

Couldn't help myself - installed Glade and sure enough there was a GTK
version clash (missing entry points in the relevant DLLs), so this will have
to wait I'm sorry.

\start
Date: Thu, 28 Apr 2005 21:06:38 -0500
From: Tim Daly
To: Mark Murray, Camm Maguire
Subject: axiom freebsd changes

Mark, Camm,

There is a similar failure in the interp build. 
That change has also been backed out.

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

I completed the merge of axiom--main--1 and axiom--BSD--1.

The build fails using the new loading scheme (in particular the
change to CMD0 in src/boot/Makefile.pamphlet). Each generated .o
file, when loaded, gives the following failure:

/home/axiom--main--1--patch-33/obj/linux/boot/tyextra.o(.text+0xab4): In function `init_code':
:multiple definition of `init_code'
/home/axiom--main--1--patch-33/obj/linux/boot/boothdr.o(.text+0x0): first defined here

I've backed out this change.

\start
Date: Thu, 28 Apr 2005 21:00:08 -0500
From: Tim Daly
To: Mark Murray, Camm Maguire
Subject: axiom freebsd changes

Mark, Camm,

I completed the merge of axiom--main--1 and axiom--BSD--1.

The build fails using the new loading scheme (in particular the
change to CMD0 in src/boot/Makefile.pamphlet). Each generated .o
file, when loaded, gives the following failure:

/home/axiom--main--1--patch-33/obj/linux/boot/tyextra.o(.text+0xab4): In function `init_code':
:multiple definition of `init_code'
/home/axiom--main--1--patch-33/obj/linux/boot/boothdr.o(.text+0x0): first defined here

I've backed out this change.

\start
Date: 28 Apr 2005 22:36:34 -0400
From: Camm Maguire
To: Mike Thomas
Subject: re: [Gcl-devel] Simple web server code for GCLfor Windows

Greetings!

Mike Thomas writes:

> Hi Camm/Bill
> 
> Camm wrote:
> 
> | Greetings!  Here's a quick way to get started:
> |
> | ==================================================================
> | ===========
> | camm@intech19:/fix/t1/camm/debian/gcl/gcl-2.6.6$ diff -u
> | ../gcl-2.6.5/o/file.d o/file.d
> | --- ../gcl-2.6.5/o/file.d	2004-05-07 21:48:58.000000000 +0000
> | +++ o/file.d	2005-04-28 16:21:33.000000000 +0000
> 
> ...
> blah blah...
> ...
> 
> |
> | >(bar 8080 #'foo)
> | ==================================================================
> | ===========
> |
> | Then point your browser to localhost:8080.  You should be able to get
> | directory listings and files.
> 
> I modified the test program to print stuff out and using port 8085 to get
> around IIS I was able to get a web page back with the following text:
> 
>   /TMP /win32app /WINDOWS
> 
> from the following input into my browser:
> 
>   http://localhost:8085/dir
> 
> So it looks like your patch works on Windows Camm to a first approximation -
> you truly are a wunderkind Camm!
> 

Great!, but hardly...

> 
> |  It is trivial to fork() in linux for each
> | connection, but don't know how this would be done on Windows.
> 
> Threads.

OK, now I'm confused.  threads need reentrancy, no?  None of our code
has been checked in this regard, and there are known issues with
things like gc.  Yet our mingw port can both run gcc and do
run-process, both of which exist atop fork() on unix.  Are these using
some type of threading?  Or rather is a completely unrelated process
with an entirely distinct memory image started?  fork() on unix these
days uses copy on write pages, making it fairly lightweight.  Am I
right in assuming that if we did server sockets with the idea of a
separate process handling each connection, that we would have to start
an entirely new gcl on windows to do such (i.e. inheriting no work
done previously in the session), at least at the moment?   Would this
effectively double the virtual memory consumption?

> 
> | Speaking of which, does MS have select?
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win
> sock/select_2.asp
> 
> but you should be warned that Windows socket functions are often different
> to the original Berkeley APIs and select is not able to handle the range of
> fd types used in Unix.

Thanks!  My peanut sized brain parses this as 'it should work, but it
might not' :-).


> 
> |  There are other hooks for
> | allowing work in the image while connections are handled in the
> | background, e.g. SIGIO, but don't know the portable nor most desirable
> | way of doing this.
> 
> Signals are a mistake for portability to Windows.
> 

OK.  This still leaves us with the three broad options for server
sockets: multitasking, file descriptor/standard input multiplexing, or
user server invocation.

The existing hooks in the original code stores the server function in
the socket stream itself.  This makes natural the idea that once one
does (si::socket p :server #'foo), the connection handling, or the
accepting, or both should be registered and handled automatically.  It
would be nice to get a feel for how people would like this to work.

\start
Date: Thu, 28 Apr 2005 21:53:36 -0500
From: MathAction (loli)
To: MathAction
Subject: [#150 To create a function from an expresion] property change

\start
Date: Thu, 28 Apr 2005 20:08:06 -0700 (PDT)
From: Cliff Yapp
To: Mike Thomas, Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Bill Page, Tim Daly Jr

--- Mike Thomas wrote:

[snip]

> common items such as the file selectors are completely
> foreign to Windows users and considerably less usable than their
> Windows equivalents.

Amen.  KDE users on Linux have been making fun of GTK's file selection
for a very long time - it's improving in the most recent versions but I
still find it a tad iffy at times.

> The only major GTK applications I'm aware of on Windows are Glade 
> and the GIMP which means that a large segment of GTK is presumably 
> largely untested on Windows.

This is my sense too - I know a few other GTK applications have been
ported but I do not have the sense it is a major movement.  Hence my
excitement at GPL QT4, which up until version 4 was commercial ONLY on
Windows - indicating it must work reasonably well.  With any luck an
McCLIM backend to that could be made to work well and reliably on both
platforms.

\start
Date: Fri, 29 Apr 2005 14:00:02 +1000
From: Mike Thomas
To: Cliff Yapp, Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Bill Page, Tim Daly Jr

Actually, I just gave in to temptation again and installed the latest
Windows GDK; Glade is a bit of a mess.  Background windows pop up when the
mouse moves in other windows, menus are left hanging etc. My suspicion is
that this is caused by trying to map the GTK signal structure onto the
Windows event loop system.

| Amen.  KDE users on Linux have been making fun of GTK's file selection
| for a very long time - it's improving in the most recent versions but I
| still find it a tad iffy at times.

Even on Linux running on a really fast box X always feels slow to me after
Windows.

| > The only major GTK applications I'm aware of on Windows are Glade
| > and the GIMP which means that a large segment of GTK is presumably
| > largely untested on Windows.
|
| This is my sense too - I know a few other GTK applications have been
| ported but I do not have the sense it is a major movement.  Hence my
| excitement at GPL QT4, which up until version 4 was commercial ONLY on
| Windows - indicating it must work reasonably well.  With any luck an
| McCLIM backend to that could be made to work well and reliably on both
| platforms.

If someone was planning (I'm certainly not) to write a cross platform
backend to McClim I personally would be telling them to use WxWidgets, which
has been connected up very nicely in both the Scheme and Haskell worlds and
is much lighter weight than GTK while retaining good cros-platform
performance and appearance.

\start
Date: Fri, 29 Apr 2005 13:52:22 +1000
From: Mike Thomas
To: Camm Maguire
Subject: re: [Gcl-devel] Simple web server code for	GCLfor Windows

Hi Camm.

| > |  It is trivial to fork() in linux for each
| > | connection, but don't know how this would be done on Windows.
| >
| > Threads.
|
| OK, now I'm confused.

Sorry.

|  threads need reentrancy, no?

Yes.

|  None of our code
| has been checked in this regard, and there are known issues with
| things like gc.

Yes.

|  Yet our mingw port can both run gcc and do
| run-process, both of which exist atop fork() on unix.

On Windows the concept of cloning an already running process down to the
program counter ie fork() does not exist.

|  Are these using
| some type of threading?  Or rather is a completely unrelated process
| with an entirely distinct memory image started?

Yes, that is what CreateProcess() does:

  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/b
ase/createprocess.asp

|  fork() on unix these
| days uses copy on write pages, making it fairly lightweight.  Am I
| right in assuming that if we did server sockets with the idea of a
| separate process handling each connection, that we would have to start
| an entirely new gcl on windows to do such (i.e. inheriting no work
| done previously in the session), at least at the moment?   Would this
| effectively double the virtual memory consumption?

Yes.  Threads are the usual process related method of avoiding such wastage.
I suppose that the trade off is between running multiple threads in the same
address space (ie a threat to one thread is a threat to the entire process)
versus frigging around in the interprocess communication jungle and having
hung/broken pipes etc.

| Thanks!  My peanut sized brain parses this as 'it should work, but it
| might not' :-).

I think that's a good way of looking at it.  I've never used select()
myself.  That function, like all of the others in the Microsoft Visual C
Runtime, including standards like "fopen()", is built on top of far more
sophisticated functions in the real Windows system APIs - ie, the ones you
get through <windows.h>.

So select() is based on WaitForMultipleObjects() and fopen() on CreateFile()
and there are really no such things as either file descriptors or FILE *.
They are, rather, an illusion built on the true workhorse of the Windows OS,
namely, HANDLE's.

In short, the entire Microsoft Visual C++ runtime was designed as a sop for
Unix C programmers and, in fact, a well designed Windows program does not
bother with any of those artifacts whatsoever.

| OK.  This still leaves us with the three broad options for server
| sockets: multitasking, file descriptor/standard input multiplexing, or
| user server invocation.

| The existing hooks in the original code stores the server function in
| the socket stream itself.  This makes natural the idea that once one
| does (si::socket p :server #'foo), the connection handling, or the
| accepting, or both should be registered and handled automatically.  It
| would be nice to get a feel for how people would like this to work.

This is definitely out of my realm of expertise so I'll trust you to work
that out.

\start
Date: 29 Apr 2005 10:52:50 -0400
From: Camm Maguire
To: Mike Thomas
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Bill Page, Tim Daly Jr

Greetings!

Mike Thomas writes:

> Actually, I just gave in to temptation again and installed the latest
> Windows GDK; Glade is a bit of a mess.  Background windows pop up when the
> mouse moves in other windows, menus are left hanging etc. My suspicion is
> that this is caused by trying to map the GTK signal structure onto the
> Windows event loop system.
> 

OK, so glade on windows is only part there, I take it.  What is really
central is whether libglade can open up a glade-output xml interface
on windows, which might be somewhat less onerous.

Did a little searching for the opinions of others.  Thought this ruby
user's summary was perhaps most relevant for us:

http://www.wonko.com/content.php?id=301

wxwidgets has the native 'look and feel', but glade is 'By far the
easiest to use'...  To me, we are far from being able to design high
quality gui's, let alone contribute to the cross-platform gui
development model.  All we can hope for is passable, serviceable, and
cross-platform, I'd think.  With these resources, ease of use appears
paramount. 

There is also wxglade, but this appears in its infancy, and it is
unclear if there is xml/libglade support:

http://wxglade.sourceforge.net/

Needess to say, if it proves to be as functional as glade, this is
definitely the way to go, at least in the long term.  Don't have time
to investigate right now, alas. 


> | Amen.  KDE users on Linux have been making fun of GTK's file selection
> | for a very long time - it's improving in the most recent versions but I
> | still find it a tad iffy at times.
> 
> Even on Linux running on a really fast box X always feels slow to me after
> Windows.
> 

Fair enough, but in the absense of some well-polished, very easy to
use, open source, massively exercised, cross-platform alternative,
this would appear the least of our concerns at this juncture. 

Whatever we choose will be less than desirable -- what we need is to
select wisely given a carefully chosen set of priorities.  

> | > The only major GTK applications I'm aware of on Windows are Glade
> | > and the GIMP which means that a large segment of GTK is presumably
> | > largely untested on Windows.
> |
> | This is my sense too - I know a few other GTK applications have been
> | ported but I do not have the sense it is a major movement.  Hence my
> | excitement at GPL QT4, which up until version 4 was commercial ONLY on
> | Windows - indicating it must work reasonably well.  With any luck an
> | McCLIM backend to that could be made to work well and reliably on both
> | platforms.
> 
> If someone was planning (I'm certainly not) to write a cross platform
> backend to McClim I personally would be telling them to use WxWidgets, which
> has been connected up very nicely in both the Scheme and Haskell worlds and
> is much lighter weight than GTK while retaining good cros-platform
> performance and appearance.
> 

The scheme hooks you mention argue strongly in wxwidgets' favor, of
course.

Here are my summary opinions at this point -- feedback most
appreciated!  (Just a note of clarification -- tcl/tk, which exists in
GCL now and is a portable scripting language, is *not the same* as
GTK+, an extremely widely used C library with multi-language bindings
running 'in-process')

=============================================================================
Goal: generic GCL gui  -- short term
=============================================================================

1) get the somewhat clunky but serviceable gcl-tk (i.e. tcl/tk)
   working on all platforms as quickly as possible (Need feedback from
   Mike and/or Bill)

2) make sure gcl-tk can display bitmaps (I'll take care of this)

=============================================================================
Goal: generic GCL gui  -- long term
=============================================================================

   Choose an in-process gui option according to the following ranked
   priorities:

        1) open source

        2) massively exercised in the open source world, which for all
           intents and purposes means the core C libraries used by the
           open source desktops with a thin lisp binding option

        3) universally portable

        4) easy to use, preferrably with a graphical gui builder.

        5) native 'look and feel'

        6) supports the option of a higher level lisp layer like
           mcclim.  This to my understanding can just be layered on
           top of a thin lisp binding layer. 

        7) lgpl better than gpl.  Just to be clear here, if qt4 is
           selected, all apps using this will be GPL when distributed
           in binary form -- Mike Thomas has voiced reservations about
           this in the past, but it doesn't particularly bother me.

    We should not do any work on this, IMHO, unless we have a
    confirmed user of such a system.  As I state below, axiom and the
    other systems currently using gcl might be more easily serviced in
    other ways.  

    My feeling is that depending on wxglade functionality, this would
    result in wxwidgets > gtk+ > qt4

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

Goal: portable axiom hypertex

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

This would appear best served by Bill Page's browser idea with GCL
server sockets.  For now, I will work on providing
fork()/CreateProcess() options, and select/stdio multiplexing options,
to the si::socket function call.  We will postpone threads unless
someone wants to volunteer some work here.  The windows fork() analog
of CreateProcess() will require some work in this context, as
basically the code will have to save the server function in a .lsp or
.o file, and restart gcl or axiom with a command line instruction to
load and execute the file (or do same with pipes).  I suggest we don't
bother working on this again unless we have a confirmed user -- axiom
might be serviced by the user invocation and/or stdio multiplexing
options.  But fork() is a great option to have on Linux, so we should
put it in, IMHO.

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

Goal: portable axiom graphics

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

This is unlikely to be well serviced by a web browser, and only
modestly well-serviced by a standard gui, as axiom's demands on plot
manipulation are likely to require such detail as canned 'widgets' are
unlikely to be available.  I really feel gnuplot is the best tool here
in the medium term, which can be fully accessed cross-platform under
GCL at the present time via run-process.  Please check out the maxima
webpages for soem very pretty pictures (aka dazzling eye candy :-))!

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

These are just my thoughts, of course.  Feedback always most welcome!


\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
