armedbear / abcl Goto Github PK

https://github.com/mcna/closure-common fails to load properly because the xstream structure causes a redefinition failure, the reason being that the slot buffer of type (simple-array buffer-byte (*)) (which is also what's in the FASL, (#5=SYSTEM::DEFSTRUCT-SLOT-DESCRIPTION BUFFER #6=0 XSTREAM-BUFFER +NULL-BUFFER+ (#7=SIMPLE-ARRAY BUFFER-BYTE (#8=*)) #2# )) has the expanded type (SIMPLE-ARRAY (INTEGER 0 65535) (*)) loaded in the runtime (c.f. (nth 0 (system::dd-slots (get 'runes::xstream 'system::structure-definition)))).

Structure redefinition not supported in DEFSTRUCT for XSTREAM
   [Condition of type PROGRAM-ERROR]

Restarts:
 0: [TRY-RECOMPILING] Recompile xstream and try loading it again
...
Backtrace:
...
  4: (ERROR PROGRAM-ERROR :FORMAT-CONTROL "Structure redefinition not supported ~
                                   in DEFSTRUCT for ~A" :FORMAT-ARGUMENTS (RUNES:XSTREAM))
  5: (SYSTEM:COMPILER-DEFSTRUCT RUNES:XSTREAM :CONC-NAME #:XSTREAM- :DEFAULT-CONSTRUCTOR RUNES::MAKE-XSTREAM/LOW ...)

It would be great if ABCL offered support for CAS and other atomic operators in order to allow the implementation of lock-free datastructures and algorithms.

A variety of implementations already offer support for operations like cas, atomic-incf, atomic-push, and atomic-pop. For instance, both ECL and SBCL follow the protocol described in the SBCL manual.

I've accumulated the information for atomic operator support in a new portability library called Atomics. For ABCL to be supported, it would need to offer CAS on at least svref, car, cdr, and structure accessor places. Naturally it would be great if it offered more than that still, but those are the most fundamental.

As for how to achieve this: since I don't know anything about ABCL internals I can't say too much, though Java itself offers support for CAS through sun.misc.Unsafe and java.util.concurrent.atomic.*.

(eval '(let ((a 15)) (boole boole-2 (logior 0 (setf a 14)) a))) ==>
14

(eval (funcall (compile nil '(lambda () (let ((a 15)) (boole boole-2 (logior 0 (setf a 14)) a)))))) ==>
15

Have you fellows checked out these projects? I imagine that the graal vm would make hosting common lisp a lot easier on the jvm.

Because the class loader is a transient memory class loader, and jclass uses the current class loader.
Fix would be something like keeping a weak hash table of name to class and have the implementation of jclass check that if the class is otherwise not found.

To reproduce:

(defclass a () ())
(defclass b (a) ())
(make-instance 'b)
(defclass a () ((s :accessor s :initarg :s)))
(make-instance 'a :s 1)
(make-instance 'b :s 1)
Invalid initarg :s in call to make-instance with arglist (#<b {1C14617D}>  :s 1).

TRAC issue tracker at:

https://abcl.org/trac/

gives:

Trac Error

TracError: No Trac environment found at /srv/project/armedbear/trac
[Errno 2] No such file or directory: '/srv/project/armedbear/trac/VERSION'

http://abcl.org/trac/changeset/15085 nee 7548151 adds three DEFGENERIC abcl/test/ansi/compiled failures

See http://abcl.org/trac/ticket/449#ticket.

http://abcl.org/trac/ticket/429

If you don't explicitly provide a repository as part of the :mvn specification in a sysdef, resolve-dependencies is called (from resolve) with repositories nil.

Then, in resolve-dependencies, since repositories-p is t and repositories is nil, the collect-request doesn't get a repository added to it. Subsequently, if the dependency isn't already downloaded, the resolution fails.

I don't understand the intended behavior if repositories-p is t and repositories is nil. I don't see anything documented about this. If repositories is nil, I think the default repository should be used. Failing that, resolve shouldn't pass the repositories argument, if nil.

That I wasn't adding the repository to the collect request is why my mvn-module was failing in the same way. Patch for that forthcoming.

ABCL 1.5.0

CL-USER> (handler-case (read-from-string "cl:asdfsad") (error (e) (describe e)))

#<READER-ERROR {B20D3DF}> is an instance of #<STANDARD-CLASS READER-ERROR {B0459D1}>.
The following slots have :INSTANCE allocation:
  FORMAT-CONTROL     "The symbol \"ASDFSAD\" was not found in package CL."
  FORMAT-ARGUMENTS   NIL
  STREAM             #S(SYSTEM::STRING-INPUT-STREAM)

The FORMAT-CONTROL string is preformatted, and it should not be.

FORMAT-CONTROL should be "The symbol ~S was not found in package CL." and FORMAT-ARGUMENTS should be ("ASDFSAD" CL).

CLHS says, "decode-float divides float by an integral power of b so as to bring its value between 1/b (inclusive) and 1 (exclusive), and returns the quotient as the first value." b is the base of the floating point number system, so in the case of ABCL it is 2, therefore the signficand returned by DECODE-FLOAT should be greater than or equal to 0.5 and less than 1.

For all single floats that I tried, ABCL's DECODE-FLOAT returns significand less than 0.5. The value returned is on the order of 1e-9 for normalized single floats and smaller for denormalized single floats.

I am working with ABCL built from svn as of r15125 if I am not mistaken.

$ ./abcl
Armed Bear Common Lisp 1.6.0-dev
Java 1.8.0_60 Oracle Corporation
Java HotSpot(TM) Server VM
Low-level initialization completed in 0.437 seconds.
Startup completed in 2.462 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (decode-float 1f0)
9.313226E-10
30
1.0
CL-USER(2): (decode-float 1f6) 
1.7763568E-9
49
1.0
CL-USER(3): (decode-float 1f-6)
9.765625E-10
10
1.0
CL-USER(4): (decode-float least-positive-normalized-single-float)
9.313226E-10
-96
1.0
CL-USER(5): (decode-float least-positive-single-float)
2.220446E-16
-97
1.0

*FEATURES*:

CL-USER(6): *features*
(:X86 :JAVA-1.8 :UNIX :LINUX :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :CDR6 :MOP :PACKAGE-LOCAL-NICKNAMES)

uname -a reports: Linux freekbox 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:23:46 UTC 2014 i686 i686 i686 GNU/Linux

reproduce:

compile a file with only the contents:

(defmacro test () "missing" ())

quit and restart abcl

load the fasl

(describe 'test)

Reported by Paul Dietz here

(defparameter *abcl1*
  '(lambda (a)
    (declare (optimize (debug 0) (compilation-speed 1)
              (speed 2) (space 3) (safety 1)))
    (ash 0
     (bit #*0100
      (catch 'ct7 a)))))

(defun test1 ()
  (let ((fn (compile nil *abcl1*)))
    (mapcar fn '(0 1 2 3))))

(test1) ==>

; Caught ERROR:
;   Stack inconsistency detected in <unknown> at index 40: found 2, expected 0.

c.f. http://abcl.org/trac/ticket/453

In a shell: touch /tmp/*

(probe-file "/tmp/")
; Evaluation aborted on #<FILE-ERROR {7DF4B809}>.
CL-USER> (probe-file "/tmp/\")
; Evaluation aborted on #<FILE-ERROR {4D5E9779}>.
CL-USER> (probe-file "/tmp/%2A")
nil
CL-USER> (probe-file "file:///tmp/%2A")
; Evaluation aborted on #<FILE-ERROR {7DF4B809}>.

The error is: Bad place for a wild pathname.

I had a quick look to see how this could be repaired, but wasn't sure what the right approach is. This stackoverflow answer suggests using "\" as a quote, which is probably the best solution, and would be compatible with what Clozure CL, SBCL and LispWorks do. I also think the percent escaped character should be made to work.

The specific screw case I had was that there was an accidentally created file with a "*" in a directory that was being scanned for ASDF's system registry, which crapped out because the directory function returned the "*" pathname, and subsequently did a probe on the file.

Consider java.util.HashMap$Node

sys:inspected-parts uses getCanonicalName to get the intended class, which yields java.util.HashMap.Node . However calling jclass on that string gives an error, which causes problems, in e.g. the slime debugger inspect of a java object.

The code that does this is in JavaObject.getParts()

parts = parts.push(new Cons("intendedClass", new SimpleString(intendedClass.getCanonicalName())));

AFAIK, the intended-class business is to handle wrapping of primitive types, i.e. substitute Byte for byte, etc. I see code like findmethod(.. intendedClass ..) which would suggest that the string intendedClass should be a valid argument to jclass.

So I think getName should be used here, vs. getCanonicalName unless I misunderstand the intention of intendedClass

I've worked around it for now by doing this check in the slime inspector code.

Periodically I remember issue #9 and then maven-embedder.lisp needs to be recompiled when abcl-asdf is required. Periodically I tear my hair out trying to figure out how to make an initial test run of abcl.jar how to know that.

What do you think of wrapping the first part (up until init is defined) and then calling init inside an eval-when?

Might be nice to add a build target that installs maven if mvn isn't on PATH.

@@ -41,6 +41,7 @@ Test:
 
 |#
 
+(eval-when (:compile-toplevel  :load-toplevel :execute)
 (defparameter *maven-verbose* t
   "Stream to send output from the Maven Aether subsystem to, or NIL to muffle output")
 

@@ -222,7 +224,10 @@ of the mvn executable with an explicit value."
     (error "Please obtain and install maven-3.0.3 or later locally from <http://maven.apache.org/download.html>, then set ABCL-ASDF:*MVN-LIBS-DIRECTORY* to the directory containing maven-core-3.*.jar et. al."))
   (unless (ensure-mvn-version)
     (error "We need maven-3.0.3 or later."))  (add-directory-jars-to-class-path *mvn-libs-directory* nil)
-    (setf *init* t))
+  (setf *init* t))
+
+(init))
+

Can't seem to make it work. This is code that works for other functions

    (let ((classloader (#"getClassLoader" class)))
      (if (or (java:jinstance-of-p classloader "org.armedbear.lisp.MemoryClassLoader")
          (java:jinstance-of-p classloader "org.armedbear.lisp.FaslClassLoader"))
      (system::disassemble-class-bytes 
       (#"getFunctionClassBytes" classloader class))

(defun test (args) (destructuring-bind (a b &rest c) args (list a b)))
(test '(1))
-> '(1 nil)

should signal an error

without the &rest args

(defun test (args) (destructuring-bind (a b) args (list a b)))
(test '(1)) 

signals an error as expected

Adds about 1.3 MB on top of 10.5 MB (figures for my recent jars)
Means that you can always see the source with meta-.

If there's a need for a small abcl.jar, have that also be buildable, but then maybe get rid of other things too.

@robert-dodier says that he wasn't able to find this issues list by looking at the common-lisp.net project info, and that he only found Trac.

https://abcl.org/trac/ticket/267

Surprisingly, it's defined in the named-readtables contrib. Used in precompile-setq. Proposed fix is to use 'simple-error as is done in precompile-psetq. Alternatively move definition of conditions from named-readtables to sys.

easye@65b62a2

ANSI tests fails FILE-POSITION.10

The protocol as provided by SBCL has been extended to include the following additional operators:

• EMPTYP
• MERGE
• MAP
• CONCATENATE

The following fails in two cases

(directory (merge-pathnames
         (make-pathname :directory '(:relative :wild-inferiors)) 
        "/Users/alanr/Desktop/ontology-cache/"))

1. If there's a dotfile somehere below, for example .DS_Store on macs an error is thrown. The fail is in pathname-match-p, which gets nil as a wildcard. There are other cases where nil is passed as well.
2. We can patch pathname-match-p so that a null wildcard never matches. However in that case, the function returns nothing, even though there are inferior directories. I have tested the same form on SBCL and it works correctly.

Also generating errors:

(directory "something/**") ;; nil is not of type fixnum (also below pathname-match-p)
(directory "something/**/") ;; nil wildcard error as above

Ticket 137 in Trac

While trying to implement a Cleavir environment as referenced in #62, I found there's only compiler-let in lisp:.

(make-pathname :directory '(:absolute ("a" "b")))
property signals an error Unsupported directory component (a b).
However the following
(merge-pathnames (make-pathname :directory '(:absolute ("a" "b"))) "")
Does not, instead spitting out a java stack trace

java.lang.Error: ABCL Debug.assertTrue() assertion failed!
at org.armedbear.lisp.Debug.assertTrue(Debug.java:48)
at org.armedbear.lisp.Pathname.<init>(Pathname.java:154)
at org.armedbear.lisp.Pathname.mergePathnames(Pathname.java:1979)
at org.armedbear.lisp.Pathname$pf_merge_pathnames.execute(Pathname.java:1957)
at org.armedbear.lisp.LispThread?.execute(LispThread?.java:832)
at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582)
at org.armedbear.lisp.Lisp.eval(Lisp.java:540)
at org.armedbear.lisp.Primitives$pfeval.execute(Primitives.java:345)
...

It seems that process-wait is not called when wait is true.
(when (or wait (not-java-6) (process-wait process)) process)

Related to #93 but it seems likely this is a different bit of code so I'm opening a separate report.

CLHS says, "decode-float divides float by an integral power of b so as to bring its value between 1/b (inclusive) and 1 (exclusive), and returns the quotient as the first value." b is the base of the floating point number system, so in the case of ABCL it is 2, therefore the signficand returned by DECODE-FLOAT should be greater than or equal to 0.5 and less than 1.

I find that for double floats less than LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT divided by 2, DECODE-FLOAT returns significand less than 0.5.

$ ./abcl
Armed Bear Common Lisp 1.6.0-dev
Java 1.8.0_60 Oracle Corporation
Java HotSpot(TM) Server VM
Low-level initialization completed in 0.414 seconds.
Startup completed in 2.535 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (lisp-implementation-version)
"1.6.0-dev"
"Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.8.0_60-b27"
"i386-Linux-3.13.0-44-generic"
CL-USER(2): (lisp-implementation-type)
"Armed Bear Common Lisp"
CL-USER(3): 
CL-USER(3): (decode-float least-positive-normalized-double-float)
0.5
-1021
1.0
CL-USER(4): (decode-float (/ least-positive-normalized-double-float 2))
0.5
-1022
1.0
CL-USER(5): (decode-float (/ least-positive-normalized-double-float 1024))
9.765625E-4
-1022
1.0
CL-USER(6): (decode-float (/ least-positive-normalized-double-float 4))
0.25
-1022
1.0
CL-USER(7): (decode-float (/ least-positive-normalized-double-float 8))
0.125
-1022
1.0
CL-USER(8): (decode-float (/ least-positive-normalized-double-float 16))
0.0625
-1022
1.0
CL-USER(9): (decode-float least-positive-double-float)              
2.220446E-16
-1022
1.0

I am working with ABCL built from svn as of r15125 if I am not mistaken.

CL-USER(6): *features*
(:X86 :JAVA-1.8 :UNIX :LINUX :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :CDR6 :MOP :PACKAGE-LOCAL-NICKNAMES)

uname -a reports: Linux freekbox 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:23:46 UTC 2014 i686 i686 i686 GNU/Linux

I see that SYSTEM:AVAILABLE-ENCODINGS returns a list of symbols which represent the various encodings that are discovered via Charset.availableCharsets. That's great, but the symbols are apparently not interned in the keyword package, so it makes it somewhat confusing to determine whether a given encoding is on the list.

e.g. (member :utf-16 (system:available-encodings)) returns NIL, although looking at the list, you can see that :UTF-16 is there.

Confusingly, (mapcar #'symbol-package (system:available-encodings)) shows that all symbols are in the keyword package, but (find-symbol "UTF-16" :keyword) returns NIL.

I believe the problem is that availableEncodings in src/org/armedbear/lisp/Stream.java says, in part, (at line 399 in the current version)

new Symbol(charset, PACKAGE_KEYWORD)

but I think more appropriate would be

PACKAGE_KEYWORD.intern(charset)

Here is a patch which implements that change, and fixes the bug, from what I can tell.

Index: src/org/armedbear/lisp/Stream.java
===================================================================
--- src/org/armedbear/lisp/Stream.java	(revision 15113)
+++ src/org/armedbear/lisp/Stream.java	(working copy)
@@ -396,7 +396,7 @@
     SortedMap<String, Charset> available = Charset.availableCharsets();
     Set<String> encodings = available.keySet();
     for (String charset : encodings) {
-      result.add(new Symbol(charset, PACKAGE_KEYWORD));
+      result.add (PACKAGE_KEYWORD.intern (charset));
     }
     return result;
   }

(declaim (optimize (safety 0)))

(lambda ()
  (loop for x of-type fixnum
        from (1- most-positive-fixnum) to most-positive-fixnum
        do (progn)
        finally (print x)))

(compile nil *)

(funcall *)

The above loops even though it is conforming ANSI CL.

Rationale, related to ANSI-TEST LOOP.1.39 and LOOP.1.40: https://gist.github.com/phoe/335fecfdc195bddd47ab0928b0e62e52

I noticed that ant make clean doesn't delete the fasls below ~/.cache which means you can seemingly do a fresh build but unwittingly be loading stale contrib fasls.

I may create things external to the running lisp the course of a lisp session that I want to do something to (like kill or delete) if the session exits. SBCL (and IIRC some other lisps) provide such a facility. I'd like ABCL to do similarly. Here's a proof of concept. I'm not submitting this as a patch as it may be desirable to implement this in java directly and I avoid (for lack of skill) writing ABCL java source.

The following will cause a file called /tmp/canary to be created when java exits.

(defvar *exit-hooks* nil)

(#"addShutdownHook" 
      (#"getRuntime" 'java.lang.Runtime) 
      (new 'thread (jss::jdelegating-interface-implementation
		    (find-java-class "Runnable")
		    nil
		    "run"
		    (lambda(&rest ignore)
		     (dolist (h *exit-hooks*)
		     	     (ignore-errors (funcall h)))))))

(push (lambda() (#"createNewFile" (new 'file "/tmp/canary") )) *exit-hooks*)

CLHS says "decode-float computes three values that characterize float. The first value is of the same type as float and represents the significand."

I find that DECODE-FLOAT applied to double float arguments always returns a single float significand instead of a double float.

CL-USER(5): (type-of 1d0)        
DOUBLE-FLOAT
CL-USER(6): (type-of (decode-float 1d0))
SINGLE-FLOAT
CL-USER(7): (type-of most-positive-double-float)
DOUBLE-FLOAT
CL-USER(8): (type-of (decode-float most-positive-double-float))
SINGLE-FLOAT
CL-USER(9): (type-of least-positive-double-float)
DOUBLE-FLOAT
CL-USER(10): (type-of (decode-float least-positive-double-float))
SINGLE-FLOAT

I am working with ABCL built from svn as of r15125 if I am not mistaken. lisp-implementation-version reports:

"1.6.0-dev"
"Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.8.0_60-b27"
"i386-Linux-3.13.0-44-generic"

CL-USER(6): *features*
(:X86 :JAVA-1.8 :UNIX :LINUX :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :CDR6 :MOP :PACKAGE-LOCAL-NICKNAMES)

uname -a reports: Linux freekbox 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:23:46 UTC 2014 i686 i686 i686 GNU/Linux

(compile nil '(lambda () (tagbody (catch 'c 100)))) ==>

COMPILE-TAGBODY: tag not found: 100
[Condition of type SIMPLE-ERROR]

Cherry pick dbba85a

CLHS says:

If the value of read-suppress is true, read, read-preserving-whitespace, read-delimited-list, and read-from-string all return a primary value of nil when they complete successfully; however, they continue to parse the representation of an object in the normal way, in order to skip over the object, and continue to indicate end of file in the normal way.

Checked against behavior of SBCL and Allegro

This is in violation to 3.4.7 which specifically allows the &environment parameter in defsetf lambda-lists.

Test case:

(defsetf foo (&environment env place) (value))
;; => &ENVIRONMENT is only valid at top level of lambda list.

I'm not entirely sure if 3.4.7 requires &environment to come after the places, unlike other lambda-lists where &environment has to be first. In any case, late &environment also fails in the same fashion.

(defsetf foo (place &environment env) (value))
;; => &ENVIRONMENT is only valid at top level of lambda list.

Failing CI with segv https://travis-ci.org/easye/abcl/jobs/618633882#L7886

Context of segv failures in CI https://travis-ci.org/easye/abcl/jobs/618633882

rdfs:seeAlso https://abcl.org/trac/ticket/464 .

In slime, compiling region with, e.g., (defun foo () (return-from bar nil)) gives a message about there being a program error with no further information

No code of mine depends on this, but I was reading an article and it prompted me to check types of arrays and how upgraded-array-element-type works.

Bottom line is that it isn't consistent.

CL-USER> (make-array 1 :element-type '(unsigned-byte 16))
#(0)
CL-USER> (jobject-class *)
#<java class org.armedbear.lisp.BasicVector_UnsignedByte16 {6F28B4E2}>
CL-USER> (class-of (make-array 1 :element-type '(unsigned-byte 16)))
#<built-in-class vector {352D86C9}>
CL-USER> (upgraded-array-element-type '(unsigned-byte 16))
(unsigned-byte 16)
CL-USER> (make-array 1 :element-type '(unsigned-byte 17))
#(0)
CL-USER> (jobject-class *)
#<java class org.armedbear.lisp.BasicVector_UnsignedByte32 {1C49E33C}>
CL-USER> (upgraded-array-element-type '(unsigned-byte 17))
t
CL-USER> (class-of (make-array 1 :element-type '(unsigned-byte 17)))
#<built-in-class vector {352D86C9}>

Summary:

• Implementation of arrays of unsigned byte 16 vs 17 are different
• class-of reports the same type
• upgraded-array-element-type of (unsigned-byte 17) reports t, but it is in fact (unsigned-byte 32)
• trying to set array element of (unsigned-byte 17) to int larger than 2^17 works, but not setting to a symbol, as type t would imply

Should probably at least get a cerror if trying to redefine a primitive. Yes it was dumb. However it was very hard to find - the compiler stopping working doesn't give a lot of hints, and evaluating still worked.

See the comment at
https://github.com/sbcl/sbcl/blob/88fd8640e118ace44185a90baac095025acec3c5/src/code/target-error.lisp#L165

The issue is when invoke-restart is called with an actual restart with a test condition rather than a symbol. Currently invoke-restart calls (compute-restarts nil). So in the case where you've computed restarts (based on the condition) and then choose one of them, that restart can be considered inactive because the test function is run again with condition=nil instead of the condition that was signaled (and tested for).

Uses cons new old instead of replacing old when a duplicate. For sources that have multiple entries at different positions, choose the most recent.

Similar to https://abcl.org/trac/ticket/297 the element type is a bit confused when using :INITIAL-CONTENTS:

CL-USER(18): (make-array 10 :element-type '(unsigned-byte 16) :initial-contents #(-1 1 2 3 4 5 6 7 8 9))
#(-1 1 2 3 4 5 6 7 8 9) ;; expected error instead
CL-USER(19): (make-array 10 :element-type '(unsigned-byte 8) :initial-contents #(-1 1 2 3 4 5 6 7 8 9))
#(255 1 2 3 4 5 6 7 8 9) ;; expected error instead