101–110 of 110 posts
> tup, transitive verb: To have sex with. https://en.wiktionary.org/wiki/tup
It's an archaic britishism. The only time I've ever seen it actually used is in the works of Morgan Howell.
Tup's main problem is it's unusual, and it doesn't have a library of build rules. But it's fast! On a related note, I've always wondered if it was possible to have a build system based on dynamic library injection / strace. The idea would be that you just write your build rules in shell script. Then, you run it with a special shell that catches open(), etc. in child processes (via library injection, etc). These syste…
The same might be true for Java, too. Anybody know if modern JVMs bother calling into libc for basic system calls like open, or otherwise obey dynamic interposition of standard library routines?
Checkout ninja-build. Generate ninja build files automatically using CMake. Ninja is really fast.
http://www.kaizou.org/2016/09/build-benchmark-large-c-project.html
A non-recursive Make build is actually pretty darn peppy for all but the largest projects. The reason ninja was faster at scale in those tests was likely because GNU Make has some very inefficient code internally which theoretically could be improved substantially with some refactoring. ninja had the benefit of a fresh implementation, avoiding decades of feature creep.
I've been writing non-recursive-style Makefiles for years. But all I ever hear is whining by project contributors about the unfamiliar syntax (e.g. having to prefix all targets and sources with a path). Yet in the same breath I'll be told to use CMake or ninja or tup or whatever the build-system-du-jour, using vastly different syntax. Ah well....
I keep dreaming of a Makefile generator that will auto-generate a non-recursive build, or perhaps add the feature into GNU Make directly. The problem with the latter approach is that one major reason to use Make (including GNU Make) is portability out-of-the-box, but OS X is stuck at GNU Make 3.81.
Earlier quoted context omitted.
> Ad-hoc parsing comes up a lot, and if I have to parse a format, I'd rather it be text. People often offer that "plain text is superior..." but neglect to recognize that PowerShell's model actually offers as superset of the current functionality of Bash, and that when object streams are required they are utterly indispensable. It's also a uniquely eurocentric conceit that text is a simple stream of bytes. At the ver…
>It's also a uniquely eurocentric conceit that text is a simple stream of bytes. At the very least, it is a stream of bytes with an encoding label. Unicode is everywhere, and for some people is required to express their language. You can no more safely assume ISO-Latin-1 as you can UTF-8 or UTF-16. True, but how many of your text-processing utilities need to account for that? Most config file parsers will just contin…
I'm not chinese, but I can have sympathy for people who are. Also who are you to tell me [UTF-8 character removed because of bad assumptions in server code] is not a valid bash variable?
> The libraries are all already there, you don't have go get apt-get integration for the components you need, and it's often pretty quick to write what you need.
This is an assumption that's very brittle though. For example, which version of Python did you target with this helper script? Do you know?
And why is that diff for Powershell? It's just a shell with better affordances for automation than bash.
> Verobosity is a huge problem.
If you want a less verbose set of powershell commands, try the latest powershell. Nearly everything you type has a short analogue. Function syntax is shorter. It's easier to do things like automate opening of remote connections (e.g., no need for a shell script to open an ssh connection and toss many streaming outputs into it on an ongoing basis).
> and it fails at things that shell is good at.
You say this but my experience has been the opposite thus far. Making functions actually functions, for example. It's amazing to be able to make a complex jq query repeatable without being forced to pipe everything over an IO stream and collect into a file and then VAR=$(cat result.json).
Earlier quoted context omitted.
>It's also a uniquely eurocentric conceit that text is a simple stream of bytes. At the very least, it is a stream of bytes with an encoding label. Unicode is everywhere, and for some people is required to express their language. You can no more safely assume ISO-Latin-1 as you can UTF-8 or UTF-16. True, but how many of your text-processing utilities need to account for that? Most config file parsers will just contin…
> True, but how many of your text-processing utilities need to account for that? I'm not chinese, but I can have sympathy for people who are. Also who are you to tell me [UTF-8 character removed because of bad assumptions in server code] is not a valid bash variable? > The libraries are all already there, you don't have go get apt-get integration for the components you need, and it's often pretty quick to write what…
>This is an assumption that's very brittle though. For example, which version of Python did you target with this helper script? Do you know?
And PS, and every other piece of software out there doesn't have that problem? Don't make me laugh.
>And why is that diff for Powershell? It's just a shell with better affordances for automation than bash.
But shell doesn't nessarily need automation affordances: we have Python/Perl/Ruby for that. What it does need is effective interactive use, which is where I think bash has PS beat.
>I'm not chinese, but I can have sympathy for people who are. Also who are you to tell me [UTF-8 character removed because of bad assumptions in server code] is not a valid bash variable?
That's a problem with Bash itself, which wasn't what I was talking about. My point was that text processing scripts (sed scripts, awk scripts, scripts using cut, etc.) won't choke on unicode, and frequently work pretty much as expected, so long as the tool versions involved can handle unicode, and sometimes even if they can't. If bash has broken unicode support right now, that's not a problem with the paradigm, that's a problem with bash itself, which can be fixed.
Earlier quoted context omitted.
> True, but how many of your text-processing utilities need to account for that? I'm not chinese, but I can have sympathy for people who are. Also who are you to tell me [UTF-8 character removed because of bad assumptions in server code] is not a valid bash variable? > The libraries are all already there, you don't have go get apt-get integration for the components you need, and it's often pretty quick to write what…
Well, the verbosity drop is good. >This is an assumption that's very brittle though. For example, which version of Python did you target with this helper script? Do you know? And PS, and every other piece of software out there doesn't have that problem? Don't make me laugh. >And why is that diff for Powershell? It's just a shell with better affordances for automation than bash. But shell doesn't nessarily need automa…
And I don't mean to say any one tool is free of version conflicts, but relying on many tools means relying on many versions. Reducing your total dependency graph is a lesson many language environments have taken from the mess of Java and C++.
Earlier quoted context omitted.
Well, the verbosity drop is good. >This is an assumption that's very brittle though. For example, which version of Python did you target with this helper script? Do you know? And PS, and every other piece of software out there doesn't have that problem? Don't make me laugh. >And why is that diff for Powershell? It's just a shell with better affordances for automation than bash. But shell doesn't nessarily need automa…
Cut is not encoding aware... not all Linux distribution have encoding aware grep, and even then you'd need to tell them which encoding to use in many cases. And I don't mean to say any one tool is free of version conflicts, but relying on many tools means relying on many versions. Reducing your total dependency graph is a lesson many language environments have taken from the mess of Java and C++.
Earlier quoted context omitted.
Cut is not encoding aware... not all Linux distribution have encoding aware grep, and even then you'd need to tell them which encoding to use in many cases. And I don't mean to say any one tool is free of version conflicts, but relying on many tools means relying on many versions. Reducing your total dependency graph is a lesson many language environments have taken from the mess of Java and C++.
Well, considering that the primary function of a shell is to run programs , reducing your depgraph isn't what you want.
The instant we start talking about automation then the repeatability of your automation has to be considered.
The shell is arguably an environment for interactive programming as much as it is a shorthand for program invocation.
Tup's main problem is it's unusual, and it doesn't have a library of build rules. But it's fast! On a related note, I've always wondered if it was possible to have a build system based on dynamic library injection / strace. The idea would be that you just write your build rules in shell script. Then, you run it with a special shell that catches open(), etc. in child processes (via library injection, etc). These syste…
IIRC strace wouldn't work if you used any setuid binaries (horrible but our makefiles used sudo for some things).
There are also some tricky corner cases like sed -i which creates a new file then moves it.
Checkout ninja-build. Generate ninja build files automatically using CMake. Ninja is really fast.
CMake-generated ninja builds aren't fast in an oranges-to-oranges comparison: http://www.kaizou.org/2016/09/build-benchmark-large-c-project.html (TL;DR: scroll to bottom of page to see "The raw results".) A non-recursive Make build is actually pretty darn peppy for all but the largest projects. The reason ninja was faster at scale in those tests was likely because GNU Make has some very inefficient code internally wh…