perlunit-devel — PerlUnit development mailing list

Re: [Perlunit-devel] PDC_REFACTOR merged back

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> > I use PCL-CVS under emacs (highly recommended), which amongst other
> > things makes it trivial to keep an eye out for files which should be
> > checked in but aren't. However for our peace of mind I've just done
> > a fresh checkout and it's all good.
> 
> I really must learn PCL-CVS properly. I use it but in a desultory
> fashion. 

I recently submitted a patch against emacs 21.1 to the maintainer,
which makes it quite a lot nicer (IMHO ;-)  A copy follows below, in
case you're interested.  Here is a breakdown of what it does:

  - Adds a custom variable `cvs-buffer-switch-list' controlling
    whether or not to switch to the new buffer created by a
    diff/status/log operation.

  - Adds bindings for C-up and C-down to move the point between
    directory fileinfos.

  - Adds a binding for M-t to move the point to the top directory
    fileinfo (i.e., the first node after the header).

  - Adds a binding for `.' to move to the containing (i.e. parent)
    directory.  If `.' is hit on the top-level directory, opens a new
    buffer for the parent directory.

  - Adds a binding for `v' to visit an arbitrary directory.  Defaults
    to the directory under the point.

  - Fixes the binding for RET to cvs-mode-find-file.

  - Allows the user to control whether "New directory `foo' -- ignored"
    messages appear or not, via cvs-parse-ignored-messages.  (The
    default is to display them, as before.)

And la piece de resistance ... ;-)

  - Adds the option of caching fileinfos on a per-buffer basis, for
    unbelievably quick start-up via cvs-quickdir on even huge CVS
    trees.

Index: pcvs-defs.el
===================================================================
RCS file: /share/cvsroot/adams/pcl-cvs/pcvs-defs.el,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 pcvs-defs.el
--- pcvs-defs.el	2001/10/22 16:11:28	1.1.1.3
+++ pcvs-defs.el	2001/10/24 16:57:16
@@ -229,6 +229,14 @@
 			     (function-item cvs-status-trees)
 			     function)))))
 
