View topic - AutoHotkey Needs You • AutoHotkey Community

View unanswered posts | View active topics

Board index » AutoHotkey » Suggestions

All times are UTC [ DST ]

AutoHotkey Needs You

Page 3 of 5

[ 61 posts ]

Go to page Previous 1, 2, 3, 4, 5 Next

Print view | E-mail friend

Previous topic | Next topic

Author

Message

PhiLho

Post subject:

Posted: November 26th, 2006, 10:19 am

Joined: December 27th, 2005, 1:46 pm
Posts: 6837
Location: France (near Paris)

Yes, the difficulty is to maintain a balance between size of file to include (loading 1MB to get one function is too much) and number of needed functions loaded at once.
Also it would need some authority to supervise this organization: I don't want PHP's confusing list of functions, where you have something like (non-real example) instr, str_reverse, strupcase, string_randomize. Ie. non consistency on function naming, making hard to do searches, to memorize, etc.
AutoHotkey is already pretty consistent on its naming convention (InStr is one of the exceptions, not a big problem), so we should stick to this convention.
Although I prefer to start my function names with a verb, here we should have a prefix by category. Call it poor man namespace...
That would give: StrReverse(), FileDiff(), ArrayInvert(), GdiDrawRect(), ProcessExist(), etc.

I am not fond of the idea of using the <> around the paths of the stdlib, like in C. Not in AHK spirit to avoid extra ponctuation. Maybe with a special include instruction:
#IncludeStd String Searches
#IncludeStd Array * ; We want all stdlib functions related to arrays!
A bit like Java's import instruction.

_________________

vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Top

majkinetor

Post subject:

Posted: November 26th, 2006, 8:37 pm

Joined: May 24th, 2006, 2:49 pm
Posts: 4511
Location: Belgrade

About importing small number of functions from big collection of them, contrained in some general library, I am afraid that this must be supported by the language. AFAIK, even in C all things in external library are imported even if you include just one func. Delphi did it another way, so if you use single function from external unit, it will import only that one.

My syntax proposition is this:

Code:

#use, [file\]function [, name]

Examples:

Code:

1. #use, String.ahk                             ;include everything from String.ahk

2. #use, String.ahk\StringReverse              ;include just StringReverse function under its original name from String.ahk

3. #use, String.ahk\StringReverse, StrReverse  ;use just one function from given file under new name, StrReverse

4. #use, StringReverse, StrReverse              ;make the new name for the given function existing somehwere in the code 

   ...
   ...

   #use String.ahk                          ; this makes func available in the code

This makes #include obsolete.

When stdlib is created, AHK can ship it with instalation. So when you skip path, it can be searched under AHK folder for stdlib match.

So, creating just this single update to lang can make many things very nice. I suppose implementing such addon can not be very complex.

_________________

Last edited by majkinetor on November 28th, 2006, 9:16 am, edited 2 times in total.

Top

Chris

Post subject:

Posted: November 28th, 2006, 4:35 am

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720

Thanks for the ideas.

Although the syntax is more complicated than I'd hoped, maybe more people would prefer it that way. When the time comes and there's any doubt, we could have a poll to decide.

Top

majkinetor

Post subject:

Posted: November 28th, 2006, 9:12 am

Joined: May 24th, 2006, 2:49 pm
Posts: 4511
Location: Belgrade

Well, if anybody can thought out any other syntax with the same functionality that is easier than this, I would like to hear it.

I don't think it is complex as you can always omit second parameter, so it basicly becomes generalised #include. This is similar to what you have with number of commands in ahk that have bunch of non mandatory parameters. It may seem complex when U provide syntax for it, but in reality it is not.

NOTE: I edited example list above to present it more natural (Complexity is increased with eatch next example )

_________________

Top

Chris

Post subject:

Posted: November 30th, 2006, 1:24 pm

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720

majkinetor wrote:

I edited example list above to present it more natural (Complexity is increased with eatch next example )

That helps because I'd read it too hastily before. Now I understand it better and like it more.

One drawback to this is development time and code size. It would probably take a lot longer to implement this than the simple #include extension I had in mind. Another consideration is how many people would actually use the ability to include only selected functions from a file. Clearly it would be useful to reduce the size of compiled scripts, but for normal scripts, the benefits seem very small: a savings of under 20 KB of memory in most cases, and with no benefit to performance.

