Golf 501 released

• Added Golf git repo to Debian Salsa.
• Fixed lintian issues with postinstall script.
• Added "--man" option to gg utility to display all available man pages, along with the documentation sections they belong to. This makes it easy to find all man topics on Golf.
• Fixed issue with updating man pages during install on OpenSUSE.
• Fixed issue with removal of man pages when uninstalling Golf.
• Added mandb to Arch Linux as a dependency, since it isn't always present, to make sure man pages are installed correctly.

Cookies in Golf applications, plus HAProxy!

Cookies are used in web development to remember the state of your application on a client device. This way, your end-user on this client device doesn't have to provide the same (presumably fairly constant) information all the time. A "client device" can be just a plain web browser, or it can be anything else, such as any internet connected device.

In practicality, cookies are used to remember user name, session state, preferences and any other information that a web application wishes to keep on a client device.

So cookies are quite important for any web application or service. In this example, we'll set a single cookie (name of the user), and then we will retrieve it later. Very simple, but it's the foundation of what you'd need to do in pretty much any application.

First, in a separate directory, create an application "yum" (as in cookies are delicious):

gg -k yum

Copied!

Next, create this source code file "biscuit.golf" (for everyone outside the US who feels it should have been "biscuit" instead of "cookie"):

 begin-handler /biscuit
     get-param action

     if-true action equal "enter-cookie"
         // Display a form to get cookie value
         @<h2>Enter your name</h2>
         @<form action="<<p-path "/biscuit">>" method="POST">
         @    <input type="hidden" name="action" value="save-cookie">
         @    <label for="cookie-value">Your name:</label><br/>
         @    <input type="text" name="cookie-value" value=""><br/>
         @    <br/>
         @    <input type="submit" value="Submit">
         @</form>

     else-if action equal "save-cookie"
         // Submittal of form: save the cookie through response to the browser
         get-param cookie_value
         get-time to cookie_expiration year 1 timezone "GMT"
         set-cookie "customer-name" = cookie_value  expires cookie_expiration  path "/"
         @Cookie sent to browser!
         @<hr/>

     else-if action equal "query-cookie"
         // Web request that delivers cookie value back here (to server); display it.
         get-cookie name="customer-name"
         @Customer name is <<p-web name>>
         @<hr/>

     else-if
         @Unrecognized action<hr/>
     end-if
 end-handler

Copied!

The code is pretty easy:

Golf 488 released

Minor maintenance version:

• Reworked watch file per debian guidelines. 
• Changed debhelper version for debian, as well as changelog to match Golf versioning.
• Closing Debian bug 1102267.
• Updated debian copyrights.
• Added upstream/metadata to debian folder.
• man pages on Debian to be installed via dh_installman
• Cleaned up Depends/Build-Depends for Debian.
• Added Vcs-git for debian control file.

Golf 465 released

 This is a maintenance release:

• Additional safety features when linking (bindnow, relro).
• Fixed build issue with busy files in rare cases.
• Removed LICENSE files from packaging per Debian guidelines since debian/copyright already has this information.
• Move text files to /usr/share/doc per Debian guidelines.
• Cleaned up debian control, copyright, rules and changelog files per Debian guidelines.
• Added watch file per Debian guidelines.

Golf 452 released

This is a minor release. 

• Debian packaging changes needed for inclusion to Debian.
• Minor documentation improvements.
• RPM spec file changes needed to automatically build debuginfo package.

Example of auto status checking with Golf

When talking about safety in programming, it is memory safety that usually takes the spotlight. However, here we'll touch on another common safety issue that typically causes application logic errors, meaning your program won't function correctly. It's about checking the status of any kind of statement that provides it. Not checking the status could mean that the result of a statement isn't correct, yet your program is proceeding as if it were. Of course, this is bound to cause problems, and this is true for any programming language.

Golf now has a built-in mechanism to help prevent issues like this. The approach taken (at this time at least) is not to force the developer to check status for every statement. Rather if status isn't checked, your program will stop in an orderly fashion and tell you exactly in which source file and which line number you didn't check the status that may cause an issue. It's a default fine line between code bloat and safety. Not every status needs to be checked. And this approach helps pinpoint the most pressing spots in your code where failure is the most likely to happen.

Another future enhancement is in the queue, which would allow (as an option) to force status checking on all statements.

Put the following code in file "file-name.golf" in a separate directory:

 %% /file-name public
     silent-header // don't output HTTP header
     get-param fname // get file name we'll read
     change-dir run-dir // change to directory we ran this program from
     read-file fname to file_content // read file
     // Transform file contents
     match-regex "File: ([0-9]+).imp" in file_content replace-with "\\1" result res cache
     // Print out the result
     p-out res
 %%

Copied!

This will take file name ("fname") as an input parameter, read that file, and transform any text in it that starts with "File: " followed by a file name that's made up of digits (without an extension), and outputs those file names. So a bit contrived example, and arguably the point here has nothing to do with matching regex patterns. But it's an example from a real-world application, so I plugged it in just the same.

So, let's say the input file is "myfile" with contents:

Golf 423 released

