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

2021.05.4 17:56

Tsuriai: Now engaging in smart contract work

I never thought I’d see the day, but Tsuriai (the tiny Japanese software company I work for) is now in the Ethereum smart contract market as a developer — which means I am now in that same market.

Need a smart contract or blockchain/IPFS-based project developers/consultants/educators*?
Just shoot the office an email at info@tsuriai.jp and they’ll hook you up.
They can even accept payment in ETH now, which makes it a lot easier to contract from overseas.

What a world!

[*Or, as always, Erlang developers or consultants, distributed systems analysis, and pretty much any other BEAM-related services, education or assistance!]

It is pretty well known that I don’t think smart contracts are going to save the world from itself because the problems in the US, Europe and China have everything to do with violations of social trust by government and lack of faith in people among the people themselves (as well as lack of faith in culture and tradition), but… smart contracts actually are kind of fun to write and our workflow is pretty darn fast.

There are clear use cases that fit the Ethereum-style computing paradigm and even some that clearly benefit from deployment on something like IPFS rather than a traditional server back end, and we can talk the client through the pros and cons. I suppose the most common thing to want to implement is NFTs at the moment, and some forms of NFTs (especially distributed name registry systems <hint!> <hint!>) are clearly extremely valuable solutions to otherwise difficult to administer problems.

2021.04.30 09:10

Valgrind “Hello, World!”: Python 3.6 VS Python 2.7 VS Erlang R23

I’ll just leave this here…

Python 3.6

ceverett@icecream:~/Code/python$ cat hello.py
#! /usr/bin/python3

print("Hello, world!")
ceverett@icecream:~/Code/python$ ./hello.py
Hello, world!
ceverett@icecream:~/Code/python$ valgrind ./hello.py
...
==19264== HEAP SUMMARY:
==19264==     in use at exit: 320,946 bytes in 166 blocks
==19264==   total heap usage: 1,698 allocs, 1,532 frees, 2,505,946 bytes allocated
==19264== 
==19264== LEAK SUMMARY:
==19264==    definitely lost: 0 bytes in 0 blocks
==19264==    indirectly lost: 0 bytes in 0 blocks
==19264==      possibly lost: 5,608 bytes in 10 blocks
==19264==    still reachable: 315,338 bytes in 156 blocks
==19264==         suppressed: 0 bytes in 0 blocks
...
==19264== ERROR SUMMARY: 8163 errors from 116 contexts (suppressed: 0 from 0)
ceverett@icecream:~/Code/python$

Python 2.7

ceverett@icecream:~/Code/python$ cat hello2.py 
#! /usr/bin/python

print "Hello, world!"
ceverett@icecream:~/Code/python$ ./hello2.py
Hello, world!
ceverett@icecream:~/Code/python$ valgrind ./hello2.py
...
==19416== HEAP SUMMARY:
==19416==     in use at exit: 417,246 bytes in 199 blocks
==19416==   total heap usage: 2,958 allocs, 2,759 frees, 3,085,205 bytes allocated
==19416== 
==19416== LEAK SUMMARY:
==19416==    definitely lost: 0 bytes in 0 blocks
==19416==    indirectly lost: 0 bytes in 0 blocks
==19416==      possibly lost: 528 bytes in 1 blocks
==19416==    still reachable: 416,718 bytes in 198 blocks
==19416==         suppressed: 0 bytes in 0 blocks
...
==19416== ERROR SUMMARY: 489 errors from 30 contexts (suppressed: 0 from 0)
ceverett@icecream:~/Code/python$

Erlang R23

(On this one I can include the entire output.)

ceverett@icecream:~/Code/erlang$ cat hello_world 
#! /usr/bin/env escript

% Example of an escript
-mode(compile).

main(_) ->
    ok = io:setopts([{encoding, unicode}]),
    io:format("Hello, world!~n").
ceverett@icecream:~/Code/erlang$ ./hello_world 
Hello, world!
ceverett@icecream:~/Code/erlang$ valgrind ./hello_world
==25872== Memcheck, a memory error detector
==25872== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==25872== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==25872== Command: ./hello_world
==25872== 
Hello, world!
ceverett@icecream:~/Code/erlang$

Hey, Python! What the actual fsck is going on here?!? Jeebus… The Good Idea Fairy came along and convinced the webtarded among you to start throwing kitchen sink features in (“walrus operator” — yeah, great idea, that, and totally worth losing the sober guidance of Guido over…) along with 8163 memory errors. Sweet! Oh how far the great have fallen…

