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?
- 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
--
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/1d32621e-5f7d-474d-b024-636462990f4a%40gmail.com.
