Helping with MPS

Helping with MPS

[Jonathon McKitrick via Emacs development discussions.]

I'm going to run MPS on my personal and work machines, and I'll report back here if I have any issues. I'm also happy to help with coding and docs if needed.

First question: Since the build succeeded and emacs is running smoothly, what's the easiest way to confirm that my executable definitely has MPS running?

Jonathon McKitrick
--
'My other computer is your Windows box.'

Re: Helping with MPS

[Pip Cet]

"Jonathon McKitrick via \"Emacs development discussions.\"" <emacs-devel@gnu.org> writes:

> I'm going to run MPS on my personal and work machines,

Thank you, that's great to hear!  May I ask which operating system and
CPU architecture they use?

> and I'll report back here if I have any issues.

Please do!  Any feedback is appreciated.

> I'm also happy to help with coding and docs if needed.

Well, it's time to fix the remaining stability issue: signal handlers
and MPS.  I've been running a workaround for weeks now, and I've
attributed all the remaining crashes to other causes, so I think it's
stable, but it's not particularly clean.

The problem is signal handlers may interrupt MPS, and then we must not
touch any Lisp data, so we must (usually) delay running the signal
handler until we've left MPS code.  The problem is MPS code may be
entered transparently by another thread, and then we don't know that
we're leaving MPS code...

My current workaround is to have a flag for each signal, plus a global
flag, and set them when the signal arrives at an inopportune time. We
check them when we know we just left MPS code, and that part usually
works, but sometimes we miss the exit, and then we have to wait until
the next 'maybe_quit' to handle the signal, and that strikes me as
potentially too long a delay.

So, if you're using GNU/Linux machines, you might run into crashes we
already know about.  I can provide a temporary fix, but it doesn't feel
quite good enough for scratch/igc yet.

Any comments or advice would be welcome, of course.

> First question: Since the build succeeded and emacs is running
> smoothly, what's the easiest way to confirm that my executable
> definitely has MPS running?

Attach gdb and wait for a segfault.  If you can continue and Emacs keeps
running, you're running MPS.

'M-x igc-stats RET s' should also work, and show a snapshot of MPS
allocations.  Just leaning on 'c' for a while in that buffer (which
triggers a collection) has produced crashes in the past...

Thanks again
Pip

Re: Helping with MPS

[Helmut Eller]

On Tue, Aug 20 2024, Jonathon McKitrick wrote:

> First question: Since the build succeeded and emacs is running
> smoothly, what's the easiest way to confirm that my executable
> definitely has MPS running?

(featurep 'mps) should return t.  There should also exist some functions
like igc-info, igc--collect, igc-stats.

Re: Helping with MPS

[Jonathon McKitrick via Emacs development discussions.]

On Tue, Aug 20, 2024 at 03:52:01PM +0000, Pip Cet wrote:
: "Jonathon McKitrick via \"Emacs development discussions.\"" <emacs-devel@gnu.org> writes:
: Thank you, that's great to hear!  May I ask which operating system and
: CPU architecture they use?

MacOS on arm64

: 'M-x igc-stats RET s' should also work, and show a snapshot of MPS
: allocations.  Just leaning on 'c' for a while in that buffer (which
: triggers a collection) has produced crashes in the past...

I'm not getting igc stats, and (featurep 'mps) returns nil.

So I thought this build was mps enabled, but apparently it's not.
I'm building again, and this time egrep finds 'with.mps' throughout
the configure script and a couple of other non-source code files.

I assume this is a source-built feature and not a linked library,
right? I don't understand why I don't see any references in .c files.

Jonathon McKitrick
--
'My other computer is your Windows box.'

Re: Helping with MPS

[Jonathon McKitrick via Emacs development discussions.]

