- stefil-devel@common-lisp.net - mailman3.common-lisp.net

Re: [stefil-devel] trouble with darcs repos
by Attila Lendvai 22 Feb '10

22 Feb '10

hi Daniel, > Sorry for the slow reply. Thank you for explaining the situation. Since > hu.dwim.stefil is a fork of Stefil, could you remove the darcs "redirect" not really a fork in the sense that i don't know about anyone doing/planning any changes against the old repo. or at least we certainly abandoned it... > notice and simply put a note on the Stefil website? i'm not sure i want to do that, because hu.dwim.stefil is a new and better revision of stefil and i want newcomers to use the new version and report bugs/send patches against that. if someone is already using stefil then they can decide if it's worth the trouble to upgrade after seeing that heads up message... btw, that notice is a hard-link between all our 10+ obsolete repos. if you don't want to bother, then please just ignore the notice and keep on using the old repo. -- attila

1 0

Re: [stefil-devel] Stefil documentation
by Attila Lendvai 22 Feb '10

22 Feb '10

> Are there more comprehensive documentation for Stefil other than the > one at http://common-lisp.net/project/stefil/demo.html? The README > currently points to http://dwim.hu/project/hu.dwim.stefil which > doesn't help a lot either. > > Do you have pointers that you can point me to? too many things to do and no time for documentation, sorry. the canonical point will be http://dwim.hu/project/hu.dwim.stefil which is the content available in the hu.dwim.stefil repo in documentation/stefil.lisp you can also find the log of a lightning talk in documentation/lightning-talk.lisp. there's really not much more to stefil docs than that... hth, -- attila

1 0

[stefil-devel] 'q' (call restart 'abort-tests) doesn't work in sldb buffer
by Jianshi Huang 15 Jul '09

15 Jul '09

I'm using the latest stefil with SLIME (CVS 2009-6-14). The key stroke 'q' doesn't work in the sldb frame which according to the stefil.lisp, should call the abort-tests restart. The reason seems to be that swank::*sldb-quit-restart* doesn't like to be a symbol. So here's the simple change that make 'q' work in my slime. === diff -rN -u old-stefil/stefil.lisp new-stefil/stefil.lisp --- old-stefil/stefil.lisp 2009-07-15 19:33:55.000000000 +0900 +++ new-stefil/stefil.lisp 2009-07-15 19:33:55.000000000 +0900 @@ -328,7 +328,7 @@ (return-from restart-wrapper)) :report-function (lambda (stream) (format stream "~@<Abort the entire test session~@:>")))) - (bind ((swank::*sldb-quit-restart* 'abort-testing)) + (bind ((swank::*sldb-quit-restart* (find-restart 'abort-testing))) ,@body)))) (defun test-was-run-p (test) === Cheers, -- 黄　澗石 (Jianshi Huang)

2 1

None
by None 19 Mar '09

19 Mar '09

1 0

[stefil-devel] Special Swank version
by Dan Weinreb 18 Mar '09

18 Mar '09

Hi. I am trying to compile stefil, but I am having problems with swank-integration.lisp, although they are different problems than Willem mentions, probably because the ITA fork of Slime was done earlier or something. The problems I'm having are: It's calling all-slots-for-inspector with two arguments, the second being an inspector object, but our version only takes one argument. Our version does not have swank::*inspector-dwim-lookup-hooks*. Probably what's the best for me is to just get rid of the swank integration, since all I'm trying to do is to run the babel test suite. But I'd appreciate any guidance. Thanks. -- Dan

1 0

[stefil-devel] Swank integration fixes
by Willem Broekema 29 Jan '09

29 Jan '09

Stefil might be the test framework I'm looking for: powered by CLOS and integrating with Slime. Thanks for sharing! The swank integration is a bit outdated though: function inspect-for-emacs has been renamed into emacs-inspect, and its second argument, inspector, was dropped. I've attached a patch that fixes this (and probably breaks things in your custom slime branch). Also there seems no reason for inspector-result to be a macro, so I've made that a function. Furthermore (when (boundp 'swank::*inspector-dwim-lookup-hooks*) ..) should maybe be under #+slime-dwim-branch, but I did not change that yet. - Willem

