A few months ago I had an idea that would improve start-up times for ZPE severalfold. I tried to implement it once before and it failed, resulting in me reverting back to a backup and leaving it alone for a while. Well, I have at last implemented this feature.
This feature makes the performance of ZPE better, the start-up times lower, the memory footprint lower and the CPU usage lower. Development is a little more complicated due to the use of reflection rather than using the object-based code that was used before but I know what I am doing with this. ZPE now has reached the 50,000 lines of code mark, even after the latest purge I carried out that took out over 20,000 lines of code.
The June release of ZPE will be available at the end of next week, with many minor improvements and additions. Today really does mark a monumental achievement.
After two release dates were cancelled, I'm finally able to release ZPE 1.11.4, aka OmegaZ, which will feature all of the previously discussed features such as union types and inline iteration etc. but will also include a major update to the record data type.
Previously, records looked like this:
record structure person { string forename = "" }
Now, with ZPE 1.11.4, they've been changed and the structure keyword is now optional. Speaking of syntactic sugar, there is now an optional is keyword:
record person { string forename = "" } record person is { string forename = "" }
As well as this, record instances use the new keyword.
$x = new person()
And fields of the record are accessed using dot notation:
$x.forename = "John" print($x.forename)
Finally, union types are accepted in ZPE 1.11.4. The March release known as OmegaZ will now include union return types:
function doubleNum(integer $x) : integer | real return $x * 2 end function print(doubleNum(2))
It will also soon support union parameter and variable declarations which are expected in OmegaY also. This further expansion of ZPE's TYPO nudges TYPO to version 2.1. All of this new stuff has been added with almost no performance penalty at all.
Since TYPO was introduced and then upgraded to TYPO v2, typing has become a big thing for YASS. The standard library uses types on all built-in functions and all of my own programs are moving to be typed. One of the new features that is coming to ZPE in the near future is forcing typing and disallowing the execution of programs that don't use strong typing. But before that, ZPE is looking to bring union types.
Union types are crucially important for return types on functions which may need to return two separate data types. Rather than using the very abstract mixed type, these functions would use the union type. Assume the following function which returns an integer (the index of the found item) or a Boolean false if the item is not found. Using types with this function currently means specifying a mixed type to allow both integer or Boolean return types:
function linearSearch(string searchTerm, list items) : mixed
This same program could be written with union types as shown below:
function linearSearch(string searchTerm, list items) : integer | boolean
This is a much less abstract and more concrete solution to the problem, forcing the return type to be one or the other. This is the first step in union types, as union types will also come to variable declaration, but this isn't planned to come any time soon.
One of the features that I most wanted to bring to ZPE this year was inline iteration. This has been one of the top features on my board of features for ZPE.
Inline incrementation will be the headline feature of the next version of ZPE and will be available from the OmegaY version of ZPE (version 1.11.2+) and it brings an easy way to create ZPELists with very minimal effort. Not only that, it's actually very fast, taking advantage of ZPE's performance in the for...to loops that I spent tireless hours working on.
It's pretty lovely too:
print(from 0 to 1000 : function($x) { return $x * 2 })
I'm also seeking to improve file transfer performance as well as bring in remote SFTP-like features into the language too.
One of the most exciting features coming to ZPE is cloud variables. This will allow booleans, strings, integers, reals and much more to be stored and retrieved from a ZPE Online account. This will, however, only work while the user is logged into the cloud.
This is intended as the headline feature of ZPE 1.11.1.
There is a possibility that serialisation of objects will come later too.
The new global keyword that has come to ZPE is one that totally changes the way in which nested functions can be used. It's actually awesome in the way it works too as it doesn't break existing code (recompilation is required) as it still works with the same syntax as the function call from before.
Performance-wise, it's much better. Feature-wise, this means that you can nest a function declaration inside an if statement and declare it as global in the if statement. This is awesome and it was by accident that I discovered this was already partially implemented in previous versions.
ZPE 1.10.12 will be available on the 12th or 13th of December.
The headline feature of ZPE 1.10.10, known as Lusty Lion, will be MQTT support. As an MQTT user myself, having MQTT support in ZPE will be a welcome addition. ZPE 1.10.10 will also reintroduce the MySQL features to ZPE.
ZPE 1.10.10 will also introduce minor performance improvements and will be the second version that will be available in native images as well as a JAR.
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.
