One of the significant updates coming to ZPE 1.12.7 is a major change to how ZPE handles library imports. This post is designed to outline this change so I can reference it from the changelog and GitHub commit.
Before this version, ZPE would read in library imports from a yex file in the libraries folder. This hasn't changed. The library files themselves need not be recompiled. However, the way they are imported has changed. In the older version of ZPE, a library was imported as a variable with all the structures and classes being defined within them:
import stdLib
print($stdLib->bubble_sort([2, 7, 1, 6]))
In ZPE 1.12.7, this changes. Now, instead of adding the bubble_sort function to the $stdLib object, the bubble_sort is put into the top level of the runtime (i.e. added to the global function), so instead you would call bubble_sort:
import stdLib
print(bubble_sort([2, 7, 1, 6]))
ZPE 1.12.7 also allows doing this in the old manner by using the new import as syntax:
import stdLib as stdLib
lib = new stdLib()
print(lib->bubble_sort([2, 7, 1, 6]))
This new change will make some difference to the way in which libraries are used and will improve ZPE performance and memory footprints.
I recently started working on the YASS to Python transcompiler. It's worked well over the last few weeks, and I've decided it needs a proper name.
Without further ado, let me introduce ZenPy.
ZPETypes were first introduced to ZPE a few years back when the move to 'everything as a function or object' concept evolved. This paradigm shift made it impossible for ZPE to encounter data types such as BufferedImages as it had previously, restricting such data only to ZPE structures (and, indeed, ZPEObject instances). This tidied up the core of ZPE, improved performance, and caused fewer crashes.
Now, I embark upon perhaps the most exciting yet ambitious project in ZPE's history: shifting away from generic values to ZPETypes for all return values. This is not going to be a quick job either, and it could take several days of development. But it's necessary to make ZPE feel more solid and improve performance even further.
ZPE is close to its 100,000th download as of this year, so it is time for this change to come around. I seek to have it done by the end of the summer.
ZPE plugins are now available to download from my website straight from my Download Center. All plugins are open-source and can be compiled, modified, forked, etc., from my GitHub.
Currently, the only existing plugins are the libZPE-MySQL, libZPE-MQTT, and libZPE-Serial plugins, which were three of my original plugins. libZPE-Windows, libZPE-Mac, and libZPE-Linux are all underway now, too.
As you'll notice, if you are interested in making plugins for ZPE, they must follow the naming convention of libZPE at the start.
The plugin system, known as the ZIP System, is now working. It's replaced the older plugin manager with a more efficient and reliable system. I recreated the ZPE MySQL plugin yesterday and got it working again. Part of my plans for this include removing some of the features in ZPE, including the MQTT features and potentially the GUI features in ZPE, and moving them to a plugin.
However, there is currently a drawback to these: instead of working like libraries, these simply add the built-in library functions to the general function list. That means you do not have to call libmysql->mysql_connect but instead just write mysql_connect. I am not entirely sure this is how I feel that these plugins should be accessed.
However, it now means that creating ZPE plugins is now possible again.
My new transpiler for YASS to Python is coming along very well. After only about 3 hours of development, I have managed to get a program like this:
function doIt($x)
for($i = $x to 100)
print("Running in a function")
end for
end function
doIt(10)
for ($i = 0; $i < 2 * 3; 2)
print("Hello", "world")
end for
$z = 9
if($z > 10 || $z < 20)
print("Yes")
else
print("No")
end if
$x = 10 + 5 / 3
print($x)
To transpile to:
def doIt(x):
for i in range(x, 100):
print ("Running in a function")
doIt(10)
for i in range(0, 2 * 3, 2):
print ("Hello", "world")
z = 9
if z > 10 or z < 20:
print ("Yes")
else:
print("No")
x = 10 + 5 / 3
print (x)
This is the first big announcement related to this new transpiler, which will be available very soon at this rate.
I am working on fixing unbound variables in ZPE that will hopefully solve a long-standing issue with their use when not declared first. This bug fix will hopefully be available in ZPE 1.12.5.
ZIDE or ZPE IDE is a powerful new IDE that I have been planning for a few months. It's built entirely on the editor built into ZPE just now, but it will offer a much more powerful and feature-rich platform for development than ZPE's editor provides. Additionally, ZPE will introduce a new step-by-step interpreter to allow concise communication.
ZIDE will be available on GitHub and will be fully open source.
ZPE has continually improved to the point where LAME X2 has improved what I had always aimed to improve in the evaluator. As a result of this new improvement, I don't foresee any easy way to improve performance on the same level as I have recently. This has meant that over the last few years, performance improvements have always been minor (bar the latest update), and I foresee this being the future.
There are plans for more compiler optimisations, and many of the improvements focus on this and more efficient variable declaration and function calling. If you have any suggestions for improving the performance of ZPE, please let me know.
ZPE and ZPE/YASS are both very mature now. Both are incredibly fast and have a lot of functionality and features built in. BlackRabbit Script was first conceived in 2008 but didn't become a proper language until after a rebuild of it with version 1.x was started in January 2011. This marked the first time the language was actually usable. This was known as Operation Foghorn.
The initial release of BlackRabbit Script was in May of that year. It was baked into Painter Pro and Wonderword as a replacement for the Macro Scripting Interface Language they both featured (it was the basis of BlackRabbit Script anyway). The new BlackRabbit Editor Ultra Edition could interpret it separately from these programs.
Looking back at the whitepapers I produced and shared via my website in 2011 brings a bit of a chuckle: Operation Foghorn's syntax was considerably different from the language developed for ZPE/YASS. Foghorn laid out what BlackRabbit became, and ZPE is built entirely on how BlackRabbit Script works. The language itself was initially known as BlackRabbit Script (BRS) before getting the name Zenlang and finally settling on YASS; a lot of what made Operation Foghorn still stands today.
BRS was slow, though, and compared with ZPE, the interpreter was ten times slower! That's to say that the hard work involved in developing ZPE has paid off.
Speaking of which, the latest version of ZPE can compile 900 lines of code and interpret them in less than half a second. I mean, that's fast!
