no gnus registry new dependency on ert?

no gnus registry new dependency on ert?

[Eric Abrahamsen]

The recent registry rewrite has introduced a dependency on the ERT
testing library -- that library is part of emacs 24 but not emacs 23.
That made for an awkward code update, is there any way to warn people of
what's happening, or even include a local installation of ERT for those
who don't have it already?

Ta,

Eric

Re: no gnus registry new dependency on ert?

[Ted Zlatanov]

On Wed, 06 Apr 2011 12:28:17 +0800 Eric Abrahamsen <eric@ericabrahamsen.net> wrote: 

EA> The recent registry rewrite has introduced a dependency on the ERT
EA> testing library -- that library is part of emacs 24 but not emacs 23.

Hmm, I'm actually not sure how to provide the ERT tests only if ERT is
available.  Is there an example?  It seems like:

(require 'ert nil t)
...
(when (featurep 'ert)
  (ert-deftest gnus-registry-usage-test ()
  ...
)

should work but I want to be sure it will work properly.

EA> That made for an awkward code update, is there any way to warn people of
EA> what's happening, or even include a local installation of ERT for those
EA> who don't have it already?

All the registry code will run fine without the ERT tests and I don't
think we need to ship ERT with Gnus.  So I'd rather make it optional.

Ted

Re: no gnus registry new dependency on ert?

[David Engster]

Ted Zlatanov writes:
> On Wed, 06 Apr 2011 12:28:17 +0800 Eric Abrahamsen <eric@ericabrahamsen.net> wrote: 
>
> EA> The recent registry rewrite has introduced a dependency on the ERT
> EA> testing library -- that library is part of emacs 24 but not emacs 23.
>
> Hmm, I'm actually not sure how to provide the ERT tests only if ERT is
> available.  Is there an example?  It seems like:
>
> (require 'ert nil t)
> ...
> (when (featurep 'ert)
>   (ert-deftest gnus-registry-usage-test ()
>   ...
> )
>
> should work but I want to be sure it will work properly.

Either that, or just do

(eval-when-compile
  (when (null (require 'ert nil t))
    (defmacro* ert-deftest (name () &body docstring-keys-and-body))))

to silence the byte-compiler. Your solution is less hacky, but then you
have to always remember to wrap ert-deftest in those featurep clauses.

-David

Re: no gnus registry new dependency on ert?

[Ted Zlatanov]

On Wed, 06 Apr 2011 12:10:26 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Either that, or just do

DE> (eval-when-compile
DE>   (when (null (require 'ert nil t))
DE>     (defmacro* ert-deftest (name () &body docstring-keys-and-body))))

DE> to silence the byte-compiler. Your solution is less hacky, but then you
DE> have to always remember to wrap ert-deftest in those featurep clauses.

Oh, I like your solution better since I don't have to reindent ;)

I made the change in *registry.el, thanks.

Ted

Re: no gnus registry new dependency on ert?

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

On Wed, 06 Apr 2011 05:54:46 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Wed, 06 Apr 2011 12:10:26 +0200 David Engster <deng@randomsample.de> wrote: 
DE> Either that, or just do

DE> (eval-when-compile
DE> (when (null (require 'ert nil t))
DE> (defmacro* ert-deftest (name () &body docstring-keys-and-body))))

DE> to silence the byte-compiler. Your solution is less hacky, but then you
DE> have to always remember to wrap ert-deftest in those featurep clauses.

TZ> Oh, I like your solution better since I don't have to reindent ;)

TZ> I made the change in *registry.el, thanks.

Interesting.  When I byte-compile in Gnus (just "make" in the Lisp
directory), I get the attached backtrace.  Sorry for the nasty backtrace
but I can't load the code AND exhibit the problem.

If I load gnus-registry.el and do `M-x eval-buffer' then it works
properly.  So something is off with the byte-compilation, at least the
compilation that Gnus does.

Ted


[-- Attachment #2: ert-backtrace.txt --]
[-- Type: text/plain, Size: 9934 bytes --]

Debugger entered--Lisp error: (void-function make-ert-test)
  make-ert-test(:name registry-instantiation-test :body #[nil "\304\305C\x18\x19\306\x1a\307^[\310\216\311	\b\"\211\x12)\204\x19\0\312\v!\210)\n+\207" [args-65 fn-64 value-66 form-description-68 registry-db "Testing" ert-form-evaluation-aborted-67 nil ((byte-code "\305C\306\b	BD\244\n\307=?\205\x12\0\310\nD\244\311\312N\211^[\205!\0\313\314\v	\"D)\244\x14\315\f!\207" [fn-64 args-65 value-66 -explainer- form-description-68 (should (registry-db "Testing")) :form ert-form-evaluation-aborted-67 :value registry-db ert-explainer :explanation apply ert--signal-should-execution] 6)) apply ert-fail] 3])
  byte-code("\301\302\303\304#\210\301\305\306\307#\210\301\310\311\312#\210\301\313\314\315#\210\301\316\317\320#\210\321\322\323\324\322\325\326$\"\210\327\bB\x10\321\330\323\324\330\325\331$\"\210\332\bB\x10\301\207" [current-load-list eieio-defmethod registry-search (((db registry-db) &rest spec)) #[(db &rest spec) "\b\205 \0\306	\307\"\306	\310\"\306	\311\"\x1a^[\x1c\312\x1d\313\314\315\b\316\"\"\210\r\237,\207" [db spec regex member all --cl-var-- plist-get :all :member :regex nil maphash #[(k v) "\b\204\x1c\0	\203\x10\0\306\307\n	#\204\x1c\0\v\205!\0\306\310\n\v#\205!\0\f\rB\211\x15\207" [all member v regex k --cl-var-- registry--match :member :regex] 4] eieio-oref :data] 5 "Search for SPEC across the registry-db THIS.\nFor example calling with :member '(a 1 2) will match entry '((a 3 1)).\nCalling with :all t (any non-nil value) will match all.\nCalling with :regex '(a \"h.llo\") will match entry '((a \"hullo\" \"bye\").\nThe test order is to check :all first, then :member, then :regex."] registry-delete (((db registry-db) keys assert &rest spec)) #[(db keys assert &rest spec) "\306\b\307\"\x19\n\206\x0e\0\310\311\b\v#\x1a\306\b\312\"\x1c\n\313\x1d\211\x1e\x14\203\246\0\x0e\x14@\x15\314\r	\"\x1e\x15\x0e\x16\2036\0\x0e\x15\2046\0\315\316\r\"\210\f\313\x1e\x17\211\x1e\x18\203\226\0\x0e\x18@\x16\x17\317\b\x0e\x17\"\203\215\0\x0e\x17\x0e\x15\236\243\313\x1e\x19\211\x1e\x1a\203\214\0\x0e\x1a@\x16\x19\320\b\x0e\x17\x0e\x19#\x1e^[\r\x0e^[\235\203\202\0\320\b\x0e\x17\x0e\x19\321\r\x0e^[\"\206\200\0\322$\210)\x0e\x1aA\211\x16\x1a\204\\\0*\x0e\x18A\211\x16\x18\204@\0*\323\r	\"\210)\x0e\x14A\211\x16\x14\204\x1d\0*\n+\207" [db data keys spec tracked key eieio-oref :data apply registry-search :tracked nil gethash error "Key %s does not exists in database" registry-lookup-secondary registry-lookup-secondary-value delete t remhash --cl-dolist-temp-- entry assert tr --cl-dolist-temp-- val --cl-dolist-temp-- value-keys] 8 "Delete KEYS from the registry-db THIS.\nIf KEYS is nil, use SPEC to do a search.\nUpdates the secondary ('tracked') indices as well.\nWith assert non-nil, errors out if the key does not exist already."] registry-insert (((db registry-db) key entry)) #[(db key entry) "\306\b\307	\310\"\"\203\x0e\0\311\312!\210\313	!\307	\314\"W\204\x1d\0\311\315!\210\316\b\n\307	\310\"#\210\307	\317\"\320^[\211\x1c\203w\0\f@\211\x13\n\236\243\320\x1d\211\x1e\x12\203o\0\x0e\x12@\x15\321	\v\r#\x1e\x13\b\x0e\x13\235\203W\0\x0e\x13\202[\0\b\x0e\x13B\x16\x13\321	\v\r\x0e\x13$\210)\x0e\x12A\211\x16\x12\204@\0*\fA\211\x14\2041\0*\n\207" [key db entry tr --cl-dolist-temp-- val gethash eieio-oref :data error "Key already exists in database" registry-size :max-hard "max-hard size limit reached" puthash :tracked nil registry-lookup-secondary-value --cl-dolist-temp-- value-keys] 7 "Insert ENTRY under KEY into the registry-db THIS.\nUpdates the secondary ('tracked') indices as well.\nErrors out if the key exists already."] registry-size (((db registry-db))) #[(db) "\301\302\b\303\"!\207" [db hash-table-count eieio-oref :data] 4 "Returns the size of the registry-db object THIS.\nThis is the key count of the :data slot."] registry-prune (((db registry-db))) #[(db) "\306\b\307\"\x19\310\x1a\306\b\311\"^[\306\b\312\"\x1c\313\b!\x1d\314\x1e\x10\315\316\v\"\210\x0e\x10\237)\211\x1e\x11G\x1e\x12\r\fV\x1e\x13\x0e\x12\r\fZV\203G\0\x0e\x11\203G\0\x0e\x12S\x16\x12\x0e\x11A\x16\x11\202,\0\317\b\x0e\x11\314#.\b\207" [db precious precious-p data limit size eieio-oref :precious #[(entry-key) "\b@	>A\207" [entry-key precious] 2] :data :max-soft registry-size nil maphash #[(k v) "\b	\306\x1a^[\x1c\307\310\f\v\n$+?\205\x18\0\r\x0e	B\211\x16	\207" [precious-p v cl-rest cl-seq cl-pred k nil apply some --cl-var--] 5] registry-delete --cl-var-- candidates candidates-count prune-needed] 5 "Prunes the registry-db object THIS.\nRemoves only entries without the :precious keys."] ert-set-test registry-instantiation-test make-ert-test :name :body #[nil "\304\305C\x18\x19\306\x1a\307^[\310\216\311	\b\"\211\x12)\204\x19\0\312\v!\210)\n+\207" [args-65 fn-64 value-66 form-description-68 registry-db "Testing" ert-form-evaluation-aborted-67 nil ((byte-code "\305C\306\b	BD\244\n\307=?\205\x12\0\310\nD\244\311\312N\211^[\205!\0\313\314\v	\"D)\244\x14\315\f!\207" [fn-64 args-65 value-66 -explainer- form-description-68 (should (registry-db "Testing")) :form ert-form-evaluation-aborted-67 :value registry-db ert-explainer :explanation apply ert--signal-should-execution] 6)) apply ert-fail] 3] (ert-deftest . registry-instantiation-test) registry-match-test #[nil "\306\x18\307\310!\210\311\312\b\313E\x19\x1a\314^[\315\x1c\316\216\317\n	\"\211\x13)\204!\0\320\f!\210)\v\210+\311\312\b\321E\x1d\x1e,\322\x1e-\315\x1e.\323\216\317\x0e,\r\"\211\x16-)\204F\0\320\x0e.!\210)\x0e-\210+\311\312\b\324E\x1e/\x1e0\325\x1e1\315\x1e2\326\216\317\x0e0\x0e/\"\211\x161)\203n\0\320\x0e2!\210)\x0e1\210+\311\312\b\327E\x1e3\x1e4\330\x1e5\315\x1e6\331\216\317\x0e4\x0e3\"\211\x165)\203\226\0\320\x0e6!\210)\x0e5\210+\307\332!\210\311\333\b\334E\x1e7\x1e8\335\x1e9\315\x1e:\336\216\317\x0e8\x0e7\"\211\x169)\204\302\0\320\x0e:!\210)\x0e9\210+\311\333\b\337E\x1e;\x1e<\340\x1e=\315\x1e>\341\216\317\x0e<\x0e;\"\211\x16=)\204\352\0\320\x0e>!\210)\x0e=\210+\311\333\b\342E\x1e?\x1e@\343\x1eA\315\x1eB\344\216\317\x0e@\x0e?\"\211\x16A)\203\x12\x01\320\x0eB!\210)\x0eA\210+\311\333\b\345E\x1eC\x1eD\346\x1eE\315\x1eF\347\216\317\x0eD\x0eC\"\211\x16E)\203:\x01\320\x0eF!\210)\x0eE\210+\311\333\b\350E\x1eG\x1eH\351\x1eI\315\x1eJ\352\216\317\x0eH\x0eG\"\211\x16I)\203b\x01\320\x0eJ!\210)\x0eI\210,\307\353!\207" [entry args-70 fn-69 value-71 form-description-73 args-75 ((hello "goodbye" "bye") (blank)) message "Testing :regex matching" registry--match :regex ((hello "nye" "bye")) ert-form-evaluation-aborted-72 nil ((byte-code "\305C\306\b	BD\244\n\307=?\205\x12\0\310\nD\244\311\312N\211^[\205!\0\313\314\v	\"D)\244\x14\315\f!\207" [fn-69 args-70 value-71 -explainer- form-description-73 (should (registry--match :regex entry ...)) :form ert-form-evaluation-aborted-72 :value registry--match ert-explainer :explanation apply ert--signal-should-execution] 6)) apply ert-fail ((hello "good")) ert-form-evaluation-aborted-77 ((byte-code "\305C\306\b	BD\244\n\307=?\205\x12\0\310\nD\244\311\312N\211^[\205!\0\313\314\v	\"D)\244\x14\315\f!\207" [fn-74 args-75 value-76 -explainer- form-description-78 (should (registry--match :regex entry ...)) :form ert-form-evaluation-aborted-77 :value registry--match ert-explainer :explanation apply ert--signal-should-execution] 6)) ((hello "nye")) ert-form-evaluation-aborted-82 ((byte-code "\305C\306\b	BD\244\n\307=?\205\x12\0\310\nD\244\311\312N\211^[\205!\0\313\314\v	\"D)\244\x14\315\f!\207" [fn-79 args-80 value-81 -explainer- form-description-83 (should-not (registry--match :regex entry ...)) :form ert-form-evaluation-aborted-82 :value registry--match ert-explainer :explanation apply ert--signal-should-execution] 6)) ((hello)) ert-form-evaluation-aborted-87 ((byte-code "\305C\306\b	BD\244\n\307=?\205\x12\0\310\nD\244\311\312N\211^[\205!\0\313\314\v	\"D)\244\x14\315\f!\207" [fn-84 args-85 value-86 -explainer- form-description-88 (should-not (registry--match :regex entry ...)) :form ert-form-evaluation-aborted-87 :value registry--match ert-explainer :explanation apply ert--signal-should-execution] 6)) "Testing :member matching" :member ((hello "bye")) ert-form-evaluation-aborted-92 ((byte-code "\305C\306\b	BD\244\n\307=?\205\x12\0\310\nD\244\311\312N\211^[\205!\0\313\314\v	\"D)\244\x14\315\f!\207" [fn-89 args-90 value-91 -explainer- form-description-93 (should (registry--match :member entry ...)) :form ert-form-evaluation-aborted-92 :value registry--match ert-explainer :explanation apply ert--signal-should-execution] 6)) ((hello "goodbye")) ert-form-evaluation-aborted-97 ((byte-code "\305C\306\b	BD\244\n\307=?\205\x12\0\310\nD\244\311\312N\211^[\205!\0\313\314\v	\"D)\244\x14\315\f!\207" [fn-94 args-95 value-96 -explainer- form-description-98 (should (registry--match :member entry ...)) :form ert-form-evaluation-aborted-97 :value registry--match ert-explainer :explanation apply ert--signal-should-execution] 6)) ((hello "good")) ert-form-evaluation-aborted-102 ((byte-code "\305C\306\b	BD\244\n\307=?\205\x12\0\310\nD\244\311\312N\211^[\205!\0\313\314\v	\"D)\244\x14\315\f!\207" [fn-99 args-100 value-101 -explainer- form-description-103 (should-not (registry--match :member entry ...)) :form ert-form-evaluation-aborted-102 :value registry--match ert-explainer :explanation apply ert--signal-should-execution] 6)) ((hello "nye")) ert-form-evaluation-aborted-107 ((byte-code "\305C\306\b	BD\244\n\307=?\205\x12\0\310\nD\244\311\312N\211^[\205!\0\313\314\v	\"D)\244\x14\315\f!\207" [fn-104 args-105 value-106 -explainer- form-description-108 (should-not (registry--match :member entry ...)) :form ert-form-evaluation-aborted-107 :value registry--match ert-explainer :explanation apply ert--signal-should-execution] 6)) ((hello)) ert-form-evaluation-aborted-112 ((byte-code "\305C\306\b	BD\244\n\307=?\205\x12\0\310\nD\244\311\312N\211^[\205!\0\313\314\v	\"D)\244\x14\315\f!\207" [fn-109 args-110 value-111 -explainer- form-description-113 (should-not (registry--match :member entry ...)) :form ert-form-evaluation-aborted-112 :value registry--match ert-explainer :explanation apply ert--signal-should-execution] 6)) "Done with matching testing." fn-74 value-76 form-description-78 args-80 fn-79 value-81 ...] 4] (ert-deftest . registry-match-test)] 7)
  require(registry)
  byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\210\300\307!\210\300\310!\207" [require gnus gnus-int gnus-sum gnus-art gnus-util nnmail easymenu registry] 2)
  (gnus-registry-initialize)
  eval-buffer(#<buffer  *load*> nil "/home/tzz/.gnus.el" nil t)  ; Reading at buffer position 1072
  load-with-code-conversion("/home/tzz/.gnus.el" "/home/tzz/.gnus.el" nil t)
  load("~/.gnus" nil t)
  gnus-read-init-file()
  gnus-1(nil nil nil)
  gnus(nil)
  call-interactively(gnus t nil)
  execute-extended-command(nil)
  call-interactively(execute-extended-command nil nil)

Re: no gnus registry new dependency on ert?

[David Engster]

Ted Zlatanov writes:
> On Wed, 06 Apr 2011 05:54:46 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>
> TZ> On Wed, 06 Apr 2011 12:10:26 +0200 David Engster <deng@randomsample.de> wrote: 
> DE> Either that, or just do
>
> DE> (eval-when-compile
> DE> (when (null (require 'ert nil t))
> DE> (defmacro* ert-deftest (name () &body docstring-keys-and-body))))
>
> DE> to silence the byte-compiler. Your solution is less hacky, but then you
> DE> have to always remember to wrap ert-deftest in those featurep clauses.
>
> TZ> Oh, I like your solution better since I don't have to reindent ;)
>
> TZ> I made the change in *registry.el, thanks.
>
> Interesting.  When I byte-compile in Gnus (just "make" in the Lisp
> directory), I get the attached backtrace.  Sorry for the nasty backtrace
> but I can't load the code AND exhibit the problem.
>
> If I load gnus-registry.el and do `M-x eval-buffer' then it works
> properly.  So something is off with the byte-compilation, at least the
> compilation that Gnus does.

It seems like putting (require 'ert) into an eval-when-compile is not
sufficient. You have to require it unconditionally.

So maybe your first idea was The Right Thing To Do, meaning to use

(require 'ert nil t)

and then test for feature 'ert. Alternatively, you could use the current
hack and put this require in there, too. But this is getting
increasingly ugly...

-David

Re: no gnus registry new dependency on ert?

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Wed, 06 Apr 2011 15:28:07 +0200 David Engster <deng@randomsample.de> wrote: 

DE> It seems like putting (require 'ert) into an eval-when-compile is not
DE> sufficient. You have to require it unconditionally.

DE> So maybe your first idea was The Right Thing To Do, meaning to use

DE> (require 'ert nil t)

DE> and then test for feature 'ert. Alternatively, you could use the current
DE> hack and put this require in there, too. But this is getting
DE> increasingly ugly...

See the attached patch, which just adds (require 'ert nil t) *in
addition* to the defmacro hack.  It seems to DTRT for me, let me know
what you think.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: registry-ert-loading.patch --]
[-- Type: text/x-diff, Size: 714 bytes --]

diff --git a/lisp/gnus-registry.el b/lisp/gnus-registry.el
index 511012d..6c660b1 100644
--- a/lisp/gnus-registry.el
+++ b/lisp/gnus-registry.el
@@ -61,6 +61,7 @@
   (when (null (require 'ert nil t))
     (defmacro* ert-deftest (name () &body docstring-keys-and-body))))
 
+(require 'ert nil t)
 (require 'gnus)
 (require 'gnus-int)
 (require 'gnus-sum)
diff --git a/lisp/registry.el b/lisp/registry.el
index cc03b20..edaa4f5 100644
--- a/lisp/registry.el
+++ b/lisp/registry.el
@@ -81,6 +81,8 @@
   (when (null (require 'ert nil t))
     (defmacro* ert-deftest (name () &body docstring-keys-and-body))))
 
+(require 'ert nil t)
+
 (eval-when-compile (require 'cl))
 (eval-and-compile
   (or (ignore-errors (progn

Re: no gnus registry new dependency on ert?

[David Engster]

Ted Zlatanov writes:
> On Wed, 06 Apr 2011 15:28:07 +0200 David Engster <deng@randomsample.de> wrote: 
>
> DE> It seems like putting (require 'ert) into an eval-when-compile is not
> DE> sufficient. You have to require it unconditionally.
>
> DE> So maybe your first idea was The Right Thing To Do, meaning to use
>
> DE> (require 'ert nil t)
>
> DE> and then test for feature 'ert. Alternatively, you could use the current
> DE> hack and put this require in there, too. But this is getting
> DE> increasingly ugly...
>
> See the attached patch, which just adds (require 'ert nil t) *in
> addition* to the defmacro hack.  It seems to DTRT for me, let me know
> what you think.

Yes, that's what I meant with the latter suggestion. I'm not sure if
this is the right way to solve this, but it works for me, too.

-David

Re: no gnus registry new dependency on ert?

[Ted Zlatanov]

On Wed, 06 Apr 2011 16:57:05 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Ted Zlatanov writes:
>> See the attached patch, which just adds (require 'ert nil t) *in
>> addition* to the defmacro hack.  It seems to DTRT for me, let me know
>> what you think.

DE> Yes, that's what I meant with the latter suggestion. I'm not sure if
DE> this is the right way to solve this, but it works for me, too.

OK, it's pushed.  Let's hope it's the end of the hackery.

Ted

Re: no gnus registry new dependency on ert?

[David Engster]

David Engster writes:
> Ted Zlatanov writes:
>> On Wed, 06 Apr 2011 15:28:07 +0200 David Engster <deng@randomsample.de> wrote: 
>>
>> DE> It seems like putting (require 'ert) into an eval-when-compile is not
>
>> DE> sufficient. You have to require it unconditionally.
>>
>> DE> So maybe your first idea was The Right Thing To Do, meaning to use
>>
>> DE> (require 'ert nil t)
>>
>> DE> and then test for feature 'ert. Alternatively, you could use the current
>> DE> hack and put this require in there, too. But this is getting
>> DE> increasingly ugly...
>>
>> See the attached patch, which just adds (require 'ert nil t) *in
>> addition* to the defmacro hack.  It seems to DTRT for me, let me know
>> what you think.
>
> Yes, that's what I meant with the latter suggestion. I'm not sure if
> this is the right way to solve this, but it works for me, too.

Addendum: Maybe the "real" solution is to have the tests in a separate
file, so that a (require 'registry) won't instantiate the ERT tests. I
can see why having the tests in the file itself can be convenient, but
usually, test-suites are separated from the actual code? Anyway, I don't
really have a strong opinion on this.

-David

Re: no gnus registry new dependency on ert?

[Ted Zlatanov]

On Wed, 06 Apr 2011 17:03:50 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Addendum: Maybe the "real" solution is to have the tests in a separate
DE> file, so that a (require 'registry) won't instantiate the ERT tests. I
DE> can see why having the tests in the file itself can be convenient, but
DE> usually, test-suites are separated from the actual code? Anyway, I don't
DE> really have a strong opinion on this.

I considered that approach but I think it's cleaner and easier to do it
in one file, if there are no technical reasons against it.

Ted

Gnus automatic builds (was: no gnus registry new dependency on ert?)

[Ted Zlatanov]

On Wed, 06 Apr 2011 12:28:17 +0800 Eric Abrahamsen <eric@ericabrahamsen.net> wrote: 

EA> The recent registry rewrite has introduced a dependency on the ERT
EA> testing library -- that library is part of emacs 24 but not emacs 23.
EA> That made for an awkward code update, is there any way to warn people of
EA> what's happening, or even include a local installation of ERT for those
EA> who don't have it already?

To answer the implied question, "how do we catch version compatibility
and other commit errors," I think the right way is with automatic builds
against various Emacs and XEmacs versions.  David Engster was planning
to set something up and he was talking to Lars last I heard.  David, if
you need anything from me, please let me know.  I'm eager to get
automatic builds working for the benefit of Gnus and Emacs as a whole.

Ted

Re: Gnus automatic builds

[David Engster]

Ted Zlatanov writes:
> On Wed, 06 Apr 2011 12:28:17 +0800 Eric Abrahamsen <eric@ericabrahamsen.net> wrote: 
>
> EA> The recent registry rewrite has introduced a dependency on the ERT
> EA> testing library -- that library is part of emacs 24 but not emacs 23.
> EA> That made for an awkward code update, is there any way to warn people of
> EA> what's happening, or even include a local installation of ERT for those
> EA> who don't have it already?
>
> To answer the implied question, "how do we catch version compatibility
> and other commit errors," I think the right way is with automatic builds
> against various Emacs and XEmacs versions.  David Engster was planning
> to set something up and he was talking to Lars last I heard.  David, if
> you need anything from me, please let me know.  I'm eager to get
> automatic builds working for the benefit of Gnus and Emacs as a whole.

There are only a few changes needed to dgnushack and the Makefiles. I
think I can do this quickly later today.

-David

Re: Gnus automatic builds

[David Engster]

David Engster writes:
> Ted Zlatanov writes:
>> On Wed, 06 Apr 2011 12:28:17 +0800 Eric Abrahamsen <eric@ericabrahamsen.net> wrote: 
>>
>> EA> The recent registry rewrite has introduced a dependency on the ERT
>
>> EA> testing library -- that library is part of emacs 24 but not emacs 23.
>> EA> That made for an awkward code update, is there any way to warn people of
>> EA> what's happening, or even include a local installation of ERT for those
>> EA> who don't have it already?
>>
>> To answer the implied question, "how do we catch version compatibility
>> and other commit errors," I think the right way is with automatic builds
>> against various Emacs and XEmacs versions.  David Engster was planning
>> to set something up and he was talking to Lars last I heard.  David, if
>> you need anything from me, please let me know.  I'm eager to get
>> automatic builds working for the benefit of Gnus and Emacs as a whole.
>
> There are only a few changes needed to dgnushack and the Makefiles. I
> think I can do this quickly later today.

OK, I've done that now. When invoking the rule 'fail-on-warning', the
build will be marked as failed for compile errors, and the most
important warnings are reported as errors as well. dgnushack will still
continue compiling, but in the end the build will be marked as failed.

The following warnings are currently enabled in dgnushack: 

	  '(free-vars unresolved callargs redefine suspicious)

All other warnings will be ignored. If you want to see those, do 'make
warn' in the lisp subdirectory.

I've now configured the buildbot to use the 'fail-on-warning' rule. You
can already see that it is working quite nicely, since there are already
failed builds. :-)

http://randomsample.de/gnus-buildbot

There are currently the following problems:

- Xemacs 21.4 doesn't seem to support the (require 'foo nil t) syntax.

- Xemacs 21.5 seems to have some problems with EIEIO :after functions.

- Emacs 22: 
 
  In toplevel form:
  message.el:1923:20:Error: `make-variable-buffer-local' should be called at toplevel


I've not yet enabled emails on failed builds. I first want to make sure
that everything works for a few days.

-David

Re: Gnus automatic builds

[Ted Zlatanov]

On Wed, 06 Apr 2011 18:14:43 +0200 David Engster <deng@randomsample.de> wrote: 

DE> OK, I've done that now. When invoking the rule 'fail-on-warning', the
DE> build will be marked as failed for compile errors, and the most
DE> important warnings are reported as errors as well. dgnushack will still
DE> continue compiling, but in the end the build will be marked as failed.

DE> The following warnings are currently enabled in dgnushack: 

DE> 	  '(free-vars unresolved callargs redefine suspicious)

DE> All other warnings will be ignored. If you want to see those, do 'make
DE> warn' in the lisp subdirectory.

Wonderful.  Can we set up a separate `make warn' build to go to just the
Gnus developers individually, not the Ding mailing list?

Also does it run the ERT tests?  I think it should, maybe as a separate
target.  The registry.el and gnus-registry.el ERT tests write files to
the filesystem (using `make-temp-file') but otherwise there are no side
effects.

DE> I've not yet enabled emails on failed builds. I first want to make sure
DE> that everything works for a few days.

Thank you for working on this.  It's really helpful.

Ted

Re: Gnus automatic builds

[David Engster]

Ted Zlatanov writes:
> On Wed, 06 Apr 2011 18:14:43 +0200 David Engster <deng@randomsample.de> wrote: 
>
> DE> OK, I've done that now. When invoking the rule 'fail-on-warning', the
> DE> build will be marked as failed for compile errors, and the most
> DE> important warnings are reported as errors as well. dgnushack will still
> DE> continue compiling, but in the end the build will be marked as failed.
>
> DE> The following warnings are currently enabled in dgnushack: 
>
> DE> 	  '(free-vars unresolved callargs redefine suspicious)
>
> DE> All other warnings will be ignored. If you want to see those, do 'make
> DE> warn' in the lisp subdirectory.
>
> Wonderful.  Can we set up a separate `make warn' build to go to just the
> Gnus developers individually, not the Ding mailing list?

I didn't plan on sending buildbot information to the ding mailing list,
but to the 'blamelist' only (meaning all people who committed since the
last build). I don't think failed builds are interesting enough for the
whole list. It's no problem to add people who always want to receive
mails, though.

As for 'make warn', I don't think it makes much sense to have a failed
builds for those warnings. There are simply too many (just try it).

> Also does it run the ERT tests?  I think it should, maybe as a separate
> target.  The registry.el and gnus-registry.el ERT tests write files to
> the filesystem (using `make-temp-file') but otherwise there are no side
> effects.

Not yet. I think we should use another Makefile rule for that. I'll see
to it that I add something, probably 'make check', which will then
depend on many smaller rules which run specific tests (like the registry
tests).

-David

Re: Gnus automatic builds

[Ted Zlatanov]

On Wed, 06 Apr 2011 20:10:14 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Ted Zlatanov writes:
>> On Wed, 06 Apr 2011 18:14:43 +0200 David Engster <deng@randomsample.de> wrote: 
>> 
DE> OK, I've done that now. When invoking the rule 'fail-on-warning', the
DE> build will be marked as failed for compile errors, and the most
DE> important warnings are reported as errors as well. dgnushack will still
DE> continue compiling, but in the end the build will be marked as failed.
>> 
DE> The following warnings are currently enabled in dgnushack: 
>> 
DE> '(free-vars unresolved callargs redefine suspicious)
>> 
DE> All other warnings will be ignored. If you want to see those, do 'make
DE> warn' in the lisp subdirectory.
>> 
>> Wonderful.  Can we set up a separate `make warn' build to go to just the
>> Gnus developers individually, not the Ding mailing list?

DE> As for 'make warn', I don't think it makes much sense to have a failed
DE> builds for those warnings. There are simply too many (just try it).

OK.  I'm OK with just the blamelist for failed builds, though I would
always add Katsumi Yamaoka, Lars, and me to it.

>> Also does it run the ERT tests?  I think it should, maybe as a separate
>> target.  The registry.el and gnus-registry.el ERT tests write files to
>> the filesystem (using `make-temp-file') but otherwise there are no side
>> effects.

DE> Not yet. I think we should use another Makefile rule for that. I'll see
DE> to it that I add something, probably 'make check', which will then
DE> depend on many smaller rules which run specific tests (like the registry
DE> tests).

Up to you, however you want to do it.

Ted

Re: Gnus automatic builds

[David Engster]

[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]

Ted Zlatanov writes:
> OK.  I'm OK with just the blamelist for failed builds, though I would
> always add Katsumi Yamaoka, Lars, and me to it.

OK, will do. Lars and Katsumi, if you're reading this, please let me
know if this is OK.

>>> Also does it run the ERT tests?  I think it should, maybe as a separate
>>> target.  The registry.el and gnus-registry.el ERT tests write files to
>>> the filesystem (using `make-temp-file') but otherwise there are no side
>>> effects.
>
> DE> Not yet. I think we should use another Makefile rule for that. I'll see
> DE> to it that I add something, probably 'make check', which will then
> DE> depend on many smaller rules which run specific tests (like the registry
> DE> tests).
>
> Up to you, however you want to do it.

I've now added a new rule 'check' which will run the whole test suite. I
think it's a good thing to have a rule for every test in lisp/Makefile,
since during development one often has to run single tests and not the
whole suite. I've now started with "test-registry".

Problem is: ERT does not run under Emacs 22, nor under XEmacs. So only
Emacs 23 and 24 will currently run the tests. Maybe someone will port
ERT to XEmacs, then we can add that any time.

I've also written a little test for NNTP connections; I've attached it
to this mail. It also shows how one can test "real" Gnus functionality
in batch mode on the buildbot server. It will connect news.gmane.org,
get gmane.discuss, retrieve a single article from it (via message-id)
and exit Gnus. The problem with these kinds of tests is that they depend
on an external server. I added a simple check so that those test will
only run if a ping to news.gmane.org succeeds, but still, the server
might have other problems, which will lead to a failing test. So a
failed NNTP test might not necessarily mean the last commit actually
broke something, but a look in the logs should clear that up.

The reason I did not commit gnustest-nntp.el yet is that I don't know
where it should live. I'm hesitant to add it to gnus/lisp, because maybe
we should have a dedicated directory for tests? We could also put other
files in there we'll need for testing (some dummy mails for populating
an IMAP folder, for instance). Suggestions?

-David


[-- Attachment #2: gnustest-nntp.el --]
[-- Type: application/emacs-lisp, Size: 3146 bytes --]

Re: Gnus automatic builds

[Ted Zlatanov]

On Thu, 07 Apr 2011 21:21:46 +0200 David Engster <deng@randomsample.de> wrote: 

DE> I've now added a new rule 'check' which will run the whole test suite. I
DE> think it's a good thing to have a rule for every test in lisp/Makefile,
DE> since during development one often has to run single tests and not the
DE> whole suite. I've now started with "test-registry".

DE> Problem is: ERT does not run under Emacs 22, nor under XEmacs. So only
DE> Emacs 23 and 24 will currently run the tests. Maybe someone will port
DE> ERT to XEmacs, then we can add that any time.

I guess we could bundle ERT with the Gnus tests.  I was hoping to avoid
that.  Can it be installed in XEmacs as a package?

DE> I've also written a little test for NNTP connections; I've attached it
DE> to this mail. It also shows how one can test "real" Gnus functionality
DE> in batch mode on the buildbot server. It will connect news.gmane.org,
DE> get gmane.discuss, retrieve a single article from it (via message-id)
DE> and exit Gnus. The problem with these kinds of tests is that they depend
DE> on an external server. I added a simple check so that those test will
DE> only run if a ping to news.gmane.org succeeds, but still, the server
DE> might have other problems, which will lead to a failing test. So a
DE> failed NNTP test might not necessarily mean the last commit actually
DE> broke something, but a look in the logs should clear that up.

That's reasonable.  We could also run a fake NNTP server on a local port
that knows only a few commands and send back replies for them, so the
interaction is scripted.  This approach will definitely help us find
Gnus issues quickly.  I don't like test-driven development, but once the
code has been written, it's extremely useful to write tests too.

DE> The reason I did not commit gnustest-nntp.el yet is that I don't know
DE> where it should live. I'm hesitant to add it to gnus/lisp, because maybe
DE> we should have a dedicated directory for tests? We could also put other
DE> files in there we'll need for testing (some dummy mails for populating
DE> an IMAP folder, for instance). Suggestions?

For the *registry.el ERT tests I tried to provide tests that show how to
use the functionality (I used to just put comments with typical usage
above each defun).  Sort of a self-documenting library approach and one
of the reasons I like tests in the first place.

For standalone tests it makes sense to keep them separate.  So
gnus/tests would IMHO be OK and ERT can live there too.  Lars?

Ted

Re: Gnus automatic builds

[David Engster]

Ted Zlatanov writes:
> On Thu, 07 Apr 2011 21:21:46 +0200 David Engster <deng@randomsample.de> wrote: 
>
> DE> Problem is: ERT does not run under Emacs 22, nor under XEmacs. So only
> DE> Emacs 23 and 24 will currently run the tests. Maybe someone will port
> DE> ERT to XEmacs, then we can add that any time.
>
> I guess we could bundle ERT with the Gnus tests.  I was hoping to avoid
> that.  Can it be installed in XEmacs as a package?

No, ERT simply won't run under Emacs22 and XEmacs, so bundling won't
help (I already locally installed it for Emacs23 on the server). Emacs22
is missing 'special-mode', as does XEmacs. Additionally, ERT is using
the 'button' library, which apparently isn't available for XEmacs. At
least that's what I got from a short test; there's probably more. If
someone ports ERT to those Emacsen, I'll happily install it...

> That's reasonable.  We could also run a fake NNTP server on a local port
> that knows only a few commands and send back replies for them, so the
> interaction is scripted.  This approach will definitely help us find
> Gnus issues quickly.  I don't like test-driven development, but once the
> code has been written, it's extremely useful to write tests too.

Yeah well, if someone writes such a server... until now, I think Gmane
will do (it's superstable, as far as I know).

As for testing nnimap, the server is running dovecot. It would be no
problem to install a test user there.

-David

Re: Gnus automatic builds

[Ted Zlatanov]

On Thu, 07 Apr 2011 22:02:36 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Ted Zlatanov writes:
>> On Thu, 07 Apr 2011 21:21:46 +0200 David Engster <deng@randomsample.de> wrote: 
>> 
DE> Problem is: ERT does not run under Emacs 22, nor under XEmacs. So only
DE> Emacs 23 and 24 will currently run the tests. Maybe someone will port
DE> ERT to XEmacs, then we can add that any time.
>> 
>> I guess we could bundle ERT with the Gnus tests.  I was hoping to avoid
>> that.  Can it be installed in XEmacs as a package?

DE> No, ERT simply won't run under Emacs22 and XEmacs, so bundling won't
DE> help (I already locally installed it for Emacs23 on the server). Emacs22
DE> is missing 'special-mode', as does XEmacs. Additionally, ERT is using
DE> the 'button' library, which apparently isn't available for XEmacs. At
DE> least that's what I got from a short test; there's probably more. If
DE> someone ports ERT to those Emacsen, I'll happily install it...

Oh I see.  That's surprising.  We could do a Gnus compatibility version
of ERT, implementing just the few macros we use and bailing completely
if there's an error.

>> That's reasonable.  We could also run a fake NNTP server on a local port
>> that knows only a few commands and send back replies for them, so the
>> interaction is scripted.

DE> Yeah well, if someone writes such a server... until now, I think Gmane
DE> will do (it's superstable, as far as I know).

OK.

Ted

Re: Gnus automatic builds

[Lars Magne Ingebrigtsen]

David Engster <deng@randomsample.de> writes:

>> OK.  I'm OK with just the blamelist for failed builds, though I would
>> always add Katsumi Yamaoka, Lars, and me to it.
>
> OK, will do. Lars and Katsumi, if you're reading this, please let me
> know if this is OK.

How about a buildbot mailing list?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Gnus automatic builds

[David Engster]

Lars Magne Ingebrigtsen writes:
> David Engster <deng@randomsample.de> writes:
>
>>> OK.  I'm OK with just the blamelist for failed builds, though I would
>>> always add Katsumi Yamaoka, Lars, and me to it.
>>
>> OK, will do. Lars and Katsumi, if you're reading this, please let me
>> know if this is OK.
>
> How about a buildbot mailing list?

Sure. That'd be even neater.

-David

Re: Gnus automatic builds

[Lars Magne Ingebrigtsen]

David Engster <deng@randomsample.de> writes:

>> How about a buildbot mailing list?
>
> Sure. That'd be even neater.

Jason, would it be possible to set up a buildbot@gnus.org mailing list?
It'll only get messages from David's spiffy new Gnus build bot farm.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Gnus automatic builds

[Jason L Tibbitts III]

No problem at all; should I keep with the existing pattern and use
"ding-buildbot" or should I be all modern and call it "gnus-buildbot"?
(Obviously the @gnus.org aliases just need to forward to the right list
in either case, so this is purely cosmetic.)

 - J<

Re: Gnus automatic builds

[Lars Magne Ingebrigtsen]

"Jason L Tibbitts III" <tibbs@math.uh.edu> writes:

> No problem at all; should I keep with the existing pattern and use
> "ding-buildbot" or should I be all modern and call it "gnus-buildbot"?
> (Obviously the @gnus.org aliases just need to forward to the right list
> in either case, so this is purely cosmetic.)

gnus-buildbot would be fine, I think.

So I'll add aliases for

gnus-buildbot@lists.math.uh.edu
gnus-buildbot-request@lists.math.uh.edu

on @gnus.org.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Gnus automatic builds

[Jason L Tibbitts III]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> gnus-buildbot would be fine, I think.

OK, that's done.

LMI> So I'll add aliases for
LMI> gnus-buildbot@lists.math.uh.edu
LMI> gnus-buildbot-request@lists.math.uh.edu

You can add gnus-buildbot-subscribe@lists.math.uh.edu as well, if you
wish.

I assume that only a specific script will be sending messages to the
list; if you know the email address it will use now, I can allow it to
post; otherwise I'll just allow addresses as the mail comes in.

 - J<

Re: Gnus automatic builds

[David Engster]

Jason L. Tibbitts, III writes:
> I assume that only a specific script will be sending messages to the
> list; if you know the email address it will use now, I can allow it to
> post; otherwise I'll just allow addresses as the mail comes in.

It'll be 'gnus-buildbot@randomsample.de'.

Thanks,
David

Re: Gnus automatic builds

[Jason L Tibbitts III]

>>>>> "DE" == David Engster <deng@randomsample.de> writes:

DE> It'll be 'gnus-buildbot@randomsample.de'.

Thanks; I've set that as the only address which can post to the list
without moderation.  Please let me know if that needs to change in the
future.

 - J<

Re: Gnus automatic builds

[David Engster]

Jason L. Tibbitts, III writes:
>>>>>> "DE" == David Engster <deng@randomsample.de> writes:
>
> DE> It'll be 'gnus-buildbot@randomsample.de'.
>
> Thanks; I've set that as the only address which can post to the list
> without moderation.  Please let me know if that needs to change in the
> future.

Thanks. The buildbot is now configured to send messages on failed builds
to that mailing list. Now someone should break the build. :-)

I've not activated sending mails to the 'blamelist', since I figure that
Gnus developers will have the buildbot list subscribed anyway.

I'd also like to repost my question where pure test files should be
stored (see my previously posted gnustest-nntp.el). Should I just check
it in to lisp/ for now? Or etc/ ? We can move it later anyway.

-David

Re: Gnus automatic builds

[Ted Zlatanov]

On Sat, 16 Apr 2011 10:22:32 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Thanks. The buildbot is now configured to send messages on failed builds
DE> to that mailing list. Now someone should break the build. :-)

DE> I've not activated sending mails to the 'blamelist', since I figure that
DE> Gnus developers will have the buildbot list subscribed anyway.

I would add it.

DE> I'd also like to repost my question where pure test files should be
DE> stored (see my previously posted gnustest-nntp.el). Should I just check
DE> it in to lisp/ for now? Or etc/ ? We can move it later anyway.

IMHO either tests/ or lisp/tests/ (the latter will make it easier to
avoid naming the "lisp" directory in relative paths).

Pick one and we can move them later if needed.

Could this work if we symlink registry.el and gnus-registry.el into the
tests directory?  Git supports symlinks and it would be a neat hack.

Ted

Re: Gnus automatic builds

[David Engster]

Ted Zlatanov writes:
> DE> I've not activated sending mails to the 'blamelist', since I figure that
> DE> Gnus developers will have the buildbot list subscribed anyway.
>
> I would add it.

OK, done.

Please note that there's one little annoyance: You will get a single
mail for all failed builds, meaning for every Emacs version. That means
if you "really" break something, you'll get 5 mails. There's no way in
buildbot to send just one mail which contains all the information.

The mails will always come from gnus-buildbot@randomsample.de, so you
can easily split them.

> DE> I'd also like to repost my question where pure test files should be
> DE> stored (see my previously posted gnustest-nntp.el). Should I just check
> DE> it in to lisp/ for now? Or etc/ ? We can move it later anyway.
>
> IMHO either tests/ or lisp/tests/ (the latter will make it easier to
> avoid naming the "lisp" directory in relative paths).
>
> Pick one and we can move them later if needed.

OK, I chose lisp/tests.

The buildbot will not run the NNTP test on new commits. I think the main
part of this test is actually not the nntp testing, but more that it is
an integration test which will fire up various parts of Gnus, so that
broken require's etc. will hopefully pop up during startup.

> Could this work if we symlink registry.el and gnus-registry.el into the
> tests directory?  Git supports symlinks and it would be a neat hack.

I think this is a bit confusing, since the tests comprise only a small
part of those files. But I have no strong opinion on this.

-David

Re: Gnus automatic builds

[Ted Zlatanov]

On Wed, 20 Apr 2011 20:50:27 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Please note that there's one little annoyance: You will get a single
DE> mail for all failed builds, meaning for every Emacs version. That means
DE> if you "really" break something, you'll get 5 mails. There's no way in
DE> buildbot to send just one mail which contains all the information.

I can live with that.

DE> OK, I chose lisp/tests.

DE> The buildbot will not run the NNTP test on new commits. I think the main
DE> part of this test is actually not the nntp testing, but more that it is
DE> an integration test which will fire up various parts of Gnus, so that
DE> broken require's etc. will hopefully pop up during startup.

That's great, thank you!

>> Could this work if we symlink registry.el and gnus-registry.el into the
>> tests directory?  Git supports symlinks and it would be a neat hack.

DE> I think this is a bit confusing, since the tests comprise only a small
DE> part of those files. But I have no strong opinion on this.

I meant if you chose to put "tests" at the top level, sorry.  The way
you have it now is great.

Ted

Re: Gnus automatic builds

[Adam Sjøgren]

On Wed, 20 Apr 2011 20:50:27 +0200, David wrote:

> Please note that there's one little annoyance: You will get a single
> mail for all failed builds, meaning for every Emacs version. That means
> if you "really" break something, you'll get 5 mails. There's no way in
> buildbot to send just one mail which contains all the information.

Would it be possible to add the build-number to the Subject-line? That
way it is easier to visually group the related reports.


  Best regards,

    Adam

-- 
 "We are like moths in a blizzard."                           Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Gnus automatic builds

[David Engster]

Adam Sjøgren writes:
> On Wed, 20 Apr 2011 20:50:27 +0200, David wrote:
>
>> Please note that there's one little annoyance: You will get a single
>> mail for all failed builds, meaning for every Emacs version. That means
>> if you "really" break something, you'll get 5 mails. There's no way in
>> buildbot to send just one mail which contains all the information.
>
> Would it be possible to add the build-number to the Subject-line? That
> way it is easier to visually group the related reports.

Yes, that's possible; the buildbot mails should now include the build
number (also the reason for the fail and the revision).

-David

Re: Gnus automatic builds

[Adam Sjøgren]

On Fri, 22 Apr 2011 23:21:26 +0200, David wrote:

> Yes, that's possible; the buildbot mails should now include the build
> number (also the reason for the fail and the revision).

Nice - thanks!


  Best regards,

    Adam

-- 
 "We are like moths in a blizzard."                           Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Gnus automatic builds

[Lars Magne Ingebrigtsen]

"Jason L Tibbitts III" <tibbs@math.uh.edu> writes:

> LMI> gnus-buildbot would be fine, I think.
>
> OK, that's done.

Great; thanks.

> LMI> So I'll add aliases for
> LMI> gnus-buildbot@lists.math.uh.edu
> LMI> gnus-buildbot-request@lists.math.uh.edu
>
> You can add gnus-buildbot-subscribe@lists.math.uh.edu as well, if you
> wish.

Done.

I'll now add the list to Gmane.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Gnus automatic builds

[David Engster]

Lars Magne Ingebrigtsen writes:
> "Jason L Tibbitts III" <tibbs@math.uh.edu> writes:
>
>> No problem at all; should I keep with the existing pattern and use
>> "ding-buildbot" or should I be all modern and call it "gnus-buildbot"?
>> (Obviously the @gnus.org aliases just need to forward to the right list
>> in either case, so this is purely cosmetic.)
>
> gnus-buildbot would be fine, I think.
>
> So I'll add aliases for
>
> gnus-buildbot@lists.math.uh.edu
> gnus-buildbot-request@lists.math.uh.edu
>
> on @gnus.org.

I now got

  gnus-buildbot@gnus.org
    SMTP error from remote mail server after RCPT TO:<gnus-buildbot@gnus.org>:
    host quimby.gnus.org [80.91.231.51]: 550 Unrouteable address

I'm using the math.uh.edu for now.

Also, the list doesn't seem to be available at Gmane?

-David

Re: Gnus automatic builds

[Ted Zlatanov]

On Wed, 20 Apr 2011 22:59:54 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Lars Magne Ingebrigtsen writes:
>> 
>> So I'll add aliases for
>> 
>> gnus-buildbot@lists.math.uh.edu
>> gnus-buildbot-request@lists.math.uh.edu
>> 
>> on @gnus.org.

DE> I now got

DE>   gnus-buildbot@gnus.org
DE>     SMTP error from remote mail server after RCPT TO:<gnus-buildbot@gnus.org>:
DE>     host quimby.gnus.org [80.91.231.51]: 550 Unrouteable address

DE> I'm using the math.uh.edu for now.

I can add those mail aliases later tonight if Lars doesn't get to it.

DE> Also, the list doesn't seem to be available at Gmane?

...and I'll try to set up the Gmane lists :)

Ted

Re: Gnus automatic builds

[Jason L Tibbitts III]

The gmane alias has been on the list for some time, although the only
other member is me.

 - J<

Re: Gnus automatic builds

[David Engster]

Jason L. Tibbitts, III writes:
> The gmane alias has been on the list for some time, although the only
> other member is me.

I can see it now, probably because some message have gone into it.

BTW, I've changed the mailing setup a bit. The people on the 'blamelist'
only get mails when a build fails the first time, not on repeated
failings; otherwise, people like Lars get mails although it was actually
Ted who broke it previously (Thanks Ted ;-) ).

The gnus.buildbot mailing list will get messages on each failed build,
just like it is now.

-David

Re: Gnus automatic builds

[Ted Zlatanov]

On Wed, 20 Apr 2011 16:03:12 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Wed, 20 Apr 2011 22:59:54 +0200 David Engster <deng@randomsample.de> wrote: 
DE> Lars Magne Ingebrigtsen writes:
>>> 
>>> So I'll add aliases for
>>> 
>>> gnus-buildbot@lists.math.uh.edu
>>> gnus-buildbot-request@lists.math.uh.edu
>>> 
>>> on @gnus.org.

DE> I now got

DE> gnus-buildbot@gnus.org
DE> SMTP error from remote mail server after RCPT TO:<gnus-buildbot@gnus.org>:
DE> host quimby.gnus.org [80.91.231.51]: 550 Unrouteable address

DE> I'm using the math.uh.edu for now.

TZ> I can add those mail aliases later tonight if Lars doesn't get to it.

It looks like Lars fixed whatever was broken, before I finally took a
look.  Let me and him know if you get any more SMTP errors from quimby.

Ted

Re: Gnus automatic builds

[David Engster]

David Engster writes:
> There are currently the following problems:
>
> - Xemacs 21.4 doesn't seem to support the (require 'foo nil t) syntax.
>
> - Xemacs 21.5 seems to have some problems with EIEIO :after functions.
>
> - Emacs 22: 
>  
>   In toplevel form:
>   message.el:1923:20:Error: `make-variable-buffer-local' should be called at toplevel

I fixed the XEmacs problems, but I don't know what to do about the
Emacs22 one. The warning is obviously bogus, since it is this expression
here that is causing it:

(unless (featurep 'xemacs)
  (make-variable-buffer-local 'message-options))

Any idea for a simple rewrite which will silence the compiler?

-David

Re: Gnus automatic builds

[David Engster]

David Engster writes:
> David Engster writes:
>> There are currently the following problems:
>>
>> - Xemacs 21.4 doesn't seem to support the (require 'foo nil t) syntax.
>
>>
>> - Xemacs 21.5 seems to have some problems with EIEIO :after functions.
>>
>> - Emacs 22: 
>>  
>>   In toplevel form:
>>   message.el:1923:20:Error: `make-variable-buffer-local' should be called at toplevel
>
> I fixed the XEmacs problems, but I don't know what to do about the
> Emacs22 one. The warning is obviously bogus, since it is this expression
> here that is causing it:
>
> (unless (featurep 'xemacs)
>   (make-variable-buffer-local 'message-options))
>
> Any idea for a simple rewrite which will silence the compiler?

I now simply removed that warning from Emacs22' bytecomp.el... so
everything's green now.

-David