| // | |
| // A simple example of a calculator programming language, that compiles to native code! | |
| // | |
| // Written by Tetralux <tetraluxonpc@gmail.com>, 2023-03-09. | |
| // | |
| // Programs are a string that you pass as an argument in the form of a mathmetical expression. | |
| // e.g: '10 + 4 - 1 + 7'. | |
| // This program will generate some Zig code that computes the answer, and prints it to stdout. | |
| // It then will invoke the Zig compiler as a subprocess to compile and run this program. | |
| // |
| // Build: zig build-exe -O ReleaseFast --strip src/main.zig | |
| // Run: zig build run -- -w 70 -h 40 -m "*" -s 0.07 -c 25 | |
| // Version: 0.10.0-dev.3475+b3d463c9e | |
| // Date: 2022/08/09 | |
| const std = @import("std"); | |
| const fmt = std.fmt; | |
| const mem = std.mem; | |
| const os = std.os; |
This is intended as a place to list blog posts about Zig, for anyone who's interested in reading what people have to say! Also check out links at https://ziglang.org/learn/ and https://ziglang.org/news/.
Posts were found by searching on lobste.rs, at https://dev.to/t/zig and https://medium.com/tag/zig.
Please let me know in a comment if there are any posts missing that you'd like me to add here!
tl;dr: Wayland is not "the future", it is merely an incompatible alternative to the established standard with a different set of priorities and goals.
Wayland breaks everything! It is binary incompatible, provides no clear transition path with 1:1 replacements for everything in X11, and is even philosophically incompatible with X11. Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.
Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating e
Nvm does not work in vscode tasks, because tasks are run without a shell. .bashrc is not loaded and the nvm command is unknown.
My solution uses a wrapper script around /bin/bash that reads in the correct node version from .npmrc in the project folder.
#!/bin/bash
set -e
if [[ "$2" == nvm* ]]; then
export NODE_VERSION=v$(cat .nvmrc)
There's a lot of type terminology and jargon going around when discussing types in Elm. This glossary attempts to list some of the most common type terms along with synonyms, terms from other language communities, examples, and links to more detailed articles on each topic.
| # Synchronize history between bash sessions | |
| # | |
| # Make history from other terminals available to the current one. However, | |
| # don't mix all histories together - make sure that *all* commands from the | |
| # current session are on top of its history, so that pressing up arrow will | |
| # give you most recent command from this session, not from any session. | |
| # | |
| # Since history is saved on each prompt, this additionally protects it from | |
| # terminal crashes. |
This gist explains how to interpret the DUSCMPUB-formatted mortality data found [here][1] in conjunction with the [reference PDF][2].
The [reference PDF][2] uses 3 components to describe the type of data, its location within the row, and its size:
How do you send information between clients and servers? What format should that information be in? What happens when the server changes the format, but the client has not been updated yet? What happens when the server changes the format, but the database cannot be updated?
These are difficult questions. It is not just about picking a format, but rather picking a format that can evolve as your application evolves.
By now there are many approaches to communicating between client and server. These approaches tend to be known within specific companies and language communities, but the techniques do not cross borders. I will outline JSON, ProtoBuf, and GraphQL here so we can learn from them all.