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

Re: [armedbear] #190: FORMAT DOLLARSIGN fails to handle rounding negative arguments
by armedbear 16 Nov '19

16 Nov '19

#190: FORMAT DOLLARSIGN fails to handle rounding negative arguments ----------------------------------+------------------------------ Reporter: Evenson Not Org | Owner: ehuelsmann Type: defect | Status: new Priority: critical | Milestone: 1.6.0 Component: interpreter | Version: 1.0 Resolution: | Keywords: ansi-conformance Parent Tickets: | ----------------------------------+------------------------------ Comment (by Evenson Not Org): In <https://mailman.common-lisp.net/pipermail/armedbear- devel/2019-March/003956.html> dingd noted this is what sbcl does {{{ * (format nil "~$" -0.0) "-0.00" }}} -- Ticket URL: <http://abcl.org/trac/ticket/190#comment:15> armedbear <http://abcl.org> armedbear

1 0

Re: [armedbear] #190: FORMAT DOLLARSIGN fails to handle rounding negative arguments
by armedbear 16 Nov '19

16 Nov '19

#190: FORMAT DOLLARSIGN fails to handle rounding negative arguments ----------------------------------+------------------------------ Reporter: Evenson Not Org | Owner: ehuelsmann Type: defect | Status: new Priority: critical | Milestone: 1.6.0 Component: interpreter | Version: 1.0 Resolution: | Keywords: ansi-conformance Parent Tickets: | ----------------------------------+------------------------------ Description changed by Evenson Not Org: Old description: > In <http://article.gmane.org/gmane.lisp.armedbear.devel/2138> Marshall > Abrams reports: > > It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign > directive's handling of negative numbers when it has to round up. > (Forgive me if this is a known issue--I didn't find it when I searched > the bug list and mailing list archives--or if there's something I'm > misunderstanding.) > > The first group of examples use the F directive for comparison to show > that the problem seems to be specific to dollarsign. (I added blank > lines between example groups for easy reading.) > > The second group of examples illustrates a problem using dollarsign with > negative numbers. The output is about 10x too large, and doesn't seem to > be getting rounded properly. I'm guessing that the out of bounds error > is the result of the same issue. > > The third group of examples shows that the problem doesn't seem to occur > with positive numbers, although there's still an extra negative sign > prepended. > > Thank you- > > Marshall Abrams > > * FAILURES > > Armed Bear Common Lisp 1.0.0-svn-13663 > Java 1.6.0_29 Apple Inc. > Java HotSpot(TM) 64-Bit Server VM > Low-level initialization completed in 0.7 seconds. > Startup completed in 2.211 seconds. > Type ":help" for a list of available commands. > > CL-USER(1): (format t "~,vf" 3 -0.1768522) > -0.177 > NIL > CL-USER(2): (format t "~,vf" 2 -0.1768522) > -0.18 > NIL > CL-USER(3): (format t "~,vf" 1 -0.1768522) > -0.2 > NIL > CL-USER(4): (format t "~,vf" 0 -0.1768522) > -0. > NIL > > CL-USER(5): (format t "~$" -0.1768522) > --1.6 > NIL > CL-USER(6): (format t "~v$" 3 -0.1768522) > --1.75 > NIL > CL-USER(7): (format t "~v$" 2 -0.1768522) > --1.6 > NIL > CL-USER(8): (format t "~v$" 1 -0.1768522) > #<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type > TYPE-ERROR > Array index out of bounds: 2 > Restarts: > 0: TOP-LEVEL Return to top level. > [1] CL-USER(9): 0 > CL-USER(10): (format t "~v$" 0 -0.1768522) > --0. > NIL > > CL-USER(11): (format t "~$" 0.1768522) > 0.18 > NIL > CL-USER(12): (format t "~v$" 3 0.1768522) > 0.177 > NIL > CL-USER(13): (format t "~v$" 2 0.1768522) > 0.18 > NIL > CL-USER(14): (format t "~v$" 1 0.1768522) > 0.2 > NIL > CL-USER(15): (format t "~v$" 0 0.1768522) > 0. > NIL > }}} New description: In <http://article.gmane.org/gmane.lisp.armedbear.devel/2138> Marshall Abrams reports: It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign directive's handling of negative numbers when it has to round up. (Forgive me if this is a known issue--I didn't find it when I searched the bug list and mailing list archives--or if there's something I'm misunderstanding.) The first group of examples use the F directive for comparison to show that the problem seems to be specific to dollarsign. (I added blank lines between example groups for easy reading.) The second group of examples illustrates a problem using dollarsign with negative numbers. The output is about 10x too large, and doesn't seem to be getting rounded properly. I'm guessing that the out of bounds error is the result of the same issue. The third group of examples shows that the problem doesn't seem to occur with positive numbers, although there's still an extra negative sign prepended. Thank you- Marshall Abrams {{{ Armed Bear Common Lisp 1.0.0-svn-13663 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.7 seconds. Startup completed in 2.211 seconds. Type ":help" for a list of available commands. CL-USER(1): (format t "~,vf" 3 -0.1768522) -0.177 NIL CL-USER(2): (format t "~,vf" 2 -0.1768522) -0.18 NIL CL-USER(3): (format t "~,vf" 1 -0.1768522) -0.2 NIL CL-USER(4): (format t "~,vf" 0 -0.1768522) -0. NIL CL-USER(5): (format t "~$" -0.1768522) --1.6 NIL CL-USER(6): (format t "~v$" 3 -0.1768522) --1.75 NIL CL-USER(7): (format t "~v$" 2 -0.1768522) --1.6 NIL CL-USER(8): (format t "~v$" 1 -0.1768522) #<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type TYPE-ERROR Array index out of bounds: 2 Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(9): 0 CL-USER(10): (format t "~v$" 0 -0.1768522) --0. NIL CL-USER(11): (format t "~$" 0.1768522) 0.18 NIL CL-USER(12): (format t "~v$" 3 0.1768522) 0.177 NIL CL-USER(13): (format t "~v$" 2 0.1768522) 0.18 NIL CL-USER(14): (format t "~v$" 1 0.1768522) 0.2 NIL CL-USER(15): (format t "~v$" 0 0.1768522) 0. NIL }}} -- -- Ticket URL: <http://abcl.org/trac/ticket/190#comment:14> armedbear <http://abcl.org> armedbear

