Blog

I want to write some reference for error management in Rust and in Go, versus exception-class based language, maybe Python deserve a specific session, I will update that, but basically the point of exception-based error management is the sub-classing of a Exception class and the try {...} catch(...) {...} block for handling exceptional cases

Golang (aka Go language)

In Go Error is an interface. This is the only fact that one must understand about error. In Go a function can return a tuple that is de-structured by the assignment operator, like in

a, b, c := GetTuple(1)

Where

func GetTuple(i int) (int, int, int) {
   return i, i, i
}

And it is dev responsability to deal with function returning Error as a second component of the tuple.

The func that generates error must always returns a tuple of 2 component: (response, error), where either response or error must be nil, typically not both, but there is no limitation.

Error type is defined as:

type CustomError struct {
  S string
}
func (e *CustomError) Error() string {
  return e.S
}

An almost complete exposition of error handling is given by the golang tour https://go.dev/tour/methods/19

Rust Language

In Rust things are a bit more complicated. The main reason is the strong type system. In fact a fn in Rust can return a Result, that is an additive type, also known from C developer as the old and good enum (but with a better implementation). So:

pub enum Result<T, E> {
    Ok(T),
    Err(E),
}

And E must implement fmt::Display.

Again, it is a dev responsability to deal with error, but there are some important constraints.

The fact that Result type is an additive type, means that only one case is given: you got a result, or you got an error. Both or neither are not possible, because the fn is just returning one value of the enum, being it Ok(T), or Err(E).

Of course the calling code must match both enum values, or if Ok(r) {...} else{...}, or if Err(e) {...}else{...}, or whatever, including question mark for throwing up to the caller of the caller.

These constraints are the gift offered by the Rust type system, and it would make your code more robust by design, at least if you are a responsible developer, and anyway one MUST deal with errors, someway, anyhow

Exception based language

Basically one has a Exception base class then there 2 main constructs:

1. raise or throw exception
2. try…catch, or try…except block

If the code do not catch the exception, depending on the strength of the language, it may not compile (/run) at all, or just crash at runtime.

(semi) Conclusion

I would like to write a more detailed article, but also I want this to remains succinct.

I want to notice here that Rust type system play an important role in error handing, but also the specific construct given by ? (question mark) and the functional nature of the language make it really robust, but of course robustness come with a price to charged to the head of the developer, question mark and anyhow are very practical to procrastinate the error management, but constraint on Err(e) type may be annoying on first sight (it must impl fmt::Display).

On contrast, Go language is very relaxed on error handling, still it is expected to provide a struct implementing the interface Error, and this is almost everything one must remember, it is idiomatic to see if err != nil everywhere in a Go source code.

From the performance point of view, both Go and Rust has the most lightweight method for dealing with errors. By contrast exception based language needs specific runtime that is almost hidden to the developer, that is not true for Go, neither for Rust, meaning literally: the error handing cost is not hidden in Go/Rust.

Adapt language to stack

If you are interested on adapting C language to something similar to C++ Exception handling you should read this article:

C Language Exception Handling

Just catch a glimpse from your windows (it was: “introduction”)

The windows method in Rust’s standard library is a powerful tool for processing sequential data. It enables efficient iteration over fixed-size, overlapping windows of elements in a collection, offering a functional and concise approach to data manipulation. This article will discuss the usefulness of the windows method, with examples and domain applications to help you grasp its potential.

Understanding windows

The windows method is part of the Iterator trait and provides a way to create an iterator over overlapping windows of elements within a slice. The syntax for using windows is as follows:

slice.windows(window_size)

where slice is the input slice and window_size is the size of the window.

The method returns an iterator that yields windows of the specified size. The iterator will produce a new window for each step, moving one element forward at a time. It’s important to note that the windows method will only work with slices, so you might need to convert other collections like Vec to a slice using the as_slice() method.

Example usage

Consider the following example, which calculates the moving average of a sequence of numbers:

fn moving_average(numbers: &[f64], window_size: usize) -> Vec<f64> {
    numbers.windows(window_size)
        .map(|window| window.iter().sum::<f64>() / window_size as f64)
        .collect()
}

fn main() {
    let numbers: Vec<f64> = vec![1.0, 2.0, 3.0, 4.0, 5.0];
    let window_size = 3;
    let output = moving_average(&numbers, window_size);
    println!("{:?}", output); // Output: [2.0, 3.0, 4.0]
}

In this example, the moving_average function takes a slice of f64 numbers and a window size as input. It uses the windows method to create an iterator over windows of the given size, calculates the average for each window, and collects the results into a Vec.

Domain applications

The windows method has numerous applications across various domains, including:

