Do we have a way of indicating that we expect a test to fail?
There's a string in the output that talks about "Unexpected test failures in..." but I am not sure if there's actually any notion of expected vs. unexpected test failure. IIRC in the past when I knew a test would fail I just used reader macros to make sure it wouldn't run.
This is actually not as good as having the test run but not cause a failure.
I ask because I get test failures in clisp on run-program, because somehow clisp lets the common-lisp prompt leak into the output of running a program. So I get something like
("[4]> hello, world") instead of ("hello, world")
IIRC this is a known clisp problem, and may even be fixed in the clisp source. But there hasn't been a clisp release for almost five years now, and I don't intend to build it from source.
With no releases since 2010, IMO clisp is only "living dead," and possibly simply "dead."
OK, so this is a regression in test-program.script, and I traced it to...
lisp-invocation giving the -I flag to clisp, which causes clisp to output extra prompts. Apparently that flag should only be used when invoked inside an emacs M-x shell.
I fixed this in lisp-invocation 1.0.4, and updated the ext/ dependency in master and minimakefile.
But yes, clisp would be better if it were released again.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Always strive to be the best yourself you can be. For you can't possibly be anyone else, anyway.
On Thu, May 7, 2015 at 8:12 AM, Robert P. Goldman rpgoldman@sift.net wrote:
Do we have a way of indicating that we expect a test to fail?
There's a string in the output that talks about "Unexpected test failures in..." but I am not sure if there's actually any notion of expected vs. unexpected test failure. IIRC in the past when I knew a test would fail I just used reader macros to make sure it wouldn't run.
This is actually not as good as having the test run but not cause a failure.
I ask because I get test failures in clisp on run-program, because somehow clisp lets the common-lisp prompt leak into the output of running a program. So I get something like
("[4]> hello, world") instead of ("hello, world")
IIRC this is a known clisp problem, and may even be fixed in the clisp source. But there hasn't been a clisp release for almost five years now, and I don't intend to build it from source.
With no releases since 2010, IMO clisp is only "living dead," and possibly simply "dead."
"Robert P. Goldman" rpgoldman@sift.net writes:
Do we have a way of indicating that we expect a test to fail?
There's a string in the output that talks about "Unexpected test failures in..." but I am not sure if there's actually any notion of expected vs. unexpected test failure. IIRC in the past when I knew a test would fail I just used reader macros to make sure it wouldn't run.
This is actually not as good as having the test run but not cause a failure.
I ask because I get test failures in clisp on run-program, because somehow clisp lets the common-lisp prompt leak into the output of running a program. So I get something like
("[4]> hello, world") instead of ("hello, world")
IIRC this is a known clisp problem,
It looks to me rather like a bug in the test. You're not capturing the output of the program correctly.
Actually, you would have to work very hard to get this concatenation. I have no idea why you would do that.
[10]> (with-open-stream (in (run-program "bash" :arguments '("-c" "echo 'Hello, world!'") :output :stream)) (read-line in)) "Hello, world!" ; NIL [11]>
and may even be fixed in the clisp source. But there hasn't been a clisp release for almost five years now, and I don't intend to build it from source.
With no releases since 2010, IMO clisp is only "living dead," and possibly simply "dead."
With less than 80 open issues, clisp doesn't NEED any new release for now.