Fix `puml` not syncing Resolve #1617 #2345

SPWwj · 2023-07-23T12:02:29Z

What is the purpose of this pull request?

Overview of changes:
Resolve #1617
By introducing a lock service to wait for asynchronous functions to complete:

// Importing LockManager module from the specified directory
const LockManager = require('../../utils/LockManager');

// Start an async function
const lockId = LockManager.createLock();

// Stop of an async function
LockManager.deleteLock(lockId);

// Wait for all async functions to complete
await LockManager.waitForLockRelease();

Fix the issue where all distinct PUML diagrams were being reprocessed on every hot reload by introducing a hashmap tracker to keep track of the diagrams.

The hash key comes from the content and the file path of the PUML diagram.

Anything you'd like to highlight/discuss:
Performance Analysis:

The implementation of the lock service has minimal impact on PUML processing performance.

Testing was conducted on 70 PUML diagrams:

Original Configuration (without lock service)
- o
- CPU Utilization: 12% to 93%
- RAM Usage: 60% to 68%
- Hot Reload CPU Utilization: 12% to 94%
- Hot Reload RAM Usage: 60% to 69%
  - d
- Initial CPU Utilization: 12% to 97%
- Initial RAM Usage: 63% to 78%
- Hot Reload CPU Utilization: 6% to 94%
- Hot Reload RAM Usage: 63% to 75%
Singleton Implementation
-o

Initial Performance Statistics:
- CPU Utilization: 12% to 95%
- RAM Usage: 63% to 72%
- On every single diagram hot reload: RAM shows no change, CPU increases by 6%
-d

Initial Performance Statistics:
- CPU Utilization: 7% to 96%
- RAM Usage: 63% to 74%
- On every single diagram hot reload: RAM shows no change, CPU increases by 6%

These results indicate that the lock service does not significantly affect PUML processing performance.
In fact, it greatly reduces the CPU computation on every hot reload, leading to a more efficient processing system.

Testing instructions:

Check out the PR locally.
Create a new MarkBind project using markbind init.
Run markbind serve -o.
Experiment with the sample:

<puml width="300">
@startuml
alice -> bob ++ : hellos
bob -> bob ++ : self call
bob -> bib ++  #005500 : a
bob -> george ** : create
return done
return rc
bob -> george !! : delete
return success
@enduml
</puml>

Edit the sample and wait for the hot reload to see the effect.

Proposed commit message: (wrap lines at 72 characters)
Introduce LockManager for Async Handling and Optimize PUML Diagrams

Introduce the LockManager module to manage the lifecycle of asynchronous
functions, ensuring robust and consistent handling within synchronous
methods.

Utilize the createLock, deleteLock, and waitForLockRelease methods for
starting, stopping, and waiting for async functions respectively.

Code snippet:

const LockManager = require('path_to/LockManager');
const lockId = LockManager.createLock();
LockManager.deleteLock(lockId);
await LockManager.waitForLockRelease();

Fix the issue where all distinct PUML diagrams were being reprocessed on
every hot reload by introducing a hashmap tracker.

The hash key comes from the content and the file name of the PUML diagram.
The original `processedDiagrams.clear()` has been updated to
`cleanDiagrams(processedDiagrams)`.

By implementing these changes, the code is made more maintainable,
asynchronous functions are properly managed, and PUML diagram processing
is optimized.

Checklist: ☑️

Updated the documentation for feature additions and enhancements
Added tests for bug fixes or features
Linked all related issues
No unrelated changes

ang-zeyu · 2023-07-23T13:31:29Z

The performance hit from execSync is quite significant (2103 site is a good demo ground).

The fix needs to be more involved #1617 (comment).

SPWwj · 2023-07-24T07:10:49Z

The performance hit from execSync is quite significant (2103 site is a good demo ground).

The fix needs to be more involved #1617 (comment).

I have an alternative solution using the lock file. Not sure if this could fix the issue.

tlylt · 2023-07-26T12:01:17Z

@SPWwj is there a real need to implement it as a lock file? Can we do it in memory?

Also pls update your PR description

SPWwj · 2023-07-27T04:32:48Z

@SPWwj is there a real need to implement it as a lock file? Can we do it in memory?

Also pls update your PR description

