Jump to content

Wish list item


Gene
 Share

Recommended Posts

Even though lately this seems to be the place to post this, I realize it may not be. If an Admin thinks it should be in a different forum, feel free to move it. I would appreciate a PM telling me where it went.

Recently I was replying to a post and realized I had verbalized something I had wished for a long time. I believe it would be useful to many others besides myself.

This request/Idea has 2 possible tracks. More about that later.

I only use #Includes during development. As soon as I'm near satisfied with a script, I paste all the "official" UDFs used into the script and delete the #include statements. That way, no matter what changes/improvements are made in the interim, the "official" UDFs won't break my script if I make changes to it later and need to recompile. Just as importantly my EXE doesn't carry the unnecessary burden of 3 to 5 #Includes, much of which aren't used.

Like Larry, I don't have much interest in developing it, but I do wish someone would develop a script/EXE to read a script and paste in all the referenced "official" UDFs and also delete the #Include statements. It would be great if it ran off the tools list in Scite.

That is the first track.

The second is...

It would be nice if the compiler would look first in the script for for a UDF and then in the Includes for a UDF. Given the first track (either manually or by script {without deleting the includes of course}), to test the effect new/improved UDFS, one could simply comment the definition in the script. Then run the script in ways to exercise the now included improved/new UDF.

The first track will work nicely without the second, but both will/can result in a better solution.

Edit: Left out a word.

Edited by Gene

[font="Verdana"]Thanks for the response.Gene[/font]Yes, I know the punctuation is not right...

Link to comment
Share on other sites

Did you even bother to search the forum? This has been brought up multiple times and there are multiple scripts in various stages of usability to accomplish this very thing.

Hi Valik,

Thanks for the response.

Given that forum search is often pointless, no, I didn't, but I have now, for "include", "UDF", "wish list", "udf scripts" and "move udf" (separately), and found nothing of interest. Perhaps you'll offer a more useful search string? But then, that would be helpful and not just a criticism. But then, I have noticed you being helpful from time to time, it could happen!

B):graduated::):o

Gene

[font="Verdana"]Thanks for the response.Gene[/font]Yes, I know the punctuation is not right...

Link to comment
Share on other sites

  • Developers

Search for Au3Preprocess UDF created by kjactive.

Only not sure if it is doing what you are asking for. Think it creates a temp file containing all needed UDFs and compiles that.

The big challenge with your idea is to make sure that all UDFs that are referenced by the original UDF are inserted, like _DateAdd() is also using _DateIsValid(), _DateTimeSplit(), _DayValueToDate(), _TicksToTime, _DateIsLeapYear and _DateToDayValue. Ofcourse these UDFs can also use other UDF's again...

conclusion: I am not in favor for this approach because its difficult to make 100% "foolsproof" B)

Edited by JdeB

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
Share on other sites

The big challenge with your idea is to make sure that all UDFs that are referenced by the original UDF are inserted, like _DateAdd() is also using _DateIsValid(), _DateTimeSplit(), _DayValueToDate(), _TicksToTime, _DateIsLeapYear and _DateToDayValue. Ofcourse these UDFs can also use other UDF's again...

conclusion: I am not in favor for this approach because its difficult to make 100% "foolsproof" B)

thats weird, because i never thought about that, other UDF's using others.. i was thinking when people started coming out with various things like what was just requested that it was easy, but i never thought of it your way
FootbaG
Link to comment
Share on other sites

I will try...

- load script and paste includes as they appear...

- isolate Funcs and load them into an array...

- scan all script lines not in the Funcs and record non-autoit Functions

- append functions found from the array of Funcs to the end of main script

something like that...

Lar.

Thanks

That reads like a good plan. I understand it to mean you're going to address personal as well as "official" Includes and UDFs. Then recurse as necessary to make sure all the required pieces are pulled in.

B)

Edit: typo

Gene

Edited by Gene

[font="Verdana"]Thanks for the response.Gene[/font]Yes, I know the punctuation is not right...

Link to comment
Share on other sites

At this point, I'll burst the proverbial bubble (as I'm wont to do) by mentioning that functions like Call(), GUISetOnEvent(), GUICtrlSetOnEvent(), AdLibEnable(), et cetera all take a parameter which is the name of a function.

This function may or may not be ...

  • ... called directly in the code, therefore it may not be exempt from exclusion.
  • ... specified as a literal string as the argument.
  • ... known at compile time when functions are processed for exclusion.
Link to comment
Share on other sites

Search for Au3Preprocess UDF created by kjactive.

Only not sure if it is doing what you are asking for. Think it creates a temp file containing all needed UDFs and compiles that.

