On Sun, Dec 24, 2023 at 09:55:03AM +0800, Qian Yun wrote:
>
>
> On 12/24/23 09:41, Waldek Hebisch wrote:
> > > >
> > > > 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.
> >
>
> "When algebra returns to outer interpreter", the $timedNameStack
> in outer interpreter is not affected by inner interpreter.
> The total time spent in inner interpreter is accounted under
> "evaluation" of outer interpreter.
Well, deciding what to do in such situation is part
of solving problem. AFAICS before your patches inner
interpreter messed statistic variables of outer one,
and printing nothing in outer interpreter masked the
trouble. IMO when some code is aborted, but error is
caught and computation continues, we should count
time spent in aborted code. Which means that we should
ensure consitent statistics. This may require use of
different function than 'processInteractive' (or change
to 'processInteractive').
To put this differently: there is 'read' which separately
times toplevel expressions in a file, which requires recursive
timing. But we also have calls from algebra to interpreter
and those IMO should be timed togethere with toplevel call.
If we assume that recursive calls via 'processInteractive'
only deal with 'read' than you change looks OK.
> Can you give an example (inner interpreter catches exception)
> so that I can verify if it messes up stats accounting?
In algebra we can use: 'trapNumericErrors', 'trappedSpadEval'
and 'eval_with_timeout'. More can be added if needed. Code
executed by constructs above may call 'interpret',
'interpret_block' or other interpeter constructs. There is
also possibility of passing interpeter functions to algebra
code. Normaly, such functions are compiled, but sometimes
interpreter really interpret functions. I am not sure if
interpretation is allowed for functions passed to algebra,
but one can argue that they should be supported.
Note: part of problem is deciding which calls should do recursive
timings and how those should behave. Past behaviour is of
limited help here, as we want to fix trouble with current
code which probably will involve changing behaviour to more
desirable one.
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/ZYgMh-72ec1ofoq5%40fricas.org.