1 0

Re: [armedbear] #190: FORMAT DOLLARSIGN fails to handle rounding negative arguments
by armedbear 16 Nov '19

16 Nov '19

#190: FORMAT DOLLARSIGN fails to handle rounding negative arguments ----------------------------------+------------------------------ Reporter: Evenson Not Org | Owner: ehuelsmann Type: defect | Status: new Priority: critical | Milestone: 1.6.0 Component: interpreter | Version: 1.0 Resolution: | Keywords: ansi-conformance Parent Tickets: | ----------------------------------+------------------------------ Description changed by Evenson Not Org: Old description: > In <http://article.gmane.org/gmane.lisp.armedbear.devel/2138> Marshall > Abrams reports: > > {{{ > > It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign > directive's handling of negative numbers when it has to round up. > (Forgive me if this is a known issue--I didn't find it when I searched > the bug list and mailing list archives--or if there's something I'm > misunderstanding.) > > The first group of examples use the F directive for comparison to show > that the problem seems to be specific to dollarsign. (I added blank > lines between example groups for easy reading.) > > The second group of examples illustrates a problem using dollarsign with > negative numbers. The output is about 10x too large, and doesn't seem to > be getting rounded properly. I'm guessing that the out of bounds error > is the result of the same issue. > > The third group of examples shows that the problem doesn't seem to occur > with positive numbers, although there's still an extra negative sign > preprended. > > Thank you- > > Marshall Abrams > }}} > > Armed Bear Common Lisp 1.0.0-svn-13663 > Java 1.6.0_29 Apple Inc. > Java HotSpot(TM) 64-Bit Server VM > Low-level initialization completed in 0.7 seconds. > Startup completed in 2.211 seconds. > Type ":help" for a list of available commands. > > CL-USER(1): (format t "~,vf" 3 -0.1768522) > -0.177 > NIL > CL-USER(2): (format t "~,vf" 2 -0.1768522) > -0.18 > NIL > CL-USER(3): (format t "~,vf" 1 -0.1768522) > -0.2 > NIL > CL-USER(4): (format t "~,vf" 0 -0.1768522) > -0. > NIL > > CL-USER(5): (format t "~$" -0.1768522) > --1.6 > NIL > CL-USER(6): (format t "~v$" 3 -0.1768522) > --1.75 > NIL > CL-USER(7): (format t "~v$" 2 -0.1768522) > --1.6 > NIL > CL-USER(8): (format t "~v$" 1 -0.1768522) > #<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type > TYPE-ERROR > Array index out of bounds: 2 > Restarts: > 0: TOP-LEVEL Return to top level. > [1] CL-USER(9): 0 > CL-USER(10): (format t "~v$" 0 -0.1768522) > --0. > NIL > > CL-USER(11): (format t "~$" 0.1768522) > 0.18 > NIL > CL-USER(12): (format t "~v$" 3 0.1768522) > 0.177 > NIL > CL-USER(13): (format t "~v$" 2 0.1768522) > 0.18 > NIL > CL-USER(14): (format t "~v$" 1 0.1768522) > 0.2 > NIL > CL-USER(15): (format t "~v$" 0 0.1768522) > 0. > NIL > }}} New description: In <http://article.gmane.org/gmane.lisp.armedbear.devel/2138> Marshall Abrams reports: It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign directive's handling of negative numbers when it has to round up. (Forgive me if this is a known issue--I didn't find it when I searched the bug list and mailing list archives--or if there's something I'm misunderstanding.) The first group of examples use the F directive for comparison to show that the problem seems to be specific to dollarsign. (I added blank lines between example groups for easy reading.) The second group of examples illustrates a problem using dollarsign with negative numbers. The output is about 10x too large, and doesn't seem to be getting rounded properly. I'm guessing that the out of bounds error is the result of the same issue. The third group of examples shows that the problem doesn't seem to occur with positive numbers, although there's still an extra negative sign prepended. Thank you- Marshall Abrams * FAILURES Armed Bear Common Lisp 1.0.0-svn-13663 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.7 seconds. Startup completed in 2.211 seconds. Type ":help" for a list of available commands. CL-USER(1): (format t "~,vf" 3 -0.1768522) -0.177 NIL CL-USER(2): (format t "~,vf" 2 -0.1768522) -0.18 NIL CL-USER(3): (format t "~,vf" 1 -0.1768522) -0.2 NIL CL-USER(4): (format t "~,vf" 0 -0.1768522) -0. NIL CL-USER(5): (format t "~$" -0.1768522) --1.6 NIL CL-USER(6): (format t "~v$" 3 -0.1768522) --1.75 NIL CL-USER(7): (format t "~v$" 2 -0.1768522) --1.6 NIL CL-USER(8): (format t "~v$" 1 -0.1768522) #<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type TYPE-ERROR Array index out of bounds: 2 Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(9): 0 CL-USER(10): (format t "~v$" 0 -0.1768522) --0. NIL CL-USER(11): (format t "~$" 0.1768522) 0.18 NIL CL-USER(12): (format t "~v$" 3 0.1768522) 0.177 NIL CL-USER(13): (format t "~v$" 2 0.1768522) 0.18 NIL CL-USER(14): (format t "~v$" 1 0.1768522) 0.2 NIL CL-USER(15): (format t "~v$" 0 0.1768522) 0. NIL }}} -- -- Ticket URL: <http://abcl.org/trac/ticket/190#comment:13> armedbear <http://abcl.org> armedbear