Honorable mention: Ruby 2.5

I didn’t expect much better from Ruby as the Good Idea Fairy has been forwarding all xer mail there for years, but wow… just wow

ceverett@icecream:~/Code/ruby$ cat hello_world.rb 
#! /usr/bin/ruby

print "Hello, World!\n"
ceverett@icecream:~/Code/ruby$ ./hello_world.rb 
Hello, World!
ceverett@icecream:~/Code/ruby$ valgrind ./hello_world.rb
...
==27051== HEAP SUMMARY:
==27051==     in use at exit: 2,921,234 bytes in 20,690 blocks
==27051==   total heap usage: 65,312 allocs, 44,622 frees, 16,447,358 bytes allocated
==27051== 
==27051== LEAK SUMMARY:
==27051==    definitely lost: 385,479 bytes in 4,421 blocks
==27051==    indirectly lost: 640,953 bytes in 5,808 blocks
==27051==      possibly lost: 1,626,429 bytes in 9,663 blocks
==27051==    still reachable: 268,373 bytes in 798 blocks
==27051==         suppressed: 0 bytes in 0 blocks
...
==27051== ERROR SUMMARY: 162050 errors from 402 contexts (suppressed: 0 from 0)
ceverett@icecream:~/Code/ruby$

162,050 memory errors. For Hello, World. How can there even be 162,050 instructions in the resulting set of commands to the system?

2021.04.5 20:25

Erlang: Socket experiments preliminary to writing a web server from scratch

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

A relative newcomer to networking in Erlang, Dr. Ajay Kumar, has started a self-educational project to create a web server from scratch in Erlang to give himself some first-hand insight into how TCP sockets work in Erlang and how web servers work in general. Web servers are a thing almost everyone has written against or for, but few have tried to implement on their own because socket programming sounds scary and time consuming to learn.

This video is quite short but incidentally demonstrates how not scary socket programming is and how easy it is to experiment with networking concepts on your own. Go experiment! Write networky things! It’s fun!

As an aside to this… I have a two-part explanation video that explains everything that is going on inside the service at he is basing his web server on. In the first part I explain what is going on within the default chat server that ZX templates as a network service project (kind of slow, covers basics for Erlang and ZX newcomers), and in the second part I explain how I used that as a basis for creating a telnet chat service that implements global shouts, channels, permissions, and other basic features needed for a real chat service (a bit better paced if you already know your way around Erlang and discusses some higher-level concepts such as service structure and the “service -> worker pattern“).

2020.12.19 17:16

Erlang: Writing a Tetris clone Part 2 – Gameplay mechanics

Last night I was able to make the second video in my series about implementing a Tetris clone in Erlang. Yay!

In this video I start where I left off in the first video where I had ended with a data abstraction to represent the play field (called the “well” in Tetris lingo), a data abstraction for the game pieces, some colored sprites to draw the game board with, and a GUI that could draw a game board and a single random piece every time it was opened as well as print to stdout any key press events that I made.

Oh but by the way…

I have a small confession to make — I didn’t actually start where I left off. I mentioned the stopping point (the “Draw the board with a random piece on it” commit), then I mentioned the next thing I did which was implement basic movement (the “Basic (unsafe) movement” commit), then I completely blew past it and never explained the way I implemented unsafe movement in the first place. The trouble with having skipped that is that I had intended to discuss how keystroke capture actually works, where it is in the GUI code, and follow the event through the system so that people could get that idea into their head earlier than later because it is so basic to making a game!

So instead I’ll explain how that works and point out where it is in the code here in this post and cover it at the beginning of the third video.

Getting Input

If we look at the “Basic (unsafe) movement” commit there is a file called ertltris/src/et_gui.erl that is the code for the GUI process. In the init/1 function we see the wx server get started, a “frame” is created (the main window in wx parlance), some various widget elements and things are all established and on line 112 we see this:

ok = wxPanel:connect(Frame, char_hook),

This is connecting the Frame to a window manager event called char_hook. I do mention this in the video, but it is important to point this out here. I should also point out that I’m mistakenly calling wxPanel:connect/2 instead of wxFrame:connect/2 — which is technically incorrect, but due to the nature of the underlying inheritance among the C++ classes that make up wx and the way that’s all masked in the generated library wrappers that make up wxErlang, it actually doesn’t cause any errors. wxPanel and wxFrame are all ancestors of wxEventHandler.

