igc: trying to chase a crash

igc: trying to chase a crash

[Óscar Fuentes]

I'm using scratch/igc on and off since some weeks for work (mostly
Dart/Flutter code edition with lsp-mode, quite stressing for the GC
system). Today it crashed, so I launched it again under gdb, and there
it SIGSEGVs consistently while processing the init files. That means
that it SIGSEGVs at the same point every time I try.

So I went to build it in debug mode to obtain a good backtrace, but the
build fails:

../../emacs/src/marker.c: In function ‘buf_bytepos_to_charpos’:
../../emacs/src/marker.c:389:18: error: invalid operands to binary && (have ‘int’ and ‘Lisp_Object’)
  389 |       if (record && BUF_MARKERS (b))
      |           ~~~~~~ ^~
      |           |
      |           int

$ gcc --version
gcc (Debian 14.2.0-8) 14.2.0

$ uname -a
Linux sky 6.11.5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.11.5-1 (2024-10-27) x86_64 GNU/Linux

$ ../emacs/configure CPPFLAGS=-I/home/oscar/lib/mps/include LDFLAGS=-L/home/oscar/lib/mps/lib --with-native-compilation --with-tree-sitter --without-toolkit-scroll-bars --with-x-toolkit=lucid --with-modules --without-imagemagick --with-mps=yes --enable-checking='yes,glyphs' --enable-check-lisp-object-type CFLAGS='-O0 -g3'

The igc/branch is updated (commit 0756b1f2f5452d715396f).

So right now here igc runs when executed from the shell, but crashes on
startup when executed from gdb. And builds succesfully in release mode,
but doesn't in debug mode.

I wonder if either my build config is too infrequent or nobody is
testing igc lately?

Re: igc: trying to chase a crash

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 25 Nov 2024 19:48:36 +0100
> 
> I'm using scratch/igc on and off since some weeks for work (mostly
> Dart/Flutter code edition with lsp-mode, quite stressing for the GC
> system). Today it crashed, so I launched it again under gdb, and there
> it SIGSEGVs consistently while processing the init files. That means
> that it SIGSEGVs at the same point every time I try.

SIGSEGV is used by MPS to implement memory barriers.  The file
src/.gdbinit on the branch has this:

  # Pass on signals used by MPS to suspend threads.
  if defined_HAVE_MPS
    # Print SIGSEGV for now, since it makes the logs more useful.  Don't
    # stop, though.
    handle SIGSEGV nostop print pass
    handle SIGXFSZ nostop noprint pass
    handle SIGXCPU nostop noprint pass
  end

So if you don't want to see these segfaults, change

    handle SIGSEGV nostop print pass
to
    handle SIGSEGV nostop noprint pass

> So I went to build it in debug mode to obtain a good backtrace, but the
> build fails:
> 
> ../../emacs/src/marker.c: In function ‘buf_bytepos_to_charpos’:
> ../../emacs/src/marker.c:389:18: error: invalid operands to binary && (have ‘int’ and ‘Lisp_Object’)
>   389 |       if (record && BUF_MARKERS (b))
>       |           ~~~~~~ ^~
>       |           |
>       |           int

I tried to fix this now, please try again.

> So right now here igc runs when executed from the shell, but crashes on
> startup when executed from gdb. And builds succesfully in release mode,
> but doesn't in debug mode.
> 
> I wonder if either my build config is too infrequent or nobody is
> testing igc lately?

The segfaults you see are not real, they are arranged by MPS
deliberately.

Re: igc: trying to chase a crash

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> SIGSEGV is used by MPS to implement memory barriers.  The file
> src/.gdbinit on the branch has this:
>
>   # Pass on signals used by MPS to suspend threads.
>   if defined_HAVE_MPS
>     # Print SIGSEGV for now, since it makes the logs more useful.  Don't
>     # stop, though.
>     handle SIGSEGV nostop print pass
>     handle SIGXFSZ nostop noprint pass
>     handle SIGXCPU nostop noprint pass
>   end

So does it make sense to run igc under gdb for obtaining backtraces when
it crashes?

>>   389 |       if (record && BUF_MARKERS (b))
>>       |           ~~~~~~ ^~
>>       |           |
>>       |           int
>
> I tried to fix this now, please try again.

Thanks. That instance compiles now, but then...

../../emacs/src/fns.c: In function ‘weak_hash_remove_from_table’:
../../emacs/src/fns.c:5789:26: error: invalid operands to binary == (have ‘Lisp_Object’ and ‘Lisp_Object’)
 5789 |               && hashval == WEAK_HASH_HASH (h, i)
      |                          ^~ ~~~~~~~~~~~~~~~~~~~~~
      |                             |
      |                             Lisp_Object

Re: igc: trying to chase a crash

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 25 Nov 2024 20:53:03 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > SIGSEGV is used by MPS to implement memory barriers.  The file
> > src/.gdbinit on the branch has this:
> >
> >   # Pass on signals used by MPS to suspend threads.
> >   if defined_HAVE_MPS
> >     # Print SIGSEGV for now, since it makes the logs more useful.  Don't
> >     # stop, though.
> >     handle SIGSEGV nostop print pass
> >     handle SIGXFSZ nostop noprint pass
> >     handle SIGXCPU nostop noprint pass
> >   end
> 
> So does it make sense to run igc under gdb for obtaining backtraces when
> it crashes?

