Cool #Bazel E2E CLI testing ruleset.
One of the things I’ve struggled with when learning #MLIR is how to compose all the different lowerings into a pipeline that ends in the result I want, especially when other people wrote those pipelines. When starting from a high level dialect like #linalg (linear algebra), there can be dozens of lowerings involved, and some of them can reintroduce ops from dialects you thought you completely lowered already, or have complex pre-conditions or relationships to other lowerings. There are also simply too many lowerings to easily scan.
There are two ways to specify a lowering from the MLIR binary. One is completely on the command line. You can use the --pass-pipeline flag with a tiny DSL, like this
How do you find the bug in a lowering? Apparently there are some folks doing this via formal verification, formalizing the dialects and the lowerings in #lean to prove correctness
Who has a good strategy for building and testing with Github Actions in a #monorepo.
Currently using #makefile in each project. Not looking foward to a bunch of GHA workflows for every project and wondering if there is a better way.
Tried #earthly but didn't seem to make things easier.
Sorta also dragging my feet on #Bazel, but still may go that way.
It’s quite an achievement given the breadth and complexity of Bazel.
Even trickier is packaging software such as JAX that uses Bazel as its build system:
𝗔𝗹𝗰𝗮𝗿𝗮𝘇 𝗺𝗲𝗹𝗱𝘁 𝘇𝗶𝗰𝗵 𝗺𝗲𝘁 𝗯𝗹𝗲𝘀𝘀𝘂𝗿𝗲 𝗮𝗳 𝘃𝗼𝗼𝗿 𝘁𝗼𝗲𝗿𝗻𝗼𝗼𝗶 𝗶𝗻 𝗕𝗮𝘇𝗲𝗹
Carlos Alcaraz doet komende week niet mee aan het ATP-toernooi van Bazel. De Spaanse tennisser meldde zich woensdag met een blessure af bij de organisatie.
TIL about Subresource Integrity (SRI), a standardized string format on specifying a cryptographic hash, not too dissimilar to what #Bazel already does with ubiquitous sha256, but more generalized.
> An `integrity` value begins with at least one string, with each string including a prefix indicating a particular hash algorithm (currently the allowed prefixes are `sha256`, `sha384`, and `sha512`), followed by a dash, and ending with the actual base64-encoded hash.
SemanticDB support, which was originally implemented by @olafurpg nearly two years ago landed a few days ago on rules_scala (#Scala plugin for #Bazel) thanks to four co-authors Matt Peterson, @aish, Dmitry Komanov, and 'crt-31' pushing this effort through
I can help with one of the last points:
> True to form, this tool [tsickle] is open source but pretty inscrutable to an outsider. It may be used by Angular but I couldn't tell.
I can confirm that Angular does *not* run `tsickle` or Closure in user projects with `ng build`. There was an experiment some years ago where we tried this to see if we could improve bundle sizes, but found that asking users to write Closure-optimizable code was too difficult and hard to justify outside Google. As a result, we never ran this in prod.
I believe we do technically run `tsickle` in Angular GitHub repositories, as we have a unique build system setup with #Bazel and #rules_nodejs. If you've ever contributed to Angular, you probably ran `tsickle`. We've been trying to remove this dependency, but I don't think it's happened yet.
Xcode 15 is finally here! It's been a joy to use these last few months.
I should mention that #rules_xcodeproj has worked with it since the first beta (though we made some fixes as more releases came out), so be sure to upgrade to 1.10.1 (https://github.com/MobileNativeFoundation/rules_xcodeproj/releases/tag/1.10.1) if you haven't already.
There are a few projects I've been working on which I'd love to give talks about and share with the community (not Angular related). Could be talking about any/all of:
1. #HydroActive - A different take on hydration in an HTML-first world. https://github.com/dgp1130/HydroActive/
2. #rules_prerender - A #Bazel ruleset serving as a fast and scalable #StaticSiteGenerator. https://github.com/dgp1130/rules_prerender/
3. #HTMLFragments - A no-tooling, web standard-based approach to HTML over the wire. https://blog.dwac.dev/posts/html-fragments/
Greatly appreciate boosts for reach!
fundamentals of build: You want one of 3 things:
1. artifact (binary) for your target or
2. Perfect runnable instructions for building artifact (bin) for your target or
3. Runnable instructions for building artifact on a variety of targets that you have tested on your target.
This allows for `1 || 2 || 3`. Good #buildtools take this into account. #Nix, #bazel, even good ol' #GNUMake. But, then we don't use that functionality; we forget about it in our scripts & they fail, missing a bin they coulda built or they fail, building a bin they coulda stolen. Note that this post puts off worrying about dependencies, because 1, 2 & 3 can worry about those, too, if you do it right.
$ git rebase main --exec "bazel test //..."
This will checkout every commit since `main` and run `bazel test //...`, stopping if any tests fail.
You can do this with any test command, but what's awesome about Bazel is that the build cache is still valid between commits. Anything which didn't change will be cached.
This means you can easily run *all* tests for *every* commit on a branch with dozens of commits in only a few seconds. The cacheability is *amazing* here. It's an excellent way to verify a every step of a large change.
because I am a Rust newbie, copy-pasting is easy, but seemingly-rudimentary refactoring is so challenging (because of the ownership), I kind of have to choose my own battle to not burn hours. I did manage to write an async lambda in one of the battles, which feels like an achievement unlocked
Hey kids wanna see something cursed #bazel #python https://gist.github.com/arrdem/05d32cc8870e87f1d6fa07df31586d19
@ianthetechie God speed. Not sure if it is an option, but have you given #Bazel a try? https://github.com/bazelbuild/rules_apple/blob/master/doc/tutorials/ios-app.md
wrote 'automate refactoring with Bazel + Scalafix'
https://eed3si9n.com/automate-refactoring-with-bazel-and-scalafix/ #Scala #Bazel
I stopped feeling bad about #autotools files (configure.ac Makefile.am m4/*) when I realized how much noise a new maven package throws on your disk.
The main difference is: for #maven / #npm / #cargo / #gradle / #bazel / ... these are autogenerated.
Even after all this time I'm still not a fan of #gradle. I use it because that's where the support is for #android development, but, on a purely build bases, #bazel and #buck are, in my experience, more robust build tools.
Today's "Nope, still don't like it" trigger was having a gradle build fail with "Gradle build daemon disappeared unexpectedly..." when the build has been specified as to not use a daemon. That's either poor parameter naming, or documented parameters being ignored.
This is the best introduction to #Bazel that I have found. This ~30 minute talk covers writing your own macros and rules, using LaTeX compilation as an example. Maybe Bazel is deemed difficult enough as it is, but many resources, even books on Bazel, do not cover this. https://media.ccc.de/v/froscon2017-1946-bazel
I’m currently trying to package several of our static library into dynamic framework using ios_framework rule in #Bazel but there’s an intermittent failure on bundling steps.
It says I copied the same framework twice.
wish the #bazel rules_python upstream would notice my PR one way or another but hey. corporate OSS project not the community projects I'm used to. either way about to get shmoovin
Really don’t love how common it is for #bazel packaging to pin a version of the thing it’s packaging. New bazel means new packaging means new packaged library version. Too much coupling!
So here's my #bazel review. Good theoretical model. When it works it may as well be alien technology. But it's horrendously underdocumented and obviously not designed for consumption by people who haven't already learned on Blaze. And the OSS rules are pretty low quality. And half the stuff you need to make it work - cache management, bad action purging, analysis cache persistence, ... happens to not be OSS.
I started writing a toot-storm, but I realized a blog post was a better medium for it. Enjoy: https://www.buildbuddy.io/blog/multiple-xcode-configurations-with-rules_xcodeproj-1-3
in the first draft I couldn't figure out how to cross build using MODULE.bazel, but eventually I figured it out, so I updated the post yesterday. also made a PR to show that it actually works on GitHub Actions.
wrote a blog post 'cross build anything with Bazel'
this technique is not limited to JVM, I figured #Scala cross building is a representative example, so I used it as an example on how it can be done using the local_repository technique
it happens so that in different orgs that I work for, the first things I tackle is the library dependency issue.
this week @ianoc showed me a neat trick of using
--override_repository to switch out a local repository in #Bazel. I've heard this technique described in the past but didn't realize how powerful it was atm.
2/14 - Gradle Build #Cache Deep Dive: https://gradle.com/training/gradle-build-cache-deep-dive-3/?time=1676332800
2/15 - Gradle Build Cache Deep Dive - EMEA: https://gradle.com/training/gradle-build-cache-deep-dive-emea/?time=1676419200
After a lot of work, I've finally landed a release of #Bazel #rules_prerender which is compatible with #aspect_rules_js! https://github.com/dgp1130/rules_prerender/releases/tag/releases%2F0.0.17
This has been a long time coming, and the issue shows how big a change this was (https://github.com/dgp1130/rules_prerender/issues/48). It didn't help that I kept getting distracted with other things and forgot everything I was doing. 😅
#aspect_rules_js does seem like a solid improvement and it sets up #rules_prerender for a lot of awesome improvements in the future (#ESM, #bzlmod, better bundling, etc.) Super excited about where we can take this next!
Shout out to @alexeagle and Greg Magolan (who I don't think is on Mastodon?) for their help, couldn't have done it without you!
I’m so excited to announce we’ve released version 1.0 of #rules_xcodeproj!
For a release this important, I’ve written a blog post. Please enjoy 😊.
This is objectively one of the dumbest and worst ideas I've ever come up with, so I made a feature request for it over-analyzing the idea way too much.
I would be very curious to know exactly _which_ aspect of the idea breaks first. Is it memory limitations? Cache invalidation? Database management? Backend usage? #RBE SLOs? So many things things that could ruin it!
Google Cloud and Firestore vs Datastore (3/n): the documentation for getting started refers to a Maven dependency that is no longer hosted in the registry (doc refers to firebase-admin 1.32.0, most recent version seems to be 9.1.1). Not a deal for people who know what they are doing, but not an example of a smooth experience.
Wondering what this means for #Bazel though where we experience similar feedback about documentation 🙈
Exploring Fediverse from a different place, here's my local #introduction
I've been exploring Mastodon from a private instance so far, and already learned that discovering content and people is a whole different thing on a well established instance. Let's try!
Thank you @nova (or, .io?) for hosting!
Time for my #introduction!