Is shell script still the best way?

[thytom]

@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?

[RobinHirst11]

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/

[RobinHirst11]

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

[thytom]

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

[thytom]

C is also my day job... and much more "suckless" I spose

[RobinHirst11]

That's awesome, I love C.. I specialise in networking and cybersecurity ^_^ (CCNA, CCNP, CISSP, pentest+)

[RobinHirst11]

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

[thytom]

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 json library
• (+) Probably just as quick since most of the time is waiting on modules
• (+) subprocess basically 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.

[RobinHirst11]

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

[thytom]

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"

[RobinHirst11]

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...

[thytom]

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.

[RobinHirst11]

busy rn but i will check it out later, can't wait to push some C lol

[RobinHirst11]

dwmbar/bar.c

Line 33 in 09b7842

// TODO: Set up the cache directory

we have a cache dir at .cache/dwmbar already

dwmbar/dwmbar

Line 48 in 3a372a0

CACHE_DIR="$HOME/.cache/dwmbar/"