Update wd_demo.au3 - Au3Stripper to support @ScriptLineNumber in compiled mode

[mlipok]

Pull request

Proposed changes

Recently I proposed the already merged : #534
Here I propose to continue this topic.

In compiled mode all information in the output should provide according information, all together with script line numbers.

Checklist

• I have read and noticed the CODE OF CONDUCT document
• I have read and noticed the CONTRIBUTING document
• I have added necessary documentation or screenshots (if appropriate)

Types of changes

• Bugfix (change which fixes an issue)
• Feature (change which adds functionality)
• Code style update (formatting, renaming)
• Refactoring (functional, structural)
• Documentation content changes
• Other (please describe)

What is the current behavior?

In compiled mode in the output the information are not complementary, thus my #540

But script line numbers would be -1 in compiled mode.

What is the new behavior?

In compiled mode, the proper line numbers are included in the results outputed to the selected output.

Influences and relationship to other functionality

none

Additional context

#534

#540

System under test

not releated

[sven-seyfert]

Hi @mlipok, hi @Danp2,

to be honest, I don't care about the wd_demo.au3 in general. Because out of my perspective it's more a user related file that includes user decisions on how you want to handle outputs, directives lile Au3Stripper and more. My understanding about this file was that's not a part of the library/UDF, more likely a helping user file.

==> So feel free to add or strip any parts of this file 😇 .
==> But to be considered is the fact that each update of this "unrelated" library file could/should/would lead to a new release?

My thoughts about it. Best regards
Sven

[mlipok]

@sven-seyfert did you change your opinion since the post below
#534 (comment)

?

[mlipok]

My understanding about this file was that's not a part of the library/UDF, more likely a helping user file.
Yes, this is a support tool that helps beginners understand the operation of this UDF, but also helps diagnose problems.

Therefore, the program also includes:
UserFile()
UserTesting()

For me, wd_demo is not just a helping user file, but also a diagnostic tool that helps solve problems I encounter.
We also often use this tool to help users when we request a feedback from them, after they request a help from us.

Feedback should be available regardless of whether you're running the script in a test (development) environment or in a production environment, where the compiled version is most often run.

But to be considered is the fact that each update of this "unrelated" library file could/should/would lead to a new release?

It is rare for a single PR to immediately generate a new RELEASE.
Sometimes the time between releases is so long that some PRs wait a very long time to be released in a new release, even though they are already accepted and merged into master.

[sven-seyfert]

Fair enough and understandable.

It is rare for a single PR to immediately generate a new RELEASE.
Sometimes the time between releases is so long that some PRs wait a very long time to be released in a new release, even though they are already accepted and merged into master.

Therefore you can fork the project/repository and build your own version until the new release is available. At least when it comes to personal necessary updates, I would go with that way instead of waiting until the release is published. The downside is that you have to monitor the repo state to avoid unsyncrones behavior.

So ones again, feel free to add or strip any parts of wd_demo.au3 file 😇 via PR. Your current two PRs are fine in my point of view.

Best regards
Sven

[mlipok]

So waiting for @Danp2 decision.