Re: igc: trying to chase a crash

[Jeff Walsh <fejfighter@gmail.com>]

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

Checking the build instructions once again for MPS it really strongly
suggests that `mps.c` is _included_ into your object format source file for
best performance/optimisation, this likely has issues for the cool/debug
configuration
at the very least, importing source into the emacs repo (similar to gnulib
) would allow some forms of LTO to take place.

FWIW I have been using a pgtk+nativecomp build occasionally synced to
master without issue for the last week or 2.
It feels faster, but my comparison is a main build on a different OS with
different computers, so it's not a reasonable comparison.

"start-up/init.el drag racing" does show mps to be reliably quicker for my
own config, but again not really a test.

On Wed, Nov 27, 2024 at 9:45 PM Andrea Corallo <acorallo@gnu.org> wrote:

> Vincenzo Pupillo <v.pupillo@gmail.com> writes:
>
> > In data mercoledì 27 novembre 2024 10:26:40 Ora standard dell’Europa
> centrale, Andrea Corallo ha scritto:
> >> Gregor Zattler <telegraph@gmx.net> writes:
> >>
> >> > Dear Andrea, Gerd, ...
> >> > * Andrea Corallo <acorallo@gnu.org> [2024-11-27; 03:52 -05]:
> >> >> Sure if it's of interest: my idea of few things that helped a lot
> native
> >> >> comp in gaining traction at time:
> >> >>
> >> >> - publishing simple blog posts summarizing and explaining the
> progresses
> >> >>   of the branch [1]
> >> >
> >> > Data Point: That got me interested.
> >> > There were progress updates, so I
> >> > visited the age rather often.
> >> >
> >> >> - native-comp being a feature branch, this clarified that the goal
> was
> >> >>   merging to master (IOW something which was probably likely to
> happen)
> >> >>   and that the branch was trackable by users.  That's why I suggested
> >> >>   more than once this solution in the past.
> >> >
> >> > That and the instructions on how to use
> >> > it motivated me to try out.
> >> >
> >> > In case of igc detailed build
> >> > instructions would be needed (for me at least).
> >>
> >> Yeah that's a great point!  For me building igc was not trivial.  MPS
> >> doesn't come with distros and the experience of compiling it from source
> >> wasn't great, the instructions in the codebase were conflicting plus I
> >> had to manually patch the codebase as OOB was not compiling.  Finally
> >> Emacs has to find it during compilation, otherwise I think it will
> >> silently revert to the standard GC even if configured for it.
> >>
> >> Maybe some of this is fixed now I'm not sure, but these are all hard
> >> barriers for users, clear and detailed instructions would be much needed
> >> for a more spread use of it.
> >
> > Wouldn't it perhaps be better to clone mps to savannah (with our
> patches) and add it as a sub-module to emacs?
> > Then initialize it if 'configure' is invoked with the --with-mps switch.
> > If it were to become such a fundamental piece of emacs perhaps it would
> be better to be more independent.
>
> If we decide MPS needs to be forked I think would be more convenient to
> have it directly inside the Emacs tree.
>
> BTW, I think if the user explicitly uses --with-mps the configuration
> should fail if MPS is not available.
>
>   Andrea
>
>

[-- Attachment #2: Type: text/html, Size: 4245 bytes --]