pAHKlight - Your Lightweight Guide to AHK libs+classes+tools

[joedf]

nnnik makes a point. Ill just post my "github-browser" tmrw, do critique my terrible coding practices

[hoppfrosch]

I think vaili111 and nnnik comments aim into the same direction:

How about "forced" libs.

AHK definitely needs to sort all usermade scripts and functions and make good documentation. But it will not be standard library, it will be collection of scripts and functions. I think AHK also needs real standard library not only collection of scripts.

I personally think vasili111 hit the point. We do need a standard library - but for a beginning we should start minimalistic: a collection of scripts. Having this we might classify the collection and identify candidates for stdlib. Let's start towards minimalistic goals - I've seen to many high-flying plans failing (including personal projects ...)

The Stdlib should be part of AHK-Distro and therefore match nnnik's "forced" libs. Members of the STDLIB should match much more quality criteria than members of the script collection (unified documentation, namespaces, versioning ...)

[joedf]

Yes I agree

[tomoe_uehara]

So, what should I do?

[joedf]

Contribute to a list of valid libs, and suggested user libs?

[ahk7]

OK as a proof of concept - I've incorporated a number of things in a DEV branch at GH https://github.com/hi5/pAHKlight/tree/dev
Download: https://github.com/hi5/pAHKlight/archive/dev.zip

Changelog:
+ Try Google button
+ Reset button
+ Category dropdown as additional filter (changed tags= to category= in INI - see below)
+ Improved regex used while searching (now using assertions)
+ Linked author name if URL is present in name (see below)

I've replaced tags with category - see a preliminary list here https://github.com/hi5/pAHKlight/blob/d ... gories.txt (taken from Tuncays stdlib ini database)

Although not entirely implemented yet in the DEV version I think I'm going to use the following structure for the database entries:

-----------------------
[sequential-number]
*name=
*fullname=
*author=name [@ URL]
*type=lib|class|function|tool
*source=URL
forum=URL [not always available]
category=[fixed list of terms - not mandatory sometimes to hard to assign one]
*description=
-----------------------

* are mandatory fields, so forum and category are not mandatory

author example:

author=fincs @ http://fincs.ahk4.net/

category=valid entries taken from categories.txt

Just "browse" through the categories and you'll see the results updated automatically, of course not all categories are used yet but you get the idea. It also acts as additional filter for the search. Gui is good example to try.

I'm hesitant to introduce an ahkversion field, the reason being is that I don't see that much value in it.
To give an example, the UUID function https://github.com/polyethene/AutoHotke ... r/uuid.ahk only works in AHK 1.0.48 because of a silly typo on line 31 (a . error) it is an easy fix to make it work. So classifying it as AHK 1.0.48 is accurate but also bit weird.

Also how should one interpret ahkversion? Some things work FROM a certain version (say StrSplit) other things UPTO a certain version, so you would have to start using things like
"=< 1.1.xx.yy 32-bit ANSI"
"1.1.xx.yy++ 64-bit" etc

Perhaps just adding it to the Description would be easiest, for example strongly advise to make it the first line of the description:

description=(All AHK versions)`n.....

description=(AHK 1.1+ 64-bit only)`n.....

