_{Jamie Balfour's}Personal blog

There have been plans for a while to include a new native graphics library in ZPE that will leverage OpenGL and, in some cases, lower-level graphics APIs. The plans are currently just plans, but it's now been identified as something I can build into ZPE. 

This will be available to YASS within the year. It will also be available to any other programming languages that use the ZPE Core, including the newly added support for defining formal language syntaxes in ZIDE.

ZPEX remains the fastest and most capable version of ZPE, especially now that ZPE has introduced its new Native UI and Native Plugin features. The latest versions of ZPEX are published daily for the three largest operating systems ZPE supports.

ZIDE or ZPE IDE is a powerful new IDE that I've been developing for quite some time. It's powered by ZPE and takes a lot of what makes the ZPE built-in editor so powerful. ZIDE is designed to support multiple languages and runtimes, whilst being flexible and yet powerful. 

But what's really awesome is how many features ZIDE now has; here's a list of my favourites:

• Git and GitHub integration
• ZPE Online
• AI Assist and AI Build
• Full error detection
• Debugging tools including breakpoints and stepping through code
• A built-in terminal
• Proper syntax highlighting for both ZPE/YASS and Zpeedy
• Python support - code highlighting, error detection and runtime support
• MD support

As I posted on my Bluesky account earlier this afternoon, I'm now using GitHub Actions to automate the deployment of ZPEX, native ZPE plugins and the plugin bridge for ZPE. 

Not only does this mean they're easier to build since I don't need to maintain three machines to compile on, but it also means deployment is smoother and more continuous integration. On top of that, ZPEX, native plugins and bridge updates are all automatically pushed to my website (or, for the bridge, pushed into the next version of ZPE). 

The goal over the next few weeks is to ensure tight integration of the new GUI and the new plugin system with both ZPE and ZPEX. I also intend to build every ZPE plugin this way over the next few days, especially since it's now so easy and automated.

ZPEX has long held the banner for performance and, more recently, has outperformed PHP and Python in the latest performance tests. However, its compatibility layer with ZPE plugins has always plagued it, meaning it wasn't a full package like standard ZPE. 

Well, thanks to some clever ideas and some assistance from AI, I have developed a bridge that lets these plugins be used, but in a slightly different way. Here's how this works:

• Each JAR contains its own plugin
• Each JAR is also compiled as a native plugin (dll, dylib, so) that can be used with ZPEX.

This way they do exactly the same thing, but work with different systems. In addition, import still works the same way; no changes are needed for either. 

In addition, ZPEX now has a UI builder. Yup, you read correctly. A UI builder for ZPE and ZPEX. And it's clever. It works using an underlying C library I've written/am writing, which uses JNI to provide native bindings to AppKit, Win32, and GTK. UIs will, for the first time, look different across operating systems, rendering engines, and layout engines, but this is to be expected and is actually fine by me. Components are fully native this way. too. Here's an example of a program made on macOS using the new UI object.

In the nick of time before release, I've just finished the interfaces in ZPE, and they're ready for release. I'm planning on releasing this as part of ZPE 1.14.9 after all. 

public interface Reportable
  public function print_report()
end interface

public structure risk_register implements Reportable

  private $risks = []
  private $next_id = 1

  public function add(string $title, string $owner, number $probability,
                      number $impact, string $mitigation) : number
    $risk = make_risk(this->$next_id, $title, $owner, $probability, $impact, $mitigation)
    this->$risks = list_add_element(this->$risks, $risk)
    this->$next_id = this->$next_id + 1
    return $risk["id"]
  end function

  public function print_report()
    print("")
    print("RISK REGISTER")
    print(repeat_text("-", 72))
    print("Open risks: " & this->open_count() & " | Total exposure: " & this->exposure())
    $ordered = sort_risks(this->$risks)
    for each($ordered as $risk)
      print("R" & $risk["id"] & " [" & $risk["state"] & "] " & $risk["title"])
      print("    Owner: " & $risk["owner"] & " | P=" & $risk["probability"] & " I=" & $risk["impact"] & " Score=" & risk_score($risk))
      print("    Mitigation: " & $risk["mitigation"])
    end for
  end function

end structure

Also, ZPE has now been tested with an 8,000+ line code program, and it still compiles it in less than 50ms! That's a major milestone right there.

Two of the most desired ZPE features, enums and interfaces, are now compiled within YASS. Both will be compilable from ZPE 1.14.9. Neither will currently be usable; however, due to the need for further testing, they will be left out of HYPR and ZPE's runtime.

In addition, ZPE now finally features a decompiler, the ZPE Program Decompiler (ZPD). It transforms the IAST, whether stored in a file or passed to it, back into a YASS program. As you'd expect, it's fast. The new ZPD will be bundled with ZPE 1.14.10 in October and not before. 

Another thing to mention is that I've finally pushed Zpeedy Script to my GitHub account, and the source code is available for viewing. It's a descriptive language powered by the Zenith Parsing Engine v6, so it's fast. If my ZPD works perfectly, you'll also be able to generate YASS from Zpeedy (not vice versa, however).

As the title says, ZPE is now able to connect to databases out of the box without needing you to install one of the plugins. This is great news, particularly for ZPEX. 

A simple connection string using the new Database object allows you to connect straightaway:

$db = new Database("mysql", "127.0.0.1", 3306, "tester", "root", "password")

ZEQL, pronounced as zequel - like sequel, is very similar to SQL, but it can be used on lists, maps, records and database queries. There are also plans for ZEQL to support conversion to SQL. 

Whilst ZEQL is not finished yet, and really nowhere near finished, it's started to take shape.

Where ZEQL comes in handy is speed; it's considerably faster than using a loop to iterate a list, as it compiles directly to native code. 

$a_words = from $word in $words
  where string_contains($word, "a")
  select $word

In addition to this syntax, it supports chained functions, commonly known as fluent interface method chaining, including where (has existed for a while now), select and order_by.

$a_words = $words.where($word => string_contains($word, "a")).select($word => $word)