unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Noisy byte compilation on master
Date: Mon, 02 Feb 2015 18:35:01 +0200	[thread overview]
Message-ID: <83h9v4gtl6.fsf@gnu.org> (raw)
In-Reply-To: <jwvsieogu3w.fsf-monnier+emacs@gnu.org>

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Mon, 02 Feb 2015 11:31:39 -0500
> 
> Not sure what to do about these: CEDET needs to work with older
> Emascsen, so we can't change the code to use the cl-defmethod thingies yet.
> But in the Emacs master code, `defmethod' is a compatibility layer which
> introduces notable inefficiencies, so we do want to mark those as obsolete.
> 
> Maybe we should keep those as "not quite obsolete yet" and only add the
> obsolescence warnings when we get to Emacs-26?  Or else, (define and)
> add extra annotations in those CEDET files to silence those warnings?

I don't have anything intelligent to say about this, except that the
amount of these messages is unbearably large.  Please find some way of
shutting them up.

> >   Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
> >   utf7.el: `mm-with-unibyte-current-buffer' is an obsolete macro (as of 25.1).
> 
> This one is also problematic: I've been trying to reduce the use of this
> macro for several years now, but I don't know the Gnus code enough to do
> much further progress.  Yet, this macro is sufficiently ill-defined that
> I think most of its uses probably suffer from latent bugs.  So spewing
> warnings during compilation sounds like the right thing to do (tho
> I see they're duplicated: one from the macro itself and one from the
> obsolescence warning, so we can drop the "Warning:" message).

Again, the problem is the sheer number of those.



  reply	other threads:[~2015-02-02 16:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-01 16:06 Noisy byte compilation on master Eli Zaretskii
2015-02-02 16:31 ` Stefan Monnier
2015-02-02 16:35   ` Eli Zaretskii [this message]
2015-02-02 18:01   ` Stephen Leake
2015-02-02 23:23     ` Stefan Monnier
2015-02-03  7:03       ` David Engster
2015-02-04 15:45         ` Stefan Monnier
2015-02-15 15:58           ` David Engster
2015-02-16  2:56             ` Stefan Monnier
2015-02-16 21:11               ` David Engster
2015-02-16 23:14                 ` Stefan Monnier
2015-02-17  6:31                   ` David Engster
2015-02-17 23:06                     ` Stefan Monnier
2015-02-18 17:53                       ` David Engster
2015-02-18 19:35                         ` Stefan Monnier
2015-02-18 19:51                           ` David Engster
2015-02-18 22:44                             ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83h9v4gtl6.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).