armedbear-ticket April 2017

armedbear-ticket@common-lisp.net

1 participants
14 discussions

[armedbear] #440: Integrate abcl-introspect with upstream SLIME
by armedbear 09 Feb '20

09 Feb '20

#440: Integrate abcl-introspect with upstream SLIME -----------------------+------------------------ Reporter: mevenson | Owner: Type: task | Status: new Priority: major | Milestone: 1.5.0 Component: libraries | Version: Keywords: slime | Parent Tickets: -----------------------+------------------------ abcl-introspect provides a more structured interface for introspecting backtraces; one can more or less just conditionalize the https://gitlab .common-lisp.net/slime/slime master to "just work" here TODO ==== Collapse the patches for a single upstream commit -- Ticket URL: <http://abcl.org/trac/ticket/440> armedbear <http://abcl.org> armedbear

1 4

[armedbear] #445: abcl test fails on trunk
by armedbear 23 Nov '19

23 Nov '19

#445: abcl test fails on trunk -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | Parent Tickets: -------------------------+---------------------- abcl test ... ``-do-compile-test: [mkdir] Created dir: /Users/lori/repos/abcl/build/empty [javac] Compiling 5 source files to /Users/lori/repos/abcl/build/test/classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6 `` -- Ticket URL: <http://abcl.org/trac/ticket/445> armedbear <http://abcl.org> armedbear

1 1

[armedbear] #438: something wrong with (function-lambda-expression (symbol-function 'lambda))
by armedbear 23 Nov '19

23 Nov '19

#438: something wrong with (function-lambda-expression (symbol-function 'lambda)) -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | Parent Tickets: -------------------------+---------------------- {{{ (print (nth-value 2 (function-lambda-expression (symbol-function 'lambda) }}} -> {{{ ABCL Debug.assertTrue() assertion failed! java.lang.Error: ABCL Debug.assertTrue() assertion failed! at org.armedbear.lisp.Debug.assertTrue(Debug.java:48) at org.armedbear.lisp.ArgumentListProcessor.match(ArgumentListProcessor.java:485) at org.armedbear.lisp.Closure.processArgs(Closure.java:230) at org.armedbear.lisp.pprint_152.execute(pprint.lisp:712) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.swank_528.execute(swank.lisp:1732) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.swank_repl_47.execute(swank-repl.lisp:270) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.swank_repl_48.execute(swank-repl.lisp:283) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.swank_repl_46.execute(swank-repl.lisp:270) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.swank_272.execute(swank.lisp:490) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.swank_repl_45.execute(swank-repl.lisp:270) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at abcl_79046444_f3e6_412c_a6d4_362381f8e171.execute(Unknown Source) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.funcall(Lisp.java:172) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2827) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.LispThread.execute(LispThread.java:851) at org.armedbear.lisp.backend_56.execute(backend.lisp:477) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.swank_489.execute(swank.lisp:1471) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.swank_repl_44.execute(swank-repl.lisp:270) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.swank_repl_42.execute(swank-repl.lisp:257) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.swank_512.execute(swank.lisp:1669) at org.armedbear.lisp.LispThread.execute(LispThread.java:851) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2800) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.swank_337.execute(swank.lisp:876) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.swank_327.execute(swank.lisp:864) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.swank_326.execute(swank.lisp:864) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at abcl_434fbc57_502d_44c7_88b2_1424a2cce67e.execute(Unknown Source) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.funcall(Lisp.java:174) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:838) at org.armedbear.lisp.LispThread.execute(LispThread.java:872) at org.armedbear.lisp.backend_97.execute(backend.lisp:842) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.swank_336.execute(swank.lisp:864) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.swank_1.execute(swank.lisp:55) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.swank_325.execute(swank.lisp:864) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.swank_repl_36.execute(swank-repl.lisp:185) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.swank_repl_35.execute(swank-repl.lisp:179) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.swank_1.execute(swank.lisp:55) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.swank_repl_34.execute(swank-repl.lisp:179) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at abcl_98bf6cb5_7e81_4c37_86b6_ae9fc865d0d9.execute(Unknown Source) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.threads_1.execute(threads.lisp:40) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.funcall(Lisp.java:172) at org.armedbear.lisp.LispThread$2.run(LispThread.java:94) at java.lang.Thread.run(Thread.java:745) }}} -- Ticket URL: <http://abcl.org/trac/ticket/438> armedbear <http://abcl.org> armedbear

1 1

[armedbear] #434: Recent maven distributions not found on mvnrepository.com
by armedbear 16 Nov '19

16 Nov '19

