The Intellectual WildernessThere is nothing more useless than doing efficiently that which should not be done at all.

2020.09.9 12:51

Erlang: Barnsley’s Fern

Filed under: Computing — Tags: , , , , — zxq9 @ 12:51

A mathematician friend of mine asked me the other day whether we used many techniques from fractal theory in game development. I told her that I didn’t think so, at least not formally. She asked me if I had ever implemented “Barnsley’s Fern” (Wikipedia) and of course I never had. So she asked me to implement it and tell her what I thought.

Her plan seems to have been to get me to recognize that we do use techniques derived from fractal theory all over the place by implementing a famous fractal by hand myself. The plan worked: it was immediately obvious to me that Barnsley’s Fern makes use of a technique that is central to the way random map generators work in game development, but I had never realized this was actually from “fractal theory”, having stumbled on the technique myself because it was a useful shortcut to making game maps that were interesting and felt natural(ish).

Here is the interesting part of the code:

The interesting part about that is the fact that the plotting of points is actually a random function, not a concretely defined rotation of an existing pattern. The constants involved in the fern1-4 functions are found here:

My Barnsley’s Fern implementation is available on gitlab and can be run using either ZX or Vapor if you have ZX on your system. The most recent version as of this post, 0.1.2, uses OpenGL to render the image and seems to work much more reliably across platforms than the previous implementation using a WX graphics context (some versions of WX don’t like the way I drew the points). In Vapor you can select the version with the version drop box if you want to see the WX implementation:

Or you can run it directly from ZX using the command line with:
`zx run barnsley_fern`

Here is what the OpenGL version looks like at 100001 iterations:

The OpenGL interface allows you to rotate and move the image around a bit, though in v0.1.2 the center of rotation is a bit off center. Also, if you have more than a few hundred thousand points it becomes cumbersome to render repeatedly in animation because it is actually re-plotting each frame (I didn’t go to the trouble to plot the points to a buffer or texture and simply rotate that instead).

The previous version looks like this at the same number of iterations:

The coordinate systems are different for the two implementations, hence the difference in the direction of the curve.

Hanging around mathematicians lately has made me realize that there is a tremendous amount of higher math involved in a lot of what we do in programming, but that the mathematicians rarely talk to the computer science people, and computer science people are living on their own little planet with little connection to what actual developers are doing in industry (all of us little people just “trying to make it go”). Further, the semantic map of what words are used to mean what in which context is an absolute mess, so it takes some patience and explanation to understand what the other person is saying half the time if you are talking outside your tribe.

Keep the patience! Explain exhaustively! Listen carefully! It is so much more interesting when you have a chance to confer with people outside your tribe!

2020.08.30 19:58

Filed under: Computing — Tags: , , , , , , — zxq9 @ 19:58

Erlang R23.0 docs have been added to the doc mirror list on the Erlang Stuff page.

2020.08.15 20:35

Building Erlang R23.0 on Debian/Ubuntu

Filed under: Computing,Science & Tech — Tags: , , , , , , , — zxq9 @ 20:35

As an update to my previous notes on building R22.2, my current notes for building Erlang R23.0 and installing ZX using kerl on a fresh system (Kubuntu 18.04 LTS) are below. The same instructions (or very nearly the same) should work for any Debian or Ubuntu version within a few years of 18.04 LTS.

```sudo apt update
sudo apt install \
gcc curl g++ dpkg-dev build-essential automake autoconf \
libncurses5-dev libssl-dev flex xsltproc libwxgtk3.0-dev \
wget vim git
mkdir vcs bin
cd vcs
git clone https://github.com/kerl/kerl.git
cd ..
ln -s ~/vcs/kerl/kerl bin/kerl
kerl update releases
kerl build 23.0 23.0
kerl install 23.0 ~/.erts/23.0
echo '. "\$HOME"/.erts/23.0/activate' >> .bashrc
. ~/.erts/23.0/activate
wget -q https://zxq9.com/projects/zomp/get_zx && bash get_zx```

[NOTE: `~/vcs/` is where I usually put “version control system” managed code and my backup and sync scripts know to never copy or update that one.]

And that’s that. If you’re on a full desktop installation some of the packages in the `apt install [stuff...]` may be redundant, of course (who doesn’t already have wget and git?), but that’s no big deal.

2020.01.29 17:27

Erlang: Minesweeper

Filed under: Computing,Games — Tags: , , , , , — zxq9 @ 17:27

I’ve been sick the last two days and utterly uninspired to do anything productive. I’ve instead procrastinated by writing a “minesweeper” clone in Erlang.