1 0

Re: [armedbear] #190: FORMAT DOLLARSIGN fails to handle rounding negative arguments
by armedbear 16 Nov '19

16 Nov '19

#190: FORMAT DOLLARSIGN fails to handle rounding negative arguments ----------------------------------+------------------------------ Reporter: Evenson Not Org | Owner: ehuelsmann Type: defect | Status: new Priority: critical | Milestone: 1.6.0 Component: interpreter | Version: 1.0 Resolution: | Keywords: ansi-conformance Parent Tickets: | ----------------------------------+------------------------------ Description changed by Evenson Not Org: Old description: > [http://article.gmane.org/gmane.lisp.armedbear.devel/2138 Marshall Abrams > reports:] > > {{{ > > It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign > directive's handling of negative numbers when it has to round up. > (Forgive me if this is a known issue--I didn't find it when I searched > the bug list and mailing list archives--or if there's something I'm > misunderstanding.) > > The first group of examples use the F directive for comparison to show > that the problem seems to be specific to dollarsign. (I added blank > lines between example groups for easy reading.) > > The second group of examples illustrates a problem using dollarsign with > negative numbers. The output is about 10x too large, and doesn't seem to > be getting rounded properly. I'm guessing that the out of bounds error > is the result of the same issue. > > The third group of examples shows that the problem doesn't seem to occur > with positive numbers, although there's still an extra negative sign > preprended. > > Thank you- > > Marshall Abrams > > Armed Bear Common Lisp 1.0.0-svn-13663 > Java 1.6.0_29 Apple Inc. > Java HotSpot(TM) 64-Bit Server VM > Low-level initialization completed in 0.7 seconds. > Startup completed in 2.211 seconds. > Type ":help" for a list of available commands. > > CL-USER(1): (format t "~,vf" 3 -0.1768522) > -0.177 > NIL > CL-USER(2): (format t "~,vf" 2 -0.1768522) > -0.18 > NIL > CL-USER(3): (format t "~,vf" 1 -0.1768522) > -0.2 > NIL > CL-USER(4): (format t "~,vf" 0 -0.1768522) > -0. > NIL > > CL-USER(5): (format t "~$" -0.1768522) > --1.6 > NIL > CL-USER(6): (format t "~v$" 3 -0.1768522) > --1.75 > NIL > CL-USER(7): (format t "~v$" 2 -0.1768522) > --1.6 > NIL > CL-USER(8): (format t "~v$" 1 -0.1768522) > #<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type > TYPE-ERROR > Array index out of bounds: 2 > Restarts: > 0: TOP-LEVEL Return to top level. > [1] CL-USER(9): 0 > CL-USER(10): (format t "~v$" 0 -0.1768522) > --0. > NIL > > CL-USER(11): (format t "~$" 0.1768522) > 0.18 > NIL > CL-USER(12): (format t "~v$" 3 0.1768522) > 0.177 > NIL > CL-USER(13): (format t "~v$" 2 0.1768522) > 0.18 > NIL > CL-USER(14): (format t "~v$" 1 0.1768522) > 0.2 > NIL > CL-USER(15): (format t "~v$" 0 0.1768522) > 0. > NIL > }}} New description: In <http://article.gmane.org/gmane.lisp.armedbear.devel/2138> Marshall Abrams reports: {{{ It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign directive's handling of negative numbers when it has to round up. (Forgive me if this is a known issue--I didn't find it when I searched the bug list and mailing list archives--or if there's something I'm misunderstanding.) The first group of examples use the F directive for comparison to show that the problem seems to be specific to dollarsign. (I added blank lines between example groups for easy reading.) The second group of examples illustrates a problem using dollarsign with negative numbers. The output is about 10x too large, and doesn't seem to be getting rounded properly. I'm guessing that the out of bounds error is the result of the same issue. The third group of examples shows that the problem doesn't seem to occur with positive numbers, although there's still an extra negative sign preprended. Thank you- Marshall Abrams }}} Armed Bear Common Lisp 1.0.0-svn-13663 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.7 seconds. Startup completed in 2.211 seconds. Type ":help" for a list of available commands. CL-USER(1): (format t "~,vf" 3 -0.1768522) -0.177 NIL CL-USER(2): (format t "~,vf" 2 -0.1768522) -0.18 NIL CL-USER(3): (format t "~,vf" 1 -0.1768522) -0.2 NIL CL-USER(4): (format t "~,vf" 0 -0.1768522) -0. NIL CL-USER(5): (format t "~$" -0.1768522) --1.6 NIL CL-USER(6): (format t "~v$" 3 -0.1768522) --1.75 NIL CL-USER(7): (format t "~v$" 2 -0.1768522) --1.6 NIL CL-USER(8): (format t "~v$" 1 -0.1768522) #<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type TYPE-ERROR Array index out of bounds: 2 Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(9): 0 CL-USER(10): (format t "~v$" 0 -0.1768522) --0. NIL CL-USER(11): (format t "~$" 0.1768522) 0.18 NIL CL-USER(12): (format t "~v$" 3 0.1768522) 0.177 NIL CL-USER(13): (format t "~v$" 2 0.1768522) 0.18 NIL CL-USER(14): (format t "~v$" 1 0.1768522) 0.2 NIL CL-USER(15): (format t "~v$" 0 0.1768522) 0. NIL }}} -- -- Ticket URL: <http://abcl.org/trac/ticket/190#comment:12> armedbear <http://abcl.org> armedbear