#434: Recent maven distributions not found on mvnrepository.com -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | Parent Tickets: -------------------------+---------------------- If you google something like: maven abcl or: maven org.abcl.abcl The top hits are to https://mvnrepository.com/ which doesn't have recent versions Other google hits https://repo1.maven.org/maven2/org/abcl/abcl/ https://maven-repository.com/artifact/org.abcl/abcl https://maven2repo.com/org.abcl/abcl http://search.maven.org/#search%7Cga%7C1%7Corg.abcl Ideally all of these sites would be consistent. But minimally we should figure out how to have them indexed at https://mvnrepository.com since that's at the top of the google results. -- Ticket URL: <http://abcl.org/trac/ticket/434> armedbear <http://abcl.org> armedbear

1 4

[armedbear] #432: open http:// pathname doesn't follow redirects
by armedbear 16 Nov '19

16 Nov '19

#432: open http:// pathname doesn't follow redirects -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: defect | Status: new Priority: major | Milestone: Component: streams | Version: Keywords: | Parent Tickets: -------------------------+---------------------- So if you want to do something like use uiop/stream:copy-file which does something like open the source, open the dest, read/write, it will not do what you might expect. I don't see a way of controlling this behavior. Arguably the default ought to be to follow redirects and open the redirected-to file. -- Ticket URL: <http://abcl.org/trac/ticket/432> armedbear <http://abcl.org> armedbear

1 12

[armedbear] #436: feature request maven exclude dependency
by armedbear 16 Nov '19

16 Nov '19

#436: feature request maven exclude dependency -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | Parent Tickets: -------------------------+---------------------- Like this: https://maven.apache.org/plugins/maven-dependency- plugin/examples/exclude-dependencies-from-dependency-analysis.html To prevent dependencies from one maven artifact from stepping on another. Which they are doing. (each loads a different version) -- Ticket URL: <http://abcl.org/trac/ticket/436> armedbear <http://abcl.org> armedbear

1 10

[Armedbear-ticket] [armedbear] #383: Build standalone JARs which contain additional application code
by armedbear 13 Feb '19

13 Feb '19

#383: Build standalone JARs which contain additional application code -------------------------+----------------------- Reporter: mevenson | Owner: Type: enhancement | Status: new Priority: major | Milestone: 1.4.0 Component: other | Version: 1.4.0-dev Keywords: | -------------------------+----------------------- Clojure ("lein uberjar") as well as jruby ("warbler jar") have facilities for creating a standalone JAR which contains the runtime plus application. Other than creating the necessary assembly instructions, the only substantial problem would seem to be the need to further abstract the mechanism for finding ABCL-CONTRIB to something that could work on a pathname as well as an entire JAR. -- Ticket URL: <http://abcl.org/trac/ticket/383> armedbear <http://abcl.org> armedbear

1 1

[Armedbear-ticket] [armedbear] #384: Binary release has no invocation wrapper
by armedbear 15 Jun '17

15 Jun '17

#384: Binary release has no invocation wrapper ----------------------+----------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.4.0 Component: other | Version: 1.4.0-dev Keywords: | ----------------------+----------------------- ABCL binary release should contain an invocation wrapper ('abcl{,.bat}'). -- Ticket URL: <http://abcl.org/trac/ticket/384> armedbear <http://abcl.org> armedbear

1 1

[armedbear] #422: SYSTEM:RUN-PROGRAM does not work on Java 5/6
by armedbear 15 Jun '17

15 Jun '17

#422: SYSTEM:RUN-PROGRAM does not work on Java 5/6 ------------------------------------------------+------------------------ Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.5.0 Component: interpreter | Version: 1.4.0 Keywords: cffi sys:run-progrom java-5 java-6 | Parent Tickets: ------------------------------------------------+------------------------ In chasing down the errors with CFFI on CL-TEST-GRID <https://mailman .common-lisp.net/pipermail/armedbear-devel/2016-October/003719.html>, I have found that the [java.lang.ProcessBuilder$Redirect][] interface used by Elias and Olof to extend SYS:RUN-PROGRAM for different types of I/O abstractions was introduced with Java 7, and will hence not work on earlier Java implementations. [java.lang.ProcessBuilder$Redirect]: https://docs.oracle.com/javase/8/docs/api/java/lang/ProcessBuilder.Redirect… Invoking ABCL-ASDF:ENSURE-MVN-VERSION, the following form causes the error {{{ (JFIELD "java.lang.ProcessBuilder$Redirect" "INHERIT") }}} TODO: investigate the Java 6 APIs to see if there is a way to do I/O redirection with backwards compatibility. I currently suspect that there is no way to support Java 5/6 for this usage, which is why we never implemented I/O redirection previously. There is undoubtedly a way re-write the SYS:RUN-PROGRAM interface so that we may invoke a process to read its output as a string in Java 5/Java 6, as it worked before. But we will have to figure out a way to advertise the different features of SYS:RUN-PROGRAM depending on the hosting VM. Longer term, we may want to deprecate Java 5/6, but I would really have the compiler emit Java 7-compatible bytecode (mainly by passing the Java 6 verification process) before we begin that. -- Ticket URL: <http://abcl.org/trac/ticket/422> armedbear <http://abcl.org> armedbear

