The following hardware specs were obtained by disassembly my personal Google Nest Mini and looking at the parts on the PCB:
| #!/bin/bash | |
| # usage: demangle_ld_trace.bash [filename|STDIN] | |
| # | |
| # Demangle C++ symbol names inside a ld.so trace file | |
| # (obtained by setting LD_DEBUG=symbols and LD_DEBUG_OUTPUT=somefile.trace) | |
| # by feeding them to name demangler c++filt. | |
| # | |
| # The idea to use perl for the replacement is based upon: | |
| # http://stackoverflow.com/a/6355941/ | |
| # (Q: "using command substitution inside a sed script, with arguments") |
| #!/bin/bash | |
| # +-----------------+ | |
| # | Path management | | |
| # +-----------------+ | |
| export ___ORIGINAL_PATH="${PATH}" | |
| function get_path() { | |
| echo "Current path: ${PATH}" | |
| } |
The default behavior of Gradle to pick the newest version also applies if a lower version has been declared locally, but another dependency transitively pulls in a newer version. This is in contrast with Maven, where a locally declared version will always win.
For example, if your build.gradle specifies the dependency org.springframework:spring-tx:3.2.3.RELEASE, and another dependency declares 4.0.5.RELEASE as a transitive dependency, then 4.0.5.RELEASE will take precedence:
dependencies {
compile("org.springframework.data:spring-data-hadoop:2.0.0.RELEASE")
compile("org.springframework:spring-tx:3.2.3.RELEASE")
// will select org.springframework:spring-tx:4.0.5.RELEASE
A small demo program in C#, demonstrating the dynamic generation of Xunit tests for each filename in a search path, where the filename matches a pattern. This Gist requires xUnit.net to compile.
After reading in the EnumerateFilesFixtureAttribute on the type Tests.AutoPopulatedTest, the main program enumerates all files in the path specified by the attribute that also match the searchPattern (e.g. "*.json").
It then uses System.Reflection.Emit to emit a test method for each of the files found. Each generated test method is also decorated with a [Xunit.FactAttribute] to make the Xunit test runner recognize it.
By modifying the value of the generated DisplayName property, one can change how the generated tests are displayed in the Xunit GUI runner, for example.