1. Time series analysis: In finance, economics, and other fields, time series data is often analyzed using rolling or moving window techniques. The windows method can help with calculating moving averages, standard deviations, and other rolling statistics.
2. Signal processing: Digital signal processing often involves applying filters or transformations to a sequence of samples. The windows method can be used to implement sliding window filters, convolution operations, or other window-based techniques.
3. Text analysis: When analyzing text data, the windows method can be used to extract n-grams (contiguous sequences of n items) for tasks such as language modeling, text classification, or information retrieval.
4. Genomics: In bioinformatics, analyzing DNA or protein sequences often involves sliding window techniques to identify motifs, calculate sequence similarity, or perform other analyses.

Conclusion

The windows method in Rust is a powerful tool for processing sequential data, offering an efficient and functional way to work with fixed-size, overlapping windows. Its applicability spans across various domains, such as time series analysis, signal processing, text analysis, and genomics. By understanding and leveraging the power of windows, you can write concise and efficient Rust code for a wide range of data manipulation tasks.

My own conclusion

The above article was generated by ChatGPT 4, my prompt was:

can you write a technical article on the usefulness of windows? including in that article example of its usage and example of domain of application

This question was “in topic” with the same chat session (that was about Rust windows() of vector, for the record)

windows’ doc is https://doc.rust-lang.org/std/slice/struct.Windows.html

Existing article https://tndl.medium.com/rusts-slice-windows-is-really-cool-70d50cdc74c5 (Austin Tindle), just the first from google.

If you found this article by google my hint is: next time consider to hire a language model.

Key concepts

Container manager.There is an actor, a daemon, or something that pull and run the right image when instructucted to do that.
That means, you can use docker, docker swarm mode, kubernetes, k3s, or whatever daemon to monitor or just run container
based on image taken from some place, and that daemon need to understand what to pull.

Architecture: every machine has its own instruction set, device, etc. and its own binary format.
This is “architecture” in this context (the context of cross building a docker image).

