- 25 Aug, 2021 1 commit
-
-
Mark authored
The CIs now build and test with openjdk8, openjdk11, and openjdk16.
-
- 17 Sep, 2021 1 commit
-
-
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
-
- 06 Sep, 2021 1 commit
-
-
Kasper Gałkowski authored
Seems to have been copied by mistake from lisp-to-java/Main.java
-
- 24 Aug, 2021 4 commits
- 12 Aug, 2021 1 commit
-
-
- 14 Aug, 2021 1 commit
-
-
Mark authored
Tests <https://abcl.org/trac/ticket/485>
-
- 12 Aug, 2021 2 commits
-
-
Mark authored
(Phil Eaton) I noticed that under the current systems calls like (jstatic "asList" "java.util.Arrays" (jnew-array "int" 0)) works because the signature is java.util.Arrays.asList(T...) but the system didn't support signatures like java.nio.file.Path.of(String first, String... more). This patch adds support for that and makes the "no method found" message easier to understand when calling jstatic with a signature that is not found. <https://github.com/armedbear/abcl/pull/379>
-
Mark authored
-
- 11 Jul, 2021 3 commits
-
-
Mark authored
-
Mark authored
Under ABCL, when loading system definitions from a JAR-PATHNAME, the PARSE-UNIX-NAMESTRING was including the DEVICE in the defaults to MAKE-PATHNAME. This was mostly harmless but fails when (the as yet unlrelease abcl-1.8.1) tightened the definition of JAR-PATHNAME to always have an absolute directory
-
Mark authored
-
- 10 May, 2021 3 commits
-
-
Mark authored
This allows constructs like (jclass "java.lang.Integer[]") to work.
-
Mark authored
Probably broken since the revision of the JAR-PATHNAME merging semantics in abcl-1.8.0. Resolves <https://github.com/armedbear/abcl/issues/372>, <https://abcl.org/trac/ticket/486>.
-
Mark authored
Use abcl.version instead, fixing manifests for jar packaging. The usage of abcl.implementation.version is now deprecated as not working for a long time. The intention was that if a given source tree could be unidentified as being under source control by the presence of given revision control system artifacts, the abcl.implementation.version would contain a version derived from the revision control system. To hack around the non-prescriptive nature of Ant, chains of conditional targets had to be created that while might have once worked for Subversion, were going to get increasingly hairy for Mercurial and Git.
-
- 07 Feb, 2021 1 commit
-
-
daewok authored
-
- 29 Jan, 2021 1 commit
-
-
Olof-Joachim Frahm authored
Not a particularly nice byte vector representation though.
-
- 21 Dec, 2020 5 commits
-
-
Mark authored
-
Mark authored
New Emacs instance: missed adding (setq-default indent-tabs-mode nil) as the default.
-
Mark authored
With Project Loom, *FEATURES* contains :JAVA-16 :|JVM-16-loom|.
-
Mark authored
Thanks to no-defun-allowed for clueing me into that this would be somewhat easily done. When the underlying JVM supports virtual threads, :VIRTUAL-THREADS will be present in CL:*FEATURES*. The special variable THREADS:*THREADING-MODEL* contains the type of threads being spawned by the implementation: it will be :NATIVE for the default, which is usually a one-to-one mapping from each Java thread to a native thread, and will be :VIRTUAL if using the lightweight threads present in Project Loom JVMs. Tested on "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-16-loom+9-316". Netbeans 12.2 has problems running the debugger with this change due to some sort of bad interaction with the JDWP protocol. Project Loom documentation of java.lang.Thread <https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/Thread.html> Overview of Project Loom <https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html#migration-from-threads-to-virtual-threads> Early Access binaries for openjdk16-loom <https://jdk.java.net/loom/>
-
Mark authored
Add support for configuring openjdk6, openjdk7, and openjdk16 within CI via adding targets for Ant. TODO: macroize this stuff in Ant to add all supported platforms. But we now at least configure the ones we (sorta) actively test.
-
- 29 Nov, 2020 9 commits
-
-
Mark authored
-
Mark authored
Since by default MERGE-PATHNAMES produces a PATHNAME with version :NEWEST, we normalize the uses of JAR-PATHNAME as a key in the zip cache to have version :NEWEST in all cases.
-
Mark authored
A DIRECTORY should always be :ABSOLUTE in a JAR-PATHNAME unless there is no name or type component. Currently a problem with loading ASDF systems from jars, as (UIOP/PATHNAME:PARSE-UNIX-NAMESTRING "quicklisp-abcl" :WANT-RELATIVE T :TYPE "lisp" :DEFAULTS #P"jar:file:///Users/evenson/work/abcl/dist/abcl-contrib.jar!/quicklisp/") fails. Why is WANT-RELATIVE doing this with a absolute default?
-
Mark authored
TODO: Check this works on remote pathnames
-
Mark authored
AS-JAR-PATHNAME-ARCHIVE returns its argument as a JAR-PATHNAME archive.
-
Mark authored
Given the overhaul of the ZipCache for nested FASLs it is not entirely possible to disable the new mechanism. For now we signal this to the user by changing the DISABLE-ZIP-CACHE docstring and always returning NIL when invoked.
-
Mark authored
Under ABCL, when loading system definitions from a JAR-PATHNAME, the PARSE-UNIX-NAMESTRING was including the DEVICE in the defaults to MAKE-PATHNAME. This was mostly harmless but fails when the as yet unreleased abcl-1.8.1 tightened the definition of JAR-PATHNAME to always have an absolute directory. TODO: ensure that this works correctly in the presence of logical pathnames, and under Windows where the device may contain the logical drive letter or the UNC path.
-
Mark authored
TODO: test for more than singly nested zip entries.
-
Mark authored
(reported by Eric Timmons) Fixes <https://abcl.org/trac/ticket/480>
-
- 30 Nov, 2020 1 commit
-
-
Mark Evenson authored
Final version of initial Github Actions workflow
-
- 11 Nov, 2020 3 commits
-
-
Mark authored
(Robert Munyer) Further fixes to <https://abcl.org/trac/ticket/476>. From <https://mailman.common-lisp.net/pipermail/armedbear-devel/2020-November/004166.html>.
-
Mark authored
Explicitly scope all symbols used in our fasl loader. Probably not strictly necessary in all cases, but it makes things clearer to the reader. Use the (find-package :keyword) idiom where it works. One can't reliably use +keyword-package+ when bootstrapping the compiler (?!?). The last fasl prologue Lisp form in the loader __init__._ forms is now an IN-PACKAGE to the COMPILE-FILE value used when creating the fasl. Normalize whitespace and comments. Fixes <https://abcl.org/trac/ticket/475>.
-
Mark authored
-
- 04 Nov, 2020 1 commit
-
-
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>.
-
- 03 Nov, 2020 2 commits
-
-
Mark authored
(Robert Munyer) Fixes "Wrong file type returned by COMPILE-FILE-PATHNAME" (ticket #476) and "COMPILE-FILE, COMPILE-FILE-PATHNAME disagree on output dir" (not yet ticketed). <https://abcl.org/trac/ticket/476> <https://mailman.common-lisp.net/pipermail/armedbear-devel/2020-November/004162.html>
-
Mark authored
-