On Tue, Aug 20, 2024 at 08:41:28PM +0000, Jonathon McKitrick via Emacs development discussions. wrote:
: On Tue, Aug 20, 2024 at 03:52:01PM +0000, Pip Cet wrote:
: : "Jonathon McKitrick via \"Emacs development discussions.\"" <emacs-devel@gnu.org> writes:
: : Thank you, that's great to hear!  May I ask which operating system and
: : CPU architecture they use?
: I assume this is a source-built feature and not a linked library,
: right? I don't understand why I don't see any references in .c files.

N/M I just discovered 'with-mps' needs to be passed a value 'yes'


Jonathon McKitrick
--
'My other computer is your Windows box.'

Re: Helping with MPS

[Jonathon McKitrick via Emacs development discussions.]

On Tue, Aug 20, 2024 at 06:05:48PM +0200, Helmut Eller wrote:
: On Tue, Aug 20 2024, Jonathon McKitrick wrote:
: 
: > First question: Since the build succeeded and emacs is running
: > smoothly, what's the easiest way to confirm that my executable
: > definitely has MPS running?
: 
: (featurep 'mps) should return t.  There should also exist some functions
: like igc-info, igc--collect, igc-stats.

That makes sense. However, after checking out the branch and then running
configure with '--with-mps=yes' followed by make bootstrap, running
src/emacs and checking for the igc stats and feature returns negative
results. Not sure how to proceed at this point.

Jonathon McKitrick
--
'My other computer is your Windows box.'

Re: Helping with MPS

[Gerd Möllmann]

Jonathon McKitrick via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> On Tue, Aug 20, 2024 at 06:05:48PM +0200, Helmut Eller wrote:
> : On Tue, Aug 20 2024, Jonathon McKitrick wrote:
> : 
> : > First question: Since the build succeeded and emacs is running
> : > smoothly, what's the easiest way to confirm that my executable
> : > definitely has MPS running?
> : 
> : (featurep 'mps) should return t.  There should also exist some functions
> : like igc-info, igc--collect, igc-stats.
>
> That makes sense. However, after checking out the branch and then running
> configure with '--with-mps=yes' followed by make bootstrap, running
> src/emacs and checking for the igc stats and feature returns negative
> results. Not sure how to proceed at this point.

Hi Jonathan.

First step is to build and install the MPS library. (The "mps" that
Homebrew has in something completely different.)

Clone

  https://github.com/Ravenbrook/mps

Apply the patch from here

  https://github.com/Ravenbrook/mps/issues/281

Then something like

  ./configure --prefix=/Users/gerd/.local
  gmake install

which I use to install MPS in ~/.local.

Then set up your system to find include files and libs in ~/.local. I
have in my ~/.zshenv

  # For own libs, like -lmps. Note that clang uses LIBRARY_PATH, not
  # LD_LIBRARY_PATH.
  export C_INCLUDE_PATH="$HOME/.local/include"
  export OBJC_INCLUDE_PATH="$HOME/.local/include"
  export CPLUS_INCLUDE_PATH="$HOME/.local/include"
  export LIBRARY_PATH="$HOME/.local/lib"
  export LD_LIBRARY_PATH="$HOME/.local/lib"

And then Emacs' ./configure --with-mps should print that it found -lmps
and is using it.

Re: Helping with MPS

[Helmut Eller]

On Wed, Aug 21 2024, Gerd Möllmann wrote:

>> That makes sense. However, after checking out the branch and then running
>> configure with '--with-mps=yes' followed by make bootstrap, running
>> src/emacs and checking for the igc stats and feature returns negative
>> results. Not sure how to proceed at this point.

Read your config.log, there must be a line like

  #define HAVE_MPS 1

If it's not there, then search "checking for mps.h" and look clues.

> Then something like
>
>   ./configure --prefix=/Users/gerd/.local

On Linux or FreeBSD, also add "CFLAGS=-fno-omit-frame-pointer".
(Or use the patch: https://github.com/Ravenbrook/mps/pull/38)

Re: Helping with MPS

[Arash Esbati]

Guten Morgen Gerd,

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

> First step is to build and install the MPS library. (The "mps" that
> Homebrew has in something completely different.)

Maybe 'libmps' from Homebrew fits the bill better:

  https://formulae.brew.sh/formula/libmps

It was added recently, I think.

Best, Arash

Re: Helping with MPS

[Helmut Eller]

On Tue, Aug 20 2024, Pip Cet wrote:

> My current workaround is to have a flag for each signal, plus a global
> flag, and set them when the signal arrives at an inopportune time. We
> check them when we know we just left MPS code, and that part usually
> works, but sometimes we miss the exit, and then we have to wait until
> the next 'maybe_quit' to handle the signal, and that strikes me as
> potentially too long a delay.
>
> So, if you're using GNU/Linux machines, you might run into crashes we
> already know about.  I can provide a temporary fix, but it doesn't feel
> quite good enough for scratch/igc yet.
>
> Any comments or advice would be welcome, of course.

What would you think about creating fork of MPS (on GitHub)
that includes:

a) fixes for known problems:
   https://github.com/Ravenbrook/mps/issues/285
   https://github.com/Ravenbrook/mps/pull/257
   https://github.com/Ravenbrook/mps/pull/38
   https://github.com/Ravenbrook/mps/pull/83

b) removes the instruction emulation on protection faults in the AWL
   pool.  For us, this adds a lot of complexity with questionable gains:
   The weak hash tables implementation is, well, complicated and for the
   marker-vector it's ineffective because there we use tagged pointers
   (apparently without problems).

c) blocks signals. Not my preferred solution, but some people seem to
   think that that is the emacsy way to do things.

