From Newsgroup: comp.lang.misc

Since the forum has turned into an Algol68 discussion group, I have a
question of my own.

I want to run this short program:

------------------------------
PROC a = (INT in k, PROC INT xl, x2, x3, x4, x5) INT:(
INT k := in k;
PROC b = INT: a(k-:=1, b, xl, x2, x3, x4);
( k<=0 | x4 + x5 | b )
);

test:(
printf(($gl$,a(10, INT:1, INT:-1, INT:-1, INT:1, INT:0)))
)
------------------------------

This is one of the 'Man or Boy' examples from https://rosettacode.org/wiki/Man_or_boy_test#ALGOL_68.

But it keeps failing with stack overflow even if I increase it to 900MB
using '--stack "900000000"' (a billion is too much).

It only works if N (the '10' in the last line) is reduced to 8, but that
is too trivial.

Is it possible to make it work with N=10, or a bit more?


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 04/10/2025 19:58, bart wrote:

Since the forum has turned into an Algol68 discussion group, I have a question of my own.

I want to run this short program:

------------------------------
PROC a = (INT in k, PROC INT xl, x2, x3, x4, x5) INT:(
-a INT k := in k;
-a PROC b = INT: a(k-:=1, b, xl, x2, x3, x4);
-a ( k<=0 | x4 + x5 | b )
);

test:(
-aprintf(($gl$,a(10, INT:1, INT:-1, INT:-1, INT:1, INT:0)))
)
------------------------------

This is one of the 'Man or Boy' examples from https://rosettacode.org/ wiki/Man_or_boy_test#ALGOL_68.

But it keeps failing with stack overflow even if I increase it to 900MB using '--stack "900000000"' (a billion is too much).

It only works if N (the '10' in the last line) is reduced to 8, but that
is too trivial.

Is it possible to make it work with N=10, or a bit more?

I've done some experiments and it seems that "--stack" is ignored. If I
run this program:

INT count:=0;

PROC f = VOID: BEGIN
count +:= 1;
print((count, newline));
f
END;

f

Then it only counts up to 306 recursive calls before the stack
overflows, whatever the parameter to "--stack".

On 3.9.9, it's only 109! But on 2.8.4 on WSL, it is 2302.

Now, there is another option called "--frame", but that doesn't help
either. I've also tried --overhead --segment --heap. But this is crazy,
you shouldn't need to try random combinations of options.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 05/10/2025 11:54, bart wrote:

On 04/10/2025 19:58, bart wrote:

[...]
But it keeps failing with stack overflow even if I increase it to
900MB using '--stack "900000000"' (a billion is too much).

900M [or 1G] is less typing than "900000000", and clearer.

Is it possible to make it work with N=10, or a bit more?

I get N=10 and N=11 with 3.8.7, but N=12 fails the same way.

I've done some experiments and it seems that "--stack" is ignored.
If I run this program: [... snipped ...]
Then it only counts up to 306 recursive calls before the stack
overflows, whatever the parameter to "--stack".
On 3.9.9, it's only 109! But on 2.8.4 on WSL, it is 2302.
Now, there is another option called "--frame", but that doesn't help
either. I've also tried --overhead --segment --heap. But this is
crazy, you shouldn't need to try random combinations of options.

For once, I tend to agree. But I'm tolerably sure that the
real problem is not stack overflow at all. If you bung a "sweepheap"
into the code, the failure becomes "program too complex" with a ref
to "src/a68g/rts-heap.c: 244". ICBA to check further. You'd have to
ask Marcel; but my suspicion is that in view of the section on bugs
and limitations in the documentation, he'd shrug and say "yeah". He
wants and uses A68G to solve real problems in physics, numerical
analysis, etc., not to set records in depth of recursion. Or speed,
for that matter. BICBW.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Litolff
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 05/10/2025 17:48, Andy Walker wrote:

On 05/10/2025 11:54, bart wrote:

On 04/10/2025 19:58, bart wrote:

[...]
But it keeps failing with stack overflow even if I increase it to
900MB using '--stack "900000000"' (a billion is too much).

-a-a-a-a900M [or 1G] is less typing than "900000000", and clearer.

Is it possible to make it work with N=10, or a bit more?

-a-a-a-aI get N=10 and N=11 with 3.8.7, but N=12 fails the same way.

I've done some experiments and it seems that "--stack" is ignored.
If I run this program: [... snipped ...]
Then it only counts up to 306 recursive calls before the stack
overflows, whatever the parameter to "--stack".
On 3.9.9, it's only 109! But on 2.8.4 on WSL, it is 2302.
Now, there is another option called "--frame", but that doesn't help
either. I've also tried --overhead --segment --heap. But this is
crazy, you shouldn't need to try random combinations of options.