1 9

[armedbear] #444: Attempt to throw to the nonexistent tag DUPLICATABLE-CODE-P ???
by armedbear 01 Jun '17

01 Jun '17

#444: Attempt to throw to the nonexistent tag DUPLICATABLE-CODE-P ??? -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | Parent Tickets: -------------------------+---------------------- (ext::macroexpand-all '(loop for a = (sort foo 'string-lessp :key #'(lambda(x) x )) for b = nil then 1 )) ;; ;; Error compiling /Users/lori/repos/slime/swank/abcl.lisp: ;; Attempt to throw to the nonexistent tag DUPLICATABLE-CODE-P. -- Ticket URL: <http://abcl.org/trac/ticket/444> armedbear <http://abcl.org> armedbear

1 1

[armedbear] #433: merge-pathnames blocks error signal?
by armedbear 01 Jun '17

01 Jun '17

#433: merge-pathnames blocks error signal? -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: defect | Status: new Priority: major | Milestone: Component: interpreter | Version: Keywords: | Parent Tickets: -------------------------+---------------------- `(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 ABCL Debug.assertTrue() assertion failed! 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$pf__eval.execute(Primitives.java:345)`` -- Ticket URL: <http://abcl.org/trac/ticket/433> armedbear <http://abcl.org> armedbear

1 2

[armedbear] #417: Bug in CL:DESTRUCTURING-BIND
by armedbear 15 May '17

15 May '17

#417: Bug in CL:DESTRUCTURING-BIND ---------------------------------------------+------------------------ Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.5.0 Component: interpreter | Version: Keywords: github-issue ansi-compatibility | Parent Tickets: ---------------------------------------------+------------------------ {{{ (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 Initial report on Github from Alan <https://github.com/armedbear/abcl/issues/8>. -- Ticket URL: <http://abcl.org/trac/ticket/417> armedbear <http://abcl.org> armedbear

1 2

[armedbear] #391: "bad place for a wild pathname" on EXT:PROBE-DIRECTORY for NAME containing #\*
by armedbear 18 Apr '17

18 Apr '17

#391: "bad place for a wild pathname" on EXT:PROBE-DIRECTORY for NAME containing #\* -----------------------------------------------+------------------------ Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.3.3 Component: interpreter | Version: Keywords: cl:probe-file ext:probe-directory | Parent Tickets: -----------------------------------------------+------------------------ John Pallister on #abcl reported problems with configuring ASDF via {{{ (asdf:initialize-source-registry '(:source-registry (:tree (:home "src/synchromesh")) :inherit-configuration))}}} for which he later traced down to problems with a pathname NAME containing a #\* character: {{{ <synchromesh> Ooh, that's interesting - EXTENSIONS:PROBE-DIRECTORY has found a filename in the specified directory tree that contains a "*". <synchromesh> Then (much deeper) org.armedbear.lisp.probe_file$pf_probe_directory.execute(probe_file.java:88) throws the error. }}} The exact error cases here still needs to be determined. TBD: What does it mean to PROBE-{DIRECTORY,FILE} on a PATHNAME containing #\*? -- Ticket URL: <http://abcl.org/trac/ticket/391> armedbear <http://abcl.org> armedbear

1 6

[armedbear] #443: ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument
by armedbear 17 Apr '17

17 Apr '17

#443: ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument -------------------------+---------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: Component: interpreter | Version: Keywords: | Parent Tickets: -------------------------+---------------------- In <https://mailman.common-lisp.net/pipermail/armedbear- devel/2017-March/003807.html> {{{ A contributor to the Maxima project bumped into this while trying Maxima + ABCL 1.4.0. CL-USER(1): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -23) 3017516508 CL-USER(2): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -13) 3017516508 CL-USER(3): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 13) 3017516508 CL-USER(4): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 23) 3017516508 CL-USER(5): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 'foo) 3017516508 Not too surprising, I think -- a glance at ./src/org/armedbear/lisp/time.lisp shows that the TIME-ZONE argument doesn't take part in the calculations. TIME-ZONE does come into play in pre-14840 versions of time.lisp and the results are consistent with other CL implementations, at least for the examples exercised by the Maxima test suite (date parsing). }}} -- Ticket URL: <http://abcl.org/trac/ticket/443> armedbear <http://abcl.org> armedbear

1 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket April 2017