To use this website fully, you first need to accept the use of cookies. By agreeing to the use of cookies you consent to the use of functional cookies. For more information read this page.

Personal Blog

A few nights ago I tweeted that I had begun work on a new HAGGIS parser. This parser is actually a YASS transpiler that transpiles from SQA HAGGIS to my own YASS before interpreting and running the YASS code. 

The parser will not only check if the code is valid, but it will also explain what is wrong with it. It will also be able to run it.

Whilst this is still experimental or incomplete, I have uploaded ZPE 1.7.2 with the new HAGGIS parser on to my server.

I hope people find this useful!

Posted by J B Balfour in Education
sqa
haggis
parser

Constants have existed in ZPE since 1.2.01 of BlackRabbit Script, and were actually added as one of the first defined features. They've always had one problem since the beginning. They were interpreted, not compiled. With ZPE 1.7.2 some 5 years later, constants are moved to the compiler where they should be. They no longer have a syntax of #x = 10 but now require the define keyword in front of them:

YASS
define Jamie = "Jamie Balfour"
print(Jamie)
print(Jamie & Jamie)

Further improvements will make the LAME evaluator faster than version 1.7.1's LAME evaluator that completely redesigned the way evaluation works.

zpe
1.7.2
constants

Starting every post about ZPE with using something along the lines of "without a doubt, the best version" is something that's pretty tricky, but since each version of ZPE is incrementally better than the previous, it makes sense. However, as great as the latest fixes and additions are, I'm not going to start the post with this line - you be the judge of that.

Anyway, I'm happy to announce ZPE 1.7.1, Kasba Lake, is now available for download.

Kasba Lake brings a huge improvement to the ZenithParser that was a complete rewrite of the basics of the parser to make it faster and more flexible and functional. The new parser offers the ability to include bound characters, return whitespaces and much more. The ZenithParser also compiles CSV, JSON and XML much faster than before which can be useful to people who want a fast parser in the native language of Java. As well as that, the new ZenithParser allows the programmer to define custom whitespace. Overall, the new parser is 10% faster than before, all while being far more memory efficient too.

Kasba Lake also brings by reference variables! This is a useful feature that has existed for a long time but not been fully implemented until now. By reference allows methods to modify an original variable, not a copy.

1.7.1 is also monumental for development by changing the core of the compiler and interpreter. When ZPE started in 2015 it was developed as the Zenith Engine. Since then things have changed and not only has the parser become publicly available, but the Zenith Engine has some exposed methods. Well since that all changed, the Zenith Engine no longer exists as one thing. Instead there is a completely separate compiler and interpreter (or runtime). This is more efficient and the new version runs much faster as a result of this. In 2015 since ZPE was only some 5,000 lines of code, the single design was easy to manage too, but even since late 2017 ZPE has over 30,000 lines of code, making management of the compiler and runtime tough. I had always planned to separate them but never got round to it.

Another huge change is that of the new LAME or Logic And Math Evaluator that replaces the LAMP or Logic And Math Parser which now carries out both the operation of parser and evaluation in one go. This is up to 3x faster in tests I have run than the original LAMP that it replaces but is 100% accurate compared. 

ZPE 1.7.1 also finally includes a web server. The ZPEWebServer is now ready for use and can act in the same way as PHP, performing very quickly. It's currently in the beta stages but all ZPE functions will work in it.

One last thing, ZPE 1.7.1 is about 15KB bigger than ZPE 1.7.0 because it has the original LAMP and the new LAME included. ZPE 1.7.1 can be seen as a hybrid between LAMP and LAME. LAMP will disappear in the near future and is now considered deprecated. You can currently use the LAMP parser if you wish by adding a setting to the properties file called use_lamp and setting it to true (ensure you lowercase both options).

The new version of ZPE is available at my Download Center.

zpe
1.7.1
updates
kasba
lake

It's about time. ZPE has finally has a web server. A few years ago I added a communication server to ZPE (I think it was added in version 1.5.x) that allowed two or more ZPE programs to communicate using XML requests. It was great and it was reasonably fast.