• New "run-dir" clause added to change-dir statement. It changes current working directory to the directory when command-line program ran from. This is useful for command-line programs. For service applications (i.e. running as servers), this clause has the same effect as the existing "home" clause.
• Added source file name and line number to the error message that is emitted when status was not checked for a statement *and* statement failed. This clearly indicates where the issue is.

Golf 419 released

 This release is mostly maintenance and a few bug fixes:

• Fixed a number of typos and misspellings in the documentation.
• Added Debian apt install, using OBS (Open Build Service) from OpenSUSE.
• Fixed bugs with Fedora rpm spec file: debug directory explicitly created, and removed unneeded sudo for SELinux setup.
• 'make clean' removes all artifacts now, including a few that have been missed before.

Overall, the biggest improvement is the addition of Debian build, which includes modernizing the debhelper version used, as well a clean lintian.

New status-safety feature

 Here's a link that describes in a bit more detail the new "status-safety" feature of Golf:

https://dev.to/golf-lang/major-new-golf-version-is-out-that-adds-status-safety-2409

This feature is available now with Golf 397. 

Golf 397 released

This is a major Golf release. The most notable features added are a new safety layer aimed at preventing logical errors in code, as well as directory support. The full list is here:

• Added a number of statements for directory support (change-dir, delete-dir, new-dir)
  
  
• Added change-mode, a statement that changes permissions mode for files and directories
  
  
• Added back support for Arch/Manjaro builds (after building overhaul)
  
  
• Added advanced application safety checks: it enforces status checking for statements that may cause serious application logic errors. This is done by checking for negative status outcome at run-time, but only if your code does not check for status, and by stopping the application if it happens. This provides for much safer application run-time because it prevents further execution of the program if such outcome happens, and it also forces the developer to add necessary status checks when needed. This feature is automatic and has an extremely low impact on performance.
  
  
• Added octal and hexadecimal number support
  
  
• delete-cookie now returns GG_OKAY or GG_ERR_EXISTS for more streamlined error checking
  
  
• Files are now created with default mask of 600 and directories with 700 for added security
  
  
• You can now use standard Linux constants, as defined in C "errno.h" include file to compare the error code obtained with get-req. For instance, you can use constants like EACCES or EEXIST. To see what's the meaning of errno number or name, use standard Linux utility "errno".
  
  
• Added ability to get current working directory, by using "directory" clause in get-req
  
  
• Added "end-of-file" clause in read-file statement, which makes it easier to see if a short read is due to end of file.
  
  
• Fixed error in documentation: "count" clause was missing in split-string. Various documentation improvements.
  
  
• Added ability to get permission mode for a file or directory (such as 0750) in stat-file statement via "mode" clause, which is reworked to be able to produce multiple queries about a file at once

New upcoming safety features

While Golf is already a memory-safe language, the work is in progress to add an additional safety layer.

This safety will internally check the status of all statements when you don't check it yourself, and your program will stop if such a statement returned a failure. This may protect your application from many forms of application logic errors.

The safety check will happen at run time, and will only kick in if there's an actual issue. Thus, the impact on your applications should be very small or non-existent, and would not require any source code changes.

The run-time cost of these checks should be close to zero, because Golf statements which encompass vast majority of run-time logic, are both written in C and produce native executables from generated C code (for performance), and are well-tested against memory and other failures (for safety). For that reason, just like with memory-safety, these checks will operate only on statements output (i.e. the result), which is a tiny bit of run time cost.

This improvement should be available in the near future, perhaps even in the next major release.  

How to start, stop or restart Golf application server

To start an application server for your Golf Application, use mgrg:

mgrg <app name>

This will start your server in "dynamic" mode, meaning the number of processes will vary to accommodate the incoming request load.

You can control your server's resource utilization in dynamic mode by specifying the minimum and maximum number of server processes allowed:

mgrg --min-worker=10 --max-worker=100 <app name>

How to build OpenSUSE zypper package for Golf

First, install the RPM tools:

sudo zypper --non-interactive in --replacefiles --force-resolution rpmlint sshpass rpm-build rpmdevtools wget

Then get the spec file:

wget 'https://github.com/golf-lang/golf/blob/main/golf.spec?raw=true' -O golf.spec

Create RPM build tree:

rpmdev-setuptree

Fetch the Golf source code:

rpmdev-spectool -g -R golf.spec

Install dependencies (zypper doesn't have the tool for this like apt or dnf, so we just parse golf.spec, which is the next best thing):

sudo zypper -n install --replacefiles --force-resolution $(rpmspec --parse golf.spec | grep BuildRequires|sed 's/^.*:\(.*\)$/\1/g')

Build the package:

rpmbuild -ba golf.spec 

In the home directory, this will produce file ~/rpmbuild/RPMS/x86_64/golf-<version>-1.x86_64.rpm, where <version> is the Golf's current version, and you can now copy that file to another system with the same Linux installed, and install Golf with (ignore the fact that we didn't sign the package):

sudo zypper install ./golf-<version>-1.x86_64.rpm  

Fragmentation of Linux and impact on packaging

Linux fragmentation (meaning many distros out there), while positive in some ways (spurring innovation, customization and freedom of choice), makes it more difficult to properly address diverging packaging methods between them. There are services online that make it possible to manage packaging for Linux, and some are quite easy, while some are (incredibly) difficult to use.

What's in packaging? For one, the list of third party packages that your package depends on.