2045 cfg implement abs int driver #2050

mayanje · 2021-10-15T07:43:35Z

What have been done

The interface IMultiBranchContext is removed
The class MultiBranchContext is moved in Graph namespace
CfgAbstractInterpretation class is added in Graph with Environment and Metrics subclasses, and also IObserver interface.
Test cases have been added in BasicAbstractInterpretationTest

TypeCobol.Analysis/Graph/BasicBlock.cs

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.cs

fm-117 · 2021-10-15T11:58:27Z

TypeCobol.Analysis/Graph/MultiBranchContext.cs

+    /// <summary>
+    /// The context of a Multi Branch instruction like IF or Evaluate.
+    /// </summary>
+    public class MultiBranchContext<N, D> : System.ICloneable


Now that the abstract interpretation is done parser-side, the context class does not need to be public. But ok we can keep it that way.

It is used in qualis test

You mean in unit tests or in the analyzer code ?

In analyzer code

This could be a problem then because we have to ensure all blocks or block indexes publicly exposed through this class are the 'final' ones otherwise we'll have to give access to the relocation map (which we don't want).
the MultiBranchContext may not be required with this new observer mechanism on the abstract interpretation.

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

fm-117 · 2021-10-15T15:58:04Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// <summary>
+            /// The Abstract Interpretation Stack
+            /// </summary>
+            private Stack<BasicBlock<N, D>> InterpretationStack { get; set; }


readonly field _interpretationStack

done in dc9a4c4

fm-117 · 2021-10-15T15:58:33Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// <summary>
+            /// The DFS Run stack
+            /// </summary>
+            private Stack<BasicBlock<N, D>> DFSStack;


readonly + rename (_dfsStack)

done in dc9a4c4

fm-117 · 2021-10-15T15:59:09Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// <summary>
+            /// Already Visited Block
+            /// </summary>
+            private System.Collections.BitArray Visited;


readonly + rename (_visited)

done in dc9a4c4

fm-117 · 2021-10-15T16:01:17Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// <summary>
+            /// Some metrics calculated.
+            /// </summary>
+            public readonly Metrics Metrics;


readonly property ?

fm-117 · 2021-10-15T16:02:47Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+                        IterateBlock(block);
+                        BasicBlock<N, D> nextFlowBlock = null;
+
+                        // Track Branching blocks
+                        if (block.Context != null)
+                        {                            
+                            nextFlowBlock = InterpretContext(block);
+                        }
+
+                        LeaveBlock(block);


Exactly ! Look at the pseudo-code I wrote, you can see clearly the three step one line above each other so the Enter - Interpret - Leave workflow is obvious for the reader.

But it's ok, we can keep it like that.

fm-117 · 2021-10-15T16:07:40Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+                            foreach (var edge in block.SuccessorEdges)
+                            {
+                                if (Cfg.SuccessorEdges[edge] == nextFlowBlock)
+                                {
+                                    Metrics.EdgeCount++;
+                                }
+                            }


Equivalent to Metrics.EdgeCount++ ? Among the successors there would be multiple edges to the same block ?
I think I need an example to see how this next flow block special case work.

Ok you are right better to do: Metrics.EdgeCount += block.SuccessorEdges.Count;
I wanted to match the execution process and to have the same result, but after checking, it appers that no.
done in dc9a4c4