But since then, ZPE has become so fast that I decided to write a server. This server uses ZPE as the main syntax for everything and because it's parser has been improved so much it's fast (maybe not as fast as PHP or C based applications, but it's good overall).

YASS
<!doctype html>
<html>
  <head>
    <title>Test ZPE</title>
  </head>
  <body>
    This is <?zpe print("Jamie") zpe ?> here.
    <?zpe
      for($i = 0; $i < 100; $i++)        
        print("<p>Hello " & $i & "</p>")
      end for
    zpe ?>
  </body>
</html>

ZPE has always been aiming to get to the point of doing this, since I consider myself more a web developer than software developer nowadays, I wanted to get something like this.

ZPE's main advantage is it's library of features, plus the ability to write extremely fast functions into the language  and it's already existing standard library.

To be clear version 1.6.x added the web parser to ZPE (the -w ZAC), but it wasn't fast enough for me until I updated the parser to version 1.3.

zpe
web
parser
server

I'm extremely happy to announce after a lot of thinking and redesigning, ZPE 1.3 is now included in version 1.7.1 of ZPE and later. The new version of the parsing engine offers much faster and more efficient parser than ever before.

The results are in:

ZPE 1.7.1 with the old parser (version 1.2.1):

real 0m0.668s
user 0m1.390s
sys 0m0.152s

Compared with ZPE 1.7.1 with the new parser (version 1.3.0):

real 0m0.595s
user 0m1.270s
sys 0m0.136s

This may only be a 10% increase overall, but in reality this is big news. Minor improvements for the standard library run and compile but for interpreting JSON, CSV and XML files amongst other file types, this is an incredible amount of speed.

As mentioned over and over, the parser is by far the fastest part of the compilation process since the ZenithParser has been the main focus for years within ZPE.

Another major improvement in the ZenithParser 1.3 is it's ability to handle whitespace better and allow the compiler to re-add whitespace later. This has had incredible use within the ZPE web parser.

zpe
1.7.1
zenithparser
1.3

ZPE's implementation of by reference variables was a tricky one since the underlying Java does not give access to such a powerful tool.

Since version 1.7.0 Reindeer Lake, which was officially released yesterday, ZPE has supported by reference variables and will continue to make them more powerful. As these are new, there is currently no documentation on them. I will add some soon. In the meantime, I thought it might be a good idea to use my blog to explain these in more detail.

ZPE/YASS by reference is achieved with a ZPEVariableReference object which points to an actual ZPEVariable. Changes can be made to overwrite these in functions or to overwrite just their value. A change to the value will change the original value. Let's see it with code:

YASS
function main()
 
  $y = 5
  j(&$y)
  print($y)

end function

function j($y)

  $v = $y + 10  
  print($v)

  &$y = 10  
  print(&$y)

end function

Notice the changes between using &$ and just $. If using the $ syntax in an assignment, it will destroy the reference. Also note, the parameter name is still just $y, even though it contains a pointer. To access the parameter $y as though it were a pointer, it is simple enough to just put an & in front of it as shown on line 14.

That's all there is to ZPE by reference variables so far. I will continue to improve them over the next few versions so keep an eye out!

zpe
byref
by
reference
variables
1.7.0
1.7.1

So for a while, I have been contemplating a new computer. I originally considered a new Intel-based computer right up until the day I was going to order it in the form of an Intel Core i7 8086 - a limited edition version of the Core i7 8700K. But something had been annoying me for a while. The Ryzen that was almost 150 pounds cheaper was offering 8 cores as opposed to Intel's six. Better still, the Ryzen 2700 that I was always considering has a TDP of just 65W as opposed to 95W and uses 12nm fabrication technology compared with 14nm. On top of that, the Ryzen 2 range was only released in October of 2018, compared with Intel's that was over a year ago.

Intel's i7 9700K - their 9th Generation Core i7, has moved to have 8 cores at the same price, the catch is though, it drops Hyper Threading, so it only has 8 threads - the first time a Core i7 has not featured this technology. This has been reserved for the high-end Core i9. I was very saddened to see this, but the reasoning behind it is because Intel is still struggling to fabricate the 10nm FINFET transistors needed for the next tick in their tick-tock cycle and the only way to make a difference was to add more physical cores (and as a result drop the logical cores added by Hyper Threading).

All in all, that meant that the Ryzen 2700 seemed more suitable than any Intel available. So my decision was made when the 8086 went back up in price as the sale ended. I did a bit more research into the AMD alternative and I could get better RAM and higher performance RAM and still be about £70 cheaper than the Intel equivalent. 

So I am happy to say, that for the first time since 2007, I have purchased an AMD CPU. And I am proud to have done this because it took a lot of guts for me to do this. I was quite drawn in by the fact I may have owned a limited edition CPU and I was always drawn to Intel over AMD, but today I went ahead and broke out of that brand loyalty thing I have and said I'm going for an AMD!

I give you, the Red Revolution.

The Red Revolution replaces my Zebra X2, and also changes my nomenclature for my PCs. Now, rather than taking the names of animals and the first letter of the motherboard model, I am using the name of the CPU. The CPU, being a Ryzen, inspires red across the design, the GPU, my Radeon 7950 is also red, and despite everything about going for an Nvidia, will be replaced by a Radeon again due to the cheaper price and performance per dollar.

The Red Revolution is my first PC to be designed from the bottom up - that is that I have chosen each part from a design perspective (well performance was the first consideration, but design came next). I've never owned a PC that was made to look this beautiful either. With a red theme, the Revolution is, to date, my most attractive machine. Further to that, the refresh that the Revolution brings will allow me to replace my very old hard disk drives with much faster SSDs for my games. More space was one of the biggest considerations when choosing the chassis for my new machine and I didn't cut any corners when selecting my case. The Corsair 780T which replaces my old Corsair 600T has loads of room inside it (the 600T had plenty of room too, but not quite as much).

Although I originally just purchased a single 8GB strip of DDR4 memory, it is my intention to upgrade it to 16GB in the next week or so. After that it will also be possible to upgrade the system to 32GB if need be.

Only a few components remain from the previous Zebra X2, including my PSU which has been in every computer I have built since 2009 and first was added in the original Platypus now which makes it 10 years old now. My oldest hard disks were bought in 2005 and 2007 and are still running.

Below are some pictures of my finished build:

Posted by J B Balfour in PC Modding
red
revolution
amd
ryzen
computer
cpu
gpu
psu

Over 2018, ZPE has improved more than ever. Here is just a sample of the new language features brought through the year 2018:

  • Performance is better than ever.
  • The syntax is cleaner than ever.
  • Its name is now a recursive acronym and much easier to say.
  • It's more object-oriented than ever before. Object inheritance was added. Objects performance has been improved.
  • TYPO was finally brought to the language.
  • Native methods for objects were brought to the language.
  • Error objects were added.
  • Pre-increment and pre-decrement syntaxes were changes to be in line with other languages such as PHP - this was one of the most requested features back in the early days of ZPE. 
  • A new FOR LOOP, the FOR EACH IN LOOP was added.
  • The circumflex (^) for representing the power value, e.g. 5^2 is now part of the syntax
  • More syntactic sugar was added to the compiler, such as the IF...THEN statements. The fat arrow syntax for lambda functions was added. elseif can now be written as else if as well.
  • Value caching with the cache_value and read_cache allow programs to save information for later.
  • If statements can have values assigned within them. E.g. if(($v = 10) == 10) 
  • Python-style fixed arrays have now been added
  • The interactive interpreter has been improved by miles - it performs better and doesn't stop when it has an error.
  • Further refinement to 'everything is a function' strategy where the whole program runs within a function has been furthered.
  • The internal updater has now been added

What's still left for development in 2019 then? Well, the answer is that there is a ton of stuff still to be done. For a start, I'd like to improve the performance of the LAMP parser considerably. There is definitely scope for improvement there. It will be a drop in replacement for the current LAMP parser too since the LAMP parser implements the ZPELAMP interface.

ZPE will also get the automatic update feature brought to it, so it will inform users when there is an update. The GUI object is also going to be one of the main focuses for the next version of ZPE. As well as that, ZPE will move further to becoming an object-oriented language by furthering the number of object-based methods within the language. 2018 also added a Python transpiler, I will continue to work on that and hopefully finish that.

What happened to ZPE 2.0?

ZPE 2.0, the C++ compiler, interpreter and runtime that was designed to replace ZPE 1.x was going to take too long to develop and I'm quite happy to work on ZPE 1.x for now as my main project. In the future I will possibly continue to work on ZPE 2.0 again.

zpe
2018
january
2019
review
lookback

A long-awaited feature in the ZPE was the request for an updater built-in to the interpreter and parser. So now with ZPE 1.6.8.1 you can, although a minor update, it is actually a big update for it.

This is a long awaited feature and it's very easy to do. ZPE 1.6.8.1 is now also available to download from my website as of today. To run the update, simply type:

zpe --update

By reference-style variables have yet to be fully implemented and are partially implemented in ZPE 1.6.8.x. They've been disabled within the release versions.

With 2019 just around the corner, ZPE 1.7.0 is also just about ready to be started and readied for release. ZPE 1.7.0 is bringing some performance improvements and one or two new syntax features that aim to make ZPE even better. ZPE 1.7.0 will also bring an automatic updater, expanding on what ZPE 1.6.8.1 brought. Unfortunately, ZPE 1.6.9 which I had hoped to bring out before the end of the year, has been scraped due to the lack of time.

zpe
1.6.8.1
1.6.9
1.7.0
1.7
january
2019
december
2018

First off, as a result of this new discovery, I have updated Girder and BalfBar.

I have recently been working on a new client website when I discovered what I'd say was glitch. This affects every website, every thing that I have worked on in the past few years and all my major projects and it's now fixed.

Every website I have ever created has been responsive since about 2012. As a result CSS media queries are a big thing in the design of these sites. However, it only came to me today that the way that these media queries work is not brilliant. Most crucially, this affected Girder and BalfBar on any website, but also affected my own website. Let's take a look at what this is.

The media gap

The two main methods of using media queries is using the min and max queries:

  • @media only screen and (max-width: 768px)
  • @media only screen and (min-width: 769px)

Combine these two queries to have a media query for mobile devices and a media query for desktop devices. All fine there. Except, there's a gap. If you can already see it then great, but if not let me explain.

First off, take a look at this graph. This what our media query would look like: left of the red bar is the mobile section and anything to the right of the red bar would be our desktop portion. But what about the red bar itself? This is where we have the issue, albeit a small issue, a complex issue to deal with at first.

It only struck me this afternoon that there are small gaps in the media queries developed for production that cause issues with this. The media queries do not specify what happens for the infinitely many real numbers that come between 768 and 769 such as 768.1, 768.2 or 768.35.

An important thing to note is that these media query issues only occur if there are two media queries back to back - one min and one max. Another thing to note is that > 768 and >= 769 are not the same here - this bit is key. This causes issues with things where the JavaScript and CSS are trying to achieve something at the same time.

A fix

A small fix I would suggest is adding granularity. For this example, a fix could be achieved with:

  • @media only screen and (max-width: 768px)
  • @media only screen and (min-width: 768.01px)

Another fix is to use just one media query here and stack changes in it. For instance, develop the mobile site then have a single min-width media query for all the changes applied to the desktop site. This is not ideal but it works and there's no need for the granularity with this type of query.

Why is this an issue?

The issue occurs with some browsers (such as Firefox) making some websites 767.200 pixels wide as opposed to a rounded number. There needs to be a better way to fix this issue.

Posted by J B Balfour in Web design
css
media
queries
issues
size
width
height
max
min