?

Re: Helping with MPS

[Gerd Möllmann]

Arash Esbati <arash@gnu.org> writes:

> Guten Morgen Gerd,
>
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> First step is to build and install the MPS library. (The "mps" that
>> Homebrew has in something completely different.)
>
> Maybe 'libmps' from Homebrew fits the bill better:
>
>   https://formulae.brew.sh/formula/libmps
>
> It was added recently, I think.

Yeah thanks, I didn't notice that. Should work, I guess.

Re: Helping with MPS

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> b) removes the instruction emulation on protection faults in the AWL
>    pool.  For us, this adds a lot of complexity with questionable gains:
>    The weak hash tables implementation is, well, complicated and for the
>    marker-vector it's ineffective because there we use tagged pointers
>    (apparently without problems).

I can't express how much I'm in favor of getting rid of that wart :-)

Re: Helping with MPS

[Pip Cet]

"Helmut Eller" <eller.helmut@gmail.com> writes:
> On Tue, Aug 20 2024, Pip Cet wrote:
>
>> My current workaround is to have a flag for each signal, plus a global
>> flag, and set them when the signal arrives at an inopportune time. We
>> check them when we know we just left MPS code, and that part usually
>> works, but sometimes we miss the exit, and then we have to wait until
>> the next 'maybe_quit' to handle the signal, and that strikes me as
>> potentially too long a delay.
>>
>> So, if you're using GNU/Linux machines, you might run into crashes we
>> already know about.  I can provide a temporary fix, but it doesn't feel
>> quite good enough for scratch/igc yet.
>>
>> Any comments or advice would be welcome, of course.
>
> What would you think about creating fork of MPS (on GitHub)
> that includes:

I'm not a huge fan of GitHub, to be honest.  There's already
https://codeberg.org/pipcet/mps, so maybe we can use that and mirror to
a GitHub repo if that's desirable?

> a) fixes for known problems:
>    https://github.com/Ravenbrook/mps/issues/285
>    https://github.com/Ravenbrook/mps/pull/257
>    https://github.com/Ravenbrook/mps/pull/38
>    https://github.com/Ravenbrook/mps/pull/83

I'll have to look through these.

> b) removes the instruction emulation on protection faults in the AWL
>    pool.  For us, this adds a lot of complexity with questionable gains:

