Amibroker Compiler

Hi Tomasz
About a year ago you had asked us about a compiler option. May I ask if there is any progress on this?

To everybody else, have you ever tried this product?
"AflXCompiler" from .

Is it any good? I did not find much information from other users.

IMHO, .NET as a concept is fundamentally flawed from the very beginning. Java as a concept was flawed and .NET as MS attempt on reinventing Java is flawed too. Don't ask me why. I would have to write a book to list all reasons, but I don't have time for that. Just my subjective opinion. I am not referring to any particular product. The thing is about technology.

Thank you for the answer.

Any comment on the possibility of the Amibroker compiler (developed by you)?

The development is on hold because:

  1. AFL array-based code runs fast inside AmiBroker - no performance benefit for compiling to DLL (in fact it could get performance down)
  2. The only beneficiary is looping code but this discourages learning of array coding (which we don't want)
  3. there does not seem to be enough market for it
  4. a risk of "black box DLLs" flood that is likely to appear once it is available

I don't like idea of black boxes and don't like idea of selling black box "signals" to people.


Hi Tomasz

May I make a suggestion?

How about a smaller scale solution/utility, that takes a function (not an entire project) written in AFL and translates this into C++ plugin code.

All the IFs and LOOPs will be translated to C++. All the AFL function calls (like MACD) will be treated with the gSiteCallFunction (ie translated to gSite.CallFunction("macd", 2, args ); ).

Would this be easier to implement/produce?

point 1: Nothing changes for the arrays, no performance degradation from the translation.

point 2: We speed-up looping. Coder still needs to educate himself and write efficient (array based) code.

point #3: Would more people be interested in this? I certainly prefer this than the full blown compliler. I just want to produce my own faster plugins, not for commercial use.

point #4: It will make easier for the AFL coders to produce plugins. No harm in this.

About point #2: I always try to use arrays, I ask here for help etc. Only as a last resort I go for loops. I had to write plugins in 2-3 cases, and of course they are lighning fast.

For example take a look at this case: Zig-Hi Zap-Lo: Unexpected result
From what I understand, this array based code is the standard solution for years. I spent several days trying to adjust it to my needs (restrict from looking into the future), until I found a possible problem in the original code. Since nobody replied, I spent one day and wrote my own plugin.