Why? I have no idea. I was just sort of thinking of simple desktop classics to mess around with that are de-facto standard to populate a GUI app launcher like Vapor… and several hours later I had this thing. By that point I figured I was invested enough to swap text for graphics, and poof! There we are.

I still need to add win/loss conditions, a wall-clock timer and some kind of score thingy, but anyway, this was actually a much more fun way to tool around on a sick day than I expected and makes me feel just barely less of a dirtbag than I would have been had I wrapped up in bed all day feeling crappy.

I hate being sick. Ugh.

Update

I went ahead and finished it (except for recording scores — does anyone ever look at that since they can’t be sanely shared and aggregated?) and put it on gitlab just in case someone wants to see what a really hasty/disorganized codebase looks like.

It even has settings! Hahaha! “Settings” really being code for me messing around and seeing if I remembered how wxSlider widgets work (turns out I do and they are boringly easy to use).

If I find myself not feeling in the mood and going to the gym is out of the question, I suppose I could do one of these in 3D next time. Seems like “minesensor” would be a slightly more involved sort of game.

2020.01.22 09:34

Building Erlang R22.2 on Debian/Ubuntu

Filed under: Computing — Tags: , , , , , , , , , — zxq9 @ 09:34

As an update to my previous notes on building R22, my current notes for building Erlang R22.2 and installing ZX using kerl on a fresh system (Kubuntu 18.04.3 LTS) follow:

```sudo apt update
sudo apt install \
gcc curl g++ dpkg-dev build-essential automake autoconf \
libncurses5-dev libssl-dev flex xsltproc libwxgtk3.0-dev \
wget vim git
mkdir vcs bin
cd vcs
git clone https://github.com/kerl/kerl.git
cd ..
ln -s ~/vcs/kerl/kerl bin/kerl
kerl update releases
kerl build 22.2 22.2
kerl install 22.2 ~/.erts/22.2
echo '. "\$HOME"/.erts/22.2/activate' >> .bashrc
. ~/.erts/22.2/activate
wget -q https://zxq9.com/projects/zomp/get_zx && bash get_zx```

[NOTE: `~/vcs/` is where I usually put “version control system” managed code and my backup and sync scripts know to never copy or update that one.]

And that’s that. If you’re on a full desktop installation some of the packages in the `apt install [stuff...]` may be redundant, of course (who doesn’t already have wget and git?), but that’s no big deal.

2020.01.9 00:26

Packaging and Distributing/Deploying Erlang GUI apps with ZX

Filed under: Computing — Tags: , , , , , , — zxq9 @ 00:26

In the last two posts I wrote walkthroughs for how to create new CLI and GUI apps in Erlang from scratch using a tool called ZX. Today I want to show how to package apps and publish them using Zomp (the package distribution system) and get them into the hands of your users with minimal fuss.

To understand how packages are distributed to users (the “why does anything do anything?” part of grokking ZX/Zomp), one must first understand a bit about how Zomp views the world.

Packages in the system are organized by “realms”. A code realm is like a package repository for a Linux distribution. The most important thing about realm/repository configuration is that you know by each package’s signature whether it really came from the it claims as its origin. Just like Linux repositories, anyone can create or host a Zomp realm, and realms can be mirrored.

(As you will see in a future tutorial, though, administration and and mirroring with Zomp is way easier and flexible than traditional Linux repositories. As you will see below, packaging with ZX is just a single command — ZX already knows everything it needs from the zomp.meta file.)

In this example I am going to put the example CLI project, Termifier GUI (a toy example app that converts JSON to Erlang terms) into the default FOSS realm, “otpr”. Because I am the sysop I have packaging and maintenance permissions for every package in the realm, as well as the sole authority to add projects and “accept” a package into the write-only indexes (packagers have “submit” authority, maintainers have “review”, “reject” and “approve” authorities).

[Note: The indexes are write only because dependencies in ZX are statically defined (no invisible updates) and the indexes are the only complete structure that must be mirrored by every mirroring node. Packages are not copied to new mirrors, they are cached the first time they are requested, with mirror nodes connected in a tree instead of a single hub pushing to all mirrors at once. This makes starting a new mirror very light weight, even for large realms, as no packages need to be copied to start (only the realm’s update history, from which the index is constructed), and packages in high demand experience “trickle down” replication, allowing mirrors to be sparse instead of complete. Only the “prime node” for a given realm must have a complete copy of everything in that particular realm. Nodes can mirror an arbitrary number of realms, and a node that is prime for one or more realms may mirror any number of others at the same time, making hosting of private project code mixed with mirrored public FOSS code a very efficient arrangement for organizations and devops.]