I don't think it's questionable at all:  There is no advantage for us.

>    The weak hash tables implementation is, well, complicated and for the
>    marker-vector it's ineffective because there we use tagged pointers
>    (apparently without problems).

Hmm.  I suspect the reason we're not seeing any problems is that few
people test on i386, and that only certain instructions are emulated: in
particular, there has to be a nonzero offset in a load instruction for
it to be emulated.  Using a tagged pointer in a weak object with the
single access emulation is definitely not okay...

> c) blocks signals. Not my preferred solution, but some people seem to
>    think that that is the emacsy way to do things.

I'm not sure whether we should block signals or add "this thread is
trying to lock the arena"/"this thread is unlocking the arena"
callbacks, but that's an implementation detail.  It does feel like I've
been trying to hammer in a screw here :-)

d) adds support for Windows/GCC builds.

I think this is the right way forward (so you've convinced me; I've
previously expressed the opposite opinion), for these reasons:

1. it's the only sensible way of supporting i386, because the single
access restrictions are too much of a problem, and virtually untestable
because they trigger so rarely
2. it supports Windows/GCC configurations
3. I don't see a way to avoid delaying signal handlers until the next
maybe_quit(), at least some of the time, without it.

Pip

Re: Helping with MPS

[Helmut Eller]

On Wed, Aug 21 2024, Pip Cet wrote:

>> What would you think about creating fork of MPS (on GitHub)
>> that includes:
>
> I'm not a huge fan of GitHub, to be honest.  There's already
> https://codeberg.org/pipcet/mps, so maybe we can use that and mirror to
> a GitHub repo if that's desirable?

It think that at least something should be on GitHub, because Ravenbrook
puts MPS there.

Re: Helping with MPS

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>  emacs-devel@gnu.org,  Jonathon McKitrick <jcm@SDF.ORG>
> Date: Wed, 21 Aug 2024 08:31:50 +0200
> 
> What would you think about creating fork of MPS (on GitHub)
> that includes:

How intensive is the development of MPS? how many commits did they
have for, say, the last year?

Re: Helping with MPS

[Jonathon McKitrick via Emacs development discussions.]

On Wed, Aug 21, 2024 at 05:46:06AM +0200, Gerd Mllmann wrote:
: Then something like
: 
:   ./configure --prefix=/Users/gerd/.local
:   gmake install
: 
: which I use to install MPS in ~/.local.

I got the patch installed and re-ran autoconf and then configure.

But when running make I get this:

xcrun xcodebuild -project code/mps.xcodeproj -config Debug
xcrun: error: unable to find utility "xcodebuild", not a developer tool or in PATH
make: *** [build-via-xcode] Error 72

I have xcode command line tools installed, and when building emacs itself,
the xcrun/xcodebuild commands work fine.

What am I missing?

Sorry if it's an obvious fix, I'm more a BSD guy than GNU/Linux....


Jonathon McKitrick
--
'My other computer is your Windows box.'

Re: Helping with MPS

[Helmut Eller]

On Wed, Aug 21 2024, Eli Zaretskii wrote:

> How intensive is the development of MPS?

Looks quite dormant at the moment.  Maybe they only work on it if a
customer requests something.  Dunno.

> how many commits did they
> have for, say, the last year?

git log | grep '^Date:.* 2024 '|wc -l => 0
git log | grep '^Date:.* 2023 '|wc -l => 343
git log | grep '^Date:.* 2022 '|wc -l => 7
git log | grep '^Date:.* 2021 '|wc -l => 27

