43 replies to this topic

[majkinetor]

Because modern computers are fast and have plenty of memory.

You have a point.

I understand your concern, but I think that even loading and parsing a 1MB library file

Not sure about that. I notice something in my big scripts (like Favmenu witch is 5000+ lines). When tray icon is loaded after everything else, there is a 1 second delay on my 2x3GHz CPU with 1GB memory. When I set it to be first line, I never see H icon.

Plus I don't see any advantage, unless parsing and referencing is done one time before shipping AutoHotkey and stored in some "database". If this is done dynamically, not only AutoHotkey will still have to load the library and parse it (at least to skip non-relevant functions) anyway, but has to resolve dependencies!

I think you overestimated complexity of this. AHK still need to parse each function it includes. Currently, if it encounteres missing funciton it will report. SO, the only thing that has to be done is not to report it, but to search in the rest of the included files. This can be cached, so it will fast.

Crhis might be able to provoide some insight for this situation.

[Chris]

These are good ideas; their intent is to make things more convenient for users (with reduced memory utilization) at the cost of increasing development time and code complexity. I'm not sure what the best compromise is.

Currently, I don't wish to get heavily into the design of stdlib due to work on v2 and other features. I'll certainly review all that's been said here when the time comes to work on stdlib, especially if any volunteers have become available. If any developers would like to work on the design and implementation of the features proposed here (such as an improved #include directive or a new #use directive), that would certainly help as well.

Thanks.

[majkinetor]

Fair enough

Thx

[corrupt]

What would you think of using the same file but using a specific prefix for user functions? Something like: usr_myfunct1, usr_playwav, usr_autolog, etc... The update script could then ignore all functions with a usr_ prefix.

The idea was to simplify the installation process, by just overwriting the system INI, but leaving the user's one untouched.
With your idea, Chris has to write a setup script (what it uses? Inno? Nsis?) that carefully deletes obsolete entries, updates others and create new ones. Doable, but might not worth the work.
Plus by separating them, the system one can be read-only, and users won't have a chance of messing with it by error, wanting to change something in their own.
Of course, having a script to automate management of user script is easy to do and should reduce the risk of errors.

There are 3 main reasons I'm currently suggesting to use the same file:

- To try to simplify the task of searching for a function that has not been declared in the main script. If 2 files are used then 2 files will need to be searched

- To avoid duplicate function names

- To deter manually editing Standard Library functions and encourage submitting changes for official distribution. Users could still modify functions but use a different name to avoid the function being overwritten.

I would be willing to put together an update script for installation, and an IDE for users to use to add/modify/delete user functions, view a list of Standard Library functions with descriptions and usage, update functions from webserver, etc... if this sounds appealing .

[PhiLho]

- To try to simplify the task of searching for a function that has not been declared in the main script. If 2 files are used then 2 files will need to be searched

Seems like a non-issue here.

- To avoid duplicate function names

That's a point, but you can have duplicates in the same INI file too.

- To deter manually editing Standard Library functions and encourage submitting changes for official distribution. Users could still modify functions but use a different name to avoid the function being overwritten.

Here I don't get it. How it is related to the problem of two INI files? Actually, having a separate system file allow to make it read-only (and even hidden!).

[Chris]

Also, there's a plan to allow dynamic function calls. This might impact the plans mentioned here because there would be no way to know in advance what functions a script will call. The program could dynamically look up a function in some other file when the call occurs. But in addition to complicating the implementation, that wouldn't work for compiled scripts.

You could argue that any user of dynamic functions must explicitly include such functions. However, that might cripple the standard library's usefulness for dynamic calls and/or produce poor script maintainability (depending on how the library is implemented).

[majkinetor]

You could argue that any user of dynamic functions must explicitly include such functions

Yes we can and we will

Metaprogramming is one of the most important parts of current programming stage. It is supported in all mainstreem languages. Benefits of metaprogramming are of such measure that its better to create some rules for eventual problems then not to allow it becuase of them.

