Re: Change in bytecomp.el breaks Gnus

Re: Change in bytecomp.el breaks Gnus

[Katsumi Yamaoka]

>>>>>> In <877jouepy8.fsf@telia.com> Henrik Enberg wrote:

>> Version 2.157 of bytecomp.el causes Gnus to fail with the following
>> backtrace: 

>> Debugger entered--Lisp error: (void-function t)
>>   t("nnml+sent:news" (1 . 888))
>>   gnus-activate-group("nnml+sent:news" scan)
>>   gnus-get-unread-articles(nil)
>>   gnus-setup-news(nil nil nil)
> [...]
>>   gnus-1(nil nil nil)
>>   gnus()

>>>>> In <b9yd5ymkq11.fsf@jpl.org> Katsumi Yamaoka wrote:

> I got the same error last night (in Japan) and noticed removing
> gnus-start.elc seems to help.  I don't think it's a Gnus' fault.
> Now I'm using the version 2.156 and rebuilt Emacs.

I found that the problem is caused if a Lisp source contains the
following forms:

(eval-when-compile
  (defsubst foo ()))

(defun bar () (foo))

Where `foo' is surrounded by `eval-when-compile' since there is
no necessity of using it at run-time.  In that case, the
function definition for `foo' is registered into the
`byte-compile-function-environment' variable as `(foo . t)', and
the byte compiler complains as follows:

In bar:
foobar.el:4:8:Warning: attempt to inline `t' before it was defined
foobar.el:4:8:Warning: `t' called as a function