In the original Termifier GUI tutorial I simply created it and launched it from the command line using ZX’s `zx rundir [path]` and `zx runlocal` commands. The package was implicitly defined as being in the otpr realm because I never defined any other, but otpr itself was never told about this, so it merely remained a locally created project that could use packages hosted by Zomp as dependencies, but was not actually available through Zomp. Let’s change that:

`ceverett@okonomiyaki:~/vcs\$ zx add package otpr-termifierg`

Done. That’s all there is to it. I’m the sysop, so this command told ZX to send a signed instruction (signed with my sysop key) to the prime node of otpr to create an entry for that package in the realm’s index.

Next we want to package the project. Last time we messed with it it was located at `~/vcs/termifierg/`, so that’s where I’ll point ZX:

```ceverett@okonomiyaki:~/vcs\$ zx package termifierg/
Packaging termifierg/
Writing app file: ebin/termifierg.app
Wrote archive otpr-termifierg-0.1.0.zsp```

Next I need to submit the package:

`ceverett@okonomiyaki:~/vcs\$ zx submit otpr-termifierg-0.1.0.zsp`

The idea behind submission is that normally there are two cases:

1. A realm is a one-man show.
2. A realm has a lot of people involved in it and there is a formal preview/approval, review/acceptance process before publication (remember, the index is write-only!).

In the case where a single person is in charge rushing through the acceptance process only involves three commands (no problem). In the case where more than one person is involved the acceptance of a package should be a staged process where everyone has a chance to see each stage of the acceptance process.

Once a package has been submitted it can be checked by anyone with permissions on that project:

```ceverett@okonomiyaki:~/vcs\$ zx list pending otpr-termifierg
0.1.0
ceverett@okonomiyaki:~/vcs\$ zx review otpr-termifierg-0.1.0
ceverett@okonomiyaki:~/vcs\$ cd otpr-termifierg-0.1.0
ceverett@okonomiyaki:~/vcs/otpr-termifierg-0.1.0\$ ```

What the `zx review [package_id]` command does is download the package, verify the signature belongs to the actual submitter, and unpacks it in a directory so you can inspect it (or more likely) run it with `zx rundir [unpacked directory]`.

After a package is reviewed (or if you’re flying solo and already know about the project because you wrote it) then you can “approve” it:

`ceverett@okonomiyaki:~/vcs\$ zx approve otpr-termifierg-0.1.0`

The if the sysop is someone different than the packager then the review command is actually necessary, because the next step is re-signing the package with the sysop’s key as a part of acceptance into the realm. That is, the sysop runs `zx review [package_id]`, actually reviews the code, and then once satisfied runs `zx package [unpacked_dir]` which results in a .zsp file signed by the sysop. If the sysop is the original packager, though, the .zsp file that was created in the packaging step above is already signed with the sysop’s key.

The sysop is the final word on inclusion of a package. If the green light is given, the sysop must “accept” the package:

`ceverett@okonomiyaki:~/vcs\$ zx accept otpr-termifierg-0.1.0.zsp`

Done! So now let’s see if we can search the index for it, maybe by checking for the “json” tag since we know it is a JSON project:

```ceverett@okonomiyaki:~/vcs/termifierg\$ zx search json
otpr-termifierg-0.1.0
otpr-zj-1.0.5
ceverett@okonomiyaki:~/vcs/termifierg\$ zx describe otpr-termifierg-0.1.0
Package : otpr-termifierg-0.1.0
Name    : Termifier GUI
Type    : gui
Desc    : Create, edit and convert JSON to Erlang terms.
Author  : Craig Everett zxq9@zxq9.com
Web     :
Repo    : https://gitlab.com/zxq9/termifierg
Tags    : ["json","eterms"]```

Yay! So we can now already do `zx run otpr-termifierg` and it will build itself and execute from anywhere, as long as the system has ZX installed.

I notice above that the “Web” URL is missing. The original blog post is as good a reference as this project is going to get, so I would like to add it. I do that by running the “update meta” command in the project directory:

ceverett@okonomiyaki:~/vcs/termifierg\$ zx update meta

```DESCRIPTION DATA
[ 1] Project Name             : Termifier GUI
[ 2] Author                   : Craig Everett
[ 3] Author's Email           : zxq9@zxq9.com
[ 4] Copyright Holder         : Craig Everett
[ 5] Copyright Holder's Email : zxq9@zxq9.com
[ 6] Repo URL                 : https://gitlab.com/zxq9/termifierg
[ 7] Website URL              :
[ 8] Description              : Create, edit and convert JSON to Erlang terms.
[ 9] Search Tags              : ["json","eterms"]
[10] File associations        : [".json"]
Press a number to select something to change, or [ENTER] to continue.
(or "QUIT"): 7
... [snip] ...```