Re: Helping with MPS

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: pipcet@protonmail.com,  gerd.moellmann@gmail.com,  emacs-devel@gnu.org,
>   jcm@SDF.ORG
> Date: Wed, 21 Aug 2024 16:36:49 +0200
> 
> On Wed, Aug 21 2024, Eli Zaretskii wrote:
> 
> > How intensive is the development of MPS?
> 
> Looks quite dormant at the moment.  Maybe they only work on it if a
> customer requests something.  Dunno.
> 
> > how many commits did they
> > have for, say, the last year?
> 
> git log | grep '^Date:.* 2024 '|wc -l => 0
> git log | grep '^Date:.* 2023 '|wc -l => 343
> git log | grep '^Date:.* 2022 '|wc -l => 7
> git log | grep '^Date:.* 2021 '|wc -l => 27

Thanks.  Yes, looks quite dormant.

My point was that if they are actively developing the library, we'll
have hard time keeping up.  But it doesn't seem it will be a problem,
so forking does seem practical.

But if we fork, why not simply add it to the Emacs Git repository? why
do we need a separate repository on GitHub?

Re: Helping with MPS

[Gerd Möllmann]

Jonathon McKitrick <jcm@SDF.ORG> writes:

> On Wed, Aug 21, 2024 at 05:46:06AM +0200, Gerd Mllmann wrote:
> : Then something like
> : 
> :   ./configure --prefix=/Users/gerd/.local
> :   gmake install
> : 
> : which I use to install MPS in ~/.local.
>
> I got the patch installed and re-ran autoconf and then configure.
>
> But when running make I get this:
>
> xcrun xcodebuild -project code/mps.xcodeproj -config Debug
> xcrun: error: unable to find utility "xcodebuild", not a developer tool or in PATH
> make: *** [build-via-xcode] Error 72
>
> I have xcode command line tools installed, and when building emacs itself,
> the xcrun/xcodebuild commands work fine.

Building Emacs just uses clang and gmake, so that can work without xcrun
working. Are you using clang from Xcode?

> What am I missing?

Something is wrong with your Xcode installation, I'd say, but I don't
know what that could be. What does

  xcode-select --print-path

say? It should print the path under which the developer tools are found.
See also

  man xcode-select

> Sorry if it's an obvious fix, I'm more a BSD guy than GNU/Linux....

(I'm also not a Linux user, on my own computers, never have been. Always
FreeBSD until I switched to OSX/macOS because I needed a working laptop
for work :-)).

Re: Helping with MPS

[Jonathon McKitrick via Emacs development discussions.]

On Wed, Aug 21, 2024 at 04:48:19PM +0200, Gerd Mllmann wrote:
: Jonathon McKitrick <jcm@SDF.ORG> writes:
: > I got the patch installed and re-ran autoconf and then configure.
: >
: > But when running make I get this:
: >
: > xcrun xcodebuild -project code/mps.xcodeproj -config Debug
: > xcrun: error: unable to find utility "xcodebuild", not a developer tool or in PATH
: > make: *** [build-via-xcode] Error 72
: >
: > I have xcode command line tools installed, and when building emacs itself,
: > the xcrun/xcodebuild commands work fine.
: 
: Building Emacs just uses clang and gmake, so that can work without xcrun
: working. Are you using clang from Xcode?

I believe so, yes. Not sure it's relevant, but that patch I applied for
arm-apple-darwin has

      BUILD_TARGET=build-via-xcode

And the error message above indicates it's using the mps.xcodeproj file,
so wouldn't that require xcode rather than clang and gmake? I just don't
know enough about autotools.

: > What am I missing?
: 
: Something is wrong with your Xcode installation, I'd say, but I don't
: know what that could be. What does
: 
:   xcode-select --print-path
: 
: say? It should print the path under which the developer tools are found.
: See also
: 
:   man xcode-select

Yep, that's the first thing I explored, and got this:

~/p/mps ❯❯❯ xcode-select -p
/Library/Developer/CommandLineTools

So xcode tools *are* there, I use them with brew and other tools all the time.

: (I'm also not a Linux user, on my own computers, never have been. Always
: FreeBSD until I switched to OSX/macOS because I needed a working laptop
: for work :-)).

That's exactly the path I followed as well!


Jonathon McKitrick
--
'My other computer is your Windows box.'

