Just for discussion

[therks]

The only reason I mentioned the addition of a Gaming sub-forum was not to encourage these fools, but to discourage them from saturating Help & Support with nonsense and idiocy.

I have occasionally thought of this myself. We get a lot of gaming and bot related questions and I wish they would just do it somewhere else. Perhaps a separate, off site, forum is the best way to do it.

Or perhaps Jon could leave that gaming forum visible, but locked, and just move all the stupid gaming threads in there.

[Gif]

IMHO the most important improvement that autoit has to work on is the speed. AutoIt is way too slow to write a real program in it.

[dandymcgee]

Maybe someone could get a free host somewhere and make it just an AutoIt bot forum. Then we can link the skiddies to it and keep them off our nice server.

EXCELLENT idea... Senton-Bomb I'd be glad to help out if you need anyone.

[Zedna]

AutoIt wasn't made to write applications in....It was made mainly for repetitive tasks but now has some kewl added features.......

Writing "real programs" is what C++, VB and those other languages are for.

Yes. that's true.

But AutoIt's power (functionality possibilities) has reached so far that now it can be fully used also as programming (not only scripting) language.

It's my case :-) I don't need Delphi anymore from time when AutoIt v3 was born

[Gif]

Yes. that's true.

But AutoIt's power (functionality possibilities) has reached so far that now it can be fully used also as programming (not only scripting) language.

It's my case :-) I don't need Delphi anymore from time when AutoIt v3 was born

Yes thats my point, i don't mean writing huge official programs but at least nice small applications. I got a huge taste of Autoit's speed when i wrote a task to retrieve current installed ActiveX objects (name and path) and add then in an array in AutoIt and Python.

Python approx. 28 seconds

AutoIt approx. 3 minutes

Except it's speed AutoIt is a great language with much potentials.

Edited January 6, 2008 by Gif

[weaponx]

Yes thats my point, i don't mean writing huge official programs but at least nice small applications. I got a huge taste of Autoit's speed when i wrote a task to retrieve current installed ActiveX objects (name and path) and add then in an array in AutoIt and Python.

Python approx. 28 seconds

AutoIt approx. 3 minutes

Except it's speed AutoIt is a great language with much potentials.

I would like to see this example, is it posted? It sounds like maybe the AutoIt code wasn't written in the most efficient way.

[Valik]

Agreed. AutoIt is somewhat unintuitive as far as optimization goes. Meaning, things you'd think would be huge performance gains sometimes aren't where-as little things you'd think don't matter sometimes produce huge gains.

[Locodarwin]

I've dreamed of and actually made steps toward creating an AutoIt compiler. Not necessarily straight to ML, but something that translates AutoIt scripts into assembler (i.e. http://nasm.sourceforge.net/ ), which is then compiled into ML.

I'd started working on it about a year ago, and actually had a pretty good parser going - but the task of translating all of those built-in functions into assembly would take a lot of time I don't have. I put it on the shelf.

If someone wanted to turn AutoIt into a "true" Windows programming language, that'd be one good way.

It would be easier for the developers of AutoIt to create an AutoIt to C++ conversion tool, since the routines are already there. Still a great deal of work, though.

-S

[GaryFrost]

I care less about breaking scripts than I did in the past. Hence the recent GUIConstants.au3 change which is going to piss a lot of people off.

To address each point:

Multi-threading is seldom needed. Most of the people who "need" it don't really, they just think they do.

I would be more interested in a syntax like Lua that allows pseudo-object oriented programming but it's not really that important.

This isn't possible as long as we compile C++ to machine code for our binaries. Scripts could be trimmed down, yes, but not the binaries themselves.

FileInstall is a compile time feature with a runtime component. In the future, this logical distinction between the halves of FileInstall() will be made more apparent, which will stop the requests and also render them rather pointless. In other words, FileInstall() is going to be re-written in the future.

This feature will not exist in an AutoIt 4 if I'm a developer.

There's nothing wrong with the core of AutoIt 3 now, except that it's too big and there's too much to work on. But that wouldn't change with a new core. It's been proven time and time again that things we never thought would be in the language have found there way there. Things I never thought we'd see, like Unicode support, have been added in. Unicode is much like multi-threading, it's a major pain (Jon will tell you this) to retro-fit to a program.

As time goes on, things are being rewritten, anyway. Soon the whole Stdio redirection and a large chunk of Run() will be re-written and expanded with bugs fixed (soon as in some is done and hopefully the rest will be done this weekend). Jon is wont to do the same thing, rewriting large parts of AutoIt while leaving the public-facing interface largely unchanged. As I've already mentioned, FileInstall() is on the list of things to be rewritten (in a non-backwards compatible manner).

