January 2017 - armedbear-ticket - mailman3.common-lisp.net

[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] #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] #437: ABCL-INTROSPECT fails to load
by armedbear 18 Jan '17

18 Jan '17

#437: ABCL-INTROSPECT fails to load -----------------------------+------------------------------ Reporter: mevenson | Owner: aruttenberg Type: defect | Status: new Priority: major | Milestone: 1.4.1 Component: abcl-contrib | Version: 1.5.0-dev Keywords: abcl-introspect | Parent Tickets: -----------------------------+------------------------------ From ABCL trunk <http://abcl.org/trac/changeset/14955> {{{ (require :abcl-contrib) }}} errors with {{{ The function (setf system:function-plist) is undefined. [Condition of type undefined-function] Restarts: 0: [try-recompiling] Recompile abcl-introspect and try loading it again 1: [retry] Retry loading FASL for #<asdf/lisp-action:cl-source-file "abcl-introspect" "abcl-introspect">. 2: [accept] Continue, treating loading FASL for #<asdf/lisp-action:cl- source-file "abcl-introspect" "abcl-introspect"> as having been successful. 3: [retry] Retry ASDF operation. 4: [clear-configuration-and-retry] Retry ASDF operation after resetting the configuration. 5: [retry] Retry SLIME REPL evaluation request. --more-- Backtrace: 0: ([error printing frame] 1: (apply [error printing frame] 2: (system::run-hook system::*invoke-debugger-hook* #<undefined-function {239477D8}> [error printing frame] 3: (invoke-debugger #<undefined-function {239477D8}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Symbol.getSymbolSetfFunctionOrDie(Symbol.java:426) 6: org.armedbear.lisp.abcl_introspect_tmpY7A8VAJR_16.execute(abcl- introspect.lisp:166) 7: org.armedbear.lisp.abcl_introspect_tmpY7A8VAJR_15.execute(abcl- introspect.lisp:166) 8: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 9: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 10: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 11: org.armedbear.lisp.abcl_introspect_tmpY7A8VAJR_34.execute(abcl- introspect.lisp:331) 12: org.armedbear.lisp.clos_304.execute(clos.lisp:2621) 13: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 14: org.armedbear.lisp.clos_292.execute(clos.lisp:2528) 15: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 16: org.armedbear.lisp.clos_277.execute(clos.lisp:2302) 17: org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) 18: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 19: org.armedbear.lisp.LispThread.execute(LispThread.java:832) --more-- }}} -- Ticket URL: <http://abcl.org/trac/ticket/437> armedbear <http://abcl.org> armedbear

1 2

[armedbear] #430: Some file compiled functions didn't record arglist or docstrings
by armedbear 17 Jan '17

17 Jan '17

#430: Some file compiled functions didn't record arglist or docstrings -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: defect | Status: new Priority: major | Milestone: Component: build | Version: Keywords: | Parent Tickets: -------------------------+---------------------- Arglists were being stored as strings and generated using format. Format wasn't available early during abcl build. Soln: Save arglists as lists. Github issue: https://github.com/armedbear/abcl/issues/21 Pull request https://github.com/armedbear/abcl/pull/13 -- Ticket URL: <http://abcl.org/trac/ticket/430> armedbear <http://abcl.org> armedbear

1 2

[armedbear] #427: bug in invoke-restart
by armedbear 17 Jan '17

17 Jan '17

#427: bug in invoke-restart -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: defect | Status: new Priority: major | Milestone: Component: interpreter | Version: Keywords: | Parent Tickets: -------------------------+---------------------- See the comment at https://github.com/sbcl/sbcl/blob/88fd8640e118ace44185a90baac095025acec3c5/… /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). Pull request https://github.com/armedbear/abcl/pull/18 to fix copied from https://github.com/armedbear/abcl/issues/17 -- Ticket URL: <http://abcl.org/trac/ticket/427> armedbear <http://abcl.org> armedbear

1 1

[armedbear] #429: Some java stack frames don't have source file information, leading to null pointer exceptions
by armedbear 17 Jan '17

17 Jan '17

#429: Some java stack frames don't have source file information, leading to null pointer exceptions -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | Parent Tickets: -------------------------+---------------------- From https://github.com/armedbear/abcl/issues/20 Pull request https://github.com/armedbear/abcl/pull/15 -- Ticket URL: <http://abcl.org/trac/ticket/429> armedbear <http://abcl.org> armedbear

1 2

[armedbear] #428: Protect against java exceptions while printing java objects
by armedbear 17 Jan '17

17 Jan '17

#428: Protect against java exceptions while printing java objects -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | Parent Tickets: -------------------------+---------------------- From https://github.com/armedbear/abcl/issues/19 Pull request https://github.com/armedbear/abcl/pull/16 -- Ticket URL: <http://abcl.org/trac/ticket/428> armedbear <http://abcl.org> armedbear

1 2

[armedbear] #431: Cryptic error while compiling
by armedbear 17 Jan '17

17 Jan '17

#431: Cryptic error while compiling -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | Parent Tickets: -------------------------+---------------------- 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 Github: https://github.com/armedbear/abcl/issues/22 Pull request: https://github.com/armedbear/abcl/pull/23 -- Ticket URL: <http://abcl.org/trac/ticket/431> armedbear <http://abcl.org> armedbear

1 2

[armedbear] #414: getFunctionClassBytes for CompiledClosures <https://github.com/armedbear/abcl/issues/3>
by armedbear 16 Jan '17

16 Jan '17

#414: getFunctionClassBytes for CompiledClosures <https://github.com/armedbear/abcl/issues/3> ----------------------+---------------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.5.0 Component: compiler | Version: 1.4.0-dev Keywords: | Parent Tickets: ----------------------+---------------------------- <https://github.com/armedbear/abcl/issues/3> 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)) }}} -- Ticket URL: <http://abcl.org/trac/ticket/414> armedbear <http://abcl.org> armedbear

1 1

[armedbear] #435: bug in maven resolve?
by armedbear 14 Jan '17

14 Jan '17

#435: bug in maven resolve? -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | Parent Tickets: -------------------------+---------------------- This one works. (funcall (intern "RESOLVE" 'abcl-asdf) "org.apache.felix/org.apache.felix.framework/5.6.1") "/Users/alanr/.m2/repository/org/apache/felix/org.apache.felix.framework/5.6.1/org.apache.felix.framework-5.6.1.jar" But this one doesn't returns two paths concatenated. (funcall (intern "RESOLVE" 'abcl-asdf) "org.apache.felix/org.apache.felix.main/5.6.1") ->"/Users/alanr/.m2/repository/org/apache/felix/org.apache.felix.main/5.6.1/org.apache.felix.main-5.6.1.jar:/Users/alanr/.m2/repository/org/apache/felix/org.apache.felix.framework/5.6.1/org.apache.felix.framework-5.6.1.jar" -- Ticket URL: <http://abcl.org/trac/ticket/435> armedbear <http://abcl.org> armedbear

1 1

Re: [armedbear] #229: JSS method resolution failure
by armedbear 14 Jan '17

14 Jan '17

#229: JSS method resolution failure --------------------------+------------------------------------------------ Reporter: | Owner: mevenson mevenson | Type: defect | Status: closed Priority: | Milestone: 1.1.0 critical | Component: java | Version: 1.1.0-dev Resolution: fixed | Keywords: jss method-resolution abcl-contrib Parent Tickets: | --------------------------+------------------------------------------------ Comment (by aruttenberg): fixed the test -- Ticket URL: <http://abcl.org/trac/ticket/229#comment:5> armedbear <http://abcl.org> armedbear

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket January 2017