Binary format, binfmt in linux. There is a lot of things on this topic, and too advanced.
Anyway, Linux kernel support a kind of pluggable executor based on magic character, characters used
to recognize the architecture, those magics are bounded with executor. Typically /proc fs or /sys fs is used
to setup and inspect kernel runtime setup, so the current binfmt status can be inspected in /proc/sys/fs/binfmt_misc/*
More infos in lwn article: https://lwn.net/Articles/630727/

Docker registry is a service that run somewhere and keep track of images and theirs tags.

Image manifest. This was a new concept to me, tag is not enough for describing an image, an image is identified by
its manifest, that is a json structure that keep reference to the real image(s) tag(s), its architecture, and other infos.

So the manifest, someway, overlap the concept of tag for image, but in fact that is a trick: a default manifest
with the same tag is created and associated to the unique image tag, when manifest is not treated explicitly.

So manifest has a tag, like each image has a tag, but manifest refers to more images.

Deal explicitly with manifest

Docker CLI, the command line interface used to communicate with dockerd, is not intended to deal with manifest,
I do not know why, but it can do it only enabling “experimental” feature, by editing ~/.docker/config.json with

{"experimental": "enabled"}

Then is possible to use it

Commands:

• docker manifest inspect --verbose TAG
• docker manifest create MANIFESTTAG [IMAGETAG1 [IMAGETAG2 [IMAGETAG3 […]]]]
• docker manifest push MANIFESTTAG

inspect is to inspect, create is to create, push is to push the created manifest into the remote registry.

There are limitations here, for example one can create a manifest tag and push it to the registry, but if
the manifest refers to image tags that are not already pushed in the registry the service will complain about it
(or at least I suppose, never tried)

Real building multiarch

What I used to understand it as of few days ago, a Dockerfile refer to main image in FROM section.
But today my idea about it become more complex and I am a bit confused.
Maybe it refers to a Manifest? and the image is automatically selected during the docker build
phase from a set of image, based on matching architecture?

Anyway, one can explicetely refer to a specific architecture by its name, for example using alpine distro
it is a prefix: ‘amd64/’, ‘arm32v7/’, ‘arm64v8/’, …

In Dockerfile is possible to define arguments and their defaults:

ARG ARCH=
FROM ${ARCH}alpine

and give values to arguments in command line during docker build:

docker build -t IMAGETAGNAME --build-args ARCH=arm32v7/

at this point the docker daemon try to build it based on image referred in FROM: arm32v7/alpine

This image contains a filesystem with binary in a format specific to arm32v7 architecture, so you have:

standard_init_linux.go:211: exec user process caused “exec format error”

it means there is no magic matched, so docker tried to execute it directly, but by

docker run --rm --privileged docker/binfmt:a7996909642ee92942dcd6cff44b9b95f08dad64

the folder /proc/sys/fs/binfmt_misc is populated, i.e.:

cat /proc/sys/fs/binfmt_misc/qemu-arm

enabled
interpreter /usr/bin/qemu-arm
flags: OCF
offset 0
magic 7f454c4601010100000000000000000002002800
mask ffffffffffffff00fffffffffffffffffeffffff

and now again

docker build -t IMAGETAGNAME –build-args ARCH=arm32v7/

will build the image in a qemu-arm machine runned magically for that job.

Then the steps are:

1. built image tag for each architecture
2. push image tag for each architecture
3. create a manifest naming it with a tag and referring to all architecture created in 1. and pushed in 2.
4. push the manifest created in 3. to the docker registry

There is nothing complex or special, but one just need to understand the concept behind the words: image tag, manifest tag, manifest, architecture, registry, binfmt, crossbuild, …

References

I found it hard to understand concepts, my learning path (I spent 5/6 hours) was to check first this document
https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

From there I needed to understand github actions, and github secrets

1. github actions

An action is defined by

i. a trigger (on: push: branch: master, for example)
ii. and a job, made of: name, environment, steps

i.e. https://github.com/danielecr/uuid-provider/blob/main/.github/workflows/image.yml

2. github secrets

It is possible to define variable binded with the repo, those are secrets and environment variable

It is possible to access those variables from github action, i.e. by ${{ secrets.MYSECRET }}

But still I was confused about it.

I googled more, and continuosly found reference to windows platform, and everywhere try to sell that
buildx as “easy way”, with result to be more confused.

I finally found https://www.docker.com/blog/getting-started-with-docker-for-arm-on-linux/
still a lot of advertising for buildx script, but reference to https://hub.docker.com/r/docker/binfmt/tags?page=1&ordering=last_updated
and by guessing it https://github.com/docker/binfmt
and suggestion to use the newer https://github.com/linuxkit/linuxkit (but I still need to see it)

Just for curiosity, the only graphical description of build environment I found was in https://www.stereolabs.com/docs/docker/building-arm-container-on-x86/ but it give little/no infos about binfmt, and it is a content specific to jetbrain device.

isomorphic javascript is a technology used to speedup rendering on browser, it can be used a pure version that is server-side-rendering (ssr) to generate template from a react app

Motivation: Create a presentation template to be converted to pdf and configurable with data: produce formatted documents.

Here:
https://www.freecodecamp.org/news/server-side-rendering-your-react-app-in-three-simple-steps-7a82b95db82e/

This is the way the piece of server generated code and client app can work together, using renderToString from:

import { renderToString } from ‘react-dom/server’;

the rendered html contains references to the window.STATE, hydrate is used to “undry” the app (sort of bring it to life).

But by using renderToStaticMarkup from:

import { renderToStaticMarkup } from ‘react-dom/server’;

it is possible to render directly to html markup, without any additional information: pure html.

note

The trick is on the use of:

require("@babel/register");

for transpilling the jsx to javascript transparently.

Here is a src/template.js code:

require("@babel/register");
let fs = require('fs');

const decoratedStyle = (content) => {
    return '<style type="text/css">\n' + content + '\n</style>\n';
}

const nodulespath = __dirname.replace(/\/[a-zA-Z]+$/,'')+"/node_modules/";

const importCss = (moduleref) => {
    const solvedPath = moduleref.replace("~",nodulespath).replace("\./",__dirname+'/');
    //console.log('solvedpath', moduleref, solvedPath);
    let styledef = fs.readFileSync(solvedPath);
    return decoratedStyle(styledef);
}

let render = require('./server');

const template = (state) => {
    let s = {...state};
    delete s.title;
    let content = render(s);
    let page = `<!DOCTYPE html>
              <html lang="en">
              <head>
                <meta charset="utf-8">
                <title> ${state.title} </title>
                ${importCss('~bootstrap/dist/css/bootstrap.min.css')}
                ${importCss('~font-awesome/css/font-awesome.min.css')}
                ${importCss('./template.css')}
              </head>
              <body>
              <div id="root">
                ${content}
                </div>
              </body>
              `;

  return page;
}

module.exports = template;

and here a rendering script that is called by a nodejs service that generate static documents:

const fs = require('fs');
const inlineCss = require('inline-css');

let template = require('./template');
let getState = require('./state/get-state');

let data = process.argv[2];
//console.log('commna',data);
let currentselection = {
    tariff_id: 5,
    selected_opt: {"3101":66,"3102":79,"3108":166,"3109":34,"3112":155,"3114":85,"3115":157,"3208":161,"4005":180,"4102":151,"4105":170,"4107":67,"4202":159,"4207":105}
};

let state = getState(JSON.parse(data));
let html = template(state);

const output_fn_inlined = __dirname + '/../dist/output.inlined.html';

inlineCss(html, {url: 'http://ssl.starsellersworld.com/'})
.then(html => {
    //fs.writeFileSync(output_fn_inlined, html);
    let buf = Buffer.from(html);
    //console.log(buf.toString('base64'))
    let res = {"html":buf.toString('base64')};
    //console.log(JSON.stringify(res))
    process.send(JSON.stringify(res));
    //process.send(data);
    process.exit(0);
}).catch(err=> {
    console.log('error', err);
    process.exit(0);
});

If you want to know more, you can consider working with us, drop me an email: dc @ xwave . de ( r e m o v e s p a c e s ! )