cosmos72 / hyperluminal-mem Goto Github PK

The MEM-TREE test fails with "bus error at #X<address>"

Reason: on sparc, double-floats reads and writes must be aligned at 8-bytes,
but 32-bit hyperluminal-mem ABI only aligns them at 4 bytes.

Hi,
any chance of using different license? Something non-infectious, which actually allows using the lib for projects?

Cheers,
Karol

Would it be possible to signal a specific error (instead of a simple error with a string) in mread-box/symbol and to have the restart-case uncommented to let callers replace non-existent symbols? The error message should use sym-name instead of sym (because sym is always nil).
I can submit a pull request, but not sure if it is useful, because it is a trivial change.

Thanks,
Ilya

Compile works on 2.0.1 ....
Compile fails on 2.1.5:

[package hyperluminal-mem-sbcl]...................
[package hyperluminal-mem-asm].
;
; caught ERROR:
; READ error during COMPILE-FILE:
;
; Lock on package SB-VM violated when interning MAKE-EA while in package
; HYPERLUMINAL-MEM-SBCL.
; See also:
; The SBCL Manual, Node "Package Locks"
;
; (in form starting at line: 51, column: 0, position: 1723)

%mwrite-package (called from mwrite-box/symbol) may write a package reference without doing a buffer boundary check.
Test case:

(let ((real-buf-size 4))
           (hlmem:with-mem-words (buf real-buf-size)
             ;; Zero the buffer
             (dotimes (i real-buf-size) (setf (cffi:mem-aref buf :uint64 i) 0))
             ;; Should fail with "attempt to write N words ..., but only M words available ...
             ;; buf fails with a type error
             (print (multiple-value-list (ignore-errors (hlmem:mwrite buf 0 1 :foo))))
             ;; Should be zero, because last-index is 1 and mwrite should not write past last-index-1.
             (print (cffi:mem-aref buf :uint64 1))))

Hi, how database can be designed for safety? You just put data there, and take eventually. How data can be danger in this case? What does it mean?

When I prepare a quicklisp dist, all projects must build without Quicklisp present. The use of ql:quickload in the .asd file of this project prevents it from being built. Can you do it without QL:?

It should shift bytes by (- ,i ,start), not by ,i in (ash (%bit-vector-extract-byte ,vector ,i) ,i)

The MEM-STRING test, newly added to the experimental branch, fails on all known versions of Clozure Common Lisp (CCL) with:
Failure Details:

MEM-STRING []:
Unexpected Error: #<TYPE-ERROR #x302001BBFF6D>
The value NIL is not of the expected type CHARACTER...

Reason: on CCL, (CODE-CHAR #xFFFE) and (CODE-CHAR #xFFFF) both return NIL, while hyperluminal-mem expects them to return the corresponding characters.

The author is discussing the point, which involves the meaning and expected behaviour of Unicode "noncharacters" (U+FFFE U+FFFF and 64 others), on CCL bug tracker http://trac.clozure.com/ccl/ticket/1278

Building with SBCL 2.0.9.5-442f54894 / ASDF 3.3.1 for quicklisp dist creation.

Commit id 7dea5a4

hyperluminal-mem-test fails to build because of a failure in hyperluminal-mem.

hyperluminal-mem fails to build with the following error:

; caught ERROR:
;   READ error during COMPILE-FILE: Lock on package SB-VM violated when interning EAX-OFFSET while in package HYPERLUMINAL-MEM-SBCL.
;   See also:
;     The SBCL Manual, Node "Package Locks"(in form starting at line: 427, column: 0, position: 16785)
...
Unhandled UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {100E838223}>: COMPILE-FILE-ERROR while compiling #<CL-SOURCE-FILE "hyperluminal-mem" "sbcl" "x86">

Full log here

On ABCL 1.3.1, all tests pass except GHASH-TABLE, which fails with
Failure Details:

GHASH-TABLE []:
Unexpected Error: #<TYPE-ERROR {3E1CA175}>
The value -32316509077753586139510713445660514514047171580093496865901477602143224540557412340472969236184020377745408638077439397456141948699754273791418869985027499602243785773646750786158629119897527698459159582903277348091197804306308450975276589715725867107713970624879795449576651053772645338545136289129326403509065092108109101077472046144122638474948527343653345105797020149055603954704727773430317796884279167058635246262041734914578626456397727386204475718614091025348906121070916929137541182355893615952208805117487445236884750886234300399097674869962426348425792929710270231641017897005896324246640151098893336183040 is too large to be converted to a single float...

The reason is a bug in ABCL implementation of EQUALP: when invoked with a very large bignum and a float, it incorrectly signals an error instead of returning NIL. The bug has been reported to ABCL mailing list, together with a partial fix.