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

[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] #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