fm-117 · 2021-10-15T16:08:52Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// <param name="block"></param>
+            private void IterateBlock(BasicBlock<N, D> block)
+            {
+                if (_observers != null)


You should keep the condition && block.Instructions != null because here we actually use them.

done in dc9a4c4

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Metrics.cs

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

fm-117 · 2021-10-18T11:02:31Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// <summary>
+            /// The DFS Run stack
+            /// </summary>
+            private Stack<BasicBlock<N, D>> _dFSStack;


naming _dfsStack

Ok for all your suggestion,, but I suggest to keep Cfg public so that observers that receive the evironment instance thru IObserver interface can accessed thru the environment instance to which graph the current execution is associted

fm-117 · 2021-10-18T11:03:09Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// Current CFG being run.
+            /// </summary>
+            public ControlFlowGraph<N, D> Cfg { get; private set; }
+            private IObserver[] _observers;


readonly as it is set only at construction time.

done in a840251

smedilol · 2021-10-25T06:36:11Z

TypeCobol.Analysis.Test/BasicCfgInstrs/ComplexGotoPara0.int

@@ -0,0 +1,34 @@
+Entering block : 0


This program gives the following result when run:

IN PARA-A IN PARA-C IN PARA-F IN PARA-G

So is the result of the file the reflect of a running program or something else ?

A CFG reflect all possible executions of a program. But in reality this can represent exponential possibilities, so Abstract interpretation can only be view of a subset of all possibilities.
But the most important thing here we are just implementing a driver, we don't evaluate variable value to decide for instance what to do in the instruction GO TO PARA-E PARA-F PARA-G DEPENDING ON m
depending on the value of m.
We are not intrepreting the COBOL program.

The comment on the default execution performed is added. 7f8af6b
Not all possible execution paths can be followed, in this default implementation. But it is the base for other execution scheme.

What about this code:

IDENTIFICATION DIVISION. PROGRAM-ID. MyPGM. DATA DIVISION. WORKING-STORAGE SECTION. 01 Group1. 05 X pic X occurs 100 indexed by Idx. 05 Y pic X occurs 50 indexed by Idx2. PROCEDURE DIVISION. MOVE 0 TO IDX2 PERFORM VARYING Idx FROM 1 BY 1 UNTIL Idx > 100 IF (IDX2 < 50) PERFORM ADD-ITEM END-IF END-PERFORM * Ko, ADD-ITEM increment Idx2 without enclosing IF PERFORM ADD-ITEM goback . ADD-ITEM. display "ADD-ITEM" ADD 1 TO Idx2 MOVE X(Idx) TO Y(IDX2) perform DisplayELt . DisplayELt. display "X(Idx)=" X(Idx) . END PROGRAM MyPGM.

Paragraph ADD-ITEM is called outside of an IF statement (just before the goback), and our custom quality rule must detect it.

Does this PR handle this case?
On my execution I get:

MOVE 0 TO IDX2 Entering block : 1 PERFORM VARYING Idx FROM 1 BY 1 UNTIL Idx > 100 Leaving block : 1 Entering block : 2 IF (IDX2 < 50) Entering block : 3 Leaving block : 3 Entering block : 4 PERFORM ADD-ITEM Leaving block : 4 Entering block : 5 Leaving block : 5 Leaving block : 2 Entering block : 6 Leaving block : 6 Leaving block : 0 Entering block : 7 Leaving block : 7 Entering block : 8 PERFORM ADD-ITEM Leaving block : 8 Entering block : 9 goback Leaving block : 9

which is not clear for me if the paragraph ADD-ITEM if the driver will pass on it 2 times.

Yes this the result:
--- Diagnostics ---
Line 9[12,27] <47, Warning, CodeAnalysis> - [Qualis] Protect table index increment (Incremented table index indX was not conditionnaly protected by IF or PERFORM UNTIL clause.)
Line 24[12,25] <47, Warning, CodeAnalysis> - [Qualis] Protect table index increment (Incremented table index indX was not conditionnaly protected by IF or PERFORM UNTIL clause.)

That is to say:
MOVE 0 TO IDX2
and
ADD 1 TO Idx2

Are detected.

smedilol · 2021-11-02T09:42:07Z

TypeCobol.Analysis.Test/BasicCfgInstrs/ComplexGotoPara0.int

@@ -0,0 +1,34 @@
+Entering block : 0


What about this code:

IDENTIFICATION DIVISION. PROGRAM-ID. MyPGM. DATA DIVISION. WORKING-STORAGE SECTION. 01 Group1. 05 X pic X occurs 100 indexed by Idx. 05 Y pic X occurs 50 indexed by Idx2. PROCEDURE DIVISION. MOVE 0 TO IDX2 PERFORM VARYING Idx FROM 1 BY 1 UNTIL Idx > 100 IF (IDX2 < 50) PERFORM ADD-ITEM END-IF END-PERFORM * Ko, ADD-ITEM increment Idx2 without enclosing IF PERFORM ADD-ITEM goback . ADD-ITEM. display "ADD-ITEM" ADD 1 TO Idx2 MOVE X(Idx) TO Y(IDX2) perform DisplayELt . DisplayELt. display "X(Idx)=" X(Idx) . END PROGRAM MyPGM.

Paragraph ADD-ITEM is called outside of an IF statement (just before the goback), and our custom quality rule must detect it.

Does this PR handle this case?
On my execution I get:

MOVE 0 TO IDX2 Entering block : 1 PERFORM VARYING Idx FROM 1 BY 1 UNTIL Idx > 100 Leaving block : 1 Entering block : 2 IF (IDX2 < 50) Entering block : 3 Leaving block : 3 Entering block : 4 PERFORM ADD-ITEM Leaving block : 4 Entering block : 5 Leaving block : 5 Leaving block : 2 Entering block : 6 Leaving block : 6 Leaving block : 0 Entering block : 7 Leaving block : 7 Entering block : 8 PERFORM ADD-ITEM Leaving block : 8 Entering block : 9 goback Leaving block : 9

which is not clear for me if the paragraph ADD-ITEM if the driver will pass on it 2 times.

mayanje · 2021-11-04T07:39:45Z

@smedilol "which is not clear for me if the paragraph ADD-ITEM if the driver will pass on it 2 times."
The answer is yes, it will be considered 2 times.

mayanje · 2021-11-09T07:56:07Z

Due to important observations by @smedilol the abstract interpretation algorithm has been improved.
The new algorithm is no longer based on marking visited blocks, any block can be visited several times, therefore a cyclic threshold is used to avoid infinite recursion on cyclic blocks. See 203b206

fm-117 · 2021-11-10T08:31:50Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

+            //Create the real perform block context for abstract interpretation
+            //This is not the context of the perform block.
+            ctx.OriginBlock.Context = null;
+            MultiBranchContext<Node, D> ctxPerform = new MultiBranchContext<Node, D>(perform);
+            ctxPerform.Start(ctx.Branches[0]); //Branches[0] is the perfom block
+            ctxPerform.AddBranch(ctx.Branches[1]); //Branches[1] i sthe perform body block
+            ctxPerform.BranchIndices.Add(ctx.BranchIndices[1]); //BranchIndices[1] is index in the SuccessorEdge of the perfomr body block.
+            ctxPerform.Terminals = terminals;


There are multiple typos:

Line 2209: 'the perform block'

Line 2210: 'Branches[1] is the perform'

Line 2211: 'perform body block'

About the comment '//This is not the context of the perform block.', I'm confused. If you call Start on the perform block, this will actually attach this context to the block so it looks like it is truly its context.

Also we previously did not need to create a MultiBranchContext to represent perform loops, if we need it now for abstract interpretation does it mean that all blocks having multiple successors require in fact a MultiBranchContext ?

In fact only Control Flow instruction needs a MultiBranchContext. The first context calculated was only for constructing the graph, but the execution context of the PerformLoop is the one abtained after knowing the branching depending if it was in iterative perfotm or not.

done in 7c56456

"Control Flow Instructions" and "Blocks having multiple successors" are not the same thing ?

fm-117 · 2021-11-10T08:32:49Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// <summary>
+            /// The Cyclic relation from one block index to another block index
+            /// </summary>
+            private Dictionary<int, HashSet<int> >_cyclicRelation;


Spacing

This is the transitive closure for each block I guess. Why do we need to compute it before running ?
Let's say we keep a dictionary that gives for each block the number of times we visited it. Upon entering the block we check this number against the threshold and increment it before continuing.

Also this last commit adds much complexity to the abstract interpretation algorithm. What about letting the client decide for each block if it needs to visit it again ? By changing the EnterBlock method or the interface IObserver, we could add this capability and this would split the compexity between the abstract runner and its observer while being more flexible.

The _cyclicRelation is only for remembering which relation (which transition) leads to a cycle, it is not the entire transtive closure relation of the graph. So it is now called _cyclicTransition.
We just want to limit how many time a cyclic transition will be executed to avoid infinite transitions. otherwise there is no limitation on the number of time a non cyclic transition can be executed.

I understood that, I know we have to limit the number of times a block is visited. My idea is to let the client decide instead of fixing a maximum for all blocks.

How can client decides on block he doesn't know? the cyclicExecutionThreshold is already a parameter of the method, do you mean that we should add an option for that? even more we don't know in adance what transition will be cyclic.
So there can only be an unique threshold for each block.

fm-117 · 2021-11-10T08:46:35Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// <summary>
+            /// Number maximal of cyclic execution for a block index.
+            /// </summary>
+            private int _cyclicExecutionThresold ;


Typo: _cyclicExecutionThreshold

done in 7c56456

fm-117 · 2021-11-10T08:48:50Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+                if (_interpretationStack == null)
+                    _interpretationStack = new Stack<BasicBlock<N, D>>();
+                if (_dfsStack == null)
+                    _dfsStack = new Stack<BasicBlock<N, D>>();
+                _metricUpdated = new System.Collections.BitArray(Cfg.AllBlocks.Count);
+                if (_cyclicThreshold == null)
+                    _cyclicThreshold = new Dictionary<int, int>();
+                else
+                    _cyclicThreshold.Clear();
+                if (_cyclicRelation == null)
+                    _cyclicRelation = new Dictionary<int, HashSet<int>>();
+                else
+                    _cyclicRelation.Clear();


Now that we have more fields to initialize, I think it is cleaner to do all the the initializations in the constructor and create a private Reset method for those that need to be cleared. This would also allow to mark fields as readonly.

It is renamed Reset, no need to have it in the constructor, beacuse it is any call to Run that need to Reset value.

done in 7c56456

Init operations in constructor and Clear operations in Reset, this would avoird testing for null at each run. This was my idea but ok to keep it like this.

fm-117 · 2021-11-10T08:55:58Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// <summary>
+            /// Current Cyclic execution Thresold by block index.
+            /// </summary>
+            private Dictionary<int,int> _cyclicThreshold;


done in 7c56456

Still missing a space after int,

fm-117 · 2021-11-10T09:19:25Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+                    }
+                }
+
+                bool CanExecute(BasicBlock<N, D> b)