Yes, it does.  Because if you hit a real segfault, it will stop again.

> 
> >>   389 |       if (record && BUF_MARKERS (b))
> >>       |           ~~~~~~ ^~
> >>       |           |
> >>       |           int
> >
> > I tried to fix this now, please try again.
> 
> Thanks. That instance compiles now, but then...
> 
> ../../emacs/src/fns.c: In function ‘weak_hash_remove_from_table’:
> ../../emacs/src/fns.c:5789:26: error: invalid operands to binary == (have ‘Lisp_Object’ and ‘Lisp_Object’)
>  5789 |               && hashval == WEAK_HASH_HASH (h, i)
>       |                          ^~ ~~~~~~~~~~~~~~~~~~~~~
>       |                             |
>       |                             Lisp_Object

Fixed.

How about if you say "make -k", so that we see all the problems at
once, not one by one?

Re: igc: trying to chase a crash

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> So does it make sense to run igc under gdb for obtaining backtraces when
>> it crashes?
>
> Yes, it does.  Because if you hit a real segfault, it will stop again.

Ok, thanks.

> Fixed.
>
> How about if you say "make -k", so that we see all the problems at
> once, not one by one?

:-)

Loading mwheel...
Pure Lisp storage overflowed

Error: error ("Cannot continue, pure space overflowed")
  defalias(mouse-wheel--get-scroll-window #[257 "\30127\0\10\203\16\0\302\1!\202\20\0\303 \304\1!\205\34\0\305\306\2!\307\"\310\1!\2054\0\311 \211@\1A\312\313\314\3\5#\5\315\316$\266\203\266\2020\206=\0\302\1!\207" [mouse-wheel-follow-mouse found mwheel-event-window selected-window window-live-p frame-parameter window-frame mouse-wheel-frame frame-live-p mouse-absolute-pixel-position walk-window-tree make-closure #[257 "\302\1\303\304\211$\211@\301X\205)\0\301\305\28X\205)\0\211A@\300X\205)\0\300\306\28X\205)\0\307\310\3\"\207" [V0 V1 window-edges nil t 2 3 throw found] 6 "\n\n(fn WINDOW-1)"] nil t] 11 "Return window for mouse wheel event EVENT.\nIf `mouse-wheel-follow-mouse' is non-nil, return the window that\nthe mouse pointer is over.  Otherwise, return the currently\nactive window.\n\n
 (fn EVENT)"])
  load("mwheel")
  (if (fboundp 'x-create-frame) (load "mwheel"))
  load("loadup.el")
Cannot continue, pure space overflowed

ok, ok... setting SYSTEM_PURESIZE_EXTRA fixes that and the build
completes. But I'm surprised to be the first to report these problems.
Is the igc project dormant? Are there people interested on bug reports
about igc?

Re: igc: trying to chase a crash

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 25 Nov 2024 21:51:03 +0100
> 
> > How about if you say "make -k", so that we see all the problems at
> > once, not one by one?
> 
> :-)
> 
> Loading mwheel...
> Pure Lisp storage overflowed
> 
> Error: error ("Cannot continue, pure space overflowed")
>   defalias(mouse-wheel--get-scroll-window #[257 "\30127\0\10\203\16\0\302\1!\202\20\0\303 \304\1!\205\34\0\305\306\2!\307\"\310\1!\2054\0\311 \211@\1A\312\313\314\3\5#\5\315\316$\266\203\266\2020\206=\0\302\1!\207" [mouse-wheel-follow-mouse found mwheel-event-window selected-window window-live-p frame-parameter window-frame mouse-wheel-frame frame-live-p mouse-absolute-pixel-position walk-window-tree make-closure #[257 "\302\1\303\304\211$\211@\301X\205)\0\301\305\28X\205)\0\211A@\300X\205)\0\300\306\28X\205)\0\307\310\3\"\207" [V0 V1 window-edges nil t 2 3 throw found] 6 "\n\n(fn WINDOW-1)"] nil t] 11 "Return window for mouse wheel event EVENT.\nIf `mouse-wheel-follow-mouse' is non-nil, return the window that\nthe mouse pointer is over.  Otherwise, return the currently\nactive window.\n
 \n(fn EVENT)"])
>   load("mwheel")
>   (if (fboundp 'x-create-frame) (load "mwheel"))
>   load("loadup.el")
> Cannot continue, pure space overflowed
> 
> ok, ok... setting SYSTEM_PURESIZE_EXTRA fixes that and the build
> completes.

Please tell by how much you needed to enlarge the pure space (the
minimum increment that fixes the build).

> But I'm surprised to be the first to report these problems.
> Is the igc project dormant?

No.  I guess there's not a lot of people who build it with
enable-checking and enable-check-lisp-object-type, that's all.

> Are there people interested on bug reports about igc?

Yes, of course.

Re: igc: trying to chase a crash

[Gerd Möllmann]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Is the igc project dormant? 

It's not very active lately, yes. And judging from the number of reports
lately, which I think equals 1, it either has a very low number of bugs,
or a very low number of users. So I'd say neither users nor developers
are pushing things forward at the moment. Don't know more either, it's
just what I'm observing.

For me personally, I can say that I'm using igc daily, for months now,
on macOS, in my fork, and it's working very well. But that's of course
only the system in my office and so on.

> Are there people interested on bug reports about igc?

I am interested, but I'm also macOS-only, so I'm not of much help with
other platforms. (And macOS as a Mach system is quite different in some
important low-level aspects like signal handling vs. Mach exception
handling.)

Re: igc: trying to chase a crash

[chad]

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

On Tue, Nov 26, 2024 at 12:18 AM Gerd Möllmann <gerd.moellmann@gmail.com>
wrote:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
> > Is the igc project dormant?
>
> [...] So I'd say neither users nor developers
> are pushing things forward at the moment. Don't know more either, it's
> just what I'm observing.
>

Anecdatally, I finally got around to building it on my wacky linux
system, then pretty much immediately shifted to the pretest as my
daily driver, and haven't been back yet. Related to the recent mention
of branches, I suspect that a "call to test out" would be
comparatively quite effective, at least based on the example of
native-comp.

I hope that helps,
~Chad

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

Re: igc: trying to chase a crash

[Andrea Corallo]

chad <yandros@gmail.com> writes:

> On Tue, Nov 26, 2024 at 12:18 AM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>
>  Óscar Fuentes <ofv@wanadoo.es> writes:
>
>  > Is the igc project dormant? 
>
>  [...] So I'd say neither users nor developers
>  are pushing things forward at the moment. Don't know more either, it's
>  just what I'm observing.
>
> Anecdatally, I finally got around to building it on my wacky linux
> system, then pretty much immediately shifted to the pretest as my
> daily driver, and haven't been back yet. Related to the recent mention
> of branches, I suspect that a "call to test out" would be
> comparatively quite effective, at least based on the example of
> native-comp.

I think at the time native-comp had a similar call to test and public
visibility on emacs-devel.  My idea is that if the results are different
this is because of other factors.

  Andrea

Re: igc: trying to chase a crash

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> chad <yandros@gmail.com> writes:
>
>> On Tue, Nov 26, 2024 at 12:18 AM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>>
>>  Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>  > Is the igc project dormant? 
>>
>>  [...] So I'd say neither users nor developers
>>  are pushing things forward at the moment. Don't know more either, it's
>>  just what I'm observing.
>>
>> Anecdatally, I finally got around to building it on my wacky linux
>> system, then pretty much immediately shifted to the pretest as my
>> daily driver, and haven't been back yet. Related to the recent mention
>> of branches, I suspect that a "call to test out" would be
>> comparatively quite effective, at least based on the example of
>> native-comp.
>
> I think at the time native-comp had a similar call to test and public
> visibility on emacs-devel.  My idea is that if the results are different
> this is because of other factors.
>
>   Andrea

I get the same feeling. Something is a bit odd.

But maybe that's even a good thing, if no one is actively working on it
anyway :-).

Re: igc: trying to chase a crash

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> chad <yandros@gmail.com> writes:
>>
>>> On Tue, Nov 26, 2024 at 12:18 AM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>>>
>>>  Óscar Fuentes <ofv@wanadoo.es> writes:
>>>
>>>  > Is the igc project dormant? 
>>>
>>>  [...] So I'd say neither users nor developers
>>>  are pushing things forward at the moment. Don't know more either, it's
>>>  just what I'm observing.
>>>
>>> Anecdatally, I finally got around to building it on my wacky linux
>>> system, then pretty much immediately shifted to the pretest as my
>>> daily driver, and haven't been back yet. Related to the recent mention
>>> of branches, I suspect that a "call to test out" would be
>>> comparatively quite effective, at least based on the example of
>>> native-comp.
>>
>> I think at the time native-comp had a similar call to test and public
>> visibility on emacs-devel.  My idea is that if the results are different
>> this is because of other factors.
>>
>>   Andrea
>
> I get the same feeling. Something is a bit odd.

I don't find this too odd, I have my own ideas about the reasons for
this difference.

> But maybe that's even a good thing,

I respectfully disagree.

  Andrea

Re: igc: trying to chase a crash

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

>> I get the same feeling. Something is a bit odd.
>
> I don't find this too odd, I have my own ideas about the reasons for
> this difference.

Care to share your thoughts?

>
>> But maybe that's even a good thing,
>
> I respectfully disagree.
>
>   Andrea

Just trying to always look at the bright side of life :-).

Re: igc: trying to chase a crash

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>>> I get the same feeling. Something is a bit odd.
>>
>> I don't find this too odd, I have my own ideas about the reasons for
>> this difference.
>
> Care to share your thoughts?

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]

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

- publishing some positive performance numbers in order to explain/prove
  the soundness of the approach.

That said, users were very interested and gave a lot of good feedbacks
and bug reports (my impression more than for igc), but the number of
developers involved I'm pretty sure was not higher than what igc got
already.

>>
>>> But maybe that's even a good thing,
>>
>> I respectfully disagree.
>>
>>   Andrea
>
> Just trying to always look at the bright side of life :-).

:)