Yes, a similar idea would be to use a singleton class instead of files for this lock service.

Another way is to use Vue components.

Alternatively, we could make NodeProcessor.ts asynchronous, but this would require a lot of work.

tlylt · 2023-07-27T11:41:26Z

@SPWwj is there a real need to implement it as a lock file? Can we do it in memory?
Also pls update your PR description

Yes, a similar idea would be to use a singleton class instead of files for this lock service.

Another way is to use Vue components.

Alternatively, we could make NodeProcessor.ts asynchronous, but this would require a lot of work.

pros & cons? rationale behind your decision? could you elaborate to aid review plz

SPWwj · 2023-07-27T20:46:53Z

pros & cons? rationale behind your decision? could you elaborate to aid review plz

Use a singleton class instead of files for this lock service.
- Pro: More efficient and faster than IO operations. Easy to implement without affecting the current implementation.
- Cons: Extra utility class needed for asynchronous operations.
Use Vue components.
- Pro: Easy to implement.
- Cons: Results in a larger client-side library. Need to re-implement the component.
Make NodeProcessor.ts asynchronous.
- Pro: Supports the asynchronous operation for the NodeProcessor pipeline.
- Cons: Need to re-implement the pipeline. This is similar to a TypeScript migration and can be very tedious.

The first option (singleton) is recommended as it does not affect the current project structure and provides a way to support asynchronous operations.

packages/core/test/unit/plugins/default/_plantuml/a31b4068deea63d65d1259b4d54bcc79.png

.gitignore

tlylt · 2023-07-29T06:23:15Z

pros & cons? rationale behind your decision? could you elaborate to aid review plz

Use a singleton class instead of files for this lock service.

Pro: More efficient and faster than IO operations. Easy to implement without affecting the current implementation.

Cons: Extra utility class needed for asynchronous operations.

The first option (singleton) is recommended as it does not affect the current project structure and provides a way to support asynchronous operations.

Sounds like a plan. What about performance (time, and maybe cpu/memory?) before and after introducing this change? How much longer(or shorter or no diff) would it take, especially for sites with a lot of puml diagrams?

packages/core/src/utils/lockFileManager.ts

SPWwj · 2023-07-30T12:43:07Z

Sounds like a plan. What about performance (time, and maybe cpu/memory?) before and after introducing this change? How much longer(or shorter or no diff) would it take, especially for sites with a lot of puml diagrams?

I don't expect much performance difference as the lock service does not change the current implementation. The only thing it does is to wait for all asynchronous operations to complete, much like a join.

The compiling time may slightly increase after applying this lockfile, due to PlantUML is able to finish generating the file, just like in the test case mentioned above.

tlylt · 2023-07-30T13:32:10Z

Sounds like a plan. What about performance (time, and maybe cpu/memory?) before and after introducing this change? How much longer(or shorter or no diff) would it take, especially for sites with a lot of puml diagrams?

I don't expect much performance difference if the lock service does not change the current implementation. The only thing it does is to wait for all asynchronous operations to complete, much like a join.

The compiling time may slightly increase after applying this lockfile, due to PlantUML is able to finish generating the file, just like in the test case mentioned above.

Sure, have some numbers when you are done so that we can make a fair judgment 👍

damithc · 2023-07-30T14:30:52Z

Sure, have some numbers when you are done so that we can make a fair judgment

Good idea. Use a decent number of puml diagram in the test case.

SPWwj · 2023-07-31T14:39:41Z

Sure, have some numbers when you are done so that we can make a fair judgment

Good idea. Use a decent number of puml diagram in the test case.

@damithc @tlyltI have updated the PR description to include some test statistics.

tlylt · 2023-08-02T13:59:00Z

@SPWwj is this ready for review? There's still a merge conflict

SPWwj · 2023-08-02T17:18:22Z

@SPWwj is this ready for review? There's still a merge conflict

Fixed merged conflict

.gitignore

packages/core/src/plugins/default/markbind-plugin-plantuml.ts

packages/core/src/utils/LockManager.ts

tlylt

Hey @SPWwj, looks mostly good on my end, thank you for your quick response. Have one more concern as I read through the diagram status tracking code:

Could you add in comments to explain the functions? the definition of "dead" and "alive" weren't as clear. I initially thought you meant "stale" and "fresh", but the logic doesn't add up.
Could you illustrate the flow of events for the typical cases:
- on first generation, what happens? (especially the state of processedDiagrams)
- after edit of a puml file, what happens? (especially the state of processedDiagrams)
- after edit of a non puml file, what happens? (especially the state of processedDiagrams)

I'm not sure whether processedDiagrams is working as advertised. Clarification from your end would help!

packages/core/src/plugins/default/markbind-plugin-plantuml.ts

SPWwj · 2023-08-19T15:37:28Z

Hey @SPWwj, looks mostly good on my end, thank you for your quick response. Have one more concern as I read through the diagram status tracking code:

Could you add in comments to explain the functions? the definition of "dead" and "alive" weren't as clear. I initially thought you meant "stale" and "fresh", but the logic doesn't add up.

Could you illustrate the flow of events for the typical cases:

on first generation, what happens? (especially the state of processedDiagrams)

after edit of a puml file, what happens? (especially the state of processedDiagrams)

after edit of a non puml file, what happens? (especially the state of processedDiagrams)

I'm not sure whether processedDiagrams is working as advertised. Clarification from your end would help!

On first generation, all the diagrams will be added to the map, and whenever a diagram is generated,
it will be marked as fresh.
Upon editing a PUML file or a non-PUML file that triggers a hot reload on the site,
the stale diagram will be removed from the map, and the map will be reset to all stale.
If the diagram is inside the map, the generateDiagram function will not regenerate the diagram.
This is to prevent generating the same diagram twice.

tlylt · 2023-08-19T16:47:56Z

Upon editing a PUML file or a non-PUML file that triggers a hot reload on the site, the stale diagram will be removed from the map, and the map will be reset to all stale.

The stale diagram may not be removed immediately right?

Example A, B are diagrams

Initial generation
- processedMap = {A=true, B=true}
Edit A (which creates C as a new diagram)
- This will trigger a hot reload on the site
  - before regeneration: no stale diagrams, so no diagrams are deleted
  - before regeneration: now set A, B as stale, C is not in the map yet
    - processedMap = {A=false, B=false}
  - during regeneration: A in the map remains stale, B mark as fresh processedMap = {A=false, B=true}
  - during regeneration: C is added to the map and marked as fresh processedMap = {A=false, B=true, C=true}

And only after a further save operation, will A be removed from the map?

Also, those diagrams that are removed from the map, but they are not deleted right?

there wasn't an issue previously because we override the same diagram? Now with this new approach we need to perform cleanup to avoid accumulating a ton of diagrams in _site folder?

Finally, have you tried observing the actual values of processedDiagrams during initialization and after edit?
I console log the values and they seem quite strange.
For example, having two images in one page (and no more puml in other pages) by adding the following to an index.md of a newly generated site:

<puml width="300">
@startuml
A -> bob ++ : hellos
bob -> bob ++ : self call
bob -> bib ++  #005500 : a
bob -> george ** : create
return done
return rc
bob -> george !! : delete
return success
@enduml
</puml>

<puml width="300">
@startuml
B -> bob ++ : hellos
bob -> bob ++ : self call
bob -> bib ++  #005500 : a
bob -> george ** : create
return done
return rc
bob -> george !! : delete
return success
@enduml
</puml>

I would assume that processedDiagrams would have both files after markbind serve, but apparently when I console log, it only contains one:
(to illustrate)

Then, even though I just delete something unrelated in an index.md, the processedDiagrams values are updated for some weird reason to one true, one false:

FYI I added the log here:

SPWwj · 2023-08-20T16:23:43Z

The stale diagram may not be removed immediately right?

Yes, it will be removed in a future update.

Example A, B are diagrams

Initial generation processedDiagrams {}
- generateDiagram => processedDiagrams Add A and B to processedDiagrams {A=true, B=true}
Edit A (which creates C as a new diagram)
- This will trigger a hot reload on the site
  - before regeneration: no stale diagrams, so no diagrams are deleted
    - now set A, B as stale, C is not in the map yet
  - during regeneration: A in the map remains stale, B mark as fresh generateDiagram => {A=false, B=true, C = true}
    - Add C = true
    - Update B = True
    - Unchange A = stale
      3 Edit B (Which will create D as a new diagram)