Why a CanExecute and CanAddExecution ? Why checking the value twice ?

/// CanExecute is used during execution to check for a block that contributes to a cycle,
/// if can be executed, that is to say if its cyclic threshold is not consumed.
/// Other blocks are always executed.

/// CanAddExecution Checks if a transition from one block to another can be pushed as to be executed.
/// For a transition that can leads to a cycle, the cyclic threshold value is decreased, if the threshold
/// is consumed the transition cannot be executed.

smedilol · 2021-11-18T09:01:43Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// </summary>
+            public void SetCyclicityThreshold()
+            {
+                BitSet _domain = new BitSet();


Why prefix local variable with _ ?

Changed in 98d7aaa

smedilol · 2021-11-18T09:03:11Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+                        var sb = Cfg.SuccessorEdges[s];
+                        int b = sb.Index;


Can you use more meaningful variable name.
Like:

Suggested change

var sb = Cfg.SuccessorEdges[s];

int b = sb.Index;

int blockBIndex = Cfg.SuccessorEdges[s].Index;

Changed in 98d7aaa

fm-117 · 2021-11-18T08:47:53Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+        /// The default execution performed is based on a dfs algorithm, with exception that
+        /// branching instructions are handled specifically.
+        /// Thus not all execution paths are applied, but all nodes are visited using dfs like algorithm if they are accessible.
+        /// A node cannot be visited twice.


This comment is now obsolete with the cyclicity threshold mechanism.

done in a049ba1

fm-117 · 2021-11-18T08:53:56Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+                Stack<int> _stack = new Stack<int>();
+
+                //Compute the domain
+                Cfg.DFS((block, incomingEdge, predecessorBlock, graph) => { _domain.Set(block.Index); return true; });


Does not take into account group blocks.

Yes, abstract interpretation like dfa analysis can only be performed on grapth generated using Extended or WithDfa mode. I know tests are executed by default in Standard mode, thus the algorithm doesn't go in group blocks. But for tracing execution steps it is not really important here.

fm-117 · 2021-11-18T09:16:06Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// <summary>
+            /// Current Cyclic execution Thresold by block index.
+            /// </summary>
+            private Dictionary<int,int> _cyclicThreshold;


Still missing a space after int,

fm-117 · 2021-11-18T09:16:22Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+            /// <summary>
+            /// The Cyclic transition from one block index to another block index
+            /// </summary>
+            private Dictionary<int, HashSet<int> >_cyclicTransition;


done in a049ba1

fm-117 · 2021-11-18T09:19:23Z

TypeCobol.Analysis/Graph/CfgAbstractInterpretation.Environment.cs

+                            dfs(b);
+                        }
+                        int _na = Visited(a);
+                        _nb = Visited(b);


