April 2017 - alexandria-devel - mailman3.common-lisp.net

[alexandria-devel] latest alexandria doesn't build on ECL due to non-standard LOOP
by Anton Vodonosov 18 Jan '18

18 Jan '18

Hello. Alexandria in the latest quicklisp has a regression comparing to quicklisp 2012-02-08. It doesn't build on ECL because on non-standard LOOP construct (it is tolerated by most Lisps, but not by ECL; see here: http://comments.gmane.org/gmane.lisp.ecl.general/3344) The compiler complains about copy-stream method in io.lisp. Build logs: https://cl-test-grid.appspot.com/blob?key=AMIfv97xRRWJgLOa5TvS78VriRK9mQ82m… Best regards, - Anton

2 1

[Alexandria-devel] add COPY-STREAM-CONTENT-INTO-{STRING, BYTE-VECTOR}?
by Jan Moringen 14 Aug '17

14 Aug '17

Hi, in my experience, READ-FILE-INTO-{STRING,BYTE-VECTOR} are very handy. However, maybe half of the time I already receive an open stream and need something like R-F-I-{S,B-V} but for streams. I already submitted the attached patch in mid 2012. Nikodemus didn't want to introduce new functions at that time. Please consider it again. The patch adds the functions COPY-STREAM-CONTENT-INTO-{STRING,BYTE-VECTOR} which implement this feature. Despite the new toplevel functions, little new code is introduced since R-F-I-{S,B-V} can be implemented in terms of the new functions. Thanks in advance and kind regards, Jan

2 3

Wrong handling of duplicate keys in alist-hash-table and plist-hash-table
by Christoph Arenz 10 Apr '17

10 Apr '17

Hi there, apparently for association lists, it is possible to have 'new' entries in front of the list 'shadow' old entries. See https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node153.html However, the Alexandria function alists-hash-table does not account for this behavior when transforming an a-list to a hash-table. There is no checking for duplicate keys in an a-list, resulting in the 'older' entries finding their way in the resulting hash-table. Similar is for p-lists and the plist-hash-table function, though I found contradicting statements whether duplicate keys are allowed for those. At least the hyperspec explains that in case of multiple pairs, the first key/value pair defines the property. See http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_p.htm#property… CL-USER> alist ((:ONE 1) (:TWO 2) (:ONE :SURPRISE)) CL-USER> (assoc :one alist) (:ONE 1) CL-USER> (gethash :one (alexandria:alist-hash-table alist)) (:SURPRISE) T Thanks for your consideration! Kind Regards, Christoph Arenz

2 1