Speeding up native-comp progress

Speeding up native-comp progress

[Ethan Edwards]

Hey all,

I've started compiling my own emacs with my own ./configure flags,
instead of my GNU/Linux Distro's binary. I also have took notice 
of the feature/native-comp git branch and compiled it and I've 
been using it for about a week and have loved it.

On Reddit there's a post linking to the talk, and one of the comments on
said post is saying that it would likely be Emacs 28 before it was
merged, which is about 2 years away. I would like to know if there's
anything I could do to help speed up that process, for example Bug
Reports, or development, etc.

Thanks.
	Ethan

Re: Speeding up native-comp progress

[Andrea Corallo via Emacs development discussions.]

Ethan Edwards <ethancarteredwards@gmail.com> writes:

> Hey all,
>
> I've started compiling my own emacs with my own ./configure flags,
> instead of my GNU/Linux Distro's binary. I also have took notice
> of the feature/native-comp git branch and compiled it and I've
> been using it for about a week and have loved it.
>
> On Reddit there's a post linking to the talk, and one of the comments on
> said post is saying that it would likely be Emacs 28 before it was
> merged, which is about 2 years away. I would like to know if there's
> anything I could do to help speed up that process, for example Bug
> Reports, or development, etc.

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.

Needless to say suggestions and/or patches are greatly appretiated too.

Thanks

  Andrea

--
akrl@sdf.org

Re: Speeding up native-comp progress

[Ethan Edwards]

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?
> 
> 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.

Thanks
	Ethan
> 
> Thanks
> 
>   Andrea
> 
> --
> akrl@sdf.org

Re: Speeding up native-comp progress

[Andrea Corallo via Emacs development discussions.]

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