The new version of ZPE is out now in beta stages, and it's pretty awesome, to say the least.
ZPE 1.10.7, aka Hasty Hyena, is quite symbolic since it now features symlink features.
The three new functions, which currently remain undocumented, are able to add symbolic links, check if a file is a link, and the best one, replace a part of a link.
The last function here is the most interesting and useful. I came up with the idea since I often need to update links on my Linux-based systems and must delete the whole link and then relink it. This function takes in the original link, figures out the exact path it points to, converts the path to a string and replaces the search term with the new replacement, moves the old link and then writes the new link to the old link path. This is something that will save me time on my server for sure.
It also brings the new run_in function, another extremely useful function that runs a function (or a lambda function) in a certain number of milliseconds, either continuously or just once.
Finally, create_cron_job is another new function coming to ZPE later this month, as well as a new command line that's also coming along. This will allow you to schedule cron jobs that ZPE will handle. The command line is designed to be run through the -x mode and will continue running in the background. ZPE aims to simplify the whole process of creating cron jobs, and will also store the actual commands in JSON files that make it easier to modify them later.
It was never my intention to release a new version of ZPE every year, and given that some releases are considerably bigger than others this would be difficult to sustain. However, 2022 has actually led to just that - ZPE has released once a month, and the version numbers, as a result, tie-up with the release dates.
For the foreseeable future, ZPE will continue to follow this and one new minor version will be released monthly, no matter what. I will devise a scheme for deciding when a new version will be released to the public. This is actually very similar to the way that Ubuntu's naming scheme goes.
Further to this, if changes are made to the YASS syntax from this moment on, YASS will move to a new version based on the month it was updated. At present, YASS sits at version 22 since the last changes were made in 2022, but if changes were made in, say October 2022, YASS would become version 22.10.
This year's codenames are a bit more fun than chosing place names or locations. This year I have chosen several animals, much like how Canonical does with Ubuntu's codenames. As always the list can be added or removed from. Here they are for ZPE 1.10:
- 1.10.1: Amazing Aardvark
- 1.10.2: Commendable Cat
- 1.10.3: Dazzling Dog
- 1.10.4: Exceptional Elephant
- 1.10.5: Fantastic Fox
- 1.10.6: Great Giraffe
- 1.10.7: Hasty Hyena
- 1.10.8: Jolly Jellyfish
- 1.10.9: Lusty Lion
- 1.10.10: Proud Penguin
- 1.10.11: Worthy Whale
- 1.10.12: Zippy Zebra
So what do you think? Are the Amazing Aardvarks and Zippy Zebras going to be good codenames for ZPE?
ZPE 1.10 plans to brings many new features to ZPE, ranging from simple things like performance improvements (plenty have been planned out) and bug fixes, to more complex things. This post will discuss the first of many new features that will come to ZPE over the next year.
Firstly, the Zenith Parsing Engine 1.5. As a result of writing the Zippidydoda syntax highlighter, I have identified a new method to make parsing more efficient within the Zenith Parsing Engine. Within the next few weeks I will launch version 1.5 of my syntax parser which will have further optimisations.
Secondly, speaking of optimisations, I have plans to bring precompiled JSON, CSV and XML to ZPE. What this means is that the code will be precompiled at compile time which will speed up runtime.
Thirdly, static variables will come to ZPE in 2022, bringing many benefits and new features including the singleton pattern. Static variables have been seen as being a requirement for a long while now.
The fourth thing I'm working on is the new ZPE Online includes feature. I am aiming to have this done by the end of the month and ready for ZPE 1.10.1 but I'm not sure if it will be ready.
ZPE 1.9.13 will be the last version to feature the ZPE UI features as ZPE 1.10.1 will remove this from ZPE. This will be moved to the ZPE UI library, a free, opensource library. It will be very easy to reintegrate these features into ZPE again once the library becomes active again.
ZPE 1.9.7 (Galashiels) is one of the most solid updates yet. Many major bug fixes have been introduced, new performance gains and a new typing system (TYPO v2).
TYPO v2 is perhaps the biggest improvement to the whole ZPE Programming Environment in the last few months, and it changes the whole way that it works underneath. Instead of doing type checking at compile time and thus making starting and interpreting programs/scripts slower, it is now done at runtime. The impact here is actually slightly smaller and relies on the underlying implementation of variables to perform this check.
TYPO v2 also removes the STRONG_TYPED property from the properties list and allows side by side strongly typed, statically typed and weakly, dynamically typed variables to be declared side by side in a single program or script.
All ZPE/YASS documentation has been updated to reflect this new change, particularly the page on Assignment and variables.
ZPE 1.9.8 is looking to use more static hidden objects to improve both performance and lower memory usage. This might be another big update.
TYPO has been completely redesigned from the ground up to make it even better. Compared with the first version of TYPO, the new version uses late static type checking which is done during runtime rather than compilation time. This does add a slight performance penalty compared with untyped data, but it is far more stable than attempting it at compile time since so many functions may return multiple data types.
For example:
declare $i as number = 50 declare j as number = 32 $i = "Test"
This would crash when it gets to setting $i from a number to a string. Previously this check was carried out by the compiler but it wasn't effective in comparison, whereas defining it this way ensures 100% efficiency in comparisons and although late typing often has performance penalties, in comparison to the previous iteration of TYPO so much has been improved that these penalties are actually minuscule.
Another major change to TYPO is that is now always enabled and doesn't need to be set in the ZPE Properties file, and can be used in parallel with untyped YASS code for the first time.
The formalised specification of the language has yet to be updated with this new information but will be sorted at some point over the next few days.
With ZPE and YASS featuring more and more unit testing capabilities, I thought it was time for me to look into adding proper testing methods.
ZPE unit testing will broaden and expand the current situation with unit testing to the point where specific unit testing scripts can be produced separately from any code.
Unit testing, known as zUnit, will feature its own language parser, also built upon the Zenith Parsing Engine, of course. It will use a language different from YASS entirely and will also allow multiple tests to be carried out on code very quickly.
Like when ZPE started out, it will likely begin as a very basic tool for testing but will expand to provide more and more features as time goes on.
As a result of the sweeping new changes brought to unit testing so far, ZPE 1.9.6 is now available much earlier than I had originally planned for. Please also note that this version removes the new record structure as this is under redevelopment.
ZPE 1.9.3 brings a really nice feature that I've wanted in YASS for a while. That's Python/JavaScript variable names. It's more like ES6 than it is Python but have a look for yourself:
let x = 10 print(x) //Or a lambda function let x = function() print("Hi") end function x()
This works by adding additional information into the compiler that allows it to distinguish variables from functions within the compiler.
I'm pretty impressed since the only performance penalty from adding this is within the compiler which is almost minimal.
ZPE 1.9.1 was officially released today marking the first of the 2021 versions of ZPE.
ZPE 1.9.1, codenamed Kelso, comes in with a large number of new features and performance improvements and is recommended to all users.
Version 1.9.1 finally fixes undefined comparisons, improves the LAME parser, adds support for empty associative arrays to the JSON parser, fixes a parameters issue, and fixes negative numbers in the binary calculator by cutting them to the appropriate number of bits (this was tricky to implement but I figured a way to do it as I always do).
But, the big feature is the match construct. This is the first new construct in a while as well (it's actually an expression but since ZPE doesn't have expressions in the documentation and it flows like an inline construct I'm calling it a construct). The match construct is now fully in the documentation and it's a pretty powerful construct.
Did I mention that ZPE 1.9.1 is actually smaller than ZPE 1.8.13 too?
One of the new features that's been recently added to PHP 8 which I'm also excited about is that of union types. ZPE has actually had union types for a while, but it was never formalised in the YASS language and therefore never actually enabled. In the next few versions, I will bring union types to ZPE.
There are other plans for ZPE in terms of types actually, since it was suggested that untyped and typed code should be mixable. Thus, in the next few versions, I will bring the ability to mix and match hard typing and soft typing in the code.
ZPE 1.8.11 is now available and is another small update in terms of the number of features but big in what the new features bring.
The first big new feature is support for infinite parameters. This is done within the definition with the double dot notation such as function x($y, $z ..). There is more in the documentation.
Reference functions have been completely redesigned, as have objects. With objects, there is a 2x performance increase whilst with reference functions, there is a much larger performance increase as well as a stability improvement. Reference functions can now be chained to each other much easier and this change requires much less code to do it.
