RE: [Axiom-developer] --patch46

[Bill Page]

Tim,

On October 31, 2005 12:16 AM you wrote:
> 
> not a virtual server problem. i'm building the FC4 in a vmware
> machine. hmmm. mod the code to lower the limit, i guess. debugging
> the problem will just take you down a different path you probably
> don't want to go.

Right! :)

The build completes with --enable-maxpage=128*1024

> it'll probably be a waste of time. i only jacked the limit
> because we thought it would solve a previous problem
>
 
Yes. In an email on 15 Septembre 2005 Vanuxem Grégory claimed
that this did solve the problem. But I was not able to reproduce
that on MathAction since I was not able to complete the build.

>  but i think that problem got cured anyway, right?

No unfortunately not, althought there is a kind of work around
by setting:

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

in the Axiom session. My last email to Camm on this issue is
attached. So far he has not replied. All this GCL memory
management stuff seems like a mystery to me so I don't know
how to follow his suggestion of "you can allocate page types
explicitly with the #'allocate".

Regards,
Bill Page.


> -----Original Message-----
> From: Page, Bill [mailto:address@hidden 
> Sent: September 27, 2005 6:11 PM
> To: Camm Maguire
> Cc: address@hidden; address@hidden; Bill Page
> Subject: RE: FW: How to set default for ALLOCATE-CONTIGUOUS-PAGES?
> 
> 
> 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/ra
> w_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.
> 
>