Re: macOS status

"Kirill A. Korinsky" <[email protected]> Wed, 27 Dec 2023 23:53:06 +0100
Newsgroups	gmane.lisp.gcl.devel
Message-ID	<[email protected]>
> On 26. Dec 2023, at 14:03, Camm Maguire <[email protected]> wrote:
> 
> Thank you for the link to the 'github/macports/runs' area.  I may need a
> little tutorial on how to parse the information there.  Have there been
> three attempts for example?  The last one is marked green, but there
> appears to be no build log there.

Yes, because macOS 13 build fails. I've skip it with hope that macOS 11 and macOS 12 pass. No, it doesn't.

My guess that this machine has very limited amount of RAM (14 Gb if I not mistaken) and simple can't build it, thus using of GCL_MEM_MULTIPLE leads to a crash.

As a dirty hack, to make it works, I've tried this patch:

> --- a/gcl/o/main.c
> +++ b/gcl/o/main.c
> @@ -266,8 +266,8 @@ get_gc_environ(void) {
> 
>    mem_multiple=1.0;
>    if ((e=getenv("GCL_MEM_MULTIPLE"))) {
> -    massert(sscanf(e,"%lf",&mem_multiple)==1);
> -    massert(mem_multiple>=0.0);
> +    mem_multiple=atof(e);
> +    massert(mem_multiple>0.0);
>    }
> 
>    gc_alloc_min=0.05;

but it doesn't help.

Anyway, as soon as we stabilise build on my laptop which has a lot of RAM, I'll try to reproduce this issue on VM with less memory.

> Do I understand correctly that 'gcl-devel' has not yet successfully
> built here, but has in your private environment, using exactly the same
> code?  I'm a little confused as the failing log indicates the
> posix_spawn has not been applied.

Yes, I have suceffuly build it on my laptop via `port build` which is used on Github CI, but it fails outside of MacPorts and on CI as well.

> Frame stack overflows have nothing to do with excessive memory usage,
> and simply refers to the rather limited static internal stack GCL keeps
> around to track frames.  This can be expanded at the configure command
> line, but I doubt that would help as this usually is a symptom of some
> other error.
> 
> I have a github account.  Is there any way to get remote ssh access into
> this environment so I can see what is going on?

Unfortunately no, you may fork this repository and push to your fork and use github CI to build it, but without any SSH access.

So, old school print debugging :(

--
wbr, Kirill
signature.asc (application/pgp-signature, 833 B)