When creating an array
(defparameter *memory*
(make-array array-dimension-limit :element-type
'(unsigned-byte 8)))
it seems that it does not return what I expect, the equivalent of
unsigned char memory[16777216];
In other words, a contigous chunk of memory, 16Mb large.
Am I misinterpreting what the term specialised array means ?
Oh, and I do mean Haible & Stoll CLISP, in case anyone would wonder.
Thanks,
Jurgen
On Nov 3, 4:05 pm, jurgen_defurne <··············@pandora.be> wrote:
> When creating an array
>
> (defparameter *memory*
> (make-array array-dimension-limit :element-type
> '(unsigned-byte 8)))
>
> it seems that it does not return what I expect, the equivalent of
>
> unsigned char memory[16777216];
>
> In other words, a contigous chunk of memory, 16Mb large.
>
> Am I misinterpreting what the term specialised array means ?
>
> Oh, and I do mean Haible & Stoll CLISP, in case anyone would wonder.
>
> Thanks,
>
> Jurgen
SBCL seems to do what I expect. I get my array, and when I reference
things, my memory does not blow up, but I get an immediate result. In
fact, when I evaluate *memory*, it just prints out the contents of the
array cells without any weird behaviour what so ever.
Unfortunately, when I write CL I like to write portable code. Portable
between CL implementations, and portable between Linux and Windows.
The previous behaviour makes CLISP unsuited as a testbed for my next
project, which is a pity because I find it the best way to use CL code
on Linux and Windows.
Regards,
Jurgen
From: Tamas K Papp
Subject: Re: Is it possible for CLISP to return a real byte array ?
Date:
Message-ID: <6n8jvjFjpal7U1@mid.individual.net>
On Mon, 03 Nov 2008 07:05:30 -0800, jurgen_defurne wrote:
> When creating an array
>
> (defparameter *memory*
> (make-array array-dimension-limit :element-type
> '(unsigned-byte 8)))
>
> it seems that it does not return what I expect, the equivalent of
>
> unsigned char memory[16777216];
Well, what is it that you expect?
Welcome to GNU CLISP 2.44.1 (2008-02-23) <http://clisp.cons.org/>
[1]> array-dimension-limit
16777215
[2]> (defparameter *m* (make-array array-dimension-limit :element-type
'(unsigned-byte 8)))
*M*
[3]> (type-of *m*)
(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (16777215))
How does this fail to satisfy your expectations?
> In other words, a contigous chunk of memory, 16Mb large.
> Am I misinterpreting what the term specialised array means ?
AFAIK nothing in the CL standard guarantees that this will be a
contiguous chunk of memory, but that's how most implementations would do
it I guess. Why do you want that? You only need that if you are passing
it to foreign functions or something. Are you? Then read the
appropriate section of the CLISP manual.
> Oh, and I do mean Haible & Stoll CLISP, in case anyone would wonder.
HTH,
Tamas
On Nov 3, 4:34 pm, Tamas K Papp <······@gmail.com> wrote:
> On Mon, 03 Nov 2008 07:05:30 -0800, jurgen_defurne wrote:
> > When creating an array
>
> > (defparameter *memory*
> > (make-array array-dimension-limit :element-type
> > '(unsigned-byte 8)))
>
> > it seems that it does not return what I expect, the equivalent of
>
> > unsigned char memory[16777216];
>
> Well, what is it that you expect?
>
> Welcome to GNU CLISP 2.44.1 (2008-02-23) <http://clisp.cons.org/>
>
> [1]> array-dimension-limit
> 16777215
> [2]> (defparameter *m* (make-array array-dimension-limit :element-type
> '(unsigned-byte 8)))
> *M*
> [3]> (type-of *m*)
> (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (16777215))
>
> How does this fail to satisfy your expectations?
>
> > In other words, a contigous chunk of memory, 16Mb large.
> > Am I misinterpreting what the term specialised array means ?
>
> AFAIK nothing in the CL standard guarantees that this will be a
> contiguous chunk of memory, but that's how most implementations would do
> it I guess. Why do you want that? You only need that if you are passing
> it to foreign functions or something. Are you? Then read the
> appropriate section of the CLISP manual.
>
> > Oh, and I do mean Haible & Stoll CLISP, in case anyone would wonder.
>
> HTH,
>
> Tamas
Yeah, sorry, it was posted in a hurry. Above, you saw what I did. What
happens next is this :
(aref *memory* 0) returns a value
(aref *memory* 16777215) starts allocating memory, way more than 16
Mb. Looking over the Task Manager I could see that the CLISP program
allocated up to 1 Gb of memory before giving up, and it takes some
time. I.o.w. the array is dynamic, and gets allocated memory upon
reference of a specific index.
What I expected was that I would get just a single contiguous block of
bytes, allocated at once, and that I could handle as a separate memory
space.
Regards,
Jurgen
From: Tamas K Papp
Subject: Re: Is it possible for CLISP to return a real byte array ?
Date:
Message-ID: <6n8r7mFkd85mU1@mid.individual.net>
On Mon, 03 Nov 2008 09:23:35 -0800, jurgen_defurne wrote:
> On Nov 3, 4:34 pm, Tamas K Papp <······@gmail.com> wrote:
>> On Mon, 03 Nov 2008 07:05:30 -0800, jurgen_defurne wrote:
>> > When creating an array
>>
>> > (defparameter *memory*
>> > (make-array array-dimension-limit :element-type
>> > '(unsigned-byte 8)))
>>
>> > it seems that it does not return what I expect, the equivalent of
>>
>> > unsigned char memory[16777216];
>>
>> Well, what is it that you expect?
>>
>> Welcome to GNU CLISP 2.44.1 (2008-02-23) <http://clisp.cons.org/>
>>
>> [1]> array-dimension-limit
>> 16777215
>> [2]> (defparameter *m* (make-array array-dimension-limit :element-type
>> '(unsigned-byte 8)))
>> *M*
>> [3]> (type-of *m*)
>> (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (16777215))
>>
>> How does this fail to satisfy your expectations?
>>
>> > In other words, a contigous chunk of memory, 16Mb large. Am I
>> > misinterpreting what the term specialised array means ?
>>
>> AFAIK nothing in the CL standard guarantees that this will be a
>> contiguous chunk of memory, but that's how most implementations would
>> do it I guess. Why do you want that? You only need that if you are
>> passing it to foreign functions or something. Are you? Then read the
>> appropriate section of the CLISP manual.
>>
>> > Oh, and I do mean Haible & Stoll CLISP, in case anyone would wonder.
>>
>> HTH,
>>
>> Tamas
>
> Yeah, sorry, it was posted in a hurry. Above, you saw what I did. What
> happens next is this :
>
> (aref *memory* 0) returns a value
>
> (aref *memory* 16777215) starts allocating memory, way more than 16 Mb.
> Looking over the Task Manager I could see that the CLISP program
> allocated up to 1 Gb of memory before giving up, and it takes some time.
> I.o.w. the array is dynamic, and gets allocated memory upon reference of
> a specific index.
>
> What I expected was that I would get just a single contiguous block of
> bytes, allocated at once, and that I could handle as a separate memory
> space.
Works fine for me:
Welcome to GNU CLISP 2.44.1 (2008-02-23) <http://clisp.cons.org/>
[1]> (defparameter *m* (make-array array-dimension-limit :element-type
'(unsigned-byte 8)))
*M*
[2]> (aref *m* (1- array-dimension-limit))
0
[3]> array-dimension-limit
16777215
This is on Linux. My laptop only has 1 GB RAM, and clisp is using very
little of it.
If I were you, I would continue with this on clisp-devel, they will be
able to offer more specific advice. Make sure you use the latest version.
HTH,
Tamas
In article <··············@mid.individual.net>,
Tamas K Papp <······@gmail.com> wrote:
> On Mon, 03 Nov 2008 09:23:35 -0800, jurgen_defurne wrote:
>
> > On Nov 3, 4:34 pm, Tamas K Papp <······@gmail.com> wrote:
> >> On Mon, 03 Nov 2008 07:05:30 -0800, jurgen_defurne wrote:
> >> > When creating an array
> >>
> >> > (defparameter *memory*
> >> > (make-array array-dimension-limit :element-type
> >> > '(unsigned-byte 8)))
> >>
> >> > it seems that it does not return what I expect, the equivalent of
> >>
> >> > unsigned char memory[16777216];
> >>
> >> Well, what is it that you expect?
> >>
> >> Welcome to GNU CLISP 2.44.1 (2008-02-23) <http://clisp.cons.org/>
> >>
> >> [1]> array-dimension-limit
> >> 16777215
> >> [2]> (defparameter *m* (make-array array-dimension-limit :element-type
> >> '(unsigned-byte 8)))
> >> *M*
> >> [3]> (type-of *m*)
> >> (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (16777215))
> >>
> >> How does this fail to satisfy your expectations?
> >>
> >> > In other words, a contigous chunk of memory, 16Mb large. Am I
> >> > misinterpreting what the term specialised array means ?
> >>
> >> AFAIK nothing in the CL standard guarantees that this will be a
> >> contiguous chunk of memory, but that's how most implementations would
> >> do it I guess. Why do you want that? You only need that if you are
> >> passing it to foreign functions or something. Are you? Then read the
> >> appropriate section of the CLISP manual.
> >>
> >> > Oh, and I do mean Haible & Stoll CLISP, in case anyone would wonder.
> >>
> >> HTH,
> >>
> >> Tamas
> >
> > Yeah, sorry, it was posted in a hurry. Above, you saw what I did. What
> > happens next is this :
> >
> > (aref *memory* 0) returns a value
> >
> > (aref *memory* 16777215) starts allocating memory, way more than 16 Mb.
> > Looking over the Task Manager I could see that the CLISP program
> > allocated up to 1 Gb of memory before giving up, and it takes some time.
> > I.o.w. the array is dynamic, and gets allocated memory upon reference of
> > a specific index.
> >
> > What I expected was that I would get just a single contiguous block of
> > bytes, allocated at once, and that I could handle as a separate memory
> > space.
>
> Works fine for me:
>
> Welcome to GNU CLISP 2.44.1 (2008-02-23) <http://clisp.cons.org/>
>
> [1]> (defparameter *m* (make-array array-dimension-limit :element-type
> '(unsigned-byte 8)))
See that ANSI CL says that ARRAY-DIMENSION-LIMIT is not a valid
dimension:
http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_v.htm#valid_array_dimension
The dimension has to be LESS than ARRAY-DIMENSION-LIMIT.
> *M*
> [2]> (aref *m* (1- array-dimension-limit))
> 0
> [3]> array-dimension-limit
> 16777215
>
> This is on Linux. My laptop only has 1 GB RAM, and clisp is using very
> little of it.
>
> If I were you, I would continue with this on clisp-devel, they will be
> able to offer more specific advice. Make sure you use the latest version.
>
> HTH,
>
> Tamas
--
http://lispm.dyndns.org/
From: Tamas K Papp
Subject: Re: Is it possible for CLISP to return a real byte array ?
Date:
Message-ID: <6n8ve5Fk937jU1@mid.individual.net>
On Mon, 03 Nov 2008 19:05:01 +0100, Rainer Joswig wrote:
>> [1]> (defparameter *m* (make-array array-dimension-limit :element-type
>> '(unsigned-byte 8)))
>
> See that ANSI CL says that ARRAY-DIMENSION-LIMIT is not a valid
> dimension:
>
> http://www.lispworks.com/documentation/HyperSpec/
Body/26_glo_v.htm#valid_array_dimension
>
> The dimension has to be LESS than ARRAY-DIMENSION-LIMIT.
Thanks Rainer, I didn't know this. In this case, it would be prudent for
an implementation to signal an error, wouldn't it?
Tamas
In article <··············@mid.individual.net>,
Tamas K Papp <······@gmail.com> wrote:
> On Mon, 03 Nov 2008 19:05:01 +0100, Rainer Joswig wrote:
>
> >> [1]> (defparameter *m* (make-array array-dimension-limit :element-type
> >> '(unsigned-byte 8)))
> >
> > See that ANSI CL says that ARRAY-DIMENSION-LIMIT is not a valid
> > dimension:
> >
> > http://www.lispworks.com/documentation/HyperSpec/
> Body/26_glo_v.htm#valid_array_dimension
> >
> > The dimension has to be LESS than ARRAY-DIMENSION-LIMIT.
>
> Thanks Rainer, I didn't know this. In this case, it would be prudent for
> an implementation to signal an error, wouldn't it?
>
> Tamas
Sure, let the respective maintainers know.
Several implementation will signal an error.
--
http://lispm.dyndns.org/
In article
<····································@n33g2000pri.googlegroups.com>,
jurgen_defurne <··············@pandora.be> wrote:
> On Nov 3, 4:34 pm, Tamas K Papp <······@gmail.com> wrote:
> > On Mon, 03 Nov 2008 07:05:30 -0800, jurgen_defurne wrote:
> > > When creating an array
> >
> > > (defparameter *memory*
> > > (make-array array-dimension-limit :element-type
> > > '(unsigned-byte 8)))
> >
> > > it seems that it does not return what I expect, the equivalent of
> >
> > > unsigned char memory[16777216];
> >
> > Well, what is it that you expect?
> >
> > Welcome to GNU CLISP 2.44.1 (2008-02-23) <http://clisp.cons.org/>
> >
> > [1]> array-dimension-limit
> > 16777215
> > [2]> (defparameter *m* (make-array array-dimension-limit :element-type
> > '(unsigned-byte 8)))
> > *M*
> > [3]> (type-of *m*)
> > (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (16777215))
> >
> > How does this fail to satisfy your expectations?
> >
> > > In other words, a contigous chunk of memory, 16Mb large.
> > > Am I misinterpreting what the term specialised array means ?
> >
> > AFAIK nothing in the CL standard guarantees that this will be a
> > contiguous chunk of memory, but that's how most implementations would do
> > it I guess. Why do you want that? You only need that if you are passing
> > it to foreign functions or something. Are you? Then read the
> > appropriate section of the CLISP manual.
> >
> > > Oh, and I do mean Haible & Stoll CLISP, in case anyone would wonder.
> >
> > HTH,
> >
> > Tamas
>
> Yeah, sorry, it was posted in a hurry. Above, you saw what I did. What
> happens next is this :
>
> (aref *memory* 0) returns a value
>
> (aref *memory* 16777215) starts allocating memory, way more than 16
> Mb. Looking over the Task Manager I could see that the CLISP program
> allocated up to 1 Gb of memory before giving up, and it takes some
> time. I.o.w. the array is dynamic, and gets allocated memory upon
> reference of a specific index.
>
> What I expected was that I would get just a single contiguous block of
> bytes, allocated at once, and that I could handle as a separate memory
> space.
>
> Regards,
>
> Jurgen
Note that the dimension must be LESS than array-dimension-limit.
http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_v.htm#valid_array_dimension
So: (make-array array-dimension-limit) is already wrong.
Note also that then the array index is in the range of 0 .. (- array-dimension-limit 2).
To create the largest one-dimensional array do:
(make-array (1- array-dimension-limit))
To access the element with the highest index do:
(aref an-array (- array-dimension-limit 2))
--
http://lispm.dyndns.org/
On Nov 3, 7:02 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@n33g2000pri.googlegroups.com>,
>
>
>
> jurgen_defurne <··············@pandora.be> wrote:
> > On Nov 3, 4:34 pm, Tamas K Papp <······@gmail.com> wrote:
> > > On Mon, 03 Nov 2008 07:05:30 -0800, jurgen_defurne wrote:
> > > > When creating an array
>
> > > > (defparameter *memory*
> > > > (make-array array-dimension-limit :element-type
> > > > '(unsigned-byte 8)))
>
> > > > it seems that it does not return what I expect, the equivalent of
>
> > > > unsigned char memory[16777216];
>
> > > Well, what is it that you expect?
>
> > > Welcome to GNU CLISP 2.44.1 (2008-02-23) <http://clisp.cons.org/>
>
> > > [1]> array-dimension-limit
> > > 16777215
> > > [2]> (defparameter *m* (make-array array-dimension-limit :element-type
> > > '(unsigned-byte 8)))
> > > *M*
> > > [3]> (type-of *m*)
> > > (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (16777215))
>
> > > How does this fail to satisfy your expectations?
>
> > > > In other words, a contigous chunk of memory, 16Mb large.
> > > > Am I misinterpreting what the term specialised array means ?
>
> > > AFAIK nothing in the CL standard guarantees that this will be a
> > > contiguous chunk of memory, but that's how most implementations would do
> > > it I guess. Why do you want that? You only need that if you are passing
> > > it to foreign functions or something. Are you? Then read the
> > > appropriate section of the CLISP manual.
>
> > > > Oh, and I do mean Haible & Stoll CLISP, in case anyone would wonder.
>
> > > HTH,
>
> > > Tamas
>
> > Yeah, sorry, it was posted in a hurry. Above, you saw what I did. What
> > happens next is this :
>
> > (aref *memory* 0) returns a value
>
> > (aref *memory* 16777215) starts allocating memory, way more than 16
> > Mb. Looking over the Task Manager I could see that the CLISP program
> > allocated up to 1 Gb of memory before giving up, and it takes some
> > time. I.o.w. the array is dynamic, and gets allocated memory upon
> > reference of a specific index.
>
> > What I expected was that I would get just a single contiguous block of
> > bytes, allocated at once, and that I could handle as a separate memory
> > space.
>
> > Regards,
>
> > Jurgen
>
> Note that the dimension must be LESS than array-dimension-limit.http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_v.htm#va...
>
> So: (make-array array-dimension-limit) is already wrong.
>
> Note also that then the array index is in the range of 0 .. (- array-dimension-limit 2).
>
> To create the largest one-dimensional array do:
>
> (make-array (1- array-dimension-limit))
>
> To access the element with the highest index do:
>
> (aref an-array (- array-dimension-limit 2))
>
> --http://lispm.dyndns.org/
Yes, and after that I discovered that, indeed, CLISP Does The Right
Thing(C) after all. The error occurs only when the requested index is
too large, in which case you normally would expect your system to
throw an exception.
However, I was also busy with several older versions of CLISP, so I
will also check out what CLISP currently does.
Regards,
Jurgen
jurgen_defurne <··············@pandora.be> writes:
> When creating an array
>
> (defparameter *memory*
> (make-array array-dimension-limit :element-type
> '(unsigned-byte 8)))
>
> it seems that it does not return what I expect, the equivalent of
>
> unsigned char memory[16777216];
>
> In other words, a contigous chunk of memory, 16Mb large.
>
> Am I misinterpreting what the term specialised array means ?
C/USER[3]> (UPGRADED-ARRAY-ELEMENT-TYPE '(unsigned-byte 8))
(UNSIGNED-BYTE 8)
C/USER[4]> (array-element-type (make-array 1000 :element-type '(unsigned-byte 8)))
(UNSIGNED-BYTE 8)
On the other hand, going close to ARRAY-DIMENSION-LIMIT may make it fail.
I'd expect (make-array (1- array-dimension-limit) :element-type '(unsigned-byte 8))
to give a good array, but in the version of clisp I use on this 64-bit
machine, this breaks with:
*** - handle_fault error2 ! address = 0x4341906ae not in [0x333aad000,0x33409b0a8) !
SIGSEGV cannot be cured. Fault address = 0x4341906ae.
Permanently allocated: 164584 bytes.
Currently in use: 548480976 bytes.
Free space: 0 bytes.
Process inferior-lisp segmentation fault
--
__Pascal Bourguignon__
On Nov 3, 4:05 pm, jurgen_defurne <··············@pandora.be> wrote:
> When creating an array
>
> (defparameter *memory*
> (make-array array-dimension-limit :element-type
> '(unsigned-byte 8)))
>
> it seems that it does not return what I expect, the equivalent of
>
> unsigned char memory[16777216];
>
> In other words, a contigous chunk of memory, 16Mb large.
>
> Am I misinterpreting what the term specialised array means ?
>
> Oh, and I do mean Haible & Stoll CLISP, in case anyone would wonder.
>
> Thanks,
>
> Jurgen
I did some further investigation in CLISP, and I know understand what
is really going on :
(defparameter *memory* (make-array 100 :element-type '(unsigned-byte
8)))
*MEMORY*
[4]> (aref *memory* 90)
0
[5]> (aref *memory* 98)
0
[6]> (aref *memory* 99)
0
[7]> (aref *memory* 100)
*** - AREF: index 100 voor
#(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0)
ligt buiten bereik
Mogelijkheden om opnieuw te beginnen:
ABORT :R1 Abort main loop
Break 1 [8]>
So, an exception is really generated, but the exception mechanism
tries to print out the complete contents of the array, and that is
where it goes wrong : this code cannot return, because it cannot
allocate enough memory to do what it wants.
Does anybody know if, and how if yes, I can turn of this feature ?
Otherwise I will need to add bounds checking code myself.
Regards,
Jurgen
From: Nikodemus Siivola
Subject: Re: Is it possible for CLISP to return a real byte array ?
Date:
Message-ID: <gepiqn$q6i$1@nyytiset.pp.htv.fi>
jurgen_defurne wrote:
> So, an exception is really generated, but the exception mechanism
> tries to print out the complete contents of the array, and that is
> where it goes wrong : this code cannot return, because it cannot
> allocate enough memory to do what it wants.
>
> Does anybody know if, and how if yes, I can turn of this feature ?
> Otherwise I will need to add bounds checking code myself.
(setf *print-array* nil) will probably help, but I assume Clisp hackers would
appreciate a bug report.
Cheers,
-- Nikodemus
On Nov 4, 2:31 pm, Nikodemus Siivola <·········@random-state.net>
wrote:
> jurgen_defurne wrote:
> > So, an exception is really generated, but the exception mechanism
> > tries to print out the complete contents of the array, and that is
> > where it goes wrong : this code cannot return, because it cannot
> > allocate enough memory to do what it wants.
>
> > Does anybody know if, and how if yes, I can turn of this feature ?
> > Otherwise I will need to add bounds checking code myself.
>
> (setf *print-array* nil) will probably help, but I assume Clisp hackers would
> appreciate a bug report.
>
> Cheers,
>
> -- Nikodemus
Thanks, works as it should.
Regards,
Jurgen
In article
<····································@e1g2000pra.googlegroups.com>,
jurgen_defurne <··············@pandora.be> wrote:
> On Nov 3, 4:05�pm, jurgen_defurne <··············@pandora.be> wrote:
> > When creating an array
> >
> > (defparameter *memory*
> > � � � � � � � (make-array array-dimension-limit :element-type
> > '(unsigned-byte 8)))
> >
> > it seems that it does not return what I expect, the equivalent of
> >
> > unsigned char memory[16777216];
> >
> > In other words, a contigous chunk of memory, 16Mb large.
> >
> > Am I misinterpreting what the term specialised array means ?
> >
> > Oh, and I do mean Haible & Stoll CLISP, in case anyone would wonder.
> >
> > Thanks,
> >
> > Jurgen
>
> I did some further investigation in CLISP, and I know understand what
> is really going on :
>
> (defparameter *memory* (make-array 100 :element-type '(unsigned-byte
> 8)))
> *MEMORY*
> [4]> (aref *memory* 90)
> 0
> [5]> (aref *memory* 98)
> 0
> [6]> (aref *memory* 99)
> 0
> [7]> (aref *memory* 100)
>
> *** - AREF: index 100 voor
> #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0)
> ligt buiten bereik
> Mogelijkheden om opnieuw te beginnen:
> ABORT :R1 Abort main loop
> Break 1 [8]>
>
> So, an exception is really generated, but the exception mechanism
> tries to print out the complete contents of the array, and that is
> where it goes wrong : this code cannot return, because it cannot
> allocate enough memory to do what it wants.
>
> Does anybody know if, and how if yes, I can turn of this feature ?
> Otherwise I will need to add bounds checking code myself.
>
> Regards,
>
> Jurgen
Compare that with LispWorks:
CL-USER 4 > *print-array*
T
CL-USER 5 > *print-length*
NIL
CL-USER 6 > (let ((a (make-array 100)))
(setf (aref a 200) t))
Error: The subscript 200 exceeds the limit 99 for the first dimension
of the array #(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL ...).
1 (abort) Return to level 0.
2 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
CL-USER 7 : 1 > *print-length*
40
CL-USER 8 : 1 > *print-array*
T
CL-USER 9 : 1 > :c 1
CL-USER 10 > *print-length*
NIL
When LispWorks enters the debugger, it rebinds the variable *print-length*
to 40. When we leave the debugger, *print-length* is restored.
So that takes care of reporting errors on long data structures.
One can change that via DBG:*DEBUG-PRINT-LENGTH* .
Genera for example binds *print-array* and *print-circle* to NIL
when entering the debugger.
See the Common Lisp printer control variables:
http://www.lispworks.com/documentation/HyperSpec/Body/v_pr_lev.htm
http://www.lispworks.com/documentation/HyperSpec/Body/v_pr_ar.htm
http://www.lispworks.com/documentation/HyperSpec/Body/v_pr_cir.htm
http://www.lispworks.com/documentation/HyperSpec/Body/v_pr_pre.htm
http://www.lispworks.com/documentation/HyperSpec/Body/v_pr_rda.htm
and so on. It makes sense to set those to some application
specific values or rebind them in some situations.
--
http://lispm.dyndns.org/