Anyway… what connecting to this event does is tells wx that whenever the frame is the focus it should relay keystroke events to the program. Inside Erlang they arrive as messages that carry a #wx{} record that includes an event element that carries another record that provides all the relevant information about the event. You can receive these in the handle_event/2 callback function of wx_object. Pretty nice. This means you can deal with GUI events in very much the same way you can handle network events as well as inter-process messages within the Erlang runtime: everything is a message.

IDIOMS IDIOMS IDIOMS!

As I often say: Develop idioms.

A common idiom I use in wxErlang code is to match on an event type in handle_event/2, assign any relevant event data to variables, and then within a case inside the handle_event clause that matched that event type determine where we want to dispatch the event (if at all). You can see a very clear example of this on lines 191-203 of this commit.

handle_event(#wx{event = #wxKey{keyCode = Code}}, State = #s{frame = Frame}) ->
    ok =
        case Code of
             32 -> et_con:random_piece();
             88 -> et_con:rotate(l);
             90 -> et_con:rotate(r);
            314 -> et_con:move(l);
            315 -> et_con:rotate(r);
            316 -> et_con:move(r);
            317 -> et_con:move(d);
            _  -> tell("KeyCode: ~p", [Code])
        end,
    {noreply, State};

I could have made each one of those dispatch decisions inside the function head instead of using a case statement within a clause, but I find it much easier to read this particular style where we open a very compact dispatch span per event type we’re looking for than have a ton of handle_event clauses. In complex GUI applications you can wind up with a lot of special keystroke events and it becomes super cumbersome to match them all as function heads. Not just writing the function heads, but trying to find a specific event gets kind of messy because the code starts looking so scrambled.

Each of the different key codes matched in the dispatching part of that function correspond to some gameplay event. Note that the GUI doesn’t really care what the status of the game is at all, it just cares that it is relaying the mapped commands to the game control process and then carries on doing GUI stuff.

This is important to point out: Nearly all communication between the controller and the GUI is asynchronous. You almost never want blocking calls to pass between them. There may be a need for a blocking call in some special code, but this is almost always a bad idea.

Buh bye!

That pretty much sums up what I wanted to cover that I forgot to mention in the video. Input handling is really important. If you want to jump ahead, check out the way the handle_event/2 function evolved in the latest commits to see how menu commands are intercepted, or go check out the handle_event/2 function in the Erlang Minesweeper clone!

Don’t forget to give me all the delicious likes and stars and channel subs! BWAHAHA! I’ll catch you magnificent nerds in the next video!

2020.12.15 17:16

Erlang: Writing a Tetris clone Part 1 – Data types and basic GUI display

Over the last few days I wrote an Erlang implementation of the classic puzzle game Tetris and decided to do a few videos to explain how it works and why. This is part one of a three-part series.

  1. Data types and basic GUI display [this page]
  2. Gameplay mechanics
  3. Gameplay rules, final features, and deployment

This first video covers how I started the project (cheating using ZX to template a GUI project for me, of course), what data types I thought I would probably need from the outset (the game board and the game pieces), and my initial stab at getting pixels on the screen in a reasonably pretty way.

The videos roughly trace the commit history of the project as I developed it, with this first video covering the first 3 commits which get me from a GUI project template to displaying the game board and drawing a random piece in it each time I start the program (as well as catching keystrokes so I can examine what their values are).

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 upgrade
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.04.5 14:44

For Data Reporting, Keep Reliable URLs

Filed under: Science & Tech,Society — Tags: , , , , , , , , — zxq9 @ 14:44

It would be really nice if governments that are trying to be transparent by reporting stats publicly on a website would stop changing their entire URL scheme every week. It is hard to track things down and even the search engines aren’t keeping up very well.

2020.02.3 15:19

X-Y Problems

Filed under: Computing,Science & Tech,Society — Tags: , , , , , — zxq9 @ 15:19

People obsess about their X-Y problems to the point of ignoring accepted wisdom, plugging their ears to the deafening silence of the solution’s instructive whisper, picking themselves up as hard as they can by their own knees and wondering why they can’t fly.

They then run off and formalize their wrong solution as a PR into a core project.

If core maintainers aren’t mindful they’ll incorporate these disturbances into a previously still space, and if they are indelicate they will piss off the misguided (but industrious) boob who made the PR who is already by this point fanatically dedicated to his wrong solution and the idea that nobody “gets it” but him.

Ah, another day at the Bazaar.

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
合計 16
-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,
                  {tg_con, start_link, []},
                  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_linking 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
Adding 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, Bin} = file:read_file(InPath),
    {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!

Older Posts »

Powered by WordPress