Mapping handler dependencies

[bn]

Hi Andy,

Many thanks for the updated version.

May I suggest a live filter feature for field "filterListInput"?

Add this to the script

Code: Select all

on textChanged
   dispatch "mouseUp" to btn "filterButton"
end textChanged

I find this faster to see what is filtered.

Kind regards
Bernd

[mwieder]

Was looking forward to this option, but the new version does an amazing job of crashing my linux desktop manager on loading the stack (even with messages suppressed) while version 1.0.5 doesn't do so until I actually try to display the flowchart.

[SWEdeAndy]

May I suggest a live filter feature for field "filterListInput"?

Very good suggestion, Bernd! Your script addition will be in the next release! Thanks!

[SWEdeAndy]

Was looking forward to this option, but the new version does an amazing job of crashing my linux desktop manager on loading the stack (even with messages suppressed) while version 1.0.5 doesn't do so until I actually try to display the flowchart.

Hmm, could it be that on Linux a stack crashes if it contains a browser widget? Since that widget doesn't work on Linux (if I recall correctly)?

If the platform is not MacOS, the tool skips updating the browser widget and instead writes an html file to desktop and tries to launch it. However, it still opens the substack Flowchart (with browser widget), because the html script stuff is there and the theme chooser etc. Might this cause a crash on Linux?

But then, v1.0.5 already included a browser widget in the main stack (the spinner), so the mere presence of a browser widget doesn't seem to cause a crash?

[mwieder]

The presence of a browser widget in linux isn't a problem.
It's only if you attempt to use it (change its properties etc).

[SWEdeAndy]

The presence of a browser widget in linux isn't a problem.
It's only if you attempt to use it (change its properties etc).