Re: Helping with MPS

[Helmut Eller]

On Wed, Aug 21 2024, Eli Zaretskii wrote:

> But if we fork, why not simply add it to the Emacs Git repository? why
> do we need a separate repository on GitHub?

Putting a fork on GitHub seems like the courteous thing to do IMO.

Re: Helping with MPS

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: pipcet@protonmail.com,  gerd.moellmann@gmail.com,  emacs-devel@gnu.org,
>   jcm@SDF.ORG
> Date: Wed, 21 Aug 2024 17:10:22 +0200
> 
> On Wed, Aug 21 2024, Eli Zaretskii wrote:
> 
> > But if we fork, why not simply add it to the Emacs Git repository? why
> > do we need a separate repository on GitHub?
> 
> Putting a fork on GitHub seems like the courteous thing to do IMO.

Not sure I understand: courteous to whom?  If we are going to make
Emacs-specific changes in the library, who else will find this fork
useful except people that build and develop Emacs?

Re: Helping with MPS

[Gerd Möllmann]

Jonathon McKitrick <jcm@SDF.ORG> writes:

> : Building Emacs just uses clang and gmake, so that can work without xcrun
> : working. Are you using clang from Xcode?
>
> I believe so, yes. Not sure it's relevant, but that patch I applied for
> arm-apple-darwin has
>
>       BUILD_TARGET=build-via-xcode
>
> And the error message above indicates it's using the mps.xcodeproj file,
> so wouldn't that require xcode rather than clang and gmake? I just don't
> know enough about autotools.

That's the same here. Building MPS uses xcodebuild with that Xcode project.

>
> : > What am I missing?
> : 
> : Something is wrong with your Xcode installation, I'd say, but I don't
> : know what that could be. What does
> : 
> :   xcode-select --print-path
> : 
> : say? It should print the path under which the developer tools are found.
> : See also
> : 
> :   man xcode-select
>
> Yep, that's the first thing I explored, and got this:
>
> ~/p/mps â%9d¯â%9d¯â%9d¯ xcode-select -p
> /Library/Developer/CommandLineTools

That's different here:

/Users/gerd % xcode-select --print-path
/Applications/Xcode.app/Contents/Developer

And xcrun and xcodebuild are found in /usr/bin.

> So xcode tools *are* there, I use them with brew and other tools all
> the time.

I'm afraid I can't help much here. It "just worked" for me, and I
haven't done any config for Xcode or its command line tools, except
installing them, a long time ago.

Re: Helping with MPS

[Jonathon McKitrick via Emacs development discussions.]

On Wed, Aug 21, 2024 at 05:40:17PM +0200, Gerd Mllmann wrote:
: Jonathon McKitrick <jcm@SDF.ORG> writes:
: 
: > : Building Emacs just uses clang and gmake, so that can work without xcrun
: > : working. Are you using clang from Xcode?
: >
: > I believe so, yes. Not sure it's relevant, but that patch I applied for
: > arm-apple-darwin has
: >
: >       BUILD_TARGET=build-via-xcode
: >
: > And the error message above indicates it's using the mps.xcodeproj file,
: > so wouldn't that require xcode rather than clang and gmake? I just don't
: > know enough about autotools.
: 
: That's the same here. Building MPS uses xcodebuild with that Xcode project.

So I deleted a few choice lines from configure.ac which selected the xcode build,
and re-ran everything. It got much farther this time, only stopping here:

gnumake -C code -f xca6ll.gmk EXTRA_TARGETS="mpseventcnv mpseventpy mpseventtxt mpseventsql"
xca6ll: xca6ll/cool/trans.o
trans.c:154:9: error: variable 'added' set but not used [-Werror,-Wunused-but-set-variable]
  Count added = 0;
        ^

Seems like progress, unless it's all going to fail later because I'm not using xcodebuild lol.

Jonathon McKitrick
--
'My other computer is your Windows box.'