[1] <https://akrl.sdf.org/gccemacs.html>

Re: igc: trying to chase a crash

[Gregor Zattler]

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

> - publishing some positive performance numbers in order to explain/prove
>   the soundness of the approach.

Also motivated me to have look.


As a mere user I could then only give
feedback on observations.

Thanks @Andrea for native-comp, it helps
a lot.

Ciao; Gregor

Re: igc: trying to chase a crash

[Andrea Corallo]

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.

  Andrea

Re: igc: trying to chase a crash

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

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

Then, why not do it? Where would people expect to find that info? In a
README-IGC or something in the top-level dir?

icg build instructions [was: Re: igc: trying to chase a crash]

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> 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.
>>
>>   Andrea
>
> Then, why not do it? Where would people expect to find that info? In a
> README-IGC or something in the top-level dir?

A README-IGC in the top-level dir SGTM (as a temporary solution before
the merge at least).  I'm wondering if we could have some way to
propagate this information also outside emacs.git as well 🤷

  Andrea

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> A README-IGC in the top-level dir SGTM (as a temporary solution before
> the merge at least).  I'm wondering if we could have some way to
> propagate this information also outside emacs.git as well 🤷
>
>   Andrea

I've added a README-IGC, with what I remember. Maybe others could add
what they know to it.

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Óscar Fuentes]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> A README-IGC in the top-level dir SGTM (as a temporary solution before
>> the merge at least).  I'm wondering if we could have some way to
>> propagate this information also outside emacs.git as well 🤷
>>
>>   Andrea
>
> I've added a README-IGC, with what I remember. Maybe others could add
> what they know to it.

