On Wednesday, November 22, 2006 8:26 PM I wrote:
> Waldek Hebisch wrote:
> > in version 288 I see:
> >
> > 2006-11-18 Bill Page <[EMAIL PROTECTED]>
> >
> >* Makefile.pamphlet (LDFLAGS): Add X11 libraries flags.
> >* Makefile.in: Regenerate.
> >
> > Why do we need this: AFAIK s
"Page, Bill" <[EMAIL PROTECTED]> writes:
[...]
| http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00297.ht
| ml
|
| includes the line:
|
| +LDFLAGS= -L${LIB} -lspad ${LDF} -lspad ${AXIOM_X11_LDFLAGS}
|
| and
|
| <>=
| ${OUT}/sman: ${SMANOBJS} ${MIDOBJ}/sman.o
| @ echo
> -Original Message-
> From:
> [EMAIL PROTECTED]
.org [mailto:axiom-developer-bounces+bill.page1>
[EMAIL PROTECTED] On Behalf Of Waldek Hebisch
> Sent: Wednesday, November 22, 2006 7:31 PM
> To: axiom-developer@nongnu.org
> Subject: [Axiom-developer] sman and X libraries
>
> in version
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| in version 288 I see:
|
| 2006-11-18 Bill Page <[EMAIL PROTECTED]>
|
|* Makefile.pamphlet (LDFLAGS): Add X11 libraries flags.
|* Makefile.in: Regenerate.
|
| Why do we need this: AFAIK sman should not use any X libraries.
| In recen
Martin Rubey wrote:
> Dear Tim,
>
> could you explain the following diff:
>
> diff -r /local/scratch/axiom/mnt/linux/doc/hypertex/pages/util.ht
> axiom49/mnt/linux/doc/hypertex/pages/util.ht
> 435,439c435,437
> < % 2003011 tpd added a leading open paren
> < \newcommand{\spadsyscom}[1]{){\tt
Gaby,
I updated by build-improvements testing repository on and rebuilt
Axiom with no errors. (GCL compiled separately with maxpage option).
Then I repeated your suggested tests (see below), but I got the
same results. No problems. Does revision 301 still fail on your
system?
And some good news:
in version 288 I see:
2006-11-18 Bill Page <[EMAIL PROTECTED]>
* Makefile.pamphlet (LDFLAGS): Add X11 libraries flags.
* Makefile.in: Regenerate.
Why do we need this: AFAIK sman should not use any X libraries.
In recent build 'ldd sman' gives me:
libXpm.so.4 => /usr/X11R
Directory src/boot defines its symbols in package boottran.
Why is it that the proclaim files says:
(make-package "BOOT" :USE '("LISP"))
Then swicthes to package boot
(IN-PACKAGE "BOOT")
before writin out the proclaims?
-- Gaby
___
Axi
root <[EMAIL PROTECTED]> writes:
| > | An excellent point. Except that none of the makefiles in the axiom
| > | tree are designed to be executed "standalone".
| >
| > The old broken makefiles were designed that way. Yes.
|
| So, let me get this straight
OK.
[...]
ENV was not chosen by
> | An excellent point. Except that none of the makefiles in the axiom
> | tree are designed to be executed "standalone".
>
> The old broken makefiles were designed that way. Yes.
So, let me get this straight
You've redesigned the Makefiles so they can be executed standalone.
You tried t
root <[EMAIL PROTECTED]> writes:
[...]
| prefix form sets the environment values but the new Makefile assignments
| will be used if they are set.
Which actually implies that most of the ENV should have been in the
Makefiles in the first place, eliminating the needs ot having to pass
anything pre
On Wednesday, November 22, 2006 4:56 PM Gaby wrote:
>
> "Page, Bill" <[EMAIL PROTECTED]> writes:
> | Damn. I just can't keep up the pace. :-(
>
> hey, it is Thanksgiving soon :-)
>
Done that already. (I'm in Canada, eh?) Gotta work this
weekend. Have fun with the family when you still can!
> .
root <[EMAIL PROTECTED]> writes:
| > There is this line in the Makefile for regression testing:
| >
| > regress:
| > ${ENV} ${MAKE} DAASE=$(axiom_targetdir) regression-tests
| >
| >
| > Notice that there is no explicit mention of sh, but Make will call it
| > because that is the way
root <[EMAIL PROTECTED]> writes:
| > It may help to state the *specific meaning* of ENV in POSIX shells. I
| > looked at the man page for bash and it says:
| >
| > "When invoked as an interactive shell with the name sh, bash looks for
| > the variable ENV, expands its value if it is define
root <[EMAIL PROTECTED]> writes:
[...]
| > | everything will still work.
| > | ENV is just a local name created 20 years ago.
| >
| > Not just because it was created 20 years ago means that its usage is
| > correct today. The world did not stop spining while Axiom was
| > hibernating.
|
| Ther
| > regress:
| > ${ENV} ${MAKE} DAASE=$(axiom_targetdir) regression-tests
|
| BTW, why isn't it
|
| ${MAKE} ${ENV} DAASE=$(axiom_targetdir) regression-tests
|
First, for defining terms, the "current Makefile" is the makefile
that contains the above chosen line. The "current Ma
> There is this line in the Makefile for regression testing:
>
> regress:
> ${ENV} ${MAKE} DAASE=$(axiom_targetdir) regression-tests
>
>
> Notice that there is no explicit mention of sh, but Make will call it
> because that is the way Make works.
>
> In my case, I stepped into the b
> It may help to state the *specific meaning* of ENV in POSIX shells. I
> looked at the man page for bash and it says:
>
> "When invoked as an interactive shell with the name sh, bash looks for
> the variable ENV, expands its value if it is defined, and uses the
> expanded value as the na
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > This patchlet works for me. Could you test it?
| >
| > *** document.in (revision 15247)
| > --- document.in (local)
| > *** while test $# -gt 0 ; do
| > *** 129,136
| >
| > --tangle)
| >
> | ok. s/ENV/GABY/ everywhere.
>
> Tim, you don't have fixate on me. As I said, the solution is to use
> MAKEFLAGS. That variable was designed specifically for those kinds
> of things.
sigh. missed the point.
s/ENV/TIM/ everywhere.
> | everything will still work.
> | ENV is just a local
"Page, Bill" <[EMAIL PROTECTED]> writes:
[...]
| Damn. I just can't keep up the pace. :-(
hey, it is Thanksgiving soon :-)
| But I kind of suspected this because I was looking for the new:
|
| document --tag=boot --mode=translate bootsys foo.boot
|
| option and didn't find it.
|
| > |
|
Waldek Hebisch <[EMAIL PROTECTED]> writes:
[...]
| >* Support parallel build.
| > Notice that GCL does not support parallel build. So we can punt
| > on build of GCL. We should work with Camm to fix GCL build
| > upstream.
| >...
| >
| >
| > If you remove the dependency
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > This patchlet works for me. Could you test it?
| >
| > *** document.in (revision 15247)
| > --- document.in (local)
| > *** while test $# -gt 0 ; do
| > *** 129,136
| >
| > --tangle)
| >
On Wednesday, November 22, 2006 4:07 PM Gaby wrote:
> Bill Page wrote:
> | But I noticed that you have many incorrectly quoted or unquoted
> | parameters in the document script.
>
> Please define more precisely what you mean by incorrectly quoted
> and unquoted.
I am referring to any parameter th
Gabriel Dos Reis wrote:
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> | In the main Makefile we have:
> |
> | SUBDIRS = src/lib lsp src
> |
> | and the recursive part will build subdirectories in this strictly
> | sequential order.
>
> No, that is untrue if you say "make -jN", aka parallel b
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
| > regress:
| > ${ENV} ${MAKE} DAASE=$(axiom_targetdir) regression-tests
|
| BTW, why isn't it
|
| ${MAKE} ${ENV} DAASE=$(axiom_targetdir) regression-tests
|
| ?
Ask Tim.
What you show is correct assuming you renamed ENV to somethin
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > But frankly, who is afraid of MAKEFLAGS? MAKEFLAGS does not just
| > control Make, it serves as a vehicle to communicate values to
| > sub-makes and sub-processes of Make.
| >
|
| I see two problems with MAKEFLAGS:
|
| 1)
"Page, Bill" <[EMAIL PROTECTED]> writes:
[...]
| All of these commands executed properly on the axiom-developer.org
| server without changes to document - probably because of the default
| behaviour of bash. See the output attached below.
|
| But I noticed that you have many incorrectly quoted o
Gabriel Dos Reis wrote:
> This patchlet works for me. Could you test it?
>
> *** document.in (revision 15247)
> --- document.in (local)
> *** while test $# -gt 0 ; do
> *** 129,136
>
> --tangle)
>do_tangle=yes
> ! if test -n $arg; then
> !
regress:
${ENV} ${MAKE} DAASE=$(axiom_targetdir) regression-tests
BTW, why isn't it
${MAKE} ${ENV} DAASE=$(axiom_targetdir) regression-tests
?
As far as I understand that, in both cases not ENV is passed to MAKE but
its value. So the variable ENV would not be set in a sub
On Wednesday, November 22, 2006 1:32 PM Gaby wrote:
> | On Wednesday, November 22, 2006 12:50 PM Gaby wrote:
> |
> | > | > ! chunk=$arg
>
> Bill Page wrote:
>
> | Why does this fail? What is the value of $chunk?
>
> Most of your questions can be asnwered as follows:
> Uncomment the
Gabriel Dos Reis wrote:
> But frankly, who is afraid of MAKEFLAGS? MAKEFLAGS does not just
> control Make, it serves as a vehicle to communicate values to
> sub-makes and sub-processes of Make.
>
I see two problems with MAKEFLAGS:
1) How portable it is to differnt favors of make?
2) IIUC in GN
root <[EMAIL PROTECTED]> writes:
[...]
| axiom could be so much faster if we got the gcl_collectfn mechanism
| fully re-implemented. the lisp type optimization code can eliminate
| hundreds of intructions per function call and axiom lives and breathes
| by function calling. however to fully take
root <[EMAIL PROTECTED]> writes:
| > No, that is untrue if you say "make -jN", aka parallel build, which
| > build-improvements must support.
|
| this is purely my opinion but i don't believe that parallel builds
| of axiom will ever succeed. i'm willing to be proven wrong and would
| find that p
Waldek Hebisch <[EMAIL PROTECTED]> writes:
[...]
| Ok, so we pick shell ENV when we run make in subdirectories. Yes, that
| is good reason to change it to something else. As quck fix we may just
| initialize ENV to empty string (explicit initialization should take
| precedence over enviroment v
Humberto Ortiz Zuazaga <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Nobody claims that is illegal. We are talking of a *specific variable*
| > here, that happens to have a *specific meaning* for shells.
|
| It may help to state the *specific meaning* of ENV in POSIX shells. I
| look
Gabriel Dos Reis wrote:
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
> | In subdirectories make variable ENV is unset, so its expansion is
> | empty.
>
> No, again you're making the assumption that ENV does not mean anything
> particular. ENV means something very precise is POSIXilly correct
> sh
Gabriel Dos Reis wrote:
Nobody claims that is illegal. We are talking of a *specific variable*
here, that happens to have a *specific meaning* for shells.
It may help to state the *specific meaning* of ENV in POSIX shells. I
looked at the man page for bash and it says:
"When invoked as an
root <[EMAIL PROTECTED]> writes:
| > No, again you're making the assumption that ENV does not mean anything
| > particular. ENV means something very precise is POSIXilly correct
| > shells. In particular its value is exported, which means that if you
| > don't set it, you get what it is supposed
root <[EMAIL PROTECTED]> writes:
| > | The name ENV predates POSIX.
| >
| > irrelevant.
| >
| > | Since we control everything about the build
| > | I don't think it matters but there would be no harm in changing it
everywhere.
| >
| > It matters that we do avoid using it. Otherwise, we're sett
"Page, Bill" <[EMAIL PROTECTED]> writes:
[...]
| > |
| > | chunk=`echo -n "$arg"`
| >
| > this one is one needed.
| >
|
| That is not what you wrote originally in your patchlet.
I think I wrote:
! if test -n "$arg"; then
! chunk=`echo -n $arg`
|
| > |
> No, that is untrue if you say "make -jN", aka parallel build, which
> build-improvements must support.
this is purely my opinion but i don't believe that parallel builds
of axiom will ever succeed. i'm willing to be proven wrong and would
find that proof a pleasant surprise.
in sub-optimal buil
"Page, Bill" <[EMAIL PROTECTED]> writes:
| On Wednesday, November 22, 2006 12:50 PM Gaby wrote:
|
| > | > ! chunk=$arg
|
| Why does this fail? What is the value of $chunk?
Most of your questions can be asnwered as follows:
Uncomment the "set -x" and "set +x" instructions from the d
On Wednesday, November 22, 2006 12:50 PM Gaby wrote:
> | > ! chunk=$arg
Why does this fail? What is the value of $chunk?
> | > ...
> | > ! chunk=`echo -n $arg`
> |
Is this one missing quotes or does it not matter?
> Bill Page wrote:
> | What shell actually requires su
> | The name ENV predates POSIX.
>
> irrelevant.
>
> | Since we control everything about the build
> | I don't think it matters but there would be no harm in changing it
> everywhere.
>
> It matters that we do avoid using it. Otherwise, we're setting a
> timebomb and it will blow (and it did fo
> No, again you're making the assumption that ENV does not mean anything
> particular. ENV means something very precise is POSIXilly correct
> shells. In particular its value is exported, which means that if you
> don't set it, you get what it is supposed to be (not empty). The
> above is an exp
Waldek Hebisch <[EMAIL PROTECTED]> writes:
[...]
| > Now that we don't need to build a patched version of GCL, we do
| > this:
| > (1) build noweb if necessary
| > (2) build GCL if necessaary -- as if we build on its own; however
| > install in $(axiom_builddir)
| > (3) build a Lis
root <[EMAIL PROTECTED]> writes:
| > > The use of ENV in the Makefiles conflicts with established practice
| > > with shells (that are POSIXilly correct).
| >
| > And we don't export ENV to submakes, so I don't know if it's doing anything.
|
| The name ENV predates POSIX.
irrelevant.
| Since
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| >
| > The use of ENV in the Makefiles conflicts with established practice
| > with shells (that are POSIXilly correct).
| >
|
| I am not sure what you mean: in the main Makefile ENV is make variable
| which expands to shell syntax:
|
| VAR1=val1 V
Humberto Ortiz Zuazaga <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > The use of ENV in the Makefiles conflicts with established practice
| > with shells (that are POSIXilly correct).
|
| And we don't export ENV to submakes, so I don't know if it's doing anything.
ENV is used as in:
"Page, Bill" <[EMAIL PROTECTED]> writes:
| Gaby
|
| On Wednesday, November 22, 2006 11:30 AM you wrote:
|
| > ! chunk=$arg
| > ...
| > ! chunk=`echo -n $arg`
|
| What shell actually requires such an awkward construction?
| Of if you wish why not write:
|
|
> > The use of ENV in the Makefiles conflicts with established practice
> > with shells (that are POSIXilly correct).
>
> And we don't export ENV to submakes, so I don't know if it's doing anything.
The name ENV predates POSIX. Since we control everything about the build
I don't think it matter
>
> The use of ENV in the Makefiles conflicts with established practice
> with shells (that are POSIXilly correct).
>
I am not sure what you mean: in the main Makefile ENV is make variable
which expands to shell syntax:
VAR1=val1 VAR2=val2 ... command
Do you mean that this syntax is illegal?
Gabriel Dos Reis wrote:
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis wrote:
> | > Waldek Hebisch <[EMAIL PROTECTED]> writes:
> | >
> | > | Remark2. From my point of view the stamp stuff in the main Makefile
> | > | is not doing anything usefull,
> | >
> | > Could you clari
Gabriel Dos Reis wrote:
The use of ENV in the Makefiles conflicts with established practice
with shells (that are POSIXilly correct).
And we don't export ENV to submakes, so I don't know if it's doing anything.
--
Humberto Ortiz-Zuazaga
Programmer-Archaeologist
UPR Bioinformatics Resource Ce
Gaby
On Wednesday, November 22, 2006 11:30 AM you wrote:
> ! chunk=$arg
> ...
> ! chunk=`echo -n $arg`
What shell actually requires such an awkward construction?
Of if you wish why not write:
chunk="$arg"
or even better :-)
chunk=`echo -n
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Waldek Hebisch <[EMAIL PROTECTED]> writes:
| >
| > | Remark2. From my point of view the stamp stuff in the main Makefile
| > | is not doing anything usefull,
| >
| > Could you clarify what you mean by this?
| >
|
| > | di
> That begs the question: why not put those warm data and files in
> interpsys too, so that we only have one image to care about?
Because the "warm data" algebra has to be compiled before it can
be loaded. PositiveInteger needs to be compiled in interpsys.
AXIOMsys is a "ship system" and it prelo
Stamp files are used for two purposes in the axiom build.
The first purpose is to prevent rebuilding external subsystems
like GCL and noweb.
The second purpose is to provide a timestamp for the database files.
Tim
___
Axiom-developer mailing list
Axi
root <[EMAIL PROTECTED]> writes:
| > My understanding is this: there is an Axiom image (interpsys) used at
| > compile time; think of as the image the build machine needs to drive
| > the compilation. One of the purpose of such image is for example, to
| > build some of the algebra needed to bui
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[...]
| | --tangle)
| |do_tangle=yes
| | - if test -n $arg; then
| | + if test -n "$arg"; then
| |chunk=$arg
|
| Without proper quotes, I think this would lead to garbage again (at
| least that was my experience some
Gabriel Dos Reis wrote:
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> | Remark2. From my point of view the stamp stuff in the main Makefile
> | is not doing anything usefull,
>
> Could you clarify what you mean by this?
>
> | diff -ru build-improvements.bb/Makefile.pamphlet
> build-improvem
The use of ENV in the Makefiles conflicts with established practice
with shells (that are POSIXilly correct).
-- Gaby
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
> My understanding is this: there is an Axiom image (interpsys) used at
> compile time; think of as the image the build machine needs to drive
> the compilation. One of the purpose of such image is for example, to
> build some of the algebra needed to build the installed image. Once
> that image
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Waldek Hebisch <[EMAIL PROTECTED]> writes:
| >
| > | > Waldek Hebisch <[EMAIL PROTECTED]> writes:
| > | >
| > | > | Recent changes broken testing build-improvements. The typical problem
| > | > | is that 'int/input/INTHEOR
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| The patch below eliminates the second build of Axiom and switches
| tests to use AXIOMsys. I also changed creation of target directories
| to make it more logical.
|
| Remark1: We probably should make target directories at before starting
| the prope
Gabriel Dos Reis wrote:
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> | > Waldek Hebisch <[EMAIL PROTECTED]> writes:
> | >
> | > | Recent changes broken testing build-improvements. The typical problem
> | > | is that 'int/input/INTHEORY.input' contains sum of INTHEORY.spad and
> | > | PNTHEOR
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| > Waldek Hebisch <[EMAIL PROTECTED]> writes:
| >
| > | Recent changes broken testing build-improvements. The typical problem
| > | is that 'int/input/INTHEORY.input' contains sum of INTHEORY.spad and
| > | PNTHEORY.spad.
| >
| > sorry, I don't unders
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> | Recent changes broken testing build-improvements. The typical problem
> | is that 'int/input/INTHEORY.input' contains sum of INTHEORY.spad and
> | PNTHEORY.spad.
>
> sorry, I don't understand.
>
For me multiple tests give bogus results. Examin
The patch below eliminates the second build of Axiom and switches
tests to use AXIOMsys. I also changed creation of target directories
to make it more logical.
Remark1: We probably should make target directories at before starting
the proper build. ATM we depend on previous stages to create tar
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Recent changes broken testing build-improvements. The typical problem
| is that 'int/input/INTHEORY.input' contains sum of INTHEORY.spad and
| PNTHEORY.spad.
sorry, I don't understand.
-- Gaby
___
Axiom-d
> In order to type check that piece of code you need compile time
> evaluation of foo. That is the reason why Aldor requires parameters of
> types to be constant in the given context.
In Axiom there would be no problem doing compile-time evaluation
provided the appropriate algebra is loaded.
Ti
In the Axiom/SPAD compiler you can write such a functor as
g(p:PositiveInteger, k:Integer):with point:()->PrimeField(p)
== add point()==k::PrimeField(p)
If that works with the spad compiler then why is there a belief that the
spad compiler cannot handle dependent types?
Maybe the problem i
Bill Page wrote:
> On Wednesday, November 22, 2006 4:35 AM Frederic Lehobey wrote:
> > PrimeField(7)
> >
> > and
> >
> > PrimeField(p)
> >
> > both work in interpreted mode whereas the second one is not compiled
> > by the old compiler (it has already been discussed some time -- years
>
On Wednesday, November 22, 2006 4:35 AM Frederic Lehobey wrote:
>
> I believe I am starting to be slightly off-topic for axiom-legal
> with this message, so I think it will be my last contribution to
> this thread.
Ok. I want to reply to one technical point so I will shift to
axiom-developer.
>
Recent changes broken testing build-improvements. The typical problem
is that 'int/input/INTHEORY.input' contains sum of INTHEORY.spad and
PNTHEORY.spad.
--
Waldek Hebisch
[EMAIL PROTECTED]
___
Axiom-developer mailing
Hi,
opening on a not very current FreeBSD using Mozilla fails with the request
to download plugins.
However, direct download of the mov/avi (e.g. fetch
http://daly.axiom-developer.org/literate/MakeAxiom_mov/MakeAxiom_mov_media/M
akeAxiom_mov.mov) and playing in mplayer works fine - but wmv fai
77 matches
Mail list logo
