Discussion:
build-improvements and latex
(too old to reply)
Waldek Hebisch
2006-11-07 20:32:34 UTC
Permalink
I tried again 'make dvi' in build-improvements. There are still three
problems:
1) typo in 'src/etc/Makefile.pamphlet'
2) confusion because Latex prefers 'axiom.sty.tex' in current directory
to 'axiom.sty' in search path
3) axiom.bib.tex file contains 10 file names with unescaped underscores
inside.

I have a patch solving problems 1 and 2 (included below). BTW the patch
to solve 1 is trival. I think that we shall agree that trivial patches
may be commited without review (but still posted to the mailing list).
Of course we need also agree what trivial means -- the solution to 2
(since it involves file renaming) is probably slightly beyond trival...

BTW. I am a bit annoyed because of discrimination of underscores (I like
them very much), so I am tempted to solve 3 by making underscore into
an active character, which expands to ordinary underscore outside math
mode and to subscript char in math mode.


Beside applying the diff one has to also rename 'src/doc/axiom.sty.pamphlet'
to 'src/doc/axiom-sty.pamphlet'

diff -ru build-improvements.bb/config/setup-dep.mk build-improvements/config/setup-dep.mk
--- build-improvements.bb/config/setup-dep.mk 2006-11-07 02:34:28.000000000 +0100
+++ build-improvements/config/setup-dep.mk 2006-11-07 17:51:37.000000000 +0100
@@ -101,7 +101,7 @@
$(axiom_build_document) --weave --output=$@ $<


-$(axiom_build_texdir)/axiom.sty: $(axiom_src_docdir)/axiom.sty.pamphlet
+$(axiom_build_texdir)/axiom.sty: $(axiom_src_docdir)/axiom-sty.pamphlet
$(mkinstalldirs) $(axiom_build_texdir)/
$(axiom_build_document) --tangle=axiom.sty --output=$@ $<

diff -ru build-improvements.bb/src/doc/Makefile.pamphlet build-improvements/src/doc/Makefile.pamphlet
--- build-improvements.bb/src/doc/Makefile.pamphlet 2006-11-07 02:34:25.000000000 +0100
+++ build-improvements/src/doc/Makefile.pamphlet 2006-11-07 17:54:25.000000000 +0100
@@ -31,7 +31,7 @@
originally written by Norman Ramsey. To this we've added macros to
support the CATS (Computer Algebra Test Suite).
<<axiom.sty>>=
-${STY}/axiom.sty: $(srcdir)/axiom.sty.pamphlet ${STY}
+${STY}/axiom.sty: $(srcdir)/axiom-sty.pamphlet ${STY}
$(axiom_build_document) --tangle=axiom.sty --output=$@ $<

${STY}:
@@ -144,7 +144,7 @@

subdir = src/doc/

-pamphlets = axiom.sty.pamphlet \
+pamphlets = axiom-sty.pamphlet \
axiom.bib.pamphlet \
DeveloperNotes.pamphlet \
Rosetta.pamphlet \
Only in build-improvements/src/doc: axiom-sty.pamphlet
Only in build-improvements.bb/src/doc: axiom.sty.pamphlet
diff -ru build-improvements.bb/src/etc/Makefile.pamphlet build-improvements/src/etc/Makefile.pamphlet
--- build-improvements.bb/src/etc/Makefile.pamphlet 2006-11-07 02:34:26.000000000 +0100
+++ build-improvements/src/etc/Makefile.pamphlet 2006-11-07 17:45:45.000000000 +0100
@@ -3,7 +3,7 @@
\usepackage{axiom}
\begin{document}
\title{\$SPAD/src/etc Makefile}
-\author{Timothy Daly \andd Gabriel Dos~Reis}
+\author{Timothy Daly \and Gabriel Dos~Reis}
\maketitle
\begin{abstract}
\end{abstract}
--
Waldek Hebisch
***@math.uni.wroc.pl
Ralf Hemmecke
2006-11-07 20:59:49 UTC
Permalink
I oppose against special treatment of .sty files.

The general rule should be

notangle file.ext.pamphlet > file.ext
noweave file.ext.pamphlet > file.ext.pamphlet.tex

remove ".pamphlet" and add ".tex". That rule seems to be a bit simpler
than having to explain why .sty files must be treated separately.

Ralf
Post by Waldek Hebisch
I tried again 'make dvi' in build-improvements. There are still three
1) typo in 'src/etc/Makefile.pamphlet'
2) confusion because Latex prefers 'axiom.sty.tex' in current directory
to 'axiom.sty' in search path
3) axiom.bib.tex file contains 10 file names with unescaped underscores
inside.
I have a patch solving problems 1 and 2 (included below). BTW the patch
to solve 1 is trival. I think that we shall agree that trivial patches
may be commited without review (but still posted to the mailing list).
Of course we need also agree what trivial means -- the solution to 2
(since it involves file renaming) is probably slightly beyond trival...
BTW. I am a bit annoyed because of discrimination of underscores (I like
them very much), so I am tempted to solve 3 by making underscore into
an active character, which expands to ordinary underscore outside math
mode and to subscript char in math mode.
Beside applying the diff one has to also rename 'src/doc/axiom.sty.pamphlet'
to 'src/doc/axiom-sty.pamphlet'
diff -ru build-improvements.bb/config/setup-dep.mk build-improvements/config/setup-dep.mk
--- build-improvements.bb/config/setup-dep.mk 2006-11-07 02:34:28.000000000 +0100
+++ build-improvements/config/setup-dep.mk 2006-11-07 17:51:37.000000000 +0100
@@ -101,7 +101,7 @@
-$(axiom_build_texdir)/axiom.sty: $(axiom_src_docdir)/axiom.sty.pamphlet
+$(axiom_build_texdir)/axiom.sty: $(axiom_src_docdir)/axiom-sty.pamphlet
$(mkinstalldirs) $(axiom_build_texdir)/
diff -ru build-improvements.bb/src/doc/Makefile.pamphlet build-improvements/src/doc/Makefile.pamphlet
--- build-improvements.bb/src/doc/Makefile.pamphlet 2006-11-07 02:34:25.000000000 +0100
+++ build-improvements/src/doc/Makefile.pamphlet 2006-11-07 17:54:25.000000000 +0100
@@ -31,7 +31,7 @@
originally written by Norman Ramsey. To this we've added macros to
support the CATS (Computer Algebra Test Suite).
<<axiom.sty>>=
-${STY}/axiom.sty: $(srcdir)/axiom.sty.pamphlet ${STY}
+${STY}/axiom.sty: $(srcdir)/axiom-sty.pamphlet ${STY}
@@ -144,7 +144,7 @@
subdir = src/doc/
-pamphlets = axiom.sty.pamphlet \
+pamphlets = axiom-sty.pamphlet \
axiom.bib.pamphlet \
DeveloperNotes.pamphlet \
Rosetta.pamphlet \
Only in build-improvements/src/doc: axiom-sty.pamphlet
Only in build-improvements.bb/src/doc: axiom.sty.pamphlet
diff -ru build-improvements.bb/src/etc/Makefile.pamphlet build-improvements/src/etc/Makefile.pamphlet
--- build-improvements.bb/src/etc/Makefile.pamphlet 2006-11-07 02:34:26.000000000 +0100
+++ build-improvements/src/etc/Makefile.pamphlet 2006-11-07 17:45:45.000000000 +0100
@@ -3,7 +3,7 @@
\usepackage{axiom}
\begin{document}
\title{\$SPAD/src/etc Makefile}
-\author{Timothy Daly \andd Gabriel Dos~Reis}
+\author{Timothy Daly \and Gabriel Dos~Reis}
\maketitle
\begin{abstract}
\end{abstract}
Gabriel Dos Reis
2006-11-07 21:45:24 UTC
Permalink
Ralf Hemmecke <***@hemmecke.de> writes:

| I oppose against special treatment of .sty files.
|
| The general rule should be
|
| notangle file.ext.pamphlet > file.ext
| noweave file.ext.pamphlet > file.ext.pamphlet.tex
|
| remove ".pamphlet" and add ".tex".

Ralf,

remove ".pamphlet" and add ".tex".

translates to

noweave file.ext.pamphlet > file.ext.tex

not

noweave file.ext.pamphlet > file.ext.pamphlet.tex

I believe that is what we currently do:

if test x$do_weave = xyes; then
file=`basename $1 .pamphlet`
$weave -delay $1 > $file.tex
if test x$do_latex != xyes; then
exit 0;
fi
fi

-- gaby
Ralf Hemmecke
2006-11-07 22:07:58 UTC
Permalink
Post by Gabriel Dos Reis
| I oppose against special treatment of .sty files.
|
| The general rule should be
|
| notangle file.ext.pamphlet > file.ext
| noweave file.ext.pamphlet > file.ext.pamphlet.tex
|
| remove ".pamphlet" and add ".tex".
Ralf,
remove ".pamphlet" and add ".tex".
translates to
noweave file.ext.pamphlet > file.ext.tex
not
noweave file.ext.pamphlet > file.ext.pamphlet.tex
if test x$do_weave = xyes; then
file=`basename $1 .pamphlet`
$weave -delay $1 > $file.tex
if test x$do_latex != xyes; then
exit 0;
fi
fi
-- gaby
Right.

And I _suggested_ to change the current rule. That would avoid the
problem with .sty files without renaming them.

Whether we have file.ext.tex or file.ext.pamphlet.tex does not matter
from the point of view of filenames, since there are (at least) two dots
already. And both are generated anyway.

But my naming scheme makes it simpler to allow srcltx.sty to work. That
would allow 'inverse search' (i.e. click in the .dvi file and jump
directly to the corresponding line in the corresponding file in the
editor of your choice.

We don't have that yet in Axiom that one .dvi file consists of several
pamphlets, but I am sure that will come.


Something like below would go to axiom.sty.pamphlet.
\SOURCEROOT is only there to allow relative or absolute path in the .dvi
file.

<<srcltx patch>>=
% For our purpose it is better to keep it in a similar form to that in
% version 1.4 of srcltx.
\@ifundefined{SOURCEROOT}{\def\SOURCEROOT{}}{}
\def\***@src@@@input#1#2{%
\***@before@***@hook{\ifx\@empty\SOURCEROOT\else\SOURCEROOT/\fi#2}%
%--rhx: NO '.tex' extension in the line above.
\***@input{#2}%
\***@after@***@hook{#1}%
}
@

<<package srcltx>>=
<<srcltx patch>>
\IfFileExists{srcltx.sty}%
{\usepackage{srcltx}[2004/05/15
v1.4]\let\src@@@input\***@src@@@input}%
{\typeout{ALLPROSE warning: Cannot find srcltx.sty.}}
@
Gabriel Dos Reis
2006-11-07 22:32:31 UTC
Permalink
Ralf Hemmecke <***@hemmecke.de> writes:

| On 11/07/2006 10:45 PM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke <***@hemmecke.de> writes:
| > | I oppose against special treatment of .sty files.
| > | | The general rule should be
| > | | notangle file.ext.pamphlet > file.ext
| > | noweave file.ext.pamphlet > file.ext.pamphlet.tex
| > | | remove ".pamphlet" and add ".tex".
| > Ralf,
| > remove ".pamphlet" and add ".tex".
| > translates to
| > noweave file.ext.pamphlet > file.ext.tex
| > not
| > noweave file.ext.pamphlet > file.ext.pamphlet.tex
| > I believe that is what we currently do:
| > if test x$do_weave = xyes; then
| > file=`basename $1 .pamphlet`
| > $weave -delay $1 > $file.tex
| > if test x$do_latex != xyes; then
| > exit 0;
| > fi
| > fi
| > -- gaby
|
| Right.
|
| And I _suggested_ to change the current rule.

I thought your suggestion was

remove ".pamphlet" and add ".tex". That rule seems to be a bit simpler
than having to explain why .sty files must be treated separately.

Is that correct?

-- Gaby
Ralf Hemmecke
2006-11-07 22:56:40 UTC
Permalink
Post by Gabriel Dos Reis
| And I _suggested_ to change the current rule.
I thought your suggestion was
remove ".pamphlet" and add ".tex". That rule seems to be a bit simpler
than having to explain why .sty files must be treated separately.
Is that correct?
If I ever suggested that, I must have made a terrible mistake. I
remember that we recently (about a week ago or so) had something on the
list about .sty files. At that time your document had already been written.

No my suggestion is as I said in my last mail.
noweave file.pamphlet > file.pamphlet.tex.

Removing .pamphlet leads to the problem with
axiom.sty.pamphlet ---> axiom.sty.tex
axiom.sty.pamphlte ---> axiom.sty
both seen by TeX.

Rather change the document script.


Ralf
Ralf Hemmecke
2006-11-08 00:20:44 UTC
Permalink
Post by Gabriel Dos Reis
| I oppose against special treatment of .sty files.
|
| The general rule should be
|
| notangle file.ext.pamphlet > file.ext
| noweave file.ext.pamphlet > file.ext.pamphlet.tex
|
| remove ".pamphlet" and add ".tex".
Gaby, maybe the last sentence of mine was misleading.
I meant: remove .pamphlet for notangle and add .tex for noweave.

Ralf
Gabriel Dos Reis
2006-11-07 21:38:23 UTC
Permalink
Waldek Hebisch <***@math.uni.wroc.pl> writes:

| I tried again 'make dvi' in build-improvements. There are still three
| problems:
| 1) typo in 'src/etc/Makefile.pamphlet'
| 2) confusion because Latex prefers 'axiom.sty.tex' in current directory
| to 'axiom.sty' in search path
| 3) axiom.bib.tex file contains 10 file names with unescaped underscores
| inside.
|
| I have a patch solving problems 1 and 2 (included below). BTW the patch
| to solve 1 is trival. I think that we shall agree that trivial patches
| may be commited without review (but still posted to the mailing list).
| Of course we need also agree what trivial means -- the solution to 2
| (since it involves file renaming) is probably slightly beyond trival...
|
| BTW. I am a bit annoyed because of discrimination of underscores (I like
| them very much), so I am tempted to solve 3 by making underscore into
| an active character, which expands to ordinary underscore outside math
| mode and to subscript char in math mode.

