From the very early days when increment and decrement methods were embedded into ZPE, ZPE has always looked a bit, let's say, different, comparatively.
I say this because of the fact that pre increment and pre decrement syntax was, not like other languages. As you may know, ZPE is inspired by many languages such as JavaScript and PHP. A lot of influence in design came from PHP in particular, most crucially the way in which variables work.
Without further ado, let's look at how pre increment works in YASS:
$x = 11 print($++x)
This has been the case since it was first introduced in version 1.3.4 in June of 2015. I updated the Zenith Parser to read a double character word differently back last year with the intention of updating this eventually, but today I just thought I might as well. You can see how it's different now:
$x = 11 print(++$x)
Merlin will be happy with this update as he originally commented on this syntax design a few years back.
Back in the early days in ZPE I released tons of new versions almost weekly sometimes but often monthly. I suppose this release cycle was down to the fact that it was under a big development - things have slowed since.
But back then versions had multiple build versions (if we follow the ProductVersion.Major.Minor.Build pattern) Version 1.3.5 was the most obvious example (that's ProductVersion 1, Major version 3, Minor version 5) because it had 1.3.5.32, 1.3.5.60, 1.3.5.68, 1.3.5.90, 1.3.5.190. Why so many versions?
I believe 1.3.5.60 was one of the most significant upgrades to ZPE in it's history. That's because it added Real Math Mode, which is now part of what is called LAMP (Logical And Mathematical Parser) which allowed mathematical expressions such as 5 +5 to be evaluated straight from the interpreter. It was a huge improvement. In my new system, this huge upgrade would likely have sanctioned a new Minor version (so in this case, it would have become 1.3.6.0) but back then my versioning was based on the number of compilations I made.
So why was this?
Well, back then a new Minor version came along when I had asked my testers to fully test the features of the previous version and assure that they work as expected. This way, a version with a Build of 0 was a stable version (or as stable as testing can assure). Nowadays, this is not the case. Versions are released when I feel that enough has changed to sanction the new version. I no longer keep the compiled version at the end of the version as the Build version unless something is fixed (but no new features are added as this would be a new Minor version).
New versions are now mostly released when something that worked before will no longer work in the new version. For example, the ZPE Standard Library is a bunch of ZPE based functionalities and is compiled prior to use. This means if any of the byte-codes are changed in YASS the whole library needs recompiled. This is why this indicates the need for a new version number.
As part of my continuous dedication to ZPE as of recent, I'm now happy to announce ZPE 1.6.3 which brings a major change across the system but also removes some things.
For example, the way that the negation worked in ZPE has totally changed. The previous version of ZPE would negate using the not command which was aliased by the ! command (or it might have been the other way around). ZPE now treats negation as a symbol it must acknowledge now as an actual negation symbol. What I mean by this is that it no longer compiles a function call from this (which is slower too) but simply negates the value. Again, this should have a small impact on performance. The LAMP Parser has been improved too, minor bits of code reuse have now been put in place of chunks of code, so it should be a bit faster too.
Another change is the way in which errors are now handled. An error in ZPE previously was a low level based error and whilst that same core principle still applies, errors can be handled a bit better now and are now an actual ZPE type.
However, the most important change is something no one will actually see (unless I've broken something in the process of building it) and that's the way in which chained functions work. Chained functions (such as a get call on a list) are now compiled completely different, so if you use compiled code, make sure to compile it again using ZPE -c. It's so important that after any update all code is recompiled anyway, this makes sure that all byte codes stay in line with compiled work - I always recompile the standard library for the ZULE archive to ensure it is up to date.
I look forward to bringing new features to ZPE 1.6.4 but I'm going to be bold and say that since adding the index brackets e.g. [0] I feel that ZPE is really on a role to looking like a proper syntax. I have also begun to update the formal specification of ZPE as this is so important. At some point, I also want to finally split the compiler and interpreter into different classes. This was something I have envisioned for a very long time but it's such a big job it's not been possible yet.
This is by far the fastest release of a new version of ZPE since ZPE 1.6.1 was only released some four or so days ago but I'm very happy to announce ZPE 1.6.2. It fixes a ton of stuff and it's a lot better designed under the compiler hood than 1.6.1 was. The VARIABLE_INDEX is now more functional than ever so that there is more stability when using the following:
$v = [44, 55, 66] $x = $v[2]
As well as adding more stability to the compiler, ZPE now will not crash if you access an undefined index, instead it will return !undefined which means it can be much, much easier to check for an undefined index. Also, if an index that currently doesn't exist is assigned a value, e.g. in the above list index 6 does not exist, ZPE will now pad the array until it reaches index 6 with a bunch of nulls.
As well as this, the oldest method in ZPE got a big refurbishment. The is_set, unset and global functions are better designed to handle errors and in general are much better designed. As part of this, the is_set function can also determine if an index is set or not. E.g.
$v = [44, 55, 66] print(is_set($v[6]))
Finally, ZPE's argument parsing system has been improved again. Arguments are now even easier to use than ever before and they are parsed far faster. As well as this, in the main/default ZPE ZAC (that's actually when no ZAC is specified but instead a file is put in it's place) program arguments now simply follow behind the file. For example, when running ZPE:
zpe test.zex "Hello" "World"
Both Hello and World will be recognised as individual arguments automatically, no need to put the args value in front any more.
I've been really focusing entirely on Dash and neglecting the other project I care about and letting ZPE receive no major updates since January. Well that's really because ZPE is pretty good as it is, but it's also because I've been busy with work and with Dash as of recent.
But ZPE 1.6.1 is now available to download from my Download Center. It brings a few major fixes as well as a few new built in functionalities. On top of that, the stdLib has been recompiled, so the ZULE repo only contains the version 1.6.1 version (of course, you can recompile the source code for old versions of ZPE, almost all of which have been made available through the Download Center on my website).
The most crucial bug fix in 1.6.1 is the way in which values are compared. For instance, in version 1.5.x and 1.6.0 there was a glitch with comparison so:
1 + "1" = true
In version 1.6.1:
1 + "1" = false
This is essential for direct comparison. As well as this, assuming $x is undefined, in version 1.5.x and 1.6.0:
$x == "!undefined" = true
But as of version 1.6.1:
$x == "!undefined" = false
One should be careful when testing for undefined values by using the is_set method.
A new name
Finally, after 3 and a bit years of development, ZPE is getting a new name. It's a big change and I've decided to rename it from the Zenith Parsing Engine to:
ZPE Programing Environment
The 13th of July may be my own birthday and I'll never forget to celebrate it, but it's also the birthday of Dash.
The new name of Dash was conceived on my birthday in 2017. That makes Dash officially just over 1 year old!
Whilst the last year has been pretty damn quiet for Dash, July has been great for it as I've spent a lot of time working on improving it. Just today I've finally got round to adding multiple notes, last week I added the Girder Framework to it and just a bit before I changed the front end to use object-oriented meta data.
Another big release by Apple kept completely quiet. Yep, Apple has updated the MacBook Pros with huge performance improvements and yet again just don't mention it to the public.
The new range of MacBook Pro feature the new eighth generation Core processors from Intel, so they should get a performance improvement. Apple also offers larger storage options now.
Anyway, the top end model as configured allows you to have a Core i9 and 4TB of storage in your overly priced laptop! What a world we live in where you can spend that sort of money on a laptop (PS: I own a £2,500 MacBook Pro and I feel it's been worth every penny, but that's as far as I'd go)!
Of course, I can't see myself going for a top model like that since it is around $6,700 so it'll be about that in GBP as well and I just don't see a MacBook Pro being worth that sort of money.
Last month, I announced that Dash was now getting BalfPick. This was the first time I had integrated one of the other components of my Web Independently Styled Project into Dash. It was an important moment for me because of two reasons. Firstly, it meant that Dash would finally be getting the dropdown boxes it needed. And secondly, it was the first step to integrating my personal projects into Dash.
The next step was, I guess, to bite the bullet and make this a thing. Well from today, I'm very excited to announce that Dash has had its first major makeover since becoming Dash last year and is now built with the Girder Framework. No longer is it tied down to a CSS stylesheet that relied on duplication of styles but it now focuses on a much simple Girder-based grid system.
This means that certain pages look far more consistent with each other, certain styles are better developed and in general, it will be easier to develop Dash. This is similar to how it helped me with my personal website when I switched it to Girder. Although Girder is not prominent across my website, there are parts where it is hugely important, and that's what it's all about.
On top of that, there have been new placeholders added and old ones have been renamed. Please take a look at the help files in Dash when you have upgraded to see all the placeholders if you use Dash at the moment. There is also now a cookie acceptance box because Dash now tries to comply with the cookie policy in case your own surrounding website does not and Dash also now uses TinyMCE 4.7 for a far more sleek look than before.
Best of all though, and as a side-effect of Girder coming to Dash, here is the new Dashboard:
This post is written for a particular family member who wanted to know what this means.
By the year 2025, BT aims to abolish the good old POTS or Plain Old Telephone Service, also known as the Public Switched Telephone Network or PSTN.
Wait? What?! Does that mean no more landline calls?!
No. Let me explain how the system works presently. We have a hybrid system where our internet is sent on approximately three-quarters of the bandwidth of the line that we use. We use Copper To The Cabinet* (CTTC), Fibre To The Cabinet (FTTC) or Fibre To The Premises (FTTP) to deliver an internet connection. Broadband as it is called, refers to the fact that three-quarters or more of the cable are given to the internet whilst the remaining quarter is given to the phone line or PSTN.
When broadband first arrived, to cope with the increased internet speed and the ability to use the phone and internet at the same time the phone signal was compressed. This meant it went from taking a full 100% of the bandwidth to just about 0.5% (0kHz to 4kHz). The rest of it went to the internet connection where 87.5% of the line was given to download (138kHz to 1104kHz) and the remaining 10% to upload (25kHz to 138kHz). Finally, to ensure that the analogue PSTN does not receive interference, there is 2% of the bandwidth reserved between it and the upload. Remember, the way that these signals are transmitted is as frequencies in pulses. This also explains why upload tends to be a lot less than download. Below is how this is all separated out:
As you are no doubt aware, removing the copper cabling that is in use at present and replacing it with fibre makes the bandwidth increase so faster connections are available.
The abolishment of the PSTN from the signal would have an increase on speeds because that existing 25kHz would allow the internet to use that instead.
So what would happen to phone lines?
The purpose of this article was to inform someone in my family of what we have recently chosen to do in our own home - abolish the PSTN from it. Yeah that's right, as of this week we've got no PSTN telephones in the house and we now use a PBX powered by Asterisk (that I setup back in November for my own line) and a bunch of SIP phones. Businesses have done this for years, but the flexibility of these phones is what makes them great.
When BT gets rid of the POTS and PSTN, we will all use phones running on VoIP or Voice over IP technology, basically internet phones. But that doesn't mean you need to buy any new phones, BT or whoever is in control of the phone line in your home will need to provide a compatible option to connect these phones to the new VoIP network.
I'm a bit of an expert now on SIP, VoIP and the PSTN so if you've got any questions just fire away!
*officially, Copper To The Cabinet is not a thing, it's just what I've called it here!
This evening I discovered a little bug that affects all sites hosted that use my Girder Framework and whilst it's not an astronomical issue and doesn't affect usability, it's one that makes some websites I've built using my framework less attractive.
Tonight I speak of parallax.
Many of you will know that a few of my websites use a parallax effect in several places. One of the most obvious is with the Jambour Digital website. Today I discovered that iPads and iPhones do not support parallax background images properly. In fact, they don't really support the background-attachment: fixed property at all.
In some ways, this makes sense due to the fact that scroll events on iOS devices are only triggered at the end of the scroll, for instance. Another reason is possibly because of battery life.
But what really gets to me as a designer is Apple's lack of understanding for developers who develop this stuff. Since a fallback would be difficult and would require at least JavaScript, Apple should have some kind of a backup for websites that rely on this.
So please Apple, fix this!