It is indeed question what to do for compiled scrpits ....
One solution may be that compiled scripts that use dynamic calls with stdlib should be compiled with all stdlib functions. Or, all stdlib functions can be even compiled in dll that can be shipped with the exe if dyn calls are used. This allows users letter to extend existing compiled script buy supplying newer version of this dll.


Then there is the thing you mentioned before - the one can try to extract, if possible, functions it may reference and paste them into his script. This will be very much achievable with eventual extended #include syntax that could be able to specify single file or range of files to be included via some metacharachters or reg exp.

Eatch of those things will probably need some compiler option.

[Tuncay]

Is there any possibility of supporting for regular expression on #Include? For example
Code (Copy):
#Include *i *r ".\lib\.ahk$"
The *r stands for regex.

It doesn't seem like that much a benefit to me (I can't envision many people using it). If anyone else feels this should be added, please give as much detail or real-world examples as you can.

I want make an own extensions framework, where every extension in a folder should be included automatically.

[Chris]

Thanks for the example. I can envision something like this getting added someday; but due to other priorities it might be a long time.

[majkinetor]

It doesn't seem like that much a benefit to me (I can't envision many people using it)

It can be very useful for plugin system in AHK.

IMagine we have one AHK script, witch do something, lets say system analise and have plugins to measure different things, like CPU, Memory, etc... Eatch plugin is contained in separate AHK include and to install it, you simple need to copy it in plugins folder.

Today, there is no way of plugin host to automaticaly include all ahk files in plugin folder on its startup as it doesn't know the names of the AHK plugin script in advance:

plugins\Cpu.ahk
plugins\Memory.ahk
...
Beside selfmodifying host, today, the only thing AHK plugin host can do is to reserve some name for plugin, like PluginXX.ahk

plugins\Plugin00.ahk
plugins\Plugin01.ahk
and to put include array :

#include *i plugins\Plugin01.ahk
#include *i plugins\Plugin02.ahk
#include *i plugins\Plugin03.ahk
...
#include *i plugins\Plugin99.ahk

Contrary to this weird scenario using regular exrpressions we can keep meaningfull names for plugin scripts and import all of them with single regex include:

#include *r plugins\\.*\.ahk$

[PhiLho]

Using regexes is a bit of overkill, the Java way is to include either a given class (set of functions) or all the classes of a group:

import java.awt.*;
import java.awt.event.*;
import java.io.*;
import java.text.SimpleDateFormat;
import java.util.*;

import javax.swing.*;
import javax.swing.filechooser.FileFilter;
import javax.swing.table.*;
import javax.swing.tree.*;

In Lua, you just specify which files you want to load:

local m = require"LPeg" -- Usually a DLL
(loadfile[[C]])() -- Direct call!
dofile"DumpObjects.lua" -- Kind of include

[majkinetor]

Any way will do...

[Tuncay]

The point is not that it must be regex, simple wildcard support would help much, if regex is too slow.

#include *i *.ahk

[majkinetor]

I also think that support for environment variables is important.

For instance, I keep all my scripts in %UTILS%\_Scripts\Autohotkey folder.

I want to be able to use:

#include %utils%\_Scripts\autohotkey\Functions\Unicode.ahk

or at least when specifying directories with includes:

#include %utils%\_Scripts\autohotkey\Functions\
#include Unicode.ahk

Relevant documentation topic:

#Include / #IncludeAgain
....
Directory: In v1.0.35.11+, specify a directory instead of a file to change the working directory used by all subsequent occurrences of #Include and FileInstall. The directory name must not contain variables other than %A_ScriptDir%, %A_AppData%, and %A_AppDataCommon%.

This should not be mixed with variables as stated in docs as when AHK includes files, script is not yet running, so refering to variables is out of scope. I am refering to Windows system syntax for environment variables witch is today the same as for AHK variables. Ad AHK vars will soon (I hope so) be switched to $ syntax, this will be more obvious.

This is very important in order to support portability. There are many situations where refering to environement variables instead of hardcoded paths is more apporopriate. Even Windows keeps mass of its system data in Registry by using %WINDIR% %USERPROFILE% etc...