Cphalcon: Phalcon uses Zephir (unstable and unmaintained) rather than C (stable and finished)

[joeyhub]

I'd recommend taking a small mathematics library, a few hundred lines, variety of types, make some basic test input, get the output, then port that library to zephir, give it the same input and compare the output. Then start inspecting the C zephir produces to find out why. Some of these issues have been laying dormant for years, even though they're reported. Some trivial pieces of code that would work for practically any other language fail in zephir. I've come to the conclusion that at the least it just cannot be used for mathematics.

"Doesn't segfault" or "Couldn't detect any memory leaks" doesn't mean it's all good. All it means is that easy detectability of faults has been minimised. The library is not safe to use as it does things like break precision and also generates statements that do nothing indicating it's very likely there's also issues with statements it generates that actually execute.

Is phalcon really using zephir or are you fixing the C afterwards? If it's all switched to zephir then it can't make any claim to stability without extensive testing. Similarly, zephir is not producing anywhere near the quality of C code or performance gains that it could be (it's treating intermal calls like external calls even).

[joeyhub]

grep -R ' / ' phalcon | grep -vP ':\s+[*]'

grep -R zephir_safe_div_double_long ext

Every single one of these you have to check. It looks like in at least one place you're working around the bug with floatval() to force double_zval or zval_double.

You may also need to search for long_double.

[JABirchall]

Zephir is maintained by @sergeyklay and other core devs. unstable, yes, it's an ongoing project and with only 1 project usage, being phalcon. Without a wide scope of usage for example with other projects of vast difference, bugs and improvements are hard to come by as the project is only really tailored to phalcon.
Zephir compiles to C which can then be compiled with GCC or VC++, as for between the process I don't know, @sergeyklay and @niden can better answer that. Also, Zephir is open source, and im sure they would welcome any and all improvements, bug reports and even PR's. Feel free.

[niden]

@joeyhub If you have not done so already can you open an issue in the zephir repo and offer either some examples or reproducible tests with what you need and/or a PR (better really).

Thanks.

[joeyhub]

If a known serious silent data corruption issue has been open for three years and hasn't been touched then that's not being maintained in my book.

I've raised this on zephir but it's worth checking the framework as well. Saying that at a glance it looks like it's been known, ignored and just worked around as seen with the floatval hack to force double_zval which potentially has a performance implication if GCC can't optimise that out.

At this point the best way I could contribute to zephir is to just give a new language spec as I think the current approach has the wrong philosophy which includes trying to do too much like being too user friendly when it really just needs to make things easy for people who can already write extensions but want to do so much quicker.

[JABirchall]

Zephir is designed so that devs with adequate PHP language experience can easily write extensions without needing to know any C.

[Jeckerson]

@joeyhub Well, there are some work in progress about what are you writing. If you want to contribute, speak with @sergeyklay on Phalcon Discord server. He will give you more details...

[joeyhub]

I'll try the discord server next opportunity. Try to do two things at once you'll end up doing neither very well. Phalcon needs something different to the any PHP user can contribute to reach the best potential.

To make a language compatible with PHP developers a significant amount of my time has been porting PHP to PHP C extensions and for that I can just get the PHP AST and turn it to C. Then just make some annotation on top for optimisations.

Thanks.