3,031 karma · joined November 7, 2011
I'm attached to a tmux session. gdb is probably running in a split with vim.
My views are not necessarily those of my employer.
I live in the Chicago burbs, but I work in the loop. I'd love to buy you a tea, coffee, or a beer to talk about start ups, Clojure, C++, Lisp, Python, toolchains, Bazel or other tech.
github: https://github.com/emidln
bsky: https://bsky.app/profile/emidln.com
email: emidln@gmail.com
Vic's (rip) Sam's (rip) Gabatoni's Joe's JT Costello's (more recently)
all served delicious crunchy thin crust with heavily spiced sauce cut thin and usually sent out covered in paper. Any bar that didnt serve frozen pizzas served a variation of this thin crust pie.
Notably, Gallina's Pizza and Lucca Pizza were both Neapolitan style.
Hiring for C++ is hard because C++ is hard and most people are quite bad at writing even somewhat reasonable code.
In bazel you have complete control over all of your deps. Ultimate power and ultimate responsibility. Even an external BUILD.bazel can be patched when you bring it in (bazel has provisions for patching stuff from http_archive if you supply a patch). You can even ignore an existing BUILD.bazel and write your own if you only care about part of an external thing. If it's a target in your graph, you can certainly modify it. If there is some internal process that prevents you from modifying your own code, I can't help you. Maybe fix that or go somewhere that gives you the authority to do your job.
I was demonstrating that you can force some libraries to be only static and still partially link some things static and some dyanmic. If you want to get really into the weeds, you could even affect the link line and individually pick dependencies in a custom rule (that is fully compatible with the rest of the bazel tooling). Almost nobody ever needs to do that, but maybe you want to make only every other dependency dynamic to satisfy some weird slide in a talk.
Bazel's rules_cc even has a system_library.bzl you can import a `system_library` from that automates this for you. https://github.com/bazelbuild/rules_cc/blob/main/cc/system_l...
I'd still recommend building everything from scratch (and understanding the relationships and graph of your dependencies), but if your build isn't that complicated and you want to role the dice on UB, this isn't that hard.
As an aside, the most galling part of bazel's cache key calculations has to be that it's up to the individual rules to implement this how they see fit. The rules native to bazel written in java vary wildly compared to starlark-written rules. On thing you (or someone in your org) end up becoming pretty comfortable with while using bazel in anger is RTFC.
Try it out like this:
# you'll need a c compiler installed, xcode is fine on macos
git clone https://github.com/emidln/bazel_static_dynamic_c_demo
cd bazel_static_dynamic_c_demo
bazel run //:foo
ldd bazel-bin/foo # otool -L bazel-bin/foo if you're on MacOSBeyond build engineering, I've also found it useful to debug container image differences.
In the US? Armed revolt by unionized workers. Blood baths on both sides (labor and hired scabs/private police/paramilitary). Forced bargaining from state and federal governments. If you know where to look, there are little "union" cemeteries dotted across the Eastern and Midwestern US where union folk are buried due to company town cemeteries banning strikers and their families from being buried "in town".
Workers' rights were bought and paid for in blood.
Emacs has a couple gdb modes which are fine, and a DAP mode which is very good.
For work, I still have some third-party toolchains that were originally compiled on x86_64 linux in 2012. They are dockerized these days to make running these legacy toolchains easy. There is no possibility to recompile these on ARM to provide parallel containers that are compatible with Docker for Mac.
[0] Let me stop you right there before you suggest I recompile 15 years of operating systems, third party toolchains, and internal tools for ARM and then rebuild every intermediate container just so we can work around Rosetta shipping without necessary features. I know that you can ship a whole parallel stack of containers with ARM but that's not feasible in the slightest for anything but the most trivial use cases or entirely greenfield projects.
(defn fizzbuzz-nth* [n]
(cond
(zero? (mod n 15)) "FizzBuzz"
(zero? (mod n 3)) "Fizz"
(zero? (mod n 5)) "Buzz"
:else (str n)))
(defn fizzbuzz* [n]
(->> (range 1 (inc n))
(map fizzbuzz-nth*)
(interpose " ")
(apply str)))
(defmacro fizzbuzz [n]
`(println ~(fizzbuzz* n)))
(println "macroexpansion: ")
(println (macroexpand '(fizzbuzz 100)))
(println)
(println "invoke the macro: ")
(fizzbuzz 100)
Compile-time programming isn't any different than runtime programming in a lisp. This is nice because we can write the business parts as regular code, which is easy to try out in the repl or write tests for and then wrap it in a macro for compile-time evaluation if that's what the situation calls for.For those not versed in lisp, `fizzbuzz-nth` and `fizzbuzz` are regular functions and `fizzbuzz` is a macro (aka a function annotated to be executed at compile time). The `fizzbuzz` macro makes use of Clojure's `syntax-quote` (the backtick) to signify templating is going on and `unquote` (the tilde) to escape the templating and execute some code at macro expansion time.
It's a real shame most languages don't have these metaprogramming facilities as judicious use makes weird, hard, and untestable stuff into common, easy, and another boring part of the test suite.
I'm really pulling for C++ to eventually get here with templates, particularly now that vectors can be constexpr and the result of templates. Maybe c++26 will finally give us reasonable macro facilities in a mainstream language.