The “update meta” command is interactive so I’ll spare you the full output, but if you followed the previous two tutorials you already know how this works.

After I’ve done that I need to increase the “patch” version number (the “Z” part of the “X.Y.Z” semver scheme). I can do this with the “verup” command, also run in the project’s base directory:

`ceverett@okonomiyaki:~/vcs/termifierg\$ zx verup patchVersion changed from 0.1.0 to 0.1.1.`

And now time to re-package and put it into the realm. Again, since I’m the sysop this is super fast for me working alone:

`ceverett@okonomiyaki:~/vcs\$ zx submit otpr-termifierg-0.1.1.zsp ceverett@okonomiyaki:~/vcs\$ zx approve otpr-termifierg-0.1.1ceverett@okonomiyaki:~/vcs\$ zx accept otpr-termifierg-0.1.1.zsp`

And that’s that. It can immediately be run by anyone anywhere as long as they have ZX installed.

BONUS LEVEL!

“Neat, but what about the screenshot of it running?”

Up until now we’ve been launching code using ZX from the command line. Since Termifier GUI is a GUI program and usually the target audience for GUI programs is not programmers, yesterday I started on a new graphical front end for ZX intended for ordinary users (you know, people expert at things other than programming!). This tool is called “Vapor” and is still an ugly duckling in beta, but workable enough to demonstrate its usefulness. It allows people to graphically browse projects from their desktop, and launch by clicking if the project is actually launchable.

Vapor is like low-pressure Steam, but with a strong DIY element to it, as anyone can become a developer and host their own code.

I haven’t written the window manager/desktop registration bits yet, so I will start Vapor from the command line with ZX:

You’ll notice a few things here:

• Termifier GUI’s latest version is already selected for us, but if we click that button it will become a version selector and we can pick a specific version.
• Observer is listed, but only as a “virtual package” because it is part of OTP, not actually a real otpr package. For this reason it lacks a version selector. (More on this below.)
• Vapor lacks a “run” button of its own because it is already running (ZX is similarly special-cased)

When I click Termifier’s “run” button Vapor’s window goes away and we see that the termifierg-0.1.1 package is fetched from Zomp (along with deps, if they aren’t already present on the system), built and executed. If we run it a second time it will run immediately from the local cache since it and all deps are already built.

When Termifier terminates Vapor lets ZX know it is OK to shutdown the runtime.

A special note on Observer and “Virtual Packages”

[UPDATE 2020-01-12: The concept of virtual packages is going away, observer will have a different launch method soon, and a rather large interface change is coming to Vapor soon. The general principles and function the system remain the same, but the GUI will look significantly different in the future — the above is the day-2 functioning prototype.]

When other programs are run by Vapor the main Vapor window is closed. Remember, each execution environment is constructed at runtime for the specific application being run, so if we run two programs that have conflicting dependencies there will be confusion about the order to search for modules that are being called! To prevent contamination Vapor only allows a single application to be run at once from a single instance of Vapor (you can run several Vapor instances at once, though, as each invocation of ZX creates an independent Erlang runtime with its own context and environment — the various `zx_daemon`s coordinate locally to pick a leader, though, so resource contention is avoided by proxying through the leader). If you want several inter-related apps to run at once within the same Erlang runtime, create a meta-package that has the sole function of launching them all together with commonly defined dependencies.

Because Observer is part of OTP it does not suffer from dependency or environmental conflict issues, so running Observer is safe and the “run” button does just that: it runs Observer. Vapor will stay open while Observer is running, allowing you to pick another application to run, and you can watch what it is up to using Observer as a monitoring tool, which can be quite handy (and interesting!).

If you want to run an Erlang network service type application using Vapor while using Observer (like a chat server, or even a Zomp node) you should start Vapor using the `zxh` command (not just plain `zx`), because that provides an Erlang shell on the command line so you can still interact with the program from there. You can also run anything using plain old zx run, and when the target application terminates that instance of the runtime will shut down (this is why ZX application templates define applications as “permanent“).

Cool story, bro. What Comes Next?