Thanks.

AFAIK, mps is not packaged by Debian.

For building it locally, possibly the easiest route is to clone

https://github.com/Ravenbrook/mps.git

(which was updated just today, BTW), compile with


cd code
cc -O2 -c mps.c
ar rvs libmps.a mps.o

Then config the Emacs build with

configure CPPFLAGS=-I/path/to/mps/includedirectory
LDFLAGS=-L/path/to/mps/codedirectory --with-mps=yes <... rest of
configure options..>

This can have a variation for compiling&using the debug version of mps.

The above is not tested with the current state of mps/emacs. I can try
later and add those instructions to README-IGC.

Whe should decide if we direct users towards the optimized build (better
engagement and real-case experience) or to the debug build (better bug
reports but unusably slow in my experience).

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Gerd Möllmann]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>>> A README-IGC in the top-level dir SGTM (as a temporary solution before
>>> the merge at least).  I'm wondering if we could have some way to
>>> propagate this information also outside emacs.git as well 🤷
>>>
>>>   Andrea
>>
>> I've added a README-IGC, with what I remember. Maybe others could add
>> what they know to it.
>
> Thanks.
>
> AFAIK, mps is not packaged by Debian.
>
> For building it locally, possibly the easiest route is to clone
>
> https://github.com/Ravenbrook/mps.git
>
> (which was updated just today, BTW), compile with

Yeah, it appears they are up to something. I think I have 3 dozen mails
from Github from the last two or three days, from watching their repo.
Merging pull requests and so. Maybe they are preparing a new release or
something?

> cd code
> cc -O2 -c mps.c
> ar rvs libmps.a mps.o
>
> Then config the Emacs build with
>
> configure CPPFLAGS=-I/path/to/mps/includedirectory
> LDFLAGS=-L/path/to/mps/codedirectory --with-mps=yes <... rest of
> configure options..>
>
> This can have a variation for compiling&using the debug version of mps.
>
> The above is not tested with the current state of mps/emacs. I can try
> later and add those instructions to README-IGC.

That would be nice.

>
> Whe should decide if we direct users towards the optimized build (better
> engagement and real-case experience) or to the debug build (better bug
> reports but unusably slow in my experience).

Yes. Maybe users would be disappointed by the performance when running
with full debug? Don't know.

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> A README-IGC in the top-level dir SGTM (as a temporary solution before
>> the merge at least).  I'm wondering if we could have some way to
>> propagate this information also outside emacs.git as well 🤷
>>
>>   Andrea
>
> I've added a README-IGC, with what I remember. Maybe others could add
> what they know to it.

Thanks, given ATM it's not distributed I'd include also info about
checking MPS out compiling it WDYT?

PS do you know if patching MPS is still necessary?

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>>> A README-IGC in the top-level dir SGTM (as a temporary solution before
>>> the merge at least).  I'm wondering if we could have some way to
>>> propagate this information also outside emacs.git as well 🤷
>>>
>>>   Andrea
>>
>> I've added a README-IGC, with what I remember. Maybe others could add
>> what they know to it.
>
> Thanks, given ATM it's not distributed I'd include also info about
> checking MPS out compiling it WDYT?