Hi Waldek,

I'm busy at the moment; but patch for (1) is obviously OK.

Patch for (2) needs an explanation in the pamphlet as to why
we are renaming. You explained why in previous mails, but we need the
explanation in the pamphlet, not just in the mail [yes, it shows up
only for in-source build, because LaTeX looks in the current directory
first, but we need those in the pamphlet. This is an exception to a
general naming scheme so it needs documentation. ]

For problem (3), I'm awaiting for input from others.

As for your other tentative patch for checking for openpty, I
believe you're reading in my mind. I'll comment later. Then, I'll
have to add comments to the fixes to regex issue. However simple, it
looks, we have to explain in the pamphlets (to people not versed in
system programming), especially the faith of regexp.h and why we must
use <regex.h> and remove the old macro interface.

-- Gaby
Ralf Hemmecke
2006-11-08 00:04:49 UTC
Permalink
Post by Gabriel Dos Reis
| 3) axiom.bib.tex file contains 10 file names with unescaped underscores
| inside.
| BTW. I am a bit annoyed because of discrimination of underscores (I like
| them very much), so I am tempted to solve 3 by making underscore into
| an active character, which expands to ordinary underscore outside math
| mode and to subscript char in math mode.
For problem (3), I'm awaiting for input from others.
The drastic way... Remove axiom.bib.pamphlet (from which probably
axiom.bib.tex was generated).
That is not really a .bib file. It is a collection of filenames. And I
would rather see that the translated documentation has hyperlinks
instead of references to a "bibliography" that consists of filenames.

If someone thinks that axiom.bib.pamphlet is a file in good LP style, I
have not understood what LP means.

Underscores would be no problem at all if filenames where properly
tagged. Note that there is a latex package called url
(/usr/share/texmf/tex/latex/misc/url.sty)
which provides a \path command. Together with hyperref one can turn that
also into hyperlinks.

(I don't like underscores. They cause problems in many places.)

Ralf
Waldek Hebisch
2006-11-07 22:17:01 UTC
Permalink
Post by Ralf Hemmecke
I oppose against special treatment of .sty files.
The general rule should be
notangle file.ext.pamphlet > file.ext
noweave file.ext.pamphlet > file.ext.pamphlet.tex
remove ".pamphlet" and add ".tex". That rule seems to be a bit simpler
than having to explain why .sty files must be treated separately.
Well, .sty files _are_ special (normal files do not contain "self
references"). And if you think about rule:

notangle file.ext.pamphlet > file.ext

this _is_ alredy broken by many files (in 'src/hyper') when we
have

file.pamphlet -> file.c

or

/-> file.h
file.pamphlet -|
\-> file.c

I agree that you proposal is logical, but it is also clumsy: .pamphlet
extension is already pretty long and sticking on it another extension
will give very long files names.
--
Waldek Hebisch
***@math.uni.wroc.pl
Ralf Hemmecke
2006-11-07 22:42:41 UTC
Permalink
Post by Waldek Hebisch
Post by Ralf Hemmecke
I oppose against special treatment of .sty files.
The general rule should be
notangle file.ext.pamphlet > file.ext
noweave file.ext.pamphlet > file.ext.pamphlet.tex
remove ".pamphlet" and add ".tex". That rule seems to be a bit simpler
than having to explain why .sty files must be treated separately.
Well, .sty files _are_ special (normal files do not contain "self
notangle file.ext.pamphlet > file.ext
this _is_ alredy broken by many files (in 'src/hyper') when we
have
file.pamphlet -> file.c
or
/-> file.h
file.pamphlet -|
\-> file.c
I agree that you proposal is logical, but it is also clumsy: .pamphlet
extension is already pretty long and sticking on it another extension
will give very long files names.
First. Why do you care about length of _generated_ filenames? You'll
almost never see or touch them.

Second. With srcltx and inverse search, you _never_ have to type
anything else than the command to start your dvi viewer with the right
.dvi file. Everything else you read in the .dvi file, click there and
magically your editor opens the right file at exactly the right place. I
cannot imagine why you don't want that.

Third. I perhaps agree that just removing ".pamphlet" is not the best
idea in general as you showed for pamphlets that contain .h and .c
files. But note that then the corresponding Makefile must be more
complex, since some logic of the .pamphlet file (namely that
file.pamphlet contains file.h and file.c) is maintained externally to
the .pamphlet.

Still, I would rather like to see a general scheme than just adjusting
locally. Keep the rules simple (or rather: introduce simple rules).

One suggestion could be to have particular chunk names that say what are
the "top-level" chunks and which are the corresponding filenames for
notangle. (I explicitly say notangle, since I still want to see my
suggestion of adding ".tex" to obtain ".pamphlet.tex" for noweave.)

Ralf
Gabriel Dos Reis
2006-11-07 22:56:51 UTC
Permalink
Ralf Hemmecke <***@hemmecke.de> writes:

[...]

| Still, I would rather like to see a general scheme than just adjusting
| locally. Keep the rules simple (or rather: introduce simple rules).

I, too, would like to see simple rules that resolve this issue in
general and simple manner (I can think of many solutions, but I don't
see any of them general and simple yet), and has some taste to it :-)

| One suggestion could be to have particular chunk names that say what
| are the "top-level" chunks and which are the corresponding filenames
| for notangle. (I explicitly say notangle, since I still want to see my
| suggestion of adding ".tex" to obtain ".pamphlet.tex" for noweave.)

I suspect I don't see why it *must* be that we must have ".pamphlet.tex".


There is a related issue, which is how serious Axiom is about
portability. In some places, it seems quite stringent in its demand
(leading to quite awkward and unnatural acts, e.g. abbreviation
names), and yet it cavalierly overlooks them (e.g. not all filesystems
can handle filenames with more than on does in them).

-- Gaby
Gabriel Dos Reis
2006-11-07 22:38:59 UTC
Permalink
Waldek Hebisch <***@math.uni.wroc.pl> writes:

[...]

| this _is_ alredy broken by many files (in 'src/hyper') when we
| have
|
| file.pamphlet -> file.c
|
| or
|
| /-> file.h
| file.pamphlet -|
| \-> file.c
|

I considered that some time ago.

However, I must confess: file.h and file.c, to my mind, forms a
logical unit. Consequently I think of file.pamphlet as that logical
unit be described. I see no logical problem or exception that from
that logical unit, different sub-units are extracted to be processed by
the same tool (the C compiler).
Consequently, I'm not convinced that it can be used an evidence for
the axiom.sty treatment.

| I agree that you proposal is logical, but it is also clumsy: .pamphlet
| extension is already pretty long and sticking on it another extension
| will give very long files names.

I agree that the .pamphlet is clumsy, and we should not sacrifice
logic.

I would like to understand more Ralf's suggestion, because I got
the impression that we already implemented what he is suggesting (but
apparently no).

-- Gaby
Page, Bill
2006-11-07 22:45:42 UTC
Permalink
Post by Waldek Hebisch
Post by Ralf Hemmecke
I oppose against special treatment of .sty files.
The general rule should be
notangle file.ext.pamphlet > file.ext
noweave file.ext.pamphlet > file.ext.pamphlet.tex
remove ".pamphlet" and add ".tex". That rule seems to be
a bit simpler than having to explain why .sty files must
be treated separately.
I don't think what Waldek proposes amounts to "separate treatment".
He is just observing that the existing name for the pamphlet file
conflicts with the behaviour of latex.
Post by Waldek Hebisch
Well, .sty files _are_ special (normal files do not contain
"self references").
I think Waldek is right. This name for the pamphlet file is
unusal. The only convention that we have is really just:

noweave filename.pamphlet > filename.tex
latex filename.tex

and I think that is very natural because noweave always applies to
the entire file. Normally, the filename part does not contain any dot.
Post by Waldek Hebisch
notangle file.ext.pamphlet > file.ext
notangle is completely different because it can either apply to
the whole file or to just one chunk of the file (-R option). If
we have a convention for notangle, then I think it should be like
this:

notangle filename.pamphlet -R 'file.ext' > file.ext
Post by Waldek Hebisch
this _is_ alredy broken by many files (in 'src/hyper') when we
have
file.pamphlet -> file.c
Is there a case like this? Maybe it should be written:

notangle file.pamphlet -R 'file.c' > file.c

With <<file.c>>= defined appropriately.
Post by Waldek Hebisch
or
/-> file.h
file.pamphlet -|
\-> file.c
In this case I think it is really

notangle file.pamphlet -R 'file.h' > file.h
notangle file.pamphlet -R 'file.c' > file.c

Right?
Post by Waldek Hebisch
.pamphlet extension is already pretty long and sticking on it
another extension will give very long files names.
I think the only convincing reason that Ralf gave for his
convention for noweave was interaction with point-and-click
in dvi. But this could be achieved through a different
patch to srcltx. No?

Regards,
Bill Page.
Gabriel Dos Reis
2006-11-07 23:02:19 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

[...]

| > this _is_ alredy broken by many files (in 'src/hyper') when we
| > have
| >
| > file.pamphlet -> file.c
| >
|
| Is there a case like this?

yes, many of the C pamphlet files. My eyes was caught by that, but
quickly my brain said it was OK, because they form a logical unit.

| Maybe it should be written:
|
| notangle file.pamphlet -R 'file.c' > file.c

Yes, that is was it is written:

$(builddir)/%.c: $(srcdir)/%.pamphlet
$(axiom_build_document) --tangle --output=$@ $<

| With <<file.c>>= defined appropriately.
|
| > or
| >
| > /-> file.h
| > file.pamphlet -|
| > \-> file.c
| >
|
| In this case I think it is really
|
| notangle file.pamphlet -R 'file.h' > file.h
| notangle file.pamphlet -R 'file.c' > file.c
|
| Right?

Yes, you're correct.

| > I agree that you proposal is logical, but it is also clumsy:
| > .pamphlet extension is already pretty long and sticking on it
| > another extension will give very long files names.
| >
|
| I think the only convincing reason that Ralf gave for his
| convention for noweave was interaction with point-and-click
| in dvi. But this could be achieved through a different
| patch to srcltx. No?

I completely agree with that.

-- Gaby
Ralf Hemmecke
2006-11-07 23:30:36 UTC
Permalink
Post by Page, Bill
I think the only convincing reason that Ralf gave for his
convention for noweave was interaction with point-and-click
in dvi. But this could be achieved through a different
patch to srcltx. No?
But I guess that patch would be a bit longer. In the patch I gave, I use
the fact that \***@input (which is defined as \let\***@input\input)
automatically adds the .tex extension.

I didn't want to change srcltx.sty too much and when I stumbled over
that file.sty/file.sty.tex problem, I decided for file.sty.nw.tex (just
adding the .tex extension) in ALLPROSE. In that way I made the patch
short and I avoided another problem. And my rule is simple.

It is even a bit more complicated. My patch basically gets the clicks
right, if the file contains \input of other files. It does not work with
the master file. So if one translates file.pamphlet to file.tex even
with my patch one doesn't get point&click. (Or rather the click will
lead to the .tex file and not to the .pamphlet.) For that to work
correctly, it would need yet another patch. I haven't investigated it
since in ALLPROSE I automatically generate a wrapper that includes the
generated latex files (plural!).

What speaks so much against just adding .tex?
Portability? Look at the output of

cd build-improvements
find . -name '*.*.pamphlet'

Is there a plan to rename them all?

Ralf
Gabriel Dos Reis
2006-11-08 02:26:03 UTC
Permalink
Ralf Hemmecke <***@hemmecke.de> writes:

[...]

| What speaks so much against just adding .tex?

Simplicity in the extensions. And yes, portability matters if you
take it seriously.

| Portability? Look at the output of
|
| cd build-improvements
| find . -name '*.*.pamphlet'
|
| Is there a plan to rename them all?

:-)

Given recent discussions, I would wait till the dust gets down.

-- Gaby
Martin Rubey
2006-11-08 08:06:31 UTC
Permalink
Dear all,
Post by Ralf Hemmecke
What speaks so much against just adding .tex?
I'd also speak in *favour* of simply adding .tex. It makes life easier also in
other places:

### The following is only for those who use auctex in emacs for latexing!) ###

I use auctex and added a dead simple "document" command. Thus I can visit a
pamphlet file (for example, by clicking in HyperDoc on INT.spad)

make some changes

press

C-c C-c
Martin Rubey
2006-11-08 08:11:17 UTC
Permalink
I pressed C-c C-c in gnus, not in the pamphlet... Sorry, continuation below
Post by Martin Rubey
Dear all,
Post by Ralf Hemmecke
What speaks so much against just adding .tex?
I'd also speak in *favour* of simply adding .tex. It makes life easier also in
### The following is only for those who use auctex in emacs for latexing!) ###
I use auctex and added a dead simple "document" command. Thus I can visit a
pamphlet file (for example, by clicking in HyperDoc on INT.spad)
make some changes
press
C-c C-c
enter document

press C-c C-c again

auctex proposes "View". But of course, the parameter is wrong, it is

name.pamphlet.dvi

instead of

name.dvi