1 0

[armedbear] #460: upgraded-array-element-type/class-of for arrays
by armedbear 10 Nov '19

10 Nov '19

#460: upgraded-array-element-type/class-of for arrays -------------------------+---------------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.5.1 Component: interpreter | Version: 1.6.0-dev Keywords: | Parent Tickets: -------------------------+---------------------------- Alan notes in <https://github.com/armedbear/abcl/issues/84> {{{ No code of mine depends on this, but I was reading an article and it prompted me to check types of arrays and how upgraded-array-element-type works. Bottom line is that it isn't consistent. CL-USER> (make-array 1 :element-type '(unsigned-byte 16)) #(0) CL-USER> (jobject-class *) #<java class org.armedbear.lisp.BasicVector_UnsignedByte16 {6F28B4E2}> CL-USER> (class-of (make-array 1 :element-type '(unsigned-byte 16))) #<built-in-class vector {352D86C9}> CL-USER> (upgraded-array-element-type '(unsigned-byte 16)) (unsigned-byte 16) CL-USER> (make-array 1 :element-type '(unsigned-byte 17)) #(0) CL-USER> (jobject-class *) #<java class org.armedbear.lisp.BasicVector_UnsignedByte32 {1C49E33C}> CL-USER> (upgraded-array-element-type '(unsigned-byte 17)) t CL-USER> (class-of (make-array 1 :element-type '(unsigned-byte 17))) #<built-in-class vector {352D86C9}> Summary: Implementation of arrays of unsigned byte 16 vs 17 are different class-of reports the same type upgraded-array-element-type of (unsigned-byte 17) reports t, but it is in fact (unsigned-byte 32) trying to set array element of (unsigned-byte 17) to int larger than 2^17 works, but not setting to a symbol, as type t would imply }}} -- Ticket URL: <http://abcl.org/trac/ticket/460> armedbear <http://abcl.org> armedbear

