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

[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