jphmrst / cl-nst Goto Github PK

You can't, for example, look to see that slots of an error are filled with the 
right values.

The underlying problem is that, since condition objects aren't ''returned'', 
but caught, you can't pass the condition object to sub-criteria.

If, for example, we were to extend the `:err` check to be of the form:

`(:err [:type` ''type''`] [:criterion `''crit''`])`

and pass the condition object to the criterion expression, ''crit'', it would 
solve the problem.

  (defun find-class-or-name (class-name) (or (find-class class-name nil) class-name))

I'm running version 4.0.1 of NST in the 13.5.1 ECL compiler.  I've submitted a 
compiler bug.  It has an issue where:  (UNLESS (FBOUNDP 'FOO) (DEFGENERIC FOO 
() (:METHOD () :FOO))) defines the generic in a different pass than it compiles 
the methods and so no methods get defined.  This construct is used in 
core/commands.lisp for #'PREP-ARG-NAMES-HELP.

Looking at the NST code, I can't see why this was wrapped up this way.  I got 
rid of the FBOUNDP in my local copy and HELP still seems to work and commands 
and all of the nst-simple tests still pass on CCL and SBCL (and 95 of 97 of 
them pass on ECL -- I'll look into the two failing ones soon).

Not sure how feasible this is, or how brittle & Lisp-specific it would be.

Integrate with SLIME

(RPG) When building nst-doc, we see a flood of warnings from the quickref build.

(JM) Would probably go away if ripping out DefDoc.

There is a transient error cropping up recently the causes overflow in 
operations on randomly-generated floating-point numbers. This error probably 
isn't new, but something in a recent Allegro update made it come up much more 
frequently.

Test `sample-2` (both interpreted and compiled) is temporarily disabled. 
Probably, the solution is to add constraints on the magnitude of that test's 
number.

In groups/tests/ASDF

Extend the NST meta tests to more closely check warnings emitted by NST.  In 
particular:
 * Verify unused variable/bad declaration warnings from macro-constructed scopes including:
    * The `:where` form of `:sample` criteria.

Unhandled SB-INT:SIMPLE-FILE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {1000A20083}>: Failed to find the TRUENAME of /home/quicklisp/quicklisp-controller/dist/build-cache/cl-nst/f4bbdd8059d1cda748cb0beed95ba66620587e5a/cl-nst-20210807-git/test/asdf/packages.lisp: No such file or directory

From an email from Allegro:

  We extend the Ansi CL notion of the "function name" (which includes all symbols and also (setf <symbol>)) and we provide an interface for user-defined function specs.  Names of methods, labels and flets, and internal functions are all implemented as function specs, as well as some others.  Read about these here:

    http://www.franz.com/support/documentation/8.1/doc/implementation.htm#function-specs-1

  and here

    http://www.franz.com/support/documentation/8.1/doc/operators/excl/def-function-spec-handler.htm

  Note that the location of each function can be of your choosing,  depending on what the name is supposed to do.  If there is a natural place to put the function objects (for example, an flet will always show up as a function-constant of its parent function) then the fboundp operation should look there for the appropriate function. Otherwise, however you choose to represent the mapping of function spec to function object is fine perhaps a single hash-table for all fspecs of the same kind.  For constistency, though, the name of the function object (its "symdef" field, and yes, it is a misnomer) should match the function spec.  You can create the function with the appropriate name by using the named-function macro:

  http://www.franz.com/support/documentation/8.1/doc/operators/excl/named-function.htm

  but only after you've created an appropriate function-spec handler for the class of names you want to deal with.

  Once you get a consistent function-spec defined, all operators that normally work on function names (i.e. function specs) will work on yours, including source-file-recording.

The problem with the `:method` implementation on CCL comes down to this:

On any of Allegro/SBCL/Clozure, we can load `:nst-meta-tests` and get the 
"right" result for:
{{{
  (for-clses (make-instance 'top-cls))
}}}
It returns an NST error report, but that's OK at the top-level --- the
point is that there's a method there.

On Allegro and SBCL, we get the result we'd expect for the following call:
{{{
  (closer-mop:compute-applicable-methods-using-classes
      (symbol-function 'for-clses)
      (list (find-class 'top-cls)))
}}}
But on CCL, this gives an error:
{{{
> Error: There is no applicable method for the generic function:
>          #<STANDARD-GENERIC-FUNCTION 
CLOSER-MOP:COMPUTE-APPLICABLE-METHODS-USING-CLASSES #x14BB5D06>
>        when called with arguments:
>          (#<STANDARD-GENERIC-FUNCTION FOR-CLSES #x14FF10EE> (#<STANDARD-CLASS 
TOP-CLS>))
> While executing: #<CCL::STANDARD-KERNEL-METHOD NO-APPLICABLE-METHOD (T)>, in 
process listener(1).
}}}
So either `closer-mop:compute-applicable-methods-using-classes` or 
`compute-applicable-methods-using-classes` does not work as I'm expecting, or 
there's a problem with `closer-mop`'s implementation of it.

----

In fact, replacing the call to 
closer-mop:compute-applicable-methods-using-classes with the unprefixed 
compute-applicable-methods-using-classes for Clozure does avoid the error - 
changeset:803. And it looks offhand like it's doing the right thing:

  (defgeneric f (x))
  (defmethod f ((x symbol)) 1)
  (defmethod f ((x string)) 2)
  (compute-applicable-methods-using-classes (symbol-function 'f)
                                            (list (find-class 'symbol)))

----

THis is robably no longer an issue.

(Patrick) This test:
   (:ALL (:EQUAL 2) (:PREDICATE EVENP))

produces 2 error messages when given the value:  5.

This test:
  (:EACH (:PREDICATE EVENP))

produces only 1 error message when given the value: (list 5 5 5 5).

I wish :EACH listed reports for each failing element.... maybe up to some 
dynamic-variable limit (first 50... or something by default).

Long overdue

(RPG) I mistakenly used `:every` instead of `:all` as my compound criterion, 
and got this error:
{{{
Running test CHECK-LOOP-PLAN (group LOOP-ACCEL-TESTS)
 - Executing test CHECK-LOOP-PLAN
Check CHECK-LOOP-PLAN (group LOOP-ACCEL-TESTS) raised an error:
 - No primary method for the generic function #<STANDARD-GENERIC-FUNCTION SIFT.NST::APPLY-CRITERION> given arguments
   (NIL).at top level
   nil values
   at NIL
TOTAL: 0 of 1 passed (0 failed, 1 error, 0 warnings)
}}}
This seems unnecessarily cryptic.

As an aside, `:every` would probably be a better name than `:all` in the CL 
context.  Possibly make the former a synonym for the latter?

From the old documentation:

  This check assumes that the next item is a list, whose contents are
expanded into the methods-and-forms. This check is especially useful with the 
`def-test-criterion` command below.
{{{
Syntax: (:with criterion)
Example: The following two def-tests are equivalent.
  (def-test seq1
      (:seq (:predicate symbolp) (:eql 1) (:symbol d))
      '(a 1 d))
  (def-test with-seq1
      (:with (:seq (:predicate symbolp) (:eql 1) (:symbol d)))
      '(a 1 d))
}}}

;;; Test the whether Fixture names are bound before the :each-setup an
;;; :setup clause of def-test def-test-group
(in-package :cl-user)
(eval-when (:compile-toplevel :load-toplevel :execute)
  (asdf:load-system :alexandria)
  (asdf:load-system :nst))
(defpackage min-test/nst
  (:use :cl :nst))
(in-package :min-test/nst)

(nst:def-fixtures int-lists-fixture
    (:documentation
     "Lisp lists comprised solely of integers of varying sizes")
  (bigint-int-list (list 12348504938 1 10 -4))
  (empty-int-list nil)
  (singleton-int-list (list 101))
  (mixed-sign-int-list (list 1 1 2 -10 -10 2 3 1 10 11 -10 -1000)))
(nst:def-fixtures string-lists-fixture
    (:documentation
     "Lisp lists comprised solely of strings")
  (empty-string-list nil)
  (star-string-list (list "jfdls" "kdf44'" "*sjkf"))
  (unicode-string-list (list "üßöÖ" "aaa" "123" "ABC" "ÖË")))
(nst:def-fixtures sort-input-params-fixture
    (:documentation "Many tests will be require a seq to be sorted and
    test predicate  to be used for sorting")
  (seq (list 1 2 3))
  (test #'<))


(nst:def-test-group
    dummy
    (sort-input-params-fixture int-lists-fixture)
  (:documentation
   "Tests whose sole purpose is to test out unfamiliar NST library
    feature.")
  (:setup
   (princ bigint-int-list)
   (princ seq)
   (princ test))
  (nst:def-test (dummy-test)
      (:forms-equal) (cl:sort seq test) (sort (copy-seq seq) test)))


(nst:def-test-group
    dummy2
    (sort-input-params-fixture int-lists-fixture)
  (:documentation
   "Tests whose sole purpose is to test out unfamiliar NST library
    feature.")
  (:each-setup
   (princ bigint-int-list)
   (princ seq)
   (princ test))
  (nst:def-test (dummy-test)
      (:forms-equal) (cl:sort seq test) (sort (copy-seq seq) test)))
(nst:def-test-group
    dummy3
    (sort-input-params-fixture int-lists-fixture)
  (:documentation
   "Tests whose sole purpose is to test out unfamiliar NST library
    feature.")
  (nst:def-test (dummy-test
                 :setup (setf seq bigint-int-list test #'>))
      (:forms-equal) (cl:sort seq test) (sort (copy-seq seq) test)))

;Compiler warnings for "/Users/mcheema/src/lisp/sort/minexample.lisp" :
;   In an anonymous lambda form inside an anonymous lambda form at position 1314: Undeclared free variable TEST
;Compiler warnings for "/Users/mcheema/src/lisp/sort/minexample.lisp" :
;   In an anonymous lambda form inside an anonymous lambda form at position 1299: Undeclared free variable SEQ
;Compiler warnings for "/Users/mcheema/src/lisp/sort/minexample.lisp" :
;   In an anonymous lambda form inside an anonymous lambda form at position 1272: Undeclared free variable BIGINT-INT-LIST
;Compiler warnings for "/Users/mcheema/src/lisp/sort/minexample.lisp" :
;   In an anonymous lambda form inside an anonymous lambda form at position 1669: Undeclared free variable TEST
;Compiler warnings for "/Users/mcheema/src/lisp/sort/minexample.lisp" :
;   In an anonymous lambda form inside an anonymous lambda form at position 1654: Undeclared free variable SEQ
;Compiler warnings for "/Users/mcheema/src/lisp/sort/minexample.lisp" :
;   In an anonymous lambda form inside an anonymous lambda form at position 1634: Undeclared free variable BIGINT-INT-LIST
;Compiler warnings for "/Users/mcheema/src/lisp/sort/minexample.lisp" :
;   In an anonymous lambda form inside an anonymous lambda form at position 2016: Undeclared free variable TEST
;Compiler warnings for "/Users/mcheema/src/lisp/sort/minexample.lisp" :
;   In an anonymous lambda form inside an anonymous lambda form at position 2016: Undeclared free variable SEQ
;Compiler warnings for "/Users/mcheema/src/lisp/sort/minexample.lisp" :
;   In an anonymous lambda form inside an anonymous lambda form at position 2016: Undeclared free variable BIGINT-INT-LIST

Interesting experiment; time to be rid of it.

For tests known to fail which we hope one day will pass.

Could be integrated with issue tracking.