<sdomi>
zenen: happy to hear you're enjoying it :3
<sdomi>
the templating engine is pending a rewrite. it works (and I like it!) but it leaves some to be desired
<sdomi>
tbh don't want to pull in external dependencies, both due to code quality (although mo doesn't look the worst) and performance (here I can at least refactor it and make it better)
<zenen>
Yea, I totally understand the external dependencies thing. I thought it might be worth it considering it's all held in a single file. In some ways I'm just being selfish because it's the same templating language that I use for everything
<zenen>
but code is art, and I will not be the person to try and tell you how to do your art :)
<sdomi>
FWIW this parser is my first experience writing templating engines, and *almost* my only experience with templates in general. I might have caught a glimpse of templates beforehand, but it's all written as a solution to a problem I had
<sdomi>
very little inspiration from the outside
<zenen>
okay! well, what lessons have you learned that you plan on integrating into the next iteration?
<sdomi>
(also, the base was written in 2.5 hours in an overcrowded train from Poznań to Warsaw coming back from an anime convention. I was literally sitting on the steps of an exit door and needed a distraction XD)
<sdomi>
zenen: naming is probably the biggest part, I wish I chose something else than {{start _asdf}}...{{end _asdf}}, this looks messy
<sdomi>
the nested_declare / nested_add is messy. I have an idea on how to integrate this more directly, resulting in a nicer interface
<sdomi>
from less user-facing parts... well, sed is a pain. not sure how I'm gonna replace this yet
<sdomi>
btw: i have 3/4 of it reimplemented in rust, for integration as a bash submodule through rusht
<zenen>
I was writing the library for config files (and just generally BASHing about), so I didn't consider the longer expressions
<sdomi>
not the same thing as yours, but it does a similar thing
<zenen>
while shift; do
<sdomi>
the first alias is a generic thing for parsing params, in a format `{ search_param column } { another_search }` (omitting the column sets it to 0)
<zenen>
very elegant
<sdomi>
i'm genuinely proud of the "new" notORM call syntax. it makes sense in my brain
<zenen>
this fellow is posting a bash project every day, http.sh was the topic today
<zenen>
I have a Tildes invite for you if you want to comment
fossdd[m] has joined #http.sh
<fossdd[m]>
oh neat
<zenen>
sdomi: are you referring to the data_add and data_get functions?
<sdomi>
zenen: add, get, yeet and I think replace
<sdomi>
i want to migrate all functions from there to the new interface but didn't finish it yet
<sdomi>
fossdd[m]: o/
<Maja_>
zenen: god i hate how the top comment goes no-true-scotsman about the fact that http.sh uses ncat to do the listening, and links to some other project that claims to be "pure bash"... and instead fucking patches bash to add more builtins
<Maja_>
like, c'mon
<sdomi>
Maja_: idk, my brain tells me that they have a point and they're right with the "true programmers write in pure bash" remark ,_,
<sdomi>
i may be in a shit mood tho
<sdomi>
altho, the last comment about maturity was nice to read
<Maja_>
they literally didn't do it in pure bash either
<fossdd[m]>
haters gonna hate
<sdomi>
i mean, you *can't* do it in pure bash
<sdomi>
the closest you could get would be to write a compiler in bash, output a loadable .so, enable -f that file and use it to open the listening socket
<sdomi>
at least, in my opinion that's the "closest"
<zenen>
yea I mean, I decided not to comment but I think socat is a pretty great dependency to have
<sdomi>
if you look at the logs of this channel from a few days back (see topic), I actually ranted about socat and ncat
<sdomi>
we're working around multiple bugs in upstream tools at this point :v
<zenen>
i've never really looked into ncat
<zenen>
i'm only familiar with socat as the tool I use to proxy ssh through tor as a server backdoor
<fossdd[m]>
lol
<zenen>
my own servers!
<fossdd[m]>
pleeease dont hack mee /j
<sdomi>
hah, valid
<zenen>
should clarify. I run stuff behind NATs and you never know when an ISP might change your WAN IP
<zenen>
but tor... tor never changes
<fossdd[m]>
thats actually a cool solution without ddns
* sdomi
just wrote a DynDNS implementation for this purpose
<Maja_>
i'm just a boring tailscale user
<Maja_>
oh, concept, tailscale-compatible thingie, in bash
<Maja_>
idk, probably doesn't make sense
<zenen>
I <3 bash, but I don't really consider it a general purpose language
<zenen>
don't ban me
<zenen>
If you're going to use tailscale, why not learn wireguard instead?
<zenen>
wg is a great tool
<Maja_>
i'm kinda assuming that tailscale is basically a wrapper around wg
<fossdd[m]>
it is kinda, with a lot more features packed in
<fossdd[m]>
and a public central server
<sdomi>
i'm using raw wg, it's fine™
<sdomi>
wrt tailscale - there's headscale and i heard it's good. no motivation to write my own thing
<fossdd[m]>
im a wg-quick user, but want to migrate everything to networkmanager so bad
<zenen>
yea I am also no expert
<zenen>
I think I could revisit now, with a bit more networking experience
<zenen>
but i just kind of hacked my way through wg-quick last time
<zenen>
oh shit, you could use the tor bridge to establish a wg connection
<zenen>
!!
<zenen>
then you don't have to deal with the slow-ass 3-hop mechanism
<sdomi>
wg-quick automated with openrc here
<sdomi>
it just works. i don't see a reason to migrate to anything else
<zenen>
i'm strugglin with init systems these days
<zenen>
trying to decide if I care enough to fight the uphill battle against systemd
<zenen>
but i'm currently running sysVinit on my laptop and learning cron better