2 1

Fwd: [stefil-devel] First impressions after porting a small test suite from RT to Stefil
by Attila Lendvai 14 Jul '08

14 Jul '08

> Here are a few suggestions for Stefil. If you think they're > worthwhile, I'll prepare proper patches. However, I suspect there > might be better, more idiomatic solutions for some of these problems > within the existing framework that I'm unaware of. > > ;; example: (returns (string-size-in-octets "abc" :encoding :ascii) 3 3) > (defmacro returns (form &rest values) > "Asserts, through EQUALP, that FORM returns VALUES." > `(is (equalp (multiple-value-list ,form) (list ,@values)))) although we've never needed it, this looks generally useful. > (defun fail (control-string &rest arguments) > (stefil::record-failure 'stefil::failed-assertion > :format-control control-string > :format-arguments arguments)) > > (defun expected (expected &key got) > (fail "expected ~A, got ~A instead" expected got)) i'm not sure about these. they look useful, but i'm a bit reluctant in growing the api too much. but... > Here's an example of how I use EXPECTED/FAIL: > > (deftest dec.ascii.2 () > (handler-case > (octets-to-string (ub8v 97 128 99) :encoding :ascii :errorp t) > (character-decoding-error (c) > (is (equalp #(128) (character-decoding-error-octets c))) > (is (eql 1 (character-coding-error-position c))) > (is (eq :ascii (character-coding-error-encoding c)))) > (:no-error (result) > (expected 'character-decoding-error :got result)))) OTOH, this looks like a good reason for them and it would be hard to do this using IS. > Another idea would be to use SIGNALS: > > (let ((c (signals (octets-to-string ...)))) > ;; test C > ) > > However, it seems to me that this would introduce bogus failures > and/or errors when SIGNALS returns NIL that would make debugging more > difficult. Any suggestions? (let ((c (signals (octets-to-string ...)))) (when c ;; test c )) which doesn't look too good. > Since babel-tests was using RT, it had lots of small tests like this: > (deftest foo form retval1 retval2 ...) so I found myself doing a lot > of (deftest foo () (is (equalp form retval1))) and worse for multiple > return values. Before writing the RETURNS macro I wrote a DEFSTEST > macro that works like RT's: > > (defmacro defstest (name form &body return-values) > "Similar to RT's DEFTEST." > `(deftest ,name () > (returns ,form ,@(mapcar (lambda (x) `',x) return-values)))) > > I like it because I'm used to RT and it made porting most of these > small tests a simple matter of replacing DEFTEST with DEFSTEST but I'm > not sure how useful it'd be in general. i think it's trivial enough to let the users do it for themselves. we have several different deftest variants in the various libs anyway. > There a few itches I'd like to scratch before porting other test > suites I maintain. Here's my TODO list, let me know if you have any > objections or better alternatives to these features: > > * make FUNCALL-TEST-WITH-FEEDBACK-MESSAGE print a list of failed > tests (perhaps along with descriptions of the failed assertions). This > could be useful for bug reports, buildbots, and other non-interactive > use cases. sounds good! the original reason for that function was that asdf does not return anything from the operations, so you can't communicate back the results normally when running an 'asdf:test-op. > * implement a functional interface for marking expected failures. > E.g.: #+lispworks (expected-failure > 'some-test-lispworks-does-not-like). i think this would be non-trivial (iow, fragile) to implement in the current setup and as speed does not matter here, maybe i'd simply add a (defmacro with-expected-failures* (expression &body body) "Any failure inside the dynamic extent of this block is registered as an expected failure when the expression evaluates to T." `(bind ((*failures-and-errors-are-expected* (if ,expression #t *failures-and-errors-are-expected*))) ,@body)) (with-expected-failures* (featurep :lispworks) ...) > * implement a way of running tests through EVAL, instead of > compiling. We use this in cffi-tests to test whether removing > compiler-macros introduces bugs and stuff like that. i'm open for this. > * minor thing: export STEFIL::ROOT-SUITE so that one can write > (deftest (foo :in root-suite)). done. > Finally, reducing the dependencies to external libraries would help > with lobbying for porting cffi-tests (and others) to Stefil. Would > that be in any way acceptable for you guys? i got rid of :defclass-star and i'm open for getting rid of :iterate (although i always regret that later... :) but alexandria and bind are pretty much by-default dependencies for us nowadays. > Thanks for Stefil and sorry for the long email. thanks for being the first serious external user with actual feedback! :) -- attila

1 0

[stefil-devel] First impressions after porting a small test suite from RT to Stefil
by Luís Oliveira 22 Jun '08

22 Jun '08

Hello, I've ported Babel's small test suite from RT to Stefil and consequently I have some fixes to contribute, some questions and some suggestions. I've pushed the small, trivial fixes to <http://common-lisp.net/~loliveira/darcs/stefil/>. I suppose having *test-progress-print-right-margin* default to 80 might be controversial with you guys. I'd argue that that's the default width for a lot of applications (xterm, emacs, etc) but the truth is that I'm an 80-column freak, really. Feel free to ignore the patches you disagree with. Here are a few suggestions for Stefil. If you think they're worthwhile, I'll prepare proper patches. However, I suspect there might be better, more idiomatic solutions for some of these problems within the existing framework that I'm unaware of. ;; example: (returns (string-size-in-octets "abc" :encoding :ascii) 3 3) (defmacro returns (form &rest values) "Asserts, through EQUALP, that FORM returns VALUES." `(is (equalp (multiple-value-list ,form) (list ,@values)))) (defun fail (control-string &rest arguments) (stefil::record-failure 'stefil::failed-assertion :format-control control-string :format-arguments arguments)) (defun expected (expected &key got) (fail "expected ~A, got ~A instead" expected got)) Here's an example of how I use EXPECTED/FAIL: (deftest dec.ascii.2 () (handler-case (octets-to-string (ub8v 97 128 99) :encoding :ascii :errorp t) (character-decoding-error (c) (is (equalp #(128) (character-decoding-error-octets c))) (is (eql 1 (character-coding-error-position c))) (is (eq :ascii (character-coding-error-encoding c)))) (:no-error (result) (expected 'character-decoding-error :got result)))) Another idea would be to use SIGNALS: (let ((c (signals (octets-to-string ...)))) ;; test C ) However, it seems to me that this would introduce bogus failures and/or errors when SIGNALS returns NIL that would make debugging more difficult. Any suggestions? Since babel-tests was using RT, it had lots of small tests like this: (deftest foo form retval1 retval2 ...) so I found myself doing a lot of (deftest foo () (is (equalp form retval1))) and worse for multiple return values. Before writing the RETURNS macro I wrote a DEFSTEST macro that works like RT's: (defmacro defstest (name form &body return-values) "Similar to RT's DEFTEST." `(deftest ,name () (returns ,form ,@(mapcar (lambda (x) `',x) return-values)))) I like it because I'm used to RT and it made porting most of these small tests a simple matter of replacing DEFTEST with DEFSTEST but I'm not sure how useful it'd be in general. There a few itches I'd like to scratch before porting other test suites I maintain. Here's my TODO list, let me know if you have any objections or better alternatives to these features: * make FUNCALL-TEST-WITH-FEEDBACK-MESSAGE print a list of failed tests (perhaps along with descriptions of the failed assertions). This could be useful for bug reports, buildbots, and other non-interactive use cases. * implement a functional interface for marking expected failures. E.g.: #+lispworks (expected-failure 'some-test-lispworks-does-not-like). * implement a way of running tests through EVAL, instead of compiling. We use this in cffi-tests to test whether removing compiler-macros introduces bugs and stuff like that. * minor thing: export STEFIL::ROOT-SUITE so that one can write (deftest (foo :in root-suite)). Finally, reducing the dependencies to external libraries would help with lobbying for porting cffi-tests (and others) to Stefil. Would that be in any way acceptable for you guys? Thanks for Stefil and sorry for the long email. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0