Re: Helping with MPS

[Gerd Möllmann]

Jonathon McKitrick <jcm@SDF.ORG> writes:

> gnumake -C code -f xca6ll.gmk EXTRA_TARGETS="mpseventcnv mpseventpy mpseventtxt mpseventsql"
> xca6ll: xca6ll/cool/trans.o
> trans.c:154:9: error: variable 'added' set but not used [-Werror,-Wunused-but-set-variable]
>   Count added = 0;
>         ^

That could be

  https://github.com/Ravenbrook/mps/issues/279

see patch there. Sorry, I forgot about that.

> Seems like progress, unless it's all going to fail later because I'm
> not using xcodebuild lol.

Don't know if that's a supported build method on macOS, but what do i
know :-)? It should work though with the Xcode project...

Alternatively, brew install libmps is now an option, as others have said.

Re: Helping with MPS

[Helmut Eller]

On Wed, Aug 21 2024, Eli Zaretskii wrote:

>> > But if we fork, why not simply add it to the Emacs Git repository? why
>> > do we need a separate repository on GitHub?
>> 
>> Putting a fork on GitHub seems like the courteous thing to do IMO.
>
> Not sure I understand: courteous to whom?  If we are going to make
> Emacs-specific changes in the library, who else will find this fork
> useful except people that build and develop Emacs?

Maybe Ravenbrook would like to see what does and doesn't work with MPS.

Re: Helping with MPS

[Jonathon McKitrick via Emacs development discussions.]

On Wed, Aug 21, 2024 at 06:23:36PM +0200, Gerd Mllmann wrote:
: Jonathon McKitrick <jcm@SDF.ORG> writes:
: 
: > gnumake -C code -f xca6ll.gmk EXTRA_TARGETS="mpseventcnv mpseventpy mpseventtxt mpseventsql"
: > xca6ll: xca6ll/cool/trans.o
: > trans.c:154:9: error: variable 'added' set but not used [-Werror,-Wunused-but-set-variable]
: >   Count added = 0;
: >         ^
: 
: That could be
: 
:   https://github.com/Ravenbrook/mps/issues/279
: 
: see patch there. Sorry, I forgot about that.
: 
: > Seems like progress, unless it's all going to fail later because I'm
: > not using xcodebuild lol.
: 
: Don't know if that's a supported build method on macOS, but what do i
: know :-)? It should work though with the Xcode project...
: 
: Alternatively, brew install libmps is now an option, as others have said.

Success! I'm getting a t returned, and igc-stats!

Jonathon McKitrick
--
'My other computer is your Windows box.'

Re: Helping with MPS

[Gerd Möllmann]

Jonathon McKitrick <jcm@SDF.ORG> writes:

> Success! I'm getting a t returned, and igc-stats!

What did you do?

Re: Helping with MPS

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: pipcet@protonmail.com,  gerd.moellmann@gmail.com,  emacs-devel@gnu.org,
>   jcm@SDF.ORG
> Date: Wed, 21 Aug 2024 19:44:31 +0200
> 
> On Wed, Aug 21 2024, Eli Zaretskii wrote:
> 
> >> > But if we fork, why not simply add it to the Emacs Git repository? why
> >> > do we need a separate repository on GitHub?
> >> 
> >> Putting a fork on GitHub seems like the courteous thing to do IMO.
> >
> > Not sure I understand: courteous to whom?  If we are going to make
> > Emacs-specific changes in the library, who else will find this fork
> > useful except people that build and develop Emacs?
> 
> Maybe Ravenbrook would like to see what does and doesn't work with MPS.

If they want it, yes.  Maybe we should try talking to them before we
decide to fork.

Re: Helping with MPS

[Jonathon McKitrick via Emacs development discussions.]

On Wed, Aug 21, 2024 at 08:04:38PM +0200, Gerd Mllmann wrote:
: Jonathon McKitrick <jcm@SDF.ORG> writes:
: 
: > Success! I'm getting a t returned, and igc-stats!
: 
: What did you do?