The next step for this little bundle of projects is to create an all-encompassing Windows installer for Erlang, ZX and Vapor (so it can all be a one-shot install for users), and add a desktop registration feature to Vapor so that Erlang applications can be “installed” on the local system, registered with desktop icons, menu entries and file associations in FreeDesktop and Windows conformant systems (I’ll have to learn how to do it on OSX, but that would be great, too!). Then users could run applications without really knowing about Vapor, because authors could write installation scripts that invoke Vapor’s registration routines directly.

If I have my way (and I always get my way eventually) Erlang will go from being the hardest and most annoying language to deploy client-side to being one of the easiest to deploy client-side across all supported platforms. BWAHAHAHA! (I admit, maybe this isn’t a world-changing goal, but for me it would be a world-changing thing…)

2019.12.28 23:56

Starting a simple GUI project in Erlang with ZX

A few days ago I wrote a tutorial about how to create a CLI program in Erlang using a new code utility called ZX that makes launching Erlang a little bit more familiar for people accustomed to modern dynamic language tooling.

Today I want to do another one in the same spirit, but with a simple GUI program as the example.

In the previous tutorial I did a CLI utility that converts files containing JSON to files containing Erlang terms. It accepts two arguments: the input file path and the desired output file path.

Today we’ll do a slightly more interesting version of this: a GUI utility that allows hand creation/editing of both the input before conversion and the output before writing. The program will have a simple interface with just three buttons at the top: “Read File”, “Convert” and “Save File”; and two text editing frames as the main body of the window: one on the left with a text control for JSON input, and one on the right a text control for Erlang terms after conversion.

First things, first: We have to choose a name and create the project. Since we did “Termifier” with a package and module name “termifier” before, today we’ll make it called “Termifier GUI” with a package and appmod “termifierg” and a project prefix “tg_”. I’ve clipped out the creation prompt output for brevity like before, but it can be found here: zx_gui_creation.txt.

```ceverett@okonomiyaki:~/vcs\$ zx create project

### --snip snip--
### Prompts for project meta
### --snip snip--

Writing app file: ebin/termifierg.app
Project otpr-termifierg-0.1.0 initialized.
ceverett@okonomiyaki:~/vcs\$```

If we run this using ZX’s `zx rundir` command we see a GUI window appear and some stuff happen in the terminal (assuming you’re using a GUI desktop and WX is built into the Erlang runtime you’re using).

The default templated window we see is a GUI version of a “Hello, World!”:

If we try the same again with some command line arguments we will see the change in the text frame:

The output occurring in the terminal is a mix of ZX writing to stdout about what it is building and WX’s GTK bindings warning that it can’t find an optional style module (which isn’t a big deal and happens on various systems).

So we start out with a window that contains a single multi-line text field and accepts the “close window” event from the window manager. A modest, but promising start.

What we want to do from here is make two editable text fields side by side, which will probably require increasing the main window’s size for comfort, and adding a single sizer with our three utility buttons at the top for ease of use (and our main frame, of course, being derived from the wxEvtHandler, will need to connect to the button click events to make them useful!). The text fields themselves we probably want to make have fixed-width fonts since the user will be staring at indented lines of declarative code, and it might even be handy to have a more natural “code editor” feel to the text field interface, so we can’t do any better than to use the Scintilla-type text control widget for the text controls.

Now that we know basically what we want to do, we need to figure out where to do it! To see where to make these changes we need to take a little tour of the program. It is four modules, which means it is a far different beast than our previous single-module CLI program was.

Like any project, the best way to figure out what is going on is to establish two things:

1. How is the code structured (or is there even a clear structure)?
2. What is called to kick things off? (“Why does anything do anything?”)

When I go into `termifierg/src/` I see some very different things than before, but there is a clear pattern occurring (though it is somewhat different than the common Erlang server-side “service -> worker” pattern):

```ceverett@okonomiyaki:~/vcs\$ cd termifierg/src/
ceverett@okonomiyaki:~/vcs/termifierg/src\$ ls -l

-rw-rw-r-- 1 ceverett ceverett 1817 12月 27 12:50 termifierg.erl
-rw-rw-r-- 1 ceverett ceverett 3166 12月 27 12:50 tg_con.erl
-rw-rw-r-- 1 ceverett ceverett 3708 12月 27 12:50 tg_gui.erl
-rw-rw-r-- 1 ceverett ceverett 1298 12月 27 12:50 tg_sup.erl```

We have the main application module `termifierg.erl`, the name of which we chose during the creation process, and then we also have three more modules that use the `tg_` prefix we chose during creation: `tg_con`, `tg_gui` and `tg_sup`. As any erlanger knows, anything named `*_sup.erl` is going to be a supervisor, so it is logical to assume that tg_sup.erl is the top (in this case the only) supervisor for the application. It looks like there are only two “living” modules, the `*_con` one, which seems short for a “control” module, and the `*_gui` one, which seems likely to be just the code or process that controls the actual window itself.

