Is shell script still the best way?
@RobinHirst11 I wonder if maybe we should consider rewriting the core in Python. Might be a performance gain.
To re-do this, Iβd probably:
- Rewrite the dwmbar executable in python and make it async
- Make sure it still supports the old modules method
- Implement a new yaml- or json- based module definitions system
I might set up a dwm install in a VM and spin up a second branch to try this out myself. Would you be interested in testing it out if I do?
I like this idea... Could also mess around with C π
Can make a VM on my homelab if needed, available 24/7 via SSH or web.. whatevers easiest for you
I often have my VMs and containers at
https://vm.robinhirst.qzz.io/
i feel like the bottlenecks aren't the language... more the modules..
python only really helps with the parallelization and state management...
the only real improvements to be made here is to implement parallelization with incremental updates.. with each module running in the bg independently
Yeah - that was sort of my idea. An Async core makes things faster.
I don't think it would be too difficult to rewrite a core in C and in python to see if there's any difference between the two
C is also my day job... and much more "suckless" I spose
That's awesome, I love C.. I specialise in networking and cybersecurity ^_^ (CCNA, CCNP, CISSP, pentest+)
Thinking more from the suckless pov, why even bother... Feel like what we have works! Is all easily maintainable with (mainly) the whole program running from dwmbar and bar.sh
Why chase those few seconds on startup or slightly delayed update...
(Speaking hypothetical here, not actually saying let's do nothing) It's just fun to work on this
That's awesome, I love C.. I specialise in networking and cybersecurity ^_^ (CCNA, CCNP, CISSP, pentest+)
Do you love C for the language or do you love C because that's usually where people let you in π
You're right to challenge. I think one of this project's unique selling points is that it's a shell script solution, you just install it and the deps and it works.
C:
- (+) More explicit dependency management
- (+) Easier to maintain/test/debug
- (+) Probably best performance if written right
- (-) Now needs compiling
- (-) Need to think about memory
- (-) Will require explicit dependency on a JSON parser lib rather than
jq
Python:
- (+) Easier to maintain/test
- (+) Already on pretty much all linux machines
- (+) built in
jsonlibrary - (+) Probably just as quick since most of the time is waiting on modules
- (+)
subprocessbasically gives us free async - (-) Slightly more annoying install - will need to shove a wrapper to call python in /usr/bin probably
Fuck it also Rust because I think it would be hilarious to have the satire line "A blazing-fast Rust-based status bar implementation, written in Rust π¦ π¦ π¦" in the README and never finish the rewrite (The compiler won't let you)
In my opinion writing a small Python core that just gets a list of modules and calls them using subprocess might be nice - that keeps the rest of it unchanged and targets the specific thing I think we need most.
bwahahaha yes lets add rust
we can also compile automatically with GH actions, so super easy to pull (while also maintaing manual install options)
C
with C I agree that we get great performance, and we can fit to the normal suckless standard (dwm, menu, st) with c code...
needing to think about memory is annoying (thats where rust is kinda cool i guess), but honestly this isn't a complicated project..
dependency on a JSON parser lib suuucccckkkssss
Py
with python being easier to maintain/test it honestly doesn't matter much.. pyhton is too dummy for maintaing imo, with suckless philosophy we are developing for advanced and experienced computer users, CI is easy for C (and py) so testing isn't end of the world
Already on pretty much all linux machines - in my (sometimes idiotic opinion) this project is primarily based on dwm and xorg so C is pretty much a prerequisite, especially because this project is based on dwm/dmenu, which needs compiling ANYways (with make clean install or whatever). one more prerequisite isn't the end of the world in most cases.. especially as we discuss a (somewhat) big rewrite.
built in json library is always nice though
Probably just as quick since most of the time is waiting on modules - but more funnnn π
free async is nice!
annoying install i agree with different python versions... hate having to figure out whether its python or python3..
π¦ π¦ π¦
PLEASE, thats a hilarious idea..
dwmbar-rs lmao
honestly, a small python core would work perfectly, but its boring and this is a hobby project to me.. we could deffo setup a main branch and seperate dev branch, with the main one being the boring lil python one, and the dev one being the beta, "nightly" version of dwmbar
OK here's my suggestion. Keep everything as-is, rebuild the core in C and pass everything in as arguments to avoid the need for a json parser, we can keep using jq for that for now.
Then the only hard thing is getting the arguments in, the rest should be easy.
I also think we should adjust the JSON, so that "modules" is the modules in the order they should appear and each module is a json object with {"name": "module_name", "internet_required": bool (default false)}
internet_required would be an optional parameter so you can now define your modules as:
{
"modules" : [
{"name": "time"},
{"name": "foo"},
{"name": "archupdates", "internet_required": true},
.....
]
}
As funny as rustbaiting would be I think I wanna actually keep this repository working and not in a perpetual state of "we're nearly there bro just one more type error I promise it was just that one unwrap it'll compile this time bro please"
Sounds good, although it'd be nicer to have the internet required in a separate section to the JSON, With a similar list to modules, so we have
Modules Module1 Module2
Internet required Module2
Because it feels neater...
Check out the c-core branch I just pushed. Itβs currently blocking and full of bad practise but a little test (you need to export CUSTOM_DIR to the modules directory and pass modules as arguments) it seems to work.
If we spawn all the popens and then wait on them to finish in a collection section weβll get some concurrency.
busy rn but i will check it out later, can't wait to push some C lol
https://github.com/thytom/dwmbar/blob/09b7842d260566fff52f8627694daef32679e9e7/bar.c#L33
we have a cache dir at .cache/dwmbar already
https://github.com/thytom/dwmbar/blob/3a372a084a2eb515de6c6d35c3b7ff29d5a46c24/dwmbar#L48
Ah yes - no need to set up :)
the C uses getenv a lot (kinda dirty imo, death to global state and side effects!) to make it more compatible with bar.sh. I might even make it accept MODULES that way too, so it's just a drag-and-drop.
Hopefully the code makes sense, most of it was written during a 13-hour overnight stay in A&E :). Just force pushed my changes that NHS wifi wasn't up to the task of doing
Oof hope you're okay, lmao NHS WiFi is... Definitely something.. gotta get on hospedia_wifi2 to get the good bandwidth π
Hope you're (or whoever you were accompanying) is better
Got plenty of free time over Friday and the weekend to get some code out!
All good thanks for asking :) other than losing a dayβs sleep.
Glad to be back home to my big monitor and 500Mbit DL speeds
500? Must be from up north.. we get brsk down here, even my mother is on 2 gig for less than Β£35 a month πΉ
Started making some modules that I find pretty useful, will make a PR with some, see what you fancy keeping
I'm in Manchester, BRSK coverage seems to be everywhere around here except where I am π
Sounds good π I'm gonna keep working on my c-core branch.
oh wow, Manchester! I'm right next door! West Yorkshire
Got myself an ubuntu VM and got core-c working properly (I think)?
Just need to run make bar first before sudo make install
It's hanging because it's not handling the "internet modules" thing which I'll sort next.
Had fun (re)learning how to use fork, pipe and exec. Does NOT feel like safe code.
Do you not want to test it on arch? Can set you up a VM if ya want :) (web accessible)
Feel like Ubuntu isn't our biggest audience
If you're offering let's give it a try :) honestly, ubuntu was just the quickest. Hardest bit was convincing GNOME to go quietly.
Yeah lemme get home and spin it up... Will install my usual setup so it's an authentic environment.. lucky I got curl -sSL https://install.robinhirst.qzz.io/install.sh | sudo sh to install my pretty wallpapers and stuff π
setup the VM, do you have any other means of communication like discord so i can share "sensitive" details like credentials?
no problem or not, can stick to here if you're comfortable w that
Discord? user id 300005669837209600
ummm... as much as i appreciate the user ID.. its kinda useless π€£