On Sun, Dec 24, 2023 at 08:59:49AM +0800, Qian Yun wrote:
>
>
> On 12/23/23 22:55, Waldek Hebisch wrote:
> > On Fri, Dec 22, 2023 at 07:28:32PM +0800, Qian Yun wrote:
> > >
> > >
> > > On 12/20/23 09:58, Waldek Hebisch wrote:
> > > > On Wed, Dec 20, 2023 at 08:03:02AM +0800, Qian Yun wrote:
> > > > >
> > > > > You mean current problem with nested stats collection?
> > > > > If using each '$timedNameStack is in its own dynamic scope,
> > > > > then there will be no problem.
> > > >
> > > > There is a problem: we need to run 'stopTimingProcess' with
> > > > correct argument, othewise we will charge resources to
> > > > wrong group. And once '$timedNameStack' is poped we lost
> > > > info about group. So we need to run 'stopTimingProcess'
> > > > before restoring previous value of '$timedNameStack'.
> > > > Current loop works here. Calling '$timedNameStack' in
> > > > UNWID-PROTECT cleanup could work too. Just restoring
> > > > '$timedNameStack' as dynamic variable will miss
> > > > calls to 'stopTimingProcess' leading to wrong accounting.
> > > >
> > >
> > > I thought more about this and realized the key differences between:
> > >
> > > 1. modifying a dynamic variable
> > > 2. creating a new dynamic binding, shadowing the old dynamic variable
> > >
> > > So I think following patch fix the loop in
> > > interpret_block("1+1")$Lisp
> > > perfectly. '$timedNameStack' is still balanced.
> > >
> > > WDYT?
> >
> > Well, with this '$timedNameStack' is balanced. But there is still
> > trouble with acconting: since 'stopTimingProcess' was not called
> > we will either ignore or assign to wrong context resources used
> > in context that did 'THROW'.
>
> If there's throw to top level, then stats will not be printed,
> so there's no need to continue collect stats.
Forget about toplevel. This tread is above recursive calls.
In particular algebra may perform call to interpreter and
catch errors. When algebra returns to outer interpreter
we should print statistics. Similar thing happens inside
interpreter.
BTW: It is debatable if not printing stats in case of errors
is right thing to do.
> And '$timedNameStack' will leave this dynamic scope and reinit in
> next call, so it will not affect future accountings.
That is true.
> > > - Qian
> > >
> > > diff --git a/src/interp/i-toplev.boot b/src/interp/i-toplev.boot
> > > index 20b4773c..03a3c870 100644
> > > --- a/src/interp/i-toplev.boot
> > > +++ b/src/interp/i-toplev.boot
> > > @@ -130,6 +130,7 @@ processInteractive(form, posnForm) ==
> > > -- and then calls processInteractive1 to do most of the work.
> > > -- This function receives the output from the parser.
> > >
> > > + $timedNameStack : local := NIL
> > > initializeTimedNames($interpreterTimedNames,$interpreterTimedClasses)
> > >
> > > $op: local:= (form is [op,:.] => op; form) --name of operator
> >
> > I think that we need something like:
> >
> > $timedNameStack : local := NIL
> > finally(
> >
> > (initializeTimedNames($interpreterTimedNames,$interpreterTimedClasses);
> > object := processInteractive1(form, posnForm)),
> > while $timedNameStack repeat stopTimingProcess peekTimedName();
> > )
> >
> > Note: this looks obscure, but first thing is normal code, second in
> > cleanup that is executed both during normal return and in case of
> > abnormal exit ('THROW', Lisp exceptions).
> >
>
> You mean 'finally' to catch all exceptions? Wouldn't that conflict
> with ')set break break/etc...' handlers?
Well, ')set break break' should give unmolested stack to debugger,
before stack unwinding and cleanups. In case of 'THROW' or
exceptions: once the cleanup part is done 'THROW' (or exception)
is supposed to propagate further as if nothing happended. In principle
there may be some confusion when cleanup code throws errors,
but intention is that cleanups should consist of safe code
which does not cause errors.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/ZYeMYn9rwvyDdImj%40fricas.org.
