Ziglings executable?

[ratfactor]

The original ziglings "driver" was a simple Bash script.

Using the build system is really cool because:

1. It's cross-platform. Wherever Zig runs, Ziglings runs.
2. It shows off the build system (in fact, it's been a stress-test for the build system since the very beginning, resulting in upstream fixes to Zig).

However, I think it's also safe to say that by trying to accomplish a good Ziglings experience with the build system has been like playing in hard mode. (Maybe it's not as hard as writing Advent of Code solutions in a Makefile, but it's pretty hard.)

Can we just make a ziglings.zig that compiles when you run build zig and runs immediately?

Not only would we have completely control over the "normal" learner experience, it would also make additional options and tooling much easier:

1. Running specific exercises
2. Applying patch files/testing. I don't think we even need patch because our use case is so simple: Replacing whole lines - we don't even need line numbers, just find-and-replace.
   (Honestly, I've stopped even using the gollum script recently because it was less work to just write the patch by hand. This would be even easier if we didn't have line numbers at all.)
3. Maybe watching files for changes? (Rustlings, my inspiration for Ziglings, has this feature: rustlings watch)

To be clear: I'm deeply grateful for the astounding amount of work that has gone into making the build.zig file do as much as it does. I think that effort would produce a pretty awesome stand-alone executable!

[perillo]

@ratfactor Recently I was thinking of writing a ziglings.zig program for fun.

I'm also interested in how the patch files are created.

Should ziglings follow the same UI as https://github.com/rust-lang/rustlings?

[perillo]

One problem is how avoid confusing the users if there are both the build.zig and ziglings.zig files.

[ratfactor]

@perillo

Rustlings

I think we can definitely look at Rustlings for UI inspiration. But I'm not at all concerned about trying to emulate it. We can do whatever works best for us.

build.zig vs ziglings.zig

The README will need to make it clear what to do to get started. We can also put big comments at the top of both files as needed.

The goal is whatever we think would be the clearest and simplest thing for the learner. Can we have the ziglings executable end up in the root dir? Then the beginning steps could be:

zig build
./ziglings

Followed by just ziglings after that.

I'm very open to suggestion.

Patches:

Originally, the patches were created by copying the broken exercise into a directory called answers/ (ignored by Git) and fixing them. Then I would just do simple diff exercises/X answers/X > patches/patches/X.

The gollum.sh script does pretty much exactly that.

(For my own convenience, I also have two Bash aliases locally: zlg to run gollum.sh and zle to run eowyn.sh from the root of Ziglings.)

Along with the original ziglings Bash script, the patches made use of existing Unix tools so I could get everything working as quickly as possible.

Creating proper patch files for the canonical patch utility is not important. If we had a stand-alone ziglings executable, we could put simple find/replace instructions right alongside the expected output.

[perillo]

@ratfactor

build.zig vs ziglings.zig

My initial concern is what to do with the current build.zig. Should we remove it, or should we keep it in is some directory?

As for the bootstrap problem, it is possible to specify the install_prefix directory from the build.zig file (equivalent to the -p option.

A different approach to build + exec it to use ziglings.zig as a driver:

1. Spawn zig build install
2. Spawn the executable (the source code is in src/main.zig)

The advantage is that

1. The executable will always be up-to-date
2. The user will just need to zig run ziglings.zig
3. ziglings.zig can also optionally spawn the old build.zig file, translating the command line arguments
4. The ziglings.zig program can check the Zig compiler compatibility
   The source code is very small, since the real work is done else were.
   This means that we no longer have to be careful about breaking the compatibility and making the code less readable because we can't use the multi-object for loop.

The disadvantage is that this is not the usual workflow for a Zig project.

[perillo]

I forgot about patches.

@ratfactor wrote that he wold like to remove the use of diff and patch and I agree, since it will make it possible to use Windows Powershell, instead of bash.

The problem is how to heal exercises.
In almost all cases, the broken fragment is marked by ???, but exercise 001 is an exception. This means that we can't use ??? like the POSIX shell $.

A possible solution is to save (in Exercise.heal?) both the broken line and the correct one. But what if the line is modified or if there are more than one broken line? The patch command was implemented to handle possible fuzzy data.

About patche creation, I would first create the exercise in answers and then copy it to exercises and break it.

[chrboesch]

Running specific exercises

👍
Then it should be easy to store the last solved exercise for a faster run.

The disadvantage is that this is not the usual workflow for a Zig project.

In fact, I see this as somewhat problematic, because Ziglings as a programming tutorial currently conveys "real" compilation feeling.

Applying patch files/testing.

I do not know if it is necessary, because it will only used from a) exercise developer and b) our test scripts.

About patche creation, I would first create the exercise in answers and then copy it to exercises and break it.

That's how I always work.

Maybe watching files for changes?

There is a guy who wrote recently one: https://github.com/Jonxslays/zwatch