+(defcustom cvs-buffer-switch-list nil
+  "*For each operation, decides whether or not to switch to the
+new buffer created when the operation is performed."
+  :group 'pcl-cvs
+  :type '(set (const "diff")
+	      (const "status")
+	      (const "log")))
+
 (defvar cvs-buffer-name '(expand-file-name "*cvs*" dir) ;; "*cvs*"
   "Name of the cvs buffer.
 This expression will be evaluated in an environment where DIR is set to
@@ -253,6 +261,22 @@
 (defvar cvs-mode-hook nil
   "Run after `cvs-mode' was setup.")
 
+(defcustom cvs-use-fileinfo-caches nil
+  "Non-nil means cache a buffer's fileinfos when it's killed, so that
+`cvs-quickdir' can retrieve them from the cache rather than from CVS/Entries
+when populating a new buffer.
+
+If you enable this, it is recommended that you add the value of
+`cvs-cache-filename' to your global .cvsignore file."
+  :group 'pcl-cvs
+  :type '(boolean))
+
+(defcustom cvs-cache-filename ".pcl-cvs-cache"
+  "The name for fileinfo cache files."
+  :group 'pcl-cvs
+  :type '(file))
+
+
 
 ;;;;
 ;;;; Internal variables, used in the process buffer.
@@ -339,6 +363,8 @@
     (" " .	cvs-mode-next-line)
     ("n" .	cvs-mode-next-line)
     ("p" .	cvs-mode-previous-line)
+    ([C-down] . cvs-mode-next-dir)
+    ([C-up]   . cvs-mode-previous-dir)
     ;; M- keys are usually those that operate on modules
     ;;("\M-C".	cvs-mode-rcs2log) ; i.e. "Create a ChangeLog"
     ;;("\M-t".	cvs-rtag)
@@ -348,6 +374,7 @@
     ("g" .	cvs-mode-revert-buffer)
     ("\M-u".	cvs-update)
     ("\M-s".	cvs-status)
+    ("\M-t".    cvs-mode-top-dir)
     ;; diff commands
     ("=" .	cvs-mode-diff)
     ("d" .	cvs-mode-diff-map)
@@ -365,19 +392,22 @@
     ("c" .	cvs-mode-commit)
     ("e" .	cvs-mode-examine)
     ("f" .	cvs-mode-find-file)
-    ([RET] .	cvs-mode-find-file)
+    ("\C-m" .	cvs-mode-find-file)
     ("i" .	cvs-mode-ignore)
     ("l" .	cvs-mode-log)
     ("o" .	cvs-mode-find-file-other-window)
     ("r" .	cvs-mode-remove)
     ("s" .	cvs-mode-status)
     ("t" .	cvs-mode-tag)
+    ("v" .      cvs-mode-examine-directory)
+    ("^" .      cvs-mode-examine-parent-directory)
+    ("." .      cvs-mode-up-level)
     ;;("v" .	cvs-mode-diff-vendor)
     ("x" .	cvs-mode-remove-handled)
     ;; cvstree bindings
     ("+" .	cvs-mode-tree)
     ;; mouse bindings
-    ([mouse-2] . cvs-mode-find-file)
+    ([(mouse-2)] . cvs-mode-find-file)
     ([(down-mouse-3)] . cvs-menu)
     ;; dired-like bindings
     ("\C-o" .   cvs-mode-display-file)
Index: pcvs-parse.el
===================================================================
RCS file: /share/cvsroot/adams/pcl-cvs/pcvs-parse.el,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -u -r1.1.1.2 -r1.2
--- pcvs-parse.el	2001/10/22 16:11:28	1.1.1.2
+++ pcvs-parse.el	2001/10/03 15:45:47	1.2
@@ -4,7 +4,7 @@
 
 ;; Author: Stefan Monnier <mo...@cs...>
 ;; Keywords: pcl-cvs
-;; Revision: $Id: pcvs-parse.el,v 1.10 2001/09/24 16:39:23 monnier Exp $
+;; Revision: $Id: pcvs-parse.el,v 1.1 2001/10/03 13:35:56 adams Exp $
 
 ;; This file is part of GNU Emacs.
 
@@ -260,11 +260,6 @@
 	(cvs-match "\\(Examining\\|Updating\\) \\(.*\\)$" (dir 2))
 	(let ((dir (if (string= "." dir) "" (file-name-as-directory dir))))
 	  (cvs-parsed-fileinfo 'DIRCHANGE "." dir)))
-
-       ;; [-n update] A new (or pruned) directory appeared but isn't traversed
-       (and
-	(cvs-match "New directory `\\(.*\\)' -- ignored$" (dir 1))
-	(cvs-parsed-fileinfo 'MESSAGE " " (file-name-as-directory dir)))
 
        ;; File removed, since it is removed (by third party) in repository.
        (and
Index: pcvs.el
===================================================================
RCS file: /share/cvsroot/adams/pcl-cvs/pcvs.el,v
retrieving revision 1.1.1.2
retrieving revision 1.12
diff -u -r1.1.1.2 -r1.12
--- pcvs.el	2001/10/22 16:11:28	1.1.1.2
+++ pcvs.el	2001/10/24 16:58:07	1.12
@@ -873,6 +873,24 @@
   (interactive)
   (cvs-examine default-directory t))
 
+(defun cvs-mode-examine-directory (dir)
+  "Run `cvs-examine' on a specified directory with the default flags."
+  (interactive (list (cvs-query-directory-prompt "CVS Examine (directory): ")))
+  (cvs-examine dir t))
+  
+(defun cvs-mode-examine-parent-directory ()
+  "Run `cvs-examine' on a specified directory with the default flags."
+  (interactive)
+  (cvs-examine ".." t))
+  
+(defun cvs-query-directory-prompt (msg)
+  (let* ((cur-fi (ewoc-data (ewoc-locate cvs-cookies)))
+         (default-dir (if (cvs-fileinfo-p cur-fi)
+                          (expand-file-name (cvs-fileinfo->dir cur-fi)
+                                            default-directory)
+                        default-directory)))
+    (read-file-name msg default-dir default-dir nil)))
+  
 (defun cvs-query-directory (msg)
   ;; last-command-char = ?\r hints that the command was run via M-x
   (if (and (cvs-buffer-p)
@@ -881,6 +899,17 @@
       default-directory
     (read-file-name msg nil default-directory nil)))
 
+(defun cvs-cache-buffer-fileinfos ()
+  "Cache the buffer of fileinfos representing a directory's CVS status
+into a file whose name is defined by `cvs-cache-filename'."
+  (when (eq major-mode 'cvs-mode)
+    (let ((cookies cvs-cookies))
+      (with-temp-file (expand-file-name cvs-cache-filename)
+        (prin1 (ewoc-map 'identity cookies) (current-buffer))))))
+
+(add-hook 'kill-buffer-hook 'cvs-cache-buffer-fileinfos)
+(add-hook 'kill-emacs-hook  'cvs-cache-buffer-fileinfos)
+
 ;;;###autoload
 (defun cvs-quickdir (dir &optional flags noshow)
   "Open a *cvs* buffer on DIR without running cvs.
@@ -902,15 +931,28 @@
     (unless (file-directory-p (expand-file-name "CVS" dir))
       (error "%s does not contain CVS controlled files" dir))
     (set-buffer cvsbuf)
-    (dolist (fi (cvs-fileinfo-from-entries ""))
+    (dolist (fi (or (cvs-fileinfo-from-cache "")
+                    (cvs-fileinfo-from-entries "")))
       (setq last (cvs-addto-collection cvs-cookies fi last)))
     (cvs-cleanup-collection cvs-cookies
-			    (eq cvs-auto-remove-handled t)
-			    cvs-auto-remove-directories
-			    nil)
+                            (eq cvs-auto-remove-handled t)
+                            cvs-auto-remove-directories
+                            nil)
     (if noshow cvsbuf
       (let ((pop-up-windows nil)) (pop-to-buffer cvsbuf)))))
 
+(defun cvs-fileinfo-from-cache (dir)
+  "If caching is enabled and a cache file exists for the given
+directory DIR, reads fileinfos from it, and returns them.  Otherwise
+returns nil."
+  (and cvs-use-fileinfo-caches
+       (let ((cache (expand-file-name cvs-cache-filename dir)))
+         (and (file-readable-p cache)
+              (with-temp-buffer
+                (insert-file-contents cache)
+                (message (format "Reading fileinfos from %s" cache))
+                (read (buffer-substring 1 (point-max))))))))
+
 ;;;###autoload
 (defun cvs-examine (directory flags &optional noshow)
   "Run a `cvs -n update' in the specified DIRECTORY.
@@ -1093,6 +1135,64 @@
   (interactive "p")
   (ewoc-goto-next cvs-cookies arg))
 
+(defun cvs-mode-previous-dir ()
+  "Go to the previous directory.  Returns the destination node."
+  (interactive)
+  (catch 'end
+    (do* ((cur-node (ewoc-goto-prev cvs-cookies 1))
+          (cur-fi (ewoc-data cur-node)))
+        ((and (cvs-fileinfo-p cur-fi)
+              (eq (cvs-fileinfo->type cur-fi) 'DIRCHANGE))
+         cur-node)
+      (setq cur-node (ewoc-goto-prev cvs-cookies 1))
+      (setq cur-fi (ewoc-data cur-node))
+      (or (cvs-fileinfo-p cur-fi) (throw 'end cur-node)))))
+
+(defun cvs-mode-next-dir ()
+  "Go to the next directory.  Returns the destination node."
+  (interactive)
+  (catch 'end
+    ;; ewoc considers being in the header equivalent to being in
+    ;; the first node (doh), so we have to compare the point's
+    ;; position with the beginning of the first node
+    (let ((first-node (ewoc-nth cvs-cookies 0)))
+      (cond ((< (point) (marker-position (ewoc-location first-node)))
+             (ewoc-goto-node cvs-cookies first-node))
+            (t
+             (do* ((cur-node (ewoc-goto-next cvs-cookies 1))
+                   (cur-fi (ewoc-data cur-node)))
+                 ((and (cvs-fileinfo-p cur-fi)
+                       (eq (cvs-fileinfo->type cur-fi) 'DIRCHANGE))
+                  cur-node)
+               (setq cur-node (ewoc-goto-next cvs-cookies 1))
+               (setq cur-fi (ewoc-data cur-node))
+               (or (cvs-fileinfo-p cur-fi) (throw 'end cur-node))))))))
+
+(defun cvs-mode-up-level ()
+  "Go to the containing directory.  Returns the new node."
+  (interactive)
+  (let* ((orig-node (ewoc-locate cvs-cookies))
+         (orig-fi (ewoc-data (or orig-node (error "Not on a fileinfo"))))
+         (orig-dir (cvs-fileinfo->dir orig-fi)))
+    (if (and (eq (cvs-fileinfo->type orig-fi) 'DIRCHANGE)
+             (equal orig-dir ""))
+        (cvs-mode-examine-parent-directory)
+      (do* ((current-node (cvs-mode-previous-dir))
+            (current-fi (ewoc-data current-node))
+            (current-dir (cvs-fileinfo->dir current-fi)))
+          ((string-match (concat "^" (regexp-quote current-dir)) orig-dir)
+           current-node)
+        (setq current-node (cvs-mode-previous-dir))
+        (setq current-fi (ewoc-data current-node))
+        (setq current-dir (cvs-fileinfo->dir current-fi))))))
+
+(defun cvs-mode-top-dir ()
+  "Go to the top-level directory in the current buffer."
+  (interactive)
+  (goto-char 0)
+  (ewoc-goto-next cvs-cookies 1)
+  (forward-line -1))
+
 ;;;;
 ;;;; Mark handling
 ;;;;
@@ -1661,7 +1761,10 @@
       ;;(set (make-local-variable 'cvs-buffer) cvs-buf)
       (let ((inhibit-read-only t)) (erase-buffer))
       (message "Running cvs %s ..." cmd)
-      (cvs-run-process args fis postproc single-dir))))
+      (cvs-run-process args fis postproc single-dir))
+    (and (member cmd cvs-buffer-switch-list)
+         (let ((w (get-buffer-window buf)))
+           (and w (select-window (get-buffer-window buf)))))))
 
 
 (defun* cvs-mode-do (cmd flags filter
cvs diff: Diffing emacs-lisp
Index: emacs-lisp/ewoc.el
===================================================================
RCS file: /share/cvsroot/adams/pcl-cvs/emacs-lisp/ewoc.el,v
retrieving revision 1.1.1.2
retrieving revision 1.3
diff -u -r1.1.1.2 -r1.3
--- emacs-lisp/ewoc.el	2001/10/22 16:16:23	1.1.1.2
+++ emacs-lisp/ewoc.el	2001/10/24 16:33:45	1.3
@@ -396,14 +396,19 @@
 it returns, if it changes it.
 
 If more than two arguments are given, the remaining
-arguments will be passed to MAP-FUNCTION."
+arguments will be passed to MAP-FUNCTION.
+
+Returns a list of all the results from all the calls to MAP-FUNCTION."
   (ewoc--set-buffer-bind-dll-let* ewoc
       ((footer (ewoc--footer ewoc))
-       (node (ewoc--node-nth dll 1)))
+       (node (ewoc--node-nth dll 1))
+       (result nil))
     (while (not (eq node footer))
-      (if (apply map-function (ewoc--node-data node) args)
-	  (ewoc--refresh-node (ewoc--pretty-printer ewoc) node))
-      (setq node (ewoc--node-next dll node)))))
+      (let ((mapped (apply map-function (ewoc--node-data node) args)))
+        (setq result (append result (list mapped)))
+        (if mapped (ewoc--refresh-node (ewoc--pretty-printer ewoc) node)))
+      (setq node (ewoc--node-next dll node)))
+    result))
 
 (defun ewoc-filter (ewoc predicate &rest args)
   "Remove all elements in EWOC for which PREDICATE returns nil.

Re: [Perlunit-devel] Towards Version 1.0

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> And, dammit, the framework is really useful now and creeping towards
> maturity. I'm thinking of picking the current trunk (with a working
> 'ok')  and tagging it 1_0_RELEASE_CANDIDATE freezing the features,
> hammering on it to make it work with 5.7.2, writing a quick tutorial
> pointing people at Test::Unit::TestCase and getting it up to CPAN as
> 1.0 as soon as we're happy with it. The Roadmap for this, as I see it
> is:
> 
> 1. Rename Test::Unit to Test::Unit::Procedural
> 2. Rename Test::Unit::HarnessUnit and Test::Unit::UnitHarness
>    Not sure what to yet, but I want to get these big API changes out
>    of the way before we bump the version number.
> 3. Working ok
> 4. Working build on 5.7.2
  5. Change suite-building API so that MySuite really ISA TestSuite,
     and gets instantiated via new() rather than the current suite()
     nonsense.  This is a *big* API change, but I'm utterly convinced
     we need to do it.  I think it should be possible to keep
     backwards compatibility, however.
  6. If a testcase fails compilation, you currently get `Suite class
     MyTests::Foo not found', rather than `Failed to load ...'; this
     needs fixing.
  7. Stop `make test' failing when DEBUG is enabled?
  8. Move test libraries out of lib/Test/Unit/tests.
  9. Deal with broken base.pm in older Perls (or we could always be
     nasty and stop supporting < 5.6, best to avoid if we can though).

None of these are big jobs, but I think they should all be done before
1.0 if we want the framework to gain respect and widespread usage;
after all, many people will check out PerlUnit for the first time when
they hear 1.0 being announced, and first impressions count for a lot.

> Nice to have
> 
> 1. Test::Unit::Loader working with whole directories.
> 2. <YOUR SUGGESTIONS HERE>

  2. Refactoring of runner classes to allow storing state in the
     runner.  This paves the way for choosing which tests to skip in a
     given run, which brings me on to ...

  3. Test filtering.  I like your Attribute::Handlers idea a lot, and
     have a very real need for decent filtering right now.
     
  3. Rethink how the tests are split up between the t/*.t.  Currently
     we have t/all_tests.t, which is clearly a misnomer, and we have
     some tests for the assertion code being run from that rather than
     from t/assert.t.

Some of these could be left until after 1.0; however given that I will
certainly be aiming to commit some of them very soon (today, tomorrow
...), it's probably more hassle than it's worth branching off for the
release straight away.

I'll commit all these to doc/TODO now, and then we can twiddle with it
as need be.

Incidentally, we must remember to consult doc/release-checklist before
making a release ...

Re: [Perlunit-devel] Resend: Re commits

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Piers Cawley (pdc...@bo...) wrote:
>> Adam Spiers <ad...@sp...> writes:
>> >> I'll do it after the merge.
>> > 
>> > Cool.  T::U::Assert::ok() is finished now, I think.  Did I already say
>> > that?
>> 
>> Have you written tests for it? And what branch did you do it on?
> 
> Yes, lots of tests (and fixes/refactorings for already existing
> tests).  It's all on HEAD (I did already say *that* ;-)

Yeah, I hadn't seen it by then. 

BTW, the tests are now passing under 5.7.2, but are throwing warnings
when run via make. Still strange...

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] PDC_REFACTOR merged back

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Piers Cawley (pdc...@bo...) wrote:
>> Adam Spiers <ad...@sp...> writes:
>> > Piers Cawley <pdc...@bo...> wrote:
>> >> Seemed to go in smoothly. If you'd all like to do a 'get' of the
>> >> main line into a virgin directory and run the tests (to make
>> >> sure that everything went in okay...) and report back.
>> > 
>> > Works great for me, although I did cvs update -A rather than a
>> > fresh checkout. Since then I've been committing to HEAD rather
>> > than the branch, so you won't have to do any more merging.
>> 
>> Can you do a fresh checkout anyway, just for me. I've been bitten
>> occasionally by having files in my local copy that weren't actually
>> in CVS so things continued to work after 'cvs update -A', but
>> didn't work for some poor schmuck who checked the thing out fresh.
> 
> I use PCL-CVS under emacs (highly recommended), which amongst other
> things makes it trivial to keep an eye out for files which should be
> checked in but aren't. However for our peace of mind I've just done
> a fresh checkout and it's all good.

I really must learn PCL-CVS properly. I use it but in a desultory
fashion. 

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] (no subject)

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Piers Cawley (pdc...@bo...) wrote:
>> Adam Spiers <ad...@sp...> writes:
>> > A nice idea, but surely this wheel has already been invented in some
>> > way?  Why not just do something idiotically simple like sticking the
>> > test libraries in the `t' directory, and then put
>> > 
>> >   use lib 't';
>> > 
>> > in your t/*.t?  (Or better, hack Makefile.PL, or god forbid,
>> > ExtUtils::Makemaker, so that a `make test' includes -It as an option
>> > when running the tests.)
>> 
>> Well, it's sort of dependent on where you run the script from.
>> Actually I'm more inclined to stick the *modules* in t/tlib (I'll
>> explain why it has to be tlib in a minute) and then do 
>> 
>>     use lib 't/tlib', 'tlib';
>> 
>> So that you can run the tests from either the project root or from
>> inside the t directory. It has to be tlib instead of lib to avoid
>> using the files in lib/* rather than blib/*.
> 
> Yep, sounds good.  It doesn't look like there's any hook in MakeMaker
> so we could persuade it to add these to @INC directly, hmph.  Although
> doing it that way would break running the tests directly (isn't that
> deprecated however?)

Dunno about deprecated, it can be damned useful.

> I can do this right now if you want me to.

Go to it.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] (no subject)

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> > A nice idea, but surely this wheel has already been invented in some
> > way?  Why not just do something idiotically simple like sticking the
> > test libraries in the `t' directory, and then put
> > 
> >   use lib 't';
> > 
> > in your t/*.t?  (Or better, hack Makefile.PL, or god forbid,
> > ExtUtils::Makemaker, so that a `make test' includes -It as an option
> > when running the tests.)
> 
> Well, it's sort of dependent on where you run the script from.
> Actually I'm more inclined to stick the *modules* in t/tlib (I'll
> explain why it has to be tlib in a minute) and then do 
> 
>     use lib 't/tlib', 'tlib';
> 
> So that you can run the tests from either the project root or from
> inside the t directory. It has to be tlib instead of lib to avoid
> using the files in lib/* rather than blib/*.

Yep, sounds good.  It doesn't look like there's any hook in MakeMaker
so we could persuade it to add these to @INC directly, hmph.  Although
doing it that way would break running the tests directly (isn't that
deprecated however?)

I can do this right now if you want me to.

Re: [Perlunit-devel] PDC_REFACTOR merged back

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> > Piers Cawley <pdc...@bo...> wrote:
> >> Seemed to go in smoothly. If you'd all like to do a 'get' of the main
> >> line into a virgin directory and run the tests (to make sure that
> >> everything went in okay...) and report back.
> > 
> > Works great for me, although I did cvs update -A rather than a fresh
> > checkout.  Since then I've been committing to HEAD rather than the
> > branch, so you won't have to do any more merging.
> 
> Can you do a fresh checkout anyway, just for me. I've been bitten
> occasionally by having files in my local copy that weren't actually in
> CVS so things continued to work after 'cvs update -A', but didn't work
> for some poor schmuck who checked the thing out fresh.

I use PCL-CVS under emacs (highly recommended), which amongst other
things makes it trivial to keep an eye out for files which should be
checked in but aren't.  However for our peace of mind I've just done a
fresh checkout and it's all good.

Re: [Perlunit-devel] Resend: Re commits

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> >> I'll do it after the merge.
> > 
> > Cool.  T::U::Assert::ok() is finished now, I think.  Did I already say
> > that?
> 
> Have you written tests for it? And what branch did you do it on?

Yes, lots of tests (and fixes/refactorings for already existing
tests).  It's all on HEAD (I did already say *that* ;-)

[Perlunit-devel] Towards Version 1.0

[Piers C. <pdc...@bo...>]

Okay, because we've been moving things around, renaming classes etc
we've reached the point where the current API is more than a little
different from the 'old' API. Which generally means you need to
increment the major version number.

And, dammit, the framework is really useful now and creeping towards
maturity. I'm thinking of picking the current trunk (with a working
'ok')  and tagging it 1_0_RELEASE_CANDIDATE freezing the features,
hammering on it to make it work with 5.7.2, writing a quick tutorial
pointing people at Test::Unit::TestCase and getting it up to CPAN as
1.0 as soon as we're happy with it. The Roadmap for this, as I see it
is:

1. Rename Test::Unit to Test::Unit::Procedural
2. Rename Test::Unit::HarnessUnit and Test::Unit::UnitHarness
   Not sure what to yet, but I want to get these big API changes out
   of the way before we bump the version number.
3. Working ok
4. Working build on 5.7.2

Nice to have

1. Test::Unit::Loader working with whole directories.
2. <YOUR SUGGESTIONS HERE>

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] PDC_REFACTOR merged back

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Piers Cawley <pdc...@bo...> wrote:
>> Seemed to go in smoothly. If you'd all like to do a 'get' of the main
>> line into a virgin directory and run the tests (to make sure that
>> everything went in okay...) and report back.
> 
> Works great for me, although I did cvs update -A rather than a fresh
> checkout.  Since then I've been committing to HEAD rather than the
> branch, so you won't have to do any more merging.

Can you do a fresh checkout anyway, just for me. I've been bitten
occasionally by having files in my local copy that weren't actually in
CVS so things continued to work after 'cvs update -A', but didn't work
for some poor schmuck who checked the thing out fresh.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] Arrgh...

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Piers Cawley (pdc...@bo...) wrote:
>> So, I thought, I'll run the tests using perl 5.7.2, and look what
>> happens.
> 
> [breakage]
> 
>> However, if I try to run the tests by hand, then t/all_tests.t
>> succeeds. Much strangeness methinks, presumably related to the new
>> MakeMaker.
> 
> Eww. To do with T::U::tests::* having an un-capitalised segment
> maybe?
> 
>> Right now this is a show stopper for making a tarball and I'm at
>> work and don't have time to work on it for another 8 or so hours.
>> If the fixing elves can see their way clear to sorting this out we
>> should be able to do a CPAN release either at the end of today or
>> tomorrow (need to work out how to get CPAN to see me as the
>> maintainer of PerlUnit...)
> 
> I don't have 5.7.2 anywhere, I'm afraid. Maybe the test library
> renaming we've been talking about will sort this out.

It's relatively easy to pull down. perldoc perlhack has the
instructions. And even now it's nicer than 5.6.1 :)

I'll try and have a look at this tonight.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] Resend: Re commits

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Piers Cawley (pdc...@bo...) wrote:
>> Ah, I like lining up the beginnings of the variables,
> 
> Yeah, so do I.
> 
>>     my $self = shift;
>>     my ($arg1, $arg2, @foo) = @_;
> 
> ... is my current favourite.
> 
>> >> but I think there might be a few more modules to move around, I'm
>> >> really not keen on the Test::Unit::TestFoo style, and, from
>> >> discussions elsewhere, I think it'd be a good idea to move
>> >> Test::Unit itself into Test::Unit::Procedural. There seem to be a
>> >> fair few folks at the moment who think that Test::Unit is the main
>> >> interface to PerlUnit.
>> > 
>> > Good idea.
>> 
>> I'll do it after the merge.
> 
> Cool.  T::U::Assert::ok() is finished now, I think.  Did I already say
> that?

Have you written tests for it? And what branch did you do it on? (If
it's not on the HEAD branch, can I leave you to the merge, I'm tied up
for today.)

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] (no subject)

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Piers Cawley (pdc...@bo...) wrote:
>> Adam Spiers <ad...@sp...> writes:
>> 
>> > Is lib/Test/Unit/tests/TestAssertionCodeRef.pm dead?  It doesn't
>> > currently seem to be used.  We also seem to be missing tests for
>> > Assertion::Regexp and Assertion::CodeRef; I'll add those to
>> > tests/AssertTest.pm along with new tests for the finished ok()
>> > wrapper.
>> 
>> I think I wrote it to help with the development and didn't get 'round
>> to adding it to AllTests.
> 
> Ah.  Are you going to resurrect it?  I didn't understand
> test_case_to_string at all, nor the
> 
>   $self->assert(qr/bar/, 'foo');
> 
> bit :-)

Well, it's gonna fail isn't it. I'll take a look at the code when I
get some time. Must write rigged demo for the refactoring engine first
or I'm going to look very silly at the London.pm tech meet...

>> BTW, I've been thinking about the naming and placing of test packages.
>> 
>> 1. By placing the tests in the ./lib tree they get installed along
>>    with the rest of the testsuite. I'm not sure that this is a good
>>    thing.
> 
> You're right, it's not.
> 
>> 2. I've taken to naming my test classes using the same 'lower case
>>    with underscores' approach as that used for method names etc. This
>>    may not be a desperately good naming strategy, but it does help to
>>    distinguish tests from operational code.
> 
> Sounds reasonable.
> 
>> 3. On preface (the refactoring engine), I've taken to placing tests in
>>    a tlib directory. This has the advantage of not having tests
>>    installed and lets you use shorter names for your test libraries:
>> 
>>    test::assertion_coderefs instead of
>>    Test::Unit::tests::TestAssertionCodeRef
>> 
>>    If we were to write a 'tlib.pm' modelled on blib.pm we could make
>>    working with a test libs directory reasonably trivial for
>>    developers. 
> 
> A nice idea, but surely this wheel has already been invented in some
> way?  Why not just do something idiotically simple like sticking the
> test libraries in the `t' directory, and then put
> 
>   use lib 't';
> 
> in your t/*.t?  (Or better, hack Makefile.PL, or god forbid,
> ExtUtils::Makemaker, so that a `make test' includes -It as an option
> when running the tests.)

Well, it's sort of dependent on where you run the script from.
Actually I'm more inclined to stick the *modules* in t/tlib (I'll
explain why it has to be tlib in a minute) and then do 

    use lib 't/tlib', 'tlib';

So that you can run the tests from either the project root or from
inside the t directory. It has to be tlib instead of lib to avoid
using the files in lib/* rather than blib/*.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

[Perlunit-devel] PDC_REFACTOR merged back

[Adam S. <ad...@sp...>]

Piers Cawley <pdc...@bo...> wrote:
> Seemed to go in smoothly. If you'd all like to do a 'get' of the main
> line into a virgin directory and run the tests (to make sure that
> everything went in okay...) and report back.

Works great for me, although I did cvs update -A rather than a fresh
checkout.  Since then I've been committing to HEAD rather than the
branch, so you won't have to do any more merging.

Re: [Perlunit-devel] Arrgh...

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> So, I thought, I'll run the tests using perl 5.7.2, and look what
> happens.

[breakage]

> However, if I try to run the tests by hand, then t/all_tests.t
> succeeds. Much strangeness methinks, presumably related to the new
> MakeMaker. 

Eww.  To do with T::U::tests::* having an un-capitalised segment
maybe?

> Right now this is a show stopper for making a tarball and I'm at work
> and don't have time to work on it for another 8 or so hours. If the
> fixing elves can see their way clear to sorting this out we should be
> able to do a CPAN release either at the end of today or tomorrow (need
> to work out how to get CPAN to see me as the maintainer of
> PerlUnit...)

I don't have 5.7.2 anywhere, I'm afraid.  Maybe the test library
renaming we've been talking about will sort this out.

Re: [Perlunit-devel] Resend: Re commits

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> Ah, I like lining up the beginnings of the variables,

Yeah, so do I.

>     my $self = shift;
>     my ($arg1, $arg2, @foo) = @_;

... is my current favourite.

> >> but I think there might be a few more modules to move around, I'm
> >> really not keen on the Test::Unit::TestFoo style, and, from
> >> discussions elsewhere, I think it'd be a good idea to move
> >> Test::Unit itself into Test::Unit::Procedural. There seem to be a
> >> fair few folks at the moment who think that Test::Unit is the main
> >> interface to PerlUnit.
> > 
> > Good idea.
> 
> I'll do it after the merge.

Cool.  T::U::Assert::ok() is finished now, I think.  Did I already say
that?

Re: [Perlunit-devel] (no subject)

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> 
> > Is lib/Test/Unit/tests/TestAssertionCodeRef.pm dead?  It doesn't
> > currently seem to be used.  We also seem to be missing tests for
> > Assertion::Regexp and Assertion::CodeRef; I'll add those to
> > tests/AssertTest.pm along with new tests for the finished ok()
> > wrapper.
> 
> I think I wrote it to help with the development and didn't get 'round
> to adding it to AllTests.

Ah.  Are you going to resurrect it?  I didn't understand
test_case_to_string at all, nor the

  $self->assert(qr/bar/, 'foo');

bit :-)

> BTW, I've been thinking about the naming and placing of test packages.
> 
> 1. By placing the tests in the ./lib tree they get installed along
>    with the rest of the testsuite. I'm not sure that this is a good
>    thing.

You're right, it's not.

> 2. I've taken to naming my test classes using the same 'lower case
>    with underscores' approach as that used for method names etc. This
>    may not be a desperately good naming strategy, but it does help to
>    distinguish tests from operational code.

Sounds reasonable.

> 3. On preface (the refactoring engine), I've taken to placing tests in
>    a tlib directory. This has the advantage of not having tests
>    installed and lets you use shorter names for your test libraries:
> 
>    test::assertion_coderefs instead of
>    Test::Unit::tests::TestAssertionCodeRef
> 
>    If we were to write a 'tlib.pm' modelled on blib.pm we could make
>    working with a test libs directory reasonably trivial for
>    developers. 

A nice idea, but surely this wheel has already been invented in some
way?  Why not just do something idiotically simple like sticking the
test libraries in the `t' directory, and then put

  use lib 't';

in your t/*.t?  (Or better, hack Makefile.PL, or god forbid,
ExtUtils::Makemaker, so that a `make test' includes -It as an option
when running the tests.)

[Perlunit-devel] Arrgh...

[Piers C. <pdc...@bo...>]

So, I thought, I'll run the tests using perl 5.7.2, and look what
happens.

PERL_DL_NONLAZY=1 /opt/perl-current/bin/perl -Iblib/arch -Iblib/lib -e 'use Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t
t/all_tests.......Package `Test::Unit::tests::TornDown' not found (did you use the incorrect case?) at blib/lib/Test/Unit/tests/SuiteTest.pm line 9.
Package `Test::Unit::tests::WasRun' not found (did you use the incorrect case?) at blib/lib/Test/Unit/tests/SuiteTest.pm line 10.
Package `Test::Unit::tests::TornDown' not found (did you use the incorrect case?) at blib/lib/Test/Unit/tests/TestTest.pm line 6.
Package `Test::Unit::tests::WasRun' not found (did you use the incorrect case?) at blib/lib/Test/Unit/tests/TestTest.pm line 7.
t/all_tests.......ok                                                         
t/assert..........ok                                                         
t/try_examples....NOK 2Skipping example file 'examples/fail_example.pm', no guru-checked answer
t/try_examples....FAILED tests 4-6                                           
	Failed 3/9 tests, 66.67% okay
Failed Test      Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
t/try_examples.t                9    3  33.33%  4-6
Failed 1/3 test scripts, 66.67% okay. 3/62 subtests failed, 95.16% okay.
make: *** [test_dynamic] Error 29

Not good.

However, if I try to run the tests by hand, then t/all_tests.t
succeeds. Much strangeness methinks, presumably related to the new
MakeMaker. 

Right now this is a show stopper for making a tarball and I'm at work
and don't have time to work on it for another 8 or so hours. If the
fixing elves can see their way clear to sorting this out we should be
able to do a CPAN release either at the end of today or tomorrow (need
to work out how to get CPAN to see me as the maintainer of
PerlUnit...)

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

[Perlunit-devel] (no subject)

>From pdcawley  Mon Nov 12 17:35:05 2001
Received: from pdcawley by despairon.bofh.org.uk with local (Exim 3.33 #1)
	id 163KzB-0004RW-00; Mon, 12 Nov 2001 17:35:05 +0000
To: per...@li...
Subject: PDC_REFACTOR merged back
From: Piers Cawley <pdc...@bo...>
Date: Mon, 12 Nov 2001 17:35:04 +0000
Message-ID: <m24...@bo...>
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (asparagus)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-jf: 19990331, 1:1,2:1,3:1,4:0,ad:1,bo:1,di:1,do:0,he:1,ip:1,us:1
Lines: 11

Seemed to go in smoothly. If you'd all like to do a 'get' of the main
line into a virgin directory and run the tests (to make sure that
everything went in okay...) and report back.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Resend: Re: [Perlunit-devel] issues with sourceforge

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> http://fsfeurope.org/news/article2001-10-20-01.en.html
> 
> I haven't looked at this closely enough to decide whether it should
> affect us, but I thought I should bring it up just in case.

Personally I'm happy to continue using sourceforge for development and
keep a watching brief on the free/non-free issues. However, if
something better comes along...


-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Resend: Re: [Perlunit-devel] the old 'ok' chestnut

[Piers C. <pdc...@bo...>]

"Weaver, Quinn BGI SF" <Qui...@ba...> writes:

>> Adam Spiers ad...@sp... wrote:
>> It's a kind of multiplexing wrapper around assert() and
>> assert_equals(), so the regex matching should work fine too.  I've
>> already committed to Assert.pm if you want to have a look.  It's not
>> finished yet.
> 
> That reminds me:  Test::Unit should explicitly require 5.005; it uses the
> qr// operator and throws references (as opposed to strings) through die.
> Both features were introduced with 5.005.

Good point. Thanks.


-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

[Perlunit-devel] Resend: Re commits

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Piers Cawley (pdc...@bo...) wrote:
>> Adam Spiers <ad...@sp...> writes:
>> > While we're at it, another quick poll:
>> > 
>> >   my $self = shift;
>> >   my $arg = shift;
>> > 
> 
> I find that the lack of space decreases legibility, and also makes it
> look more like a function call than a declaration.  Not much in it
> though :-)

Ah, I like lining up the beginnings of the variables, but I'm not
terrifically attached to it.

>> but I think there might be a few more modules to move around, I'm
>> really not keen on the Test::Unit::TestFoo style, and, from
>> discussions elsewhere, I think it'd be a good idea to move
>> Test::Unit itself into Test::Unit::Procedural. There seem to be a
>> fair few folks at the moment who think that Test::Unit is the main
>> interface to PerlUnit.
> 
> Good idea.

I'll do it after the merge.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

[Perlunit-devel] Mail problems

[Piers C. <pdc...@bo...>]

It seems that some of my outgoing mail has been falling on the floor,
including some messages to here. I'll try and resend.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] (no subject)

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Is lib/Test/Unit/tests/TestAssertionCodeRef.pm dead?  It doesn't
> currently seem to be used.  We also seem to be missing tests for
> Assertion::Regexp and Assertion::CodeRef; I'll add those to
> tests/AssertTest.pm along with new tests for the finished ok()
> wrapper.

I think I wrote it to help with the development and didn't get 'round
to adding it to AllTests.

BTW, I've been thinking about the naming and placing of test packages.

1. By placing the tests in the ./lib tree they get installed along
   with the rest of the testsuite. I'm not sure that this is a good
   thing.

2. I've taken to naming my test classes using the same 'lower case
   with underscores' approach as that used for method names etc. This
   may not be a desperately good naming strategy, but it does help to
   distinguish tests from operational code.

3. On preface (the refactoring engine), I've taken to placing tests in
   a tlib directory. This has the advantage of not having tests
   installed and lets you use shorter names for your test libraries:

   test::assertion_coderefs instead of
   Test::Unit::tests::TestAssertionCodeRef

   If we were to write a 'tlib.pm' modelled on blib.pm we could make
   working with a test libs directory reasonably trivial for
   developers. 

Anyway, just a few thoughts.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] DEBUG breaks tests

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Enabling DEBUG in T::U::Assert breaks the try_examples.t test, because
> of the
> 
>     print "Calling $assertion\n" if DEBUG;
> 
> in T::U::Assert::assert().
> 
> I haven't checked the effects of enabling other DEBUGs.

I wouldn't be surprised if they break other tests (at least those
tests that look at program output.)

> Any ideas what to do about it?

Well, there's the somewhat brutal idea of removing all the DEBUG stuff
and using Aspect::Trace to track program execution as and when we need
it. 

However, the immediate step should probably be to change 'print' to
'warn' for all the 'if DEBUG' clauses...

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?