The big challenge with your idea is to make sure that all UDFs that are referenced by the original UDF are inserted, like _DateAdd() is also using _DateIsValid(), _DateTimeSplit(), _DayValueToDate(), _TicksToTime, _DateIsLeapYear and _DateToDayValue. Ofcourse these UDFs can also use other UDF's again...

conclusion: I am not in favor for this approach because its difficult to make 100% "foolsproof" B)

I see your point, in fact that's a big part of why I want to automate it. I've been doing that manually, I figure a well written automation should more reliable than a manual effort. Have you looked at Larry's plan/outline?

Of course each added UDF would have to be recursed to make sure all the pieces are present. Multiple passes either through code or arrays would likely be necessary.

Thanks for the search suggestion, I will go look at it next. :o

A few questions

  • Do you think the current situation is fine?
  • Do you see how it could be a problem?
  • Do you think I'm spinning my wheels with this?
  • Is there any effort to document changes to the "official" UDFs and how they may break scripts based on a previous version?
  • Do you have suggestions as to more acceptable approaches?
  • Are there other issues you think I should be considering?
Gene :graduated:

[font="Verdana"]Thanks for the response.Gene[/font]Yes, I know the punctuation is not right...

Link to comment
Share on other sites

At this point, I'll burst the proverbial bubble (as I'm wont to do) by mentioning that functions like Call(), GUISetOnEvent(), GUICtrlSetOnEvent(), AdLibEnable(), et cetera all take a parameter which is the name of a function.

This function may or may not be ...

  • ... called directly in the code, therefore it may not be exempt from exclusion.

  • ... specified as a literal string as the argument.

  • ... known at compile time when functions are processed for exclusion.

Hi Valik,

That's a good point. Why would a script processing the the script of interest not be able to see any of these UDFs used as parameters?

Would you give an example of a UDF called as a literal string?

Would you further explain "known at compile time when functions are processed for exclusion."?

Thanks for the response.

Gene B)

[font="Verdana"]Thanks for the response.Gene[/font]Yes, I know the punctuation is not right...

Link to comment
Share on other sites

  • Developers

A few questions

  • Do you think the current situation is fine?

  • Do you see how it could be a problem?

  • Do you think I'm spinning my wheels with this?

  • Is there any effort to document changes to the "official" UDFs and how they may break scripts based on a previous version?

  • Do you have suggestions as to more acceptable approaches?

  • Are there other issues you think I should be considering?

In general I think that the UDF libraries should be included, not copy/pasted into your own scripts since that defeats the whole purpose of including standard code.

In general the UDFs should be backwards compatible also after upgrading.

I do realize that with the latest BETA and its extra possibilities, some UDFs won't run anymore with the regular production version.

For me the only real solution for that would be that AutoIt starts using the Include Subdirectory from its own directory in stead of both Production and Beta using the same set of UDF files.

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
Share on other sites

Why would a script processing the the script of interest not be able to see any of these UDFs used as parameters?

The script will have to be at least a partial parser of AutoIt code to detect such things.

Would you give an example of a UDF called as a literal string?

#include <GUIConstants.au3>

Opt("GUIOnEventMode", True)
GUICreate("Title")
GUISetOnEvent($GUI_EVENT_CLOSE, "OnClose")
GUISetState(@SW_SHOW)
While True
    Sleep(25)
WEnd

Func OnClose()
    Exit
EndFunc

The function "OnClose" is never directly invoked. Instead a string containing the name of the callback function is passed as a parameter and AutoIt will invoke this function when appropriate. A simple parser looking for function invocations will remove "OnClose" and your script is no longer valid.

Furthermore, I can do this and make your parser have to do even more work:

#include <GUIConstants.au3>
 
Global $sFunction = "OnClose"

 Opt("GUIOnEventMode", True)
 GUICreate("Title")
 GUISetOnEvent($GUI_EVENT_CLOSE, $sFunction)
 GUISetState(@SW_SHOW)
 While True
     Sleep(25)
 WEnd
 
 Func OnClose()
     Exit
 EndFunc

Both of those examples are perfectly valid, legal and common scripts (tested under 3.1.1.91).

Would you further explain "known at compile time when functions are processed for exclusion."?

Functions which are invoked through the standard syntax with parenthesis are known at compile time. Some functions, such as in the example above, are not known until run-time. The function "OnClose" may or may not be called, depending on whether the script is closed by the GUI or by selecting Exit from the tray icon. That is one form of run-time function, although in most cases it can still be detected at compile time with a little effort.

The other form of run-time function is:

If $CmdLine[0] Then
    Call($CmdLine[1])
    If @error Then
        MsgBox(4096, "", "Invalid function")
    EndIf
Else
    MsgBox(4096, "", "Usage: " & @ScriptName & " <MyFunc1 | MyFunc2>")
EndIf

Func MyFunc1()
    MsgBox(4096, "", "MyFunc1")
EndFunc

