[Axiom-developer] RE: FW: How to set default for ALLOCATE-CONTIGUOUS-PAGES?

[Page, Bill]

Camm, 

On Tuesday, September 27, 2005 5:10 PM you wrote:
> 
> Greetings, and please exsude the delay!
> 

No problem! I exsude (sic) delay myself ;)

On Thursday, September 15, 2005 12:17 PM Bill Page wrote:
> > 
> > On Thursday, September 15, 2005 12:07 PM I wrote:
> > > > ... 
> > > > GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
> > > > --enable-maxpage=256*1024"
> > > > 
> > 
> > Oops... the build just died with: NULL_OR_ON_C_STACK macro invalid
> > 
> > ...
> > echo " (in-package \"USER\")(system:save-system \"saved_pre_gcl\")"
> > >>foo
> > 
>
/home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport/raw_pre_gcl
> > /home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport/ -libdir
> > /home/page/repository/axiom--main--1/lsp/gcl-2.6.7/ < foo
> > GCL (GNU Common Lisp)  April 1994  262144 pages
> > 
> > Unrecoverable error: NULL_OR_ON_C_STACK macro invalid.
> 
> What kind of machine is this?

This is the axiom-developer server where we run MathAction. It
is a x686 shared virtual server running RedHat 9.  The error
occurs when trying to build Axiom patch-44 which includes
gcl-2.6.7. The build succeeds if I use the normal Axiom default
of --enable-maxpage=128*1024, but then I get the
ALLOCATE-CONTINUOUS-PAGES error. See below. That is why I was
trying to increase maxpage.

> The purpose of this macro is to distinguish the stack address
> space. Addresses of local variables should return true, and
> others false. GCL tests this on starup on a local variable, NIL,
> and core_end. One can see what the macro expands to by doing
> 'cpp -I../h main.c' in the o directory.  Most likely there was
> some problem in detecting CSTACK_ADDRESS in the configure stage.
> I recommend looking at the configure output for this.

Ok. Here is where CSTACK_ADDRESS is mentioned in the configure
output:

...
checking for randomized sbrk... no
checking finding DBEGIN... got 0x8000000
checking finding CSTACK_ADDRESS... got 1073738356
...

In config.log I see

...
configure:3780: checking for sbrk
configure:3798: gcc -o conftest      conftest.c  1>&5
configure:3814: checking for randomized sbrk
configure:3831: gcc -o conftest      conftest.c  1>&5
configure:3863: gcc -o conftest      conftest.c  1>&5
configure:3984: checking finding DBEGIN
configure:4028: gcc -o conftest     conftest.c  1>&5
configure:4051: checking finding CSTACK_ADDRESS
configure:4068: gcc -o conftest      conftest.c  1>&5
...

So I don't see a problem here. Do you?

On Thursday, September 15, 2005 5:58 AM Bill Page wrote:
> > > 
> > > On Thursday, September 15, 2005 5:22 AM I wrote: 
> > > 
> > > > ... 
> > > > Yes, I think you are right. I changed the short name 
> > > > (abbreviation=file name?) of my Aldor category from
> > > > upper case to lower case and now it **sometimes** works.
> > > > See:
> > > > 
> > > > http://wiki.axiom-developer.org/SandBoxCategoryOfGraphs
> > > > 
> > > > But often when I try to save this page I get:
> > > > 
> > > >     >> System error:
> > > >     Contiguous blocks exhausted.
> > > >   Currently, 1354 pages are allocated.
> > > >   Use ALLOCATE-CONTIGUOUS-PAGES to expand the space.
> > > > 
> 
> You can allocate page types explicitly with the #'allocate function
> (see the docs if needed),

I do not know what you mean by "allocate page types explicitly".
Is this a function like si::allocate-contiguous-pages that I used
in the Axiom )lisp command below? Or does this have something to
do with the gcl configuration?

> but this is not necessary, as you are totally out of memory here,
> and this will just forestall total failure.

As I mentioned in the previous email, all seems well if I call

  )lisp (si::allocate-contiguous-pages 3000 t)

inside Axiom before access the Aldor category. Why do you say
that I am "totally out of memory"?

> You need to configure with a greater --enable-maxpage.

That is what I tried to do but the build of gcl fails as
I mentioned above.

> 
> Do I understand right that someone is layering aldor on top
> of axiom?

Aldor used to be available as an optional library compiler
for the commercial version of Axiom. The current open source
version of Axiom was released without Aldor because NAG had
previously and separately given the rights to the Aldor source
to "aldor.org" (aka. Stephen Watt). "aldor.org" makes binary
versions of Aldor available for free for non-commmercial use
but does not follow the current open source licensing model.

Recently Peter Broadbery was able to configure the open source
version of Axiom to use the Aldor binary on linux. So now
Axiom functions the way it used to in the commercial release
but the license status of Aldor is still uncertain. I have made
several requests to Stephen Watt to obtain a copy of the
source code license for Aldor but I have not yet heard from
him.

> Can we distribute such in Debian yet?

I presuemt that to distribute on Debian we would require
a GPL-compatible source license to Aldor, right?

> If so, I might be persuaded to package it, and thereby ensure
> that it works :-).

Wonderful. I think we should try hard to make this happen.
I would love to be able to just 'apt-get install aldor'! :)

Regards,
Bill Page.