From: Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>
To: Ethan Edwards <ethancarteredwards@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Speeding up native-comp progress
Date: Sun, 16 Aug 2020 15:32:53 +0000 [thread overview]
Message-ID: <xjf8seea9ne.fsf@sdf.org> (raw)
In-Reply-To: <20200816144903.vdjpffdzkdipcwt7@archlaptop.localdomain> (Ethan Edwards's message of "Sun, 16 Aug 2020 10:49:03 -0400")
Ethan Edwards <ethancarteredwards@gmail.com> writes:
> On Sun, Aug 16, 2020 at 02:06:39PM +0000, Andrea Corallo wrote:
>> Hi Ethan,
>>
>> thanks for the mail, is great to ear you enjoy using the branch.
>>
>> On my side I think precise bug reports are _extremely_ important. For
>> precise I especially mean providing a clear recipe to reproduce it
>> starting from scratch. Precise bug reports saves me a lot of time and
>> greatly help improving the usability of the branch for all users.
> Sure thing, is the bug-gnu-emacs [at] gnu.org the correct mailing list
> for these?
Yes M-x report-emacs-bug is the right way to go. We tipically add
[feature/native-comp] in the subject to recognize these, Ex:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42761
>>
>> Needless to say suggestions and/or patches are greatly appretiated too.
> Great, is there a TODO file or anything like that would lead me in a
> direction to start? The ./etc/TODO file is exactly the same in both
> master and native-comp repo.
No unfortunatelly there's no TODO. On my side I'm going to push a
branch reworking the eln placement and compilation trigger mechanism.
This is indirectly open the door for solving once for all the primitive
functions advice issue (probably the cause of some bug still around).
Other than that I've a nuimber of ideas on the performance subject but I
believe the priority should definitely go on tackling and cleaning the
open bugs.
An help in that area can come on trying to reproduce and reduce
analysing reported bug. Often a generic symptom is reported but
investigation is required to find what is the original discrepancy with
the vanilla implementation. This bug is good example of that:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42265
That said any input or suggestion based on the user experience or
improvements (including documentation patches) is very welcome.
Thanks!
Andrea
prev parent reply other threads:[~2020-08-16 15:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-16 8:50 Speeding up native-comp progress Ethan Edwards
2020-08-16 14:06 ` Andrea Corallo via Emacs development discussions.
2020-08-16 14:49 ` Ethan Edwards
2020-08-16 15:32 ` Andrea Corallo via Emacs development discussions. [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xjf8seea9ne.fsf@sdf.org \
--to=emacs-devel@gnu.org \
--cc=akrl@sdf.org \
--cc=ethancarteredwards@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.