Func MyFunc2()
    MsgBox(4096, "", "MyFunc2")
EndFunc

Neither MyFunc1() or MyFunc2() are invoked. However, if you call the script and pass the name of the function as a command line argument, that function will be invoked at run-time via Call().

The script which excludes unused functions is run at compile time. Such a script is going to be looking for function invoked using the parenthetical method. A simple script will accidentally remove functions not invoked using the parenthetical method. Even an advanced script which tries to resolve function names when passed as strings will still fail some of the time when the string isn't generated until the script is run.

Link to comment
Share on other sites

The script will have to be at least a partial parser of AutoIt code to detect such things.

#include <GUIConstants.au3>

Opt("GUIOnEventMode", True)
GUICreate("Title")
GUISetOnEvent($GUI_EVENT_CLOSE, "OnClose")
GUISetState(@SW_SHOW)
While True
    Sleep(25)
WEnd

Func OnClose()
    Exit
EndFunc

The function "OnClose" is never directly invoked. Instead a string containing the name of the callback function is passed as a parameter and AutoIt will invoke this function when appropriate. A simple parser looking for function invocations will remove "OnClose" and your script is no longer valid.

Furthermore, I can do this and make your parser have to do even more work:

#include <GUIConstants.au3>
 
Global $sFunction = "OnClose"

 Opt("GUIOnEventMode", True)
 GUICreate("Title")
 GUISetOnEvent($GUI_EVENT_CLOSE, $sFunction)
 GUISetState(@SW_SHOW)
 While True
     Sleep(25)
 WEnd
 
 Func OnClose()
     Exit
 EndFunc

Both of those examples are perfectly valid, legal and common scripts (tested under 3.1.1.91).

Functions which are invoked through the standard syntax with parenthesis are known at compile time. Some functions, such as in the example above, are not known until run-time. The function "OnClose" may or may not be called, depending on whether the script is closed by the GUI or by selecting Exit from the tray icon. That is one form of run-time function, although in most cases it can still be detected at compile time with a little effort.

The other form of run-time function is:

If $CmdLine[0] Then
    Call($CmdLine[1])
    If @error Then
        MsgBox(4096, "", "Invalid function")
    EndIf
Else
    MsgBox(4096, "", "Usage: " & @ScriptName & " <MyFunc1 | MyFunc2>")
EndIf

Func MyFunc1()
    MsgBox(4096, "", "MyFunc1")
EndFunc

Func MyFunc2()
    MsgBox(4096, "", "MyFunc2")
EndFunc

Neither MyFunc1() or MyFunc2() are invoked. However, if you call the script and pass the name of the function as a command line argument, that function will be invoked at run-time via Call().

The script which excludes unused functions is run at compile time. Such a script is going to be looking for function invoked using the parenthetical method. A simple script will accidentally remove functions not invoked using the parenthetical method. Even an advanced script which tries to resolve function names when passed as strings will still fail some of the time when the string isn't generated until the script is run.

Hi Valik,

You're right; these techniques will make it more difficult, especially the last one. However all the functions have to be defined, either in the script being scanned or in one or possibly more (assuming that there will be personal as well as "official" includes) of the includes.

What you have pointed out revises the logic of such an endeavor from starting with the script of interest to first finding all of the defines in the includes and hence their names then scanning the script for any references to them. That still leaves the issue of UDFs embedded in command line variables. I'll have to think about that. It may not be directly addressable, still that type of logic should not be that hard to recognize. In such cases the processing script may have to warn the developer that UDFs called in that manner cannot be ascertained at this time and give them the option to select them from the list of UDFs available in the includes and defined in the script being processed. B)

In January of 2004 I posted in the Yahoo file space a utility to find and xref all the variables, macros and UDFs. It was slow, but for all the files I tried it on and personally counted, it found them. I still think it had a fairly decent output. I revisited it recently and it has some problems with current scripts, especially as they get larger. Just for fun I've been playing with it and scripts that took it 2 minutes are now down to 2 plus seconds. That's for fun though; Tidy does a good job of xrefing and Tidies up too. :graduated:

Mine currently takes 329 Seconds for a 5049 line file

Tidy took 195 seconds just Tidying

Tidy took 482 seconds Tidying and Xrefing

So that's 285 for Tidy vs 329 for me, so far... Smaller is better. :o

With the problems you have presented, this whole endeavor has become more interesting. I still don't want to write the whole thing, but I like puzzles / problems that I'm not required to solve.

Thanks for the reply Valik.

PS. I have to admit that when I posted the original of this thread, I was just thinking about what would ease my personal burden. Even though I thought other people would be interested, I was focused on my own wants. Thank you for your latter comments.

[font="Verdana"]Thanks for the response.Gene[/font]Yes, I know the punctuation is not right...

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...