- This will trigger a hot reload on the site
  - before regeneration:
    - A will be remove
    - now set B, C as stale, D is not in the map yet
  - during regeneration: A in the map remains stale, B mark as fresh generateDiagram => { B=false, C = true, D = true}
    - Add D = True
    - Update C = True
    - Unchange B = False
      4 Future Edit repeat above steps.

Yes answered above

Also, those diagrams that are removed from the map, but they are not deleted right?

Yes

there wasn't an issue previously because we override the same diagram? Now with this new approach we need to perform cleanup to avoid accumulating a ton of diagrams in _site folder?

We can add a feature here to remove diagrams.

SPWwj · 2023-08-20T16:37:58Z

Upon editing a PUML file or a non-PUML file that triggers a hot reload on the site, the stale diagram will be removed from the map, and the map will be reset to all stale.

The stale diagram may not be removed immediately right?

Example A, B are diagrams

Initial generation

processedMap = {A=true, B=true}

Edit A (which creates C as a new diagram)

This will trigger a hot reload on the site

before regeneration: no stale diagrams, so no diagrams are deleted

before regeneration: now set A, B as stale, C is not in the map yet

processedMap = {A=false, B=false}

during regeneration: A in the map remains stale, B mark as fresh processedMap = {A=false, B=true}

during regeneration: C is added to the map and marked as fresh processedMap = {A=false, B=true, C=true}

And only after a further save operation, will A be removed from the map?

Also, those diagrams that are removed from the map, but they are not deleted right?

there wasn't an issue previously because we override the same diagram? Now with this new approach we need to perform cleanup to avoid accumulating a ton of diagrams in _site folder?

Finally, have you tried observing the actual values of processedDiagrams during initialization and after edit? I console log the values and they seem quite strange. For example, having two images in one page (and no more puml in other pages) by adding the following to an index.md of a newly generated site:
<puml width="300">
@startuml
A -> bob ++ : hellos
bob -> bob ++ : self call
bob -> bib ++  #005500 : a
bob -> george ** : create
return done
return rc
bob -> george !! : delete
return success
@enduml
</puml>

<puml width="300">
@startuml
B -> bob ++ : hellos
bob -> bob ++ : self call
bob -> bib ++  #005500 : a
bob -> george ** : create
return done
return rc
bob -> george !! : delete
return success
@enduml
</puml>
I would assume that processedDiagrams would have both files after markbind serve, but apparently when I console log, it only contains one: (to illustrate)

This is because the diagram is only added to the map before the generation of a new diagram:

Then, even though I just delete something unrelated in an index.md, the processedDiagrams values are updated for some weird reason to one true, one false:

FYI I added the log here:

This is correct because the console log is placed at the beginning of the function. However, the following code is in charge of preventing the regeneration of the existing diagram:

tlylt · 2023-08-21T00:44:36Z

This is correct because the console log is placed at the beginning of the function. However, the following code is in charge of preventing the regeneration of the existing diagram:

I see, thank you for that!

I adjusted the comments slightly as well as code (made unlink sync).

For inline use of puml diagrams via e.g.

<puml width="300">
@startuml
B -> bob ++ : hellos
bob -> bob ++ : self call
bob -> bib ++  #005500 : a
bob -> george ** : create
return done
return rc
bob -> george !! : delete
return success
@enduml
</puml>

seems alright now, the only issue is the delayed deletion of the stale diagrams. Could be improved in the future but ok for now.

For use of src in puml, via e.g. <puml src="diagrams/ArchitectureSequenceDiagram.puml" width="574" />, I am encountering some problems. It seems like we might either have some collision or accidentally delete the wrong files.
To reproduce:

clone https://github.com/tlylt/ab3-docs-demo
cd docs
markbind serve using your branch of markbind
go to http://127.0.0.1:8080/DeveloperGuide.html#design
now, add <puml src="diagrams/ArchitectureDiagram.puml" width="280" /> to the end of index.md
- save the file (i.e. ctrl + s)
- save the file again (i.e. ctrl + s)
refresh the http://127.0.0.1:8080/DeveloperGuide.html#design
see that besides the first image, the rest are not found

