Waldek Hebisch <[EMAIL PROTECTED]> writes:
[...]
| Hmm, I do not think information from the e-mail belongs to the
| document -- for example writing a paper I discard many alternatives
| and failed attempts and publish only final version. IMHO information
| about specific problem belongs to the Ch
"Bill Page" <[EMAIL PROTECTED]> writes:
[...]
| It means that we *do*
| publish the many alternatives and failed attempts as well as the
| "final version". Very few projects ever reach the stage of a final
| version.
Agreed.
-- Gaby
___
On October 19, 2006 10:38 PM Waldek Hebisch wrote:
> ...
> Bill Page wrote:
> > When you say "as a reader", I wonder what you are reading:
> > the Lisp code or the dvi document that you generated from the
> > pamphlet file? In terms of creating a document that can be read
> > while sitting in a co
Bill Page wrote:
> > 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.
> > >
> Let us look at an example. I wrote:
>
>
>
>; Clean old data
>(do-symbols (symbol)
> (when (get symbol 'database)
> (setf (get symbol 'database) nil)))
>(setq *allconstructors* nil)
> ...
>
>
> Do you think that:
>
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
"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
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
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
> > 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
26 matches
Mail list logo
