TheDcoder

And also not my call unfortunately I'll try to make it as modular as possible so that every executable is unique, perhaps don't include networking code at all for programs which don't need it. Other than that, we all just hope to god (or dog, your choice) that those AV companies don't add generic signature checking to prejudice to the scanning process.

Well, that's good to know. Only if AutoIt executables weren't detected as viruses all the time. I updated one of my programs 2 weeks ago but due to all the false positives, the update process at chocolatey (it's a software repository) is still not complete. Yeah, in my opinion AutoIt isn't the best tool for product testing, instead one should rely on more integrated methods to test, and nothing tops a manual test by a human before a major release AutoIt is good for quick and easy automation, which is exactly what it's made for.

@Earthshine Can you share the reason? Also, do you mean "im out" as in "im out" of this thread or as in "im out" of this forum?

@Jos While you are right, I'd argue it's more about convenience and efficiency. There are also legit uses for MT, otherwise we'd all be using single core processors instead of the latest 32-core Intel Radon or whatever it is Multi-threading is not an essential feature in high-level programming, but it sure is a powerful feature. @JockoDundee Interesting take, but I don't think Windows has a true fork due to all of the security and handles stuff... P.S I didn't realize there was another page full of replies when I made my previous post.

@JockoDundee There are no such blasphemous things in Windows world, only CreateProcess()

@CoffeeJoe No problem, the discussion is always open in my threads. Thanks for the input @argumentum Cool, I was thinking about making a multi-tasking UDF myself back in the day, even started writing it I think. I have a couple of unreleased bits of AutoIt, and I guess they will never see the light of the day as I was much less experienced when writing them. I sometimes cringe at the stuff I used to write... still good to have something to look back to.

Mildly curious, what OS are you using as your daily driver currently? That's sounds hella sus to me

The WHAT I'd recommend staying away from that version for various reasons At the end of the day, if one is determined enough, they can de-compile your script. No amount of obfuscation is going to stop that, there is only so much you can do before even the computer can't de-obfuscate your script The only way to protect secrets in your code is to remove them before compiling.

@CarlD _PathSplit

While there exists drivers for the Ext-family partitions and others, they might not be very stable. Many years ago I had the same requirement of accessing files inside partitions not supported by Windows. What I did was use VirtualBox to install a light-weight Linux distro and gave it raw access to the disk! It worked perfectly and I was able to transfer files via shared folders Refer to the manual to know how to create disk images which point towards your physical disc for raw access. Use it in Read-only mode if you are concerned about data-corruption.

I apologize for the lack of updates, life threw a bunch of stuff at me again so I couldn't focus on the project very much, however I think I can now resume my focus as I have mostly dealt with the other stuff Behind the scenes I have been working on two helper libraries (UDFs in AutoIt-speak): alloc - This is a wrapper around dynamic memory allocation functions (like malloc), its primary purpose is to keep record of all allocated memory for a certain context. cease - This is a wrapper around setjmp and longjmp, it is similar to the raise_error functions we had in the old parser. Both of these libraries assist in error recovery, alloc makes it easier to clean up all the memory and cease will make it easier to return to a point in the program where we can safely clean up everything and resume routine operation. With these two now in place, I can resume work on the parser! Here is the current code I have if anyone is interested: Source: https://forum.dtw.tools/d/28-easycodeit-update-flex-bison-parser/10

No problem. Since my last post, I have tried out NPM once again and I see how it can be beneficial, one key component that I realized is that you can skip committing the "node modules" directory to the source control, many projects however do this and the result is huge repo sizes with just bloat. The approach of just committing the package-lock.json (or whatever it is called) and calling npm to download all the deps after a fresh clone is far better IMO Make sure you implement this in au3pm too

Wow, look at those cores, bet that machine would perform great in gaming Imagine how much more efficient it would be if it was written in a truly parallel manner?

Yes, that's part of the overhead, but here is a rough high-level view of the over head: floating point math -> execution of statements -> parsing code The math part goes inside expression evaluation, which is part of executing statements... like the layers of an onion The machine-code produced by gcc would be very simple, a couple of instructions which just increase a counter, in fact I think most of the overhead would come from initialization of the runtime. Try Tiny C compiler, it may produce a more efficient version. Also MinGW-w64 provides a native port of GNU GCC to Windows, it is a lot better and it is what I use personally, none of that WSL bull$hit

@JockoDundee I think you are talking about asynchronous execution, JavaScript uses this model as an alternative to multi-threading. This is how multi-threading used to be implemented in the days of single core processors I think. Anyway, I still haven't looked much into how I would be implementing threads, but the time is coming nearer.

There already is a way to create threads in AutoIt, yes, real actual threads. You literally call the CreateThread function via DllCall (since it's a Win32 function), someone even made a wrapper UDF around it: https://github.com/jesobreira/thread.au3 It works, but crashes are imminent because AutoIt was designed to work in a single thread, so once the thread does something which conflicts with the main thread, the program segfaults and crashes hard. Yeah... I am being careful of that too, I don't want to make ECI yet another OOP language, the beauty of AutoIt is in the simplicity, no complex object hierarchy and convoluted code. I guess there is no way to enforce this but making the standard library not use objects extensively should set an example for those who want to write code with the best practices.

@jchd Sorry, but I don't see the Execute function anywhere in your code, maybe you omitted it before submitting? Somewhat true, and I was expecting a slight deviation when I started this. People like sharing their opinions and discussing, I am not complaining as it provides me with valuable feedback on what people are looking for. About threads, the arguments you present are a bit one-sided, sure multi-threading isn't the magical panacea for programming, but it is just another tool that you can use, it comes with its own drawbacks but it also offers unique benefits. I am not really concerned about the theoretical argument about correctness as this is a high-level scripting language and we can apply restraints when needed, the rest is left up to the programmer's code design. You can take a horse to the water but you can't make it drink @JockoDundee Yikes, that got nasty in the end. However I think it was because of the confrontation, not due to the merit of the facts that were being discussed. Also TIL there were something called "Tables" I'd end up implementing records/objects/structs at some point anyway, so those could be used as a replacement for DllStructs

I don't recall seeing Execute in your code, but I will surely provide some alternative which would make arrays more "manipulable". Interesting, but they are fundamentally incompatible with dynamic typing, so unfortunately you will have to live with whatever non-OOP objects that end up in ECI. No problem! I see, but I don't think AutoIt uses any kind of bytecode, perhaps the interpreter runs purely based on the parser without any intermediate? This would explain why it takes a very large overhead. In my opinion the overhead shouldn't be too big if the instructions are ready in advance, I would expect a slow down of 10x at max, so it shouldn't take hours like in AutoIt. I mean, I don't want to limit my imagination I'd want to be able to atleast run it on SoC type computers, like RPi and mobile phones, and perhaps some advanced micro-processors. Of course, that goes without saying, I'd be implementing all the labour-intensive tasks in C and provide functions from them. As for a compiler, I think we can target LLVM and have it translate the IR into actual machine code instead, it is a very mature platform which supports many targets, so we get those benefits for free I am imagining something like this Parser -> Byte-code (ECI-specific IR) -> LLVM IR -> Whatever LLVM can give you Initially I'd be implementing an interpreter which will work with the AST, and after there is enough momentum we can switch to bytecode, don't want to start too quick and mess up the bytecode stuff before we have a working proof of concept. Once the project is mature enough we can start thinking about LLVM, JIT and all that fancy stuff Sorry about being so dismissive about it, I initially thought you were suggesting a more direct integration. I appreciate your suggestion, I will surely be implementing the useful utility functions you mentioned, we will see to what degree we can adopt them Anyway, how does a library implement a language feature like lambdas? Is it all just a bunch of macros? Since functions would be first-class features, you could use them as a value in any place. Maybe I can make "constructors" possible by implementing sub-functions which inherit the parent function's calling context, effectively adding state to it . No inheritance system for now... unless I change my mind for some reason or if people really ask for it. No doubt, but they GPU code you mentioned is an extreme case in my opinion, I don't really see people using ECI to write efficient graphics stuff, I am sure @UEZ and co would happily explore the limits, but not serious stuff really. The multi-threaded system I am imagining would be baked into the language itself, not like an after-thought as it is usually implemented in many language. All of the locking, barriers, synchronization etc. would be handled internally, your MT code would look just like the ST code, but it will block when reading locked variables etc. This shouldn't be an issue for a high-level scripting language like AutoIt or ECI. Thank you! I am absolutely going to need them if I am ever going to lead this project towards fruition I like his take on objects too, also see on my thoughts above about implementing "constructors" via sub-functions and inheritance. Nah, not really, JS isn't a multi-threaded language, but it has the ability to switch the context of execution whenever it needs to, so it creates an illusion. It is a nice way to implement non-linear code but it doesn't really work if you don't have an event-based approach. Promises are just wrappers around the event-based stuff in JS, they are handy but I would never use them outside JS. If I am being pedantic I could say you can do that with OnEvent mode, I use it in one of my programs (ProxAllium). Multi-threading is seldomly used in scripting, but having it available can be a blessing! Imagine myself when I had to implement a complex scheduler in AutoIt, all single threaded 😭 No problem about late replies. It doesn't effect performance directly, but I get your point, you don't want there to be extra effort for only a little less bloat. I am in the same boat (pun unintended), I'd only look into this when it is time, not something I am racing to implement in v1 -- Damn, did this post beat my previous post's record?

Going to chime in with my own version of a translation UDF inspired from the original "Gettext" UDF: I think it is the most up to date one, so you don't have to worry about compatibility with the latest version. It is also the most simple one out there I think.

Absolutely agree with your points. I was planning to axe Execute anyway because the parser is going to be decoupled from the interpreter. We need to keep the loaded dependencies to a minimum.

@seadoggie01 I see the appeal as a JS programmer myself, but objects in JavaScript are very different from object in Java if I am correct. According to my knowledge, Java is a statically typed language so you need to declare your objects and their type before you can use them, and the object inheritance is implemented using a class system. JavaScript on the other hand lets you do whatever you want with objects and inheritance is "prototypial", where an object can inherit properties form a parent object, which is just a normal object like any other, no special types etc., so it is very dynamic and duck typing is king So which kind of objects do you prefer? @Alecsis1 Hi, thanks for posting, your English is a lot better than some people who are native speakers but suck at writing, more than suitable for communication In the context of AutoIt it is agreeable, but personally my primary goal to make another language was so that I can use it anywhere. I switched to Linux a couple of years ago and I have been missing AutoIt ever since, I am still using it for work but all my personal projects have been effectively halted because I can't use it in Linux. There is some truth, but it is a very nice feature which easily out-weighs any disadvantages. So it is better to add them at the beginning instead of doing it after you already have a single-threaded codebase. I am sure many programmers would relate to the urge to start writing from scratch again instead of reworking a large part of some code... don't want to make that mistake with this project The other features are noteworthy, thanks for posting them. @jpm @JockoDundee That kind of syntax is the last thing I want to see in AutoIt!

Sorry, I am 2 years late to the party, but I stumbled across this thread while searching for something, I can perhaps take a look at those YACC and FLEX bugs as I am a certified professional now because I read the book about them. @Jos Are these bugs still relevant? If so, I can offer my assistance if that is okay, please advice.

I think this is a new record, another update just before a week passes! 🥳 I am here to present the first prototype of the new bison parser: // parser.y /* * This file is part of EasyCodeIt. * * Copyright (C) 2021 TheDcoder <[email protected]> * * EasyCodeIt is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see <https://www.gnu.org/licenses/>. */ %code top { #define _GNU_SOURCE /* Required to enable (v)asprintf */ #include <stdio.h> #include <string.h> } %union { char *str; } %token UNKNOWN %token WS %token COMMENT DIRECTIVE %token <str> NUMBER STRING BOOL %token WORD %token MACRO VARIABLE %token OPERATOR BRACKET DOT COMMA /* Operators */ %precedence '?' %precedence ':' %left AND "And" OR "Or" %left LT '<' GT '>' LTE "<=" GTE ">=" EQU '=' NEQ "<>" SEQU "==" %left '&' %left '+' '-' %left '*' '/' %left '^' %left NOT "Not" %precedence INVERSION %precedence GROUPING %type <str> expression %{ int yylex(); void yyerror(const char *s); %} %% exp-list: /* nothing */ | expression {puts($1);} expression: NUMBER {$$ = strdup($1);} | expression '?' expression ':' expression {asprintf(&$$, " (%s ? %s : %s) ", $1, $3, $5);} | expression "And" expression {asprintf(&$$, " (%s And %s) ", $1, $3);} | expression "Or" expression {asprintf(&$$, " (%s Or %s) ", $1, $3);} | expression '<' expression {asprintf(&$$, " (%s < %s) ", $1, $3);} | expression '>' expression {asprintf(&$$, " (%s > %s) ", $1, $3);} | expression '=' expression {asprintf(&$$, " (%s = %s) ", $1, $3);} | expression "<=" expression {asprintf(&$$, " (%s <= %s) ", $1, $3);} | expression ">=" expression {asprintf(&$$, " (%s >= %s) ", $1, $3);} | expression "<>" expression {asprintf(&$$, " (%s <> %s) ", $1, $3);} | expression "==" expression {asprintf(&$$, " (%s == %s) ", $1, $3);} | expression '&' expression {asprintf(&$$, " (%s & %s) ", $1, $3);} | expression '+' expression {asprintf(&$$, " (%s + %s) ", $1, $3);} | expression '-' expression {asprintf(&$$, " (%s - %s) ", $1, $3);} | expression '*' expression {asprintf(&$$, " (%s * %s) ", $1, $3);} | expression '/' expression {asprintf(&$$, " (%s / %s) ", $1, $3);} | expression '^' expression {asprintf(&$$, " (%s ^ %s) ", $1, $3);} | "Not" expression {asprintf(&$$, " (Not %s) ", $2);} | '-' expression %prec INVERSION {asprintf(&$$, " (-%s) ", $2);} | '(' expression ')' %prec GROUPING {asprintf(&$$, " (%s) ", $2);} %% void start_parser() { yyparse(); } void yyerror(char const *s) { fputs(s, stderr); fputs("\n", stderr); } This version can only handle numeric expressions, and the output is just a string with an excessive amount of brackets to show the correct order of evaluation. It ain't pretty but it does the job Here are a few sample inputs I tried: > echo '1 + 2' | ./eci /dev/fd/0 (1 + 2) > echo '-((1 + 2) / 3) * 4' | ./eci /dev/fd/0 ( (- ( ( ( (1 + 2) ) / 3) ) ) * 4) > echo '42 ? 123 ? 86 : -((1 + 2) / 3) * 4 : 007' | ./eci /dev/fd/0 (42 ? (123 ? 86 : ( (- ( ( ( (1 + 2) ) / 3) ) ) * 4) ) : 007) (the output is the line of text below the > shell prompt) Even though this is very primitive, it has served as proof that I can use bison to write a proper parser, now I can move onto the more intricate details of parsing such as evaluating values and constructing a syntax tree to represent the code. I will keep you guys updated on the progress, hope the next update comes as soon as this one 🤞 Source: https://forum.dtw.tools/d/28-easycodeit-update-flex-bison-parser/5 -- Also, If anyone has not noticed the new thread I created, please check it out: I am gathering community consensus on which features are more popular so that they can be prioritized accordingly.

@Earthshine Good to know that you'd use EasyCodeIt if those features were implemented. Yes, but I was not referring to AutoIt itself in my message, I was talking about ECI. As you can see from the amount of suggested features in this thread, some of those would take a couple of good megabytes No reason to have any of that around if your code isn't using those bits. Also this would make the job of AVs easier as they can actually check if the code needs networking or crypto to determine if it is a virus, win-win for everyone. We have discussed namespaces already, I plan to introduce them as they could be used to maintain backward compatible version of functions etc. while also providing improved versions of the same functions. Perhaps it could also be useful to get rid of very long prefixes to variable and function names in UDFs. You have bought up a good point, I am not sure if I will implement multi-dimensional arrays, instead I am thinking about implementing first-class support for sub-arrays, meaning you can assign an array like a normal value to any other variable, including arrays. C has the same implementation, you can't have multi-dimensional arrays but you can have arrays inside arrays. This would not be needed if arrays are implemented in the method mentioned above. I will also be introducing array literals, this should give array objects first class support as opposed to the sort of exotic objects they are now in AU3. Should be easy to implement, named arguments aren't bad either. Again, array as a first-class object means you can have arbitrary amount of recursion or cells (only limited by memory and integer representation size). Struggled with this issue myself, so will definitely implement an atomic swap operation for variables. This was already suggested atleast once before, what's the difference between them and arrays? Perhaps you can link to relevant material (according to what you mean by "lists"?) Another thing which I thought of before, will definitely look into implementing... perhaps the syntax can be For ByRef $x In $aArray so that $x will always reference the same object that is in the array. -- Without quoting jchd's huge post about sorting, I think a good idea will be to implement native in-place sorting with the help of a custom function, similar to how qsort works.

I hate homework and interview coding, there isn't much of a difference between both, they want some arbitrary twisted thing done instead of something practical. If I was good at those I would be doing math or spell bee competitions