Ops I see now that the section is already there and just need to be
filled, hopefully someone who went through it recently can do it.

Thanks

  Andrea

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> PS do you know if patching MPS is still necessary?

I'm not sure, it's been a while since I built mps myself since some
kind soul added it to Homebrew.

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Óscar Fuentes]

Andrea Corallo <acorallo@gnu.org> writes:

>> I've added a README-IGC, with what I remember. Maybe others could add
>> what they know to it.
>
> Thanks, given ATM it's not distributed I'd include also info about
> checking MPS out compiling it WDYT?

Done.

> PS do you know if patching MPS is still necessary?

Just checked that with unpatched MPS HEAD (compiled following the
instructions on README-IGC) Emacs builds and starts fine.

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Gerd Möllmann]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>>> I've added a README-IGC, with what I remember. Maybe others could add
>>> what they know to it.
>>
>> Thanks, given ATM it's not distributed I'd include also info about
>> checking MPS out compiling it WDYT?
>
> Done.
>
>> PS do you know if patching MPS is still necessary?
>
> Just checked that with unpatched MPS HEAD (compiled following the
> instructions on README-IGC) Emacs builds and starts fine.

👍 Thanks

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Pip Cet via Emacs development discussions.]

On Thursday, November 28th, 2024 at 12:46, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Andrea Corallo acorallo@gnu.org writes:
> > PS do you know if patching MPS is still necessary?
> 
> Just checked that with unpatched MPS HEAD (compiled following the
> instructions on README-IGC) Emacs builds and starts fine.

That is excellent news! Patching MPS is something we would really like to avoid, IIUC.

Pip

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Óscar Fuentes]

Pip Cet <pipcet@protonmail.com> writes:

> On Thursday, November 28th, 2024 at 12:46, Óscar Fuentes <ofv@wanadoo.es> wrote:
>> Andrea Corallo acorallo@gnu.org writes:
>> > PS do you know if patching MPS is still necessary?
>> 
>> Just checked that with unpatched MPS HEAD (compiled following the
>> instructions on README-IGC) Emacs builds and starts fine.
>
> That is excellent news! Patching MPS is something we would really like
> to avoid, IIUC.

AFAIK the patches were (are?) necessary for fixing the autoconf build.
My recipe directly compiles mps.c with no autoconf/make involved.

So maybe the patches are still required to build MPS with the autoconf
scripts. However, I don't see the point of doing that, since directly
compiling mps.c is less troublesome and is what the MPS documentation
implicitly encourages.

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: chad <yandros@gmail.com>,  Óscar Fuentes <ofv@wanadoo.es>,
>  emacs-devel@gnu.org
> Date: Wed, 27 Nov 2024 05:25:44 -0500
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
> > Andrea Corallo <acorallo@gnu.org> writes:
> >
> >> 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.
> >>
> >>   Andrea
> >
> > Then, why not do it? Where would people expect to find that info? In a
> > README-IGC or something in the top-level dir?
> 
> A README-IGC in the top-level dir SGTM (as a temporary solution before
> the merge at least).  I'm wondering if we could have some way to
> propagate this information also outside emacs.git as well 🤷

Adding new files is not the best idea, IMO.  Why not add this to the
existing INSTALL-REPO.  Come to think of that, why not change
configure.ac on the branch to insist on building with MPS, and
complaining loudly if that cannot be done (e.g., because the MPS
library cannot be found)?  We can always change this back to optional
when the feature lands on master.

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> A README-IGC in the top-level dir SGTM (as a temporary solution before
>> the merge at least).  I'm wondering if we could have some way to
>> propagate this information also outside emacs.git as well 🤷
>
> Adding new files is not the best idea, IMO.  Why not add this to the
> existing INSTALL-REPO.  Come to think of that, why not change
> configure.ac on the branch to insist on building with MPS, and
> complaining loudly if that cannot be done (e.g., because the MPS
> library cannot be found)?  We can always change this back to optional
> when the feature lands on master.

I've done both yesterday, except that I used README-IGC. I think an
advantage of that file name could be that it is easier to spot for a
"normal" user. Don't know, please do with it as you see fit.

Re: icg build instructions [was: Re: igc: trying to chase a crash]

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Andrea Corallo <acorallo@gnu.org>,  yandros@gmail.com,  ofv@wanadoo.es,
>   emacs-devel@gnu.org
> Date: Thu, 28 Nov 2024 05:42:18 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> A README-IGC in the top-level dir SGTM (as a temporary solution before
> >> the merge at least).  I'm wondering if we could have some way to
> >> propagate this information also outside emacs.git as well 🤷
> >
> > Adding new files is not the best idea, IMO.  Why not add this to the
> > existing INSTALL-REPO.  Come to think of that, why not change
> > configure.ac on the branch to insist on building with MPS, and
> > complaining loudly if that cannot be done (e.g., because the MPS
> > library cannot be found)?  We can always change this back to optional
> > when the feature lands on master.
> 
> I've done both yesterday, except that I used README-IGC. I think an
> advantage of that file name could be that it is easier to spot for a
> "normal" user. Don't know, please do with it as you see fit.

