Two new posts

.gitignore

@@ -1,2 +1,3 @@
 public/
 capsule.tar
+tags

content/gemlog/re_error_handling.gmi

@@ -0,0 +1,30 @@
+(
+    title: "Re: Error Handling",
+    summary: Some("Thoughts on error handling and algabraic data types."),
+    published: Some((
+        year: 2022,
+        month: 5,
+        day: 28,
+        hour: 14,
+        minute: 9,
+        second: 40,
+    )),
+    tags: [
+        "programming",
+    ],
+)
+---
+From nytpu's flight log:
+> I don't mind writing C—I actually enjoy it a lot of the time—but every time I use it I get more and more annoyed at it's error handling.  Looking at all the function bodies in this codebase I'm working on, ~20% of all the lines are solely checking return values for errors
+And then:
+> Honestly I don't really like exceptions either, I really prefer Hare and Zig's error handling that uses return values like C but isn't pure pain.
+=> gemini://nytpu.com/flightlog/
+
+I couldn't agree more. And I'm glad the Zig was among the languages pointed out as having a good system for error handling. I would go one step further and look at the implementation level to see what is actually going on "under the hood" here, and shine a light on Algabraic Data Types.
+
+## What's an Algabraic Data Type?
+At it's simplest, an enum is almost an algabraic data type. In C however enums are little more than an integer constant. If one looks at Zig's error handling, we see that errors are implemented as error unions. That is, the function is able to return either the intended return value or the error. Zig also has tagged unions, which in code look like an enum wrapping a union. This is what is really meant by the term Algabraic Data Types. A type that can be one of several things with a tag to determine unequivically what type it is
+
+Interestingly, Rust's enums work exactly the same if you ignore syntax, and are in fact a tagged union under the hood. And Rust's Result<T, E> is nothing more than this in implementation. I'm sure that you can make an error handling scheme without tagged unions, but to me the two concepts work so well together that no other implementation really makes sense.
+
+I've worked some in a lot of different languages now. Among them are old standards like C and Fortran, interpreted languages from their heyday such as Python and Php, and the new hotness of Rust, Zig, and most recently Hare. Algabraic data types are probably the one feature that I miss when it's not there.

content/gemlog/re_jazzmaster.gmi

