I thought the name is pretty funny in a self-deprecating way. Just commenting because everyone seems to hate it so far. I didn't know about the drug, though.
Thanks for the suggestions! I'll definitely look into those. I'd been hoping posting on HN would result in being able to shave off yet a few more bytes.
This project started as a rewrite of a Bash script (for learning purposes), so I can easily answer this question. It's indeed small. Here's the full Bash script I used to use (including comments):
#!/usr/bin/env bash
# Print the remaining amount of energy (or charge)
# stored in the battery identified by `BAT0`. This
# is what works on my ThinkPad X220 and may not be
# portable to other laptops without changes.
cd /sys/class/power_supply/BAT0 || exit $?
# Sometimes there are `energy_now` and `energy_full`
# pseudofiles, and sometimes there are `charge_now`
# and `charge_full` pseudofiles instead.
if [[ -e energy_now ]]; then
now=$(<energy_now)
full=$(<energy_full)
unit=Wh
elif [[ -e charge_now ]]; then
now=$(<charge_now)
full=$(<charge_full)
unit=Ah
fi
percent=$((100 * now / full))
# Convert from microwatt-hours (or microampere-hours)
# to watt-hours (or ampere-hours).
now=$(bc <<< "scale=1; $now / 1000000")
full=$(bc <<< "scale=1; $full / 1000000")
echo "$now $unit / $full $unit (${percent}%)"
This project is a rewrite of a Bash script that I started to teach myself a little bit of x86 assembly. I still don't know much, but I did learn that ELF executables can be surprisingly small and simple for a very basic program. A 64-byte file header and a single 56-byte program header are the only "overhead" that is really mandatory (and it's even possible to make those overlap a little).
But it's difficult to stop the linker from adding extra stuff, which is why I eventually specified the headers (and three addresses) by hand in the assembly file and stopped using a linker.
Good luck on your x86-golfing journey! If it helps, I have a nice template for overlapping the two headers into 80 bytes, and stuffing up to ~24 bytes of instructions into them. It's included near the top of my article on the smallest x86-64 ELF Hello World [0]. (In the same article, I have a 73-byte template that's a bit shorter but trickier to use.)
You may find some of the other tricks in the article helpful, but it might be hard to follow depending on your level of experience with assembly. My general advice would be that 'push' and 'pop' are your two best friends if you want to move around 64-bit values.
I'll have a look. Thanks! I'll avoid using potentially transient details of Linux's ELF loader, though, since I use `btry` daily and don't want to tempt fate to have it suddenly break following a kernel update too much. (Perhaps that's a bit silly given the hardcoded `/sys` path and syscall numbers.)
You're in the clear with the syscall numbers, at least. Linux treats them as part of the stable public API for each platform. If they want to update a syscall, they have to make a new version with its own number, and keep the old version around for as long as x86-64 is supported.
I don't remember if it's why I initially did it, but it allows hardcoding the final characters of the output string ("%)\n") somewhere into the ELF header where they don't do damage ahead of execution.
> Don't like one of Hancho's defaults? It's only 500 lines - hack it up however you like.
It's fascinating to think of this as a deliberate approach or paradigm rather than a shortcoming. The antithesis to the inner-platform effect [1]. Instead of digging an ever deeper rabbit hole of options and configuration, encourage customization via forking. You can't beat the flexibility. And lots of projects have well over 500 lines of build system configuration anyway. With that kind of competition, forking a 500-line build system may well yield the more comprehensible end result. Not to mention that when facing a problem outside of a given build system's anticipated set, I'd much rather have Python to solve that with than a special build system language.
Problem with python based "systems" of any sort is that they break over time without constant maintenance.
make from 2000 will still work with makefile from 2000.
Python script from 2015 will not work today unless you have maintained it over that time.
Every time I try to use any Python script for anything I follow the posted instructions and end up with an error. Something somewhere has changed and the script no longer works...if it ever did, there is no way to know or go back to the working version.
So for me anything more than 10 lines of Python can be considered broken and unmaintainable.
It's possible that you experienced the end of the 2->3 transition. My Python scripts from 2015 all still work, except the ones that used the then-experimental async framework, which was widely documented as experimental and subject to change.
This is sort of the suckless approach. Most (all?) of their projects are customized by editing the source and recompiling. From their window manager, dwm:
dwm is customized through editing its source code, which makes it extremely fast and secure - it does not process any input data which isn't known at compile time, except window titles and status text read from the root window's name. You don't have to learn Lua/sh/ruby or some weird configuration file format (like X resource files), beside C, to customize it for your needs: you only have to learn C (at least in order to edit the header file).
I’m a big fan of copy-pasting code. When you are just learning to program you learn all of the common abstractions, for loops, functions, modules, etc. to reduce code duplication. This leads too many devs to think duplication is a bad thing to be avoided at all costs. I’ve seen a ton of terrible libraries out there that aim to end code duplication. Please, I can handle needing to copy/paste a couple of lines of code around my code base. But I can’t handle your bad abstractions.
Copy-pasting is fun when you add code, and a pain when you subsequently have to alter it. So it's easy to sell to a beginner or a hobbyist, and it also works well in projects which do not live long, like most games and many websites.
It can go either way. If you duplicate code, but the two copies need to stay in sync, then you've made it a bit harder and more error-prone to maintain. But the worse offense is if you have some code that serves two conflicting sets of requirements, but you keep the code together with increasing complexity to thread the needle of satisfying all the requirements.
The latter is the worse offense because it's much harder to decouple two systems than it is to notice a similarity in two bits of code and to extract the commonality.
Yep years ago I worked on a web application that was made with "classic" Active Server Pages. Each page was a self-contained .asp file. To make a new page, you copied another page and changed it around.
This meant that when you wanted to change something on all pages, it was a PITA but not always terrible because tools like grep, sed and awk exist for Windows also.
The nice thing was, you could make a change on any page and know that it would only affect that page and had no (or very little) chance to introduce bugs anywhere else in the system.
I wouldn't recommend the approach, but it wasn't all bad.
Exactly. If you have to care about this for any prolonged time, do yourself a favor and structure your code carefully, think about the right abstractions, etc.
If you only need to release it before Christmas no matter what, and sales will wane anyway in 6 months, then even worse crimes against maintainability may find a justification.
The problem is, of course, is that even code that was intended as throwaway tends to live much much longer than expected, if it actually works.
I think of it instead as the code is just a more expressive config file.
Smetimes you don't want that but sometimes you do, and it's a counter-productive mistake to only ever go one way or the other in all situations instead of identifying what best serves different situations.
I managed to log in again following a few days with failed attempts because of your post. Thank you! I use `xdotool` to autotype my email address and was also consistently presented with endless captchas that I couldn't get past. Now I just typed my email address by hand. No captchas. Seems pretty ridiculous indeed.
