[Top][All Lists]

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

Re: [Gcl-devel] Git

From: Matt Kaufmann
Subject: Re: [Gcl-devel] Git
Date: Mon, 5 Aug 2013 13:30:45 -0500

Hi, Camm --

Thanks for the info.  As to your question:

>> BTW, what is your mac version?

I'm not sure exactly what info you would like, but it's a MacBook Pro
with a 2.66 GHz Intel Core i7 processor and 8 GB 1067 GHz DDR3 of
memory.  I think I got it in about May, 2010.  Here's some additional
info -- feel free to send me another command to submit or, more
generally, to tell me how to find what you need.

~$ system_profiler SPSoftwareDataType

    System Software Overview:

      System Version: Mac OS X 10.6.8 (10K549)
      Kernel Version: Darwin 10.8.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Computer Name: Matt Kaufmann’s MacBook Pro
      User Name: kaufmann (kaufmann)
      Secure Virtual Memory: Enabled
      64-bit Kernel and Extensions: No
      Time since boot: 4 days 21:20


And from "About This Mac":

Hardware Overview:

  Model Name:   MacBook Pro
  Model Identifier:     MacBookPro6,2
  Processor Name:       Intel Core i7
  Processor Speed:      2.66 GHz
  Number Of Processors: 1
  Total Number Of Cores:        2
  L2 Cache (per core):  256 KB
  L3 Cache:     4 MB
  Memory:       8 GB
  Processor Interconnect Speed: 4.8 GT/s
  Boot ROM Version:     MBP61.0057.B0C
  SMC Version (system): 1.58f17
  Serial Number (system):       W80190SAAGW
  Hardware UUID:        F109A455-E8D5-5571-9A54-C9A05BEC979F
  Sudden Motion Sensor:
  State:        Enabled

-- Matt
   From: Camm Maguire <address@hidden>
   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 
   >  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]