Corrected subject line. Delete previous email.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Page, Bill
Sent: Thursday, October 26, 2006 1:27 AM
To: Gabriel Dos Reis
Cc: axiom-developer@nongnu.org
Subject: RE: [Axiom-developer] postprop.lisp
Gaby,
Gaby,
Here are some simple patches to build-improvements required by
some versions of awk. Of course you need also to rebuild the
corresponding Makefile.in files.
-
[EMAIL PROTECTED]:~/axiom.build-improvements$ hg diff .
The following patch ensures that if make is restarted, it does
not app
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Well, beauty of Lisp: the same things are defined in 'property.lisp'
| (except for |special| property, which is unused). You are probably
| right that depsys picks definitions from 'postprop.lisp'. In my
| experiments (IIRC using AXIOMsys) changing 'po
> > | >
> > | > Tim --
> > | >
> > | > The source file postprop.lisp is compiled into depsys, but loaded
> > | > in interpreted form in AXIOMsys. What is the reason for that?
> > | >
> > |
> > | AFAIK postprop.lisp is unused -- IMHO it should be removed.
> >
> > It is compiled into depsys -
root <[EMAIL PROTECTED]> writes:
| > > | >
| > > | > Tim --
| > > | >
| > > | > The source file postprop.lisp is compiled into depsys, but loaded
| > > | > in interpreted form in AXIOMsys. What is the reason for that?
| > > | >
| > > |
| > > | AFAIK postprop.lisp is unused -- IMHO it should
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| > Waldek Hebisch <[EMAIL PROTECTED]> writes:
| >
| > | >
| > | > Tim --
| > | >
| > | > The source file postprop.lisp is compiled into depsys, but loaded
| > | > in interpreted form in AXIOMsys. What is the reason for that?
| > | >
| > |
| > | A
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> | >
> | > Tim --
> | >
> | > The source file postprop.lisp is compiled into depsys, but loaded
> | > in interpreted form in AXIOMsys. What is the reason for that?
> | >
> |
> | AFAIK postprop.lisp is unused -- IMHO it should be removed.
>
>
Tim --
def.lisp is loaded twice into debugsys.
-- Gaby
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| >
| > Tim --
| >
| > The source file postprop.lisp is compiled into depsys, but loaded
| > in interpreted form in AXIOMsys. What is the reason for that?
| >
|
| AFAIK postprop.lisp is unused -- IMHO it should be removed.
It is compiled into deps
>
> Tim --
>
> The source file postprop.lisp is compiled into depsys, but loaded
> in interpreted form in AXIOMsys. What is the reason for that?
>
AFAIK postprop.lisp is unused -- IMHO it should be removed.
--
Waldek Hebisch
[EMAIL PROTECTED]
__
Tim --
The source file postprop.lisp is compiled into depsys, but loaded
in interpreted form in AXIOMsys. What is the reason for that?
-- Gaby
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axi
Le jeudi 26 octobre 2006 à 02:36 +0200, Waldek Hebisch a écrit :
> I wanted to try hypertex in silver on Gentoo Linux. It turned out
> that I can not start sman, becouse 'ptyopen' was failing. Atfter
> a little investigation I found out that the machine (which otherwise
> uses bleeding edge new s
Bill,
I did a checkout of the sourceforge SVN root.
I'll diff the SVN vs axiom--silver--1 so nothing gets lost.
t
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
> Waldek,
>
> Could you latex bookvol1.tex and let me know why it stops?
> This file is a copy of the published tutorial.
>
The problem is very simple: '\spadgraph' is defined both in
'axiom.sty' and at the beginiing of 'bookvol1.pamphlet'. It
is fixed in build-improvements (and I suppose also in
Tim --
Is there a reason why construc.lisp is not loaded into debugsys?
-- Gaby
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
Waldek,
Could you latex bookvol1.tex and let me know why it stops?
This file is a copy of the published tutorial.
Tim
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
Camm,
See output of objdump as suggested below.
On Wednesday, October 25, 2006 11:10 AM you wrote:
> ...
> > >
> > > This might be instructive with srget in place of cos:
> > >
> > > objdump -x /usr/lib/gcl-2.6.7/unixport/saved_gcl |grep cos
> > > 0812f590 l F .text015b
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| I wrote:
| > I tested build-improvements on x86-64 Debian testing, using bundled
| > noweb and gcl. Now, I also tested silver on 32-bit Debian sarge
| > (x86-64 Debian testing is still working on silver).
|
| Unfortunatly, silver does not build on x86
I wanted to try hypertex in silver on Gentoo Linux. It turned out
that I can not start sman, becouse 'ptyopen' was failing. Atfter
a little investigation I found out that the machine (which otherwise
uses bleeding edge new software) has only old legacy pty's -- the
new '/dev/ptmx' and '/dev/pts'
> I wrote:
> > I tested build-improvements on x86-64 Debian testing, using bundled
> > noweb and gcl. Now, I also tested silver on 32-bit Debian sarge
> > (x86-64 Debian testing is still working on silver).
>
> Unfortunatly, silver does not build on x86-64 Debian testing:
>
> 1 linking /var/tmp/
I wrote:
> I tested build-improvements on x86-64 Debian testing, using bundled
> noweb and gcl. Now, I also tested silver on 32-bit Debian sarge
> (x86-64 Debian testing is still working on silver).
Unfortunatly, silver does not build on x86-64 Debian testing:
1 linking /var/tmp/hebisch/axp7/sil
Camm,
On Wednesday, October 25, 2006 11:10 AM you wrote:
> ...
> OK, will try to reactivate my sourceforge status. Something
> changed over the summer.
Yes, there were some problems with access to the compile farm.
That seems to be fixed now.
> In the meantime, here is what needs doing:
>
>
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > This looks fine to me. Could say on which platform you built and
| > tested this change? Please add appropriate ChangeLog entry. This
| > change should go to silver too; please send a corresponding patch
| > for review (I
Gabriel Dos Reis wrote:
> This looks fine to me. Could say on which platform you built and
> tested this change? Please add appropriate ChangeLog entry. This
> change should go to silver too; please send a corresponding patch
> for review (I appreciate some path changes on build-improvements are
Onednesday, October 25, 2006 6:21 PM Waldek Hebisch wrote:
>
> Bill Page wrote:
> > Well, the procedure that we agreed on (I think) was the Tim
> > would be solely responsible for committing changes to Silver
> > (axiom--silver-1 == SVN /trunk). Tim's preferred way to do this
> > is entirely a man
Greetings! OK, should be optional now. Please let me know if not.
Take care,
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Camm Maguire <[EMAIL PROTECTED]> writes:
>
> | Greetings, and thanks!
> |
> | Should we make makeinfo a build dependency of GCL? We cannot generate
> | any documentati
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| > Waldek Hebisch <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | @
| > | -<>=
| > | -${OUT}/libdb.text: $(srcdir)/libdb.text
| > | - @ echo 4300a copying $< to $@
| > | - $(INSTALL_DATA) $< $@
| > | -
| > | -@
| >
| > Given this, the file libdb.
Bill Page wrote:
> Well, the procedure that we agreed on (I think) was the Tim
> would be solely responsible for committing changes to Silver
> (axiom--silver-1 == SVN /trunk). Tim's preferred way to do this
> is entirely a manual process - send him patches and copy the
> axiom-developer list. Pers
On Wednesday, October 25, 2006 5:08 PM Waldek Hebisch wrote:
Bill Page wrote:
> > ... Is deleteing and re-creating /trunk a safe and sensible
> > thing to do?
>
> I am not sure if it is safe, but I wonder if it has any
> advantages (like preserving history) compared to other options.
>
My plan w
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | @
> | -<>=
> | -${OUT}/libdb.text: $(srcdir)/libdb.text
> | - @ echo 4300a copying $< to $@
> | - $(INSTALL_DATA) $< $@
> | -
> | -@
>
> Given this, the file libdb.text should also be removed from the repo.
>
there are two 'libd
First, I think we can agree that axiom--silver--1 is the master copy.
(I haven't yet looked at it but it probably contains all the history
since Tim started.)
So in fact the history in the sourceforge or google mirror of silver are
not too important.
But anyway, if they the log data should b
> One way to do this would be to first of all delete /trunk
> from the repository and rebuild it from the current contents
> of axiom--silver--1, but given the little I understand about
> how SVN works, I am concerned that using svnadmin to delete
> /trunk might have serious consequences for any br
On Wednesday, October 25, 2006 4:46 PM Ralf Hemmecke wrote:
>
> Doing a delete via svnadmin... I don't think that's the right way.
>
I am also worried about this.
> ...
> One problem with 'svn delete' applied to the trunk and then
> recreation from new files is that you basically double the s
| One way to do this would be to first of all delete /trunk
| from the repository and rebuild it from the current contents
| of axiom--silver--1, but given the little I understand about
| how SVN works, I am concerned that using svnadmin to delete
| /trunk might have serious consequences for any b
Bill,
fire up emacs, start a shell, do a
diff -r --brief axiom--silver--1 sourceforge | grep -v svn | grep -v arch
and you can see which files need to be copied.
t
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/
"Page, Bill" <[EMAIL PROTECTED]> writes:
| Gaby,
|
| Since Tim has agreed to what I proposed below and no one
| else has disagreed, I would like to plan for this but I
| would appreciate your opinion first on how best to do it
| without screwing up the SVN repository to badly. Specfically
| what
Alfredo,
You are right. I guess I will have to talk to him anyway since
if we do this on SourceForge, we would still have the problem of
updating Google the same say. I am quite sure that my current
method of updating Google would not work properly if I were to
try to delete SourceForge /trunk and
Gaby,
Since Tim has agreed to what I proposed below and no one
else has disagreed, I would like to plan for this but I
would appreciate your opinion first on how best to do it
without screwing up the SVN repository to badly. Specfically
what we would be trying to do is to replace the existing
/tru
Waldek Hebisch <[EMAIL PROTECTED]> writes:
[...]
| @
| -<>=
| -${OUT}/libdb.text: $(srcdir)/libdb.text
| - @ echo 4300a copying $< to $@
| - $(INSTALL_DATA) $< $@
| -
| -@
Given this, the file libdb.text should also be removed from the repo.
-- Gaby
__
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Waldek Hebisch <[EMAIL PROTECTED]> writes:
| >
| > | As few people noticed hypertex searches for constructors where
| > | giving no result, for example clicking on "NAG link" and then
| > | on "Browser pages for individual r
root <[EMAIL PROTECTED]> writes:
| Waldek, Gaby,
|
| I understand your enthusiasm for changing things but you do realize
| that you're going to make it very difficult to merge your changes.
| You started out "fixing make" and, as you learn more, you're starting
| to change files. However, you're
Waldek, Gaby,
I understand your enthusiasm for changing things but you do realize
that you're going to make it very difficult to merge your changes.
You started out "fixing make" and, as you learn more, you're starting
to change files. However, you're not packaging these changes into
changesets in
Gabriel Dos Reis wrote:
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> | As few people noticed hypertex searches for constructors where
> | giving no result, for example clicking on "NAG link" and then
> | on "Browser pages for individual routines" gives:
> |
> | There is no constructor matchin
Hi,
As discussed earlier, this patch makes Axiom stop setting
*default-pathname-defaults* -- which led to surprising and incoherent
behaviour. This variable, while Common Lisp standard, has an
implementation-defined meaning that, in fact, Axiom has no business in
changing directly.
Other cha
root <[EMAIL PROTECTED]> writes:
| > > So, I suspect we have to make a list of people for whom either SF or
| > > Google SVN works and decide where we go from there.
| > >
| >
| > For me SF SVN works. I did only tiny commits and one of them failed
| > (I had to redo it), so I am not sure how wel
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > So, I suspect we have to make a list of people for whom either SF or
| > Google SVN works and decide where we go from there.
| >
|
| For me SF SVN works. I did only tiny commits and one of them failed
| (I had to redo it),
root <[EMAIL PROTECTED]> writes:
[...]
| SVN won't work for me so i have stopped trying to use it.
| it should "just work" and it doesn't. Gaby likes it and it works
| well for him so he uses it. Bill wrestled heroically with it.
You did not look hard enough to see for whom else it is working.
Greetings!
"Bill Page" <[EMAIL PROTECTED]> writes:
> Camm,
>
> On October 24, 2006 11:56 AM you wrote:
> > >
> > > Aha. No "__srget" symbol defined in the gcl image? Isn't it strange?
> > >
> >
> > Yes, in light of this and previous messages. We need a gdb session
> > on raw_pre_gcl. Pleas
> > So, I suspect we have to make a list of people for whom either SF or
> > Google SVN works and decide where we go from there.
> >
>
> For me SF SVN works. I did only tiny commits and one of them failed
> (I had to redo it), so I am not sure how well will scale. Getting
> sources was slow, but
> >
> > > tla get axiom--silver--1
> > ...
> > I hope it is not too hard for you to convince "tailor" to move
> > the patches from Tim to SourceForge.
> > ...
>
> If everyone agrees (and especially, Tim Daly agrees) then I would
> delete the current SourceForge SVN /trunk and replace it with a
> > i've been unable to use SVN and could generate no interest in GIT.
>
> It's interesting to me, but I'm somewhat dismayed by the multitude of
> systems we are going through. I would have been happy to standardize
> on and learn Arch, but as it is no longer maintained that's not really
> a viab
If everyone agrees (and especially, Tim Daly agrees) then I would
delete the current SourceForge SVN /trunk and replace it with a
copy of axiom--silver--1 that is automatically maintained in sync
by running Tailor every night, like we currently do between
SourceForge and Google and between the bui
Gabriel Dos Reis wrote:
> So, I suspect we have to make a list of people for whom either SF or
> Google SVN works and decide where we go from there.
>
For me SF SVN works. I did only tiny commits and one of them failed
(I had to redo it), so I am not sure how well will scale. Getting
sources was
On October 25, 2006 5:18 AM Ralf Hemmecke wrote:
>
> > tla get axiom--silver--1
> ...
> I hope it is not too hard for you to convince "tailor" to move
> the patches from Tim to SourceForge.
> ...
If everyone agrees (and especially, Tim Daly agrees) then I would
delete the current SourceForge SV
> You see, Tim applied patches to his Gold-to-be and now Silver is no
longer in sync with that. Tim, mirror your Gold-to-be branch publicly
and accept the offer of Bill to move your changes to sourceforge.
How to move things from any other place back to Tim is another issue.
But the mailing-list
--- root <[EMAIL PROTECTED]> wrote:
> i've been unable to use SVN and could generate no interest in GIT.
It's interesting to me, but I'm somewhat dismayed by the multitude of
systems we are going through. I would have been happy to standardize
on and learn Arch, but as it is no longer maintained
> I fetched silver from SourceForge. The last ChangeLog entry is from
> 2006-09-14 (so it is somewhat old) and it has build problems (fixed
> in build-improvenents): one has to remove by hand '.svn' subdirectories,
> full Latex installation is needed. I fetched silver about two
> weeks ago, but
57 matches
Mail list logo