-a-a-a-aFor once, I tend to agree.-a But I'm tolerably sure that the
real problem is not stack overflow at all.-a If you bung a "sweepheap"
into the code, the failure becomes "program too complex" with a ref
to "src/a68g/rts-heap.c: 244".-a ICBA to check further.-a You'd have to
ask Marcel;-a but my suspicion is that in view of the section on bugs
and limitations in the documentation, he'd shrug and say "yeah".-a He
wants and uses A68G to solve real problems in physics, numerical
analysis, etc., not to set records in depth of recursion.-a Or speed,
for that matter.-a BICBW.

While we're all grateful that such a product exists, I'm not sure that
it is useful to make excuses for bugs and inconsistences, or to brush
them under the carpet.

I was able to run my benchmark on WSL, but as I showed in my other post,
WSL seems to have much a larger stack set up. Why is that?

I'm genuinely interested in why the size of the software stack of an interpreter (which seems to be only a few 10s of 10KB anyway) should
depend on the OS. Also why the stack size has decreased considerably (by
2/3) between 2.8.3 and 3.9.9.

He
wants and uses A68G to solve real problems in physics, numerical
analysis, etc., not to set records in depth of recursion

The stack should be a decent size. One that only allows 100-deep
recursion is hardly record-breaking! A typical default would allow 10K
at least (for calls with minimal stack frame size) and probably 100K
(EXE default stack sizes are 1MB-4MB).

Or speed, for that matter.

And yet some effort has been expanded in those compile/optimise options.
So speed matters enough.





--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 05/10/2025 18:56, bart wrote:

[...] I'm tolerably sure that the real
problem is not stack overflow at all.

***** NB! *****

[...]

I'm genuinely interested in why the size of the software stack of an interpreter (which seems to be only a few 10s of 10KB anyway) should
depend on the OS. Also why the stack size has decreased considerably
(by 2/3) between 2.8.3 and 3.9.9.

That seems remarkably unlikely. So I expect something else is
going on, eg a typo.

The stack should be a decent size.

Until proven otherwise, I think the failure has nothing at all
to do with the actual stack size. *You* reported that a 900MB stack
made no difference at all. To find out what the /actual/ problem is,
someone would have to delve into the innards of a large-ish C program.
Feel free to be the someone or to ask Marcel to comment. I've passed
on all that I know or can conjecture.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Litolff
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 05/10/2025 20:45, Andy Walker wrote:

On 05/10/2025 18:56, bart wrote:

[...] I'm tolerably sure that the real
problem is not stack overflow at all.

-a-a-a ***** NB! *****

[...]

I'm genuinely interested in why the size of the software stack of an
interpreter (which seems to be only a few 10s of 10KB anyway) should
depend on the OS. Also why the stack size has decreased considerably
(by 2/3) between 2.8.3 and 3.9.9.

-a-a-a-aThat seems remarkably unlikely.-a So I expect something else is going on, eg a typo.

The stack should be a decent size.

-a-a-a-aUntil proven otherwise, I think the failure has nothing at all
to do with the actual stack size.

While the 'manboy' example could well involve internal complexities, I
also posted a much simpler example (see below) that fails with "stack overflow" far earlier than expected (either 100 or 300 levels).

'Manboy' can require extensive recursion depth depending on N, so
actually running out of stack seems the most likely. Remember that with
N=10, it runs under Linux for example which seems to have a 10x higher
stack size, as the test below fails with a much higher count.

You even say yourself that it fails with a stack overflow with N=12:

I get N=10 and N=11 with 3.8.7, but N=12 fails the same way.

-a *You* reported that a 900MB stack
made no difference at all.

I think *that* is the problem! It didn't affect the result of that
simple program below; it should have.


Anyway this is for the maintainer to worry about if they are interested.
I've reported it via email.

You seem remarkably unbothered however!


---------------------
INT count:=0;

PROC f = VOID: BEGIN
count +:= 1;
print((count, newline));
f
END;

f
----------------------



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 05/10/2025 22:13, bart wrote:

Anyway this is for the maintainer to worry about if they are interested. I've reported it via email.

The email bounced, so I guess they are not that interested!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 05/10/2025 22:13, bart wrote:

While the 'manboy' example could well involve internal complexities,
I also posted a much simpler example (see below) that fails with
"stack overflow" far earlier than expected (either 100 or 300
levels).

Fails with a /reported/ stack overflow at depths varying
up to at least 2377, depending on the version but not on the
stack size. It seems more likely to me that the report is wrong
than that [small] changes the A68G code and [large] changes to
the stack size make no difference. Could be, for example, that
the error report is triggered by the number of frames exceeding
some limit that ought to be related to the stack size but is
actually somehow related to the version. Ie, to some typo in
the C code.

You seem remarkably unbothered however!

