Hi;
I have done some debugging. It seems the problem of serializing integers is
caused by mixing of the types int and integer in the foreign interface?
I change the function read-int in the package memutil.lisp to:
(defun pread-int (buf offset)
"Read a 32-bit signed integer from a foreign char buffer."
(declare (optimize speed (safety 1) (debug 1))
(type (alien (* char)) buf)
(type fixnum offset))
(print "Offset: ") (print offset)
(the (signed-byte 32)
(deref (cast (sap-alien (sap+ (alien-sap buf) offset) (* char))
(* int))))) ;; !!!!!!!!!!!!! Changed from (* integer)
After this the integer-test runs fine. I will do some more testing.
Cheers,
Petter Egesund
-----Opprinnelig melding-----
Fra: Ian Eslick [mailto:[EMAIL PROTECTED]
Sendt: 21. august 2006 16:11
Til: Petter Egesund
Kopi: Robert L. Read; [EMAIL PROTECTED]; Ian Eslick
Emne: Re: SV: SV: SV: SV: SV: [elephant-devel] Memory error with Elephant
Interesting. That explains the source of our problem (serializing
integers) but I still don't understand why. Even if the 4 byte assumption in
lisp keeps us from expanding the buffer streams appropriately the write should
still write the first 8 bytes correctly and thus be able to read it correctly.
It almost looks like it is writing 4 bytes but reading 8.
1) Try replacing the #x45 with #x00 in my test code
The other test is to see what is actually being put into the buffer stream.
2) replace #x45 with #x40302010 and add the following code instead of the
buffer-read-int at the end:
(loop for i from 0 upto 16 do
(format t "byte ~A: ~A~%" i (buffer-read-byte bs)))
Ian
Petter Egesund wrote:
>
>
> ----------------------------------------------------------------------
> --
> *Fra:* Robert L. Read [mailto:[EMAIL PROTECTED]
> *Sendt:* 19. august 2006 22:26
> *Til:* Petter Egesund
> *Kopi:* [EMAIL PROTECTED]; Ian Eslick
> *Emne:* Re: SV: SV: SV: SV: [elephant-devel] Memory error with
> Elephant
>
> Personally, the fact that buffer-write-int in memutil.lisp assumes a
> 4-byte integer:
> (defun buffer-write-int (i bs)
> "Write a 32-bit signed integer."
> (declare (optimize (speed 3) (safety 0))
> (type buffer-stream bs)
> (type (signed-byte 32) i))
> (with-struct-slots ((buf buffer-stream-buffer)
> (size buffer-stream-size)
> (len buffer-stream-length))
> bs
> (let ((needed (+ size 4)))
> (when (> needed len)
> (resize-buffer-stream bs needed))
> (write-int buf i size)
> (setf size needed)
> nil)))
> While the c-code version of write-int in libmemutil.c uses the
> "sizeof(int)" paradigm seems fragile on a 64-bit architecture:
>
> void write_int(char *buf, int num, int offset) {
> memcpy(buf+offset, &num, sizeof(int)); }
>
> I would like to know if "sizeof(int)" is 8 or 4 as compiled.
> A simple C program (or reading the f-ing manual) would answer that
> question.
> An awful hack that would let us test things would be to hard-wire "4"
> in place of
> "sizeof(int)" in the libmemutil.c file; I don't know enough about
> UFFI and sap-alien to know if that would work.
>
> A better solution is to expose a C-function that simply gives the size
> of an integer in bytes to LISP (it could be added to libmemutil.c
> file) and then have memutil.lisp use that in place of the assumption
> "4".)
>
> How this changes the typing in memutil.lisp, I'm not sure ---- can
> we/should we force the
> AMD64 to use 32-bit integers, or should we rewrite memutil.lisp to
> determine based on its compilation environment the size of an integer?
> Either solution is better than what we have now.
>
>
> On Sat, 2006-08-19 at 20:53 +0200, Petter Egesund wrote:
>> It looks like below. Certainly not 35.
>>
>> Petter
>>
>> -------
>>
>> ELE> (defun fixnum-test ()
>> (with-buffer-streams (bs)
>> (buffer-write-int #x23 bs)
>> (buffer-write-int #x45 bs)
>> (reset-buffer-stream bs)
>> (buffer-read-int bs)))
>> ; in: LAMBDA NIL
>> ; (ELEPHANT-MEMUTIL:BUFFER-WRITE-INT 69 ELEPHANT::BS)
>> ; --> BLOCK ELEPHANT-MEMUTIL::WITH-STRUCT-SLOTS SYMBOL-MACROLET LET
>> WHEN ; --> COND IF PROGN ; ==>
>> ; (ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM ELEPHANT-MEMUTIL::BS
>> ; ELEPHANT-MEMUTIL::NEEDED)
>> ;
>> ; note: doing signed word to integer coercion (cost 20)
>>
>> ; (ELEPHANT-MEMUTIL:BUFFER-WRITE-INT 35 ELEPHANT::BS)
>> ; --> BLOCK ELEPHANT-MEMUTIL::WITH-STRUCT-SLOTS SYMBOL-MACROLET LET
>> WHEN ; --> COND IF PROGN ; ==>
>> ; (ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM ELEPHANT-MEMUTIL::BS
>> ; ELEPHANT-MEMUTIL::NEEDED)
>> ;
>> ; note: doing signed word to integer coercion (cost 20) ; ;
>> compilation unit finished
>> ; printed 2 notes
>> FIXNUM-TEST
>> ELE> (fixnum-test)
>> 296352743459
>> ELE>
>>
>>
>>
>>
>>
>>
>> -----Opprinnelig melding-----
>> Fra: Ian Eslick [mailto:[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>]
>> Sendt: 19. august 2006 20:21
>> Til: Petter Egesund
>> Kopi: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>; Robert L.
>> Read; Ian Eslick
>> Emne: Re: SV: SV: SV: [elephant-devel] Memory error with Elephant
>>
>> What happens if you write two fixnums and read a fixnum by hand?
>>
>> (defun fixnum-test ()
>> (with-buffer-streams (bs)
>> (buffer-write-int #x23 bs)
>> (buffer-write-int #x45 bs)
>> (reset-buffer-stream bs)
>> (buffer-read-int bs)))
>>
>> Running this function should return 35 (#x23).
>>
>> Ian
>>
>> Petter Egesund wrote:
>> > Hi, thanks for advices.
>> >
>> > I have had a quick look. It seems the problem lies in the
>> > serializing, which might be illustrated by the fact that the error
>> > occurs when entering these small lines;
>> >
>> > (in-package "ELEPHANT")
>> > (defvar str (coerce "this is a test" 'base-string))
>> > (ser-deser-equal
>> > str)
>> >
>> > I have had a look at the code, a rather wild guess might be that the
>> > problem is related to the function (buffer-read-fixnum bs) combined with
>> > reading from the buffer? Seems like byte-length, endian and stuff like
>> > this is relevant?
>> >
>> > I have not had other problems with the 64-bit Sbcl so far. I have been
>> > running a few other programs, like a web-server and some parser stuff. The
>> > 32-bits version did run, but it had problems with linking to libraries
>> > (which might probably be solved). On my private PC which is a 32-bits
>> > Slackware, everything seems to work well, Elephant also.
>> >
>> > I will try to do some tracing on Tonday/Tuesday.
>> >
>> > Cheers,
>> >
>> > Petter
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > -----Opprinnelig melding-----
>> > Fra: Ian Eslick [mailto:[EMAIL PROTECTED]
>> > <mailto:[EMAIL PROTECTED]>]
>> > Sendt: 19. august 2006 01:11
>> > Til: Robert L. Read
>> > Kopi: Petter Egesund; Ian Eslick
>> > Emne: Re: SV: SV: [elephant-devel] Memory error with Elephant
>> >
>> > I got my head wrapped around Elephant again recently so I'd be happy to
>> > assist. I'm on vacation this week and the latter part of next week so
>> > won't be highly responsive, but I think this is such a major problem it
>> > actually should be quite easy to track down.
>> >
>> > I did observe that it appears to be unbounded primitives like bignum and
>> > strings that fail.
>> >
>> > Some possible candidates off the top of my head:
>> > - When reading a fixnum back for the length of a string, bignum, etc we
>> > are actually reading adjacent
>> > values causing the allocator to request a string length in the
>> > gigabytes...
>> > - Also, length calculation in memutil.lisp may mismatch with the
>> > actual string length
>> > - Some memutil.lisp system-dependent parameter such as byte-length, etc
>> > might not be setup properly for AMD 64 systems.
>> >
>> > Don't forget that the SBCL 64-bit implementation is new so if compiled
>> > for native AMD-64 it might have a bug. Have you tried a 32-bit SBCL on
>> > your AMD-64 CPU?
>> >
>> > Anyway, see if you can trace serialize and (labels serialize %serialize)
>> > as well as deserialize and %deserialize put a break at the entry point to
>> > each so you can allow computation to continue at each step and see why
>> > we're getting the strange memory requests. Then just create a
>> > buffer-stream using 'with-buffer-streams' and try serializing a string to
>> > it, resetting the stream and reading the string back using deserialize
>> > (all buffer stream methods are in src/memutil/memutil.lisp).
>> >
>> > That should get you close to the problem.
>> >
>> > Thanks for the help, I'll pitch in as I can.
>> >
>> > Cheers,
>> > Ian
>> >
>> >
>> > Robert L. Read wrote:
>> >
>> >> Ughh --- you make a kind and generous offer, which I would
>> >> definitely accept if I weren't so busy with other things.
>> >>
>> >> How about this?
>> >> You spend some time, a few hours maybe, trying to get the simplest
>> >> serialization tests working. If you can clearly reduce it to the
>> >> first first test that fails and perhaps track it down to the
>> >> module or the assumption in question, then I will log into your
>> >> computer and either debug it further, or see if there is (for
>> >> example), a simple improvement in the serializer that will let it get
>> >> further.
>> >>
>> >> On Fri, 2006-08-18 at 22:58 +0200, Petter Egesund wrote:
>> >>
>> >>> A quick guess is that this has nothing to do with the
>> >>> BDB-backend, it seems it fails before it reaches the database point?
>> >>>
>> >>> I am not sure where to start debugging, but I can offer you a
>> >>> user on the AMD64 if that could be of any help?
>> >>>
>> >>> Anyhow I will try to do some small debugging - this package works
>> >>> so well on my private 32-bits Linux...
>> >>>
>> >>> Petter
>> >>>
>> >>> -----------------------------------------------------------------
>> >>> ---
>> >>> -
>> >>> ---
>> >>>
>> >>> *Fra:* Robert L. Read [mailto:[EMAIL PROTECTED]
>> >>> <mailto:[EMAIL PROTECTED]>]
>> >>> *Sendt:* 18. august 2006 22:51
>> >>> *Til:* Petter Egesund
>> >>> *Kopi:* Elephant-devel mailing list
>> >>> *Emne:* Re: SV: [elephant-devel] Memory error with Elephant
>> >>>
>> >>>
>> >>> Well, its good we know this ---- there is zero hope of getting
>> >>> Elephant to work until we solve this problem.
>> >>>
>> >>> My hunch would be this has to do with the AMD64.
>> >>>
>> >>> It is entirely possible that the serializer makes some assumption
>> >>> that isn't true on AMD64; the serializer gets into some
>> >>> byte-representation issues that could fail there.
>> >>>
>> >>> If you would like to debug it, I would be happy to answer your
>> >>> questions. I hope to use a 64-bit processor in my own business
>> >>> soon, but I don't have one available now.
>> >>>
>> >>> Does anyone else have this working on a 64 bit processor?
>> >>>
>> >>>
>> >>> On Fri, 2006-08-18 at 22:37 +0200, Petter Egesund wrote:
>> >>>
>> >>>> Thanks for answering!
>> >>>>
>> >>>> I did run one test, the not-so-good result was like below. Any clues?
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>> Petter
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------
>> >>>>
>> >>>> ; SLIME 2006-04-20
>> >>>> CL-USER> (asdf:operate 'asdf:load-op :ele-bdb)
>> >>>> ; loading system definition from
>> >>>> /home/pe/.sbcl/systems/ele-bdb.asd
>> >>>> into ; #<PACKAGE "ASDF0"> ; loading system definition from
>> >>>> /home/pe/.sbcl/systems/uffi.asd into ; #<PACKAGE "ASDF1"> ;
>> >>>> registering #<SYSTEM UFFI {1002EB0B41}> as UFFI ; registering
>> >>>> #<SYSTEM ELE-BDB {10034A6441}> as ELE-BDB ; loading system
>> >>>> definition from /home/pe/.sbcl/systems/elephant.asd into ;
>> >>>> #<PACKAGE "ASDF0"> ; registering #<SYSTEM ELEPHANT {100260E571}>
>> >>>> as ELEPHANT
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> PERSISTENT-SLOTS
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function OLD-PERSISTENT-SLOTS
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> UPDATE-PERSISTENT-SLOTS
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> INDEXED-RECORD
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> OLD-INDEXED-RECORD
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> UPDATE-INDEXED-RECORD
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> MAKE-NEW-INDEXED-RECORD
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> REMOVED-INDEXING?
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> REGISTER-INDEXED-SLOT
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> UNREGISTER-INDEXED-SLOT
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> REGISTER-DERIVED-INDEX
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> UNREGISTER-DERIVED-INDEX
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> PREVIOUSLY-INDEXED ; loading system definition from
>> >>>> /home/pe/.sbcl/systems/cl-base64.asd into ; #<PACKAGE "ASDF0"> ;
>> >>>> registering #<SYSTEM CL-BASE64 {1003993E91}> as CL-BASE64 ;
>> >>>> registering #<SYSTEM CL-BASE64-TESTS {1003C546C1}> as
>> >>>> CL-BASE64-TESTS ; loading system definition from
>> >>>> /home/pe/.sbcl/systems/kmrcl.asd into ; #<PACKAGE "ASDF0"> ;
>> >>>> registering #<SYSTEM KMRCL {1003345D31}> as KMRCL
>> >>>> STYLE-WARNING: implicitly creating new generic function GET-CON
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> CONTROLLER-PROPERTIES
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> SET-ELE-PROPERTY
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> GET-ELE-PROPERTY
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> ENSURE-MARKED-VERSION
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> CONTROLLER-VERSION
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> UP-TO-DATE-P
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> UPGRADABLE-P
>> >>>> STYLE-WARNING: implicitly creating new generic function UPGRADE
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function FLUSH-INSTANCE-CACHE
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> DROP-POBJECT
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> MAP-BTREE
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> EMPTY-BTREE-P
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> CLASS-INDEX-CACHED?
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> DETERMINE-SYNCH-METHOD
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> SET-DB-SYNCH
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> INDEXED-SLOT-WRITER
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> CLASS-INDEXEDP-BY-NAME
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> FIND-INVERTED-INDEX-NAMES
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> WIPE-CLASS-INDEXING
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> COPY-BTREE-CONTENTS
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> BUILD-BTREE-INDEX NIL
>> >>>> CL-USER> (asdf:operate 'asdf:load-op :elephant-tests)
>> >>>> ; loading system definition from
>> >>>> /home/pe/.sbcl/systems/elephant-tests.asd
>> >>>> ; into #<PACKAGE "ASDF0">
>> >>>> ; registering #<SYSTEM ELEPHANT-TESTS {10038A95E1}> as
>> >>>> ELEPHANT-TESTS ; registering #<SYSTEM ELEPHANT-TESTS-BDB
>> >>>> {1003B28C91}> as ; ELEPHANT-TESTS-BDB ; loading system
>> >>>> definition from /home/pe/.sbcl/systems/rt.asd into ; #<PACKAGE
>> >>>> "ASDF0"> ; registering #<SYSTEM :RT {1003F11531}> as RT NIL
>> >>>> CL-USER> (in-package "ELEPHANT-TESTS")
>> >>>> #<PACKAGE "ELEPHANT-TESTS">
>> >>>> ELE-TESTS> (setf *default-spec* *testbdb-spec*)
>> >>>> (:BDB "/home/pe/.sbcl/site/elephant/tests/testdb/")
>> >>>> ELE-TESTS> (do-backend-tests)
>> >>>> ; compiling file
>> >>>> "/home/pe/.sbcl/site/elephant/tests/testsleepycat.lisp" (written 19 FEB
>> >>>> 2006 05:53:02 AM):
>> >>>> ; compiling (IN-PACKAGE "ELE-TESTS") ; compiling (DEFVAR ENV) ;
>> >>>> compiling (DEFVAR DB) ; compiling (DEFUN PREPARE-SLEEPYCAT ...)
>> >>>> ; compiling (DEFTEST PREPARES-SLEEPYCAT ...) ; compiling (DEFUN
>> >>>> TEST-SEQUENCE1 ...) ; compiling (DEFTEST TEST-SEQ1 ...) ;
>> >>>> compiling (DEFUN TEST-SEQUENCE2 ...) ; compiling (DEFTEST
>> >>>> TEST-SEQ2 ...) ; compiling (DEFUN CLEANUP-SLEEPYCAT ...) ;
>> >>>> compiling (DEFTEST CLEANSUP-SLEEPYCAT ...)
>> >>>>
>> >>>> ; /home/pe/.sbcl/site/elephant/tests/testsleepycat.fasl written
>> >>>> ; compilation finished in 0:00:00 Doing 115 pending tests of 115
>> >>>> tests total.
>> >>>> FIXNUMS FIXNUM-TYPE-1
>> >>>> Test BIGNUMS failed
>> >>>> Form: (ARE-NOT-NULL (IN-OUT-EQUAL 10000000000) (IN-OUT-EQUAL
>> >>>> -10000000000)
>> >>>> (LOOP FOR I FROM 0 TO 2000 ALWAYS
>> >>>> (IN-OUT-EQUAL (EXPT 2 I)))
>> >>>> (LOOP FOR I FROM 0 TO 2000 ALWAYS
>> >>>> (IN-OUT-EQUAL (- (EXPT 2 I))))
>> >>>> (LOOP FOR I FROM 0 TO 2000 ALWAYS
>> >>>> (IN-OUT-EQUAL (- (EXPT 2 I) 1)))
>> >>>> (LOOP FOR I FROM 0 TO 2000 ALWAYS
>> >>>> (IN-OUT-EQUAL (- 1 (EXPT 2 I))))
>> >>>> (LOOP FOR I FROM 0 TO 2000 ALWAYS
>> >>>> (IN-OUT-EQUAL (EXPT 3 I)))
>> >>>> (LOOP FOR I FROM 0 TO 2000 ALWAYS
>> >>>> (IN-OUT-EQUAL (- (EXPT 3 I)))))
>> >>>> Expected
>> >>>> values: T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> Actual value: #<SB-KERNEL::MEMORY-FAULT-ERROR {1002897E31}>.
>> >>>> FLOATS
>> >>>> Test RATIONALS failed
>> >>>> Form: (ARE-NOT-NULL (IN-OUT-EQUAL 1/2) (IN-OUT-EQUAL -1/2)
>> >>>> (IN-OUT-EQUAL (/ 1 MOST-POSITIVE-FIXNUM))
>> >>>> (IN-OUT-EQUAL (/ 1 MOST-NEGATIVE-FIXNUM))
>> >>>> (IN-OUT-EQUAL
>> >>>> (/ MOST-POSITIVE-FIXNUM MOST-NEGATIVE-FIXNUM))
>> >>>> (IN-OUT-EQUAL (/ (EXPT 2 200) (EXPT 3 300)))
>> >>>> (IN-OUT-EQUAL (/ (EXPT 2 200) (- (EXPT 3
>> >>>> 300))))) Expected values: T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> Actual value: #<DIVISION-BY-ZERO {10028F0B41}>.
>> >>>> Test BASE-STRINGS failed
>> >>>> Form: (ARE-NOT-NULL
>> >>>> (IN-OUT-EQUAL (MAKE-STRING 0 :ELEMENT-TYPE 'BASE-CHAR))
>> >>>> (IN-OUT-EQUAL (COERCE "this is a test" 'BASE-STRING))
>> >>>> (IN-OUT-EQUAL
>> >>>> (MAKE-STRING 400 :INITIAL-ELEMENT (CODE-CHAR 127) :ELEMENT-TYPE
>> >>>> 'BASE-CHAR))) Expected values: T
>> >>>> T
>> >>>> T
>> >>>> Actual value: #<SB-KERNEL::MEMORY-FAULT-ERROR {100291E3F1}>.
>> >>>> Heap exhausted: 8517255168 bytes available, 498216206416 requested.
>> >>>> PROCEED WITH CAUTION!
>> >>>> [Condition of type SB-KERNEL::HEAP-EXHAUSTED-ERROR]
>> >>>>
>> >>>> Restarts:
>> >>>> 0: [ABORT-REQUEST] Abort handling SLIME request.
>> >>>> 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD
>> >>>> "repl-thread" {1003511531}>)
>> >>>>
>> >>>> Backtrace:
>> >>>> 0: (SB-KERNEL::HEAP-EXHAUSTED-ERROR 8517255168 498216206416)
>> >>>> 1: ("foreign function: call_into_lisp")
>> >>>> 2: ("foreign function: funcall2")
>> >>>> 3: ("foreign function: gc_heap_exhausted_error_or_lose")
>> >>>> 4: ("foreign function: gc_find_freeish_pages")
>> >>>> 5: ("foreign function: gc_alloc_large")
>> >>>> 6: ("foreign function: alloc_tramp")
>> >>>> 7: ((LABELS ELEPHANT::%DESERIALIZE) #<unavailable argument>)
>> >>>> 8: (IN-OUT-EQUAL "this is a test")
>> >>>> 9: (SB-INT:EVAL-IN-LEXENV (IN-OUT-EQUAL "this is a test")
>> >>>> #<NULL-LEXENV>)
>> >>>> 10: (SB-INT:EVAL-IN-LEXENV (PROGN (IN-OUT-EQUAL "this is a
>> >>>> test"))
>> >>>> #<NULL-LEXENV>)
>> >>>> 11: (SB-INT:EVAL-IN-LEXENV (NULL (PROGN (IN-OUT-EQUAL "this is
>> >>>> a
>> >>>> test"))) #<NULL-LEXENV>)
>> >>>> 12: (SB-INT:EVAL-IN-LEXENV (IS-NOT-NULL (IN-OUT-EQUAL "this is
>> >>>> a
>> >>>> test")) #<NULL-LEXENV>)
>> >>>> 13: (SB-INT:EVAL-IN-LEXENV (ARE-NOT-NULL (IN-OUT-EQUAL "")
>> >>>> (IN-OUT-EQUAL "this is a test") (IN-OUT-EQUAL (MAKE-STRING 400
>> >>>> :INITIAL-ELEMENT #))) #<NULL-LEXENV>)
>> >>>> 14: ((FLET REGRESSION-TEST::%DO))
>> >>>> 15: (REGRESSION-TEST::DO-ENTRY #S(REGRESSION-TEST::ENTRY :PEND
>> >>>> T :NAME STRINGS :PROPS NIL :FORM (ARE-NOT-NULL (IN-OUT-EQUAL "")
>> >>>> (IN-OUT-EQUAL "this is a test") (IN-OUT-EQUAL #)) :VALS (T T T))
>> >>>> #<SWANK-BACKEND::SLIME-OUTPUT-STREAM {100337B2F1}>)
>> >>>> 16: (REGRESSION-TEST::DO-ENTRIES*
>> >>>> #<SWANK-BACKEND::SLIME-OUTPUT-STREAM {100337B2F1}>)
>> >>>> 17: (REGRESSION-TEST::DO-ENTRIES
>> >>>> #<SWANK-BACKEND::SLIME-OUTPUT-STREAM {100337B2F1}>)
>> >>>> 18: (DO-BACKEND-TESTS (:BDB
>> >>>> "/home/pe/.sbcl/site/elephant/tests/testdb/"))
>> >>>> 19: (SB-INT:EVAL-IN-LEXENV (DO-BACKEND-TESTS) #<NULL-LEXENV>)
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ________________________________
>> >>>>
>> >>>> Fra: [EMAIL PROTECTED]
>> >>>> <mailto:[EMAIL PROTECTED]>
>> >>>> <mailto:[EMAIL PROTECTED]
>> >>>> <mailto:[EMAIL PROTECTED]>>
>> >>>> [mailto:[EMAIL PROTECTED]
>> >>>> <mailto:[EMAIL PROTECTED]>
>> >>>> <mailto:[EMAIL PROTECTED]
>> >>>> <mailto:[EMAIL PROTECTED]>>] På vegne av
>> >>>> Robert L. Read
>> >>>> Sendt: 18. august 2006 22:04
>> >>>> Til: Elephant bugs and development
>> >>>> Emne: Re: [elephant-devel] Memory error with Elephant
>> >>>>
>> >>>>
>> >>>> That mystifies me. I can only conjecture that it is somehow related to
>> >>>> your environment.
>> >>>>
>> >>>> Even thought it may seem strange since that simplest of
>> >>>> functionality doesn't work, you might wish to execute the test.
>> >>>> If, for example, there were an infinite loop in the serializer
>> >>>> when compiled in your environment, the larges suite of automated tests
>> >>>> might reveal that, as opposed to a problem with BDB, for example.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>>
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