I manually applied the patch you referred to, ran configure,
then make and make install. I added those 4 exports so
the emacs build could find the includes and libraries.

Then I re-ran emacs configure to enable mps, and then did
ran make. I ran from src rather than make install, and then
checked for the feature and for stats.

The initial stats window was empty, so I ran igc-collect
and then the stats page was populated.

Jonathon McKitrick
--
'My other computer is your Windows box.'

Re: Helping with MPS

[Gerd Möllmann]

Jonathon McKitrick <jcm@SDF.ORG> writes:

> On Wed, Aug 21, 2024 at 08:04:38PM +0200, Gerd Mllmann wrote:
> : Jonathon McKitrick <jcm@SDF.ORG> writes:
> : 
> : > Success! I'm getting a t returned, and igc-stats!
> : 
> : What did you do?
>
> I manually applied the patch you referred to, ran configure,
> then make and make install. I added those 4 exports so
> the emacs build could find the includes and libraries.
>
> Then I re-ran emacs configure to enable mps, and then did
> ran make. I ran from src rather than make install, and then
> checked for the feature and for stats.
>
> The initial stats window was empty, so I ran igc-collect
> and then the stats page was populated.

👍

Re: Helping with MPS

[Jonathon McKitrick via Emacs development discussions.]

On Wed, Aug 21, 2024 at 08:43:29PM +0200, Gerd Mllmann wrote:
: Jonathon McKitrick <jcm@SDF.ORG> writes:
: 
: > On Wed, Aug 21, 2024 at 08:04:38PM +0200, Gerd Mllmann wrote:
: > : Jonathon McKitrick <jcm@SDF.ORG> writes:
: > : 
: > : > Success! I'm getting a t returned, and igc-stats!
: > : 
: > : What did you do?
: >
: > I manually applied the patch you referred to, ran configure,
: > then make and make install. I added those 4 exports so
: > the emacs build could find the includes and libraries.
: >
: > Then I re-ran emacs configure to enable mps, and then did
: > ran make. I ran from src rather than make install, and then
: > checked for the feature and for stats.
: >
: > The initial stats window was empty, so I ran igc-collect
: > and then the stats page was populated.
: 
: ????

M-x igc-stats opens an empty window. I read that I can press
'c' in that window to collect stats, but it remains empty.

Perhaps I misunderstood, but I see now I can press 'c' to collect
or 's' for a snapshot, which does populate the window with stats.


Jonathon McKitrick
--
'My other computer is your Windows box.'

Re: Helping with MPS

[Gerd Möllmann]

Jonathon McKitrick <jcm@SDF.ORG> writes:

> M-x igc-stats opens an empty window. I read that I can press
> 'c' in that window to collect stats, but it remains empty.
>
> Perhaps I misunderstood, but I see now I can press 'c' to collect
> or 's' for a snapshot, which does populate the window with stats.

Sorry, I don't know what you are asking, or if you are asking something.

Maybe C-h f igc-stats RET or C-h b and so on in the statistics buffer
helps making things clearer.

Re: Helping with MPS

[Jonathon McKitrick via Emacs development discussions.]

Ok, I got everything working, a few weeks ago, actually.

Does it matter (for testing) if I use native compilation
mode or not? I'm on macOS.

Jonathon McKitrick
--
'There is no limit to stupidity. Space itself
is said to be bounded by its own curvature,
but stupidity continues beyond infinity.'

Re: Helping with MPS

[Gerd Möllmann]

Jonathon McKitrick <jcm@SDF.ORG> writes:

> Ok, I got everything working, a few weeks ago, actually.
>
> Does it matter (for testing) if I use native compilation
> mode or not? I'm on macOS.
>

That sounds good, thanks!

Regarding native compilation I'd say it's helpful because testing then
covers more ground, so to say, but it's not required.