On Sun, Dec 17, 2023 at 10:49:14AM +0800, Qian Yun wrote:
> 
> 
> On 12/17/23 09:46, Waldek Hebisch wrote:
> > On Wed, Dec 13, 2023 at 07:44:16PM +0800, Qian Yun wrote:
> > > Now I have a series of 7 patches, hopefully to solve this problem.
> > > 
> > > You can view them in attachment or at
> > > https://github.com/oldk1331/fricas/commits/stats
> > > 
> > > I'm not very sure about
> > > "reinit stats global variables when error happens".
> > > 
> > > Is "int_loop" the right place to reset $timedNameStack
> > > when error happens? (e.g. "1/0").
> > 
> > The code looks mostly good.  But concerning reseting $timedNameStack
> > I am not sure what to do.  Typical pattern in interpreter is
> > use of Lisp dynamic variables.  When something THROW-s, then
> > dynamic variables are automatically restored to value they had
> > at outer level.  Reseting in different way is problematic,
> 
> Yes, I tried to use dynamic variables, aka ":local" variable
> in BOOT.  But I failed.  Now that you mentioned it, I tried again:
> 
> ====
> diff --git a/src/interp/i-map.boot b/src/interp/i-map.boot
> index cbe7aa3c..c3a3620b 100644
> --- a/src/interp/i-map.boot
> +++ b/src/interp/i-map.boot
> @@ -630,13 +630,10 @@ interpMap(opName,tar) ==
>    $mapName : local := opName
>    $mapTarget : local := tar
>    body:= get(opName,'mapBody,$e)
> -  savedTimerStack := COPY $timedNameStack
>    catchName := mapCatchName $mapName
>    c := CATCH(catchName, interpret1(body,tar,nil))
>  --  $interpMapTag and $interpMapTag ~= mapCatchName $mapName =>
>  --    THROW($interpMapTag,c)
> -  while savedTimerStack ~= $timedNameStack repeat
> -    stopTimingProcess peekTimedName()
>    c  -- better be a triple
> 
>  analyzeDeclaredMap(op,argTypes,sig,mapDef,$mapList) ==
> diff --git a/src/interp/i-toplev.boot b/src/interp/i-toplev.boot
> index 20b4773c..54e87a15 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
> @@ -259,10 +260,7 @@ printStorage() ==
>  interpretTopLevel(x, posnForm) ==
>    --  Top level entry point from processInteractive1.  Sets up catch
>    --  for a thrown result
> -  savedTimerStack := COPY $timedNameStack
>    c := CATCH('interpreter,interpret(x, posnForm))
> -  while savedTimerStack ~= $timedNameStack repeat
> -    stopTimingProcess peekTimedName()
>    c = 'tryAgain => interpretTopLevel(x, posnForm)
>    c
> 
> ====
> 
> So the "$timedNameStack : local" declaration is the key here.

For just restoring value there is construction:

fun1(x, $var) ==
    -- do work

fun(x) == fun1(x, $var)

The effect is that 'fun1' uses current value of '$var' but any
changes inside 'fun1' are discarde when 'fun1' resturns (Lisp
restores value that '$var' had at entry to 'fun1').

> > BTW: AFAICS first patch and the last one are somewhat independent,
> > but to other seem to be tightly related, so it looks
> > unnatural to split this part into 5 patches.
> > 
> 
> I break them down so that it's easier for me to write and test,
> and easier for reviewers.
> 
> How about let's proceed like this:
> 
> 1. apply the patch in this mail, to prevent infinity recursion

I am affraid that we need to do something in 'interpMap' in (i-map.boot).

> 2. apply your patch, to allow evaluation after "systemCommand"
> 3. apply my first patch in branch "stats", to separate printTime
> from printType
> 
> Then I will do some minor changes to the code to allow recursive
> timing, and let's discuss that in another thread.

-- 
                              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/ZX8aMy7AIRlKl8jt%40fricas.org.

Reply via email to