-------------------------------------------------------------------------------

I fail to see a reason why simply adding the tex is a bad idea.

But very often in this Makefile business I only know half of the story, so
please don't be angry with me.

Martin
Page, Bill
2006-11-07 23:53:31 UTC
Permalink
Post by Ralf Hemmecke
...
One suggestion could be to have particular chunk names that
say what are the "top-level" chunks and which are the
corresponding filenames for notangle.
Yes, I agree that the convention for notangle should interact
with chunk names. There is at least one system that uses noweb
format with the convention that all chunk names that "look like
file names" automatically imply extraction as a file name. E.g.

http://en.literateprograms.org/LiteratePrograms

Or we could adopt something like you suggest, i.e. a special
"top-level" chunk that contains that names of chunks to create
as files. But I think that would also have the negative effect
of hiding implicit file names inside the pamphlet file. In a
make script I think it is better to make it obvious how the
dependency is satisfied e.g.

file.c: filename.pamphlet
document --tangle='file.c' filename.pamphlet

would extract the chunk -R 'file.c' as a file named 'file.c'
from the file 'filename.pamphlet'. Or see Gaby's stanza
template rule and my proposed modification below.
Post by Ralf Hemmecke
(I explicitly say notangle, since I still want to see my
suggestion of adding ".tex" to obtain ".pamphlet.tex" for
noweave.)
It is possible to use srcltx even if we don't keep the
*.pamphlet.* part if we assume that all .dvi files are
derived from .pamphlet files. Right? I think this is a
reasonable assumption for Axiom given the policy on literate
programming.
Post by Ralf Hemmecke
...
|
| notangle file.pamphlet -R 'file.c' > file.c
$(builddir)/%.c: $(srcdir)/%.pamphlet
I think with the current 'document' script that would have to
be:

$(builddir)/%.c: $(srcdir)/%.pamphlet
$(axiom_build_document) --tangle=$@ --output=$@ $<

because by default the --tangle option in 'document' will
extract the root chunk.

I would suggest allowing the --output option to default to the
chunk name instead of begin derived from the pamphlet name. Then
one could wrote:

$(builddir)/%.c: $(srcdir)/%.pamphlet
$(axiom_build_document) --tangle=$@ $<


I.e. patch 'document' like this:

if [ -z $output ]; then
- output=`basename $file .pamphlet`;
+ output=$chunk;
fi

Regards,
Bill Page.
Ralf Hemmecke
2006-11-08 00:17:46 UTC
Permalink
Post by Page, Bill
It is possible to use srcltx even if we don't keep the
*.pamphlet.* part if we assume that all .dvi files are
derived from .pamphlet files. Right? I think this is a
reasonable assumption for Axiom given the policy on literate
programming.
srcltx does nothing else than writing setting a counter for the line
number and writes calls

\special{src:\the\inputlineno\***@maybe@space\CurrentInput

or

\special{src:1\CurrentInput}

which puts some bytes into the .dvi for the point&click.

Hmmm... the task would than be to write a tex macro which
replaces the .tex extension of \CurrentInput by .pamphlet.

Maybe that would be a solution. But it doesn't solve the axiom.sty.tex
problem.

Ralf
Gabriel Dos Reis
2006-11-08 02:23:11 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

[...]

| > Bill Page wrote:
| > | Maybe it should be written:
| > |
| > | notangle file.pamphlet -R 'file.c' > file.c
| >
| > Yes, that is was it is written:
| >
| > $(builddir)/%.c: $(srcdir)/%.pamphlet
| > $(axiom_build_document) --tangle --output=$@ $<
|
| I think with the current 'document' script that would have to
| be:
|
| $(builddir)/%.c: $(srcdir)/%.pamphlet
| $(axiom_build_document) --tangle=$@ --output=$@ $<
|
| because by default the --tangle option in 'document' will
| extract the root chunk.

Yes; but the root chunk corresponds to the .c files. Most of them
look like this:

<<*>>=
<<license>>
<<titlebar.c>>
@

I must confess that I did not invent anything there: I just
abstracted over the repetitions.

However, for header files, the rules look like this:

<<header files>>=
.PRECIOUS: $(builddir)/%.h

$(HEADERS): $(builddir)/%.h: $(srcdir)/%.pamphlet
$(axiom_build_document) --tangle=$*.h --output=$@ $<
@

| I would suggest allowing the --output option to default to the
| chunk name instead of begin derived from the pamphlet name. Then
| one could wrote:
|
| $(builddir)/%.c: $(srcdir)/%.pamphlet
| $(axiom_build_document) --tangle=$@ $<
|
|
| I.e. patch 'document' like this:
|
| if [ -z $output ]; then
| - output=`basename $file .pamphlet`;
| + output=$chunk;
| fi

this is when $chunk is specified. That is doable. We just have to
check when it is not specified and use the other rule.

-- Gaby
Page, Bill
2006-11-08 00:19:21 UTC
Permalink
Ralf,
Post by Ralf Hemmecke
...
What speaks so much against just adding .tex?
Portability? Look at the output of
cd build-improvements
find . -name '*.*.pamphlet'
Is there a plan to rename them all?
Ugh! You are right. Despite Gaby's implication, I can not think
of any file system in use today where we might want to run Axiom
that does not permit multiple dots in file names.

But yes, I think Tim did promote a plan that would (eventually)
change most of these names. For example I think all the .input
test files would likely be collected as chunks within a single
testing "volume" .pamphlet.

However pamphlet files with multiple chunks interact badly with
the make dependency processing since changing or adding a single
chunk in a pamphlet file triggers re-extraction of all files
dependent on that pamphlet and subseqent dependent make processing.
To over come this, we would have modify the 'document' script so
that it does not touch an existing file if it has not changed
(i.e. extract the chunk to a temporary file and overwrite the
original only if diff -q fails).

In the mean time, I think just renaming axiom.sty as Waldek
suggested is not so confusing, given the discussion in the rest
of this thread. Maybe instead of 'axiom-sty.pamphlet' something
like 'axiom-latex.pamphlet' might be a better name with
<<axiom.sty>= and possibly other latex-related chunks collected
in a single pamphlet file.

Regards,
Bill Page.
Ralf Hemmecke
2006-11-08 00:32:03 UTC
Permalink
Post by Page, Bill
However pamphlet files with multiple chunks interact badly with
the make dependency processing since changing or adding a single
chunk in a pamphlet file triggers re-extraction of all files
dependent on that pamphlet and subseqent dependent make processing.
To over come this, we would have modify the 'document' script so
that it does not touch an existing file if it has not changed
(i.e. extract the chunk to a temporary file and overwrite the
original only if diff -q fails).
I would use "cpif" for that purpose. Norman Ramsey has already thought
of that case.
Post by Page, Bill
In the mean time, I think just renaming axiom.sty as Waldek
suggested is not so confusing, given the discussion in the rest
of this thread. Maybe instead of 'axiom-sty.pamphlet' something
like 'axiom-latex.pamphlet' might be a better name with
<<axiom.sty>= and possibly other latex-related chunks collected
in a single pamphlet file.
I agree that LP suggests to think in terms of logical units for humans,
but on the other hand I am still a bit old-fashioned (and maybe also
human), since I would have hard times to look in the file system for the
place of a particular file (which is hidden in a .pamphlet file with
another name). In that sense pamphlet files would not fit me as a human.
Maybe I should change ... ;-)

Ralf
Gabriel Dos Reis
2006-11-08 02:33:33 UTC
Permalink
Ralf Hemmecke <***@hemmecke.de> writes:

[...]

| > In the mean time, I think just renaming axiom.sty as Waldek
| > suggested is not so confusing, given the discussion in the rest
| > of this thread. Maybe instead of 'axiom-sty.pamphlet' something
| > like 'axiom-latex.pamphlet' might be a better name with
| > <<axiom.sty>= and possibly other latex-related chunks collected
| > in a single pamphlet file.
|
| I agree that LP suggests to think in terms of logical units for
| humans, but on the other hand I am still a bit old-fashioned (and
| maybe also human), since I would have hard times to look in the file
| system for the place of a particular file (which is hidden in a
| .pamphlet file with another name). In that sense pamphlet files would
| not fit me as a human. Maybe I should change ... ;-)

The LP idea, and the pamphlet files by implication, works beautifully
when you get everything right from the start and you don't have to
look under the hood (e.g. debugging, etc.). By definition, if you're
not using it for an evolving system -- which by definition is buggy.
By the minutes you have to deal also with the generated and
intermediate files, it becomes very very messy.

Fire!

-- Gaby
Humberto Ortiz-Zuazaga
2006-11-08 10:09:42 UTC
Permalink
Post by Gabriel Dos Reis
The LP idea, and the pamphlet files by implication, works beautifully
when you get everything right from the start and you don't have to
look under the hood (e.g. debugging, etc.). By definition, if you're
not using it for an evolving system -- which by definition is buggy.
By the minutes you have to deal also with the generated and
intermediate files, it becomes very very messy.
Fire!
I've used the "-L" notangle option to great effect when writing C code
with noweb. Even gdb can find the proper source lines.
--
Humberto Ortiz-Zuazaga
Programmer-Archaeologist
University of Puerto Rico
http://www.hpcf.upr.edu/~humberto/
Ralf Hemmecke
2006-11-08 10:23:50 UTC
Permalink
Post by Humberto Ortiz-Zuazaga
Post by Gabriel Dos Reis
The LP idea, and the pamphlet files by implication, works beautifully
when you get everything right from the start and you don't have to
look under the hood (e.g. debugging, etc.). By definition, if you're
not using it for an evolving system -- which by definition is buggy.
By the minutes you have to deal also with the generated and
intermediate files, it becomes very very messy.
Fire!
I've used the "-L" notangle option to great effect when writing C code
with noweb. Even gdb can find the proper source lines.
I very much support that. But what you write after the -L depends on the
programming language that notangle spits out. Seeing #line statements in
a generated .bib file, is maybe not such a good idea.

As I said earlier, I would rather like to see generic rules than having
always to look at the Makefile what actually happens. Distinguishing
according to filetypes is probably ok, there are not too many types
around. But I would like to see no exceptions to general rules on a
per-file basis.

Ralf
Gabriel Dos Reis
2006-11-08 02:30:00 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

[...]

| However pamphlet files with multiple chunks interact badly with
| the make dependency processing since changing or adding a single
| chunk in a pamphlet file triggers re-extraction of all files
| dependent on that pamphlet and subseqent dependent make processing.

Like for most (all?) generated files, there is a way out within the
GNU build system: change a file only if its content really changed.
Use the move-if-change script.

It is on the list of things to do for build-improvements.

-- Gaby
Page, Bill
2006-11-08 00:39:27 UTC
Permalink
Post by Ralf Hemmecke
...
Post by Gabriel Dos Reis
| 3) axiom.bib.tex file contains 10 file names with
| unescaped underscores inside.
...
Post by Gabriel Dos Reis
For problem (3), I'm awaiting for input from others.
The drastic way... Remove axiom.bib.pamphlet (from which probably
axiom.bib.tex was generated). That is not really a .bib file. It
is a collection of filenames. And I would rather see that the
translated documentation has hyperlinks instead of references to
a "bibliography" that consists of filenames.
If someone thinks that axiom.bib.pamphlet is a file in good
LP style, I have not understood what LP means.
I support Ralf's view. The axiom.bib.pamphlet file doesn't make
any sense to me.
Post by Ralf Hemmecke
Underscores would be no problem at all if filenames where
properly tagged. Note that there is a latex package called url
(/usr/share/texmf/tex/latex/misc/url.sty) which provides a \path
command. Together with hyperref one can turn that also into
hyperlinks.
I like this idea but I think it might need more thought. How do
we want to present this large collection of Axiom documentation
files to a user? How will they navigate? How will this interact,
or will it interact with hyperdoc? Will they be searchable? What
is better, dvi or pdf? Etc.

Regards,
Bill Page.
Ralf Hemmecke
2006-11-08 00:58:41 UTC
Permalink
Post by Page, Bill
Post by Ralf Hemmecke
Underscores would be no problem at all if filenames where
properly tagged. Note that there is a latex package called url
(/usr/share/texmf/tex/latex/misc/url.sty) which provides a \path
command. Together with hyperref one can turn that also into
hyperlinks.
I like this idea but I think it might need more thought. How do
we want to present this large collection of Axiom documentation
files to a user? How will they navigate? How will this interact,
or will it interact with hyperdoc? Will they be searchable? What
is better, dvi or pdf? Etc.
I have a simple suggestion. Forget the Axiom user for a moment. First we
need to have good documentation for developers. A user probably cares
mose about the "algebra" subdirectory. I don't care too much about
interaction with hyperdoc and such. The current pamphlet -> dvi way also
does not involve hyperdoc.

My dream would be to have for each bigger unit one document (which is
.dvi, .pdf or .html -- you have already seen in ALLPROSE that it is not
so hard to generate different output formats). By "bigger unit" I
approximately mean the subdirectories in src. Such a document would be
similar to the ALLPROSE stuff -- hyperlinks here and there.

The question is whether other Axiom developers would like it or whether
there are other suggestions we could agree upon. It's a lot of effort
after all. And before I invest time there I would rather like to know in
advance what other peoples dreams are. So that I don't have to throw
away my stuff in the end.

Ralf
Gabriel Dos Reis
2006-11-08 02:39:47 UTC
Permalink
Ralf Hemmecke <***@hemmecke.de> writes:

| >> Underscores would be no problem at all if filenames where
| >> properly tagged. Note that there is a latex package called url
| >> (/usr/share/texmf/tex/latex/misc/url.sty) which provides a \path
| >> command. Together with hyperref one can turn that also into
| >> hyperlinks.
|
| > I like this idea but I think it might need more thought. How do
| > we want to present this large collection of Axiom documentation
| > files to a user? How will they navigate? How will this interact,
| > or will it interact with hyperdoc? Will they be searchable? What
| > is better, dvi or pdf? Etc.
|
| I have a simple suggestion. Forget the Axiom user for a moment. First
| we need to have good documentation for developers. A user probably

I care a lot about users. I have no chance of attracting a developer
if I cannot first get him as a user.

| cares mose about the "algebra" subdirectory. I don't care too much
| about interaction with hyperdoc and such. The current pamphlet -> dvi
| way also does not involve hyperdoc.
|
| My dream would be to have for each bigger unit one document (which is
| .dvi, .pdf or .html -- you have already seen in ALLPROSE that it is
| not so hard to generate different output formats). By "bigger unit" I
| approximately mean the subdirectories in src. Such a document would be
| similar to the ALLPROSE stuff -- hyperlinks here and there.
|
| The question is whether other Axiom developers would like it or
| whether there are other suggestions we could agree upon. It's a lot of
| effort after all. And before I invest time there I would rather like
| to know in advance what other peoples dreams are. So that I don't have
| to throw away my stuff in the end.

I very much like hyperlinks pointing to sections in other files.
I really disliuke duplicating documentation for no good reasons.
But, I don't know what ALLPROSE looks like in practice (sorry, I
cannot do everything...)

-- Gaby
Martin Rubey
2006-11-08 08:00:03 UTC
Permalink
I very much like hyperlinks pointing to sections in other files. I really
disliuke duplicating documentation for no good reasons. But, I don't know
what ALLPROSE looks like in practice (sorry, I cannot do everything...)
Do you have Axiom with Aldor support installed, or, at least Aldor installed?

Do you have $ALDORROOT set?



The following should not take more than 15 minutes. If it takes longer, drop me
an email...

Go to Ralf's webpage and download packaged-allprose

http://www.hemmecke.de/aldor/packaged-allprose.tar.gz

-------------------------------------------------------------------------------

tar -xzf packaged-allprose.tar.gz

cd packaged-allprose

notangle -t8 Makefile.nw > Makefile

make

## you should now have three new shiny things: aldorextio aldorunit (these are
## due to Christian Aistleitner) and allprose (due to Ralf)

cd ~

svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat

cd combinat/trunk/combinat

notangle -t8 Makefile.nw > Makefile


## make the documentation

make dvi

## if tex4ht is installed

make html

## or, if you actually want to use it:

make check



### or, if you prefer to use it from within axiom
### WARNING: HIGHLY EXPERIMENTAL

cd ~/combinat/branches/axiom-port/combinat

notangle -t8 Makefile.nw > Makefile

make VARIANTSTOBUILD=axiom

cd src

axiom

)lib csaxal csstream csseries csspexpr csspecies csparse csinterp

s: String := "Plus(SingletonSpecies, Times(Self, Self))"

BinTree ==> Interpret([parse s], IntegerLabel)

l: SetSpecies IntegerLabel := set [1,2,3]

trees := structures(l)$BinTree

[retract partialNext! trees for i in 1..12]

## enjoy.


-------------------------------------------------------------------------------

Martin
Gabriel Dos Reis
2006-11-08 12:53:50 UTC
Permalink
Martin Rubey <***@univie.ac.at> writes:

| Gabriel Dos Reis <***@integrable-solutions.net> writes:
|
| > I very much like hyperlinks pointing to sections in other files. I really
| > disliuke duplicating documentation for no good reasons. But, I don't know
| > what ALLPROSE looks like in practice (sorry, I cannot do everything...)
|
| Do you have Axiom with Aldor support installed, or, at least Aldor installed?

I don't have Axiom support on the machine I usually work with.

-- Gaby
Martin Rubey
2006-11-08 13:17:20 UTC
Permalink
Post by Gabriel Dos Reis
|
| > I very much like hyperlinks pointing to sections in other files. I really
| > disliuke duplicating documentation for no good reasons. But, I don't know
| > what ALLPROSE looks like in practice (sorry, I cannot do everything...)
|
| Do you have Axiom with Aldor support installed, or, at least Aldor installed?
I don't have Axiom support on the machine I usually work with.
That means, you have axiom and aldor installed, but they don't work together
yet?

Well, meanwhile Ralf gave you an easier way to get an impression for
ALLPROSE. Just in case you want Axiom to support Aldor on your machine, here
are the instructions:

http://wiki.axiom-developer.org/AldorForAxiom

Although I guess that you know that anyway.

BTW, is it planned to have a debian package with support for Aldor built-in?



Martin
Gabriel Dos Reis
2006-11-08 14:46:06 UTC
Permalink
Martin Rubey <***@univie.ac.at> writes:

| Gabriel Dos Reis <***@integrable-solutions.net> writes:
|
| > Martin Rubey <***@univie.ac.at> writes:
| >
| > | Gabriel Dos Reis <***@integrable-solutions.net> writes:
| > |
| > | > I very much like hyperlinks pointing to sections in other files. I really
| > | > disliuke duplicating documentation for no good reasons. But, I don't know
| > | > what ALLPROSE looks like in practice (sorry, I cannot do everything...)
| > |
| > | Do you have Axiom with Aldor support installed, or, at least Aldor installed?
| >
| > I don't have Axiom support on the machine I usually work with.
^^^^^

sorry, that should read "Aldor".

| That means, you have axiom and aldor installed, but they don't work together
| yet?

no, that I don't have Aldor (or course, Axiom is installed).

| Well, meanwhile Ralf gave you an easier way to get an impression for
| ALLPROSE.

Yes.

[...]

| BTW, is it planned to have a debian package with support for Aldor built-in?

I don't know. I've decided not to spend too much time on Aldor as far
as it is free only in promises. I'm concentratig on Axiom and SPAD.

-- Gaby
Ralf Hemmecke
2006-11-08 09:07:50 UTC
Permalink
| >> Underscores would be no problem at all if filenames where | >>
properly tagged. Note that there is a latex package called url | >>
(/usr/share/texmf/tex/latex/misc/url.sty) which provides a \path | >>
command. Together with hyperref one can turn that also into | >>
hyperlinks. | | > I like this idea but I think it might need more
thought. How do | > we want to present this large collection of Axiom
documentation | > files to a user? How will they navigate? How will
this interact, | > or will it interact with hyperdoc? Will they be
searchable? What | > is better, dvi or pdf? Etc. | | I have a simple
suggestion. Forget the Axiom user for a moment. First | we need to
have good documentation for developers. A user probably
I care a lot about users. I have no chance of attracting a developer
if I cannot first get him as a user.
Don't take me too seriously. What I meant was that we cannot do
everything in one stroke. Of course, I care about documentation for the
end user. All of the Axiom source code should become documentation for
an end user. An end user shoul actually just find his/her way quickly to
the section of the documentation in which he/she is interested. But, in
fact, even the documentation for developers should be written in a form
that makes it easy for "users of axiom" to become "developers of axiom".
So, in fact, I don't actually distinguish too much between developer and
end user. It's just that they will read different parts.

What I care about is that the overall documentation method should be in
some sense simple. And currently we have the Axiom-book for end-users
but we have a mess for developers.

I hope that makes my intentions a bit clearer.
I very much like hyperlinks pointing to sections in other files. I
really disliuke duplicating documentation for no good reasons. But, I
don't know what ALLPROSE looks like in practice (sorry, I cannot do
everything...)
Understood.

For a 30 seconds impression click on

http://www.hemmecke.de/aldor/allprose/

Maybe that gives you a feeling of what I would like to see also for
axiom. (.pdf and .dvi basically look the same.)
And this is *not* just one .nw file (or .pamphlet if you like). That are
many. So in fact, it isn't really a problem to have file.c.pamphlet and
file.h.pamphlet separate, since the workflow would be: Read the .dvi and
if you find something that you want to edit, click there and suddenly
your editor opens the right file. In some sense that is like Tim's idea
of having a huge .pamphlet file, only that I have not. Only the
generated (more human readable) format is one file. The actual sources
are organised so that the build process gets simple.
Also note that all newer dvi viewers allow to search inside .dvi files.
You can forget about grep.

Ralf
Gabriel Dos Reis
2006-11-08 12:57:27 UTC
Permalink
Ralf Hemmecke <***@hemmecke.de> writes:

[...]

| I hope that makes my intentions a bit clearer.

It does; thanks!

| > I very much like hyperlinks pointing to sections in other files. I
| > really disliuke duplicating documentation for no good reasons. But, I
| > don't know what ALLPROSE looks like in practice (sorry, I cannot do
| > everything...)
|
| Understood.
|
| For a 30 seconds impression click on
|
| http://www.hemmecke.de/aldor/allprose/

OK, thanks.

-- Gaby
Gabriel Dos Reis
2006-11-08 02:37:06 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

| On Tuesday, November 07, 2006 7:05 PM Ralf Hemmecke wrote:
| >
| > Waldek wrote:
| > ...
| > > | 3) axiom.bib.tex file contains 10 file names with
| > > | unescaped underscores inside.
| > ...
| > Gaby wrote:
| > > For problem (3), I'm awaiting for input from others.
| >
| > The drastic way... Remove axiom.bib.pamphlet (from which probably
| > axiom.bib.tex was generated). That is not really a .bib file. It
| > is a collection of filenames. And I would rather see that the
| > translated documentation has hyperlinks instead of references to
| > a "bibliography" that consists of filenames.
| >
| > If someone thinks that axiom.bib.pamphlet is a file in good
| > LP style, I have not understood what LP means.
|
| I support Ralf's view. The axiom.bib.pamphlet file doesn't make
| any sense to me.

So, what concretly do you propose as course of action?

| > Underscores would be no problem at all if filenames where
| > properly tagged. Note that there is a latex package called url
| > (/usr/share/texmf/tex/latex/misc/url.sty) which provides a \path
| > command. Together with hyperref one can turn that also into
| > hyperlinks.
| >
|
| I like this idea but I think it might need more thought. How do
| we want to present this large collection of Axiom documentation
| files to a user?

You are right that the need for presenting the collection of Axiom
source files are references will not go away by axiom.bib.pamphlet.
We still need to links to references sections in other files.

| How will they navigate? How will this interact,
| or will it interact with hyperdoc? Will they be searchable? What
| is better, dvi or pdf? Etc.

PDF has my vote.

