From: Eli Zaretskii <eliz@gnu.org>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: eller.helmut@gmail.com, emacs-devel@gnu.org
Subject: Re: Building the igc branch on MS-Windows
Date: Fri, 26 Apr 2024 18:11:46 +0300 [thread overview]
Message-ID: <86wmokxiod.fsf@gnu.org> (raw)
In-Reply-To: <m2h6fomgbh.fsf@pro2.fritz.box> (message from Gerd Möllmann on Fri, 26 Apr 2024 14:58:10 +0200)
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com, emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 14:58:10 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> I've meanwhile pushed something that handles the use of PVEC_OTHER in
> >> modules. Nothing done for the scroll_bar struct in w32. Caution: I
> >> remved the assert.
> >
> > Why did you do that? What possible useful purpose can that serve? If
> > the assertion gets in the way of what you are looking at, you can
> > always remove it locally, can't you?
>
> Because PVEC_OTHER is handled fine now, except whatever w32 does in
> addition or maybe instead
Then maybe the assertion should be w32-only (if only w32 uses
PVEC_OTHER; I thought Helmut said he saw the same problem on
GNU/Linux?). But removing it completely is not TRT, IMO. We already
have quite a lot of code which was disabled under HAVE_MPS, and at
least some of that looks like workarounds for problems that got "low
priority". I'm not sure this is a good way of making progress here,
especially since some of those #ifdef's could potentially cause
problems elsewhere.
I think we should methodically try to solve every problem we bump
into, without any priorities. Priorities are fine when we want to
make a POC, to see if this is workable. I think we are way past that
point, so leaving unsolved problems is no longer a useful methodology.
> (has it modules?)
Of course. In a Windows build I have:
load-suffixes
=> (".dll" ".elc" ".el")
> >> I'd say that xpostmortem wouldn't make sense during normal debugging,
> >> when MPS is not dead in the water. I don't think one can get out of that
> >> state again.
> >
> > I don't follow. How is debugging problems with GC different from
> > "normal debugging"?
>
> Imagine running Emacs under GDB and stopping at some breakpoint to debug
> whatever. You want to xbacktrace and then proceed with continue. That
> xbacktrace should not put MPS in post-mortem state.
>
> > In any case, I asked about the downsides of calling igc_postmorten,
> > which I think is crucial to understand for making this decision. If
> > there are no significant downsides, then doing so is a net win, no?
>
> It's post-mortem = after death. MPS is then not in a usable state anymore.
It should have been obvious that I meant to do that after a crash. I
admit I didn't say that explicitly, but I thought it was obvious.
Sorry.
next prev parent reply other threads:[~2024-04-26 15:11 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 15:06 Building the igc branch on MS-Windows Eli Zaretskii
2024-04-24 15:20 ` Gerd Möllmann
2024-04-24 16:07 ` Eli Zaretskii
2024-04-24 16:48 ` Gerd Möllmann
2024-04-24 16:59 ` Gerd Möllmann
2024-04-24 19:09 ` Eli Zaretskii
2024-04-24 19:44 ` Gerd Möllmann
2024-04-25 5:38 ` Eli Zaretskii
2024-04-25 6:17 ` Gerd Möllmann
2024-04-25 4:54 ` Helmut Eller
2024-04-25 5:30 ` Eli Zaretskii
2024-04-25 6:38 ` Helmut Eller
2024-04-25 7:39 ` Gerd Möllmann
2024-04-25 10:34 ` Eli Zaretskii
2024-04-25 11:09 ` Eli Zaretskii
2024-04-25 11:16 ` Eli Zaretskii
2024-04-25 11:59 ` Gerd Möllmann
2024-04-25 13:22 ` Eli Zaretskii
2024-04-25 13:29 ` Gerd Möllmann
2024-04-25 11:55 ` Gerd Möllmann
2024-04-25 13:29 ` Eli Zaretskii
2024-04-25 14:00 ` Gerd Möllmann
2024-04-25 14:34 ` Eli Zaretskii
2024-04-25 14:40 ` Gerd Möllmann
2024-04-25 12:35 ` Helmut Eller
2024-04-25 12:40 ` Gerd Möllmann
2024-04-26 7:18 ` Helmut Eller
2024-04-26 7:38 ` Gerd Möllmann
2024-04-26 7:41 ` Eli Zaretskii
2024-04-26 8:11 ` Gerd Möllmann
2024-04-26 9:13 ` Helmut Eller
2024-04-26 9:31 ` Gerd Möllmann
2024-04-26 10:55 ` Eli Zaretskii
2024-04-26 11:27 ` Po Lu
2024-04-26 13:04 ` Gerd Möllmann
2024-04-26 13:42 ` Po Lu
2024-04-26 13:46 ` Gerd Möllmann
2024-04-26 14:35 ` Gerd Möllmann
2024-04-26 10:35 ` Eli Zaretskii
2024-04-26 10:56 ` Gerd Möllmann
2024-04-26 11:25 ` Eli Zaretskii
2024-04-26 11:38 ` Po Lu
2024-04-26 12:58 ` Gerd Möllmann
2024-04-26 14:49 ` Eli Zaretskii
2024-04-26 14:53 ` Gerd Möllmann
2024-04-27 0:21 ` Po Lu
2024-04-27 6:13 ` Eli Zaretskii
2024-04-27 6:48 ` Gerd Möllmann
2024-04-27 7:13 ` Eli Zaretskii
2024-04-26 12:58 ` Gerd Möllmann
2024-04-26 15:11 ` Eli Zaretskii [this message]
2024-04-26 15:27 ` Gerd Möllmann
2024-04-26 11:32 ` Eli Zaretskii
2024-04-26 13:09 ` Gerd Möllmann
2024-04-26 13:12 ` Gerd Möllmann
2024-04-26 15:01 ` Helmut Eller
2024-04-26 15:30 ` Gerd Möllmann
2024-04-26 15:39 ` Eli Zaretskii
2024-04-26 17:03 ` Gerd Möllmann
2024-04-26 18:24 ` Helmut Eller
2024-04-26 18:37 ` Gerd Möllmann
2024-04-26 16:57 ` Gerd Möllmann
2024-04-26 18:11 ` Helmut Eller
2024-04-26 18:30 ` Gerd Möllmann
2024-04-26 20:45 ` Helmut Eller
2024-04-27 4:22 ` Gerd Möllmann
2024-04-27 5:18 ` Ihor Radchenko
2024-04-27 5:26 ` Gerd Möllmann
2024-04-27 5:54 ` Ihor Radchenko
2024-04-27 6:07 ` Gerd Möllmann
2024-04-27 6:31 ` Gerd Möllmann
2024-04-27 6:22 ` Eli Zaretskii
2024-04-27 6:29 ` Ihor Radchenko
2024-04-27 7:11 ` Eli Zaretskii
2024-04-27 7:40 ` Ihor Radchenko
2024-04-27 6:45 ` Gerd Möllmann
2024-04-27 6:11 ` Eli Zaretskii
2024-04-27 6:58 ` Eli Zaretskii
2024-04-27 7:17 ` Eli Zaretskii
2024-04-27 8:38 ` Gerd Möllmann
2024-04-27 11:15 ` Eli Zaretskii
2024-04-27 12:09 ` Gerd Möllmann
2024-04-27 12:33 ` Eli Zaretskii
2024-04-27 12:37 ` Eli Zaretskii
2024-04-27 13:26 ` Gerd Möllmann
2024-04-27 14:54 ` Eli Zaretskii
2024-04-27 15:25 ` Gerd Möllmann
2024-04-27 15:40 ` Eli Zaretskii
2024-04-27 15:47 ` Helmut Eller
2024-04-27 15:48 ` Gerd Möllmann
2024-04-27 7:23 ` Gerd Möllmann
2024-04-27 7:33 ` Eli Zaretskii
2024-04-27 9:04 ` Gerd Möllmann
2024-04-27 11:44 ` Eli Zaretskii
2024-04-27 12:07 ` Eli Zaretskii
2024-04-27 12:41 ` Gerd Möllmann
2024-04-27 13:23 ` Gerd Möllmann
2024-04-27 12:32 ` Gerd Möllmann
2024-04-27 14:11 ` Gerd Möllmann
2024-04-27 14:47 ` Eli Zaretskii
2024-04-27 15:09 ` Gerd Möllmann
2024-04-27 15:15 ` Helmut Eller
2024-04-27 15:29 ` Gerd Möllmann
2024-04-27 15:38 ` Eli Zaretskii
2024-04-27 15:42 ` Gerd Möllmann
2024-04-27 16:37 ` Gerd Möllmann
2024-04-27 15:23 ` Gerd Möllmann
2024-04-28 6:31 ` Eli Zaretskii
2024-04-28 6:44 ` Gerd Möllmann
2024-04-27 7:17 ` Gerd Möllmann
2024-04-27 12:11 ` Helmut Eller
2024-04-27 12:32 ` Eli Zaretskii
2024-04-27 13:41 ` Helmut Eller
2024-04-26 8:12 ` Helmut Eller
2024-04-26 8:57 ` Gerd Möllmann
2024-04-26 10:39 ` Eli Zaretskii
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=86wmokxiod.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=gerd.moellmann@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.