Thanks.  It isn't important enough to do anything about it before we
consider landing the branch.  (But it would be nice if people left
some time to respond to proposals before they rush to install them...)

Re: igc: trying to chase a crash

[Vincenzo Pupillo]

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.

> 
>   Andrea
> 
> 

Re: igc: trying to chase a crash

[Andrea Corallo]

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

Re: igc: trying to chase a crash

[Óscar Fuentes]

Andrea Corallo <acorallo@gnu.org> writes:

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

That reflects my experience as well.

Figuring out what is needed is the long and frustrating part, by far.
Once this is done, it's just a sligthly customized emacs build process.

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

+1000.

I can't fathom why if I say --with-something the configure script can
ignore my request and I must scroll up a wall of text to test if that
was the case.

Re: igc: trying to chase a crash

[Andrea Corallo]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>>>> 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.
>
> That reflects my experience as well.
>
> Figuring out what is needed is the long and frustrating part, by far.
> Once this is done, it's just a sligthly customized emacs build process.
>
>>> 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.
>
> +1000.
>
> I can't fathom why if I say --with-something the configure script can
> ignore my request and I must scroll up a wall of text to test if that
> was the case.

Yeah I don't know how much the current behavior of most flags was
intentional, I'm not in love with it as well, but I guess there's a
reason for it.

  Andtrea

Re: igc: trying to chase a crash

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> BTW, I think if the user explicitly uses --with-mps the configuration
> should fail if MPS is not available.
>
>   Andrea

Can't say much about that - it's behaving like for some other libs ATM.

Re: igc: trying to chase a crash

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> BTW, I think if the user explicitly uses --with-mps the configuration
>> should fail if MPS is not available.
>>
>>   Andrea
>
> Can't say much about that - it's behaving like for some other libs ATM.

True, but my feeling is that for important features like this (at least)
the other behavior is better, that's why --with-nativecomp can signal an
error.

Also I assume that a user checking out scratch/igc and compiling with
--with-mps really want to try igc :)

Re: igc: trying to chase a crash

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>>> BTW, I think if the user explicitly uses --with-mps the configuration
>>> should fail if MPS is not available.
>>>
>>>   Andrea
>>
>> Can't say much about that - it's behaving like for some other libs ATM.
>
> True, but my feeling is that for important features like this (at least)
> the other behavior is better, that's why --with-nativecomp can signal an
> error.
>
> Also I assume that a user checking out scratch/igc and compiling with
> --with-mps really want to try igc :)

I've added that now, 1001 votes was bit much :-)

Re: igc: trying to chase a crash

[Óscar Fuentes]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

>> Also I assume that a user checking out scratch/igc and compiling with
>> --with-mps really want to try igc :)
>
> I've added that now, 1001 votes was bit much :-)

Thank you. Democracy works.

:-)

Re: igc: trying to chase a crash

[Jeff Walsh]

[-- 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 --]

Re: igc: trying to chase a crash

[Eli Zaretskii]

> From: Vincenzo Pupillo <v.pupillo@gmail.com>
> Cc: chad <yandros@gmail.com>, Óscar Fuentes <ofv@wanadoo.es>,
>  emacs-devel@gnu.org, Andrea Corallo <acorallo@gnu.org>
> Date: Wed, 27 Nov 2024 11:40:53 +0100
> 
> Wouldn't it perhaps be better to clone mps to savannah (with our patches) and add it as a sub-module to emacs? 

It could be, but someone will have to take the responsibility for
doing this, updating from upstream, etc.

Re: igc: trying to chase a crash

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>>>> I get the same feeling. Something is a bit odd.
>>>
>>> I don't find this too odd, I have my own ideas about the reasons for
>>> this difference.
>>
>> Care to share your thoughts?
>
> 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]
>
> - 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.
>
> - publishing some positive performance numbers in order to explain/prove
>   the soundness of the approach.
>
> That said, users were very interested and gave a lot of good feedbacks
> and bug reports (my impression more than for igc), but the number of
> developers involved I'm pretty sure was not higher than what igc got
> already.

Yes, thanks, that's interesting, for me at least, because I wasn't there
at the time.

So, you did a ton of work, also outside the technical aspects, to get it
in, certainly requiring a very strong motivation and will power over a
long time.

If that's a requirement, maybe it is the reason why users are ignoring
igc, indeed. And in that case, the question would be, if the project or
some individual(s) could or want to do something similar. Which I can't
answer. I won't do it, though, which I think I said already too often.
And, from my POV, no one can be blamed for not having that stamina.

Hm.

