1. 19 Sep, 2021 2 commits
  2. 25 Aug, 2021 1 commit
  3. 17 Sep, 2021 1 commit
    • Samuel Hunter's avatar
      Fix and standardize all error reader functions · 2aae074e
      Samuel Hunter authored
      Fixes #388, replaces #389. The reader function `stream-error-stream`
      signals a `type-error` if it's applied to conditions that's typep to
      `stream-error`, but whose class is a subtype to `stream-error`:
      
      ```lisp
      (define-condition broken-error (stream-error) ())
        BROKEN-ERROR
      (stream-error-stream (make-condition 'stream-error :stream (make-string-input-stream "foo")))
        #S(SYSTEM::STRING-INPUT-STREAM)
      (stream-error-stream (make-condition 'broken-error :stream (make-string-input-stream "foo")))
        #<THREAD "interpreter" {2075326}>: Debugger invoked on condition of type TYPE-ERROR
          The value #<BROKEN-ERROR {75A83798}> is not of type STREAM-ERROR.
      ```
      
      This fault exists within these reader functions:
      
      - file-error-pathname (almost -- instead of a type-error, the function returns NIL instead.)
      - package-error-package
      - arithmetic-error-operation
      - arithmetic-error-operands
      
      The fault exists because the Java code checks if its argument is
      instanceof its respective Java class. So, the method will fail on any
      conditions defined in CL that subclass these errors.
      
      Furthermore, some reader functions only check if they're instanceof
      StandardObject, which allows any CLOS object to succeed as long as the
      slot the primitive method is looking for exists:
      
      - cell-error-name
      - type-error-datum
      - type-error-expected-type
      
      Finally, some reader functions exist in standalone Java files, while
      others reside in its condition's class file, adding to some
      organizational clutter.
      
      This change fills two main jobs:
      
      - Standardize all reader functions to the same behavior: If the argument
        is typep to the right condition, return the right slot value.
        Otherwise, signal a type error.
      - Move standalone reader Java code to the files of errors they apply to.
      
      As an aside, this change would make ABCL's reader functions conformant
      to a wave of proposals for WSCL:
      
      - https://github.com/s-expressionists/wscl/blob/main/wscl-issues/proposed/cell-error-name-type-error
      - https://github.com/s-expressionists/wscl/blob/main/wscl-issues/proposed/stream-error-stream-type-error
      - https://github.com/s-expressionists/wscl/blob/main/wscl-issues/proposed/type-error-datum-type-error
      - And the rest
      2aae074e
  4. 06 Sep, 2021 1 commit
  5. 24 Aug, 2021 4 commits
  6. 12 Aug, 2021 1 commit
  7. 14 Aug, 2021 1 commit
  8. 12 Aug, 2021 2 commits
  9. 11 Jul, 2021 3 commits
  10. 10 May, 2021 3 commits
  11. 07 Feb, 2021 1 commit
  12. 29 Jan, 2021 1 commit
  13. 21 Dec, 2020 5 commits
  14. 29 Nov, 2020 9 commits
  15. 30 Nov, 2020 1 commit
  16. 11 Nov, 2020 3 commits
  17. 04 Nov, 2020 1 commit
    • Mark's avatar
      arrays: fix fail to reset position after relative access · 231e00ef
      Mark authored
      The position of all buffers should always be zero.  TODO how to
      unintrusively make this assertion?
      
      We fix new types specializing (or (unsigned-byte 8) (unsigned-byte
      32)) in BasicVector_ByteBuffer, ComplexArray_ByteBuffer,
      ComplexVector_ByteBuffer, and ComplexVector_IntBuffer for relative
      accesses which always advance the position of the
      underlying java.nio.Buffer subclass.
      
      Fixes <https://github.com/armedbear/abcl/issues/345>.
      231e00ef