In end of data:
foobar.el:4:1:Warning: the function `t' is not known to be defined.

I used this technique in many places of some packages including
Gnus in oder to reduce useless function symbols at run-time.  If
such a technique is forbidden, I will get into a plight.  Could
you also support the `(eval-when-compile (defsubst ...' forms?

Thanks in advance.

Re: Change in bytecomp.el breaks Gnus

[Katsumi Yamaoka]

>>>>> In <b9ysm7gq1dm.fsf@jpl.org> Katsumi Yamaoka wrote:

> I found that the problem is caused if a Lisp source contains the
> following forms:

> (eval-when-compile
>   (defsubst foo ()))

> (defun bar () (foo))

Although I'm not sure of it, the following patch seems to solve
the problem.

*** bytecomp.el~	Tue Nov  9 21:53:14 2004
--- bytecomp.el	Thu Nov 11 11:17:58 2004
***************
*** 3720,3726 ****
    (if (and (consp (cdr form)) (consp (nth 1 form))
  	   (eq (car (nth 1 form)) 'quote)
  	   (consp (cdr (nth 1 form)))
! 	   (symbolp (nth 1 (nth 1 form))))
        (let ((constant
  	     (and (consp (nthcdr 2 form))
  		  (consp (nth 2 form))
--- 3720,3727 ----
    (if (and (consp (cdr form)) (consp (nth 1 form))
  	   (eq (car (nth 1 form)) 'quote)
  	   (consp (cdr (nth 1 form)))
! 	   (symbolp (nth 1 (nth 1 form)))
! 	   (not (byte-code-function-p (nth 2 form))))
        (let ((constant
  	     (and (consp (nthcdr 2 form))
  		  (consp (nth 2 form))

Re: Change in bytecomp.el breaks Gnus

[Luc Teirlinck]

Katsumi Yamaoka wrote:

   Although I'm not sure of it, the following patch seems to solve
   the problem.

Your patch does not seem to solve a related problem I reported earlier
on emacs-devel, so it probably is not a complete solution:

   Changes in byte compilation which must be less than a day old, have
   strange effects.  `winner' is no longer usable when winner.elc is
   used, but still seems to work fine when winner.el is used.

   After `emacs -q' I get the following ielm run:

   *** Welcome to IELM ***  Type (describe-mode) for help.
   ELISP> (load "winner")
   t
   ELISP> (winner-sorted-window-list)
   *** Eval error ***  Symbol's function definition is void: t
   ELISP> (load "winner.el")
   t
   ELISP> (winner-sorted-window-list)
   (#<window 3 on *ielm*>)

   ELISP> 

   Byte compiling winner.el produces:

   Compiling file /home/teirllm/emacscvsdir/emacs/lisp/winner.el at Tue
   Nov  9 08:32:15 2004
   Entering directory `/home/teirllm/emacscvsdir/emacs/lisp/'
   winner.el:52:14:Warning: Function `gensym' from cl package called at
   runtime
   winner.el:56:10:Warning: Function `gensym' from cl package called at
   runtime

   In winner-sorted-window-list:
   winner.el:125:10:Warning: attempt to inline `t' before it was defined
   winner.el:124:4:Warning: `t' called as a function

   In winner-make-point-alist:
   winner.el:284:33:Warning: attempt to inline `t' before it was defined
   winner.el:285:44:Warning: `t' called as a function

   In end of data:
   winner.el:488:1:Warning: the function `t' is not known to be defined.

   Comments:

   The first two warnings are probably legitimate.

   The function `t' stuff appears to be a bug in byte compilation.

Re: Change in bytecomp.el breaks Gnus

[Stefan]

> Your patch does not seem to solve a related problem I reported earlier
> on emacs-devel, so it probably is not a complete solution:

>    Changes in byte compilation which must be less than a day old, have
>    strange effects.  `winner' is no longer usable when winner.elc is
>    used, but still seems to work fine when winner.el is used.

>    After `emacs -q' I get the following ielm run:

>    *** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (load "winner")
>    t
ELISP> (winner-sorted-window-list)
>    *** Eval error ***  Symbol's function definition is void: t
ELISP> (load "winner.el")
>    t
ELISP> (winner-sorted-window-list)
>    (#<window 3 on *ielm*>)

Hmm... the problem seems to be related to the fact that some `defsubst's are
first turned into `defalias' but that the new defalias code gets surprised
when it encounters those `defalias'es.

I've installed the patch below which I think does The Right Thing(tm).
But the distinction between top-level and non-top-level forms as well as
several aspects of the byte-compiler are still a bit fuzzy in my mind.

I think the patch not only fixes the problem but also fixes an older
"problem" which is that code such as:

   (defun toto ()
     (foobsfg x)
     (if toto
         (defalias 'foobsfg 'y)))

did not complain about calling an unknown function `foobsfg'.
Can someone who's already played a bit with bytecomp.el do a reality check?


        Stefan


--- bytecomp.el	09 Nov 2004 09:27:47 -0500	2.157
+++ bytecomp.el	11 Nov 2004 16:35:49 -0500	
@@ -3614,7 +3613,6 @@
 (byte-defop-compiler-1 defconst byte-compile-defvar)
 (byte-defop-compiler-1 autoload)
 (byte-defop-compiler-1 lambda byte-compile-lambda-form)
-(byte-defop-compiler-1 defalias)
 
 (defun byte-compile-defun (form)
   ;; This is not used for file-level defuns with doc strings.
@@ -3716,7 +3714,8 @@
   (error "`lambda' used as function name is invalid"))
 
 ;; Compile normally, but deal with warnings for the function being defined.
-(defun byte-compile-defalias (form)
+(put 'defalias 'byte-hunk-handler 'byte-compile-file-form-defalias)
+(defun byte-compile-file-form-defalias (form)
   (if (and (consp (cdr form)) (consp (nth 1 form))
 	   (eq (car (nth 1 form)) 'quote)
 	   (consp (cdr (nth 1 form)))

Re: Change in bytecomp.el breaks Gnus

[Luc Teirlinck]

Stefan Monnier wrote:

   I've installed the patch below which I think does The Right Thing(tm).

Do you mean that you are going to install it, or that you did install it?

I do not see it on Savannah.

Sincerely,

Luc.

Re: Change in bytecomp.el breaks Gnus

[Luc Teirlinck]

From my last message:

   Do you mean that you are going to install it, or that you did install it?

   I do not see it on Savannah.

I saw it now.

Sincerely,

Luc.

Re: Change in bytecomp.el breaks Gnus

[Katsumi Yamaoka]

>>>>> In <m17jos12x6.fsf-monnier+emacs@gnu.org> Stefan wrote:

> Hmm... the problem seems to be related to the fact that some `defsubst's are
> first turned into `defalias' but that the new defalias code gets surprised
> when it encounters those `defalias'es.

That looks to be the right interpretation, but...

[...]

> Can someone who's already played a bit with bytecomp.el do a reality check?

I rebuilt Emacs and found the following case causes the `t' error.

(defalias 'foo (lambda (s) (message "%s" s)))

(defun bar (s) (inline (foo s)))

Re: Change in bytecomp.el breaks Gnus

[Stefan Monnier]

> I rebuilt Emacs and found the following case causes the `t' error.

> (defalias 'foo (lambda (s) (message "%s" s)))
> (defun bar (s) (inline (foo s)))

Hmm...indeed.  I think I've fixed it now,


        Stefan

Re: Change in bytecomp.el breaks Gnus

[Katsumi Yamaoka]

>>>>> In <871xezbtyh.fsf-monnier+emacs@gnu.org> Stefan Monnier wrote:

>> I rebuilt Emacs and found the following case causes the `t' error.

>> (defalias 'foo (lambda (s) (message "%s" s)))
>> (defun bar (s) (inline (foo s)))

> Hmm...indeed.  I think I've fixed it now,

It does the trick.  Thanks.  Though it may not be a real
problem, the compiler warns with the following forms:

(if (fboundp 'message) (defalias 'foo 'message))
(defun bar () (foo "Hello World"))

In end of data:
test5.el:2:1:Warning: the function `foo' is not known to be defined.

Re: Change in bytecomp.el breaks Gnus

[Stefan]

> It does the trick.  Thanks.  Though it may not be a real
> problem, the compiler warns with the following forms:

> (if (fboundp 'message) (defalias 'foo 'message))
> (defun bar () (foo "Hello World"))

> In end of data:
> test5.el:2:1:Warning: the function `foo' is not known to be defined.

That's normal and correct.
If `message' is not bound, then `foo' won't be bound either, so `foo' is not
guaranteed to be defined.


        Stefan

Re: Change in bytecomp.el breaks Gnus

[Katsumi Yamaoka]

>>>>> In <m11xex1hhh.fsf-monnier+emacs@gnu.org> 
>>>>>	Stefan <monnier@iro.umontreal.ca> wrote:

>> (if (fboundp 'message) (defalias 'foo 'message))
>> (defun bar () (foo "Hello World"))

>> In end of data:
>> test5.el:2:1:Warning: the function `foo' is not known to be defined.

> That's normal and correct.
> If `message' is not bound, then `foo' won't be bound either, so `foo' is not
> guaranteed to be defined.

Is also the following case normal and correct?

(if (fboundp 'message)
    (defalias 'foo 'message)
  (defalias 'foo 'ignore))
(defun bar () (foo "Hello World"))

In end of data:
test6.el:4:1:Warning: the function `foo' is not known to be defined.

If it is normal, we will have to use `eval-and-compile' to
surround similar `defalias' forms in many places.

Re: Change in bytecomp.el breaks Gnus

[Stefan]

> (if (fboundp 'message)
>     (defalias 'foo 'message)
>   (defalias 'foo 'ignore))

  (defalias 'foo
    (if (fboundp 'message) 'message 'ignore))

> If it is normal, we will have to use `eval-and-compile' to
> surround similar `defalias' forms in many places.

Yuck.  Why do people feel like it's better to use ugly hacks than to get
a few warnings ?


        Stefan

Re: Change in bytecomp.el breaks Gnus

[Katsumi Yamaoka]

>>>>> In <m1lld5xb07.fsf-monnier+emacs@gnu.org> 
>>>>>	Stefan <monnier@iro.umontreal.ca> wrote:

>> (if (fboundp 'message)
>>     (defalias 'foo 'message)
>>   (defalias 'foo 'ignore))

>   (defalias 'foo
>     (if (fboundp 'message) 'message 'ignore))

That's okay.

>> If it is normal, we will have to use `eval-and-compile' to
>> surround similar `defalias' forms in many places.

> Yuck.  Why do people feel like it's better to use ugly hacks than to get
> a few warnings ?

Because it will grow up to be not a few numbers of warnings if
we don't take any countermeasure.  It makes it hard to find
important messages from such chaos.  Gnus was made not to issue
such negligible warnings until now.

Re: Change in bytecomp.el breaks Gnus

[Stefan]

>>> (if (fboundp 'message)
>>>     (defalias 'foo 'message)
>>>   (defalias 'foo 'ignore))

>> (defalias 'foo
>> (if (fboundp 'message) 'message 'ignore))

> That's okay.

I'm not sure you realize that my code is not just shorter but it gets you
rid of the warning (if you use a recent enough version of Emacs-CVS).


        Stefan

Re: Change in bytecomp.el breaks Gnus

[Katsumi Yamaoka]

>>>>> In <m1y8h5vsy6.fsf-monnier+emacs@gnu.org>
>>>>>	Stefan <monnier@iro.umontreal.ca> wrote:

> I'm not sure you realize that my code is not just shorter but it gets you
> rid of the warning (if you use a recent enough version of Emacs-CVS).

Yes, I know we get a lot of warnings to Gnus modules while
bootstrapping Emacs CVS.  Even though there's a serious problem,
it will be buried into them.  OTOH, Gnus CVS filters those
negligible warnings carefully using dgnushack.el and lpath.el.
It is useful to finding something wrong when performing `make'.

>>> (defalias 'foo
>>> (if (fboundp 'message) 'message 'ignore))

>> That's okay.

That I wrote `okay' means that we will have to modify them in
Gnus if it is really necessity (i.e., the case where it is
unable to silence bytecomp).

Re: Change in bytecomp.el breaks Gnus

[Luc Teirlinck]

Katsumi Yamaoka wrote:

   Because it will grow up to be not a few numbers of warnings if
   we don't take any countermeasure.  It makes it hard to find
   important messages from such chaos.

In Emacs, the situation is already hopeless.  I redirected make
bootstrap's error messages to a file.  That file is 8155 lines long.
Not all these lines are compiler warnings but a lot of them are.

`(elisp)Coding Conventions' says to avoid compiler warnings, but many
authors ignore this.  In fact, it seems obvious that many authors not
only do not worry about silencing compiler warnings, they do not even
look at them.  Many authors seem to believe that _all_ compiler
warnings are bogus anyway and act accordingly.  In fact, I have seen
people silence compiler warnings them without even checking whether
they are bogus or not.

Most warnings are of the "function may not be defined at runtime" or
"assignment to free variable" type.  There are such an enormous amount
of them that we have, practically speaking, no choice but to assume
that they are bogus until proven non-bogus.

Most "function from cl package called at runtime" seem to involve
situations where loading the .el file loads cl, but loading the .elc
does not.  I believe that this is acceptable, in which case most of
these warnings are bogus.

Most "obsolete variable" warnings are not bogus, but fixing them does
not seem urgent.

Most of the new "designed for interactive use" warnings are probably
not bogus, but they have to be looked at individually.

Every single "assigning to a constant" warning seemed to be non-bogus.
These are actually real non-trivial bugs, because reloading the file
will erase all changes made in the Emacs session.  I will discuss
these separately.

Sincerely,

Luc.

Re: Change in bytecomp.el breaks Gnus

[Stefan Monnier]

> In Emacs, the situation is already hopeless.  I redirected make
> bootstrap's error messages to a file.  That file is 8155 lines long.
> Not all these lines are compiler warnings but a lot of them are.

Elisp compilation warnings are basically useless to anyone else than the
author.  To fix this part is currently hopeless.
To the elisp author, OTOH they can be very handy if she chooses to pay
attention to them.

> `(elisp)Coding Conventions' says to avoid compiler warnings, but many
> authors ignore this.

I think there's a whole range of cases:
1 - the author never byte compiles her files.
2 - she byte-compiles occasionally but just ignores all the warnings.
3 - she'd like to pay attention to the warnings, but there's so many that
    she's discouraged before even starting (anybody who's taken a look at
    Calc knows what I'm talking about).
4 - she'd pays attention to the warnings but several of them can't be fixed
    without ugly workarounds.  For vars the (defvar foo) form is a godsent,
    but for functions, there's nothing equivalent (yet).  The recently
    proposed (defun foo) form would be extremely helpful.
5 - ...

> Most "function from cl package called at runtime" seem to involve
> situations where loading the .el file loads cl, but loading the .elc
> does not.  I believe that this is acceptable, in which case most of
> these warnings are bogus.

Many of those warnings are bogus.  One of the most common case of "bogus"
is when a CL function is used in a macro and this macro is only used inside
the file, so it's only used during byte-compilation and never at runtime.
The warning is "bogus" is the sense that it's harmless but it is real in the
sense that loading the resulting .elc file will define a macro which will
burp if you try to use it without first loading CL.


        Stefan

Re: Change in bytecomp.el breaks Gnus

[Richard Stallman]

    > Most "function from cl package called at runtime" seem to involve
    > situations where loading the .el file loads cl, but loading the .elc
    > does not.

I am not sure how that would happen--would you please give one example?

		 I believe that this is acceptable, in which case most of
    > these warnings are bogus.

    Many of those warnings are bogus.

Perhaps the ones that remain are bogus, but that's because I fixed
many real ones that used to occur.

      One of the most common case of "bogus"
    is when a CL function is used in a macro and this macro is only used inside
    the file, so it's only used during byte-compilation and never at runtime.

I think the right fix for that is with-no-warnings.
However, it could be that the code that generates this warning
can be improved.

Re: Change in bytecomp.el breaks Gnus

[Stefan Monnier]

>     Many of those warnings are bogus.
> Perhaps the ones that remain are bogus, but that's because I fixed
> many real ones that used to occur.

Indeed.  I find the warning very useful.

>     One of the most common case of "bogus" is when a CL function is used
>     in a macro and this macro is only used inside the file, so it's only
>     used during byte-compilation and never at runtime.

> I think the right fix for that is with-no-warnings.  However, it could be
> that the code that generates this warning can be improved.

Yes, I have no good idea how to improve it, but hopefully an idea will show
up at some point.  In the mean time with-no-warning is the best we have.


        Stefan

Re: Change in bytecomp.el breaks Gnus

[Miles Bader]

On Mon, Nov 15, 2004 at 10:36:52AM -0500, Stefan Monnier wrote:
> >     One of the most common case of "bogus" is when a CL function is used
> >     in a macro and this macro is only used inside the file, so it's only
> >     used during byte-compilation and never at runtime.
> 
> > I think the right fix for that is with-no-warnings.  However, it could be
> > that the code that generates this warning can be improved.
> 
> Yes, I have no good idea how to improve it, but hopefully an idea will show
> up at some point.  In the mean time with-no-warning is the best we have.

Couldn't such macros be wrapped in `eval-when-compile' (I forgot the exact
name, but ...)?

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: Change in bytecomp.el breaks Gnus

[Stefan Monnier]

> Couldn't such macros be wrapped in `eval-when-compile' (I forgot the exact
> name, but ...)?

Some are wrapped.  Some could be.  But those like the setf methods generated
by `defstruct' can't.


        Stefan

Re: Change in bytecomp.el breaks Gnus

[Miles Bader]

On Mon, Nov 15, 2004 at 06:28:58PM -0500, Stefan Monnier wrote:
> > Couldn't such macros be wrapped in `eval-when-compile' (I forgot the exact
> > name, but ...)?
> 
> Some are wrapped.  Some could be.  But those like the setf methods generated
> by `defstruct' can't.

Hmmm.  Well, I'd say just rewrite defstruct to not use cl functions (I'm sure
cl fans will bitch about how horrible that is, but cl is a part of emacs, it
should cater to Emacs' idiosyncrasies where possible).

Anyway, wouldn't such wrapping address at least majority of such cases?  The
reason I'm going on about this is that I think it's a much more
understandable way of fixing such warnings (in that it directly shows what's
going on) than using `with-no-warnings' (which is a pretty blunt tool).

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Change in bytecomp.el breaks Gnus

[Stefan Monnier]

> Hmmm.  Well, I'd say just rewrite defstruct to not use cl functions.

That might be an option, indeed.

> Anyway, wouldn't such wrapping address at least majority of such cases?  The
> reason I'm going on about this is that I think it's a much more
> understandable way of fixing such warnings (in that it directly shows what's
> going on) than using `with-no-warnings' (which is a pretty blunt tool).

Agreed.


        Stefan

Re: Change in bytecomp.el breaks Gnus

[Luc Teirlinck]

Richard Stallman wrote:

       > Most "function from cl package called at runtime" seem to involve
       > situations where loading the .el file loads cl, but loading the .elc
       > does not.

Do `emacs -q'.

ELISP> (load "winner")
t
ELISP> (featurep 'cl)
nil
ELISP> (load "winner.el")
t
ELISP> (featurep 'cl)
t

That will always happen when the file contains:

(eval-when-compile
  (require 'cl))

because the `(require cl)' is executed when the source file is loaded,
as it should be.

However, that was _not_ the cause of the compiler warning, as I
mistakenly thought.

Here is the compiler warning:

  Compiling file /home/teirllm/emacscvsdir/emacs/lisp/winner.el at Mon
  Nov 15 17:27:42 2004
  Entering directory `/home/teirllm/emacscvsdir/emacs/lisp/'
  winner.el:53:10:Warning: Function `gensym' from cl package called at runtime

This warning is bogus.  `gensym' can indeed be called at runtime, but
only if `setf' is called first, which requires cl to be loaded anyway.

Adding `with-no-warnings' as below definitely gets rid of the winner
warning.  I do not know whether better solutions currently being
discussed apply to this case, nor when such better solutions would be
available.

(with-no-warnings
 (defsetf winner-active-region () (store)
   (if (fboundp 'zmacs-activate-region)
       `(if ,store (zmacs-activate-region)
         (zmacs-deactivate-region))
     `(setq mark-active ,store))))

One better, currently available, solution might be to put the
`with-no-warnings' around the call to `gensym' in `defsetf'.  That would
seem to get rid of all similar bogus warnings.

Sincerely,

Luc.

Re: Change in bytecomp.el breaks Gnus

[Nick Roberts]

 > Here is the compiler warning:
 > 
 >   Compiling file /home/teirllm/emacscvsdir/emacs/lisp/winner.el at Mon
 >   Nov 15 17:27:42 2004
 >   Entering directory `/home/teirllm/emacscvsdir/emacs/lisp/'
 >   winner.el:53:10:Warning: Function `gensym' from cl package called at runtime
 > 
 > This warning is bogus.  `gensym' can indeed be called at runtime, but
 > only if `setf' is called first, which requires cl to be loaded anyway.

I don't think this is bogus. setf is a macro and is not needed at runtime
because it has been expanded and compiled into winner.elc (I think you might
mean defsetf but that is also a macro, so the same applies). gensym, on the
other hand, is a function, so Emacs will need to know where to find it
when it is called.

The warning is presumably there to help the person writing the code decide
if cl needs to be loaded. Without it, it may be the user who discovers the
problem at runtime. Once the the coder decides its not a problem, then
putting with-no-warnings around the call would, indeed, appear to be the
right thing to do.

Nick

Re: Change in bytecomp.el breaks Gnus

[Luc Teirlinck]

Nick Robert wrote:

    > This warning is bogus.  `gensym' can indeed be called at runtime, but
    > only if `setf' is called first, which requires cl to be loaded anyway.

   I don't think this is bogus. setf is a macro and is not needed at runtime
   because it has been expanded and compiled into winner.elc (I think you might
   mean defsetf but that is also a macro, so the same applies). gensym, on the
   other hand, is a function, so Emacs will need to know where to find it
   when it is called.

I do not believe so.  The only purpose of defsetf is to tell setf what
to do.  The expansion of the defsetf macro will only be called if setf
is called first, which requires cl to be loaded.  _No_ cl function
used inside the defsetf expansion will ever load cl, when called from
there.

Sincerely,

Luc.

Re: Change in bytecomp.el breaks Gnus

[Luc Teirlinck]

>From my previous message:

   _No_ cl function used inside the defsetf expansion will ever load
   cl, when called from there.

I have to correct this:

(defmacro defsetf (func arg1 &rest args)

Calls to `gensym' in args definitely could load cl at runtime.

But not the code in defsetf that is only used to compute the `setf'
expansion.  This applies to the involved calls to `gensym'.

Sincerely,

Luc.

Re: Change in bytecomp.el breaks Gnus

[Richard Stallman]

    Most warnings are of the "function may not be defined at runtime" or
    "assignment to free variable" type.  There are such an enormous amount
    of them that we have, practically speaking, no choice but to assume
    that they are bogus until proven non-bogus.

I have been eliminating the "free variable" warnings from many files
over the past couple of years.  I have not tried to to so in calc
or rmail, because calc is big and I don't know it, and rmail is being
to a large extent rewritten.

Would others like to carry on with this work?