Yes, except these are the devdocs for the current IR: https://docs.julialang.org/en/v1/devdocs/ssair/. I wrote that system about 10 years ago, but it was a bit of a rush job in the lead up to Julia 1.0 in order to be able to do some optimizations that we desperately needed to do. It's held up reasonably well, but it's definitely hit its limitations as Julia's popularity has continued to grow. There've been multiple downstream attempts to use it to do compiler-y things and they've all had middling success (including my own). I think the jankiness of the IR API played a role in that, so this is my attempt to try to start cleaning that up.
I don't think there's anything we need to do here that couldn't be expressed in MLIR representationally. That said, I also haven't studied MLIR's representation in too much detail myself, so it's possible there's subtle corner cases. For example, in LLVM you end up getting quadratic processing times even for linear time passes, because it needs to restore the ordering count for instructions (I think the trick in this PR may be backportable to LLVM to improve that, but I haven't looked into it yet). We ran into that badly with larger functions, so it's possible there'd be similar corner cases in MLIR if we used it e.g. for the tree structuring that's proposed in this PR.
Not using MLIR here is more about other considerations:
1. It'd probably be more of a pain to write high performance bindings than just to write the data structure in julia itself.
2. We will be targeting WasmGC in the near future, so we need our core runtime and compiler data structures to be compilable without the assumption of necessarily having linear memory available.
3. It's designed to be used by downstream julia users, so it's easier for them to not have to deal with another system in another language.
4. It's experimental and we need to be able to make changes quickly without having to necessarily have a big upstream discussion.
That said, like I mentioned in the other comment, easy interop with MLIR is an explicit design goal.
MLIR pulls in a lot of interface complexity that we don't want or need for pure-julia end-users. That said, it is obviously and deliberately close to MLIR as a representation since people do want to be able to interface with MLIR (e.g. in Enzyme), so I'd like to facilitate easy conversion back and forth.
Uh, hi guys. This is my PR, but you should probably know that this is an AI generated prototype based on some of my design documents, but nowhere near ready for prime time. I do want to do something like this, but whether it'll take this shape or another is still up in the air.
You'd think so, but Julia has been around a while now. Julia was one of the first non-python languages added back when it was still called ipython. I remember sitting in a room at the CfA with Fernando Perez and Steven Johnson and hacking up then original integration. Don't remember exactly when that was but more than a decade ago.
It always amuses me when people assume that the nefarious scheme is taking open source contributions and selling them. That's not the nefarious scheme. The nefarious scheme is going to partners, funding agencies and investors and saying "look at this unique capability / important research / profitable business opportunity that we can do together, but oops, all of our code is written in Julia, so I guess we better pay some people to maintain it so it'll all come crashing down, wouldn't want that to happen".
Also, I'm of course using nefarious in jest here in both cases. While we don't directly try to monetize our open source work, I respect that sometimes people need to do that. As long as people are transparent about it, I don't have a problem. Doing the thing we're doing seems to work, but it's a lot harder, because you have to build a successful pice of software and a (or multiple) successful something elses that has a critical dependency on it. It's like hitting the lottery twice.
Congratulations to the Oxide team! It's a tough market out there :)! I'm still personally frustrated that I don't get to play with the hardware (too expensive for our internal server needs; not the right fit for our datacenter partners/customers), but I'm excited to see that they're successful and hopefully they'll come around to my use case eventually :). In the meantime, I appreciate that they're building largely in the open - every once in a while I'll glance at their issue tracker for light bedtime reading. Just recently we had some fun internally throwing our controls software at their thermal loop as a usage example - it's often hard to find compelling real-world systems to use as openly sharable examples (of course we have interesting customer problems, but that's all NDA'd), so having companies build real stuff in the open is fantastic. Great company, wish them the best.
The full complaint linked above has a full list of trademarks. There's also a claim for trade dress infringement, since the food truck uses the same font and red-yellow-white color scheme.
You're supposed to generate a random one, but the only consequence of not doing so is that you won't be able to register your package if someone else already took the UUID (which is a pain if you have registered versions in a private registry). That said, "vanity" UUIDs are a bad look, so we'd probably reject them if someone tried that today, but there isn't any actual issue with them.
One of them I managed to fry the pcie root complex somehow, not sure exactly how. One I damaged the traces to the BMC SPI flash. Two others I think just have bricked firmware, but it's been years, so I don't remember for sure.
Funny to see this come back and see my write-up linked. I did this 8 years ago and think I was the first on this particular board (although others had done similar on other boards). I still have a pile of them sitting on my desk because I accidentally kept bricking them by being ... not careful. That said, even at the time this board was already old, so I guess it's positively prehistoric at this point. I eventually stopped working on this because I thought that others were making sufficient progress. It hasn't really fully materialized yet, but between openbmc, opensil, DC-SCM and the work the oxide folks are doing, I'm still hopeful that we'll get out of server firmware hell eventually.
Reach me at [email protected]