Installation directory
Waldek Hebisch
$PREFIX/lib/axiom to $PREFIX/lib/fricas and the name of installed
binary from $PREFIX/bin/axiom to $PREFIX/bin/fricas.
I think that we should do this change to avoid conflicts with
other Axiom flavours.
--- trunk.bb/Makefile.in 2007-12-17 20:03:43.000000000 +0100
+++ trunk/Makefile.in 2007-12-17 20:07:50.000000000 +0100
@@ -4,7 +4,7 @@
## ----------------------------------------
## CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
-COMMAND=$(DESTDIR)$(libdir)/axiom/target/$(target)/bin/axiom
+COMMAND=$(DESTDIR)$(libdir)/fricas/target/$(target)/bin/axiom
GCLOPTS=@GCLOPTS@
@@ -100,19 +100,19 @@
install:
@echo Installing Axiom in $(prefix)
- rm -rf $(DESTDIR)$(libdir)/axiom
- @mkdir -p $(DESTDIR)$(libdir)/axiom
- @cp -pr $(builddir)/target $(DESTDIR)$(libdir)/axiom
+ rm -rf $(DESTDIR)$(libdir)/fricas
+ mkdir -p $(DESTDIR)$(libdir)/fricas
+ cp -pr $(builddir)/target $(DESTDIR)$(libdir)/fricas
@echo '#!/bin/sh -' > ${COMMAND}
- @echo AXIOM=$(libdir)/axiom/target/$(target) >> ${COMMAND}
+ echo AXIOM=$(libdir)/fricas/target/$(target) >> ${COMMAND}
@echo export AXIOM >> ${COMMAND}
@echo PATH='$${AXIOM}/bin':'$${PATH}' >> ${COMMAND}
@echo export PATH >> ${COMMAND}
@cat $(axiom_src_srcdir)/etc/axiom >> ${COMMAND}
@chmod +x ${COMMAND}
- @rm -f $(DESTDIR)$(bindir)/axiom
+ rm -f $(DESTDIR)$(bindir)/fricas
@mkdir -p $(DESTDIR)$(bindir)
- @ $(INSTALL_PROGRAM) $(COMMAND) $(DESTDIR)$(bindir)/axiom
+ $(INSTALL_PROGRAM) $(COMMAND) $(DESTDIR)$(bindir)/fricas
@echo 79 Axiom installation finished.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Rubey
> The following patch changes installation directory from
> $PREFIX/lib/axiom to $PREFIX/lib/fricas and the name of installed
> binary from $PREFIX/bin/axiom to $PREFIX/bin/fricas.
>
> I think that we should do this change to avoid conflicts with
> other Axiom flavours.
Waldek, I think this is not a very good idea. I think that those who really
want to install several flavours of axiom in parallel, will find a way to do
that.
But for all the others, it just means that incompatibility is increased. For
example, axiom.el would have to be customized for no good reason.
Please do not commit this change.
Martin
Martin Rubey
> It should be possible to have both systems installed, ala CMUCL and SBCL,
> even though they do the same things; if only for the reason that it would
> make it possible to compare results of system changes. Why should the user
> suddenly lose all of their Fricas work (or Axiom work) when they install the
> other system?
But they wouldn't! Why would you think that any of your work was lost when you
install axiom after having installed friCAS? The only difference is, if the
names wouldn't change, they wouldn't need to adjust paths they currently don't
even know about.
> It would be trivial to ship a fricas.el that got installed properly.
> Maintaining a single symbol in a non-algebra file is hardly a reason to
> maintain a collision between the systems.
If it were a single symbol, ok. But it's not. What about the wikimedia plugin
for axiom? What about the TeXmacs interface? Do you really want to maintain
axiom.el, fricas.el, openaxiom.el,
axiom.tm, fricas.tm, openaxiom.tm
axiom.php, fricas.php, openaxiom.php?
> We've been working cooperatively (eg, Waldek has sent Axiom patches, I've
> sent )help files to Fricas) and I expect that to continue.
It seems to me that such a change would rather be a hindrance to cooperation
than making cooperation easier. It's quite the same with IssueTracker.
Really, if this mess stays the same, it will drive me mad. Already I have to
include 3 email lists if I want to say something all axioms should care about,
which is the case most of the time, since I'm working only on the algebra
level. Cooperation in this manner is for me such a nuisance, that I'd rather
stop it.
> As a mathematician I'd expect that you understand that different things
> should have different names.
In fact, as a mathematician, I often use the same symbol for different things,
and let context decide. I do so as an axiom programmer, too. For example,
"eval" can refer to roughly 38 operations, some even having different number of
arguments.
I cannot understand why you want different names for the same thing!
Martin
C Y
--- Martin Rubey <martin...@univie.ac.at> wrote:
> But they wouldn't! Why would you think that any of your work was
> lost when you install axiom after having installed friCAS?
I think the concern here is accidentally overwriting an installation of
Axiom with FriCAS, for example, or having the wrong library used due to
path confusion. In my opinion that concern is valid.
> Really, if this mess stays the same, it will drive me mad. Already I
> have to include 3 email lists if I want to say something all axioms
> should care about, which is the case most of the time, since I'm
> working only on the algebra level. Cooperation in this manner is
> for me such a nuisance, that I'd rather stop it.
Aren't most of the key players on all the lists anyway? Surely it is
reasonable to pick your "favorite" platform and work with that, and
people will track the various lists as they choose?
> I cannot understand why you want different names for the same thing!
If they were the same thing we wouldn't need the forks. I expect the
systems will begin to drift further apart with time, and maintaining
common files for all of them will be increasingly difficult.
Mathematica and Maple are different despite attempting to do the same
job - I expect FriCAS, Axiom and OpenAxiom will all eventually look
different from each other. Aldor, for example - unless Tim has plans
I'm not aware of Axiom itself won't be moving in the direction of using
Aldor. Pursuing branches at the Algebra language level will quickly
lead to very different systems. It looks similar right now because we
are all still close to the origin - personally I doubt this will last
indefinitely. Macsyma is very different from Maxima, for example.
Cheers,
CY
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
Martin Rubey
> I think the concern here is accidentally overwriting an installation of Axiom
> with FriCAS, for example, or having the wrong library used due to path
> confusion. In my opinion that concern is valid.
So, how much work is it to reinstall axiom or friCAS, or open-axiom? 1 minute?
2 minutes?
> Pursuing branches at the Algebra language level will quickly lead to very
> different systems. It looks similar right now because we are all still close
> to the origin - personally I doubt this will last indefinitely.
I believe, the question is rather: do we want to drift apart at the user level?
I don't. If the algebra starts to diverge, do you think the number of
contributers will triple? As far as I can see, (i.e., among the mathematicians
I know of) the number of axiom users has rather decreased since the forks,
although it was increasing before.
I believe that forking the fundamental workings of axiom (i.e., the algebra,
the compiler) in an essentially incompatible way would be a disaster for axiom.
In this case, axiom would be lucky if only one fork would survive. Otherwise,
we will have three nearly dead CAS.
> Aren't most of the key players on all the lists anyway?
At least, it doesn't seem that the "key players" read all the lists. Otherwise
Tim would have known that SAGE runs Waldek's branch, there was a lengthy
discussion of the reasons for that.
Martin
Martin Rubey
> Oh, but they DO. Try to do parallel installations.
> Being able to run Fricas and Axiom in parallel would be great.
I cannot see any problem running friCAS and axiom in parallel. I do it, for
example (because I couldn't get Aldor to run with friCAS yet), and I wouldn't
even know what could go wrong!?
But please answer my question:
> Do you really want to maintain
>
> axiom.el, fricas.el, openaxiom.el,
> axiom.tm, fricas.tm, openaxiom.tm
> axiom.php, fricas.php, openaxiom.php?
(I think ALLPROSE is another candidate, but I do not know for sure)
Martin
C Y
--- root <da...@axiom-developer.org> wrote:
> ...[snip]...
> >Aldor, for example - unless Tim has plans I'm not aware of Axiom
> >itself won't be moving in the direction of using Aldor.
>
> Sigh. I replied to Bill's email a while ago that Axiom will have
> aldor available. I explained at that time that Bill was making
> a statement about Axiom that was not true. Aldor will be available
> in Axiom when I get it working and documentated in a literate way.
Ah, my bad.
> In fact, if you look at the posted patches on the
> Axiom mailing list you'll see one from 12/16 titled:
>
> 20071216.01.tpd.patch 20071216.02.tpd.patch (7045)
>
> I was patching bug 7045 and I forgot I was in the Aldor branch
> of the git directory rather than the mathml branch so I ended
> up posting the wrong Makefile.pamphlet. I'm actively working
> an aldor git branch. It's just not ready for silver yet.
OK. Sorry Tim - not paying close enough attention.
Alfredo Portes
Waldek, I think this is not a very good idea. I think that those who really
want to install several flavours of axiom in parallel, will find a way to do
that.
But for all the others, it just means that incompatibility is increased. For
example, axiom.el would have to be customized for no good reason.
I do think it is a good idea, especially to eliminate the very well discussed
issue of the name, which can cause friction among the projects.
Plus a think a simple syslink can solve the problem for those who want to
use the other interfaces.
Regards,
Alfredo
Gabriel Dos Reis
| --- Martin Rubey <martin...@univie.ac.at> wrote:
|
| > But they wouldn't! Why would you think that any of your work was
| > lost when you install axiom after having installed friCAS?
|
| I think the concern here is accidentally overwriting an installation of
| Axiom with FriCAS, for example, or having the wrong library used due to
| path confusion.
People familiar with Axiom, FriCAS, and OpenAxiom know that they have
different installation procedure (even before Waldek's patch). FriCAS had
the same procude as Axiom.build-improvements. OpenAxiom later changed
the installation procedure. Waldek's patch is was OpenAxiom used to
do in the earliest day (e.g. OpenAxiom-1.0.0).
It seems to me that we have more FUD that concrete data that we can
subject to rational analysis.
-- Gaby
Gabriel Dos Reis
|
| root <da...@axiom-developer.org> writes:
|
| > Oh, but they DO. Try to do parallel installations.
| > Being able to run Fricas and Axiom in parallel would be great.
With OpenAxiom and FriCAS, one can specify their own installation
directories at configure time.
-- Gaby
Gabriel Dos Reis
[...]
| The name issue has already caused problems. William Stein of SAGE
| believe he has Axiom installed when he actually has Fricas.
Of course, both you and me cannot speak for William Stein, but there
is strong evidence that he knows he has FriCAS.
-- Gaby
Gabriel Dos Reis
| >It seems to me that we have more FUD that concrete data that we can
| >subject to rational analysis.
|
| Sigh. So you don't read the mailing lists. However, you'll remember
| that Axiom was clobbered by the newer install on the windows platform.
You reported that you fumbled your installation. That is a different story.
-- Gaby
Gabriel Dos Reis
| >| The name issue has already caused problems. William Stein of SAGE
| >| believe he has Axiom installed when he actually has Fricas.
| >
| >Of course, both you and me cannot speak for William Stein, but there
| >is strong evidence that he knows he has FriCAS.
|
| Actually the Sage .spkg was named AxiomForSage or some such.
That is not what you wrote above. William Stein has been following
FriCAS development for almost its beginning. He knows the difference.
[...]
| Unless OpenAxiom and Fricas implement the )browse machinery
| there will be confusion.
Are you going to make a law that prevents them from implementing a
)browse command?
-- Gaby
Gabriel Dos Reis
| So it's not FUD.
In the specific case we are talking about, yes. Confer the discussion
we had on September 30, 2007.
| The problem is that they both use the same shell variable, command
| name, initialization filename and path variable name.
No.
When I install GNU coreutils on my Solaris box, I don't confuse
GNU with Sun. I install them in different directory. And Sun or AT&T
don't get to say how the `ls' command must be named by GNU on either
Solaris boxes or Linux boxes.
OpenAxiom installs all its algebra and sub-components in different
directory. OpenAxiom does not depend on an external setting of the
AXIOM variable -- this is the nth time I'm repeating it to you.
| CMUCL and SBCL, which differ because SBCL uses autoconf, do not
| interfere with each other in any way.
Install OpenAxiom in a directory different from Axiom. You can do it,
because OpenAxiom -- unlike Axiom -- lets you specify the destination
install directory at configuration time.
As a matter of fact, I have 6 copies of Axiom derivatives running on
the box I'm writing from.
Otherwise, the rest is a bug in Axiom -- you know how to fix it.
-- Gaby
Gabriel Dos Reis
| I only made one request when you forked Axiom. I asked
| that, as a professional courtesy, you please use your
| own project name.
It is called OpenAxiom. When you starts OpenAxiom-1.1.0-xxx
it says
OpenAxiom: The Open Scientific Computation Platform
Version: OpenAxiom 1.1.0-2007-12-15
Built on Saturday December 15, 2007 at 16:54:27
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave OpenAxiom and return to shell.
-----------------------------------------------------------------------------
-- Gaby
znmeb
On Dec 17, 2:14 pm, Martin Rubey <martin.ru...@univie.ac.at> wrote:
> > Pursuing branches at the Algebra language level will quickly lead to very
> > different systems. It looks similar right now because we are all still close
> > to the origin - personally I doubt this will last indefinitely.
>
> I believe, the question is rather: do we want to drift apart at the user level?
> I don't. If the algebra starts to diverge, do you think the number of
> contributers will triple? As far as I can see, (i.e., among the mathematicians
> I know of) the number of axiom users has rather decreased since the forks,
> although it was increasing before.
>
> I believe that forking the fundamental workings of axiom (i.e., the algebra,
> the compiler) in an essentially incompatible way would be a disaster for axiom.
> In this case, axiom would be lucky if only one fork would survive. Otherwise,
> we will have three nearly dead CAS.
systems. I don't have time to *test* three different CAS, *learn*
three different CAS, etc. Bluntly put, FriCAS offers me nothing I
can't get from Axiom, and Sage offers me nothing I can't get either
from Gentoo's Portage repository or from upstream source. So it really
doesn't matter to me if FriCAS "drifts apart" from Axiom at any level
-- it doesn't solve any problems I have better than Axiom does.
> > Aren't most of the key players on all the lists anyway?
>
> At least, it doesn't seem that the "key players" read all the lists. Otherwise
> Tim would have known that SAGE runs Waldek's branch, there was a lengthy
> discussion of the reasons for that.
posters on the three lists. And just how many Axiom users are there?
How many FriCAS users are there? How many OpenAxiom users are there?
And how many have enough free time to even contribute to *one* of
them, let alone three?
In short ... do we need three forks? Can there be a re-merging in the
near future? Or is it really just five or ten people that care about
*any* of them, and the rest of the world is happily using Maxima as a
general purpose open source CAS and Singular, Pari, GiNaC, etc. for
special-purpose applications?
>
> Martin
Bill Page
>
> ... Bluntly put, FriCAS offers me nothing I can't get from Axiom,
> and Sage offers me nothing I can't get either from Gentoo's
> Portage repository or from upstream source. So it really doesn't
> matter to me if FriCAS "drifts apart" from Axiom at any level
> -- it doesn't solve any problems I have better than Axiom does.
> ...
This statement makes me doubt that you have much experience with
either FriCAS or Sage since my experience is the exact opposite of
this. But I suppose it all depends on exactly what problems you
have... ;-)
Regards,
Bill Page.
znmeb
problems I need to solve range from simple asymptotic bounds analysis
that can be solved on a pocket calculator (even an HP-12C!) to complex
matrix models involving, among other things, Laplace transforms. I
need an expressive very-high-level mathematical language that reads
and writes like textbook formulas.
Some of the algorithms don't play all that well in floating point
arithmetic, so I need occasionally to have exact arithmetic or
rational arithmetic. And I need literate programming. But basically, I
need to be able to pick up a book like Haverkort's _Performance of
Computer Communication Systems_ and just punch in algorithms without
having to code them in a lower-level language.
There are a lot of things I *don't* need:
1. Groebner bases
2. Large-integer operations using modular algorithms
3. Hyperdoc (and probably the browser-based follow-on)
4. A Mathematica / Maple scale price tag.
At $200US, Derive was close to what I needed. The only thing it
wouldn't do was full literate documents -- I still needed to cut and
paste from a Derive session into a document. It wasn't exactly the
most programmable system either -- once you realized that it was a
dialect of Lisp, you could make things work, but Derive "programs"
were not nearly as readable as Axiom programs are. And, of course, it
has been dropped from Texas Instruments' catalog after version 6. And
of course, it only ran on Windows.
Yes, you're right -- I have almost no experience with FriCAS and none
whatsoever with Sage. When the FriCAS fork first happened, I
downloaded it just to see what it was all about. And I also downloaded
Sage, only to discover that it essentially installed a whole bunch of
packages I already had. They weren't things I needed or was even
interested in, so I uninstalled it.
Waldek Hebisch
Later:
> If it were a single symbol, ok. But it's not. What about the wikimedia plugin
> for axiom? What about the TeXmacs interface? Do you really want to maintain
>
> axiom.el, fricas.el, openaxiom.el,
> axiom.tm, fricas.tm, openaxiom.tm
> axiom.php, fricas.php, openaxiom.php?
Well, there are two changes. One is installation directory -- currently
Axiom and FriCAS use _different_ subdirectories of $PREFIX/lib/axiom
subdirectory. Which means that if you want to get somehing from
installation directory you need to find correct path anyway. OTOH
installing FriCAS from source will wipe out the entire $PREFIX/lib/axiom
tree -- this is not nice if you have something different here.
Also, when installing from binary packages user may want to delete
delete the whole install tree -- keeping names different reduces
confusion here. More important, having different installations
directories allows easier creation of non-conflictiong binary
packages.
The drawback changeing name of installation directory is that
different FriCAS versions will be found in different places. It is
a problem, but a few lines of code could do proper patch seach so
there is really no long term problem. And if we keep current name
we may expect that at least some binary packagers will change it
(for example current name violates Debian policy) -- so changing
name ourself will minimize confuzion.
Concerning name of user visible "binary" command (the axiom script):
user (and binary packagers) can choose any name for command, in
particular they can copy the script to a different name or use symlinks.
It is hard to second-guess what users will prefer, so we probably
should give them choice -- I will post a modified (compromise)
patch on FriCAS list.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
install the user visible command under two names: as 'axiom'
for backwards comatibility and as 'fricas'.
--- trunk.bb/Makefile.in 2007-12-17 20:03:43.000000000 +0100
+++ trunk/Makefile.in 2007-12-18 11:40:51.000000000 +0100
@@ -4,7 +4,7 @@
## ----------------------------------------
## CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
-COMMAND=$(DESTDIR)$(libdir)/axiom/target/$(target)/bin/axiom
+COMMAND=$(DESTDIR)$(libdir)/fricas/target/$(target)/bin/axiom
GCLOPTS=@GCLOPTS@
@@ -100,19 +100,20 @@
install:
@echo Installing Axiom in $(prefix)
- rm -rf $(DESTDIR)$(libdir)/axiom
- @mkdir -p $(DESTDIR)$(libdir)/axiom
- @cp -pr $(builddir)/target $(DESTDIR)$(libdir)/axiom
+ rm -rf $(DESTDIR)$(libdir)/fricas
+ mkdir -p $(DESTDIR)$(libdir)/fricas
+ cp -pr $(builddir)/target $(DESTDIR)$(libdir)/fricas
@echo '#!/bin/sh -' > ${COMMAND}
- @echo AXIOM=$(libdir)/axiom/target/$(target) >> ${COMMAND}
+ echo AXIOM=$(libdir)/fricas/target/$(target) >> ${COMMAND}
@echo export AXIOM >> ${COMMAND}
@echo PATH='$${AXIOM}/bin':'$${PATH}' >> ${COMMAND}
@echo export PATH >> ${COMMAND}
@cat $(axiom_src_srcdir)/etc/axiom >> ${COMMAND}
@chmod +x ${COMMAND}
- @rm -f $(DESTDIR)$(bindir)/axiom
+ rm -f $(DESTDIR)$(bindir)/fricas
@mkdir -p $(DESTDIR)$(bindir)
- @ $(INSTALL_PROGRAM) $(COMMAND) $(DESTDIR)$(bindir)/axiom
+ $(INSTALL_PROGRAM) $(COMMAND) $(DESTDIR)$(bindir)/fricas
+ $(INSTALL_PROGRAM) $(COMMAND) $(DESTDIR)$(bindir)/axiom
Martin Rubey
> This is a modified patch to change installation directory. It install the
> user visible command under two names: as 'axiom' for backwards comatibility
> and as 'fricas'.
OK, I think you are right. Two minor things:
1) question: will $AXIOM/src/algebra still refer to the right place? (used by
SPADEDIT) As far as I know, Tim's axiom needs a *global* environment
variable AXIOM, but neither friCAS nor open-axiom (I think) do, so it is
probably OK, isn't it.
2) request: some scripts, like the axiom.php for wikimedia, and I think also
the TeXmacs plugin want access to AXIOMsys. I admit, I don't really know
why. Do you think it's possible to give access to AXIOMsys via the axiom or
fricas script, which is would then be the only user-visible thing?
I think it is wrong to call AXIOMsys directly anyway, so this update would
make sense. Of course, it leaves users of Tim's axiom out in the cold...
Martin
Martin Rubey
Martin
znmeb
> It is hard to second-guess what users will prefer, so we probably
> should give them choice -- I will post a modified (compromise)
> patch on FriCAS list.
idea how many users of Axiom there were before the forks, and I have
no idea how many users decided to stay with Axiom and how many went
down one of the two forks. But I think the number of *users* who would
want to run more than one version of "Axiom" is miniscule -- perhaps
zero.
What *I* would prefer as a user is that there would only be one Axiom,
called Axiom, that works and is maintained by a large and friendly
community. Since that doesn't appear to be the case, I have chosen to
stay with the original Axiom.
So I am leaving this mailing list. There is no point in my getting
three copies of arguments when I don't even need *one* copy of them. I
suppose I should really just break down and buy a Mathematica license
-- at least I'd have some assurance that I'd be dealing with people
whose livelihoods depend on *asking* users what they would prefer and
then *delivering* it.
Waldek Hebisch
>
> Waldek Hebisch <heb...@math.uni.wroc.pl> writes:
>
> > This is a modified patch to change installation directory. It install the
> > user visible command under two names: as 'axiom' for backwards comatibility
> > and as 'fricas'.
>
Applied now.
> OK, I think you are right. Two minor things:
>
> 1) question: will $AXIOM/src/algebra still refer to the right place? (used by
> SPADEDIT)
Yes, part of the patch is to update setting of AXIOM variable inside
axiom/frics script.
> As far as I know, Tim's axiom needs a *global* environment
> variable AXIOM, but neither friCAS nor open-axiom (I think) do, so it is
> probably OK, isn't it.
>
> 2) request: some scripts, like the axiom.php for wikimedia, and I think also
> the TeXmacs plugin want access to AXIOMsys. I admit, I don't really know
> why. Do you think it's possible to give access to AXIOMsys via the axiom or
> fricas script, which is would then be the only user-visible thing?
>
> I think it is wrong to call AXIOMsys directly anyway, so this update would
> make sense.
Actually, there is legitimate need to use AXIOMsys: piping to/from
sman does not work, so one have to directly invoke AXIOMsys.
Giving access to AXIOMsys should be easy: we probably should add
'--nosman' option to the axiom/fricas script to do this.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Rubey
> Giving access to AXIOMsys should be easy: we probably should add '--nosman'
> option to the axiom/fricas script to do this.
I'd be grateful if you'd implement this. I'll patch axiom.el later to use
fricas instead of axiom.
Thanks,
Martin
Waldek Hebisch
The patch below is a possible implementation:
--- /home/s/test/tt/fricas/trunk/src/etc/axiom 2007-09-30 21:17:07.000000000 +0200
+++ trunk/src/etc/axiom 2007-12-22 05:26:31.000000000 +0100
@@ -44,7 +44,8 @@
showuse() {
-echo "axiom"
+echo "fricas"
+echo " [-nosman] use plain command line interface (disables other options)"
echo " [-ht |-noht] whether to use HyperDoc"
echo " [-gr |-nogr] whether to use Graphics"
echo " [-clef |-noclef] whether to use Clef"
@@ -118,6 +119,12 @@
# 2. Process command line arguments.
+if [ "$*" = "-nosman" ] ; then
+ exec $SPAD/bin/AXIOMsys
+ exit 1
+fi
+
+
# Defaults for command-line arguments.
list=no
go=yes
--
Waldek Hebisch
heb...@math.uni.wroc.pl