Ah, I see now why as
is exported, as it is a synonym for for
. Still don't know why in
is exported, though.
Your second interpretation is correct: those test failures are long-standing and so expected. It's not great that they are there, but the failures are not regressions.
You should be able to compare the results you see with the ones run on the common-lisp.net GitLab by looking at the "build" tab on the left menu to verify that these failures are not new.
Sorry, I opened a merge request a few minutes ago, but was confused by the GitLab UI and had the wrong source branch. I couldn't figure out how to fix that after the fact, so closed it and am opening this one as a replacement. Hope this all works and doesn't cause too much confusion.
I believe this closes issue #22
Makes in-hash-table
and in-hashtable
synonymous. To avoid duplicating the bodies of the clauses I introduced a macro that just sets the word to be used. I've cloned all the existing tests for hash-tables so both forms are tested; all the units pass, except six, unrelated to hash-tables, that didn't pass in the freshly cloned repo before I made these changes. I've also updated the doc to cite both spellings.
Closes #22
Makes in-hash-table
and in-hashtable
synonymous. To avoid duplicating the bodies of the clauses I introduced a macro that just sets the word to be used. I've cloned all the existing tests for hash-tables so both forms are tested; all the units pass, except six, unrelated to hash-tables, that didn't pass in the freshly clone repo before I made these changes. I've also updated the doc to cite both forms.
Closes #22
Makes in-hash-table
and in-hashtable
synonymous. To avoid duplicating the bodies of the clauses I introduced a macro that just sets the word to be used. I've cloned all the existing tests for hash-tables so both forms are tested; all the units pass, except six, unrelated to hash-tables, that didn't pass in the freshly clone repo before I made these changes. I've also updated the doc to cite both forms.
Don Morrison (26cf129a) at 29 Dec 22:12
Don Morrison (5d94b5bc) at 29 Dec 22:11
correct a texinfo command in the doc
Don Morrison (26cf129a) at 29 Dec 21:43
Don Morrison (2cbe4b71) at 29 Dec 21:42
make in-hash-table and in-hashtable synonyms
Don Morrison (26cf129a) at 29 Dec 21:33
It looks as if symbols that introduce clauses, such as for
, collect
and while
, are exported from the iterate
package; but those used only in the interiors of clauses, such as from
, into
and =
, are not. However there are (at least) two exceptions to this pattern: in
and as
are exported, though it looks to me as if they never introduce clauses. Am I missing something? Is there a deliberate reason for this? Is this perhaps a minor bug?
As a sanity check before trying to make some changes in iterate
I tried to run the unit tests in a fresh clone of the repo. It looks to me as if there are several failures, though the wording is a bit ambiguous. I ran the tests with make test
which I believe ran SBCL 2.4.0 on my Ubuntu 22.04.3 LTS box, using the version of RT that comes for free with SBCL. At the end of its output it appeared to report
6 out of 278 total tests failed: ITERATE.TEST::ALWAYS.FINALLY,
ITERATE.TEST::NEVER.FINALLY, ITERATE.TEST::THEREIS.FINALLY,
ITERATE.TEST::IN-STREAM.2, ITERATE.TEST::BUG/WALK.2,
ITERATE.TEST::BUG/COLLECT-AT-BEGINNING.
No unexpected failures.
DO-ITERATE-TESTS ran successfully.
; in:
; PROGN (FORMAT *ERROR-OUTPUT* "~&Note: These tests generate warnings ~
; involving MACROLET within Iterate~%")
; (ITERATE:MULTIPLYING (ITERATE.TEST::FOO))
;
; caught STYLE-WARNING:
; undefined function: ITERATE:MULTIPLYING
;
; compilation unit finished
; Undefined function:
; ITERATE:MULTIPLYING
; caught 1 ERROR condition
; caught 1 WARNING condition
; caught 1 STYLE-WARNING condition
I'm not quite sure how to interpret that "No unexpected failures." Is that RT-speak for "no failures outside the stuff being tested," or "the above failures are known and expected," or something else?
Anyway, would it have been expected that some tests fail, or is this an indication that there's something screwy in my configuration I need to look into? Are these actual bugs in the version of iterate in the repo that need addressing?
Oddly iterate spells it "in-hashtable", while Common Lisp itself (as well as Alexandria and Serapeum) spell things involving hash tables as 'hash-table' with a hyphen. I'm guessing I'm not the only one this divergence in spelling trips up frequently. It would seem sensible to add "in-hash-table" to iterate, and I think doing so would break no existing code so long as "in-hashtable" also remains as an alternative.
Having briefly discussed this with Robert Goldman by mail, I will set about figuring out how to make this happen, and submit a merge request once it seems to be working, including updating the unit tests and documentation.
Robert Goldman (26cf129a) at 29 Dec 01:43
Update README.md
Robert Goldman (26cf129a) at 29 Dec 01:43
Update README.md
WALK-COND
produces unreachable ELSE branches in COND
's that end with a T
case.
This is a problem only on Allegro Common Lisp.
@alendvai That's great. I don't have a ton of time myself, either, but decided to do some hobby programming this weekend.
i only saw this now.
i'm afraid i won't be much help with CL stuff nowadays. but i'llredirect the notification emails at least to my non-gmail account. i'm shutting that one down, and not reading it that frequently anymore.
This is ready to go now. Fixes warnings on the upcoming version of Allegro, and doesn't break anything.