Jamie Balfour

Welcome to my personal website.

Find out more about me, my personal projects, reviews, courses and much more here.

Jamie Balfour'sPersonal blog

Jamie Balfour'sPersonal blog

At the beginning of the development of ZPE/YASS, transpilation was one of the key features of ZPE. It worked in the first versions of ZPE, converting what was called Zenlang back then into Java, Python, and PHP. But since then, ZPE has evolved so much that it has become more challenging to continue developing these transpilers. 

Let me put this into context. Assume you have language A and language B. Language A could be a subset of language B in terms of language tokens (in other words, language A has every token that language B has and more). Transpiling B to A is easy. 

But now, let's pretend that language B has added some tokens/syntax that language A does not have. Now transpiling to A from B is not directly possible. 

This is where ZPE/YASS is, to some degree. Although ZPE/YASS is not a subset, and nothing is a subset of it, the languages have all gone down a tree in different ways and have different syntaxes. They do, however, have the same meaning. For example, Java and YASS have loops, if statements, etc. But ZPE/YASS is the only language out of the three above which features a all_true predefined language function. This means I need to develop a little library that goes with any Java code that simulates this function. Then, the same goes with Python and PHP. 

Ultimately, this is why ZPE's transpilers do not work any more. 

ZPE 1.12.2 will be released later today with LAME X2. LAME X2 was conceptualised at the end of 2023 with a completely different thought process to how it ended up.

LAME X2 was initially planned to be lazy in evaluation, putting more strain on the compiler to perform some form of evaluation/optimisation on expressions rather than leaving it to runtime. This wasn't the best way to go about it. I devised a better way after sitting down with pen and paper this morning.

This new way of doing it leaves LAME as a runtime evaluator rather than what LAMP was that proceeded LAME. LAME X2 is now up to 4 times faster for larger sums. Check these figures for evaluating the sum '3 * (5 + 2) / 2 ^ 2' and displaying the result 100,000 times:

LAME: 14.37s user 2.62s system 114% cpu 14.775 total

LAME X2: 10.40s user 2.04s system 120% cpu 10.362 total

Counting on my Watch, I also got much lower figures with X2 compared with the original. 

The new version is experimental and will be bundled with ZPE. It can also be disabled, at least for now, using the property USE_OLD_LAME and setting it to true.

YES! That's what I shouted when I made a breakthrough with LAME that improved its performance (retrospectively named X1) by a whopping 2 to 5 times. The new version of LAME, LAME X2, will come to ZPE throughout the year. The theoretical improvement comes from compiler optimisations that improve LAME performance so much by reducing the number of iterations needed on a mathematical or logical expression.

In LAME X1, mathematical expressions were processed up to four times before the result was generated. With LAME X2, a mathematical expression needs to be processed precisely once. Assume you have k expressions within that expression; version X1 must process all expressions up to four times, leading to a worst-case computational time of O(4k + 1). LAME X1 is fast, but LAME X2 is faster.

With LAME X2, the worst-case scenario with k expressions is O(k + 1). 

Another improvement coming this year is the Zenith Parsing Engine version 1.5. 1.5 will bring some performance improvements, although I am not quite sure how substantial these will be yet. 

We're already getting close to version 1.12 of ZPE so it's time to think about code names. 

After having a long thought about what I could do, I resorted back to my previous code names where my favourites were definitely the ones related to animals. So without further ado, here are ZPE 1.12's code names:

  1. Bagpipe Badger
  2. Celtic Caterpillar
  3. Glen Grouse
  4. Haggis Horse
  5. Kilted Kelpie
  6. Loch Lion
  7. Nessie Newt
  8. Piper Pine Marten
  9. Scottish Seagul
  10. Tartan Turtle

The main goals of ZPE 1.12.x are:

  • A heavy focus on improving the security of the language
  • Stronger typing with TYPO v2.1
  • A higher performance lower memory footprint Zenith Parsing Engine (version 1.5)
  • Rebuilt Python and Java transpilers
  • A new plugin system (backwards compatible with existing plugins)
  • Further opening ZPE with ZPEKit.

The very first Linux build for ZPE was built this evening, offering massive performance boosts. The build was built on Ubuntu Linux which my home server runs on.

The new build is now available based on ZPE 1.11.11. It is also the basis of the online ZPE tester, making it speedier than before.

So many new improvements due to switching IDE. After 12 years of using Eclipse, I have finally moved to IntelliJ again. This has meant new things for ZPE, for example, little artefacts such as if statements I hadn't noticed were redundant due to code changes surrounding them were wasting resources. IntelliJ notices these and suggests how to improve the code. I have implemented a lot of changes due to this.

Also thanks to IntelliJ I have now started to host ZPE on a private GitHub repository. This has meant change tracking is even easier than it was before. It also means I don't rely on Dropbox Rewind anymore. Further to this, ZPE now has proper build numbers that automatically update each time I build ZPE. I really like this because it goes back to the way ZPE was back in the olden days with version 1.3 up to 1.5.

ZPE has had some major new features that don't just relate to performance too including the new unbound variable declaration, the new empty expression and the new compiler directives feature. Further to this, to make the development of other subset editors of ZPE (such as that found in the SQARL editor I have recently made) easier and faster, the new CodeEditorView component makes it easier to embed line numbering and syntax highlighting in any program. For those who haven't seen my SQARL editor, it simply parses SQARL into YASS which is passed to ZPE for parsing, compilation and passed through the runtime.

After learning a bit about how Ant works and how great the IntelliJ IDE is, I have finally got automatic build numbers being generated. Prior to this, I would estimate the build versions and as of recently, I have ignored build versions entirely. This changes now with a new Ant script being added to ZPE that will automatically increment the build version every time I compile it. This means every time I test the program (since it is built then too) it will increase by one. Build numbers are useful as it's often the case that users of early builds who try out the early access nightly version will be unable to update to a newer build in the same version because the updater cannot decern the version differences deterministically. This will change now! 

Apart from the minor performance improvements featured in ZPE 1.11.8, codenamed Phi, the next release brings about a long-requested feature. That feature is unbound variable assignment.

ZPE generally enforces variable declaration with a bound $ symbol or the let or var keywords. Languages like Python allow variables to be declared simply with their name. From the point of view of the compiler, I thought that due to my recent work on variables, mainly related to the use of unbound variables in assignment, I thought this would be easy. It was. It only took me five minutes and two lines to change ZPE to include this feature.

So now you can do this:

x = 10

Oh, what does that look like? Python maybe?! Maybe that's why I didn't actually want this in YASS.

ZPE Online is the cloud service for ZPE that runs via my own website. Users rarely have to interact with it from my website and I intend to keep it that way. ZPE Online already allows users to save their code online - one of the most significant breakthroughs with ZPE since its inception. But cloud variables, which will be known as ZPE Online Variables on release, are only a short while away. In fact, they are partially implemented in ZPE as of now.

This is how they work:

  • A user creates a variable online (only the original creator can then change the value)
  • A user subscribes to the variable by selecting it from online (they are then periodically checked against the online version to check for changes)
  • A user then uses the variables, which for quick access, are read from their local machine rather than online. If a user runs a program which contains a reference to an online variable that they do not have, they will be asked if they wish to download the variable. 

ZPE will also contain a new security feature which will ensure that the user does not download a variable that could exploit their system. Further to this, cloud variables will only be able to store ZPE primitive types excluding records and objects.

ZPE 1.11.7 also intends to improve the performance of ZPE a bit further as well.

This is all planned for July's release.

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. 

Powered by DASH 2.0