Steel Bank Common Lisp

On Tue, Nov 25, 2008 at 11:04 PM, nicolas edel <nicolas.edel@...> wrote:

> Now, when in the debugger, I am asking for the local variables of frame #3,
> eg:
> 3] L
> SB-DEBUG::ARG-0  =  (#<BAR {A858559}>)
>
> 3]
>
> I would like to inspect this variable to understand the crash landing. How
> am i suppose to do that, given that I am not using slime at the moment.

(inspect (sb-debug:var 'sb-debug::arg-0))

Cheers,

 -- Nikodemus

Hi everyone,

When I started using Lisp, I received a lot of help on this mailing
list regarding foreign interfaces in SBCL.  I use foreign functions
quite frequently, yet I like to use native Lisp arrays whenever
possible, thus I created the FFA library to hide the plumbing
necessary for foreign interfaces.

A lot of the code in FFA was created to work around the fact that
sb-sys:vector-sap doesn't work for simple-arrays that have a rank
higher than 1.  Currently the workaround is to create a simple array
of rank 1, and then displace to this when I need multidimensional
arrays.

I am about to redesign FFA, and I would like to ask if there is a
chance of getting this limitation removed, ie have sb-sys:vector-sap
work on array of rank higher than 1, or the introduction of another
function that would allow this.  I know little of SBCL's internal
workings, is there anything that makes this impossible, or tricky, or
is it just that no one has asked for it yet?

Thanks,

Tamas

On Fri, Nov 28, 2008 at 10:25 PM, Tamas K Papp <tkpapp@...> wrote:

> A lot of the code in FFA was created to work around the fact that
> sb-sys:vector-sap doesn't work for simple-arrays that have a rank
> higher than 1.  Currently the workaround is to create a simple array
> of rank 1, and then displace to this when I need multidimensional
> arrays.
>
> I am about to redesign FFA, and I would like to ask if there is a
> chance of getting this limitation removed, ie have sb-sys:vector-sap
> work on array of rank higher than 1, or the introduction of another
> function that would allow this.  I know little of SBCL's internal
> workings, is there anything that makes this impossible, or tricky, or
> is it just that no one has asked for it yet?

In SBCL a multidimensional simple-array has an underlying
one-dimensional simple-array which holds the data. You can access it
like so (though this is not officially supported, but support for it
could possible be added.)

(defun simple-array-vector (array)
  (declare (simple-array array))
  (if (sb-kernel:array-header-p array)
      (sb-kernel:%array-data-vector array)
      array))

(simple-array-vector (make-array '(3 3) :initial-contents '((1 2 3) (4
5 6) (7 8 9))))

Cheers,

 -- Nikodemus

On Sat, 29 Nov 2008 15:57:50 +0200, Nikodemus Siivola wrote:

> On Fri, Nov 28, 2008 at 10:25 PM, Tamas K Papp <tkpapp@...> wrote:
> 
>> A lot of the code in FFA was created to work around the fact that
>> sb-sys:vector-sap doesn't work for simple-arrays that have a rank
>> higher than 1.  Currently the workaround is to create a simple array of
>> rank 1, and then displace to this when I need multidimensional arrays.
>>
>> I am about to redesign FFA, and I would like to ask if there is a
>> chance of getting this limitation removed, ie have sb-sys:vector-sap
>> work on array of rank higher than 1, or the introduction of another
>> function that would allow this.  I know little of SBCL's internal
>> workings, is there anything that makes this impossible, or tricky, or
>> is it just that no one has asked for it yet?
> 
> In SBCL a multidimensional simple-array has an underlying
> one-dimensional simple-array which holds the data. You can access it
> like so (though this is not officially supported, but support for it
> could possible be added.)
> 
> (defun simple-array-vector (array)
>   (declare (simple-array array))
>   (if (sb-kernel:array-header-p array)
>       (sb-kernel:%array-data-vector array)
>       array))
> 
> (simple-array-vector (make-array '(3 3) :initial-contents '((1 2 3) (4 5
> 6) (7 8 9))))

Thank you, this is exactly what I was looking for.

If feasible, please make this officially supported, and let me know when 
it is, will then release the new version of FFA.

Thanks,

Tamas

On Jueves 20 Noviembre 2008, Benjamin Lambert wrote:
> Dear SBCL people,
>
> I use SBCL frequently at Carnegie Mellon.  We use it mostly for our
> knowledge representation system, Scone, developed by Scott Fahlman,
> an old CMUCL Lisper.
>
> I recently came across a new problem, and I'm not seeing anything in
> the mailing list history.
>
> We're running on an x86-64 Linux machine with 8GB of RAM.  One person
> in our group was getting error #1 below when he used more than around
> 1GB of memory.  So, I tried recompiling SBCL (1.0.22) a few times
> with greater values for GENCGC-PAGE-SIZE.  Each time I increased it,
> he'd get error #1 eventually, each time after more memory had been
> used. After bumping this up to 32768, he was getting error #1 at
> around 6GB of RAM used.
>
> I tried increasing it once more, first to 64k, then back down to
> 49152.  When I compile with GENCGC-PAGE-SIZE set to either,
> compilation terminates with error #2.  (The main part of this error
> message seems to be this: GC invariant lost, file "gencgc.c", line
> 4503).
>
> Is it possible to increase GENCGC-PAGE-SIZE even more?  If so, is
> that desirable?  What exactly is  GENCGC-PAGE-SIZE?
>
> Ben Lambert
>
>
> Error #1:
>
> fatal error encountered in SBCL pid 18893:
> An mprotect call failed with ENOMEM. This probably means that the
> maximum amount
> of separate memory mappings was exceeded. To fix the problem, either
> increase
> the maximum with e.g. 'echo 262144 > /proc/sys/vm/max_map_count' or
> recompile
> SBCL with a larger value for GENCGC-PAGE-SIZE in 'src/target/
> parms.lisp'.
> Welcome to LDB, a low-level debugger for the Lisp runtime
> environment.
>
> Error #2:
>
> beginning GENESIS, creating core "output/cold-sbcl.core"
> obj/from-xc/src/code/show.lisp-obj
> ....
> obj/from-xc/src/code/late-defbangmethod.lisp-obj
> obj/from-xc/src/pcl/walk.lisp-obj
> [building initial core file in "output/cold-sbcl.core":
> writing 8192 bytes [2 pages] from #<SB!FASL::GSPACE :READ-ONLY>
> writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :STATIC>
> writing 51998720 bytes [12695 pages] from #<SB!FASL::GSPACE :DYNAMIC>
> /(DESCRIPTOR-BITS INITIAL-FUN)=#X1002993D19
> done]
> * //testing for consistency of first and second GENESIS passes
> //header files match between first and second GENESIS -- good
>
> real	13m0.960s
> user	4m32.852s
> sys	0m9.967s
> //entering make-target-2.sh
> //doing warm init - compilation phase
> fatal error encountered in SBCL pid 16153:
> GC invariant lost, file "gencgc.c", line 4503

A quick look into gencgc.c reveals that the heap size should be 
divisible by PAGE_BYTES (that, with gencgc, is equal to 
GENCGC_PAGE_BYTES).

    /* Compute the number of pages needed for the dynamic space.
     * Dynamic space size should be aligned on page size. */
    page_table_pages = dynamic_space_size/PAGE_BYTES;
    gc_assert(dynamic_space_size == npage_bytes(page_table_pages));

> --
> Benjamin Lambert
> Graduate Student of Computer Science
> Carnegie Mellon University
> http://www.cs.cmu.edu/~belamber

>> * //testing for consistency of first and second GENESIS passes
>> //header files match between first and second GENESIS -- good
>>
>> real	13m0.960s
>> user	4m32.852s
>> sys	0m9.967s
>> //entering make-target-2.sh
>> //doing warm init - compilation phase
>> fatal error encountered in SBCL pid 16153:
>> GC invariant lost, file "gencgc.c", line 4503
>
> A quick look into gencgc.c reveals that the heap size should be
> divisible by PAGE_BYTES (that, with gencgc, is equal to
> GENCGC_PAGE_BYTES).
>
>    /* Compute the number of pages needed for the dynamic space.
>     * Dynamic space size should be aligned on page size. */
>    page_table_pages = dynamic_space_size/PAGE_BYTES;
>    gc_assert(dynamic_space_size == npage_bytes(page_table_pages));

I wasn't sure exactly which parameter specifies PAGE_BYTES, but I  
tried compiled again with the following in backend-parms.lisp:

(setf *backend-page-size* 65536)
(def!constant gencgc-page-size 65536)

Compilation finishes OK with these parameters

But then another error shows up when running (below). This time, I  
noticed that when I started SBCL the process was only allocated 4GB of  
memory (previously was 8GB). And this time the error appeared when the  
memory consumption was close to 4GB.

ERROR:

Heap exhausted during garbage collection: 256 bytes available, 272  
requested.
Gen StaPg UbSta LaSta LUbSt Boxed Unboxed LB   LUB  !move  Alloc   
Waste   Trig
  WP  GCs Mem-age
  0:     0     0     0     0     0     0     0     0     0         
0     0  2000
000    0   0  0.0000
  1:     0     0     0     0     0     0     0     0     0         
0     0  2000
000    0   0  0.0000
  2:     0     0     0     0     0     0     0     0     0         
0     0  2000
000    0   0  0.0000
  3: 18702 19623     0     0  2316  1559     0     0     0 253304736  
647264 367
902928    0   1  1.4445
  4: 65533 64042     0     0 10721  6663  1731  1539    10 1350800224  
2780320 7
78330752 9602   1  1.3438
  5: 56837 57662     0     0 21457 15654  1569  1745    25 2643916288  
5376512 2000000 22023   0  0.5391
  6:     0     0     0     0   581     0     0     0     0  
38076416     0  2000
000  535   0  0.0000
  Total bytes allocated=4286097664
GC control variables:
         *GC-INHIBIT* = false
         *GC-PENDING* = true
fatal error encountered in SBCL pid 23666:
Heap exhausted, game over.

Two questions.

1. How do I make DOS line-endings the default for line-oriented i/o.

2. Does SBCL support accessing files via UNC:
http://en.wikipedia.org/wiki/Path_%28computing%29#Uniform_Naming_Convention?

Thanks,

Matt

Tamas K Papp <tkpapp@...> writes:

> I use Debian, and prefer to install SBCL as a deb package - last time I 
> tried installing from the binary tarball, I could not get CLC working.  
> But apparently the debian package is still at version 1.0.18.0.  Does 
> anyone know if there is a reason for this lag?

I believe none other than the usual debian lag to update packages :-(
that's the main reason I stopped using debian after 8+ years.

Pedro

On Tue, 18 Nov 2008 12:19:52 -0300, Pedro Kröger wrote:

> Tamas K Papp <tkpapp@...> writes:
> 
>> I use Debian, and prefer to install SBCL as a deb package - last time I
>> tried installing from the binary tarball, I could not get CLC working.
>> But apparently the debian package is still at version 1.0.18.0.  Does
>> anyone know if there is a reason for this lag?
> 
> I believe none other than the usual debian lag to update packages :-(
> that's the main reason I stopped using debian after 8+ years.

May I ask what you are using now (if it is Linux?)

Thanks,

Tamas

Tamas K Papp <tkpapp@...> writes:

> May I ask what you are using now (if it is Linux?)

sure, I'm using arch linux.

Pedro

* Tamas K. Papp:

> I use Debian, and prefer to install SBCL as a deb package - last time I 
> tried installing from the binary tarball, I could not get CLC working.  
> But apparently the debian package is still at version 1.0.18.0.  Does 
> anyone know if there is a reason for this lag?

Debian is preparing a release, so we are currently very conservative
about incorporating new upstream versions.

On Tue, 18 Nov 2008 17:45:41 +0100, Florian Weimer wrote:

> * Tamas K. Papp:
> 
>> I use Debian, and prefer to install SBCL as a deb package - last time I
>> tried installing from the binary tarball, I could not get CLC working.
>> But apparently the debian package is still at version 1.0.18.0.  Does
>> anyone know if there is a reason for this lag?
> 
> Debian is preparing a release, so we are currently very conservative
> about incorporating new upstream versions.

My understanding is that it is testing that is frozen, and becomes the 
new stable.  Couldn't the new sbcl version go to unstable or experimental?

Tamas

"Chun Tian (binghe)" <binghe.lisp@...> writes:

> So which version of SBCL in Arch Linux at current?

1.0.22. you can check here:

http://www.archlinux.org/packages/?q=sbcl

the beauty of arch linux is that it is *very* easy to make packages, so
even if a package is behind I just download the script to make the
package, update it and compile myself.

Pedro

* Tamas K. Papp:

>> Debian is preparing a release, so we are currently very conservative
>> about incorporating new upstream versions.
>
> My understanding is that it is testing that is frozen, and becomes
> the new stable.  Couldn't the new sbcl version go to unstable or
> experimental?

experimental would be fine.  Updates to testing should still land via
unstable.

On Nov 17, 2008, at 10:54 AM, Didier Verna wrote:

> So how is it that with a slot type of fixnum, things still work,  
> even if
> by accident?


Fixnums are already tagged objects, so there's no special  
representation necessary to store an unboxed fixnum in the structure.  
This means that if you lie to the compiler and put some other pointer  
in there, it'll come out with the same representation when you read  
the slot value. If the recipient also assumes a fixnum, strangeness  
will ensue, but if the recipient is safe code it will properly check  
the tag to determine the type.

If you were to make the slot type (unsigned-byte 32), you'd see the  
type of strangeness you're expecting.
--
Brian Mastenbrook
brian@...
http://brian.mastenbrook.net/

Didier Verna <didier.verna@...> writes:

> So how is it that with a slot type of fixnum, things still work, even if
> by accident?

Well, "work".  Fixnum structure slots are optimized, but their
optimized representation is still tagged, so if you manage to store
something that's not a fixnum in there you will get it back unchanged,
as no tagging or untagging will be done at any point.

That's not all there is to it, though; not only is there no need to
tag an entry stored in a fixnum structure slot, there's no need to
consider it as a possible pointer: I put "work" in scare quotes above
because it will probably be OK until the float (or other
non-immediate object) that you put in there is GCed, at which point you will
probably crash the lisp.  So don't do that.

The reason that a single-float structure slot is different immediately
is that the representation in the slot is untagged, so the underlying
representation is different from the tagged lispobj, and is therefore
always retagged on access.