diff --git a/.github/workflows/nix.yml b/.github/workflows/nix.yml index eccedcf..1c09d87 100644 --- a/.github/workflows/nix.yml +++ b/.github/workflows/nix.yml @@ -14,6 +14,3 @@ jobs: nix-build docker.nix docker load -i result docker tag xena/christinewebsite:latest xena/christinewebsite:$(echo $GITHUB_SHA | head -c7) - - run: | - nix-env -if ./nix/dhall-yaml.nix - dhall-to-yaml-ng --omit-empty --file site.dhall diff --git a/blog/v-vaporware-2019-06-23.markdown b/blog/v-vaporware-2019-06-23.markdown index 7cc1dc0..7280225 100644 --- a/blog/v-vaporware-2019-06-23.markdown +++ b/blog/v-vaporware-2019-06-23.markdown @@ -1,8 +1,8 @@ --- title: V is for Vaporware date: 2019-06-23 +series: v tags: - - v - rant --- diff --git a/blog/v-vvork-in-progress-2020-01-03.markdown b/blog/v-vvork-in-progress-2020-01-03.markdown index a0d0def..e2aa54d 100644 --- a/blog/v-vvork-in-progress-2020-01-03.markdown +++ b/blog/v-vvork-in-progress-2020-01-03.markdown @@ -1,8 +1,8 @@ --- title: "V is for Vvork in Progress" date: 2020-01-03 +series: v tags: - - v - constructive-criticism --- diff --git a/blog/vlang-update-2020-06-17.markdown b/blog/vlang-update-2020-06-17.markdown new file mode 100644 index 0000000..0811cd7 --- /dev/null +++ b/blog/vlang-update-2020-06-17.markdown @@ -0,0 +1,260 @@ +--- +title: V Update - June 2020 +date: 2020-06-17 +series: v +--- + +# V Update - June 2020 + +Every so often I like to check in on the [V Programming Language][vlang]. It's been +about six months since [my last post](https://christine.website/blog/v-vvork-in-progress-2020-01-03), +so I thought I'd take another look at it and see what progress has been done in six +months. + +[vlang]: https://vlang.io + +Last time I checked, V 0.2 was slated for release in December 2019. It is currently +June 2020, and the latest release (at time of writing) is [0.1.27][vrelease0127]. + +## Feature Update + +Interestingly, the V author seems to have walked back one of their original +listed features of V and now has an [abstract syntax tree][ast] for representing the +grammar of the language. They still claim that functions are "pure" by default, but +allow functions to perform print statements while still being "pure". Printing data +to standard out is an impure side effect, but if you constrain the definition of +"side effects" to only include mutability of memory, this could be fine. + +[vrelease0127]: https://github.com/vlang/v/releases/tag/0.1.27 +[ast]: https://github.com/vlang/v/commit/093a025ebfe4f0957d5d69ad4ddcdc905a6d7b81#diff-5adb689a65970037f7f0ced3d4b9e800 + +The next stable release 0.2 seems to be planned for June 2020 (according to the readme); +and according to the todo list in the repo, memory management seems to be one of the +things that will be finished. V is also apparently in alpha, but will also apparently +jump from alpha directly to stable? + +## Build + +Testing V is a bit more difficult for me now as its build process is incompatible +with my Linux tower's [NixOS](https://nixos.org/nixos) install (I tend to try and +package all the programs I use for testing this stuff so it is easier to reproduce +my environment on other machines). The V scripts also do not work on my NixOS tower +because it doesn't have a `/usr/local/bin`. The correct way to make a shell script +cross-platform is to use the following header: + +```sh +#!/usr/bin/env v +``` + +This makes the `env` program search for the V binary in your `$PATH`, and will +function correctly on all platforms. + +The Makefile in the V source tree seems to do +network calls, specifically a `git clone`. Remember that this is on the front page +of the website: + +> V can be bootstrapped in under a second by compiling its code translated to C with a simple +> +> `cc v.c` +> +> No libraries or dependencies needed. + +Git is a dependency, which means perl is a dependency, which means a shell is a +dependency, which means glibc is a dependency, which means that a lot of other +things (including posix threads) are also dependencies. Pedantically, you could even +go as far as saying that you could count the Linux kernel, the processor being used +and the like as dependencies, but that's a bit out of scope for this. + +## Memory Management + +> V doesn't use garbage collection or reference counting. The compiler cleans +> everything up during compilation. If your V program compiles, it's guaranteed +> that it's going to be leak free. + +Amusingly, the documentation still claims that memory management is both a work in +progress and has perfect accuracy for cleaning up things at compile time. Let's run +my favorite test, the "how much ram do you leak compiling hello world" test. Last +it leaked `4,600,383` bytes (or about 4.6 megabytes) and before that it leaked +`3,861,785` bytes (or about 3.9 megabytes). This time: + +``` +$ valgrind ./v hello.v +==5413== Memcheck, a memory error detector +==5413== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. +==5413== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info +==5413== Command: ./v hello.v +==5413== +==5413== +==5413== HEAP SUMMARY: +==5413== in use at exit: 7,232,779 bytes in 163,690 blocks +==5413== total heap usage: 182,696 allocs, 19,006 frees, 11,309,504 bytes allocated +==5413== +==5413== LEAK SUMMARY: +==5413== definitely lost: 2,673,351 bytes in 85,739 blocks +==5413== indirectly lost: 4,265,809 bytes in 77,711 blocks +==5413== possibly lost: 256,000 bytes in 1 blocks +==5413== still reachable: 37,619 bytes in 239 blocks +==5413== suppressed: 0 bytes in 0 blocks +==5413== Rerun with --leak-check=full to see details of leaked memory +==5413== +==5413== For counts of detected and suppressed errors, rerun with: -v +==5413== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) +``` + +It seems that the memory managment really is a work in progress. This increase in +leakage means that the compiler building itself now creates `30,409,141` bytes of +leaked ram (which if i recall is actually a remarkable improvement). + +However, `hello world` seems to leak again: + +``` +$ valgrind ./hello +==13258== Memcheck, a memory error detector +==13258== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. +==13258== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info +==13258== Command: ./hello +==13258== +hello world +==13258== +==13258== HEAP SUMMARY: +==13258== in use at exit: 12,144 bytes in 14 blocks +==13258== total heap usage: 15 allocs, 1 frees, 13,168 bytes allocated +==13258== +==13258== LEAK SUMMARY: +==13258== definitely lost: 0 bytes in 0 blocks +==13258== indirectly lost: 0 bytes in 0 blocks +==13258== possibly lost: 0 bytes in 0 blocks +==13258== still reachable: 12,144 bytes in 14 blocks +==13258== suppressed: 0 bytes in 0 blocks +==13258== Rerun with --leak-check=full to see details of leaked memory +==13258== +==13258== For counts of detected and suppressed errors, rerun with: -v +==13258== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) +``` + +I'm not entirely sure how this happened, but here is the output of +`v -keepc hello.v`: https://git.io/Jfdsu. + +## Doom + +The [Doom](https://github.com/vlang/doom) translation project still has one file +translated (and apparently it breaks sound effects but not music). + +## 1.2 Million Lines of Code + +Let's re-run the artificial as heck 1.2 million lines of code benchmark from the +last post: + +``` +$ bash -c 'time ~/code/v/v main.v' + +real 7m54.847s +user 7m32.860s +sys 0m14.212s +``` + +This is a major improvement! It's cut at least 2 minutes off of the build time for +this incredibly contrived benchmark! Let's see how big the generated binary is: + +``` +$ du -hs ./main +179M ./main +``` + +This is identical to how big it was last time. Let's see how much ram it leaks: + +``` +$ valgrind ./main +==11773== Memcheck, a memory error detector +==11773== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. +==11773== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info +==11773== Command: ./main +==11773== +hello, 1 1! + +==11773== +==11773== HEAP SUMMARY: +==11773== in use at exit: 12,144 bytes in 14 blocks +==11773== total heap usage: 15 allocs, 1 frees, 13,168 bytes allocated +==11773== +==11773== LEAK SUMMARY: +==11773== definitely lost: 0 bytes in 0 blocks +==11773== indirectly lost: 0 bytes in 0 blocks +==11773== possibly lost: 0 bytes in 0 blocks +==11773== still reachable: 12,144 bytes in 14 blocks +==11773== suppressed: 0 bytes in 0 blocks +==11773== Rerun with --leak-check=full to see details of leaked memory +==11773== +==11773== For counts of detected and suppressed errors, rerun with: -v +==11773== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) +``` + +About what I expected. + +## Concurrency + +A common problem that shows up when writing multi-threaded code are +[race conditions][races]. Effectively, race conditions are when two bits of code try +to do the same thing at the same time on the same block of memory. This leads to +undefined behavior, which is bad because it can corrupt or crash programs. + +[races]: https://en.wikipedia.org/wiki/Race_condition + +As an example, consider this program `raceanint.v`: + +``` +fn main() { + foo := [ 1 ] + go add(mut foo) + go add(mut foo) + + for {} +} + +fn add(mut foo []int) { + for { + foo[0] = foo[0] + 1 + } +} +``` + +In theory, this should have two threads infinitely trying to increment `foo[0]`, +which will eventually result in `foo[0]` getting corrupted by two threads trying to +do the same thing at the same time (given the tight loops invovled). + +However, I can't get this to build: + +``` +================== +/home/cadey/.cache/v/raceanint.tmp.c: In function ‘add_thread_wrapper’: +/home/cadey/.cache/v/raceanint.tmp.c:1209:6: error: incompatible type for argument 1 of ‘add’ + add(arg->arg1); + ^~~ +/home/cadey/.cache/v/raceanint.tmp.c:1198:13: note: expected ‘array_int * {aka struct array *}’ but argument is of type ‘array_int {aka struct array}’ + static void add(array_int* foo); + ^~~ +/home/cadey/.cache/v/raceanint.tmp.c: In function ‘strconv__v_sprintf’: +/home/cadey/.cache/v/raceanint.tmp.c:3611:7: warning: variable ‘th_separator’ set but not used [-Wunused-but-set-variable] + bool th_separator = false; + ^~~~~~~~~~~~ +/home/cadey/.cache/v/raceanint.tmp.c: In function ‘print_backtrace_skipping_top_frames_linux’: +... +================== +(Use `v -cg` to print the entire error message) + +builder error: +================== +C error. This should never happen. + +If you were not working with C interop, please raise an issue on GitHub: + +https://github.com/vlang/v/issues/new/choose +``` + +Like I said before, I also cannot file new issues about this. So if you are willing +to help me out, please open an issue about this. + +--- + +Overall, V looks like it is making about as much progress as I had figured it would. +I wish the team luck in their work!