Re: igc: trying to chase a crash

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> Andrea Corallo <acorallo@gnu.org> writes:
>>>
>>>>> I get the same feeling. Something is a bit odd.
>>>>
>>>> I don't find this too odd, I have my own ideas about the reasons for
>>>> this difference.
>>>
>>> Care to share your thoughts?
>>
>> 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]
>>
>> - 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.
>>
>> - publishing some positive performance numbers in order to explain/prove
>>   the soundness of the approach.
>>
>> That said, users were very interested and gave a lot of good feedbacks
>> and bug reports (my impression more than for igc), but the number of
>> developers involved I'm pretty sure was not higher than what igc got
>> already.
>
> Yes, thanks, that's interesting, for me at least, because I wasn't there
> at the time.
>
> So, you did a ton of work, also outside the technical aspects, to get it
> in, certainly requiring a very strong motivation and will power over a
> long time.
>
> If that's a requirement, maybe it is the reason why users are ignoring
> igc, indeed. And in that case, the question would be, if the project or
> some individual(s) could or want to do something similar. Which I can't
> answer. I won't do it, though, which I think I said already too often.
> And, from my POV, no one can be blamed for not having that stamina.

Absolutely, still I think few things are probably really low cost (the
feature branch comes to my mind).

  Andrea

Re: igc: trying to chase a crash

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

>> If that's a requirement, maybe it is the reason why users are ignoring
>> igc, indeed. And in that case, the question would be, if the project or
>> some individual(s) could or want to do something similar. Which I can't
>> answer. I won't do it, though, which I think I said already too often.
>> And, from my POV, no one can be blamed for not having that stamina.
>
> Absolutely, still I think few things are probably really low cost (the
> feature branch comes to my mind).
>

Maintainers could just decide to do it, cough, cough :-). But I don't
have a say in this, Pip added to CC.

scratch/igc as a feature branch [was: Re: igc: trying to chase a crash]

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>>> If that's a requirement, maybe it is the reason why users are ignoring
>>> igc, indeed. And in that case, the question would be, if the project or
>>> some individual(s) could or want to do something similar. Which I can't
>>> answer. I won't do it, though, which I think I said already too often.
>>> And, from my POV, no one can be blamed for not having that stamina.
>>
>> Absolutely, still I think few things are probably really low cost (the
>> feature branch comes to my mind).
>>
>
> Maintainers could just decide to do it, cough, cough :-).

Maintainers could decide autonomously, but IMO is more about developers
of that branch being okay with the decision.  The implications are,
other than the name change, not being able to force push.

That said not only I'm okay with having scratch/icg being pushed as
feature/icg, but I long time suggested that :)

Re: scratch/igc as a feature branch [was: Re: igc: trying to chase a crash]

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: chad <yandros@gmail.com>,  Óscar Fuentes <ofv@wanadoo.es>,
>  emacs-devel@gnu.org,  Pip Cet <pipcet@protonmail.com>
> Date: Wed, 27 Nov 2024 05:18:08 -0500
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
> >> Absolutely, still I think few things are probably really low cost (the
> >> feature branch comes to my mind).
> >>
> >
> > Maintainers could just decide to do it, cough, cough :-).
> 
> Maintainers could decide autonomously, but IMO is more about developers
> of that branch being okay with the decision.  The implications are,
> other than the name change, not being able to force push.
> 
> That said not only I'm okay with having scratch/icg being pushed as
> feature/icg, but I long time suggested that :)

The question is indeed what kind of trouble this could cause.  If it
loses the history, I wouldn't do it, since the fact that it's under
scratch/ is not a catastrophe, IMO.

Re: scratch/igc as a feature branch [was: Re: igc: trying to chase a crash]

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: chad <yandros@gmail.com>,  Óscar Fuentes <ofv@wanadoo.es>,
>>  emacs-devel@gnu.org,  Pip Cet <pipcet@protonmail.com>
>> Date: Wed, 27 Nov 2024 05:18:08 -0500
>> 
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> 
>> >> Absolutely, still I think few things are probably really low cost (the
>> >> feature branch comes to my mind).
>> >>
>> >
>> > Maintainers could just decide to do it, cough, cough :-).
>> 
>> Maintainers could decide autonomously, but IMO is more about developers
>> of that branch being okay with the decision.  The implications are,
>> other than the name change, not being able to force push.
>> 
>> That said not only I'm okay with having scratch/icg being pushed as
>> feature/icg, but I long time suggested that :)
>
> The question is indeed what kind of trouble this could cause.  If it
> loses the history, I wouldn't do it, since the fact that it's under
> scratch/ is not a catastrophe, IMO.

Sure, my idea would be to just push the current head of scratch/icg to
feature/igc (and remove the first), so no history would be lost.

  Andrea

Re: scratch/igc as a feature branch [was: Re: igc: trying to chase a crash]

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: gerd.moellmann@gmail.com,  yandros@gmail.com,  ofv@wanadoo.es,
>   emacs-devel@gnu.org,  pipcet@protonmail.com
> Date: Thu, 28 Nov 2024 05:56:29 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The question is indeed what kind of trouble this could cause.  If it
> > loses the history, I wouldn't do it, since the fact that it's under
> > scratch/ is not a catastrophe, IMO.
> 
> Sure, my idea would be to just push the current head of scratch/icg to
> feature/igc (and remove the first), so no history would be lost.

If that works (I never did anything like that, so don't know what Git
does), then I don't mind.

If we do this, it would be good to post a message here telling people
how to switch to the renamed branch, even if that is trivial.