(On initial markbind serve, the _site images are present)

(After double save, only the first diagram remains, hence resulting in error)

@SPWwj could you investigate this, please?

SPWwj · 2023-08-25T09:09:29Z

This is correct because the console log is placed at the beginning of the function. However, the following code is in charge of preventing the regeneration of the existing diagram:

I see, thank you for that!

I adjusted the comments slightly as well as code (made unlink sync).

For inline use of puml diagrams via e.g.
<puml width="300">
@startuml
B -> bob ++ : hellos
bob -> bob ++ : self call
bob -> bib ++  #005500 : a
bob -> george ** : create
return done
return rc
bob -> george !! : delete
return success
@enduml
</puml>
seems alright now, the only issue is the delayed deletion of the stale diagrams. Could be improved in the future but ok for now.

For use of src in puml, via e.g. <puml src="diagrams/ArchitectureSequenceDiagram.puml" width="574" />, I am encountering some problems. It seems like we might either have some collision or accidentally delete the wrong files. To reproduce:

clone https://github.com/tlylt/ab3-docs-demo

cd docs

markbind serve using your branch of markbind

go to http://127.0.0.1:8080/DeveloperGuide.html#design

now, add <puml src="diagrams/ArchitectureDiagram.puml" width="280" /> to the end of index.md

save the file (i.e. ctrl + s)

save the file again (i.e. ctrl + s)

refresh the http://127.0.0.1:8080/DeveloperGuide.html#design

see that besides the first image, the rest are not found

(On initial markbind serve, the _site images are present)

(After double save, only the first diagram remains, hence resulting in error)

@SPWwj could you investigate this, please?

The hot reload scans only the PUML diagram on the modified page, causing diagrams on other non-modified pages to become stale. Currently, there's no good solution, as there's no way to identify inline PUML. Every change to inline PUML generates a new diagram without a common identifier to the stale diagram.

Since this is for production, one option is to clean up the PUML diagrams in the directory on init when no diagram is in the tracker list, to remove the redundant diagrams.

tlylt · 2023-08-25T10:11:56Z

Does making the plantuml status tracking hashmap persist through site rebuild help to fix the issue? Either somehow make it global or write to file

SPWwj · 2023-08-25T10:43:35Z

Does making the plantuml status tracking hashmap persist through site rebuild help to fix the issue? Either somehow make it global or write to file

The issue won't be resolved, as we have no way to identify and remove the inline PUML diagram tracker from the tracking list. This is because there's no common identifier for the inline PUML diagram, unlike the .puml file where we can use the filename as an identifier.

One solution is to remove the diagram during the initial load with 'Markbind serve'. This ensures that our tracker list only captures the required diagrams.

tlylt · 2023-08-26T07:22:30Z

Hey @SPWwj could you help me understand your replies further?

Every change to inline PUML generates a new diagram without a common identifier to the stale diagram.

Aren't we currently making the identifier depend on both the output file path and the puml content, meaning every change to any PUML diagram will generate a new diagram without a common identifier to the stale diagram? This includes both inline and file puml diagrams?

Since this is for production, one option is to clean up the PUML diagrams in the directory on init when no diagram is in the tracker list, to remove the redundant diagrams.

"what" is for production? What do you mean by "production" here?

One solution is to remove the diagram during the initial load with 'Markbind serve'. This ensures that our tracker list only captures the required diagrams.

Do you mean we now ONLY remove the diagram during the initial load with "markbind serve", and stop removing the diagrams afterwards? I think that is a viable solution.

SPWwj · 2023-08-26T09:00:10Z

Hey @SPWwj could you help me understand your replies further?

Every change to inline PUML generates a new diagram without a common identifier to the stale diagram.

Aren't we currently making the identifier depend on both the output file path and the puml content, meaning every change to any PUML diagram will generate a new diagram without a common identifier to the stale diagram? This includes both inline and file puml diagrams?

The goal is to remove unused, outdated diagrams.

Here's the relevant code snippet:

If node.attribs.name is present, a new diagram can overwrite the old one using the same imageOutputPath.
imageOutputPath also can be used to update the current tracking list.

    const imageOutputPath = path.resolve(config.outputPath, PUML_DIR, pathFromRootToImage);
    generateDiagram(imageOutputPath, pumlContent);

