One of the new features I found interesting, declarations for global variables, is buried in the reference manual. Here's a link to the section that discusses it: https://www.lua.org/manual/5.5/manual.html#2.2
Strictly speaking, Lua is not global by default. All free names, that is, all names unqualified with `local`, is actually indexed from a table `_ENV`, which is set to `_G`, the global environment. So, all free names are effectively global by default, but you can change this behavior by put this line at the top of your file `local _G = _G; _ENV = {};`. This way, all free names are indexed from this new table, and all access to the global names must explicitly be accessed through `_G`, which is a local variable now. However, I have never seen such practice. Maybe it is just too complicated to accept that all free names are global variables and you have to explicitly make it local.
Thanks to Lua’s great metaprogramming facilities, and the fact that _G is just a table, another workaround is to add a metamethod to _G that throws an error if you try to declare a global. That way you can still declare globals using rawset if you really want them, but it prevents you from declaring them accidentally in a function body.
yeah. I hate typing `local` for every variable. I would prefer they introduce some syntactic sugar like `let`(to mean local variable) and `const`(to mean local and constant).
For me it's interesting because global variable declarations haven't been needed before, so why now? Also, I'm not sure `global` was reserved before, but now it seems to be.
The point now is so that if you use a `global` statement in your code, Lua will now error on misspellings of local variables when compiling, rather than defaulting to treat them as globals.
I love Organic Maps! I don't use it for driving, but I do use it regularly for hiking. It is reassuring to know that even if I don't have service I can open the app and can check to see if I'm still on the trail. Highly recommended! I'll have to try navigation sometime.
In addition to the other answers, this is the most logical way to handle most errors in this specific type of code. The http code in the Zig standard library doesn’t know how the programmer wants to handle all the errors, so it uses try to bubble up any error it doesn’t know how to handle.
Why so many uses of try? Because Zig is all about readability, and anytime you see try you _know_ that the called function can possibly fail.
Rust used to use the word try in a similar context, but was considered too noisy, and opted for ? instead, which I think worked out very well in practice.
Author here! I’m aware of the FZF search syntaxes. They are very useful! I designed zf to be a small tool that worked a bit better for me by default without special syntaxes.
Have you considered submitting this idea as a patch for fzf (like with a flag to switch syntax)? fzf author seems fairly strict/holding back about what goes in and what not, but it seems worth an attempt: thing is fzf can do a lot, is pretty well architected, many features are really neat, and it seems less work to patch it than to start from scratch.
No I hadn't considered that. I wouldn't be against my "zf algorithm" being ported to other tools though. But when I first had the idea for zf I had just learned Zig and it seemed like the perfect way to practice with my new language.
I’ve absolutely had satisfaction with my several personal projects written in Zig. And based on an imperfect measurement (GitHub stars) I have also had moderate success in making something useful. It’s a terminal fuzzy finder [0]. I also maintain a Zig Lua bindings package [1], and I’m working on a port of an old Macintosh game [2].
Zig is exactly what I want out of a language though, so take my opinion with a grain of salt :)
Zig is a very consistent language in syntax and semantics, so there are a small number of features I need to be concerned with. My understanding is that once Zig reaches a stable 1.0 the language will not change. Although there is a lot of churn right now, I appreciate the idea of a language that is simple, and stays simple.
The code is also very readable. I haven't found another language (yet) that I can just open up the standard library source code and understand just about everything. With no hidden control flow I can easily read a function and not have to question what a line of code does. Everything it does is right in front of me.
I also love that Zig is trying to fix many of C's problems. Rather than a global libc allocator, each function that can allocate (by convention) accepts an allocator as an argument. In my projects this has been really great for understanding what code paths allocate, which has made it easy to package my fuzzy finder as an allocation-free Zig module and C library.
Now, if I were working on a project with more critical safety requirements, I might consider a different language. But for most of my personal projects Zig is exactly what I need.
I did! I did the Google Summer of Code twice with Blender and ever since I find myself preferring the patch workflow of Phabricator over the merge/pull request found elsewhere. I am comfortable with both, but phabricator just clicked with me better
What was your experience like with GSOC? Gitea has applied to it this year, and are hoping to be able to make it a good experience for any contributor that is matched (hopefully we are accepted as well).
GSoC was a great experience. It was my first time planning a major contribution to an open source project. It would have been much more challenging for me without the help of my mentor and the other core contributors, so it is important to have a good support system for any involved.
My projects were focused on user interface improvements, so I also spent a lot of time gathering feedback from users. It was really valuable for me to learn how to get feedback at different stages of the development cycle, and also to learn how to filter the good from the bad feedback.