Is showing/hiding the browser widget or changing the size of it enough to cause a crash?
If so, then that is probably the cause of the crashes you experience (as there's a hide widget line already in the openStack handler).
To fix that, I can change the stack so that it starts out with no browser widgets at all (to be safe), and then creates them on the fly, if the platform is not Linux.

[mwieder]

Got things working here on linux. The main problem was the spinner widget, which is another browser widget in disguise. Interestingly, the spinner widget did indeed show a red-and-blue spinner, it's just that the process made things unstable.

Made two changes:

1. in the resizeStack handler, only affect the browser widget if the platform is MacOS
2. comment the processSpinner internal statements and then *delete the spinner widget*

The flowchart (now displayed in my default browser) looks *very* nice. Thank you. This is great.

[SWEdeAndy]

Great, I'm glad we could find the problem, so that the tool can work on Linux too!
In upcoming versions, this will be taken care of, so it will work out of the box on all platforms (at least until we hit the next snag... )

I'm also doing an overhaul of the UI now, so that all settings for the flowchart is done in the main stack, and the substack will only open on Mac, while Win and Linux go straight to the external browser output.

I''m planning to take this project in the direction of a code documentation facility, which was also actually the motivation behind the development of the Mermaid library. The Mermaid team writes:

Mermaid is a JavaScript based diagramming and charting tool that uses Markdown-inspired text definitions and a renderer to create and modify complex diagrams. The main purpose of Mermaid is to help documentation catch up with development.

Doc-Rot is a Catch-22 that Mermaid helps to solve.

Diagramming and documentation costs precious developer time and gets outdated quickly. But not having diagrams or docs ruins productivity and hurts organizational learning.
Mermaid addresses this problem by enabling users to create easily modifiable diagrams, it can also be made part of production scripts (and other pieces of code).

I'm thinking it may strengthen LiveCode as a serious option for software development if it comes with a competent 'live documentation' feature. It would make software made with LiveCode a little more future-proof and a little less dependent on the original developer. Perhaps... Let's see where it goes!

[SWEdeAndy]

New release:
https://github.com/wheninspace/WIS_Scri ... ses/latest

v1.1.0 (18 Aug 2023)
Enhancements:
- A major overhaul of the stack selection feature. You can now save sets of stacks as ”projects” to easily switch between stack sets when running the analysis.
- The flowchart settings have moved into the main UI, making flowchart customisation equally accessible on all platforms.
- Project data and general settings are now saved to an lson file in the same folder when closing the stack. Any new version of the WIS_ScriptDependencies stack placed in the same folder will automatically restore your project data and general settings.

- Fixed bug: No browser widgets will appear when using the stack on Linux, to prevent crashing
- Other minor fixes

[jacque]

I finally got a chance to try this. I pointed it at a mainstack with a pretty long script. The text report is 1.8 MB and it couldn't make a flowchart. I got a PNG that only said I'd exceeded the maximum text size.

Do you know what the limit is?

[mwieder]

Added some color to replace line 773 of processFlowchartSyntax:

Code: Select all

     # display getProp and setProp
      switch char 1 of getBracketType(pParent)
         case "{" # getProp or setProp
            put sSyntaxCatalogue[pParent] && "fill:#09f" into tStyle
            break
         case "(" # command
            put sSyntaxCatalogue[pParent] && "fill:#0af" into tStyle
            break
         default # function
            put sSyntaxCatalogue[pParent] && "fill:#f90" into tStyle
      end switch
      put sSyntaxCatalogue[tKey] & getBracketType(tKey) && "-->" && sSyntaxCatalogue[pParent] & getBracketType(pParent) into tRow
      put cr & "style" && tStyle after tRow
      #put sSyntaxCatalogue[tKey] & getBracketType(tKey) & " -->" && sSyntaxCatalogue[pParent] & getBracketType(pParent) into tRow

[SWEdeAndy]

I finally got a chance to try this. I pointed it at a mainstack with a pretty long script. The text report is 1.8 MB and it couldn't make a flowchart. I got a PNG that only said I'd exceeded the maximum text size.

Do you know what the limit is?

Oh, that sounds like a pretty long script indeed! I only got that error once. The default char max of Mermaid is 50.000 chars, but this can be altered (I just learnt, thanks to your question). I'll implement this as a setting in the next version (with a warning that it may cause "performance problems due to high CPU usage in the browser", as someone on Stackoverflow claims).

With that in mind, it may also be wise to try to limit the output a bit, as it will be a pretty big flowchart too, with a small fontsize even if you maximize it on a large screen. For sure, that represents the complexity of the stack, but it may appear more intimidating than useful, perhaps...

So, how to limit the output if everything is in one stack/one massive script? Well, you can try lowering the recursion limit, in case there are loops involving handlers with high dependency weights. But this will probably impact the text report more than the flowchart, as the flowchart only shows each relation once anyway (while the text report generation repeats a lot - it has room for improvement).

Another way is to skip certain handlers that may not add very useful information to the flowchart, such as "log" and mouse actions. "Log" could be present in so many handlers (if you use that feature) and will cause a useless jungle of arrows in the flowchart. Mouse actions typically just start off various handler chains and are not always interesting to include.

So, I usually put in the Exclusion filter field "log,mouse*" and perhaps some frequent functions that just do something simple, such as "q" for returning a value within quotes etc. This tends to lighten up the flowchart density a bit.

I'm glad that you experiment and stress test the tool - I want it to be useful, not just "cool", so we need to find good ways of improving it to that end.

[SWEdeAndy]

Added some color to replace line 773 of processFlowchartSyntax:

Yes, that is a good idea. The different node shapes are not really enough, it's an improvement to give commands/functions/set/getProps different colours as well.

I'll implement it a bit differently though. Your method adds a line with several chars per node relation, and if we're going to cater for Jacque's monster scripts ( ) (and general performance) then keeping down the char count matters. Colouring can be done through class definitions instead, and all nodes assigned on one line per class. I think. I'll be back...

[mwieder]

Absolutely. I'm just not familiar enough with mermaid to know where to inject the additional class definitions This was more of a proof of concept.
But I did notice that this also showed me the difference between system messages and script handlers as a side effect.
I also fiddled with the idea of changing the arrow endpoints to differentiate between getProp and setProp calls, but didn't follow through on that.

[SWEdeAndy]

Absolutely. I'm just not familiar enough with mermaid to know where to inject the additional class definitions This was more of a proof of concept.

And a good one. I'll also add the possibility to let the user choose the colours.

But I did notice that this also showed me the difference between system messages and script handlers as a side effect.

Well, I think in fact it shows the difference between a handler being called by at least one other handler, and handlers that are first in their 'chain of command'. The latter are indeed often system messages, i.e. "on" handlers such as "on openCard" or "on keyDown", but not necessarily so. It's still a nice side effect though, to see the "trigger handlers" in a different colour, so I'll try to keep that in.

I also fiddled with the idea of changing the arrow endpoints to differentiate between getProp and setProp calls, but didn't follow through on that.

Yeah, there is a problem with that. The way the handler catalogue is currently built, it uses handler names as array keys. Since getProp and setProp share the same handler name, they unfortunately fight for the same name space in the array (the last added wins). The same applies if a function and a command have the same name, which is allowed and works in LC, but isn't, in my opinion, good scripting practice...

In any case it potentially causes some faults in the way the handler relations are defined, that I find hard to get around. I may have to find a more robust way to map the handlers, but it's not a simple thing to change without breaking everything else...