Re: pdumper on Solaris 10

[Eli Zaretskii]

> Date: Tue, 10 Dec 2024 15:23:45 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>, luangruo@yahoo.com, 
> ali_gnu2@emvision.com, emacs-devel@gnu.org
> 
> > > I thought that WIDE_EMACS_INT will remain supported in non-MPS
> > > (i.e. "old GC") builds even after the igc merge? Am I mistaken?
> > 
> > Probably, but who will want to give up igc to get back WIDE_EMACS_INT
> > (if indeed they are incompatible, which seems to be in disagreement)?
> 
> It's !USE_LSB_TAG that's incompatible with MPS, not WIDE_EMACS_INT per se. I 
> don't think anyone suggested that there is a fundamental problem if we force 
> USE_LSB_TAG to 1 and enable WIDE_EMACS_INT.

That's not what Gerd says, AFAIU.  But if you are right, then how
about making the WIDE_EMACS_INT configuration on the igc branch use
USE_LSB_TAG in the HAVE_MPS code branch?  I can volunteer to test such
a build, if that would help.

> > Maybe so, but why is such a long wait a problem? GC works, and
> > works well. There are no pressing problems there, and we've lived
> > with it for many years virtually without changes. What's the urge to
> > make modifications there now, especially when there are chances we
> > will be dropping this GC at some point?
> 
> The old !USE_LSB_TAG code, which is broken, interferes with GC development, 
> both MPS and non-MPS.

That work is on the igc branch.  My objection is against doing that on
master and/or with the "old" GC code.  In the HAVE_MPS branch of the
code, all the arguments I brought up against removing !USE_LSB_TAG are
null and void, and I therefore have no objections to doing that in
those parts of the code.

> > IMO, our main task here is to develop the application levels of Emacs,
> > and infrastructure needed to enable such developments. We should only
> > invest efforts in stuff like GC and other basics if we see significant
> > issues, or could envision significant performance gains. There are no
> > such issues or gains here, AFAIU. So diverting our humble resources
> > to such jobs is a mistake, IMO.
> 
> Given how many GC developers we have already "lost", simplifying the GC code 
> even a little so people can work with it is worth it, IMHO. And encouraging 
> someone to invest resources into fixing a code path that will never again be 
> used is a much greater mistake.

Our perspectives are very different, so let's agree to disagree on
this.