Nice!
I always wanted to build an XSLT that parses Markdown and outputs HTML, but was lacking the time. That would elevate your blog framework to a wider audience.
The README covers the idea behind errtrace in more details, but the primary difference is in what is captured:
pkg/errors captures a stack trace of when the error occurred, and attaches it to the error. This information doesn't change as the error moves through the program.
errtrace captures a 'return trace'--every 'return' statement that the error passes through. This information is appended to at each return site.
This gives you a different view of the code path: the stack trace is the path that led to the error, while the return trace is the path that the error took to get to the user.
The difference is significant because in Go, errors are just plain values that you can store in a struct, pass between goroutines etc. When the error passes to another goroutine, the stack trace from the original goroutine can become less useful in debugging the root cause of the error.
As an example, the Try it out section (https://github.com/bracesdev/errtrace/#try-it-out) in the README includes an example of a semi-realistic program comparing the stack trace and the return trace for the same failure.
Judging by the project, it's implemented by instrumenting the source code; either manually modifying error returns with a wrapper function, or by running source files through an automated tool that will find and modify the return statements for you.
It’s archived mainly because it’s been superseded by fmt.Errorf() with the %w directive. Go 1.20 also introduced errors.Join() and multi-%w which github.com/pkg/errors lack, so using for green field projects is very ill-advised.
It’s pretty easy to write your own Errorf() wrapper or some sort of WithStack() that stores runtime/debug.Stack() output. github.com/pkg/errors offers more flexibility in formatting though.
Well, sure, but by that metric this library is even easier to build yourself since it's only gathering a single stack entry per wrap. And it has no backwards compatibility to worry about.
"You can build X by hand too" has little to do with why people choose to create or use libraries.
My implementation is about 120 lines, plus about 100 lines of tests. It's not hard, but not trivial either. Doing that for every single project is rather tedious. Especially for prototyping I just quickly want something that 'just works' without fuss.
The same way you get stack traces of names, email addresses, random numbers, etc. It is funny how the word 'error' leaves some suddenly forgetting how to write software.
A good internet connection. I had troubles in the past and got a second internet line with LTE. I setup automatic fallback and never had problems since then.
Somebody already developed an obsidian online version?
I know that there are plenty but they all use their own database to store the data and not the good old filesystem.
Anyone has an alternative where I can use simple markdown files (in a folder or google drive) as the primary datasource?
I am using obsidian on the Mac, but on the go I have no real solution. (I want to avoid using the obsidian mobile app because it forces you to use Obsidian Sync)
You need to use Obsidian Sync if you have an iPhone. IIRC it’s because the third-party storage APIs are limited on iOS in such a way that makes it non-feasible for Obsidian. Something about bulk editing/access.
I don’t see a usecase where a non dev should expose some local resource to the internet.
These people don’t run local webservers, nor know how they work.
ngrok is a developer tool. I don’t see why marketing a dev tool to non devs is a good idea, maybe somebody can explain?
What makes this seem like a non-developer tool? You need a server you control, you need to mess with YAML files, "configure Caddy" is one step that's assumed to be easy, etc.
Why?
Stable subdomains and SSO are two things too expensive.
Why not just pick one from the Awesome Tunneling? Think broader. Not everyone is a dev who knows about server operations. For people working as community managers, sales, and PMs, booting up something locally could already be a stretch and requiring them to understand how to set up and fix server problems is a waste of team's productivity.
> Not everyone is a dev who knows about server operations. For people working as community managers, sales, and PMs, booting up something locally could already be a stretch and requiring them to understand how to set up and fix server problems is a waste of team's productivity.
Oh, I read that as "you can send the links to community managers, sales, and PMs rather than making them run the app locally," since that's like, the main usecase.
I've heard of people wanting remote access to things like Plex or security cameras hosted in their basement. Usually via VPN, but I could see someone using this kind of thing.