We know that we picked `termifierg` as the appmod for the project, so it should be the place to find the typical OTP `AppMod:start/2` function… and sure enough, there it is: `termifierg:start/2` is simply call to start things by calling `tg_sup:start_link/0`. So next we should see what `tg_sup` does. Being a supervisor its entire definition should be a very boring declaration of what children the supervisor has, how they depend on one another (order), and what restart strategy is being employed by that supervisor.

(Protip: magical supervision is evil; boring, declarative supervision is good.)

```init([]) ->
RestartStrategy = {one_for_one, 0, 60},
Clients   = {tg_con,
permanent,
5000,
worker,
[tg_con]},
Children  = [Clients],
{ok, {RestartStrategy, Children}}.```

Here we see only one thing is defined: the “control” module called `tg_con`. Easy enough. Knowing that we have a GUI module as well, we should expect that the `tg_con` module probably links to the GUI process instead of monitoring it, though it is possible that it might monitor it or maybe even use the GUI code module as a library of callback functions that the control process itself uses to render a GUI on its own.

[NOTE: Any of these approaches is valid, but which one makes the most sense depends entirely on the situation and type of program that is being written. Is the GUI a single, simple interface to a vast and complex system underneath? Does each core control component of the system have its own window or special widget or tab to render its data? Are there lots of rendered “views” on the program data, or a single view on lots of different program data? Is it OK for updates to the GUI to block on data retrieval or processing? etc.]

Here we see a program that is split between interface code and operation code. Hey! That sounds a lot like the “View” and “Control” from the classic “MVC” paradigm! And, of course, this is exactly the case. The “Model” part in this particular program being the data we are handling which is defined by the Erlang syntax on the one hand and JSON’s definition on the other (and so are implicit, not explicit, in our program).

The `tg_con` process is the operation code that does things, and it is `spawn_link`ing the interface that is defined by `tg_gui`. If either one crashes it will take the other one down with it — easy cleanup! For most simple programs this is a good model to start with, so we’ll leave things as they are.

The tg_gui process is the one that interfaces with the back-end. In this simple of a program we could easily glom them all together without getting confused, but if we add even just a few interesting features we would bury our core logic under the enormous amounts of verbose, somewhat complex code inherent in GUI applications — and that becomes extremely frustrating to separate out later (so most people don’t do it and their single-module-per-thingy WX code becomes a collection of balls of mud that are difficult to refactor later, and that stinks!).

Since we already know what we want to do with the program and we already proved the core code necessary to accomplish it in the previous tutorial, we can move on to building an interface for it.

This is what the final program looks like, using the same `example.json` from the CLI example:

At this point we are going to leave the blog and I will direct you instead to the repository code, and in particular, the commit that shows the diff between the original template code generated by ZX and the modified commit that implements the program described at the beginning of this tutorial. The commit has been heavily commented to explain every part in detail — if you are curious about how this Wx program works I strongly recommend reading the code commit and comments!

2019.12.25 23:04

Starting a simple CLI project in Erlang with ZX

Filed under: Computing,Science & Tech — Tags: , , , , , — zxq9 @ 23:04

Yesterday I wrote a post about a new tooling suite for developers and users that makes dealing with Erlang more familiar to people from other languages. Using the tool for packaging and deployment/launch makes writing and deploying end-user programs in Erlang non-mysterious as well, which is a great benefit as Erlang provides a wonderful paradigm for making use of modern overwhelmingly multi-core client systems.

It is still in beta, but works well for my projects, so I’ll leave a quick tutorial here that shows the basic flow of writing a simple CLI utility in Erlang using ZX.

In this example we’ll make a program that accepts two arguments: a path to a file with JSON in it and a path to a file where the data should be written back after being converted to Erlang terms.

To start a project we do `zx create project` and follow the prompts.
(The snippet below excludes the full output for brevity, but you can view the entire creation prompt log here: zx_cli_creation.txt.)

```ceverett@okonomiyaki:~/vcs\$ zx create project

### --snip snip--
### Prompts for project meta
### --snip snip--

Writing app file: ebin/termifier.app
Project otpr-termifier-0.1.0 initialized.
ceverett@okonomiyaki:~/vcs\$ ```

After the project is created we see a new directory in front of us called “termifier” (or whatever the project is named). We can execute this now just to make sure everything is going as expected:

