g000001/arc-compat

Arc compatible package

arc-compat

Arc compatible package for CL

---

Licence: Perl Foundations’s Artistic License 2.0.

---

Example:

(in-package :arc-user)
(named-readtables:in-readtable :arc)


(map [car cdr._] '((1 2) (1 2) (1 2) (1 2) (1 2)))
;=>  (2 2 2 2 2)


(map #'list:car:cdr '((1 2) (1 2) (1 2) (1 2) (1 2)))
;=>  ((2) (2) (2) (2) (2))


(accum acc
  (each e (range 0 10)
    (when odd.e acc.e)))
;=>  (1 3 5 7 9)

arc-compat's Issues

The test for SINCE can fail sometimes.

The current test for since currently does;
(== 1 (let t0 (seconds) (sleep 1) (since t0))
which may fail if the first seconds happens just before the switch to returning the next second, and the sleep
plus the rest of processing takes a little more a second. It fails to me once in several tens runs of the test-suite.
I suggest change it like this:

 (tst since
    (== t (let t0 (seconds) (sleep 0.99)
            (cl:let ((s1 (since t0)))
              (or (cl:= s1 1)
                  (and (cl:= s1 0)
                       (progn  (sleep 0.1)
                         (cl:= (since t0) 1))))))))

Lispworks get-time-of-day hack needs fising for 32bit

arc-compat/ac.lisp

Line 452 in b96c15c

(declare (cl:type (simple-array (unsigned-byte 64) (2)) tv))

This declaration works on 64bit, but on 32bit. On 32bit it is (unsigned-byte 32), so the declaration needs to be:

(declare (cl:type (simple-array #+lispworks-64bit (unsigned-byte 64)
                                    #+lispworks-32bit (unsigned-byte 32)
                                    (2)) tv))

/dev/urandom will not work on Windows

rand-string is string.lisp uses "dev/urandom", which will not work on Windows

The tests effectively assume ordering of items in hash-tables

Both the test OBJ in table.lisp and the test DEDUP in list.lisp (last check with the result of calling obj) effectively assume specific order of items inside a hash-table, because they generate a list by mapping over a hash table and compare the result to a list with a specific order. That cause these tests to fail unpredictably.

They may be other tests with the same issue, I didn't check systemetically.

WITH-OPEN-STREAM may be used incorrectly in call-w/stdin and call-w/stdout

in file ac.lisp, the functions arc:call-w/stdin and arc:call-w/stdout both use with-open-stream, which closes the stream on exit. That is probably not the intention.

It specifically goes wrong when arc:call-w/stdout is called to output into a string stream and then getting the string of the stream, because calling get-output-stream-string on a closed stream gives "unspecifed results" (see entry for CLOSE in the ANSI standard). The test (tst call-w/stdout .. ) in test-after.lisp fails because of that on LispWorks.

If the closing of the stream intentional, then the test needs to be changed such that the call to get-output-stream-string (arc:inside, which is fbound to #'get-output-stream-string) needs to be inside the with-open-stream, so the call happens before the stream is closed.

Does not build on sbcl 1.4.10 - type inference issue

Log is here: http://report.quicklisp.org/2018-07-27/failure-report/arc-compat.html#arc-compat