I've never triggered this bug in any real code of my own,
and there are limits to how far I want to delve into the innards
of 70K lines of C code written by someone else to track down a
bug in test programs written by other people. Esp as you're not
offering to pay for my services.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Litolff
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 05.10.2025 23:19, bart wrote:

On 05/10/2025 22:13, bart wrote:

Anyway this is for the maintainer to worry about if they are
interested. I've reported it via email.

The email bounced, so I guess they are not that interested!

From a technical bounce you impute a personal stance?

I'm in regular exchange with the maintainer since I started
to use Genie, and before that (quite some time ago) I also
had been in contact with him a few times with no problems.
And I'm using no secret information or anything like that.

Is, maybe, your email address or your email provider not
trustworthy so that the addressee's provider blocks "you"?

Janis
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 08/10/2025 01:34, Janis Papanagnou wrote:

On 05.10.2025 23:19, bart wrote:

On 05/10/2025 22:13, bart wrote:

Anyway this is for the maintainer to worry about if they are
interested. I've reported it via email.

The email bounced, so I guess they are not that interested!

From a technical bounce you impute a personal stance?

I'm in regular exchange with the maintainer since I started
to use Genie, and before that (quite some time ago) I also
had been in contact with him a few times with no problems.
And I'm using no secret information or anything like that.

Is, maybe, your email address or your email provider not
trustworthy so that the addressee's provider blocks "you"?

Janis

Not long ago, I tried to send an email to the address Bart uses on
Usenet, and that email bounced. (It wasn't particularly important -
just a "nice to see you back in comp.lang.c as the group is more
interesting with your posts" message.) Perhaps there is a problem with
Bart's email. Bart, I sent you a test email - if you did not receive
it, you might have something wrong.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 13/10/2025 21:44, David Brown wrote:

On 08/10/2025 01:34, Janis Papanagnou wrote:

On 05.10.2025 23:19, bart wrote:

On 05/10/2025 22:13, bart wrote:

Anyway this is for the maintainer to worry about if they are
interested. I've reported it via email.

The email bounced, so I guess they are not that interested!

-aFrom a technical bounce you impute a personal stance?

I'm in regular exchange with the maintainer since I started
to use Genie, and before that (quite some time ago) I also
had been in contact with him a few times with no problems.
And I'm using no secret information or anything like that.

Is, maybe, your email address or your email provider not
trustworthy so that the addressee's provider blocks "you"?

Janis

Not long ago, I tried to send an email to the address Bart uses on
Usenet, and that email bounced.-a (It wasn't particularly important -
just a "nice to see you back in comp.lang.c as the group is more
interesting with your posts" message.)-a Perhaps there is a problem with Bart's email.-a Bart, I sent you a test email - if you did not receive
it, you might have something wrong.

If you mean bc@freeuk.com, that hasn't worked for a decade or two. I had several with that provider, but they became choked with spam and were
rarely used.

Eventually the provider switched to paid-for accounts, with better filters.

There seemed little need to have a valid email for usenet. The odd
person who wanted to send an actual email was told to either use bcas,
or gmail using bart4858.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 13/10/2025 23:30, bart wrote:

On 13/10/2025 21:44, David Brown wrote:

On 08/10/2025 01:34, Janis Papanagnou wrote:

On 05.10.2025 23:19, bart wrote:

On 05/10/2025 22:13, bart wrote:

Anyway this is for the maintainer to worry about if they are
interested. I've reported it via email.

The email bounced, so I guess they are not that interested!

-aFrom a technical bounce you impute a personal stance?

I'm in regular exchange with the maintainer since I started
to use Genie, and before that (quite some time ago) I also
had been in contact with him a few times with no problems.
And I'm using no secret information or anything like that.

Is, maybe, your email address or your email provider not
trustworthy so that the addressee's provider blocks "you"?

Janis

Not long ago, I tried to send an email to the address Bart uses on
Usenet, and that email bounced.-a (It wasn't particularly important -
just a "nice to see you back in comp.lang.c as the group is more
interesting with your posts" message.)-a Perhaps there is a problem
with Bart's email.-a Bart, I sent you a test email - if you did not
receive it, you might have something wrong.

If you mean bc@freeuk.com, that hasn't worked for a decade or two. I had several with that provider, but they became choked with spam and were
rarely used.

OK. I was just checking it was not an unknown problem.

You might want to change your Usenet email to something obviously
invalid if you don't want to have a working email there. I understand
why you might not want to use a working email, but it's nice to make
that clear in case someone wants to contact you directly.

Eventually the provider switched to paid-for accounts, with better filters.

There seemed little need to have a valid email for usenet. The odd
person who wanted to send an actual email was told to either use bcas,
or gmail using bart4858.

--- Synchronet 3.21a-Linux NewsLink 1.2