```ceverett@okonomiyaki:~/vcs\$ ls
termifier
ceverett@okonomiyaki:~/vcs\$ zx rundir termifier
Recompile: src/termifier
Hello, World! Args: []
ceverett@okonomiyaki:~/vcs\$ zx rundir termifier foo bar baz
Hello, World! Args: ["foo","bar","baz"]```

Ah! So we already have something that builds and runs, very similar to how an escript works, except that using ZX we can easily add dependencies from Zomp package realms and package and execute this program on any system in the world that has ZX on it via Zomp ourselves.

…not that we have any reason to deploy a “Hello, World!” program to the wider public, of course.

Notice here that the first time we run it we see a message `Recompile: src/termifier`. That means the module `termifier` is being compiled and cached. On subsequent runs this step is not necessary unless the source file has changed (the compiler detects this on its own).

Next lets search Zomp for the tag “json” to see if there are any packages that list it as a tag, and if there are any let’s get a description so maybe we can find a website or docs for it:

```ceverett@okonomiyaki:~/vcs\$ zx search json
otpr-zj-1.0.5
ceverett@okonomiyaki:~/vcs\$ zx describe otpr-zj
Package : otpr-zj-1.0.5
Name    : zj
Type    : lib
Desc    : A tiny JSON encoder/decoder in pure Erlang.
Author  : Craig Everett zxq9@zxq9.com
Web     : https://zxq9.com/projects/zj/docs/
Repo    : https://gitlab.com/zxq9/zj
Tags    : ["json","json encoder","json decoder"]```

Ah. Checking the website it is clear we can use this to decode JSON by simply calling `zj:decode(JSON)`. Easy. So let’s add it to the project as a dependency and invoke it in `src/termifier.erl`:

```ceverett@okonomiyaki:~/vcs\$ cd termifier
ceverett@okonomiyaki:~/vcs/termifier\$ zx set dep otpr-zj-1.0.5
ceverett@okonomiyaki:~/vcs/termifier\$ cd src
ceverett@okonomiyaki:~/vcs/termifier/src\$ vim termifier.erl```

Inside termifier.erl we can see the templated code for `start/1`:

```start(ArgV) ->
ok = io:format("Hello, World! Args: ~tp~n", [ArgV]),
zx:silent_stop().```

Lets change it so it does what we want (note here I’m going a bit further and writing a function `write_terms/2` based on an older post of mine — this performs the inverse procedure of `file:consult/1`):

```start([InPath, OutPath]) ->
{ok, Terms} = zj:decode(Bin),
ok = write_terms(OutPath, Terms),
zx:silent_stop();
start(_) ->
ok = io:format("ERROR: Two arguments are required."),
zx:silent_stop().

write_terms(Path, Terms) when is_list(Terms) ->
Format = fun(Term) -> io_lib:format("~tp.~n", [Term]) end,
Text = lists:map(Format, Terms),
file:write_file(Path, Text);
write_terms(Path, Term) ->
write_terms(Path, [Term]).```

Note that we are calling `zj:decode/1` in the body of `start/1` above, knowing that ZX will find it for us and configure the environment at execution time. And now let’s give it a go!

```ceverett@okonomiyaki:~/vcs\$ zx rundir termifier example.json example.eterms
Recompile: src/zj
Recompile: src/termifier
ceverett@okonomiyaki:~/vcs\$ cat example.json
{
"fruit": "Apple",
"size": "Large",
"color": "Red"
}
ceverett@okonomiyaki:~/vcs\$ cat example.eterms
{"color" => "Red","fruit" => "Apple","size" => "Large"}.```

From here I could run `zx package termifier`, submit it to a realm (either the default public realm, or a new one I can create and host myself by doing `zx create realm` and then `zx run zomp`), and anyone could then run the command `zx run termifier [in path] [out path]` and ZX will take care of finding and building the necessary packages and launching the program.

That’s all there is to it. ZX’s template for CLI applications is quite minimal (as you can see) and is more similar to an escript than a more traditional OTP-style, supervised Erlang application. ZX has templates, however, for full-blown OTP applications, GUI code (structured also in the OTP paradigm), minimalist CLI programs like we see above, pure library code, and escripts (sometimes escript is exactly the tool you need!).

Happy coding!

2019.12.24 23:20

Erlang: A new packager and launching tool

I’ve never really liked the way that Erlang’s existing tools generally force one to accept “releases” as the One True Way to structure, build, test, launch and deploy Erlang programs. We have escript, of course, which is fantastic, but it does come with a few handicaps such as making it a somewhat cubmersome and magical process to write OTP-structured programs as scripts.

