home.social

Search

167 results for “nobodyinperson”

  1. RE: fosstodon.org/@nobodyinperson/

    Okay as it's such a hassle to get a working going on , I made this flake so you can use this command to launch Spyder with your desired packages available:

    > nix run git+codeberg.org/nobodyinperson/ni numpy scipy pandas matplotlib ...

    EDIT: 👆 And Mastodon still can't do Markdown, so it wrecks the displayed link. If you copy-paste it, it should be correct though.

    More info here:

    codeberg.org/nobodyinperson/ni

  2. @nobodyinperson

    I'm open to recommendations if you have them.

    I've gotten vdirsyncer working bidirectionally between #orage and Google Calendars. That's nifty and was "easy" after setting up Google CalDAV API. So that's kinda cool, I guess.

    Although, I've also learned this week that:
    - Google Calendar will drop and does not support VTODOs
    - vdirsyncer is apparently in the process of being deprecated for pimsync 😡 (whynothugo.nl/journal/2026/04/)
    - Neither of these will probably work well with Proton Calendar
    - The local TODO app that I like & have been using for the past 3ish weeks (GTG) seems mostly abandoned & sync is borked(possibly due to the VTODO issue?)
    - The NextCloud trial instance I'm using doesn't seem to support the QOwnnotesAPI(I've been using QOwnnotes to help organize my .md documents starting this year and was curious about using its TODO functionality).

    Seems that I've just made some poor lifestyle choices.... 🤣

    #CalDAV

  3. TIL that some servers just silently ignore your precious X-whatever fields 😑

    Well I guess I'll have to teach caldav-event-pusher¹ to first check which fields survive an event upload...

    ¹gitlab.com/nobodyinperson/cald

  4. @nobodyinperson Wonder if there is a #FUSE that allows you to mirror writes to multiple parent mounts.

  5. hasn't been updated for a decade, yikes. But apparently it's still the *only* available statically servable (i.e. no database / no PHP / whatever) web client out there. 😱

    The code is also... interesting. There's so much hard-coding going on, but maybe that's how you do web dev 😅 I made a package you can override with some useful options such as increasing the animation speed and allowing vCard 4.0 support.

    gitlab.com/nobodyinperson/yann

  6. I noticed that the aarch64 git annex standalone build test suite (emulated on NixOS under x86_64) is *far* slower than the the nixpkgs-provided one:

    > nix run nixpkgs#legacyPackages.aarch64-linux.git-annex test
    # ... takes ~8min

    > nix run gitlab:nobodyinperson/yannix#packages.aarch64-linux.git-annex-standalone test
    # ... takes ~35min

  7. @nobodyinperson I'm asking you first because involving #gitannex would be high on my priority list. Really this wouldn't need to be #hledger specific as it could just as well be paired with #ledgercli or #beancount either directly or via CSV or whatever. I'm not a huge GitLab fan these days but can do it if you prefer. Codeberg seems more aligned or GitHub having the advantage of contributor pool. Thoughts?

  8. @nobodyinperson @musicmatze Is there somewhere you'd like to start collaborating on a project related to this? I just did some tests with local ollama and the glm-ocr model and there is some promise here, but getting a full workflow together for ingesting scans, handling intermediate artifacts, extracting bits using a multi-modal LLM or any other tooling, then generating CSV or ledger transactions or whatever is a lot of moving parts. Any other #plaintextaccounting folks want to tag along?

  9. More radicale goodness on :nixos: NixOS: services.radicale.git can now sync regularly and on change via radicale with multiple remotes. Currently, it'll prioritise the remote's state in case of conflicts. It's so amazing to have a git history of your calendar and addressbook! 🤩

    gitlab.com/nobodyinperson/yann

  10. services.radicale.git.enable=true now makes nicer commit messages, for events and contacts it will list the name and even describe renames. Proof of concept, written in bash/awk. It'll be hard to write a diff-parser that covers all kinds of changes, I guess having a local LLM could do it, but it'd slow down radicale significantly.

    gitlab.com/nobodyinperson/yann

  11. Organising my :nixos: code and splitting out sharable things into a separate repo. Here for example is my package for (:forgejo: + :gitannex: support) with a couple of my patches applied:

    gitlab.com/nobodyinperson/yann

    > nix build --refresh gitlab:nobodyinperson/yannix#forgejo-aneksajo
    > result/bin/forgejo -v
    forgejo version 13.0.3-git-annex2 built with go1.25.4 : sqlite, sqlite_unlock_notify

  12. My very first programming projects when I started self-teaching around 15 years ago were about accounting. I was unhappy with keeping track of expenses in a physical notebook, and the spreadsheet I made was also very limited. And existing solutions like felt too weird for my use case and its budgeting/forecasting approach was also an especially bad experience. After several funny PHP-based approaches I eventually made simbuto, the simple budgeting tool.

    gitlab.com/nobodyinperson/simb

  13. Had to switch back to base C++ #nix from #lix to package :hledger: #hledger's prebuilt release version, because lix still has an annoying builitins.fetchTarball bug¹ that prevents using tarballs that just contain a bunch of files without an extra single directory at the top level. (As you know, tarballs only EVER contain a top-level directory and never just a bunch of files, right?). In #cppnix it's already fixed.

    ¹git.lix.systems/lix-project/li
    ²github.com/NixOS/nix/pull/1119
    ³gitlab.com/nobodyinperson/nixc

  14. Had to switch back to base C++ from to package :hledger: 's prebuilt release version, because lix still has an annoying builitins.fetchTarball bug¹ that prevents using tarballs that just contain a bunch of files without an extra single directory at the top level. (As you know, tarballs only EVER contain a top-level directory and never just a bunch of files, right?). In it's already fixed.

    ¹git.lix.systems/lix-project/li
    ²github.com/NixOS/nix/pull/11195
    ³gitlab.com/nobodyinperson/nixc

  15. Had to switch back to base C++ #nix from #lix to package :hledger: #hledger's prebuilt release version, because lix still has an annoying builitins.fetchTarball bug¹ that prevents using tarballs that just contain a bunch of files without an extra single directory at the top level. (As you know, tarballs only EVER contain a top-level directory and never just a bunch of files, right?). In #cppnix it's already fixed.

    ¹git.lix.systems/lix-project/li
    ²github.com/NixOS/nix/pull/1119
    ³gitlab.com/nobodyinperson/nixc

  16. Had to switch back to base C++ #nix from #lix to package :hledger: #hledger's prebuilt release version, because lix still has an annoying builitins.fetchTarball bug¹ that prevents using tarballs that just contain a bunch of files without an extra single directory at the top level. (As you know, tarballs only EVER contain a top-level directory and never just a bunch of files, right?). In #cppnix it's already fixed.

    ¹git.lix.systems/lix-project/li
    ²github.com/NixOS/nix/pull/1119
    ³gitlab.com/nobodyinperson/nixc

  17. Had to switch back to base C++ #nix from #lix to package :hledger: #hledger's prebuilt release version, because lix still has an annoying builitins.fetchTarball bug¹ that prevents using tarballs that just contain a bunch of files without an extra single directory at the top level. (As you know, tarballs only EVER contain a top-level directory and never just a bunch of files, right?). In #cppnix it's already fixed.

    ¹git.lix.systems/lix-project/li
    ²github.com/NixOS/nix/pull/1119
    ³gitlab.com/nobodyinperson/nixc

  18. I find it rather weird that defining your :nixos: machine in your flake via `inputs.mynixpkgs.lib.nixosSystem` is *not* enough to have it actually use your `mynixpkgs`. No, you need to do this boilerplate stunt. Why doesn't it do it automatically? 🤔

    gitlab.com/nobodyinperson/nixc

  19. @rahix @sowa While we're at it, you could also give my fork a try. It's much simpler than and has even more powerful fillets, chamfers and smooth operations. STL only output amd sharp edges are a bit jagged, but the underlying code and maths is understandable and hackable.

    gitlab.com/nobodyinperson/sdfc

  20. @nobodyinperson maybe use a tool like #Colmena or #DeployRS to do the heavy-lifting on another node, so all the store objects will be pushed remotely to the Pi's store and all that's left to do for it is to run the activation script?

    #NixOS #RaspberryPi

  21. @nobodyinperson maybe use a tool like #Colmena or #DeployRS to do the heavy-lifting on another node, so all the store objects will be pushed remotely to the Pi's store and all that's left to do for it is to run the activation script?

    #NixOS #RaspberryPi

  22. @nobodyinperson maybe use a tool like #Colmena or #DeployRS to do the heavy-lifting on another node, so all the store objects will be pushed remotely to the Pi's store and all that's left to do for it is to run the activation script?

    #NixOS #RaspberryPi

  23. @nobodyinperson maybe use a tool like #Colmena or #DeployRS to do the heavy-lifting on another node, so all the store objects will be pushed remotely to the Pi's store and all that's left to do for it is to run the activation script?

    #NixOS #RaspberryPi

  24. @nobodyinperson maybe use a tool like #Colmena or #DeployRS to do the heavy-lifting on another node, so all the store objects will be pushed remotely to the Pi's store and all that's left to do for it is to run the activation script?

    #NixOS #RaspberryPi