If node.attribs.name is missing, the old diagram can't be removed or replaced by a new one,
and tracking list will expand because we have no information on which diagram has been updated.

Since this is for production, one option is to clean up the PUML diagrams in the directory on init when no diagram is in the tracker list, to remove the redundant diagrams.

"what" is for production? What do you mean by "production" here?

When the site is ready to be deployed and go live.

One solution is to remove the diagram during the initial load with 'Markbind serve'. This ensures that our tracker list only captures the required diagrams.

Do you mean we now ONLY remove the diagram during the initial load with "markbind serve", and stop removing the diagrams afterwards? I think that is a viable solution.

Yes, because during the implementation of the website, I don't think there's a need to worry about deleting unused diagrams while editing PUML source code. This will also improve the undo operation during PUML code editing.

tlylt · 2023-08-26T09:23:10Z

If node.attribs.name is missing, the old diagram can't be removed or replaced by a new one, and tracking list will expand because we have no information on which diagram has been updated.

Hmm, now it reminds me that we should ensure that our solution works for the case where the user edits the plantuml files without running markbind serve.

Yes, because during the implementation of the website, I don't think there's a need to worry about deleting unused diagrams while editing PUML source code. This will also improve the undo operation during PUML code editing.

Sure, sounds like a plan 👍.
To track, there are a few use cases to check in order to ensure the functionality works:

unused diagrams don't end up accumulating and occupying disk space (should at least be cleared after stopping and rerunning markbind serve
updates to inline puml should work
updates to puml with src to a file should work
updates to puml with the user-defined name should work
updates to puml done without running markbind serve should work

SPWwj · 2023-08-26T17:11:55Z

@tlylt Actually, I just realized that MarkBind already takes care of deleting redundant files during build time. Thus, there's no need to worry about accumulating and occupying disk space.

tlylt

Thank you @SPWwj, LGTM 🚀

I updated the relevant docs to:

use the <puml src="...puml"> directly in our UG
remove the generated diagrams since they will be generated on the fly
update instructions in DG regarding puml files in UG
add a note on duplicated names may result in invalid output

And finally some minor refactoring/adjusting comments.

SPWwj marked this pull request as draft July 23, 2023 12:05

SPWwj marked this pull request as ready for review July 24, 2023 07:10

tlylt reviewed Jul 29, 2023

View reviewed changes

packages/core/test/unit/plugins/default/_plantuml/a31b4068deea63d65d1259b4d54bcc79.png Outdated Show resolved Hide resolved

tlylt reviewed Jul 29, 2023

View reviewed changes

.gitignore Outdated Show resolved Hide resolved

tlylt reviewed Jul 29, 2023

View reviewed changes

packages/core/src/utils/lockFileManager.ts Outdated Show resolved Hide resolved

tlylt reviewed Jul 29, 2023

View reviewed changes

packages/core/src/utils/lockFileManager.ts Outdated Show resolved Hide resolved

SPWwj added 5 commits July 31, 2023 22:11

Fix puml not syncing.

f493979

Fix lint error

eae18c8

Revert plantuml.test.ts

7fa3dbc

Fix file not found on wait

16f3edd

Update to LockManager

6e7cddb

SPWwj force-pushed the pr-puml branch from 8637fd4 to 6e7cddb Compare July 31, 2023 14:25

SPWwj added 4 commits August 3, 2023 00:30

Merged index.ts

67c4fc6

Update index.ts

9c52f52

Update index.ts

4d66abc

Fix lint

c7dfa89

tlylt reviewed Aug 4, 2023

View reviewed changes

refactor

02a805e

tlylt reviewed Aug 19, 2023

View reviewed changes

packages/core/src/plugins/default/markbind-plugin-plantuml.ts Outdated Show resolved Hide resolved

packages/core/src/plugins/default/markbind-plugin-plantuml.ts Outdated Show resolved Hide resolved

SPWwj added 4 commits August 19, 2023 23:03

Add comment for stale tracking

ca312d6

Rename isStale to isFresh

9ad306f

Update comments for processedDiagrams

5e029a3

Fix lint

e30f5d5