description=(AHK v2.0-a)`n.....

etc? If you've got a good alternative I could be convinced

[joedf]

i like the update thumbs up
here is my "github-browser" if anyone is interested

ahklibr.zip

(4.96 KiB) Downloaded 229 times

[ahk7]

Keys indicating the AHK-compatibility (Version: 1.0.48-1.1.xx-2.x-all, 32bit-64bit-all, UNICODE ...)

I still think its a good idea to introduce this field. It's easy to provide the data at the time a new entry is added to the database - but a pain to do it at a later date. It does not cost to much effort and keeps the doors open ...

Perhaps an alternative interpretation of an ahkversion field would be:

"person who added it to the database has tested it with this AHK Version"

That at least gives some indication without making it a compulsory or a lot of work.

Otherwise: are you really going to test each entry with AHK Basic, AHK 32 Ansi/Unicode, AHK 64-bit just to be sure. Or are you going to guess it by glancing at the code (no DLL calls so should be OK for 32/64 bit) or just take the authors word for it?

Edit: unless - could you or someone else come up a script that looks at the source of a script and can determine which version it is compatible with: checking for certain commands, and with those commands try to see if they are 32/64 ansi and/or unicode? Then it would be an ahkversioncheck field as tested by this script making at sure the value of this field is consistent.

[ahk7]

I think v0.1 is now complete, see DEV branch here https://github.com/hi5/pAHKlight/tree/dev
Download: https://github.com/hi5/pAHKlight/archive/dev.zip
Feel free to test. (just to note: if you try "check updates" it will work but it will overwrite the DEV version with the older master version so be careful at this stage)

Next step would be to start building the database. Suggestions for categories are welcome(d).

There could be several methods of adding or suggesting packages

1 - a post here on AHKScript.org (this thread or a new pAHKlight-candidates thread)
2 - file an issue at GH (candidate label)
3A - pull request at GH on the master branch (this may be ineffecient in case you'd need to correct errors before adding it? Not sure as I'm not that familiar with GHs workflow)

As an alternative:

3B - Perhaps it would be easier to work in a new repository where candidates can be submitted and only after checking for format errors they would be moved into the main database. As an example I've setup a candidates repository here:

https://github.com/hi5/pAHKlight-candidates

Just prepare one INI per candidate and update the repository. Others can check and then update the main database.

Any thoughts on this?

Additional tool(s) that could be developed:

Tool 1: An editor (GUI) script to create new entries: this should check correct for formatting errors and see if the source url is not already present in the database as that might be the best indication to avoid duplicates. Or check name & author?

Tool 2: See post above - script to check AHK version compatibility

[ahk7]

forgot to include new database in DEV - works now...

[hoppfrosch]

Otherwise: are you really going to test each entry with AHK Basic, AHK 32 Ansi/Unicode, AHK 64-bit just to be sure. Or are you going to guess it by glancing at the code (no DLL calls so should be OK for 32/64 bit) or just take the authors word for it?

Edit: unless - could you or someone else come up a script that looks at the source of a script and can determine which version it is compatible with: checking for certain commands, and with those commands try to see if they are 32/64 ansi and/or unicode? Then it would be an ahkversioncheck field as tested by this script making at sure the value of this field is consistent.

As I seem to be the only one, who wants to have this field we might omit this - unless I still think the AHK-versin might be useful.

I haven't an automatic AHK-version validation in mind, what I thought about was to use the AHK-version the library/function author states the lib/func works with ... It should be guaranteed to work at least with this version - it might work with other versions as well...

[vasili111]

As I seem to be the only one, who wants to have this field we might omit this - unless I still think the AHK-versin might be useful.

I agree, version field will be very nice.


Also some scripts depend on other scripts. I think we need dependency field too.

[ahk7]

OK "final" version is now ready I think

Source: https://github.com/hi5/pAHKlight
Download: https://github.com/hi5/pAHKlight/archive/master.zip

Changelog:
- Adding ahkversion field to database - makes at least two people happy
- Upgraded Anchor to 64-bit (unicode) - polyethene's GH version is only works with Ansi
- MsgBox with Errorlog warning upon startup

Thanks joedf & hoppfrosch!

[george2]

Hey. o/
This tool looks pretty nice, I'm glad to see someone is working on a library management tool again.

I actually really like this idea, I know that George2 is maintaining a repo "ahk-libs" or something,
Maybe if I talk to him him about it, we could merge something with ahkscript group on githib and setup this lib distribution service thought github, then pull the info directly from there...
I will check on this. I am glad that you brought this up.

I would love this, shoot me an email or ping me on IRC if you want to talk about it. I see you have already done some work on it too.

Copying scripts to GH with(out) the Authors consent, knowledge and influence is not a good idea. Some script authors like to retain control over their code and also update it on their preferred location which may be a forum post or personal website (I could name a few important ones here already). So if you start to copy script(s) to GH your are ALWAYS are behind the current version, the author looses control and the user is directed to the "old" version which doesn't do anybody any favours.

Most of the stuff in my GH repo is submodules, meaning it points directly to the upstream source on GitHub. It takes one command to update all of them to the latest revision, and I do this on a regular basis. Libraries that exist only on the AHK forums or on AHK.net are more difficult, so there are only a few of these included. I did contact the devs I knew beforehand to make sure they were OK with me posting the libraries in this way, and all of the libraries in this repo have links to the upstream sources included.

I have also thought about moving this repo's ownership to a GitHub org that any ahk dev can join and contribute to (seems Uberi might have had the same idea). I really just want an easy way to centrally manage AHK libs, where anyone can contribute, and GitHub seems like a good place for that to me. If there's any way I can help accomplish this, please let me know.

[joedf]

@ahk7 no problem, cant wait for the full fledge distrib service submission is done through: GitHub? or forum PM, Email, wiki, or even a seperate page on ahkscript.org ... i could make one, or somekind of a beginning of such a page... submit and discuss this whole idea with the staff..

@george2 good to see you on this forum topic! im "pretty active" on this forum so i normally respond really quickly.. (sometimes faster than IRC ) .. When i first saw your repo of ahk-libs, i was really happy to see something like this, ..maintained ... so i made a "github-browser" that can browse repos which i posted here: http://ahkscript.org/boards/viewtopic.p ... 0255#p9899 (Screenshot: http://ahkscript.org/boards/viewtopic.p ... 1241#p9498 ) ... and ive tested with your ahk-libs repo, and it worked quite well, it can get the author, update time, creation time, url, etc... all this because of you used submodules. it makes it all so much easier. .. and thats when i saw that github could be a potential candidate... Since then, ideas have been made... still uncertain of how submissions would be made.. but i would really like this to be supported by ahkscript.org itself! ;D ... ill have to discuss this with staff... ill write a post now, and see what their opinions and ideas are..

cheers!

[nnnik]

Hi what if pAHKlite would adda standard Include.
With that Include, scripts should be able to test if an Include exists and if not ask the user to download it.

[joedf]

That's a good idea, and maybe if we make all libraries hosted in ahkscript, in case of abandon..
It would be downloaded directly from the "official repo" here..

[hoppfrosch]

That's a good idea, and maybe if we make all libraries hosted in ahkscript, in case of abandon..
It would be downloaded directly from the "official repo" here..

I'm not quite sure, which path to go ...

For the sake of maintainance and availability, it would be ideal to have all "libs" concentrated in a central place ...

On the other hand I totally agree with ahk7's objections:

Copying scripts to GH with(out) the Authors consent, knowledge and influence is not a good idea. Some script authors like to retain control over their code and also update it on their preferred location which may be a forum post or personal website (I could name a few important ones here already). So if you start to copy script(s) to GH your are ALWAYS are behind the current version, the author looses control and the user is directed to the "old" version which doesn't do anybody any favours.

I want to come back to my differentation between a stdlib and a simple catalogue of available scripts/libs/functions. pAHKLight fulfills the second task.

My vision:

• Let's collect and catalogue the current script landscape within the current distributed infrastructure. The tool we use for this is pAHKLight.
• Let's build a "board of honorable members", which looks over the catalogue and identifies candidates for a stdlib
• Those candidates should be hosted on a public, centrallized place as joedf suggested and build the stdlib
• Before being published as members of stdlib those candidates have to fulfill certain quality criteria (documentation, namespace, versioning ...)
• Becoming part of the stdlib should be a honour and obligation to the author (obligation to maintain it on a standardized location, considering certain standardized requirements - honor to be part of the stdlib (which should become essential part of AHK culture, like pypi or cpan ....))

[joedf]

I agree, but what I meant by "repo" is that of those that will in the stdlib, as you have suggested "candidates", could host at http://ahkscript.org ... But I am still unsure like you are

[ahk7]

Everyone is welcome to submit entries for pAHKlight:
- By posting an entry in the INI format here in this thread
- Pull request(s) on GH @ https://github.com/hi5/pAHKlight
- Opening an issue on GH (there is a label "candidate" you can use)
- Pull request(s) on GH @ https://github.com/hi5/pAHKlight-candidates