absolutely_vivid

joined 1 year ago

It is now lol

I'm bad at naming things, so it was originally GHA (for github archiver, changed to good helpful archiver because trademark), but I kept misspelling it as GAH so it was just easier to change the name.

But the reference is way better :P

[–] absolutely_vivid@programming.dev 2 points 2 days ago* (last edited 2 days ago)

You're right! In hindsight I probably should have change the title when I cross-posted here πŸ˜…

Yeah, microsoft has owned github since 2018. I made this to help people and organizations move off of github, onto something like forgejo or sourcehut. But even after moving, all of those old issues, pull requests, comments, those need to live somewhere. A lot of people seem to use a script to recreate all their issues on their new code host, but that loses a lot of metadata and can only work if there's a script for your new chosen host. Everyone else just archives the repo and leaves all that info there, which is great until people forget its there, or microsoft decides to start charging for issue hosting.

So now, with GAH!, people can more easily move away from github, they don't need to worry about what happens to their issues and PRs. It's one less barrier to leaving github :)

 

cross-posted from: https://programming.dev/post/42508495

Issue and PR threads are invaluable documentation for a project, it's difficult to migrate to another code host when years of knowledge are locked into your old hosting service. So I built a couple of scripts to archive issues, pull requests, comments, and source code from github repositories, and to turn them into static sites! With the accelerating exodus away from github, I've heard from a lot of people that there aren't any good tools for archiving that knowledge in a human-readable format, so I thought this would be a useful tool to make. The initial release is ready, and just in time for github to start charging for self-hosted runners!

If you try it out, let me know what you think. There's definitely areas that can be improved on :)

 

cross-posted from: https://programming.dev/post/42508495

Issue and PR threads are invaluable documentation for a project, it's difficult to migrate to another code host when years of knowledge are locked into your old hosting service. So I built a couple of scripts to archive issues, pull requests, comments, and source code from github repositories, and to turn them into static sites! With the accelerating exodus away from github, I've heard from a lot of people that there aren't any good tools for archiving that knowledge in a human-readable format, so I thought this would be a useful tool to make. The initial release is ready, and just in time for github to start charging for self-hosted runners!

If you try it out, let me know what you think. There's definitely areas that can be improved on :)

 

Issue and PR threads are invaluable documentation for a project, it's difficult to migrate to another code host when years of knowledge are locked into your old hosting service. So I built a couple of scripts to archive issues, pull requests, comments, and source code from github repositories, and to turn them into static sites! With the accelerating exodus away from github, I've heard from a lot of people that there aren't any good tools for archiving that knowledge in a human-readable format, so I thought this would be a useful tool to make. The initial release is ready, and just in time for github to start charging for self-hosted runners!

If you try it out, let me know what you think. There's definitely areas that can be improved on :)

11
submitted 8 months ago* (last edited 8 months ago) by absolutely_vivid@programming.dev to c/rust@programming.dev
 

I built a library for working with a compression format used by Godot. It’s my first Rust library and I thought the little bit of reverse engineering I did for the format would make for an interesting blog post. Let me know what you think!

(Reposting because I still don't know understand the lemmy UI lol)

Oh hi, I forgot to reply to this!

My reasoning was mostly "I read it somewhere when I started coding and then didn't do much with threads" to be honest. Not great reasoning there. But modeling the interactions between a user, UI thread, and work thread made it a lot easier to organize my code and create a good separation of concerns; the UI thread handles interface updates and dispatching events, and the worker thread works. Honestly that code organization was the biggest advantage I got out of doing things this way, and I wish I'd emphasized that more in the blog post.

 

I wrote a quick blog post about a pattern I discovered while building TUI applications in Rust. It's a bit unrefined, and I'm working on package to help make the pattern easier. Let me know what you think!