Incoming release

[Waldek Hebisch]

As I wrote I would like to do release early in January, that
is quite soon. There are still some things to do:
- I would like to include root simplification package, it
needs some work to finish
- I would be good to have more bugs fixed
- the are still pending updates to documentation

Basically I would like to concentrate on "release critical"
things and do release 2-3 days after they are resolved.

--
Waldek Hebisch

[Qian Yun]

How do you suggest to proceed the "looping in recursive stats"
problem?

Can I commit the first patch "separate printTime from printType"?

https://github.com/oldk1331/fricas/commit/ae6e3012e6de1e5f91cd64ccb4dfadc53a5bb74f

- Qian

[Waldek Hebisch]

On Thu, Jan 04, 2024 at 07:12:33PM +0800, Qian Yun wrote:
> How do you suggest to proceed the "looping in recursive stats"
> problem?

ATM removing 'initializeTimedNames' from 'processInteractive' looks
like safest and simplest fix. But it needs a bit more testing.

Note: other changes may be desirable, but AFAICS this one fixes
problem with unbalanced '$timedNameStack' (that is allow loops
dropping excess entries to work).

> Can I commit the first patch "separate printTime from printType"?
>
> https://github.com/oldk1331/fricas/commit/ae6e3012e6de1e5f91cd64ccb4dfadc53a5bb74f

Yes, it looks very safe.

--
Waldek Hebisch

[Qian Yun]

On 1/6/24 06:05, Waldek Hebisch wrote:
> On Thu, Jan 04, 2024 at 07:12:33PM +0800, Qian Yun wrote:
>> How do you suggest to proceed the "looping in recursive stats"
>> problem?
>
> ATM removing 'initializeTimedNames' from 'processInteractive' looks
> like safest and simplest fix. But it needs a bit more testing.

2 problems:

1. "$timedNameStack" will keep growing when throw to toplevel, e.g:

1/0

2. "initializeTimedNames" also clears old stats information stored
in symbols of "$interpreterTimedNames". Otherwise the stats keep
accumulating.

This will not be a problem once I store the stats info in
"$timedNameStack".

- Qian

[Waldek Hebisch]

On Sat, Jan 06, 2024 at 09:00:53AM +0800, Qian Yun wrote:
>
>
> On 1/6/24 06:05, Waldek Hebisch wrote:
> > On Thu, Jan 04, 2024 at 07:12:33PM +0800, Qian Yun wrote:
> > > How do you suggest to proceed the "looping in recursive stats"
> > > problem?
> >
> > ATM removing 'initializeTimedNames' from 'processInteractive' looks
> > like safest and simplest fix. But it needs a bit more testing.
> 2 problems:
>
> 1. "$timedNameStack" will keep growing when throw to toplevel, e.g:
>
> 1/0

Yes, we need to do something with this.

> 2. "initializeTimedNames" also clears old stats information stored
> in symbols of "$interpreterTimedNames". Otherwise the stats keep
> accumulating.

Well, much of the trouble is that AFAICS in some cases we prefer
to keep accumulating stats. In other cases we want separate
stats (in particular for ')read' we want separate stats).

In short term I see two possibilities:
1) use my original patch
2) use your dynamic variable change to 'processInteractive'

Both changes get rid of crashes and consequently solve problem
in case when we do not need statistics. AFAICS both have
problem that commands that throw will be accounted in wrong
way, my patch will effectively ignore them, your will charge
time spent in inner context to outer context.

> This will not be a problem once I store the stats info in
> "$timedNameStack".

I think that still there will be issue: different ways of
calling interpreter should behave differently.

BTW: AFAICS trouble with system commands affects not only ')read':
many system commands use 'terminateSystemCommand' which throws to
reader. This aborts statement calling 'systemCommand'. And
effects on statistic subsystem are strange (IIUC system commands
normally are not subject to reporting statistics).

--
Waldek Hebisch

[Waldek Hebisch]

I am testing the attached patch. The 'i-syscmd.boot' part
prevents system command from throwing to reader, this should
prevent aborting code after 'systemCommand' in most cases (and
in remaining ones it debatable if code should continue).

The 'i-toplev.boot' part uses dynamic variable to make
sure that '$timedNameStack' is restored, but also executes
cleanup loop. AFAICS this is reasonably close to correct
behaviour and is simple to implement.

--
Waldek Hebisch

[Qian Yun]

Looks good.

Except that the "updateHist()" after that still uses '$timedNameStack',
so you should use $savedTimeStack to prevent resetting '$timedNameStack'
to NIL.

- Qian

[Waldek Hebisch]

On Mon, Jan 08, 2024 at 07:47:59PM +0800, Qian Yun wrote:
> Looks good.
>
> Except that the "updateHist()" after that still uses '$timedNameStack',

Yes.

> so you should use $savedTimeStack to prevent resetting '$timedNameStack'
> to NIL.

The attached patch handles this: cleanup is run only after all
real work is done.

--
Waldek Hebisch

[Qian Yun]

Well, in this case, there's no point of cleaning up:

Simply exit this dynamic scope will clean up $timedNameStack.

BTW, shall I commit my fixes of "enable recursive stats"
before or after release?

- Qian

[Waldek Hebisch]

On Tue, Jan 09, 2024 at 07:07:32PM +0800, Qian Yun wrote:
> Well, in this case, there's no point of cleaning up:
>
> Simply exit this dynamic scope will clean up $timedNameStack.
>
> BTW, shall I commit my fixes of "enable recursive stats"
> before or after release?

After.

--
Waldek Hebisch