“Why do would you care about this? Isn’t Erlang what you use for writing game servers and streaming servers and web servers and… the key word being ‘server’?”

I care because I also write a lot of client-side code and Erlang provides a very smooth paradigm for writing networked GUI and CLI programs. While how to best structure those has been a bit of an exploratory art of its own since the first release of Erlang’s GUI bindings, the best way to deploy them to client systems (that is “end-user systems” — yes, the unwashed, non-technical masses) has been one of those subjects people tend to wave off because, well, nobody wants to discuss it and, “HAH! Who would write client-side Erlang without endless armies of tech support goons around the product?!?”.

Well, now we can (or at least I can).

I’ve started on a suite of tools that handles source templating for projects (GUI apps, CLI utilities, escripts, traditional OTP applications and library projects), packaging of them, distribution and resolution of the packages, building, and launching (in a “first-run means automatic deployment” paradigm) in a way that a developer familiar with other dynamic scripting languages would probably feel more at home with.

I’m still messing about with a few of the minor features (like text search for packages based on tags, a GUI application browser, an installer for Windows, and so on) but the core of it is in place for developers already.

If you’re an Erlanger or perhaps just Erlang-curious but never were quite sure how to get started with writing Erlang programs because structuring an Erlang project was always a bit of a mystery you never had time to work your way through, give it a try and please give me some feedback so I can improve the tools.

The tool itself is called ZX and the distribution service node code is called Zomp. To run the installer it all you need is an Erlang runtime somewhere in \$PATH.

2019.11.21 17:24

Testing Textually Composed Numbers for Primality

Filed under: Computing,Science & Tech — Tags: , , , , , — zxq9 @ 17:24

Last night on Twitter one of my favorite accounts, @fermatslibrary, put up an interesting post:

Start at 82 and write it down, then 81, write that down, etc. until you reach one, and you’ve written a (huge) prime number. Wow!

This seemed so strange to me, so of course I got curious:

After some doodling around I wrote a script that checks whether numbers constructed by the method above are prime numbers when the number construction is performed in various numeric bases (from 2 to 36, limited to 36 because for now I’m cheating using Erlang’s integer_to_list/2). It prints the results to the screen as the process handling each base finishes and writes a text file “texty_primes-result-[timestamp].eterms” at the end for convenience so you can use file:consult/1 on it later to mess around.

There are a few strange aspects to large primes, one of them being that checking whether or not they are prime can be a computationally intense task (and nobody knows a shortcut to this). To this end I wrote the Miller-Rabin primality test into the script and allow the caller to decide how many rounds of Miller-Rabin to run against the numbers to check them. So far the numbers that have come out have matched what is expected, but once the numbers get extremely large (and they get pretty big in a hurry!) there is only some degree of confidence that they are really prime, so don’t take the output as gospel.

I wrote the program in Erlang as an escript, so if you want to run it yourself just download the script and execute it.
The script can be found here: texty_primes

A results file containing the (very likely) prime constructions in bases 2 through 36 using “count-back from X” where X is 1 to 500 can be found here: texty_primes-result-20191121171755.eterms
Analyzing from 1 to 500 in bases 2 through 36 took about 25 minutes on a mid-grade 8-core system (Ryzen5). There are some loooooooooong numbers in that file… It would be interesting to test the largest of them for primality in more depth.

(Note that while the script runs you will receive unordered “Base X Result” messages printed to stdout. This is because every base is handed off to a separate process for analysis and they finish at very different times somewhat unpredictably. When all processing is complete the text file will contain a sorted list of {Base, ListOfPrimes} that is easier to browse.)

An interesting phenomenon I observed while doing this is that some numeric bases seem simply unsuited to producing primes when numbers are generated in this manner, bases that themselves are prime numbers in particular. Other bases seem to be rather fruitful places to search for this phenomenon.

Another interesting phenomenon is the wide number of numeric bases in which the numbers “21”, “321”, “4321” and “5321” turn out to be prime. “21” and “4321” in particular turn up quite a lot.

Perhaps most strangely of all is that base 10 is not a very good place to look for these kinds of primes! In fact, the “count back from 82” prime is the only one that can be constructed starting between 1 and 500 that I’ve found. It is remarkable that anyone discovered that at all, and also remarkable that it doesn’t happen to start at 14,562 instead of 82 — I’m sure nobody would have noticed this were any number much higher than 82 the magic starting point for constructing a prime this way.

This was fun! If you have any insights, questions, challenges or improvements, please let me know in the comments.