Re: scratch/igc as a feature branch [was: Re: igc: trying to chase a crash]

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: gerd.moellmann@gmail.com,  yandros@gmail.com,  ofv@wanadoo.es,
>>   emacs-devel@gnu.org,  pipcet@protonmail.com
>> Date: Thu, 28 Nov 2024 05:56:29 -0500
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > The question is indeed what kind of trouble this could cause.  If it
>> > loses the history, I wouldn't do it, since the fact that it's under
>> > scratch/ is not a catastrophe, IMO.
>> 
>> Sure, my idea would be to just push the current head of scratch/icg to
>> feature/igc (and remove the first), so no history would be lost.
>
> If that works (I never did anything like that, so don't know what Git
> does), then I don't mind.

One can also rename branches, BTW.

>
> If we do this, it would be good to post a message here telling people
> how to switch to the renamed branch, even if that is trivial.

Shouldn't we wait for Pip to say something?

Re: scratch/igc as a feature branch [was: Re: igc: trying to chase a crash]

[Pip Cet via Emacs development discussions.]

On Thursday, November 28th, 2024 at 12:54, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:

> Shouldn't we wait for Pip to say something?

Sorry, for reasons that don't really belong here, I've been unable to keep up with things on emacs-devel. I'll try to catch up with my emails now, but can't make any promises, health being what it is.

Pip

Re: scratch/igc as a feature branch [was: Re: igc: trying to chase a crash]

[Gerd Möllmann]

Pip Cet <pipcet@protonmail.com> writes:

> On Thursday, November 28th, 2024 at 12:54, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>
>> Shouldn't we wait for Pip to say something?
>
> Sorry, for reasons that don't really belong here, I've been unable to
> keep up with things on emacs-devel. I'll try to catch up with my
> emails now, but can't make any promises, health being what it is.
>
> Pip

Take it slow, and all the best.

Re: scratch/igc as a feature branch [was: Re: igc: trying to chase a crash]

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Andrea Corallo <acorallo@gnu.org>
>>> Cc: gerd.moellmann@gmail.com,  yandros@gmail.com,  ofv@wanadoo.es,
>>>   emacs-devel@gnu.org,  pipcet@protonmail.com
>>> Date: Thu, 28 Nov 2024 05:56:29 -0500
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> > The question is indeed what kind of trouble this could cause.  If it
>>> > loses the history, I wouldn't do it, since the fact that it's under
>>> > scratch/ is not a catastrophe, IMO.
>>> 
>>> Sure, my idea would be to just push the current head of scratch/icg to
>>> feature/igc (and remove the first), so no history would be lost.
>>
>> If that works (I never did anything like that, so don't know what Git
>> does), then I don't mind.
>
> One can also rename branches, BTW.

Cool didn't know it 😀

>>
>> If we do this, it would be good to post a message here telling people
>> how to switch to the renamed branch, even if that is trivial.
>
> Shouldn't we wait for Pip to say something?

Sure

Re: igc: trying to chase a crash

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: chad <yandros@gmail.com>,  Óscar Fuentes <ofv@wanadoo.es>,
>  emacs-devel@gnu.org
> Date: Wed, 27 Nov 2024 10:55:00 +0100
> 
> So, you did a ton of work, also outside the technical aspects, to get it
> in, certainly requiring a very strong motivation and will power over a
> long time.
> 
> If that's a requirement, maybe it is the reason why users are ignoring
> igc, indeed.

It's indeed true that Andrea did a ton of work, but I don't think it's
true that "users are ignoring igc".  The branch was built and tested
at least to some extent on all the important supported platforms which
can build it (perhaps with the exception of Android), so I think you
are good.  What needs to be worked on there are those unresolved
issues we know about, like handling of signals when MPS is GC-ing and
a few others.  When those issues are resolved, the branch will be a
good candidate for landing, I think.  (And then we will have a flood
of exciting bugs, of course, but that happens with every major new
feature.)

> And in that case, the question would be, if the project or
> some individual(s) could or want to do something similar. Which I can't
> answer. I won't do it, though, which I think I said already too often.
> And, from my POV, no one can be blamed for not having that stamina.

I agree that if someone volunteers to oversee the branch, its testing,
and its merge to master at some future point, we might be able to move
faster with it.

Re: igc: trying to chase a crash

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: chad <yandros@gmail.com>,  Óscar Fuentes <ofv@wanadoo.es>,
>>  emacs-devel@gnu.org
>> Date: Wed, 27 Nov 2024 10:55:00 +0100
>> 
>> So, you did a ton of work, also outside the technical aspects, to get it
>> in, certainly requiring a very strong motivation and will power over a
>> long time.
>> 
>> If that's a requirement, maybe it is the reason why users are ignoring
>> igc, indeed.
>
> It's indeed true that Andrea did a ton of work, but I don't think it's
> true that "users are ignoring igc".  The branch was built and tested
> at least to some extent on all the important supported platforms which
> can build it (perhaps with the exception of Android), so I think you
> are good.  

Maybe "ignore" was too strong. I was just wondering about the "silence",
so to speak.