Thanks.

Top

majkinetor

Post subject:

Posted: November 30th, 2006, 2:59 pm

Joined: May 24th, 2006, 2:49 pm
Posts: 4511
Location: Belgrade

Quote:

Another consideration is how many people would actually use the ability to include only selected functions from a file. Clearly it would be useful to reduce the size of compiled scripts, but for normal scripts, the benefits seem very small: a savings of under 20 KB of memory in most cases, and with no benefit to performance.

Today yes.
Tomorrow with large standard library, not.

This is reqest related to stdlib.

_________________

Top

JSLover

Post subject:

Posted: November 30th, 2006, 5:19 pm

Joined: December 20th, 2004, 12:19 pm
Posts: 798
Location: LooseChange911.com Ask Questions, Demand Answers █ The WTC bldgs █ shouldn't have fallen █ that fast

Chris wrote:

Another consideration is how many people would actually use the ability to include only selected functions from a file.

...I would use it...but not by specifying each function...my Reference only include/mode...could do this...it would either read/parse each include & only keep in memory what it needs to run...or thinking of it the other way...it would only look in the includes if a function (or variable etc) is used but never defined...before it throws an error, it would check each include for the function & not throw an error if it's found...ok, sorry I already mentioned that in this topic...but his idea is almost the same...but mine don't require you to list each function you want...

