[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Git

From: Camm Maguire
Subject: Re: [Gcl-devel] Git
Date: Mon, 05 Aug 2013 14:14:00 -0400


>  Hi, Camm --
>  Thanks very much for the work and the information.  I took a quick
>  look at https://buildd.debian.org/status/package.php?p=acl2&suite=sid,
>  specifically at the logs in the failure cases (ia64, kfreebsd-i386,
>  mips, mipsel), and in each case I found the following (or something
>  close to it, at least):
>    ACL2 Error in ACL2-INTERFACE:  Unable to obtain the truename of file
>    "/sbuild-nonexistent/".
>    Error: ACL2 Halted
>    Fast links are on: do (si::use-fast-links nil) for debugging
>    Error signalled by LET.
>    Raw Lisp Break.
>    Backtrace: lp > let > error > lisp:lambda-closure > APPLY
>  I'm pretty sure that the message is coming from ACL2 function
>  our-truename.  One way this could happen is that ACL2 function our-pwd
>  is attempting to get the current directory namestring using
>  our-truename (which for cltl1 GCL, calls si::stat if it's fboundp),
>  but that directory somehow doesn't exist (odd).  A more likely
>  possibility is that our-truename is being called on
>  (user-homedir-pathname), which in turn is returning nil or perhaps a
>  non-existent directory name.
>  For the future, I think I'll fix our-truename to print a message that
>  gives more information about why it's failing.  For now, a more
>  complete backtrace might help.

Thanks so much for checking!  Actually, the latest acl2 failures are as

ia64, mips, mipsel: the autobuilder times out when certifying
elementary-bounders.  By default, a package build must some produce
terminal output in 150 minutes lest the job be terminated.  This limit
can be configured per package, and I've requested an extended setting
for acl2.  Even without this, these packages can be built by hand and
uploaded, so are not an issue.

kf-i386: ran out of memory certifying elementary-bounders.  The previous
iteration of the acl2 package had the same on only powerpc.  As you
know, the new larger appetites of some of these jobs has motivated some
recent gcl work, notably dynamic maximum pages.  The ppc failure was the
last of originally many that were fixed by the recent changes.  I
believe this may be cleared by the latest upload.

Note on modern memory management -- linux and it appears most other unix
like kernels have an overcommit memory strategy on by default.  This is
a system wide setting, and is not changeable by the process.  This means
that an allocation request can be granted by the operating system, only
for the process to perhaps be killed when it tries to access the
returned memory.  This is very non-optimal from gcl's point of view.
Putting on pages early in a job can paint one into a corner at the end,
so it is very helpful for gcl to know where the edge of available memory
is.  I'll post a note in the near future on gcl's current attempts to
get at least a qualitative bound, in hopes some others might suggest
>  By the way, I tried to follow your instructions on my Mac (running Mac
>  OS 10.6.8) after installing git, but I needed another "cd gcl".  Hope
>  I did it right (below, "lt" is an alias for "ls -lrt"; sorry about
>  that).
>    ~/lisps/gcl/2013-08-04$ git clone git://git.sv.gnu.org/gcl.git
>    Cloning into 'gcl'...
>    remote: Counting objects: 57616, done.        
>    remote: Compressing objects: 100% (12893/12893), done.        
>    remote: Total 57616 (delta 38402), reused 57616 (delta 38402)        
>    Receiving objects: 100% (57616/57616), 56.82 MiB | 334.00 KiB/s, done.
>    Resolving deltas: 100% (38402/38402), done.
>    Checking connectivity... done
>    Checking out files: 100% (11213/11213), done.
>    ~/lisps/gcl/2013-08-04$ lt
>    total 0
>    drwxr-xr-x  4 kaufmann  staff  136 Aug  4 10:47 gcl
>    ~/lisps/gcl/2013-08-04$ cd gcl
>    ~/lisps/gcl/2013-08-04/gcl$ git checkout Version_2_6_9pre
>    Branch Version_2_6_9pre set up to track remote branch Version_2_6_9pre 
> from 
>  origin.
>    Switched to a new branch 'Version_2_6_9pre'
>    ~/lisps/gcl/2013-08-04/gcl$ ./configure && make
>    bash: ./configure: No such file or directory
>    ~/lisps/gcl/2013-08-04/gcl$ ls -l
>    total 0
>    drwxr-xr-x  70 kaufmann  staff  2380 Aug  4 11:02 gcl
>    ~/lisps/gcl/2013-08-04/gcl$ 

This is correct, sorry for the ommission.

BTW, what is your mac version?

>  The build on my Mac seemed to succeed (hooray!).  But the debugger
>  seems to have a problem ("illegal ihs index") when entered with
>  control-c (where you'll see two control-c keys echoed by emacs below),
>  though not when entered through an error:
>    ~/lisps/gcl/2013-08-04/gcl/gcl$ bin/gcl
>    GCL (GNU Common Lisp)  2.6.9 CLtL1    Aug  4 2013 11:05:45
>    Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
>    Binary License:  GPL due to GPL'ed components: (READLINE UNEXEC)
>    Modifications of this banner must retain notice of a compatible license
>    Dedicated to the memory of W. Schelter
>    Use (help) to get some basic information on how to use GCL.
>    Temporary directory for compiler files set to 
>  /var/folders/kt/ktfN4HB6GeqP--4uIFkD+E+++TI/-Tmp-/
>    >(car 3)
>    Error: 3 is not of type LIST.
>    Fast links are on: do (si::use-fast-links nil) for debugging
>    Error signalled by CAR.
>    Broken at EVAL.  Type :H for Help.
>    >>:q
>    Top level.
>    >  C-c C-c
>    Correctable error: Console interrupt.
>    Signalled by SYSTEM:TOP-LEVEL.
>    If continued: Type :r to resume execution, or :q to quit to top level.
>    Error: 4 is an illegal ihs index.
>    Fast links are on: do (si::use-fast-links nil) for debugging
>    Error signalled by SYSTEM::GCL-TOP-LEVEL.
>    Broken at SYSTEM::GCL-TOP-LEVEL.
>    >>>

Thanks for the report!  Should be fixed no in cvs and git.  I think you
can do 'git pull' to update.

>  By the way, I forgot to include --enable-ansi with my configure
>  command.  Maybe at this point it would be reasonable for that to be
>  the default?

I think once 2.6.9 is out that is a good idea, but I will have to
synchronize with axiom.

>  Finaly, regarding your comment:
>     3) update the website with this announcement
>  Are you referring to http://www.gnu.org/software/gcl/?  If so, then
>  are you referring to the "Get Latest Release" link near the top on the
>  left side of the page, or perhaps to the "Debian package page" below
>  it (which is currently a broken link)?

Yes to the former, and will fix the broken link of the latter.  Thanks
for pointing this out!

Take care,
Camm Maguire                                        address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]