@@ -0,0 +1,46 @@
+(
+    title: "RE Jazzmaster - my amplifiers",
+    summary: Some("Talking music gear"),
+    published: Some((
+        year: 2022,
+        month: 4,
+        day: 22,
+        hour: 15,
+        minute: 43,
+        second: 53,
+    )),
+    tags: [
+        "music",
+        "guitar",
+        "electronics",
+        "amplifiers",
+    ],
+)
+---
+I enjoyed reading Mieum's post about some diy upgrading of his guitar.
+=> gemini://rawtext.club/~mieum/music/2022-04-22-jazzmaster_pickguard.gmi Jazzmaster - Pickguard Replacement & Re-shielding
+
+I tend to collect hobbies, and I love diy. I've been playing guitar since I was about ten years old myself, and have often combined my love of music with other interests. In the spirit of diy, I thought I might share one of my guitar amplifiers.
+
+I've built four all vacuum tube (or valve, depending on which side of the pond you're from) based guitar amps, all designed from scratch. The first one was an experiment in cheapness, reusing a lot of parts from a cheap old record player, including the output transformer and 25L6 output tube. It was an ugly rats nest inside, and never really finished, but sounded way better than it had a right to.
+
+The second amp I called the "Miniplex". It was based around the transformers taken from a Carvin Vintage 16, which never really satisfied, but had a preamp topology very much like an early Marshall. This one was neater inside and out, but still not "finished" to a great standard. It sounded good enough that I took it to gigs occasionally. Probably about 18 watts of unrefined power that could pull off a great early rock vibe.
+
+Amp number three was an experiment in excess, seeing if I could pull off a modern high gain metal amp. It had a five tube preamp section and a single ecc99 output with the twin triodes in push pull mode. This one was a bit of a flop. It did the job if you dialed the gain way back, but there was just too much gain to control overall. I learned a lot though.
+
+The last one, and the actual subject of this post, is my still current daily driver. I completed this amp in 2010 and have been using it ever since. I wanted to strip it back to just the essence of what makes a great rock and roll tube amp, but with a couple of little tricks that I'd been wanting to try. It has a two stage 12ax7 preamp with a gain control between the two triodes, feeding into a 12ay7 long tailed pair phase inverter. There is an additional DC coupling path between the second stage and the phase inverter, allowing for the phase inverter to be smoothly overdriven without any blocking distortion. That's custom feature number one.
+
+The output is a pretty simple 6v6 push pull stage with cathode bias, very much like an early Fender Deluxe minus the negative feedback loop. It's got a 12ax7 tube based tremolo oscillator which bias modulates the output stage for some nice, swampy tremolo that sounds a lot like the old brown tolex era Fender amps.
+
+Trick number two is the post phase inverter master volume, allowing for the preamp and phase inverter to be fully overdriven at any volume and retaining a lot of the character of a fully cranked amp. This was the tricky part, because the tremolo modulation had to be applied in a way that did not interact with the master volume. What I came up with in the end, and which is to my knowledge something never done on a production amp (or any other amp I've ever seen) is to place a 50r resistor in between the normally grounded lug of the volume control and ground, and apply the tremolo at that junction. This only works because the oscillator tube uses it's second triode as a cathode follower buffer, which can easily drive that low impedence without much loss. It's a cool circuit.
+
+The chassis was custom fabricated from sheet aluminum by a fellow enthusiast out of Florida, and the cabinet is dovetail jointed pine. The speaker is a ten inch Alnico magnet Weber gifted to me by a good friend. This was the first amp I built that I consider professional quality, minus the fact that I never quite got around to having nice control panels made for it. But with only four knobs, a footswitch for the tremolo, and in and out jacks it's pretty easy to keep it all straight. I also never got around to spraying the finish on the back panels of the speaker cab, but that could be easily done still. The cab also has a split back panel and can be used as either a fully enclosed or open back cab.
+
+=> images/16w-front.jpg Front of the amp
+=> images/16w-side.jpg Side shot showing off the dovetails
+=> images/16w-back.jpg Back of the amp
+=> images/16w-back-detail.jpg Detail of the back
+
+I've used this amp for both at home practice and small gigs. It actually matched up really nicely with an old leslie cab that a friend of mine had, and it drives a 4x12 cab to painful volume levels. Since there's no tone stack, you're pretty much getting just the raw tone from your guitar. It's different than what most of us are used to hearing, as most guitar amps have a tone stack that automatically creates a scoop in the mids even with all of the controls set flat. But it's a more honest tone, and paired with a hot bridge pickup it's definitely not lacking in high end.
+
+I don't have any shots of the inside right now and the schematic only exists now on an old hard drive from an old laptop, which may or may not work now. I fully intended to follow up with more projects, but my personal life was blowing up around this time and money has been a problem ever since. I do have a number of schematics and layout drawings ready to go, and one of these days I'll be getting back to it. The next one up is a revisit of the 25L6 concept, but this time with DC coupling going to the output stage using a number of my own ideas including a twin voltage power supply.

content/gemlog/re_lagrange_and_bloat.gmi

@@ -0,0 +1,76 @@
+(
+    title: "Re: Lagrange and Bloat",
+    summary: Some("Some thoughts on Lagrange and software bloat"),
+    published: Some((
+        year: 2022,
+        month: 5,
+        day: 13,
+        hour: 16,
+        minute: 11,
+        second: 16,
+    )),
+    tags: [
+        "software",
+        "lagrange",
+        "programming",
+    ],
+)
+---
+There's quite a long thread going on it seems.
+On the one hand, we have this (on the Unix philosophy)
+> That said, Lagrange objectively breaks that pattern and therefore is subjectively starting to sound bloated, in my opinion. Don't get me wrong, like I said above, Lagrange is awesome. I use it every single day. At what point, though, should we stop to consider if it is following the same path to complexity as web browsers did? The root cause of that is more HTTP (Hypertext Transfer Protocol) itself, so at least we don't have that problem here in Gemini. That's my take, wholly from the perspective of looking at its feature list.
+
+=> gemini://ainent.xyz/gemlog/2022-05-07-critique-of-lagrange.gmi
+
+And then we have Skyjake's response, which I quite agree with.
+> I, too, deeply appreciate the Unix philosophy when it comes to system-level utilities and command line tools, but when it comes to GUI apps, and cross-platform ones at that, things get a lot less clear.
+
+=> gemini://skyjake.fi/gemlog/2022-05_bloat.gmi
+
+## In praise of Lagrange
+I'm writing my own smolnet client, but that has nothing to do with any perceived shortcomings of Lagrange. I actually use Lagrange quite heavily, and it has inspired a number of features in Eva. Skyjake is exceptionally modest in that he seems to think the Android port of Lagrange is not terribly great. My feeling is that it's already, even in pre-release form, the best client on Android. The fact that it runs cross platform is amazing, and a testament to fundamentally great programming, and the best that C has to offer.
+
+When I think of bloat, I don't count lines of code. When it comes to a gui application I'm looking for an interface that is simple enough to be easily discoverable. By that I mean that one should be able to install the application and start using it without reading a manual first. You don't generally use all of the application's advanced features this way, at least not at first, but we've probably all been frustrated before by a dense user interface with endless heirarchical menus and multiple toolbars that might be incredibly powerful, but makes it impossible to fire it up and just go to work.
+
+Lagrange most definitely does NOT have that problem.
+
+## On lines of code
+* C is one of the more verbose languages to begin with, as it does not have the abstractions that a lot of more modern languages take for granted.
+* 10k lines of code really isn't that much (for waht you get)
+* Gui programs are necessarily more complex.
+* Multi platform applications are even more complex.
+
+As a comparison, at it's current state Eva is 3197 lines of code, and the underlying GemView library is another 2366 LOC. That's over half of Lagrange already, aaannnddd...
+* Gtk+ is doing a lot of the heavy lifting.
+* Eva doesn't have the feature set that Lagrange does (although it's steadily becoming more capable).
+* Eva is only theoretically cross platform at this point. I develop it on Linux and have tested it on FreeBSD. It will most likely run on MacOS and Windows if one were to compile Gtk+ first. Android and IOS support will probably never happen.
+* I'm not even counting any other Rust crates in that total. Adding my Rgba-Simple crate adds another 729 LOC, and I'm fairly liberally using a number of crates that I didn't author myself. I suspect that all told it's already beefier than Lagrange.
+
+## On the Unix philosophy
+I think that the Unix philosophy is not a great goal for graphical applications. I've been in the Unix world for over 20 years now, and my feelings on the Unix philosophy have evolved in that time. Let's remember that we've had 50 years of progress in the interim. Gui applications were not taken into account in 1970. Storage was tiny and expensive. The importance that networking would come to play was not yet understood. Finally, and this is important, Unix was invented by really smart nerds who do not represent the average person's ability.
+
+I think Benno Rice makes some great points in his talk, "What Unix cost us". Sorry for the evil site link, but the other places I've seen it posted have teriible bandwidth in comparison.
+=> https://www.youtube.com/watch?v=9-IWMbJXoLM
+
+Benno is a long time FreeBSD contributor and Unix expert. I don't always agree with him, but I do agree that things can and should evolve. It turned out that Unix made a grreat base for an operating system and has managed to continue to work well for us for a much longer time than anyone expected, but we can and should move things forward from time to time as we find new ways of doing things. If we only ever look back, and tie ourselved rigidly to old ways of doing things, we slow or even stop progress.
+
+## What I really love about Unix
+In over 20 years time using Unix and it's clones I've made some discoveries. The Unix philosophy is all right, but it's not the best thing about Unix. It's not even in my top ten anymore. More so than the Unix idea of small and simple modular programs, I appreciate the following (in approximately this order).
+* Open source is a better development model. Sure, there's been proprietary Unix systems. They're all dead now, while Linux and BSD live on.
+* The Unix filesystem is worlds better than Windows. Windows has to maintain a registry to know where the executables and libraries are, while on Unix we have known paths that we can just drop those components into. Over the years we've expanded on that to include things like standard configuration folders, architecture inependent data files, etc.
+* User and group priviledge separation was baked in from the start.
+* Development as a use case is a first class citizen on Unix. To develop for Windows or Mac you are encouraged to get and use proprietary tools and sign a bunch of EULA's. And you can't read the source, so you have to just trust the API docs they give you.
+* If you don't like the interface, you're free to install a different one or write your own.
+## On complexity
+Complexity has become a dirty word in certain circles. But I want to point out that it is sometimes justified, and sometimes in fact necessary.
+
+I've programmed in a number of different languages. I can do a bit with C, but I prefer Zig and most of all Rust. I've given oldschool languages like Fortran a go, and tried out Hare the day after Drew Devault announced it. My strong preference for Rust is because the language has managed to find a way to allow you to write close to the metal while using a lot of high level abstractions. Hare does not have generics. Neither do Fortran or C. I want my algabraic types (enums and tagged unions) and I want a strong type system that enforces code correctness.
+
+I think C++ fails not due to complexity, but due to attempting to retrofit those concepts onto an existing language. It wasn't really designed but rather haphazardly grew as more and more bits were added. Some of those bits were mistakes, but they left them in after coming up with a replacement because hey, someone might be using them. It's messy. Rust and Zig, in comparision, feel engineered. Sure they're more complex, but the complexity is there to enable you to write less verbose and better organized code that is easier to maintain. You are forced to consider corner cases and failure modes, leading to more reliable software.
+
+I'm a big fan of the Ford flathead V8. I've seen one that was locked solid fixed with a sledgehammer. That said, they made very little power and used a lot of gas. You had to take the heads off from time to time to de-coke the cylinders. Cracked blocks were common due to the way the exhaust routes through the block. My F150 has an aluminum block with steel cylinder liners and overhead camshafts. It also has close to 200k miles without a rebuild and is not only more powerful than a flathead but gets better gas mileage. I can deal with the additional complexity because what you get in return is a better experience all around.
+
+Nostalgia causes us to look back on old technologies with the proverbial rose tinted glasses. But if we want to build and use the best tools going forward it pays to evaluate things with a more critical eye. Complexity can be bad if an engineer is overreaching and delivers something that is less refined as a result of that complexity, but overly simplified programs tend to create more complex workflows.
+
+## Conclusion
+I can see both sides of this. At one time I would have been the guy talking about "simple programs that only do one thing". But really, until you actually write a simlilar program you're not in a great position to evaluate the decisions that went into writing something like Lagrange. My hat's off to Skyjake, because he has given us a remarkable piece of software in Lagrange. It sets a high bar, and has been a great source of inspiration for me when writing my own client.

content/software/eva.gmi

@@ -52,6 +52,7 @@ Eva is currently alpha quality software and is under heavy development. Some fea
 
 ## Keybindings
 > Note: See KEYS.md for information on changing keybindings
+```
 | Key           | Action            |
 | ------------- | ----------------- |
 | Ctrl/T        | New tab           |
@@ -71,7 +72,7 @@ Eva is currently alpha quality software and is under heavy development. Some fea
 | Ctrl/S        | Save Page         |
 | Ctrl/Shift/P  | Open preferences  |
 | Ctrl/Shift/A  | Open about dialog |
-
+```
 ## Installing
 ### Arch Linux
 Install the eva-browser package from the aur. Alternatively, beginning with the 0.3.0 release, releases on Codeberg and Github include an Arch PKGBUILD file.

public/software/eva.gmi

@@ -76,6 +76,12 @@ cargo build --release
 cargo xtask dist
 ```
 
+### Tags for this page
+=> ../tags/software.gmi software
+=> ../tags/eva.gmi eva
+=> ../tags/rust.gmi rust
+=> ../tags/gtk.gmi gtk
+
 => .. Home
 All content for this site is released under the CC BY-SA license.
 © 2022 by Nathan Fisher