_________________
AutoHotkey-Hotstring.ahk - Helping the world spell "AutoHotkey" correctly! (btw, it's a lowercase k!)

Top

majkinetor

Post subject:

Posted: November 30th, 2006, 7:29 pm

Joined: May 24th, 2006, 2:49 pm
Posts: 4511
Location: Belgrade

This is not complete proposition, just an idea. Regular Expresssions or some other mechanism could help specifying function collection you want to add. For instance, if you have 1 big script containing all modules of stdlib:

#use Stdlib\String_* to import them all

Other alternative would be to include file with the set of functions you want

Code:

File: MyStdLibFuncs.ahk

#use Stdlib\Func1
#use StdLib\Func2

#use StdLib\FuncN

then latter:

#use MyStdlibFunc.ahk

Your "reference only mode" seems good to me. So in this case, AHK wouldn't merge them into single script but create symbol tables of things in all scripts referenced so to able to know where the given function resides. This would slow down execution alot, especialy with large libraries like Stdlib will become, except if some type of cashing is done on some temporary place by AHK.

But this is generaly speaking, the best solution. This is how Delphi handles it. You just need to know where is the given function located, and put that UNIT in the reference list. Only that function will be taken to final executable. The problem is this: not only that function need to be taken, but also the functions that THAT function use. So .. it requires a lot of parsing to find this chain referencing (but this is true also in my case...)

The one thing is sure - we need to carefully think about this, as the future of stdlib will depend on how succesifully is this issue solved...

_________________

Top

corrupt

Post subject:

Posted: December 1st, 2006, 2:37 am

Joined: December 29th, 2004, 1:28 pm
Posts: 2545

http://www.autohotkey.com/forum/viewtop ... 6&start=15

Any thoughts?

Top

JSLover

Post subject:

Posted: December 1st, 2006, 10:19 am

Joined: December 20th, 2004, 12:19 pm
Posts: 798
Location: LooseChange911.com Ask Questions, Demand Answers █ The WTC bldgs █ shouldn't have fallen █ that fast

corrupt wrote:

Any thoughts?

...yes, don't link with a plain url...use the subject as the text of the link...

Small Extension to #Include

...much clearer...

_________________
AutoHotkey-Hotstring.ahk - Helping the world spell "AutoHotkey" correctly! (btw, it's a lowercase k!)

Top

majkinetor

Post subject:

Posted: December 1st, 2006, 11:32 am

Joined: May 24th, 2006, 2:49 pm
Posts: 4511
Location: Belgrade

lol

_________________

Top

corrupt

Post subject:

Posted: December 2nd, 2006, 3:54 pm

Joined: December 29th, 2004, 1:28 pm
Posts: 2545

JSLover wrote:

...yes, don't link with a plain url...use the subject as the text of the link...

Small Extension to #Include

...much clearer...

Bugs Bunny wrote:

Nyyyaaaaahhh... Shaddupp

Since it's obvious that it links to an Autohotkey forum topic by the URL I don't see the point... but thanks for wasting a bit of extra bandwidth and storage by pointing that out. Any constructive thoughts :roll:

...?

Top

JSLover

Post subject:

Posted: December 2nd, 2006, 5:19 pm

Joined: December 20th, 2004, 12:19 pm
Posts: 798
Location: LooseChange911.com Ask Questions, Demand Answers █ The WTC bldgs █ shouldn't have fallen █ that fast

corrupt wrote:

Since it's obvious that it links to an Autohotkey forum topic by the URL I don't see the point...

...yes, but by the url I don't know WHAT topic...topic 8246 doesn't register with me...it's as bad as "click here" links (W3 - Don't say click here)...I (& other people) don't like clicking on crap that don't say what it is...you want people to click...give them a reason...some context for what clicking will take them too...like the forum subject...

corrupt wrote:

Any constructive thoughts

...that is constructive...linking with stupid plain urls or click here isn't helping anyone...it looks like forum barf with plain urls everywhere...never know whatcha gonna get...plus urls can be long & cause horiz scrolling...

_________________
AutoHotkey-Hotstring.ahk - Helping the world spell "AutoHotkey" correctly! (btw, it's a lowercase k!)

Top

corrupt

Post subject:

Posted: December 2nd, 2006, 5:55 pm

Joined: December 29th, 2004, 1:28 pm
Posts: 2545

JSLover wrote:

...linking with stupid plain urls or click here isn't helping anyone...it looks like forum barf with plain urls everywhere...never know whatcha gonna get...plus urls can be long & cause horiz scrolling...

Neither is this conversation... If you want to find out what it links to then click the link. I haven't been known to post spam or inappropriate, completely unrelated links. It might not have mattered if I gave the previous subject title as that title might not have indicated to some people that the text linked to was directly related to discussing possible "Standard Library" implementation either. I did take the time to link to the relevant post within the topic... Anyway... Here's the suggestion I had made in the other topic for anyone that may have been hesitant to click on the mysterious, possibly evil looking link that I had posted, in hopes that this topic may now return to a constructive discussion.

corrupt wrote:

Instead of adding options to #Include I had pictured adding a standard include library a bit differently. I haven't put a lot of thought into it but here's the basic idea that I had:

- Create an Include directory in the AHK installation folder
- Create an ini file in this directory called index.ini
- The ini file would contain a function section with a list of commands as keys with the corresponding values being the name of the file containing the associated function in the Include directory.

Then, when a new script is loaded and parsed and finds a reference to a function that doesn't exist, it then checks the .ini file. If the function is found in the .ini file, the associted file containing the function is included at the end of the script.

This way the include directory becomes a standard include library and only scripts that use the included functions are affected. This also allows others the ability to add additional files and update the index to add additional functionality.

An ini file may not end up being an ideal candidate but I've suggested an ini file to make searching for existing/possibly duplicate functions easy, a means to quickly generate a list of functions currently included, a method of adding descriptions for functions in a different section, date function was last updated, function version, etc... all from within one file.

I'm not certain about how easy it would be for the AutoHotkey installer to update the Include directory using this method but it could be as easy as adding an option to run a script at the end of the install process.

This script could then search the .ini file for standard functions and update as necessary. To simplify things a key could be added for each function in a different section with a non-standard include flag to indicate functions that shouldn't be overwritten by the install process. This section (maybe named update) could be checked when updating. If a function name exists as a key with a value of "False" in the update section for example, that function would not be updated/replaced during the install process.

This would make adding additional options to #Include unnecessary and would allow a fair bit of flexibility.

Top

majkinetor

Post subject:

Posted: December 2nd, 2006, 8:54 pm

Joined: May 24th, 2006, 2:49 pm
Posts: 4511
Location: Belgrade

Quote:

I haven't been known to post spam or inappropriate, completely unrelated links.

Tell that to the n00b that will probably walkaround this place, once in the lifetime, looking at plain URL having to horizontaly scroll suspicious links provided by one of the forum users witch names itself "corrupt"

_________________

Top

Page 3 of 5

[ 61 posts ]

Go to page Previous 1, 2, 3, 4, 5 Next

Board index » AutoHotkey » Suggestions

All times are UTC [ DST ]

Who is online

Users browsing this forum: No registered users and 8 guests

You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum