[PATCH] Do not store stats information into symbol plist

21 views
Skip to first unread message

Qian Yun

unread,
Jan 16, 2024, 6:29:18 AM1/16/24
to fricas-devel
This is the first patch (of two) to enable correct collection
of statistics information on recursive calls to interpreter.

So instead of storing stats info into symbol plist of
$interpreterTimedNames and $interpreterTimedClasses, (which are
overwritten during recursive calls.) it now stores such info
into $statsInfo.

- Qian
60861acf1fbcd572303591d259781dd5b8979c44.patch

Qian Yun

unread,
Jan 16, 2024, 6:33:01 AM1/16/24
to fricas-devel
This is the second patch (of two) to enable correct collection
of statistics information on recursive calls to interpreter.

Move $statsInfo and other global variables required for timing
to the top of $timedNameStack.

Since $timedNameStack now has dynamic scope, recursive timing
is correctly supported after this patch.

- Qian
9eb6e0f240c686024676ce6e2ad99abbad4a8491.patch

Qian Yun

unread,
Jan 16, 2024, 7:07:29 AM1/16/24
to fricas-devel
Fix up:

diff --git a/src/interp/i-toplev.boot b/src/interp/i-toplev.boot
index 18f9f3db..bd0ec450 100644
--- a/src/interp/i-toplev.boot
+++ b/src/interp/i-toplev.boot
@@ -131,7 +131,7 @@ processInteractive(form, posnForm) ==
initializeTimedStack()
finally(
object := processInteractive0(form, posnForm),
- while $timedNameStack repeat stopTimingProcess peekTimedName())
+ while IFCDR $timedNameStack repeat stopTimingProcess
peekTimedName())
object

processInteractive0(form, posnForm) ==

- Qian

Waldek Hebisch

unread,
Jan 16, 2024, 7:50:14 AM1/16/24
to fricas...@googlegroups.com
On Tue, Jan 16, 2024 at 08:07:25PM +0800, Qian Yun wrote:
> Fix up:
>
> diff --git a/src/interp/i-toplev.boot b/src/interp/i-toplev.boot
> index 18f9f3db..bd0ec450 100644
> --- a/src/interp/i-toplev.boot
> +++ b/src/interp/i-toplev.boot
> @@ -131,7 +131,7 @@ processInteractive(form, posnForm) ==
> initializeTimedStack()
> finally(
> object := processInteractive0(form, posnForm),
> - while $timedNameStack repeat stopTimingProcess peekTimedName())
> + while IFCDR $timedNameStack repeat stopTimingProcess
> peekTimedName())
> object
>
> processInteractive0(form, posnForm) ==

Yes, thanks for catching this.

--
Waldek Hebisch

Waldek Hebisch

unread,
Jan 16, 2024, 7:55:10 PM1/16/24
to fricas...@googlegroups.com
On Tue, Jan 16, 2024 at 07:32:56PM +0800, Qian Yun wrote:
> This is the second patch (of two) to enable correct collection
> of statistics information on recursive calls to interpreter.
>
> Move $statsInfo and other global variables required for timing
> to the top of $timedNameStack.
>
> Since $timedNameStack now has dynamic scope, recursive timing
> is correctly supported after this patch.

This business with 'topFrame' looks fishy. Stack should be
a stack, but you effectively turn top item into a global
variable and push below it. I did not analyzed the whole
of the patch, but ATM moment my feeling is "there should be
better way".

--
Waldek Hebisch

Qian Yun

unread,
Jan 17, 2024, 5:33:10 AM1/17/24
to fricas...@googlegroups.com
OK, here is an alternative way:

Pack every variable that is related with stats to $statsInfo,
and make it a dynamic variable, along side with $timedNameStack.
(Otherwise we have to make 5 dynamic variables.)

Basically move the topFrame into an individual variable.

See attachment.

- Qian
stats-2.patch
stats-1.patch

Waldek Hebisch

unread,
Jan 22, 2024, 9:05:07 PM1/22/24
to fricas...@googlegroups.com
On Wed, Jan 17, 2024 at 06:33:05PM +0800, Qian Yun wrote:
> OK, here is an alternative way:
>
> Pack every variable that is related with stats to $statsInfo,
> and make it a dynamic variable, along side with $timedNameStack.
> (Otherwise we have to make 5 dynamic variables.)
>
> Basically move the topFrame into an individual variable.

Looks OK.

--
Waldek Hebisch

Qian Yun

unread,
Jan 23, 2024, 5:42:45 AM1/23/24
to fricas...@googlegroups.com
Patches committed.

Back to Ralf's original problem, it seems that most
"terminateSystemCommand" can be removed?

- Qian

Waldek Hebisch

unread,
Jan 23, 2024, 7:22:02 AM1/23/24
to fricas...@googlegroups.com
On Tue, Jan 23, 2024 at 06:42:40PM +0800, Qian Yun wrote:
> Patches committed.
>
> Back to Ralf's original problem, it seems that most
> "terminateSystemCommand" can be removed?

Probably. I am affraid that they require looking at the code
to see if they matter now. There is now a catch in
'doSystemCommand' so 'terminateSystemCommand' should do
no harm.

--
Waldek Hebisch
Reply all
Reply to author
Forward
0 new messages