AutoIt 3 is still evolving, both internally and publicly. It's not time to think about an AutoIt 4 yet.

I would think AdlibEnable/AdlibDisable could go away also. Could be replacee with something like SetTimer/KillTimer now that Callbacks can be done, this would give the user the ability to have multiple functions that run at timed intervals.

[Valik]

It would be easier for the developers of AutoIt to create an AutoIt to C++ conversion tool, since the routines are already there. Still a great deal of work, though.

The problem there is, it requires everybody to have at least Visual Studio Express 2005 installed to compile a script. I think that's about the minimum compiler any of us use now. AutoIt may still compile with VS2003 but I don't remember the last time anybody tried. Furthermore, as a closed source language, it'd be trivial to intercept the raw C++ code on its way to the compiler, thus, all our secrets are out.

Everybody just needs to accept the fact that AutoIt is not going to compile straight to machine code, it's going to be interpreted by a program written in C++. If that isn't acceptable for a specific project, then write it in a different language. AutoIt is how it is and no amount of wishing and bringing it up time and time again is going to change that. Besides, that's rather the point of multiple languages, having options on which language to use to fit which need. I freely move between AutoIt, C++ and Lua, as circumstance dictates. Even a bit of assembly if the need arises. I don't sit around and whine "Oh AutoIt can't do this how I need" or "Lua doesn't allow this". Surprisingly, given my propensity for bitching, I focus more on solving the problem at hand rather than bitching about my favorite hammer can't do a particular job. That's an attitude I wish others would take before I decide to start embedding my favorite hammer into people's skulls for being so daft and cheeky to ask for something we said we won't do and if we do end up doing it we're probably not going to tell you about it until it's done anyway (we're bastards like that). No, that's not foreshadowing. Are there things in the next release you don't know about? Sure. Is it this? No.

[therks]

...if we do end up doing it we're probably not going to tell you about it until it's done anyway (we're bastards like that).

Actually I agree with a mentality like that, especially for unexpected things that people would really want, once they know it's in the works. Kind of like the idea of an AutoIt4 even. As far as I understand, rewriting the language from scratch is not something that would happen quickly, so I wouldn't even announce that it's started because then you're just going to get posts from the impatients like once a week, "what's the progress?" "when's it coming out?" etc.

If you guys start an AutoIt4 (presuming you haven't already, haha) then I say don't even tell us about it. The anticipation will kill some people.

No, that's not foreshadowing. Are there things in the next release you don't know about? Sure. Is it this? No.

Oh! What kind of things what kind of things!?? When's the next release coming out anyway, it's been forever!!!

[Valik]

Oh! What kind of things what kind of things!?? When's the next release coming out anyway, it's been forever!!!

Assuming Jon waits like I asked... then the next release is coming out as soon as I finish making StdoutRead()/StderrRead() not backwards-compatible. And for me to fix a bug.

If you guys don't hate me enough already, you're going to very soon. GUIConstants.au3 is not backwards compatible and so far, neither is StdoutRead()/StderrRead().

[weaponx]

I agree with Valik here. If your script begins to push the limits of AutoIt you have to make an executive decision.

A: Write a dll in C++ that can do what you need and include it with your script

B: Start over in C++ using AutoitX for the groundwork

C: Panic

If AutoIt can't create the GUI you need, write your GUI in Flash and compile it with Zinc or Swf Studio

If AutoIt isn't fast enough, ask for advice because after all AutoIt is still C++ at the core.

[Jon]

As much as I'd love to reboot and start AutoIt 4 it's probably not going to happen. Mainly because if I'd known the sheer mind boggling size of Autoit, the helpfile pages, the C++ and asm learning, the linux _agonizing_ learning (web support, subversion, new toys) and the total time-burgling nature of it then I wouldn't have even started it. I'm sure I could have used the time and money more productively!

On the other hand I learnt about things I'd never have otherwise touched and that are useful for work (sometimes at home) and it's helped me get a couple of jobs. Maybe better than sitting down the pub every night after all

The problem with pushing further down a full programming language road is that I don't really see the point. There are awesome programming languages out there already. And like Valik, I tend to pick languages based on need. If I want to do something that works pretty well and is supportable for a lot of people I'll use VBScript. If I need a fast and small dialog-based app (like GImageX I did recently) I'll use C. If I want something that can automate some tricky apps and is a half-decent scripting language I'll use AutoIt. None of the other devs have really ever liked AutoItX (AFAIK) - but I've got a real soft spot for it - because it isn't trying to be a new language, it lets you add AutoIt-ness to other languages and that will never go out of fashion I need to give it some love soon because some of the interfaces are well dodgy.

Performance-wise AutoIt is slower than I'd like. But it really is much improved since 3.2.4.0. I spent a couple of weeks doing nothing but optimizing and a lot of people who used to "bash" AutoIt compared to other languages need to re-do their perf tests But there is always room for improvement so you are welcome to post scripts that you consider being slow (you may get flamed ofc )

[Locodarwin]

The problem there is, it requires everybody to have at least Visual Studio Express 2005 installed to compile a script. I think that's about the minimum compiler any of us use now. AutoIt may still compile with VS2003 but I don't remember the last time anybody tried.

Sure, that requirement would be there. I don't see that as much of a problem for the typical, talented AutoIt programmer. Or, to look at it another way - anyone who can't figure out how to do it won't get to do it.

Anyway, it was only a statement of fact. I never suggested this particular project as something that should be done.

Furthermore, as a closed source language, it'd be trivial to intercept the raw C++ code on its way to the compiler, thus, all our secrets are out.

That would be the real crux of the problem.

Everybody just needs to accept the fact that AutoIt is not going to compile straight to machine code, it's going to be interpreted by a program written in C++.

....

That's an attitude I wish others would take before I decide to start embedding my favorite hammer into people's skulls for being so daft and cheeky to ask for something we said we won't do and if we do end up doing it we're probably not going to tell you about it until it's done anyway (we're bastards like that). No, that's not foreshadowing. Are there things in the next release you don't know about? Sure. Is it this? No.

No disagreements, here, for the most part.

I suppose the dream stems from an old-school desire I've always had. The best language out there should also be the among fastest and should compile natively.

I mean, let's face it. From a programmer's point of view, AutoIt as a language is simply beautiful. The syntax is simple, its handling of data is intuitive, and it can interoperate with basically anything with relative ease. Throw in the ability to control Windows in a way I haven't seen since SilkTest or Winbatch, and you have a pretty elegant, all-purpose dream.

Maybe I'll take that project down off the shelf...

-S

[therks]

If you guys don't hate me enough already, you're going to very soon. GUIConstants.au3 is not backwards compatible and so far, neither is StdoutRead()/StderrRead().

I had actually thought the GUIConstants change would already be in effect for 3.2.10, and was surprised when it wasn't. I have since made the alteration myself (although I'm frustrated when I try to test other people's GUI code and they've relied on the bad behaviour and I have to fix it myself).

Have to mention though, did you notice the GUIDefaultConstants.au3 is just as bad? I think that needs to be split up so that each default style is defined within it's respective constants file. Also it defines $DEFAULT_GUI_FONT, which is used in several of the API calls, so perhaps it should be declared in that include (WinAPI.au3)?

[Valik]

Yeah, I know about GUIDefaultConstants.au3. Probably should just use the hard-coded values and put in a comment which styles are being used. That's the sort of ugly crap that once has to do to make a small, fast library because otherwise I'd be against magic values.

[GaryFrost]

I had actually thought the GUIConstants change would already be in effect for 3.2.10, and was surprised when it wasn't. I have since made the alteration myself (although I'm frustrated when I try to test other people's GUI code and they've relied on the bad behaviour and I have to fix it myself).

Have to mention though, did you notice the GUIDefaultConstants.au3 is just as bad? I think that needs to be split up so that each default style is defined within it's respective constants file. Also it defines $DEFAULT_GUI_FONT, which is used in several of the API calls, so perhaps it should be declared in that include (WinAPI.au3)?

I had already moved $DEFAULT_GUI_FONT to WinAPI.au3 a while back in doing much of the cleanup that I was asked to do.

[Valik]

Gary, I leave it up to you. Saunders suggestion sounds sensible as does mine. If you want to get rid of GUIDefaultConstants.au3, use Saunders suggestion and make it go away. Or if you want to keep it, using hard-coded values will work. I don't care either way, but I do think something needs done about the file as it is messed up as it is. Or I'll fix it when I find free time next year. Either way.

[GaryFrost]

Gary, I leave it up to you. Saunders suggestion sounds sensible as does mine. If you want to get rid of GUIDefaultConstants.au3, use Saunders suggestion and make it go away. Or if you want to keep it, using hard-coded values will work. I don't care either way, but I do think something needs done about the file as it is messed up as it is. Or I'll fix it when I find free time next year. Either way.

If I get some free time I'll take a look at it.

Would be some more script breaking, but oh well...