Should be in the previous if body as if we don't DFS the block the value won't change.

done in a049ba1

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

fm-117

Ok for me, the last remaining thing is my remark about the MultiBranchContext (see https://github.com/TypeCobolTeam/TypeCobol/pull/2050/files#r740842228). We should try to keep it internal because of the cloned/relocated blocks.

I've not checked how this PR would impact the code in our private analyzer, but ideally the context is used by the Abstract Interpretation driver but not exposed to observers.

mayanje added 2 commits October 14, 2021 17:35

WI #2045 Implement Abstract Interpretation

24bd256

WI #2045 make public MultiBranchContext

8b88898

mayanje requested review from smedilol and fm-117 October 15, 2021 07:43

mayanje self-assigned this Oct 15, 2021

trafico-bot bot added the 🔍 Ready for Review Pull Request is not reviewed yet label Oct 15, 2021

mayanje added 2 commits October 15, 2021 09:48

WI #2045 comment change

494b9d8

WI #2045 Add missing file

7ae0f3c

fm-117 requested changes Oct 15, 2021

View reviewed changes

mayanje added 2 commits October 15, 2021 15:51

WI #2045 Change review

7e780a9

WI #2045 better handling 1 branch in multi branch case.

95f2622

fm-117 self-requested a review October 15, 2021 15:37

fm-117 requested changes Oct 15, 2021

View reviewed changes

trafico-bot bot added ⚠️ Changes requested Pull Request needs changes before it can be reviewed again and removed 🔍 Ready for Review Pull Request is not reviewed yet labels Oct 15, 2021

WI #2045 Change Review

dc9a4c4

trafico-bot bot added 🔍 Ready for Review Pull Request is not reviewed yet and removed ⚠️ Changes requested Pull Request needs changes before it can be reviewed again labels Oct 18, 2021

mayanje requested a review from fm-117 October 18, 2021 08:30

WI #2045 Change Review

c673a8a

fm-117 requested changes Oct 18, 2021

View reviewed changes

WI #2045 Change Review

a840251

mayanje requested a review from fm-117 October 18, 2021 11:35

fm-117 previously approved these changes Oct 18, 2021

View reviewed changes

mayanje mentioned this pull request Oct 22, 2021

WI #2022 Put Block Relocation info in the Context #2042

Closed

smedilol reviewed Oct 25, 2021

View reviewed changes

WI #2045 Add comment on the default execution performed.

7f8af6b

mayanje dismissed fm-117’s stale review via 7f8af6b October 27, 2021 15:13

mayanje requested review from smedilol and fm-117 October 29, 2021 11:14

smedilol suggested changes Nov 2, 2021

View reviewed changes

WI #2045 Enhance abstract execution scheme with cyclic threshold

203b206

fm-117 requested changes Nov 10, 2021

View reviewed changes

WI #2045 Change review

7c56456

mayanje requested review from smedilol and fm-117 November 16, 2021 10:40

WI #2045 Add comments and missing node closure instruction.

10e4bfc

smedilol suggested changes Nov 18, 2021

View reviewed changes

fm-117 requested changes Nov 18, 2021

View reviewed changes

mayanje added 2 commits November 18, 2021 10:43

WI #2045 Change Review

a049ba1

WI #2045 Rename variables

98d7aaa

mayanje requested review from smedilol and fm-117 November 19, 2021 08:52

smedilol reviewed Nov 24, 2021

View reviewed changes

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs Show resolved Hide resolved

smedilol mentioned this pull request Nov 25, 2021

WI #2039 Compute cyclic call using transitive closure. #2052

Open

mayanje added 2 commits November 28, 2021 13:31

WI #2045 Change Review

bac7556

WI #2045 Add comment

1f74bae

fm-117 mentioned this pull request Dec 7, 2021

WI #2045 Simplify abstract interpretation class #2093

Merged

fm-117 and others added 4 commits December 14, 2021 10:02

WI #2045 Simplify abstract interpretation class (#2093)

3fb6d9d

WI #2045 Add cyclic execution threshold information as methods

b2f208a

WI #2045 Use null-able return type for cyclic execution threshold value.

80c5473

WI #2045 Use a single method.

9014b0d

fm-117 approved these changes Dec 16, 2021

View reviewed changes

mayanje requested a review from smedilol January 3, 2022 10:07

	var sb = Cfg.SuccessorEdges[s];
	int b = sb.Index;
	int blockBIndex = Cfg.SuccessorEdges[s].Index;

2045 cfg implement abs int driver #2050

Are you sure you want to change the base?

2045 cfg implement abs int driver #2050

Conversation

mayanje commented Oct 15, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mayanje Oct 18, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mayanje commented Nov 4, 2021

mayanje commented Nov 9, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mayanje Nov 12, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mayanje Nov 12, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mayanje Nov 12, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fm-117 left a comment

Choose a reason for hiding this comment

mayanje commented Oct 15, 2021 •

edited

mayanje Oct 18, 2021 •

edited

mayanje commented Nov 9, 2021 •

edited

mayanje Nov 12, 2021 •

edited

mayanje Nov 12, 2021 •

edited

mayanje Nov 12, 2021 •

edited