1 1

Re: [armedbear] #297: Array elements aren't checked when setting specialized integer arrays
by armedbear 02 Nov '19

02 Nov '19

#297: Array elements aren't checked when setting specialized integer arrays ------------------------------+------------------------ Reporter: stassats | Owner: ehuelsmann Type: defect | Status: new Priority: critical | Milestone: 1.6.0 Component: interpreter | Version: 1.2.0-dev Resolution: | Keywords: Parent Tickets: | ------------------------------+------------------------ Comment (by Evenson Not Org): Referenced by <https://github.com/armedbear/abcl/issues/105>. -- Ticket URL: <http://abcl.org/trac/ticket/297#comment:10> armedbear <http://abcl.org> armedbear

1 0

[armedbear] #463: Problems with compiling AP5
by armedbear 29 Mar '19

29 Mar '19

#463: Problems with compiling AP5 ----------------------+------------------------ Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.6.0 Component: compiler | Version: Keywords: | Parent Tickets: ----------------------+------------------------ In <https://mailman.common-lisp.net/pipermail/armedbear- devel/2019-March/003967.html>, Dan Cohen notes problems with AP5 recompiling code. -- Ticket URL: <http://abcl.org/trac/ticket/463> armedbear <http://abcl.org> armedbear

1 2

[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] #461: Build failure via use of an implementation beyond Java 8 needs to be caught
by armedbear 17 Jan '19

17 Jan '19

#461: Build failure via use of an implementation beyond Java 8 needs to be caught ---------------------------+---------------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.6.0 Component: build | Version: 1.6.0-dev Keywords: beyond-java-8 | Parent Tickets: ---------------------------+---------------------------- Mebbe the regex in <file:abcl.xml>? -- Ticket URL: <http://abcl.org/trac/ticket/461> armedbear <http://abcl.org> armedbear

1 1

[armedbear] #459: Defsetf Lambda-Lists Don't Permit the &environment Parameter
by armedbear 28 Aug '18

28 Aug '18

#459: Defsetf Lambda-Lists Don't Permit the &environment Parameter ---------------------------+---------------------------- Reporter: mevenson | Owner: Type: defect | Status: new Priority: major | Milestone: 1.6.0 Component: interpreter | Version: 1.6.0-dev Keywords: com.github-88 | Parent Tickets: ---------------------------+---------------------------- https://github.com/armedbear/abcl/issues/88 {{{ This is in violation to 3.4.7 which specifically allows the &environment parameter in defsetf lambda-lists. Test case: (defsetf foo (&environment env place) (value)) ;; => &ENVIRONMENT is only valid at top level of lambda list. I'm not entirely sure if 3.4.7 requires &environment to come after the places, unlike other lambda-lists where &environment has to be first. In any case, late &environment also fails in the same fashion. (defsetf foo (place &environment env) (value)) ;; => &ENVIRONMENT is only valid at top level of lambda list. }}} -- Ticket URL: <http://abcl.org/trac/ticket/459> armedbear <http://abcl.org> armedbear

1 0