SPWwj and others added 2 commits August 21, 2023 01:06

Update clearDeadDiagrams to remove unused diagrams

d0ff17d

minor refactor

e7d5a9e

Merge branch 'master' into pr-puml

a46f136

SPWwj added 2 commits August 27, 2023 00:23

Remove delete stale diagram feature

89e3de5

Fix .puml file not update

ced74fb

tlylt added 4 commits August 27, 2023 08:47

refactor import and comment

da5bef0

update ug inline puml

4727492

cleanup docs

938d125

update comment

ee49d91

tlylt approved these changes Aug 27, 2023

View reviewed changes

tlylt added this to the v5.0.2 milestone Aug 27, 2023

tlylt merged commit da9d3f7 into MarkBind:master Aug 27, 2023
7 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix `puml` not syncing Resolve #1617 #2345

Fix `puml` not syncing Resolve #1617 #2345

SPWwj commented Jul 23, 2023 •

edited by tlylt

Loading

ang-zeyu commented Jul 23, 2023

SPWwj commented Jul 24, 2023

tlylt commented Jul 26, 2023 •

edited

Loading

SPWwj commented Jul 27, 2023

tlylt commented Jul 27, 2023

SPWwj commented Jul 27, 2023

tlylt commented Jul 29, 2023

SPWwj commented Jul 30, 2023 •

edited

Loading

tlylt commented Jul 30, 2023

damithc commented Jul 30, 2023

SPWwj commented Jul 31, 2023

tlylt commented Aug 2, 2023

SPWwj commented Aug 2, 2023

tlylt left a comment

SPWwj commented Aug 19, 2023 •

edited

Loading

tlylt commented Aug 19, 2023

SPWwj commented Aug 20, 2023

SPWwj commented Aug 20, 2023

tlylt commented Aug 21, 2023

SPWwj commented Aug 25, 2023 •

edited

Loading

tlylt commented Aug 25, 2023

SPWwj commented Aug 25, 2023

tlylt commented Aug 26, 2023

SPWwj commented Aug 26, 2023

tlylt commented Aug 26, 2023 •

edited

Loading

SPWwj commented Aug 26, 2023 •

edited

Loading

tlylt left a comment

Fix puml not syncing Resolve #1617 #2345

Fix puml not syncing Resolve #1617 #2345

Conversation

SPWwj commented Jul 23, 2023 • edited by tlylt Loading

ang-zeyu commented Jul 23, 2023

SPWwj commented Jul 24, 2023

tlylt commented Jul 26, 2023 • edited Loading

SPWwj commented Jul 27, 2023

tlylt commented Jul 27, 2023

SPWwj commented Jul 27, 2023

tlylt commented Jul 29, 2023

SPWwj commented Jul 30, 2023 • edited Loading

tlylt commented Jul 30, 2023

damithc commented Jul 30, 2023

SPWwj commented Jul 31, 2023

tlylt commented Aug 2, 2023

SPWwj commented Aug 2, 2023

tlylt left a comment

Choose a reason for hiding this comment

SPWwj commented Aug 19, 2023 • edited Loading

tlylt commented Aug 19, 2023

SPWwj commented Aug 20, 2023

SPWwj commented Aug 20, 2023

tlylt commented Aug 21, 2023

SPWwj commented Aug 25, 2023 • edited Loading

tlylt commented Aug 25, 2023

SPWwj commented Aug 25, 2023

tlylt commented Aug 26, 2023

SPWwj commented Aug 26, 2023

tlylt commented Aug 26, 2023 • edited Loading

SPWwj commented Aug 26, 2023 • edited Loading

tlylt left a comment

Choose a reason for hiding this comment

Fix `puml` not syncing Resolve #1617 #2345

Fix `puml` not syncing Resolve #1617 #2345

SPWwj commented Jul 23, 2023 •

edited by tlylt

Loading

tlylt commented Jul 26, 2023 •

edited

Loading

SPWwj commented Jul 30, 2023 •

edited

Loading

SPWwj commented Aug 19, 2023 •

edited

Loading

SPWwj commented Aug 25, 2023 •

edited

Loading

tlylt commented Aug 26, 2023 •

edited

Loading

SPWwj commented Aug 26, 2023 •

edited

Loading