-- Gaby
Page, Bill
2006-11-08 00:55:19 UTC
Permalink
Post by Ralf Hemmecke
...
I agree that LP suggests to think in terms of logical units for
humans, but on the other hand I am still a bit old-fashioned
(and maybe also human), since I would have hard times to look
in the file system for the place of a particular file (which is
hidden in a .pamphlet file with another name). In that sense
pamphlet files would not fit me as a human.
Maybe I should change ... ;-)
:-) That is definitely not "new think". There are many places
in the Axiom source where you already must do this, e.g. the
src/algebra/*.spad.pamphlet files.

Anyway, I think that if you are reading the .dvi file you will
already know the names of the generated files. If you are a
developer working directly with the generated files then I
think you would know enough to check the Makefile to see how
this file is generated. But it might well be convenient if there
was a nice wrapper for

grep '<<whatever.h>>=' *.pamphlet

along the lines of what Martin Rubey wrote for the
*.spad.pamphlet files.

Regards,
Bill Page.
Page, Bill
2006-11-08 03:39:09 UTC
Permalink
Post by Gabriel Dos Reis
| >
| > ...
| > > | 3) axiom.bib.tex file contains 10 file names with
| > > | unescaped underscores inside.
| > ...
| > > For problem (3), I'm awaiting for input from others.
| >
| > The drastic way... Remove axiom.bib.pamphlet
| ...
|
| I support Ralf's view. The axiom.bib.pamphlet file doesn't make
| any sense to me.
So, what concretly do you propose as course of action?
I propose that we remove axiom.bib.pamphlet.

There is no axiom.bib.tex as far as I can tell - only axiom.bib.

But the idea of including citations to pamphlet files seems ill-
conceived to me. There is no documentation in the axiom.bib.pamphlet
file itself but in src/doc/Makefile.pamphlet we can read:

--------

\section{The bibtex stanza}
Axiom pamphlet files have citations. We collect all of the
pamphlet file citations into this one file so we have a standard
place and format for bibliographic references.

Citations of pamphlet files which are local are generally by the
name. For example, [[asq.c.pamphlet]] would be cited using
[[\cite{asq.c}]].

--------

But as far as I can tell this method is not actually used in any
other pamphlet file. Looking at the contents of axiom.bib I see
many non-unique entries.Further, I don't see how this wculd work
in the case where there are multiple root code chunks in a single
pamphlet file (e.g. algebra/*.spad.pamphlet).

I think that in future updates to the pamphlet files we should
encourage the use hyperref where relevant to include hypertex
links directly in the dvi/pdf files. See for example:

http://wiki.axiom-developer.org/book--main--1/Endpaper3

which contains hyperlinks in the graphics.

Regards,
Bill Page.
Ralf Hemmecke
2006-11-08 09:20:48 UTC
Permalink
Post by Gabriel Dos Reis
| > The drastic way... Remove axiom.bib.pamphlet
Sorry, I take that back. Only remove (most of) the (file referencing)
content.

I am very much in favour of having a central .bib file (or a collection
of them in a central place), but with actual references to papers and
books. Even better would be what once was in discussion... Online
documentation should directly link a reference in text to the actual
paper if that is somewhere on the internet. But I guess we also care
about printed versions so a .bib file is not such a bad idea in the end.
We should however care about uniqe bibkeys, that would avoid
duplications of entries in axiom.bib.

Maybe some day .bib files go away since there would be a central
database of references on the internet and one only has to know a unique
key into that database to extract all relevant information needed for a
printed version. But up to then .bib files are of some use.

Ralf
Martin Rubey
2006-11-08 09:31:44 UTC
Permalink
I am very much in favour of having a central .bib file (or a collection of
them in a central place), but with actual references to papers and
books. Even better would be what once was in discussion... Online
documentation should directly link a reference in text to the actual paper if
that is somewhere on the internet.
If you use the right style file, you get the links to the articles quite
easily. Look for example, at

http://front.math.ucdavis.edu/math.CO/0604140

(click on pdf or dvi and go to the very last page)

In fact, in my community this is standard now.

But I guess you know that?

Martin
C Y
2006-11-08 13:10:20 UTC
Permalink
Post by Ralf Hemmecke
Post by Gabriel Dos Reis
| > The drastic way... Remove axiom.bib.pamphlet
Sorry, I take that back. Only remove (most of) the (file referencing)
content.
I am very much in favour of having a central .bib file (or a collection
of them in a central place), but with actual references to papers and
books. Even better would be what once was in discussion... Online
documentation should directly link a reference in text to the actual
paper if that is somewhere on the internet. But I guess we also care
about printed versions so a .bib file is not such a bad idea in the end.
We should however care about uniqe bibkeys, that would avoid
duplications of entries in axiom.bib.
Maybe some day .bib files go away since there would be a central
database of references on the internet and one only has to know a unique
key into that database to extract all relevant information needed for a
printed version. But up to then .bib files are of some use.
I did some work earlier on the bibliography question and got pretty
close to something I would be happy with, it is still available on my
Axiom portal site:

http://portal.axiom-developer.org/Members/starseeker/axiombibliographysystem.tar.gz/file_view
http://portal.axiom-developer.org/Members/starseeker/axiombibliography.pdf/file_view

I suppose the pdf structuring part is of less interest to most, but I
also was able to use the ToC style files to generate links from the
bibliography to some of the online sources (not all - more work is
needed for sources Axiom would want).

Also, this bib file allows a comments section on each source. I would
suggest this a a preferable way to have a "literate" bib file - it
remains a valid bib file, can be referenced directly by all documents
without any complications, and can still include comments on the
document by us - which to me should be sort of the best of all possible
worlds. If it MUST be a pamphlet I would suggest that the noweb part
generate, if possible, the simple file to incorporate the bib file and
explain our conventions, plus the bib file itself. I doubt any purpose
would be served by adding in the bib entries as "source code" in a
document, but of course I may be wrong.

Cheers,
CY
Gabriel Dos Reis
2006-11-08 13:01:08 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

[...]

| I think that in future updates to the pamphlet files we should
| encourage the use hyperref where relevant to include hypertex
| links directly in the dvi/pdf files.

That makes sense.

-- Gaby
Page, Bill
2006-11-08 04:06:55 UTC
Permalink
Post by Ralf Hemmecke
...
I have a simple suggestion. Forget the Axiom user for a
moment. First we need to have good documentation for developers.
A user probably cares most about the "algebra" subdirectory.
I don't care too much about interaction with hyperdoc and such.
The current pamphlet -> dvi way also does not involve hyperdoc.
I think perhaps the pamplet files should interact with hyperdoc.
Or rather hyperdoc should be replaced with a web browser interface
that would integrate with the dvi/pdf files including hyperlinks
between them.
Post by Ralf Hemmecke
My dream would be to have for each bigger unit one document
(which is .dvi, .pdf or .html -- you have already seen in
ALLPROSE that it is not so hard to generate different output
formats). By "bigger unit" I approximately mean the subdirectories
in src. Such a document would be similar to the ALLPROSE stuff --
hyperlinks here and there.
The question is whether other Axiom developers would like it
or whether there are other suggestions we could agree upon. It's
a lot of effort after all. And before I invest time there I would
rather like to know in advance what other peoples dreams are. So
that I don't have to throw away my stuff in the end.
Ralf, I appreciate that you have put a lot of work into ALLPROSE
but when I look at it I see a tool that seems more suitable to
the user/developer of Axiom library code then to the general build
environment for Axiom. It that sense I see it as part of the type
of web browser interface that I referred to above.

But for development *my* dream really is not just bigger units but
rather a single outline for the entire Axiom project such as is
possible in Leo. This outline allows you to navigate freely just
like navigating in the src directory right down to the "chunk"
level with quick access to generated documentation, source code
and the build environment. The outline is like a tree structure
but includes "cloning" which actually creates a lattice and makes
it possible to create different "views" of the same information
without duplicating content.

Regards,
Bill Page.
Ralf Hemmecke
2006-11-08 09:53:47 UTC
Permalink
I think perhaps the pamplet files should interact with hyperdoc. Or
rather hyperdoc should be replaced with a web browser interface that
would integrate with the dvi/pdf files including hyperlinks between
them.
I am more in favour of any webbrowser than hyperdoc. Hyperdoc looks old.
The contents is what we should care about. And then I'd like to see a
nice help system. I think Mathematica has quite a reasonable one. It
also links to the Mathematica book. I am not an expert in that but I
guess, we can achieve it also in a normal webbrowser. The Eclipse
documenation would be an example.

And yes, I like some features of hyperdoc. I like to click on a category
or a domain and see its documentation and I can ask a category for all
domains that implement this category. That is sometimes quite helpful.
So in a replacement of hyperdoc must be as "active" as hyperdoc is now.
Post by Ralf Hemmecke
My dream would be to have for each bigger unit one document (which
is .dvi, .pdf or .html -- you have already seen in ALLPROSE that it
is not so hard to generate different output formats). By "bigger
unit" I approximately mean the subdirectories in src. Such a
document would be similar to the ALLPROSE stuff -- hyperlinks here
and there.
The question is whether other Axiom developers would like it or
whether there are other suggestions we could agree upon. It's a lot
of effort after all. And before I invest time there I would rather
like to know in advance what other peoples dreams are. So that I
don't have to throw away my stuff in the end.
Ralf, I appreciate that you have put a lot of work into ALLPROSE but
when I look at it I see a tool that seems more suitable to the
user/developer of Axiom library code then to the general build
environment for Axiom.
OK, maybe I should say half-ALLPROSE. When I speak about ALLPROSE in the
context of Axiom, it makes no sense to carry over all of the build
procedures that are in there. Only that related to documentation is
perhaps relevant at the moment for Axiom. It basically concerns some
.sty files and some conventions of how documentation should be written.
It that sense I see it as part of the type of
web browser interface that I referred to above.
But for development *my* dream really is not just bigger units but
rather a single outline for the entire Axiom project such as is
possible in Leo. This outline allows you to navigate freely just like
navigating in the src directory right down to the "chunk" level with
quick access to generated documentation, source code and the build
environment. The outline is like a tree structure but includes
"cloning" which actually creates a lattice and makes it possible to
create different "views" of the same information without duplicating
content.
Bill, believe me, I am actually on your side. But there are a few problems.

First. I did not find Leo too attractive to me since it does not
actually enforce an LP style.

Second. Although I like this idea with different views (oh that would be
the "crystal idea" right?) on code+documentation, it becomes harder to
actually write the documentation so that it stays human readable. The
question namely is: What are the smallest resonable units that can be
moved around and included in other views. If you change the content of
one unit, it also has influence on another "view" where this unit is used.

So my current position is a bit hesitant although I like this
"multiple-views" thing.

Ralf
C Y
2006-11-08 12:58:37 UTC
Permalink
Post by Ralf Hemmecke
I think perhaps the pamplet files should interact with hyperdoc. Or
rather hyperdoc should be replaced with a web browser interface that
would integrate with the dvi/pdf files including hyperlinks between
them.
I am more in favour of any webbrowser than hyperdoc. Hyperdoc looks old.
The contents is what we should care about.
Agreed.
Post by Ralf Hemmecke
And then I'd like to see a
nice help system. I think Mathematica has quite a reasonable one. It
also links to the Mathematica book. I am not an expert in that but I
guess, we can achieve it also in a normal webbrowser. The Eclipse
documenation would be an example.
I think the help system is extremely important, especially in such a
complex tool as Axiom. Linking to the book will be somewhat tricky
though - we need to think carefully about what to link to for any given
type of help request, and possibly even write documentation with such
requests in mind in order to help make it more "searchable". Whether
this meshes well with book style documentation I am not yet sure.
Post by Ralf Hemmecke
And yes, I like some features of hyperdoc. I like to click on a category
or a domain and see its documentation and I can ask a category for all
domains that implement this category. That is sometimes quite helpful.
Definitely agree!
Post by Ralf Hemmecke
So in a replacement of hyperdoc must be as "active" as hyperdoc is now.
I don't think that's in doubt. Once we achieve ANSI lisp compliance
there are a number of interesting things that could be attempted in this
department. One might be to explore the idea of using Lisp based http
server tools as a general communications protocol between all front ends
- things like Uncommon Web http://common-lisp.net/project/ucw/ and
http://www.cliki.net/araneida may prove useful in that respect. Kai and
I talked about this briefly on IRC - one option might be to use araneida
as the "gateway" part of the client-server system. Different clients
might not care to speak html, of course, but I doubt if there is any
fundamental reason we couldn't send arbitrary data down the pipe and
have araneida farm it out to the appropriate input handler. I still
think McCLIM offers some very intriguing potential for an Axiom
interface in such a framework. Anyway, interesting possibilities.
Post by Ralf Hemmecke
Bill, believe me, I am actually on your side. But there are a few problems.
First. I did not find Leo too attractive to me since it does not
actually enforce an LP style.
Perhaps that could be changed? Or is the design of the tool not
compatible with such a requirement? I do like the idea of the tools
enforcing the literate programming paradigm - it's too easy to get
sidetracked. (Of course, we're going to need several hour long
"training videos" on how to work with the Axiom source code, sorta like
that SLIME tutorial movie.)
Post by Ralf Hemmecke
Second. Although I like this idea with different views (oh that would be
the "crystal idea" right?) on code+documentation, it becomes harder to
actually write the documentation so that it stays human readable.
I do have to agree there.
Post by Ralf Hemmecke
The
question namely is: What are the smallest resonable units that can be
moved around and included in other views. If you change the content of
one unit, it also has influence on another "view" where this unit is used.
I think the end consequence of such a method is that we will have to
write very small, "self contained" documentation for units that will be
used multiple places, and then "plug them in" to larger components. I'm
dubious that discrete units below the scale of an academic paper will
prove really useful, but at a minimum it should be possible to (say)
document various TeX output formatting code (let's say I add knowledge
of siunits in a unit pamphlet, and someone else adds some chemistry
specific LaTeX output methods in a chemistry pamphlet) as part of the
original pamphlet, and then use a different view to collect all of the
various TeX output methods into a single view that could produce one
document describing all TeX output methods. In this fashion, a general
change to all TeX output routines (for a new TeX distribution, say)
could be carried out very rapidly across many distinct categories,
without risk of "missing one" due to having to look at dozens or
hundreds of individual documents to check for special TeX output routines.

It may prove that the only really useful unit is the code chunk itself,
with the views being documents into which they plug in. But if we could
as a chunk we were editing what views (documents) it was included in,
and check each of them before we commit the change, we could at least
keep everything consistent with a high degree of confidence and convenience.
Post by Ralf Hemmecke
So my current position is a bit hesitant although I like this
"multiple-views" thing.
I think it needs exploring, which I suppose means I need to take another
good hard run at Leo. Such a setup also means we would need to "chunk"
the whole source code pretty much at the outset, and then fit in the
pieces - correct? That's a mean job even without adding documentation,
but I suppose it would be a benefit in any case.

Cheers,
CY
Page, Bill
2006-11-08 05:13:36 UTC
Permalink
Post by Page, Bill
...
I propose that we remove axiom.bib.pamphlet.
There is no axiom.bib.tex as far as I can tell - only axiom.bib.
But the idea of including citations to pamphlet files seems ill-
conceived to me. There is no documentation in the axiom.bib.pamphlet
--------
\section{The bibtex stanza}
Axiom pamphlet files have citations. We collect all of the
pamphlet file citations into this one file so we have a standard
place and format for bibliographic references.
Citations of pamphlet files which are local are generally by the
name. For example, [[asq.c.pamphlet]] would be cited using
[[\cite{asq.c}]].
--------
I see also \cite mentioned here in the FAQ file:

--------

FAQ 11: How do I add a new pamphlet file
...

You must also modify src/doc/axiom.bib.pamphlet to include
the file. Axiom uses bibtex to cross-reference the various
pamphlet files. The normal method of citing a file involves
just using the name, for example \cite{asq.c} will build
a citation to the ./src/etc/asq.c.pamphlet file.

You must include the following two lines in your pamphlet file:

\bibliographystyle{plain}
\bibliography{axiom}

---------
Post by Page, Bill
But as far as I can tell this method is not actually used in any
other pamphlet file. Looking at the contents of axiom.bib I see
many non-unique entries. Further, I don't see how this would work
in the case where there are multiple root code chunks in a single
pamphlet file (e.g. algebra/*.spad.pamphlet).
Am I wrong about this?

Regards,
Bill Page.
Page, Bill
2006-11-08 11:03:10 UTC
Permalink
Post by Martin Rubey
I pressed C-c C-c in gnus, not in the pamphlet... Sorry,
continuation below
What is 'gnus'?
Post by Martin Rubey
Post by Martin Rubey
Post by Ralf Hemmecke
What speaks so much against just adding .tex?
I'd also speak in *favour* of simply adding .tex. It makes
### The following is only for those who use auctex in emacs
for latexing!) ###
I use auctex and added a dead simple "document" command.
Thus I can visit a pamphlet file (for example, by clicking in
HyperDoc on INT.spad)
make some changes
press
C-c C-c
enter document
What does your 'document' command do?

I presume that it runs noweave and latex to create the dvi
file?
Post by Martin Rubey
press C-c C-c again
auctex proposes "View". But of course, the parameter is wrong,
it is
name.pamphlet.dvi
instead of
name.dvi
Why does emacs simply assume .dvi should be appended? Is this
because it does not know that .pamphlet files create .dvi
files? I presume that if the file ends in .tex then the
parameter that emacs proposes would not be

name.tex.dvi

which would be wrong in most cases.

Perhaps you can somehow configure emacs so that .pamphlet is
similar to .tex as an extension and should be ignored when
proposing the parameter for tex-view?
Post by Martin Rubey
--------------------------------------------------------------
I fail to see a reason why simply adding the tex is a bad idea.
But very often in this Makefile business I only know half of
the story, so please don't be angry with me.
I do not think "anger" would be appropriate here... :-)

I would give the following reasons why it is bad:

1) All other programs that I can think of that process an
input file with a given extension, generate output files
by replacing the extension with one appropriate to the
output. E.g.

latex name.tex --> name.dvi
dvipdfm name.dvi --> name.pdf

In latex this happens even if the extension is not .tex

latex name.pamphlet --> name.dvi

It would be very strange to see

latex name.tex --> name.tex.dvi
dvipdfm name.tex.dvi --> name.tex.dvi.pdf

wouldn't it?

2) File names with more than one . are may not be portable to
non-linux file systems - although the only ones I can think of
are old and unlikely candidates for Axiom.

3) Files with unnecessarily long names are more awkward to use.

Ok I admit that reasons 2) and 3) are not very strong reasons...

Regards,
Bill Page.
Martin Rubey
2006-11-08 11:15:25 UTC
Permalink
Post by Page, Bill
Post by Martin Rubey
I pressed C-c C-c in gnus, not in the pamphlet... Sorry,
continuation below
What is 'gnus'?
the mailer/newsreader I use...

Thanks for your explanations, I think I understand now.

Martin
Ralf Hemmecke
2006-11-08 11:29:29 UTC
Permalink
Post by Page, Bill
1) All other programs that I can think of that process an
input file with a given extension, generate output files
by replacing the extension with one appropriate to the
output. E.g.
latex name.tex --> name.dvi
dvipdfm name.dvi --> name.pdf
In latex this happens even if the extension is not .tex
latex name.pamphlet --> name.dvi
OK, that is the common state.
Post by Page, Bill
It would be very strange to see
latex name.tex --> name.tex.dvi
dvipdfm name.tex.dvi --> name.tex.dvi.pdf
wouldn't it?
Of course.
Post by Page, Bill
2) File names with more than one . are may not be portable to
non-linux file systems - although the only ones I can think of
are old and unlikely candidates for Axiom.
That is an argument. But perhaps for all those of us who are not so
familiar with non-Linux, it would be more helpful to say which systems
these are. The only system I know would be DOS. But then forget about
the .pamphlet extension. You only have 3 characters. ;-)

Anything else that cannot handle 2 dots or long filenames?
Post by Page, Bill
3) Files with unnecessarily long names are more awkward to use.
Ok I admit that reasons 2) and 3) are not very strong reasons...
Not even 1) is a reason. Why do you believe one can say

make dvi

in ALLPROSE and then say

xdvi myalps.dvi

to get the whole documentation although I have the convention
notangle removes .nw
noweave adds .tex (result is .nw.tex)
?

There will never be generated anything else than one dvi file. And I
don't understand, why people care so much about the names of
intermediate files. You can remove .nw.tex files and no harm is done. If
make would already remove them, one would not even see what strange
things are done under the hat.
But that naming scheme simplifies the understanding of the system (only
in my opinion, of course). One doesn't have to rename axiom.sty.pamphlet
to axiom-sty.pamphlet.

So the only reason I see not to just add ".tex" would be portability.
But which are systems we want to build Axiom on that cannot handle two dots?

Ralf
Gabriel Dos Reis
2006-11-08 13:12:09 UTC
Permalink
Ralf Hemmecke <***@hemmecke.de> writes:

[...]

| That is an argument. But perhaps for all those of us who are not so
| familiar with non-Linux, it would be more helpful to say which systems
| these are. The only system I know would be DOS. But then forget about
| the .pamphlet extension. You only have 3 characters. ;-)

Yes. My question is how serious Axiom takes portability?
Notice that the notion of filename limitations enshrines in the user
interface that I really dislike.

[...]

| There will never be generated anything else than one dvi file. And I
| don't understand, why people care so much about the names of
| intermediate files.

if you don't understand why you care, then I'm confused :-)

[...]

| (only in my opinion, of course). One doesn't have to rename
| axiom.sty.pamphlet to axiom-sty.pamphlet.

Yes. This problem has many roots. Part of it is that
build-improvements extracts the TeX file in the same directory as it
latexs it. The problem can be papered over in many different way:
(1) add .tex unconditionally.
(2) replace .pamphlet with .tex and pay attention
(3) extract to a different directory
(4) find a btter solution.

-- Gaby
Ralf Hemmecke
2006-11-08 22:21:46 UTC
Permalink
Post by Gabriel Dos Reis
Yes. This problem has many roots. Part of it is that
build-improvements extracts the TeX file in the same directory as it
(1) add .tex unconditionally.
(2) replace .pamphlet with .tex and pay attention
(3) extract to a different directory
(4) find a btter solution.
(3) is not an option, since when you compile axiom.sty.tex -->
axiom.sty.dvi then it does not matter whether axiom.sty is visible or
not. \usepackage will choose the wrong file.

Ralf
Gabriel Dos Reis
2006-11-08 23:38:35 UTC
Permalink
Ralf Hemmecke <***@hemmecke.de> writes:

| > Yes. This problem has many roots. Part of it is that
| > build-improvements extracts the TeX file in the same directory as it
| > latexs it. The problem can be papered over in many different way:
| > (1) add .tex unconditionally.
| > (2) replace .pamphlet with .tex and pay attention
| > (3) extract to a different directory
| > (4) find a btter solution.
|
| (3) is not an option,

but that is what silver does.

| since when you compile axiom.sty.tex -->
| axiom.sty.dvi then it does not matter whether axiom.sty is visible or
| not. \usepackage will choose the wrong file.

No. It depends on where you call LaTeX from and the value of TEXINPUTS.

-- Gaby
Gabriel Dos Reis
2006-11-08 13:05:05 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

| On Wednesday, November 08, 2006 3:11 AM Martin Rubey wrote:
| >
| > I pressed C-c C-c in gnus, not in the pamphlet... Sorry,
| > continuation below
| >
|
| What is 'gnus'?

News and mail reader: That is what I've been for ages now, to read
bpth newsgroups and mails, and therefore write codes too :-)

-- Gaby
Waldek Hebisch
2006-11-08 11:52:44 UTC
Permalink
Post by Gabriel Dos Reis
[...]
| However pamphlet files with multiple chunks interact badly with
| the make dependency processing since changing or adding a single
| chunk in a pamphlet file triggers re-extraction of all files
| dependent on that pamphlet and subseqent dependent make processing.
Like for most (all?) generated files, there is a way out within the
GNU build system: change a file only if its content really changed.
Use the move-if-change script.
It is on the list of things to do for build-improvements.
move-if-change solves only part of the problem: if you have a file
which has dependency newer than the file itself make will try
to rebuild the file on _every_ run. Even if extraction is not very
expensive the cost of extracting and then discarding exctracted version
may quickly accumulate. AFAICS within make paradigm one would need
_two_ times: modification time and update time. File needs update
if its update time is before modification time of one of its dependencies.
However, if update do not change file content only update time changes,
modification time would stay the same. But I do not know of a make like
tool which offers such model (possibly because normal filesystems do
not provide a way to store update time).
--
Waldek Hebisch
***@math.uni.wroc.pl
Page, Bill
2006-11-08 12:04:00 UTC
Permalink
Oh, so much email over such a simple thing ... :-(
Post by Ralf Hemmecke
...
Post by Page, Bill
It would be very strange to see
latex name.tex --> name.tex.dvi
dvipdfm name.tex.dvi --> name.tex.dvi.pdf
wouldn't it?
Of course.
Post by Page, Bill
2) File names with more than one . are may not be portable to
non-linux file systems - although the only ones I can think of
are old and unlikely candidates for Axiom.
That is an argument. But perhaps for all those of us who are not so
familiar with non-Linux, it would be more helpful to say which systems
these are. The only system I know would be DOS. But then forget about
the .pamphlet extension. You only have 3 characters. ;-)
Anything else that cannot handle 2 dots or long filenames?
I think older CDrom formats also had this sort of limitation

http://en.wikipedia.org/wiki/ISO_9660

and still cause some trouble in rare cases with very long file
names.
Post by Ralf Hemmecke
Post by Page, Bill
3) Files with unnecessarily long names are more awkward to use.
Ok I admit that reasons 2) and 3) are not very strong reasons...
Not even 1) is a reason. Why do you believe one can say
make dvi
in ALLPROSE and then say
xdvi myalps.dvi
to get the whole documentation although I have the convention
notangle removes .nw
noweave adds .tex (result is .nw.tex)
?
Good question. If the rule is "add .tex" then the result is

latex myalps.nw.tex --> myalps.nw.dvi

not myalps.dvi. You must be doing something more to hide the .nw.

Your suggestion would require that we use awkwqard names like

xdvi axiom.sty.pamphlet.dvi

No?
Post by Ralf Hemmecke
There will never be generated anything else than one dvi file.
And I don't understand, why people care so much about the names
of intermediate files. You can remove .nw.tex files and no harm
is done. If make would already remove them, one would not even
see what strange things are done under the hat.
I don't think anyone is that worried about internal file names,
but this discussion is about making the makefiles "simpler" and
more obvious, so we do care what goes on under the hat, right?
Using a file name for dvi files that retains the original
.pamphlet extension is not so obvious to me.
Post by Ralf Hemmecke
But that naming scheme simplifies the understanding of the
system (only in my opinion, of course). One doesn't have to
rename axiom.sty.pamphlet to axiom-sty.pamphlet.
In my opinion it is only an accident that axiom.sty.pamphlet
has this name and contains only one root chunk. In general this
is not the case.
Post by Ralf Hemmecke
So the only reason I see not to just add ".tex" would be portability.
But which are systems we want to build Axiom on that cannot
handle two dots?
I would guess: none.

Regards,
Bill Page.
Gabriel Dos Reis
2006-11-08 13:19:10 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

[...]

| Good question. If the rule is "add .tex" then the result is
|
| latex myalps.nw.tex --> myalps.nw.dvi
|
| not myalps.dvi. You must be doing something more to hide the .nw.
Ralf Hemmecke
2006-11-08 22:18:23 UTC
Permalink
Post by Page, Bill
Post by Ralf Hemmecke
Post by Page, Bill
3) Files with unnecessarily long names are more awkward to use.
Ok I admit that reasons 2) and 3) are not very strong reasons...
Not even 1) is a reason. Why do you believe one can say
make dvi
in ALLPROSE and then say
xdvi myalps.dvi
to get the whole documentation although I have the convention
notangle removes .nw
noweave adds .tex (result is .nw.tex)
?
Good question. If the rule is "add .tex" then the result is
latex myalps.nw.tex --> myalps.nw.dvi
not myalps.dvi. You must be doing something more to hide the .nw.
Your suggestion would require that we use awkwqard names like
xdvi axiom.sty.pamphlet.dvi
No?
Wow. I must be doing something wrong. I already question whether I
should use German to get my idea through. English doesn't seem to work. ;-)

OK. Let me repeat. In ALLPROSE and any project that is built with
ALLPROSE there are many files. All of them have the extension .nw
(forget about README, GPL and that). Actually all have a second
extension. So the general form is file.ext.nw. Now my Makefile basically
have the rule that notangle removes .nw and noweave adds .tex.

There is only *one* dvi file that will be produced and *not* one for
every .nw file. So "xdvi axiom.sty.pamphlet.dvi" is absolutely no
argument. One should not even look at something like
axiom.sty.pamphlet.tex, because that is generated and could look like a
big mess --- if you have really looked at files that come out of noweave
you will know that theses files are not for humans even if they are .tex
files.

So now the trick why I don't have myalps.nw.dvi.

The top-level project file is called myalps.tex.nw. Applying my rules
gives myalps.tex and myalps.tex.nw.tex. The first one is just a wrapper
that in shortended form looks like

\documentclass{article}
\usepackage{allprose}
\begin{document}
\author{Ralf Hemmecke}
\title{\xProject{} \LIBRARYVERSION}}
\maketitle
\begin{abstract}
...
\end{abstract}
\hypertarget{sec:Contents}{}\tableofcontents
\input{\projectname.tex.nw}
\end{document}

and that will be latex'ed. As you can see, it's some kind of template.
And my Makefiles make sure that the setup will be such that all other
.nw.tex files will be included into the documentation.


There is another point that speaks against the current practise of
translating each .pamphlet file into one .dvi, namely "literate
programming". Ideas don't just live in one file. That completely misses
the point that there are relations from one part of the system to
another. For example, there should not be 5 Makefile.dvi files lying
around in different directories. Since the build procedure should be
described as a whole.

It would better to describe the interpreter as a whole rather than
producing a .dvi file for each of the 187 files in src/interp.
Tim's approach (if I understood that correctly) is to make *one* huge
.pamphlet file.
My approach is to have as many pamphlet file as you like but produce
*one* human readable document from all of them to describe a _unit_
(i.e. the interpreter).

Eventually, we perhaps want just one document (a web-site, for example)
that describe all of axiom (including the source code). For a web site
the size doesn't matter. But still, there should be some backlinks from
the human-readable format (.dvi) to the actual .pamphlets.
Post by Page, Bill
Post by Ralf Hemmecke
There will never be generated anything else than one dvi file.
And I don't understand, why people care so much about the names
of intermediate files. You can remove .nw.tex files and no harm
is done. If make would already remove them, one would not even
see what strange things are done under the hat.
I don't think anyone is that worried about internal file names,
but this discussion is about making the makefiles "simpler" and
more obvious, so we do care what goes on under the hat, right?
Of course, we care about Makefiles and conventions and such but as long
as that becomes simple, generated file names can be complicated.
Post by Page, Bill
Using a file name for dvi files that retains the original
.pamphlet extension is not so obvious to me.
I hope, this time my English is understandable.
Post by Page, Bill
Post by Ralf Hemmecke
But that naming scheme simplifies the understanding of the
system (only in my opinion, of course). One doesn't have to
rename axiom.sty.pamphlet to axiom-sty.pamphlet.
In my opinion it is only an accident that axiom.sty.pamphlet
has this name and contains only one root chunk. In general this
is not the case.
Post by Ralf Hemmecke
So the only reason I see not to just add ".tex" would be portability.
But which are systems we want to build Axiom on that cannot
handle two dots?
I would guess: none.
I agree. Other opinions concerning filename portability?

Ralf
Gabriel Dos Reis
2006-11-08 23:37:02 UTC
Permalink
Ralf Hemmecke <***@hemmecke.de> writes:

[...]

| There is only *one* dvi file that will be produced and *not* one for
| every .nw file.

Ah, but that is a fundamental distinction between the respective
states of Axiom and your peoject.

| So "xdvi axiom.sty.pamphlet.dvi" is absolutely no argument.

Unfortunately, for Axiom, that is going to be an argument for the
short and mi-term.

[...]

| The top-level project file is called myalps.tex.nw. Applying my rules
| gives myalps.tex and myalps.tex.nw.tex. The first one is just a
| wrapper that in shortended form looks like
|
| \documentclass{article}
| \usepackage{allprose}
| \begin{document}
| \author{Ralf Hemmecke}
| \title{\xProject{} \LIBRARYVERSION}}
| \maketitle
| \begin{abstract}
| ...
| \end{abstract}
| \hypertarget{sec:Contents}{}\tableofcontents
| \input{\projectname.tex.nw}
| \end{document}

Aha! thanks for going through the details.
Now that you've explained the magic, I think I give a higher rank to
axiom-sty.pamphlet :-)

[...]

| It would better to describe the interpreter as a whole rather than
| producing a .dvi file for each of the 187 files in src/interp.

That is absolutely true; but I'm not sure that is solved by
systematically appending .tex.

| Tim's approach (if I understood that correctly) is to make *one* huge
| .pamphlet file.
| My approach is to have as many pamphlet file as you like but produce
| *one* human readable document from all of them to describe a _unit_
| (i.e. the interpreter).

Yes.

-- Gaby
Ralf Hemmecke
2006-11-09 00:06:35 UTC
Permalink
Post by Gabriel Dos Reis
| There is only *one* dvi file that will be produced and *not* one for
| every .nw file.
Ah, but that is a fundamental distinction between the respective
states of Axiom and your peoject.
Of course.
Post by Gabriel Dos Reis
| So "xdvi axiom.sty.pamphlet.dvi" is absolutely no argument.
Unfortunately, for Axiom, that is going to be an argument for the
short and mi-term.
Are you so sure? Where should I branch from for that experiment?

Ralf
Page, Bill
2006-11-08 14:47:47 UTC
Permalink
...
| In my opinion it is only an accident that axiom.sty.pamphlet
| has this name and contains only one root chunk. In general this
| is not the case.
The axiom.sty.pamphlet is inded very special. Its purpose and
its functionality are not the same like any others. We should
not forget that.
I don't understand. In what way is it special? To me it looks
just like any other "header" file and could easily be a chunk
in some other latex-related file.

It seems to me the only peculiarity here is with the latex
command as reported by Waldek:

http://www.mail-archive.com/axiom-***@nongnu.org/msg07222.html

that when given the command:

\usepackage{axiom}

by default looks for

axiom.sty.tex

in the current directory even though the common practice is to name
the file

axiom.sty

and to locate it in the shared texmf file tree. To me this is
strange and unexpected. I cannot find this behaviour documented
anywhere on the web. So it looks like a bug in tex to me.

Changing axiom.sty.pamphlet to axiom-sty.pamphlet and added a
chunk named <<asxiom.sty>>= still seems like the right thing to
do to avoid this "bug". I one sentence explanation in the pamphlet
file should be enough documentation for such a simple change that
is otherwise consistent with the rest of the Axiom source code.

Regards,
Bill Page.
Gabriel Dos Reis
2006-11-08 15:00:11 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

| On Wednesday, November 08, 2006 8:19 AM Gaby wrote:
| > ...
| > Bill Page wrote:
| > | In my opinion it is only an accident that axiom.sty.pamphlet
| > | has this name and contains only one root chunk. In general this
| > | is not the case.
| >
| > The axiom.sty.pamphlet is inded very special. Its purpose and
| > its functionality are not the same like any others. We should
| > not forget that.
| >
|
| I don't understand. In what way is it special?

It is self-referencing, and foundational to anything else for Axiom
documentation, and therefore has a more intimate relationship with TeX
than others.

| To me it looks
| just like any other "header" file and could easily be a chunk
| in some other latex-related file.

No argument there.

| It seems to me the only peculiarity here is with the latex
| command as reported by Waldek:
|
| http://www.mail-archive.com/axiom-***@nongnu.org/msg07222.html
|
| that when given the command:
|
| \usepackage{axiom}
|
| by default looks for
|
| axiom.sty.tex
|
| in the current directory even though the common practice is to name
| the file
|
| axiom.sty
|
| and to locate it in the shared texmf file tree. To me this is
| strange and unexpected. I cannot find this behaviour documented
| anywhere on the web. So it looks like a bug in tex to me.

Probably.

| Changing axiom.sty.pamphlet to axiom-sty.pamphlet and added a
| chunk named <<asxiom.sty>>= still seems like the right thing to
| do to avoid this "bug". I one sentence explanation in the pamphlet
| file should be enough documentation for such a simple change that
| is otherwise consistent with the rest of the Axiom source code.

I'm not disagreeing with that. I'm explaning, *why* from my
perspective, that exception to the general rule is acceptable -- even
when I don't find it perfect or don't like it.

-- Gaby
Ralf Hemmecke
2006-11-08 21:38:42 UTC
Permalink
Post by Gabriel Dos Reis
| > ...
| > | In my opinion it is only an accident that axiom.sty.pamphlet
| > | has this name and contains only one root chunk. In general this
| > | is not the case.
| >
| > The axiom.sty.pamphlet is inded very special. Its purpose and
| > its functionality are not the same like any others. We should
| > not forget that.
| >
|
| I don't understand. In what way is it special?
It is self-referencing, and foundational to anything else for Axiom
documentation, and therefore has a more intimate relationship with TeX
than others.
I still don't see a reason that makes axiom.sty.pamphlet special.
First one extracts any file via notangle (tex is completely irrelevant
here). Then one transforms pamphlets to .tex files (tex is still
irrelevant). Now you have all the generated files you need to start the
latex process.
Gabriel Dos Reis
2006-11-08 23:17:41 UTC
Permalink
Ralf Hemmecke <***@risc.uni-linz.ac.at> writes:

[...]

| Since when you compile axiom.sty.tex also axiom.sty must be in the
| path \usepackage will always take axiom.sty.tex instead. So the option
| of moving the files to another place does not help since they must be
| visible at the same time.

Sorry, I don't follow.

-- Gaby
Ralf Hemmecke
2006-11-08 23:27:05 UTC
Permalink
Post by Gabriel Dos Reis
[...]
| Since when you compile axiom.sty.tex also axiom.sty must be in the
| path \usepackage will always take axiom.sty.tex instead. So the option
| of moving the files to another place does not help since they must be
| visible at the same time.
Sorry, I don't follow.
Can I quote a sentence of yours? "Be more specific." ;-)
What was unclear in the TeX example I gave?

Ralf
Page, Bill
2006-11-08 22:57:32 UTC
Permalink
...
Most of you opt now for renaming axiom.sty.pamphlet to something
else (like axiom-sty.pamphlet). I rather like to see the general
noweave file.pamphlet > file.pamphlet.tex
no matter how many dots are in "file".
You should not forget to mention how the .tex name (which is only
internal) is converted to a .dvi name (which is visible to all
users). If you use latex with no extra processing then Rule 2
implies

latex file.pamphlet.tex --> file.pamphlet.dvi

-------

The rule used in the current Axiom make files is also simple
(Rule 1) :

noweave file.pamphlet > file.tex
latex file.tex --> file.dvi

no matter how many dots are in "file".
Post by Gabriel Dos Reis
| Changing axiom.sty.pamphlet to axiom-sty.pamphlet and added a
| chunk named <<asxiom.sty>>= still seems like the right thing
| to do to avoid this "bug". I one sentence explanation in the
| pamphlet file should be enough documentation for such a simple
| change that is otherwise consistent with the rest of the Axiom
| source code.
I'm not disagreeing with that. I'm explaining, *why* from my
perspective, that exception to the general rule is acceptable
-- even when I don't find it perfect or don't like it.
I do not understand your point of view. As far as I can see there
is *no* exception to the either Rule 1 or Rule 2! What do you think
is violated by the use of the "axiom-sty.pamphlet" file name?

Perhaps you are really concerned about a different more implicit
rule (Rule 3) :

The 'file' part of the file.pamphlet name should the same as the
"name" of the program in the file - in other words the same as
the name of a code chunk in the file.

Of course if there is only one such code chunk then it is natural
to try to make these names the same or at least similar. But the
application of Rule 3 is not always straightforward. If there is
more than one program or style file in the pamphlet file there
will be multiple code chunk names.
Why would you accept even a single exception if you can have
something without it?
There is *no* exception to the rule whether we choose Rule 1 or
Rule 2.

If we try to apply *both* Rule 1 and Rule 3, without renaming
axiom.sty.pamphlet to axiom-sty.pamphlet, then in this single
case of a file continuing a code chunk named <<axiom.sty>>= the
result is a conflict with the behavior of latex.

If we apply *both* Rule 2 and Rule 3, then yes this single
problem case is avoided. BUT *all* the names of all the dvi
files and the internal .tex files will change to include the
extra 'pamphlet' suffix.

But if we admit just *one more* exception to Rule 3 (there are
already many exceptions to Rule 3 in the src/algebra files),
then the combination of Rule 1 and Rule 3 is ok because we are
not obliged to make the file name and the chunk name the same
even though at this time there is only one code chunk in the
axiom-sty.pamphlet file. And we do not change any of the other
names of the intermediate .tex or external .dvi files.

-----------

Ok. I think that really is my last word on this subject! :-) In
the end I will agree to either of these choices. I just think
that Rule 1 with a small compromise to Rule 3 is the most simple
and easy approach. Obviously both methods will solve the problem.

Regards,
Bill Page.
Gabriel Dos Reis
2006-11-08 23:29:53 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

[...]

| > > Bill Page wrote:
| > > | Changing axiom.sty.pamphlet to axiom-sty.pamphlet and added a
| > > | chunk named <<asxiom.sty>>= still seems like the right thing
| > > | to do to avoid this "bug". I one sentence explanation in the
| > > | pamphlet file should be enough documentation for such a simple
| > > | change that is otherwise consistent with the rest of the Axiom
| > > | source code.
| > >
| > Gsby wrote:
| > > I'm not disagreeing with that. I'm explaining, *why* from my
| > > perspective, that exception to the general rule is acceptable
| > > -- even when I don't find it perfect or don't like it.
| >
|
| I do not understand your point of view. As far as I can see there
| is *no* exception to the either Rule 1 or Rule 2! What do you think
| is violated by the use of the "axiom-sty.pamphlet" file name?

It is ironic that we're agreeing, but we seem to think we disagree.

Let me explain again. The *current* situation is that we have
axiom.sty.pamphlet, from which we extract axiom.sty. Everything is
OK. Except that for very obscure reasons, it does not seem to work
properly when LaTeXinig that specific file (sorry, Ralf, the more yyou
explain, the less I become convinced we should just add .tex).
*A* solution is to rename the source file to axiom-sty.pamphlet, which
departs from the original naming. axiom-sty.pamphlet is the only file
to go through that mutification.

| Perhaps you are really concerned about a different more implicit
| rule (Rule 3) :
|
| The 'file' part of the file.pamphlet name should the same as the
| "name" of the program in the file - in other words the same as
| the name of a code chunk in the file.

No.

| Of course if there is only one such code chunk then it is natural
| to try to make these names the same or at least similar. But the
| application of Rule 3 is not always straightforward. If there is
| more than one program or style file in the pamphlet file there
| will be multiple code chunk names.

yes; of course.
Page, Bill
2006-11-08 23:32:19 UTC
Permalink
Post by Ralf Hemmecke
...
Wow. I must be doing something wrong. I already question whether
I should use German to get my idea through. English doesn't
seem to work. ;-)
...
There is only *one* dvi file that will be produced and *not* one
for every .nw file. So "xdvi axiom.sty.pamphlet.dvi" is absolutely
no argument. One should not even look at something like
axiom.sty.pamphlet.tex, because that is generated and could
look like a big mess --- if you have really looked at files that
come out of noweave you will know that theses files are not for
humans even if they are .tex files.
Ok, thank you! I finally understand what you are saying. :-)

axiom.sty.pamphlet.tex

is never processed by

latex axiom.sty.pamphlet.tex

Maybe it would be much less confusing if these files did not have
the extension .tex. Why not something like

axiom.sty.pamphlet.inc

to make it clear that we will not be directly apply latex to this
file?
Post by Ralf Hemmecke
So now the trick why I don't have myalps.nw.dvi.
The top-level project file is called myalps.tex.nw. Applying my
rules gives myalps.tex and myalps.tex.nw.tex. The first one is
just a wrapper that in shortened form looks like
\documentclass{article}
\usepackage{allprose}
\begin{document}
\author{Ralf Hemmecke}
\title{\xProject{} \LIBRARYVERSION}}
\maketitle
\begin{abstract}
...
\end{abstract}
\hypertarget{sec:Contents}{}\tableofcontents
\input{\projectname.tex.nw}
\end{document}
and that will be latex'ed.
Ok, so this is a file that we do not currently have in any of the
Axiom directories, right? We would have to create at least one for
each src directory.
Post by Ralf Hemmecke
As you can see, it's some kind of template. And my Makefiles make
sure that the setup will be such that all other .nw.tex files will
be included into the documentation.
Ok.
Post by Ralf Hemmecke
There is another point that speaks against the current practice
of translating each .pamphlet file into one .dvi, namely "literate
programming". Ideas don't just live in one file. That completely
misses the point that there are relations from one part of the
system to another. For example, there should not be 5 Makefile.dvi
files lying around in different directories. Since the build
procedure should be described as a whole.
I agree.
Post by Ralf Hemmecke
It would better to describe the interpreter as a whole rather than
producing a .dvi file for each of the 187 files in src/interp.
Tim's approach (if I understood that correctly) is to make *one*
huge .pamphlet file. My approach is to have as many pamphlet file
as you like but produce *one* human readable document from all of
them to describe a _unit_ (i.e. the interpreter).
Yes, I like your approach much more than Tim's book volumes even
though the end result for the user is nearly the same. Nice.
Post by Ralf Hemmecke
Eventually, we perhaps want just one document (a web-site, for
example) that describe all of axiom (including the source code).
For a web site the size doesn't matter. But still, there should
be some backlinks from the human-readable format (.dvi) to the
actual .pamphlets.
Ok.
Post by Ralf Hemmecke
...
Post by Page, Bill
Using a file name for dvi files that retains the original
.pamphlet extension is not so obvious to me.
I hope, this time my English is understandable.
Yes certainly. I don't think the problem is your English. It
just takes time to say the critical things so that someone
else can appreciate a beautiful idea.
Post by Ralf Hemmecke
...
But now I understand, I do feel like I have to take a step back
and because this is an even bigger change then what I incorrectly
thought you were suggesting - instead of changing nearly 1000 files
we would probably be reducing the number of dvi files to less than
100. I think that might take some planning - as you originally
suggested - but I am starting to agree that the result would be
worth it.

Thanks again for your patience.

Regards,
Bill Page.
Ralf Hemmecke
2006-11-08 23:37:15 UTC
Permalink
Post by Page, Bill
Thanks again for your patience.
Thank you for listening. ;-)

Ralf
Ralf Hemmecke
2006-11-08 23:50:57 UTC
Permalink
Ah, one last remark. I don't yet have a complete understanding of LEO,
but, in fact, what I am suggesting now should not prevent us from
introducing LEO at a later stage (I think). Noweb files are noweb files.
LEO maintains them in some way I suggest to do it in another way (maybe
only because I did not understand LEO). Whether the compilation to dvi
is achieved through a set of Makefile rules and perl scripts (in my
case) or through LEO is just a matter of the tool. The .nw files should
be the same.

And thank you, Bill. I really should change "appending .tex" to
"appending .texinclude" or something like that. I have to explore first
what implications that has to my srcltx setup, but with a little
TeX-hacking that should work.

Ralf
Gabriel Dos Reis
2006-11-09 00:47:21 UTC
Permalink
Ralf Hemmecke <***@hemmecke.de> writes:


[...]

| And thank you, Bill. I really should change "appending .tex" to
| "appending .texinclude" or something like that.

We should appoint Bill as Axiom Speaker :-)
I'm semi serious :-)

-- Gaby
Page, Bill
2006-11-09 00:23:59 UTC
Permalink
Post by Ralf Hemmecke
Post by Gabriel Dos Reis
[...]
| Since when you compile axiom.sty.tex also axiom.sty must be in
| the path \usepackage will always take axiom.sty.tex instead.
| So the option of moving the files to another place does not
| help since they must be visible at the same time.
Sorry, I don't follow.
Can I quote a sentence of yours? "Be more specific." ;-)
What was unclear in the TeX example I gave?
Ralf,

I think what Gaby is suggesting is that aaa.tex would be extracted
to some directory other than the current directory, e.g.

$ noweave axiom.sty.pamphlet > intermediate/axiom.sty.tex

then presumably calling

$ tex intermediate/axiom.sty.tex

even though it contains

\usepackage{axiom.sty)

will not look for axiom.sty in the intermediate directory -
only the current directory.

Your test did not test this case.

Try this:

$ mkdir intermediate

Create the file 'intermediate/axiom.sty.tex'

%%%BEGIN intermediate/axiom.sty.tex
\documentclass{book}
\usepackage{axiom}
\begin{document}
test
\end{document}
%%%END intermediate/axiom.sty.tex

Now create 'axiom.sty.tex' file in the current directory

%%%BEGIN axiom.sty.tex
\message{======= I am axiom.sty.tex =======}
%%%END axiom.sty.tex

Plus two 'axiom.sty' files - one in the current directory

%%%BEGIN axiom.sty
\message{======= I am just axiom.sty =======}
%%%END axiom.sty

and one in the intermediate directory

%%%BEGIN intermediate/axiom.sty
\message{======= I am intermediate/axiom.sty =======}
%%%END intermediate/axiom.sty

Remember also that we still have the axiom.sty file in the share
texmf directory tree and tex appropriately initialized to look
for it there. That makes three 'axiom.sty' files in all.

--------

Now from the current directory run

$ latex intermediate/axiom.sty.tex
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./intermediate/axiom.sty.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german,
ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,
norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,
swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/book.cls
Document Class: book 2004/02/16 v1.4f Standard LaTeX document class
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/bk10.clo))
(./axiom.sty.tex
======= I am axiom.sty.tex =======) (./axiom.sty.aux) [1]
(./axiom.sty.aux) )
Output written on axiom.sty.dvi (1 page, 216 bytes).
Transcript written on axiom.sty.log.

---------

So indeed, \usepackage{axiom} does cause latex to look in the
*current* directory for 'axiom.sty.tex'.

What happens if we rename 'axiom.sty.tex' and try again?

$ mv axiom.sty.tex axiom.sty.tex_old

$ latex intermediate/axiom.sty.tex
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./intermediate/axiom.sty.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german,
ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,
norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,
swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/book.cls
Document Class: book 2004/02/16 v1.4f Standard LaTeX document class
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/bk10.clo))
(./axiom.sty
======= I am just axiom.sty =======) (./axiom.sty.aux) [1]
(./axiom.sty.aux) )
Output written on axiom.sty.dvi (1 page, 216 bytes).
Transcript written on axiom.sty.log.

----------

Now the devil finds 'axiom.sty' in the current directory!

Finally, let's rename 'axiom.sty' and try a 3rd time.

$ mv axiom.sty axiom.sty_old

$ latex intermediate/axiom.sty.tex
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./intermediate/axiom.sty.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german,
ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,
norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,
swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/book.cls
Document Class: book 2004/02/16 v1.4f Standard LaTeX document class
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/bk10.clo))
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/axiom.sty)
(./axiom.sty.aux)
[1] (./axiom.sty.aux) )
Output written on axiom.sty.dvi (1 page, 216 bytes).
Transcript written on axiom.sty.log.

---------

Finally success. latex finds the copy of axiom.sty where it is
supposed to - in the share texmf tree (no messages).

Summary: One way to solve this stupid problem is to extract the
.tex file to an intermediate directory different from the current
directory when we run latex.

Regards,
Bill Page.
Gabriel Dos Reis
2006-11-09 00:44:41 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

| On Wednesday, November 08, 2006 6:27 PM Ralf Hemmecke wrote:
| >
| > On 11/09/2006 12:17 AM, Gabriel Dos Reis wrote:
| > > Ralf Hemmecke <***@risc.uni-linz.ac.at> writes:
| > >
| > > [...]
| > >
| > > | Since when you compile axiom.sty.tex also axiom.sty must be in
| > > | the path \usepackage will always take axiom.sty.tex instead.
| > > | So the option of moving the files to another place does not
| > > | help since they must be visible at the same time.
| > >
| > > Sorry, I don't follow.
| >
| > Can I quote a sentence of yours? "Be more specific." ;-)
| > What was unclear in the TeX example I gave?
| >
|
| Ralf,
|
| I think what Gaby is suggesting is that aaa.tex would be extracted
| to some directory other than the current directory, e.g.

Yes, exactly.

-- Gaby
Ralf Hemmecke
2006-11-09 05:27:22 UTC
Permalink
Post by Gabriel Dos Reis
| I think what Gaby is suggesting is that aaa.tex would be extracted
| to some directory other than the current directory, e.g.
Yes, exactly.
Yep. When Gaby was saying something about "from where latex is called"
that made me test this situation. You are right. In that way we can
avoid to rename axiom.sty.pamphlet no matter what naming scheme we agree
upon. The only problem that remains is srcltx. It works as I have it now
and I have to investigate how to twist that. But I already have an idea.

Ralf
Page, Bill
2006-11-09 00:31:24 UTC
Permalink
Post by Ralf Hemmecke
Post by Gabriel Dos Reis
| There is only *one* dvi file that will be produced and
| *not* one for every .nw file.
Ah, but that is a fundamental distinction between the respective
states of Axiom and your peoject.
Of course.
Post by Gabriel Dos Reis
| So "xdvi axiom.sty.pamphlet.dvi" is absolutely no argument.
Unfortunately, for Axiom, that is going to be an argument for
the short and mi-term.
Are you so sure? Where should I branch from for that experiment?
Yes a new branch! I strongly encourage you to do that. :-)

I am just a little uncertain of the technical implications for
merging later, but I suggest that you clone build-improvements -
primarily because I think it represents the best environment in
which to experiment with alternate build scripts. It is more
modular than Axiom Gold and once you get used to it, autoconf
really does make things simpler and easier to understand.

Gaby, what do you think about branching from build-improvements?

Regards,
Bill Page.
Gabriel Dos Reis
2006-11-09 00:53:17 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

[...]

| > > | So "xdvi axiom.sty.pamphlet.dvi" is absolutely no argument.
| >
| > > Unfortunately, for Axiom, that is going to be an argument for
| > > the short and mi-term.
| >
| > Are you so sure? Where should I branch from for that experiment?
| >
|
| Yes a new branch! I strongly encourage you to do that. :-)
|
| I am just a little uncertain of the technical implications for
| merging later, but I suggest that you clone build-improvements -
| primarily because I think it represents the best environment in
| which to experiment with alternate build scripts. It is more
| modular than Axiom Gold and once you get used to it, autoconf
| really does make things simpler and easier to understand.
|
| Gaby, what do you think about branching from build-improvements?

That makes perfect sense to me. Ralf can sync from build-improvements
at any time.

Given recent discussions, I would very much appreciate Tim shime in.

-- Gaby
root
2006-11-09 01:02:32 UTC
Permalink
Post by Gabriel Dos Reis
Given recent discussions, I would very much appreciate Tim shime in.
I have no opinion.

Tim
Ralf Hemmecke
2006-11-09 05:46:39 UTC
Permalink
Post by Gabriel Dos Reis
[...]
| > > | So "xdvi axiom.sty.pamphlet.dvi" is absolutely no argument.
| >
| > > Unfortunately, for Axiom, that is going to be an argument for
| > > the short and mi-term.
| >
| > Are you so sure? Where should I branch from for that experiment?
| >
|
| Yes a new branch! I strongly encourage you to do that. :-)
|
| I am just a little uncertain of the technical implications for
| merging later, but I suggest that you clone build-improvements -
| primarily because I think it represents the best environment in
| which to experiment with alternate build scripts. It is more
| modular than Axiom Gold and once you get used to it, autoconf
| really does make things simpler and easier to understand.
|
| Gaby, what do you think about branching from build-improvements?
That makes perfect sense to me. Ralf can sync from build-improvements
at any time.
Given recent discussions, I would very much appreciate Tim shime in.
Maybe it doesn't matter to much from where I branch since I intend to do
the first approximation with my own Makefiles. What I currently have in
ALLPROSE seems to be in conflict with autoconf (I generate Makefiles and
things that are included in Makefiles on the fly).

I would be happy to discuss later how this could be integrated with
build-improvements. But, in fact, it is rather independent of that.
Still though I am currently reading about autoconf and also want to add
autoconf facilities to ALLPROSE, maybe it is easier for me to learn
something about autoconf if I branch from build-improvements.

It seems that I am going to have some sleepless nights coming. ;-)

Ralf

Continue reading on narkive:
Loading...