root <[EMAIL PROTECTED]> writes:
| > > On Monday, October 16, 2006 8:47 PM Waldek Hebisch wrote:
| > > > ...
| > > > 1) ATM I can not add much value to what is already there --
| > > >I can read the code but the classic rule of documentation is
| > > >"documentation should not repeat the c
Waldek Hebisch <[EMAIL PROTECTED]> writes:
[...]
| To clean old data we loop over all symbols from [[boot]] package
| and reset [[boot::database]] property to [[nil]]. We also rest
| [boot::*allconstructors*]] to [[nil]].
I'm asking you to include an explanation of *why* that is essential;
wha
"Page, Bill" <[EMAIL PROTECTED]> writes:
| On Tuesday, October 17, 2006 12:09 AM Tim Daly wrote:
|
| > ...
| >
| > Waldek Hebisch wrote
| > >
| > > The patch I wrote changed the paphlet file. I admit that I did
| > > not use dvi viewer to check formatting, but since the parts I
| > > changed fo
> Processor: Intel(R) Pentium(R) 4 CPU 3.00GHz (2 CPUs)
> Memory: 2048MB RAM
> SONY CD-RW CRX320E: 52X max CD-R write, 52X max CD read, 16X max DVD read,
> 32X CD-RW write. 2MB buffer memory.
o, nice toy package it up and send it so we can debug the problem. :-)
t
_
"Page, Bill" <[EMAIL PROTECTED]> writes:
[...]
| Actually I agree. Your original patch was not so bad - it is
| just that it did not add any explanation to the document itself.
| It improved the program but did not improve the document.
You very well capture the essence of my original remarks.
"Page, Bill" <[EMAIL PROTECTED]> writes:
| On Monday, October 16, 2006 8:47 PM Waldek Hebisch wrote:
| > ...
| > 1) ATM I can not add much value to what is already there --
| >I can read the code but the classic rule of documentation is
| >"documentation should not repeat the code"...
|
|
root <[EMAIL PROTECTED]> writes:
| > (2) please, please, document behaviour in the pamphlets; not just
| > the code.
|
| can i get a witness! amen, amen! stand and sing, all who enter! :-0
| (couldn't resist :-) )
I would have made exactly the same request, was it a change for
GCC -- whi
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > (2) please, please, document behaviour in the pamphlets; not just
| > the code.
|
| What do you mean by "document behaviour in the pamphlets"? Do you think
| that I should split changes into chunks and annotate them
Hi Alejandro,
Thanks for the feedback.
Processor: Intel(R) Pentium(R) 4 CPU 3.00GHz (2 CPUs)
Memory: 2048MB RAM
SONY CD-RW CRX320E: 52X max CD-R write, 52X max CD read, 16X max DVD read,
32X CD-RW write. 2MB buffer memory.
Note that out of these 5 minutes or so, the timeout for bringing up eth
Alfredo
Something is wrong. Doyen does not take 5 minutes to load, not even in
a virtual machine. Can you give me the specs of the machine you are
testing please (memory - cpu - cdrom speed).
Processor: Intel(R) Pentium(R) 4 CPU 3.00GHz (2 CPUs)
Memory: 2048MB RAM
SONY CD-RW CRX320E: 52X max
On Tuesday, October 17, 2006 12:09 AM Tim Daly wrote:
> ...
>
> Waldek Hebisch wrote
> >
> > The patch I wrote changed the paphlet file. I admit that I did
> > not use dvi viewer to check formatting, but since the parts I
> > changed follow textual format using only text terminal should be
> > O
> > On Monday, October 16, 2006 8:47 PM Waldek Hebisch wrote:
> > > ...
> > > 1) ATM I can not add much value to what is already there --
> > >I can read the code but the classic rule of documentation is
> > >"documentation should not repeat the code"...
> >
> > Actually this classic rule
> Bill Page wrote:
> > ... In a literate program the document contains the code so it
> > certainly "repeats the code" in that sense. The code illustrates
> > and implements the ideas described in the document. Code and
> > documentation are not two separate things.
> >
>
On Monday, October 16, 20
> 1. The main purpose of the "database" is, as I understand it, to
> enable the loading of mathematical knowledge on an "as needed" basis
> into Axiom rather than carry everything at once in the image? If i've
> got that right I'm impressed by the power of that design, but I wonder
> how much lik
CY wrote:
> 1. The main purpose of the "database" is, as I understand it, to
> enable the loading of mathematical knowledge on an "as needed" basis
> into Axiom rather than carry everything at once in the image? If i've
> got that right I'm impressed by the power of that design, but I wonder
> ho
> On Monday, October 16, 2006 8:47 PM Waldek Hebisch wrote:
> > ...
> > 1) ATM I can not add much value to what is already there --
> >I can read the code but the classic rule of documentation is
> >"documentation should not repeat the code"...
>
> Actually this classic rule of documentati
--- Waldek Hebisch <[EMAIL PROTECTED]> wrote:
> I am not sure if compression is obsolete: we have performance problem
> with Spad compiler and databases may be part of this problem. If
> we need fast reading of databases compressed version is likely to
> be faster (of course there are other possib
Alejandro,
OK, some feedback:
1. I could not run properly doyen04262005 on my machine at home because it
produced some ammount of cloop readerror messages. It run fine on an older
machine at the office, though. Sadly, there is no md5 file to check the iso
file. Anyway, I have found that this Kn
On Monday, October 16, 2006 8:47 PM Waldek Hebisch wrote:
> ...
> 1) ATM I can not add much value to what is already there --
>I can read the code but the classic rule of documentation is
>"documentation should not repeat the code"...
Actually this classic rule of documentation is *not* ap
Gabriel Dos Reis wrote:
> (2) please, please, document behaviour in the pamphlets; not just
> the code.
What do you mean by "document behaviour in the pamphlets"? Do you think
that I should split changes into chunks and annotate them separately?
I would oppose that: current structure is m
Tim, Alfredo, CY
The axiom-developer@nongnu.org mailing list is the best forum
for this discussion. I've taken the liberty of copying your questions
and comments to the list so we can all contribute.
Please
subscribe to this list so you can be up to date with the project.
I have subscribed,
> > 2) Patch adds ability to dump uncompressed databases (easier to
> >read): to get uncompressed format just set *do-not-compress-databases*
> >to t
>
> I feel you should simply patch the databases to remove the
> compression. It was only written so we could create databases
> that could
> (1) please, please, avoid *var*. Use boot::var
The lisp coding convention uses *foo* as a "global" variable name
so this is a proper way to name it.
> (2) please, please, document behaviour in the pamphlets; not just
> the code.
can i get a witness! amen, amen! stand and sing, all w
root <[EMAIL PROTECTED]> writes:
| Removing calls to these should create uncompressed databases.
That sounds better. Please, document what is happening.
-- Gaby
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mail
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Below is a patch that fixes few problems with databases:
|
| 1) If old database contained constructors or operations which
|were removed from new database, Axiom kept using old data.
|The patch cleans old data
|
| 2) Patch adds ability to dump
> 2) Patch adds ability to dump uncompressed databases (easier to
>read): to get uncompressed format just set *do-not-compress-databases*
>to t
I feel you should simply patch the databases to remove the
compression. It was only written so we could create databases
that could fit on one dis
Below is a patch that fixes few problems with databases:
1) If old database contained constructors or operations which
were removed from new database, Axiom kept using old data.
The patch cleans old data
2) Patch adds ability to dump uncompressed databases (easier to
read): to get uncomp
"Gernot Hueber" <[EMAIL PROTECTED]> writes:
| Weiss, Juergen writes:
| >
| >> "Gernot Hueber" <[EMAIL PROTECTED]> writes: | Hi, what about the BSDs?
| >> For some time I think I am the only one :-(
| >> Currently, you cannot build build-improvements on *BSD because I use
| >> some GNUisms in the M
Axiom will build properly on gcl-2.6.7
You just have to set the GCLVERSION variable and fetch the
gcl-2.6.7.tgz from the archive and put it in the zips directory.
t
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/ma
"Weiss, Juergen" <[EMAIL PROTECTED]> writes:
|
|
| > "Gernot Hueber" <[EMAIL PROTECTED]> writes:
| >
| > | Hi, what about the BSDs? For some time I think I am the only one :-(
| >
| > Currently, you cannot build build-improvements on *BSD because I use
| > some GNUisms in the Makefile (e.g. "
Weiss, Juergen writes:
"Gernot Hueber" <[EMAIL PROTECTED]> writes:
| Hi, what about the BSDs? For some time I think I am the only one :-(
Currently, you cannot build build-improvements on *BSD because I use
some GNUisms in the Makefile (e.g. "export"). That will be
fixed later
by using
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis wrote:
> | > The real fix, is to test for $$fail, NOT $$failcmd. Notice fail is
> | > set when --keep is specified.
> | >
> |
> | Yes, like:
> |
> | --- config/setup-dep.mk (wersja 182)
> | +++ config/setup-dep.mk (kop
> "Gernot Hueber" <[EMAIL PROTECTED]> writes:
>
> | Hi, what about the BSDs? For some time I think I am the only one :-(
>
> Currently, you cannot build build-improvements on *BSD because I use
> some GNUisms in the Makefile (e.g. "export"). That will be
> fixed later
> by using MAKEFLAGS.
>
Martin Rubey wrote:
> Dear Waldek, Tim, Cliff,
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > > Waldek Hebisch <[EMAIL PROTECTED]> writes:
> > > >
> > > > I agree that algebra bootstrap should be revisited. But IMHO the
> > > > main work to do is outside Makefiles: I think that algebra sh
You've clearly spent a fair amount of time understanding things
about axiom. Hopefully you're documenting as you learn so we can
all benefit from your work.
t
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/l
Actually, it appears you are correct. I was confused by the compression.
At some point in the near future we should eliminate the compression
and that would eliminate the compress.daase file completely.
t
___
Axiom-developer mailing list
Axiom-develope
> > This is not a valid database file.
> > I'll see if I can document the structure of such a file.
> >
> > t
> >
> >
> > (30 . 3469429128)
> > ((|Category| NIL NIL NIL "NIL" NIL T NIL (NIL) NIL NIL NIL) (|Union| NIL
> > NIL NIL "NIL" NIL NIL NIL (NIL) |domain| NIL NIL) (|Record| NIL NIL NIL
>
> This is not a valid database file.
> I'll see if I can document the structure of such a file.
>
> t
>
>
> (30 . 3469429128)
> ((|Category| NIL NIL NIL "NIL" NIL T NIL (NIL) NIL NIL NIL) (|Union| NIL NIL
> NIL "NIL" NIL NIL NIL (NIL) |domain| NIL NIL) (|Record| NIL NIL NIL "NIL" NIL
> NIL NIL
root <[EMAIL PROTECTED]> writes:
| > what about the BSDs? For some time I think I am the only one :-(
| >
| > Gernot
| >
| >
| > Gabriel Dos Reis writes:
| >
| > > "Bill Page" <[EMAIL PROTECTED]> writes:
| > >
| > > | Is anyone working on Axiom for OS X?
| > >
| > > Not right now, but I
"Gernot Hueber" <[EMAIL PROTECTED]> writes:
| Hi, what about the BSDs? For some time I think I am the only one :-(
Currently, you cannot build build-improvements on *BSD because I use
some GNUisms in the Makefile (e.g. "export"). That will be fixed later
by using MAKEFLAGS.
-- Gaby
__
Waldek Hebisch <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > The real fix, is to test for $$fail, NOT $$failcmd. Notice fail is
| > set when --keep is specified.
| >
|
| Yes, like:
|
| --- config/setup-dep.mk (wersja 182)
| +++ config/setup-dep.mk (kopia robocza)
| @@ -
C Y <[EMAIL PROTECTED]> writes:
[...]
| http://lists.nongnu.org/archive/html/axiom-developer/2006-10/msg00039.html
|
| Ah! I remember seeing that but I confess I did not appreciate the full
| significance of it. Very nice indeed.
|
| Gaby, is there any plan to incorporate this into the build-
root <[EMAIL PROTECTED]> writes:
| > (1) it leads to wrong behaviour; this is factual.
|
| But Axiom's been like this for years.
It does not mean it was correct :-)
| What is wrong about the behavior?
I explained the behaviour that you can reproduce. Try it with depsys,
bootsys.
| > (1) all
> I agree. The only thing one has to do is to rebuild the databases after each
> layer. In fact, I did this manually to build an Axiom with my Guessing
> Package...
>
> I said
>
> make DAASE=../../int
>
> after each layer. (It's a pain, but it works.)
>
> Tim, you wrote the Makefile, do you kn
Ok, actually I have a tight schedule until Thursday ... but I try to do it
ASAP.
Gernot
root writes:
Gernot,
Please send me a diff -Naur of your version and --patch-50
and I'll see if I can get it running on my FreeBSD machine.
t
___
Axi
Gernot,
Please send me a diff -Naur of your version and --patch-50
and I'll see if I can get it running on my FreeBSD machine.
t
___
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
root writes:
what about the BSDs? For some time I think I am the only one :-(
Gernot
Gabriel Dos Reis writes:
> "Bill Page" <[EMAIL PROTECTED]> writes:
>
> | Is anyone working on Axiom for OS X?
>
> Not right now, but I need to get to it, because 66% of my students
> runs on MACs.
> what about the BSDs? For some time I think I am the only one :-(
>
> Gernot
>
>
> Gabriel Dos Reis writes:
>
> > "Bill Page" <[EMAIL PROTECTED]> writes:
> >
> > | Is anyone working on Axiom for OS X?
> >
> > Not right now, but I need to get to it, because 66% of my students
> > runs on
--- Waldek Hebisch <[EMAIL PROTECTED]> wrote:
> > >
> > > I agree that algebra bootstrap should be revisited. But IMHO the
> > > main work to do is outside Makefiles: I think that algebra should
> > > build just from spad files using Spad compiler and almost empty
> > > databases.
> >
> > Agree
Hi,
what about the BSDs? For some time I think I am the only one :-(
Gernot
Gabriel Dos Reis writes:
"Bill Page" <[EMAIL PROTECTED]> writes:
| Is anyone working on Axiom for OS X?
Not right now, but I need to get to it, because 66% of my students
runs on MACs.
-- Gaby
_
50 matches
Mail list logo
