Off topic, but I recently encountered a weirdness in HTML and this seems like a thread where someone might understand why:
I have an SVG image that contains some JPEG images referenced via the SVG image attribute. Browsers display it fine. If I reference it via an HTML img tag, the SVG vector images display fine, but the raster files are not loaded (no errors in the debugging tools, they just don’t get loaded). If I reference it via an HTML object tag, the browser displays them correctly.
This is not a browser bug. Chrome, Firefox, and Safari all have the same behaviour, so I presume this is actually specified and intentional behaviour, I just have no idea why this would be what people want.
There is a difference between SVG being rendered as a document amd SVG rendered as an image. Sadly, I don’t know there that line is drawn and what is and isn’t supposed to be included in documents vs images. A typical example that I am aware of is JavaScript. Embedding something via shouldn’t allow scripts.
JavaScript is disabled.
External resources (e.g. images, stylesheets) cannot be loaded, though they can be used if inlined through data: URLs.
:visited-link styles aren’t rendered.
Platform-native widget styling (based on OS theme) is disabled.
Couldn’t find a link to the proper specification text though. The one on MDN seems wrong. :-(
I assume a good chunk of the why is “we started it that way and didnt see a reason to try change it”, but images are in HTML pretty much defined to be things that can be fetched in one request and then displayed in one go, there is no room made for them to cause subsequent requests (which could cause layout shifts etc further down the line).
I am not sure how that would apply. The .jpeg and .svg files are in the same directory on the web server and that is a subdirectory of the directory containing the HTML.
The fix here (if you need to work with the img tag) is to preprocess the SVG to bake the images into it by changing their hrefs to data: URLs. They don’t count as “external resources” in that case.
This explains why I couldn’t figure out what the default theme was! That was my main onboarding annoyance actually - I couldn’t find the default colour scheme so I couldn’t configure nvim/helix/bat/etc to match the terminal.
Someone linked me to their codeberg repo the other day and I was amazed how slick it was. If the forgefed protocol ever really gets off the ground (cross-instance pull requests!) I think forgejo becomes unstoppable. I get that email-based patch workflows are already federated but I just haven’t got around to learning it and PRs are pretty intuitive.
I did some poking around and honestly, Forgejo looks like everything I’d want out of a forge these days. I’m a bit surprised to see it even includes CI. A lot of smaller companies should probably be using this instead of Gitlab.
Have the Forgejo developers shown any interest in supporting self-hosted CI runners on Windows and macOS? Or is that specifically out of scope for them because those platforms are proprietary?
I believe there isn’t an active movement for using anything outside of their fork of act, however their docs state
It is possible to use other runners instead of Forgejo runner. As long as they can connect to a Forgejo instance using the same protocol, they will be given tasks to run.
So, technically speaking, someone could write a runner that runs on any platform that can connect and respond to the protocol (and what happens after that seems to be up to the runner itself).
I may be mistaken, but I think they just don’t provide pre-built binaries for those OSes. But you should be able to build forgejo-runner on your own for them.
The proportion of software engineers who have the living knowledge base of how to use PRs seems far greater than those possessing the knowledge of how to effectively use git send-email. Maybe it’s true that git send-email is much less work once you know it (I don’t know, never tried, only project I know of that uses it is the Linux kernel) but any “less work” analysis will have to account for the work of training others how to use it, amortized over the number of patches they send. And for open source projects seeking contributors, removing friction to initial contributions is everything.
I really don’t think PRs are more work. I just git push myorigin, and it prints a URL. I click it and, if it’s a simple case, just click Create PR (if it’s a complicated case you have to write a cover letter, just like you do with email). It takes longer to figure out what email address to send to for git send-email than those two clicks.
The real benefit of forge PRs comes after the initial send. I can force push to update the PR instead of having to resend emails, as often as I want, without spamming people. Countless times I noticed a mistake after the fact and quickly fixed it without having to bother anyone.
All review comments on the PR are linked in one convenient place and with a rich UI where you can expand code context without having to cross-reference a code editor manually. It’s almost impossible to review complex email patches without manually digging up context (and visualizing how the patch applies mentally, unless you manually apply it for real so you can use Git tooling!). I find that this encourages “lazy” email reviews that only consider the immediate code context because it’s too much work to pull up more, which often waste everyone’s time because the comments turn out to be invalid when considered with more code context. Meanwhile, a forge PR can be reviewed entirely in the forge, pulling up as much code context as you need on demand with a couple clicks. Comments are tied to the code context, such that you can see all comments from different people on one piece of the code together, instead of having to walk through separate email subthreads. Other PRs can be linked directly and commit IDs are clickable. Reviewers can suggest code changes that can be applied directly with one click.
Review and commenting occurs in parallel in one place, without having to break the conversation into discrete “versions” that are re-sent as unique PRs (and often end up with duplicated discussions as new people join who missed the context). That means I can be working on discussing changes A and B while I’ve already fixed C as C’ and someone is already reviewing C’, and D is already considered good and need not be re-sent to anyone if nobody has any comments on it. The UI automatically hides obsolete comments after that particular part of the code is updated (but you can still click to read them). There is an explicit concept of “resolved” conversations so you can keep track of every review change without having to do it manually in a text file or something (or worse, in your head, and then forget a few days later if you have to set the PR aside for a bit).
It’s easy to enumerate at a glance open PRs for a project, and there is a consistent notion of “closed/merged”, unlike email where there’s no programmatic way of doing that that doesn’t involve parsing human language with heuristics. And anyone joining in from elsewhere can just do it, without worrying about being subscribed to the ML or CCed in advance, or else they don’t have context in their inbox and have to cross-reference an ML archive or manually import messages.
And actually merging the PR is way easier too, just one button click for a whole series of commits vs. using something like b4 (which isn’t even part of Git itself) to download the mbox and apply it, or doing it manually via bespoke email client workflows message by message (and then if your email client doesn’t preserve whitespace properly, you’re in trouble). Plus a PR is explicit about the base commit, while bare patches aren’t, and then you have to either guess, ask, or ask for a rebase when they don’t apply (and Git can’t do useful automatic conflict resolution without a base commit, git am just gives up, unlike a rebase where you get conflict markers etc.).
And then there’s the manual email editing, and the endless nested quotes. That’s just a poor workaround for lack of rich, fine-grained threading and grouping with context! It creates visual clutter and slows everything down, because if I’m reading an email thread in sequence now I have to skip over all the quotes which I just read, and if I’m looking at a leaf message far down it was probably trimmed too much and I’ll have to look at the parents for context anyway. Clearly if you have a data structure which is a set of messages and replies to specific code context points, grouped by author/review, the efficient way to manage it is like that, not flattening it out to emails with duplicate context to make it fit a medium that cannot efficiently represent that data structure. Consider that a review implies commenting on multiple pieces of code, and while there is value to grouping them together, the comments usually stand alone. But nobody does email review like that, one comment per email. They get grouped together in one reply, and then replies to that splinter off, but the email metadata does not tell you which part of the email, which review comment, the reply is a reply to. And on the other hand, when the review is of multiple commits which are related, email has no way of grouping those together, because you can only reply to individual patches. I can fit a dozen comments and replies in one screen in a forge including the original code, while with email I can only fit one message, which might or might not have arbitrary context which may or may not be what I need depending on what the authors did while trimming quotes. And I can scroll up and down through the discussion seamlessly, while with email I have to jump from message to message (or at best get a GMail type view which is just a heuristic and may not get the threading/context right). Email is just not, at all, the right data structure to do complex code reviews with.
There’s endless other reason to use a forge depending on what you’re doing. For example, if your project involves artwork at all, forges can display and even diff images for you, while email clients just see a huge blob of base64 (because email flows also can’t integrate with attachments, which are actually the native mechanism email has for sending files). And that’s if your change even made it to the inbox and wasn’t dropped for being too large. Some projects have multi-megabyte resources and that simply can’t work with email, while Git handles it fine, especially if it’s an efficiently delta-able binary format (or there’s git LFS, which might kind of work with email if you send the changes to the LFS blob store and only email the identifiers, but I don’t know if anyone does that and why would you do that instead of using a forge with LFS integration?). Same with better integration with CI and code quality bots (which can suggest changes or fixes, and again those can be applied without the author having to re-send the entire PR, including going through several attempts at fixing a CI problem without spamming every human in the conversation).
What may be interesting is a bridge that converts pull requests from forgefed to email, so I don’t have to ever interact with the hosting website.
There are already several solutions along these lines. You can provide email interfaces for a forge flow, because it’s easy to go from rich structured content to plain text, and degrade gracefully when replies can’t be parsed back into rich content. The converse is nearly impossible.
Honestly, my intuition is that PRs provide at least a several-fold improvement in overhead over email flow. And for small changes overhead dominates the overall time spent on the whole change. The PR flow is also much friendlier to newcomers (just ask people).
Sure, with a forge you have to create an account upfront, but that is amortized among projects using the same forge or compatible login providers (quite common these days). And quite frankly, I waste more time dealing with the overhead of a single complex email code submission and review than it takes to create a forge account from scratch, with manual email/password login (if it’s OAuth then it’s just two clicks and it beats even simple email code review overhead).
Source: I regularly contribute to both large forge flow projects (Mesa) and the only large notable email flow project (Linux) and I very, very much prefer the forge flow. Even for simple changes like this one which had no review comments and didn’t need any of the post-send PR flow features I just mentioned, the email flow gives me significantly more anxiety and mental overhead, and that’s using b4 prep/b4 send which is already a huge improvement over git send-email.
You’re allowed to feel that way. I absolutely loathe the PR review UIs I’ve had to use, and I think that the foregefed protocol is a good opportunity to allow me to ignore them completely.
The way activitypub, (and by extension forgefed), works is already extremely analogous to email. There are already projects that serve activitypub via imap. Fully bridging to email seems quite doable, and I won’t be forced to conform to your preferred workflow.
IMHO a major failing of the email based workflow is that it doesn’t preserve enough commit metadata. Including the parent commit ID would help figuring out conflicts as well as avoiding missing dependencies. If the exact commit could be transferred via email it would also help future merges and updates as Git would understand that the commit that you sent as a patch is the same as the one applied by the maintainer. Right now that information is lost and when merging upstream back into your branch it can become a huge pain to resolve all of these false conflicts.
It’s also really hard to send a follow-up v2 patch that shows up in the same thread as the original. I’m a huge email fan in general, but git send-email doesn’t actually benefit from the main advantage of email flows because it doesn’t let you send using your existing mail client you already know how to use! As a result, I mess this up like 50% of the time.
I just do git push origin HEAD:refs/for/main -o topic="branch-name" and let the magic of the AGit workflow do its thing (most recent example here). I do need an account on the forge, but if I plan to contribute to things hosted there, that’s a very small price to pay.
Other than that: I just clone the upstream repo, do my thing, and git push away. I get reviews in email, and can push my updates the same way, with a simple git push. It’s bliss, I very, very rarely have to interact with the hosting website. And even in the rare cases I do: it has an API, so I can do all my interactions through Emacs, after the initial registration.
Merging PRs is similarly doable without interacting with the site, and doesn’t even require anything but git itself.
They’ve made PRs super easy, honestly. When you push to a fork the server sends back a URL to create a PR and you just fill in the title and description like you would write in an email. If there’s only one commit, those are filled in for you. That’s less work than mailing around patches for me at least.
It’s even better when you discover the AGit workflow: you don’t even need to fork. Clone the upstream repo, branch off, do your thing, and you’re a single git push away from a PR.
No fork, no email, just git clone, git checkout -b, and git push.
I like Forgejo and I think Codeberg is doing really good work there.
On the subject of email-based workflows… as a contributor, I like to be notified if my PR ends up having conflicts with the mainline so that I can fix them, for example. As a maintainer, I like being able to see all open PRs. I like suggestions in code reviews that contributors can just accept in one click. The list goes on. I’m not against creating PRs by email, but I really wouldn’t want to be a part of a process where git send-email to a mailing list is the only available tool.
It’s not that hard to write tooling that makes opening a PR as easy as git send-mail.
The fundamental issue is that git send-mail works with email addresses, whereas PRs work with accounts on a git forge. Email addresses are in some sense more decentralized internet IDs than accounts on a git forge are; but both have serious issues.
You don’t even need to write any tooling, because it already exists. It’s called git. As long as you have an account on any Forgejo instance, you can just git push using the AGit workflow.
No need to visit the web UI, no need for a fork. Just clone the original repo, then git push your branch, and a wild PR appears.
My ideal Forge would be one that would offer all forms of workflow at once. You can use ForgeFed, you can send email to create “PR” and for internal developers/core team you can use stacked diffs.
I’ll reserve judgement but I’m not confident this is going to be a great experience for everyone. Spammers, griefers, LLMs, all able to spring up from any domain straight into your issues and PRs, with no central account management to control abuse… It’s a tough gig.
Good comparison for this would be mastodon replies. In theory anyone could spin up an instance and spam you. In practice your instance moderators do a good job on spam detection and defederating malicious instances, so this isn’t a problem
Nice, I’m (pleasantly) surprised to learn they’re working on Rust given QEMU’s object-oriented C model. I had assumed it would be too difficult to make ergonomic bindings to, but they seem to have a plan so fingers crossed it goes well.
It’s basically an easier version of glib/gtk bindings. Why easier? Because the public API is not stable so Rust work is not constrained by that (C things can change to favor Rust bindings) and because, and this was just my impression, the surface is smaller in QEMU. glib/gtk Rust bindings are great so I’m optimistic there’s a great approach to be found for QEMU as well.
Source: I introduced Rust support/bindings/device in QEMU.
Thanks for your hard work! We have a crypto accelerator written in Rust (thanks to Rivos) which connects to QEMU via a C file that sets up all the registers, objects, etc. It would be interesting to try the Rust bindings directly at some point.
I’m less concerned about topicality in this case (we have fun little trivia posts sometimes, and as long as they don’t overwhelm the queue I’m fine with it; we all need a little whimsy in our lives), but I am concerned that the poster seems to almost entirely post their own content.
Looking at their posting history it’s pretty lopsided.
I think all of those examples can answer ‘yes’ to at least one of the questions for at least some Lobsters readers. (If you’re dealing with upgrade compatibility issues for a platform you develop; if you’re interested in programming languages or systems in the niche of Gleam; if you’re building LLM-based systems; if you maintain any kind of system that has a CAPTCHA-type access control).
It’s funny, I wouldn’t have flagged this story as off-topic, but I did flag the Half Life documentary you posted as off topic. I feel like this story is on topic because it explains a weird error message, while the Half Life documentary did not give me technical insights about building or running software. What makes you feel the Half Life documentary is more on-topic?
(To be fair, while I think this story is on topic, I also feel it’s not very good.)
(To be fair, while I think this story is on topic, I also feel it’s not very good.)
I felt the same way about it. I think some exposition about __builtin_unreachable and why we might want that in release builds but something different in debug builds could have made it a good article.
But my take was “on-topic, but not very good,” which led to neither a vote nor a flag from me. It’s certainly about computing, even if it doesn’t meet those rules of thumb for a “good” submission.
As a ‘making-of’ documentary I think it’s interesting and on-topic to anyone who does game development, even as a twenty-years-later retrospective – in particular because it’s about a game that has been so massively influential. Sure, there’s a lot in it that isn’t on-topic in that sense (I don’t think an entire documentary about the Valve/Vivendi lawsuit would be on-topic), but also a lot that is. It interested me even though I’ve never done any game development (but I’ve been curious about it for a long time).
rss2email. You already have a client for email, so no need to setup anything else. I configure r2e to send digests each week (a single email with all rss entries attached as email attachments) and I have configured a local alias on my email server to quickly add/remove feeds by sending an email to a specific address (that only works with my personal address, which is only from clients authenticated locally).
You are not completely wrong, but I only “really” read my email on my main machine at home, on my work machine I occasionally open webmail if I need something, but don’t check it even daily. Same for mobile, and I wouldn’t want to read RSS feeds in K9 tbh.
The only minor complaint is that K9 has very aggressive HTML sanitization which can impact some feeds (no syntax highlighting for code examples) but overall it is a pleasant way to read.
This. You also get cross-device synchronization for free (if you use
IMAP), and you can easily build up the history log for news, if anyone
would want to go back in time to see what was hot in 2012.
I find it funny (this remind me of the old “for the lulz” internet I liked as a teenager), and sad at the same time (the web was designed to link documents, referrer hijaking is usually used by jerks, such as newspapers or science journals putting paywalls when it was linked from the wrong place.)
Yep, that’s the one. When I first saw it I thought it was kind of childish and crass, but then again, so is much of the discourse on the orange site, so perhaps it’s not entirely inappropriate.
Location: Full remote. UK or USA are easy, other locales may be possible.
Description:
SCI Semiconductor is a startup that aims to ship and support CHERIoT microcontrollers. We currently maintain a fork of LLVM with CHERIoT support. This includes custom attributes in clang, tweaks to some mid-level optimisers, support for the ISA in code gen, some extensions for linking compartmentalised software in LLD and will grow to include LLDB support for our targets.
This role will include updating our current LLVM fork and upstreaming most of it to LLVM and long-term maintenance of that code upstream. It will also include evolution of the language features, support for other languages (such as Rust), and feedback on the long-term evolution of the ISA. A willingness to collaborate with upstream LLVM (soliciting reviews, incorporating feedback, and so on) is essential.
We are aiming to hire two candidates and can accommodate different levels of experience.
Tech stack: We build CHERIoT chips! Across the company, we work on hardware, RTOS, compilers, and supporting infrastructure. For this job, LLVM is written in C++, but if you didn’t know that already then you might not have the required experience.
Compensation:
Base salary: £60-75K for a more junior applicant, £80-100K for more senior.
Total compensation will also include magic beans share options, which are worth something between zero and infinite currency units (we are a young startup).
I wrote our leave policy, so it’s not stupid and assumes that leave is an obligation that you have to us to make sure that you remain sufficiently relaxed that you are able to work productively, not a gift that we give you for being good little drones. You may not go more than two months without taking time off. For tax and accounting purposes (accounting fun and for calculating due salary in case of departure) you have 25 days of leave (not including public holidays). Paid time off has no hard limit (if you take more than 35 days, your manager is required to notify his manager, because this might be an indication that a team is overburdened and close to burnout, or someone has a long-term issue that may require cover), just a requirement to be a grownup about it. As a manager, I would be worried if someone took less than 25 days and would expect 25-35 to be fairly normal in the absence of family / medical crises.
Contact: Me. Happy to take questions here (this thread or private messages). Apply at info@scisemi.com
out of curiosity, how did people in your current team end up getting the experience to be an LLVM compiler engineer? I’ve always been curious about this kind of work but it all seems a bit “5 years experience required”, leading me to wonder how I can even get my foot in the door.
We’re just starting to build the compiler team, so the only person with LLVM experience is me currently. I wrote a lot of the CHERI LLVM bits, some is done the right way, some is done the way that seemed right before we learned more, and some is done the way that made it work before a deadline. The new team will get to rip out all of the bad bits and point and laugh at some of my code.
I started looking at LLVM in 2007 and built a few toy compilers with it. I started working on clang when I decided that getting GCC to support modern Objective-C was too hard, so I added IR generation for Objective-C to clang for the GCC runtime (clang could compile Objective-C on non-Apple platforms before Apple ones as a result). These patches landed in 2008. I then did a load of FreeBSD fixes and hung around in the LLVM mailing lists and IRC and got some consulting word (including the Solaris and FreeBSD ports of libc++ and associated compiler bits) and kept working on things of personal interest. In 2012 I joined the team at Cambridge to lead the compiler / languages strand of the CHERI research and I’ve mostly been doing CHERI focused bits of LLVM since then. Alex Richardson and Jessica Clarke mostly maintained it after I moved to Microsoft and my compiler work has been in a downstream form of theirs.
So, TL;DR: Mostly by accident. I wanted a working Objective-C compiler and got sidetracked.
I’d love to apply for this this, but dealing with more C++ would probably make me hate my life pretty quickly. I should probably actually learn LLVM someday though…
This sounds really exciting. I worked on Mill Computing’s custom LLVM backend for genAsm. (We couldn’t work from IR because we needed memory access order dependency details, which IR omitted.)
One of my key contributions was improving the runtime complexity of our memory dependency oracle from O(n^4) to amortized quadratic.
I’ll take some time to read up on SCI and CHERIoT, but you’ll be hearing from me. Cheers!
P.S. Your website is lightweight, readable, and works with NoScript — it gets the job done.
P.P.S. s/centre’s/centres/
P.P.P.S. I love the subtle reference to Isaac Newton.
But ‘your’, do you mean LLVM’s? There’s almost no C in LLVM, but the back ends use a DSL called TableGen in addition to C++, which defines pattern matching. It’s better than the mess of C macros that GCC uses (used?) but it’s really painful to debug (the inputs are not always clear, the outputs are state machines encoded in ten-thousand-element arrays).
The current CHERIoT toolchain is LLVM and we support C and C++ (Objective-C would be fun, but no one apart from me actually wants it. I did Objective-C bringup on CHERI MIPS ages ago but not targeting embedded systems). There’s parallel work that’s connected CHERI LLVM to rustc. I’d like to see that working with CHERIoT and for CHERIoT Rust to reach (and exceed) parity with the C/C++ language extensions that we have for compartmentalisation.
To guide usage and head off distracting meta conversations (“Why was this flagged!?”, etc), flagging requires selecting from a preset list of reasons. […] “Spam” for links that promote a commercial service.
I wish the time crate was merged into the stdlib. Everyone depends on it, and it regularly either breaks support for old rustc in a minor version, or rustc breaks support for compiling an old version of time.
I’m not sure that would be a good idea since there’s a second major datetime crate in widespread use (and there was a post on here recently about a third).
Whether that’s a good thing or not, I think the std philosophy is not to include things unless there’s one obvious and uncontroversial API and implementation. There are caveats to that, and maybe this is one, but maybe not.
I agree with the “no extra fluff in std” decision even if it’s painful; sometimes the best action is not what’s most pleasant. I’d cheer for a rust team effort to have a “batteries” crate, with no strong guarantees like the rest of rust, shipped with the non-minimal profile of rustup and is opt-in (like std is opt-out, currently). And if modules get unmaintained and deprecated like in python’s standard library, they can be removed and users can fallback to an eponymous crate on crates.io maintained by rust-lang.
I’m not sure that would be a good idea since there’s a second major datetime crate in widespread use (and there was a post on here recently about a third).
I don’t know that we would have any of them if there were a std time, not because it would kill people’s joy to do the work, but because I think some of these crates only exist because:
We needed a first crate, because it wasn’t in standard
That crate was in a confusing state, so we got a second crate
Maybe there are others but idk, at least the first 2 didn’t need to exist as far as I am aware. I don’t think Chrono diverges wildly from time in terms of API.
Everyone depends on time? I never see time used, actually I always assumed it was a dead project (I never looked at how active it is). I use chrono everywhere, because that’s the one I see everyone use.
Actually, the fact that std has Duration and chrono also has a Duration but now it’s deprecated but also in this weird limbo where chrono half-uses it’s own Duration and sorta-mostly-uses std‘s Duration and then there’s some more old code lying around that wants chrono‘s Duration because it was made before std got it. I kinda wish stddidn’t add it’s own Duration so we could have standardized on chrono‘s. There’s a few things in std that shouldn’t be there, in fact I think even a core developer said Error itself was a mistake, and I agree. I’ve gotten very comfortable with the “build your own language” philosophy Rust has gotten, I almost even think std should be ripped out entirely, only salvaging all of it’s traits, adding a few more (especially to abstract async runtimes!) and putting them into several community-driven crates. I don’t strongly believe that should actually happen, mind you. It’s far too late for that, more of a retrospective idea.
I often see time as a deeply nested transitive dependency. Crates that directly depend on time of crates seemingly just want to get the current time. The top ones (according to crates.io stats):
rustls and a bunch of X.509-related parsers,
humantime (itself dependency of a clap and a bunch of logging libraries),
tracing-subscriber and tracing (tokio, hyper, h2, tower, axum, tonic, AWS stuff, Sentry and OpenTelemetry, some other logging libraries, tokio-postgresql, color-eyre)
time has about as many downloads and a release cadence similar to chrono.
Can you expand on this? Why would you want ownership to do the state transition? Why is &mut self bad?
Perhaps not with &mut self specifically, but as it currently stands, I am first handling the new state, before mutating self.state = state. The issue being, failure may occur, causing the transitioned state to be lost, and leaving the worker in an inconsistent state.
I’d prefer a simpler handle_event(self, event: Event), which (a) performs the transitions only and (b) gives us back the worker with the new state which we can match and action. Not sure if I’m articulating it as well as I should.
Why do you need that?
I’d like to be able to get the new state more idiomatically:
if let Ok(state) = self.handle_event(event).await {
// Do something with new state
}
Versus:
if self.handle_event(event).await.is_ok() { // Check
let state = self.state; // Use
}
I hate to spoil the fun, but can someone please describe what the point of this repository is? All I can find in the README are more repeating e’s, and when reading that with a screen reader, any patterns that one is meant to find in there don’t come through.
There is no obvious and no specific point to the repository. The name and README are simply repeating e’s and people have contributed many small different programs in various languages that do something whimsical related to the letter e or the mathematical constant with the same name. For example the Haskell file in the repository is probably the shortest valid Haskell code that prints e in a loop:
main = putStr $ cycle "e"
There are also visual gags, such as implementing a program in Conway’s Game of Life cellular automatons that has cells sliding to the right and “printing” the e character by leaving dead cells behind on the grid which form the letter figure, like pixels.
Did you intend this as a serious attempt to answer mwcampbell’s question?
mwcampbell says “All I can find in the README are more repeating e’s”; it seems to me very unhelpful to reply with even more repeating ‘e’s without making any attempt to explain their significance.
Really glad about the temporary lifetime extensions. Now we just need to be able to call &mut self functions that mutate fields in a struct while non-mutably borrowing unrelated fields in the same struct. There’s been so many times were I had to write ugly “god methods” just because the borrow checker couldn’t figure out I wasn’t mutating something that was also borrowed when trying to simply split up a function.
I was also trying to figure out a solution for that problem a while back. I was proposing something tangentially related on the Rust forum, and someone mentioned a concept called view types. I quickly realized that can be used to solve this “partial borrow” problem as I call it.
Consider a syntax like this:
struct Type {
a: i32,
b: i32,
}
impl Trait for Type {
fn func1(&{a} self) -> &u32 { ... };
}
impl Type {
fn func2(&{b} self) -> &u32 { ... };
}
The & {a} part denotes which members the function has access to.
I ended up dropping it because it was way too big of a syntax for me to pursuit, and it didn’t really generate much interests on the forum anyway.
I like this a lot. It feels like you’re basically deconstructing the Self type into an anonymous substructural type, but in a way that the borrow checker understands is exclusive.
That’s an interesting syntax, but it’s not really much more different than just making static functions that mutably borrows fields through arguments anyway. You can just replace &{a} self with &mut i32 and it would be relatively similar (or ${a, b, c} self with just the types). That’s the primary issue with not being able to call &mut self functions when non-mutably borrowing unrelated fields, because otherwise you just have to use a static function. More of a problem of clean syntax than lifetime accessibility.
I do want to echo insanitybit’s comment though, it is a very interesting idea to “deconstruct” self into it’s fields. It’s probably worth doing some R&D into.
Using this syntax is a lot easier than static methods IMO. You don’t need to repeat types of fields and it’s possible to call methods like you normally would (self.func()). And because they are types you can imagine creating aliases for common combinations: type TypeA = {a,b} TypeB
I feel like Rust having special syntax for self makes this weird and special cased. If “methods” in Rust were just static functions that accepted the Self type as the first argument syntactically (already is semantically), something like
I’d definitely vote for the second and only the second, no need to extend the (very nice) syntactic sugar to a case where it might be confusing.
For those who aren’t aware, that’s already valid rust provided you replace self (lowercase s) with this. You just can’t use method call syntax to call it if you do that (and it doesn’t do the proposed partial borrowing currently, you have to fully destructure the structure).
Now we just need to be able to call &mut self functions that mutate fields in a struct while non-mutably borrowing unrelated fields in the same struct.
New annotations will be required to enable that on the functions you’re calling, given Rust’s “the function signature is the point of API stability” policy. Otherwise, changing the implementation could change whether code that does that will compile.
Yeah, I know it’s a non-trivial problem to solve, just one of those “I really hope they figure it out one day” things. It should be possible to actually look into a method (at least a method, maybe not all functions) to see if there are any mutations to anything non-mutably borrowed before the method call. But that would probably be an entire architectural overhaul to the borrow checker, so I’m not holding my breath. I only really bring it up because it does feel like a “bug” in the borrow checker when actually encountering it, because I technically am doing something valid, it just can’t see that deep. You’re right though, a new type of annotation might indeed be a good fix for it.
I don’t disagree… you just seem to be missing that it’s not about “should be possible”.
It should be possible to actually look into a method (at least a method, maybe not all functions)
As with Rust demanding explicit types for arguments and returns on non-closure functions, it’s an intentional restriction in the name of making it easier to achieve “if it compiles with dependency version X, it should continue to compile with any later semver-compatible version”.
The new type of annotation would be necessary to achieve a solution within that paradigm so that the compilation failure can reliably surface on the dependency author’s end, when the compiler says “You promised you wouldn’t access that member in this function and now you’re trying to do so”.
Performing the initial installation of an Operating System to the Ampere Altra Developer Platform.
I had a problem finding an extra monitor when working on the Ampere Altra too, I ended up getting an hdmi to displayport adapter to connect it to a monitor that was out of HDMI inputs :)
By the way, if the author is here: the twitter embedded images are not visible without login (to me at least), could you upload them somewhere else?
That’s great to hear. The JLCPCB integration sounds useful. I probably should try out the JLCPCB plugin for KiCAD next time I’m making a board for similar integration.
Off topic, but I recently encountered a weirdness in HTML and this seems like a thread where someone might understand why:
I have an SVG image that contains some JPEG images referenced via the SVG image attribute. Browsers display it fine. If I reference it via an HTML img tag, the SVG vector images display fine, but the raster files are not loaded (no errors in the debugging tools, they just don’t get loaded). If I reference it via an HTML object tag, the browser displays them correctly.
This is not a browser bug. Chrome, Firefox, and Safari all have the same behaviour, so I presume this is actually specified and intentional behaviour, I just have no idea why this would be what people want.
There is a difference between SVG being rendered as a document amd SVG rendered as an image. Sadly, I don’t know there that line is drawn and what is and isn’t supposed to be included in documents vs images. A typical example that I am aware of is JavaScript. Embedding something via shouldn’t allow scripts.
Can you upload a test case somewhere?
MDN is reasonably clear.
That’s a great description indeed. To quote:
Couldn’t find a link to the proper specification text though. The one on MDN seems wrong. :-(
I assume a good chunk of the why is “we started it that way and didnt see a reason to try change it”, but images are in HTML pretty much defined to be things that can be fetched in one request and then displayed in one go, there is no room made for them to cause subsequent requests (which could cause layout shifts etc further down the line).
I am not sure how that would apply. The .jpeg and .svg files are in the same directory on the web server and that is a subdirectory of the directory containing the HTML.
The fix here (if you need to work with the img tag) is to preprocess the SVG to bake the images into it by changing their
hrefs todata:URLs. They don’t count as “external resources” in that case.Company: Apple Inc.
Company site: https://www.apple.com
Position(s): Core OS Software Engineer - Darwin Server
Location: On-Site - London, UK
Description: Work on developing the core of iOS and macOS into an operating system for use in the cloud, to power services like Private Cloud Compute.
Tech stack: C, Objective-C, Swift // iOS and macOS
Compensation: See job posting above.
Contact: Apply at job posting above.
[Duplicate from the last quarter’s “Who’s Hiring?” post, but I am still actively seeking candidates for this role.]
If it’s the same as the previous month, this link should be https://jobs.apple.com/en-us/details/200567238/swe-core-os-software-engineer-darwin-server
🤦♂️ Yes, thank you! That’s what I get for copy/paste.
I love that the default theme seems to be mathematically generated? https://github.com/ghostty-org/ghostty/blob/main/src/terminal/color.zig Care to write a little about how you came up with this design?
This function looks like it computes the standard 256 Xterm palette at compile-time. https://upload.wikimedia.org/wikipedia/commons/1/15/Xterm_256color_chart.svg
This explains why I couldn’t figure out what the default theme was! That was my main onboarding annoyance actually - I couldn’t find the default colour scheme so I couldn’t configure nvim/helix/bat/etc to match the terminal.
Someone linked me to their codeberg repo the other day and I was amazed how slick it was. If the forgefed protocol ever really gets off the ground (cross-instance pull requests!) I think forgejo becomes unstoppable. I get that email-based patch workflows are already federated but I just haven’t got around to learning it and PRs are pretty intuitive.
I did some poking around and honestly, Forgejo looks like everything I’d want out of a forge these days. I’m a bit surprised to see it even includes CI. A lot of smaller companies should probably be using this instead of Gitlab.
Have the Forgejo developers shown any interest in supporting self-hosted CI runners on Windows and macOS? Or is that specifically out of scope for them because those platforms are proprietary?
I believe there isn’t an active movement for using anything outside of their fork of
act, however their docs stateSo, technically speaking, someone could write a runner that runs on any platform that can connect and respond to the protocol (and what happens after that seems to be up to the runner itself).
I may be mistaken, but I think they just don’t provide pre-built binaries for those OSes. But you should be able to build
forgejo-runneron your own for them.Hah maybe I should have a crack at it. I really don’t like the act/GitHub Actions based runners, though.
I had another look and the runner seems to build fine for/on Windows.
PRs are so much work compared to
git send-email --to list@project.com, or piping the current email togit am.What may be interesting is a bridge that converts pull requests from forgefed to email, so I don’t have to ever interact with the hosting website.
The proportion of software engineers who have the living knowledge base of how to use PRs seems far greater than those possessing the knowledge of how to effectively use
git send-email. Maybe it’s true thatgit send-emailis much less work once you know it (I don’t know, never tried, only project I know of that uses it is the Linux kernel) but any “less work” analysis will have to account for the work of training others how to use it, amortized over the number of patches they send. And for open source projects seeking contributors, removing friction to initial contributions is everything.I really don’t think PRs are more work. I just
git push myorigin, and it prints a URL. I click it and, if it’s a simple case, just click Create PR (if it’s a complicated case you have to write a cover letter, just like you do with email). It takes longer to figure out what email address to send to forgit send-emailthan those two clicks.The real benefit of forge PRs comes after the initial send. I can force push to update the PR instead of having to resend emails, as often as I want, without spamming people. Countless times I noticed a mistake after the fact and quickly fixed it without having to bother anyone.
All review comments on the PR are linked in one convenient place and with a rich UI where you can expand code context without having to cross-reference a code editor manually. It’s almost impossible to review complex email patches without manually digging up context (and visualizing how the patch applies mentally, unless you manually apply it for real so you can use Git tooling!). I find that this encourages “lazy” email reviews that only consider the immediate code context because it’s too much work to pull up more, which often waste everyone’s time because the comments turn out to be invalid when considered with more code context. Meanwhile, a forge PR can be reviewed entirely in the forge, pulling up as much code context as you need on demand with a couple clicks. Comments are tied to the code context, such that you can see all comments from different people on one piece of the code together, instead of having to walk through separate email subthreads. Other PRs can be linked directly and commit IDs are clickable. Reviewers can suggest code changes that can be applied directly with one click.
Review and commenting occurs in parallel in one place, without having to break the conversation into discrete “versions” that are re-sent as unique PRs (and often end up with duplicated discussions as new people join who missed the context). That means I can be working on discussing changes A and B while I’ve already fixed C as C’ and someone is already reviewing C’, and D is already considered good and need not be re-sent to anyone if nobody has any comments on it. The UI automatically hides obsolete comments after that particular part of the code is updated (but you can still click to read them). There is an explicit concept of “resolved” conversations so you can keep track of every review change without having to do it manually in a text file or something (or worse, in your head, and then forget a few days later if you have to set the PR aside for a bit).
It’s easy to enumerate at a glance open PRs for a project, and there is a consistent notion of “closed/merged”, unlike email where there’s no programmatic way of doing that that doesn’t involve parsing human language with heuristics. And anyone joining in from elsewhere can just do it, without worrying about being subscribed to the ML or CCed in advance, or else they don’t have context in their inbox and have to cross-reference an ML archive or manually import messages.
And actually merging the PR is way easier too, just one button click for a whole series of commits vs. using something like b4 (which isn’t even part of Git itself) to download the mbox and apply it, or doing it manually via bespoke email client workflows message by message (and then if your email client doesn’t preserve whitespace properly, you’re in trouble). Plus a PR is explicit about the base commit, while bare patches aren’t, and then you have to either guess, ask, or ask for a rebase when they don’t apply (and Git can’t do useful automatic conflict resolution without a base commit,
git amjust gives up, unlike a rebase where you get conflict markers etc.).And then there’s the manual email editing, and the endless nested quotes. That’s just a poor workaround for lack of rich, fine-grained threading and grouping with context! It creates visual clutter and slows everything down, because if I’m reading an email thread in sequence now I have to skip over all the quotes which I just read, and if I’m looking at a leaf message far down it was probably trimmed too much and I’ll have to look at the parents for context anyway. Clearly if you have a data structure which is a set of messages and replies to specific code context points, grouped by author/review, the efficient way to manage it is like that, not flattening it out to emails with duplicate context to make it fit a medium that cannot efficiently represent that data structure. Consider that a review implies commenting on multiple pieces of code, and while there is value to grouping them together, the comments usually stand alone. But nobody does email review like that, one comment per email. They get grouped together in one reply, and then replies to that splinter off, but the email metadata does not tell you which part of the email, which review comment, the reply is a reply to. And on the other hand, when the review is of multiple commits which are related, email has no way of grouping those together, because you can only reply to individual patches. I can fit a dozen comments and replies in one screen in a forge including the original code, while with email I can only fit one message, which might or might not have arbitrary context which may or may not be what I need depending on what the authors did while trimming quotes. And I can scroll up and down through the discussion seamlessly, while with email I have to jump from message to message (or at best get a GMail type view which is just a heuristic and may not get the threading/context right). Email is just not, at all, the right data structure to do complex code reviews with.
There’s endless other reason to use a forge depending on what you’re doing. For example, if your project involves artwork at all, forges can display and even diff images for you, while email clients just see a huge blob of base64 (because email flows also can’t integrate with attachments, which are actually the native mechanism email has for sending files). And that’s if your change even made it to the inbox and wasn’t dropped for being too large. Some projects have multi-megabyte resources and that simply can’t work with email, while Git handles it fine, especially if it’s an efficiently delta-able binary format (or there’s git LFS, which might kind of work with email if you send the changes to the LFS blob store and only email the identifiers, but I don’t know if anyone does that and why would you do that instead of using a forge with LFS integration?). Same with better integration with CI and code quality bots (which can suggest changes or fixes, and again those can be applied without the author having to re-send the entire PR, including going through several attempts at fixing a CI problem without spamming every human in the conversation).
There are already several solutions along these lines. You can provide email interfaces for a forge flow, because it’s easy to go from rich structured content to plain text, and degrade gracefully when replies can’t be parsed back into rich content. The converse is nearly impossible.
Honestly, my intuition is that PRs provide at least a several-fold improvement in overhead over email flow. And for small changes overhead dominates the overall time spent on the whole change. The PR flow is also much friendlier to newcomers (just ask people).
Sure, with a forge you have to create an account upfront, but that is amortized among projects using the same forge or compatible login providers (quite common these days). And quite frankly, I waste more time dealing with the overhead of a single complex email code submission and review than it takes to create a forge account from scratch, with manual email/password login (if it’s OAuth then it’s just two clicks and it beats even simple email code review overhead).
Source: I regularly contribute to both large forge flow projects (Mesa) and the only large notable email flow project (Linux) and I very, very much prefer the forge flow. Even for simple changes like this one which had no review comments and didn’t need any of the post-send PR flow features I just mentioned, the email flow gives me significantly more anxiety and mental overhead, and that’s using
b4 prep/b4 sendwhich is already a huge improvement overgit send-email.You’re allowed to feel that way. I absolutely loathe the PR review UIs I’ve had to use, and I think that the foregefed protocol is a good opportunity to allow me to ignore them completely.
The way activitypub, (and by extension forgefed), works is already extremely analogous to email. There are already projects that serve activitypub via imap. Fully bridging to email seems quite doable, and I won’t be forced to conform to your preferred workflow.
IMHO a major failing of the email based workflow is that it doesn’t preserve enough commit metadata. Including the parent commit ID would help figuring out conflicts as well as avoiding missing dependencies. If the exact commit could be transferred via email it would also help future merges and updates as Git would understand that the commit that you sent as a patch is the same as the one applied by the maintainer. Right now that information is lost and when merging upstream back into your branch it can become a huge pain to resolve all of these false conflicts.
It’s also really hard to send a follow-up v2 patch that shows up in the same thread as the original. I’m a huge email fan in general, but
git send-emaildoesn’t actually benefit from the main advantage of email flows because it doesn’t let you send using your existing mail client you already know how to use! As a result, I mess this up like 50% of the time.git has a way to attach this and it’s suggested eg. for kernel patches: https://people.kernel.org/monsieuricon/all-patches-must-include-base-commit-info
Agreed on other points.
I just do
git push origin HEAD:refs/for/main -o topic="branch-name"and let the magic of the AGit workflow do its thing (most recent example here). I do need an account on the forge, but if I plan to contribute to things hosted there, that’s a very small price to pay.Other than that: I just clone the upstream repo, do my thing, and
git pushaway. I get reviews in email, and can push my updates the same way, with a simplegit push. It’s bliss, I very, very rarely have to interact with the hosting website. And even in the rare cases I do: it has an API, so I can do all my interactions through Emacs, after the initial registration.Merging PRs is similarly doable without interacting with the site, and doesn’t even require anything but git itself.
Forgejo + AGit is <3.
They’ve made PRs super easy, honestly. When you push to a fork the server sends back a URL to create a PR and you just fill in the title and description like you would write in an email. If there’s only one commit, those are filled in for you. That’s less work than mailing around patches for me at least.
It’s even better when you discover the AGit workflow: you don’t even need to fork. Clone the upstream repo, branch off, do your thing, and you’re a single
git pushaway from a PR.No fork, no email, just
git clone,git checkout -b, andgit push.That’s how gerrit (which I mostly use for work) does it, and I find the GitHub PR flow so confusing and crufty in comparison.
I like Forgejo and I think Codeberg is doing really good work there.
On the subject of email-based workflows… as a contributor, I like to be notified if my PR ends up having conflicts with the mainline so that I can fix them, for example. As a maintainer, I like being able to see all open PRs. I like suggestions in code reviews that contributors can just accept in one click. The list goes on. I’m not against creating PRs by email, but I really wouldn’t want to be a part of a process where
git send-emailto a mailing list is the only available tool.It’s not that hard to write tooling that makes opening a PR as easy as
git send-mail.The fundamental issue is that
git send-mailworks with email addresses, whereas PRs work with accounts on a git forge. Email addresses are in some sense more decentralized internet IDs than accounts on a git forge are; but both have serious issues.You don’t even need to write any tooling, because it already exists. It’s called
git. As long as you have an account on any Forgejo instance, you can justgit pushusing the AGit workflow.No need to visit the web UI, no need for a fork. Just clone the original repo, then git push your branch, and a wild PR appears.
My ideal Forge would be one that would offer all forms of workflow at once. You can use ForgeFed, you can send email to create “PR” and for internal developers/core team you can use stacked diffs.
I’ll reserve judgement but I’m not confident this is going to be a great experience for everyone. Spammers, griefers, LLMs, all able to spring up from any domain straight into your issues and PRs, with no central account management to control abuse… It’s a tough gig.
Good comparison for this would be mastodon replies. In theory anyone could spin up an instance and spam you. In practice your instance moderators do a good job on spam detection and defederating malicious instances, so this isn’t a problem
Nice, I’m (pleasantly) surprised to learn they’re working on Rust given QEMU’s object-oriented C model. I had assumed it would be too difficult to make ergonomic bindings to, but they seem to have a plan so fingers crossed it goes well.
It’s basically an easier version of glib/gtk bindings. Why easier? Because the public API is not stable so Rust work is not constrained by that (C things can change to favor Rust bindings) and because, and this was just my impression, the surface is smaller in QEMU. glib/gtk Rust bindings are great so I’m optimistic there’s a great approach to be found for QEMU as well.
Source: I introduced Rust support/bindings/device in QEMU.
Thanks for your hard work! We have a crypto accelerator written in Rust (thanks to Rivos) which connects to QEMU via a C file that sets up all the registers, objects, etc. It would be interesting to try the Rust bindings directly at some point.
Flagged as off-topic because the answer to all three topicality questions is a resounding ‘no’, I think.
I’m less concerned about topicality in this case (we have fun little trivia posts sometimes, and as long as they don’t overwhelm the queue I’m fine with it; we all need a little whimsy in our lives), but I am concerned that the poster seems to almost entirely post their own content.
Looking at their posting history it’s pretty lopsided.
By those metrics, half of the front page is off-topic. For some examples, all of these would be considered off-topic by your argument: “Why did Windows 95 setup use three operating systems?”, “Gleam v1.6.0 released”, “ChatGPT is Slipping”, “I was banned from the hCaptcha accessibility account for not being blind”. Not to mention that it says those are “rules of thumb for great stories to submit”, not the end all be all of what and what not to post.
I think all of those examples can answer ‘yes’ to at least one of the questions for at least some Lobsters readers. (If you’re dealing with upgrade compatibility issues for a platform you develop; if you’re interested in programming languages or systems in the niche of Gleam; if you’re building LLM-based systems; if you maintain any kind of system that has a CAPTCHA-type access control).
It’s funny, I wouldn’t have flagged this story as off-topic, but I did flag the Half Life documentary you posted as off topic. I feel like this story is on topic because it explains a weird error message, while the Half Life documentary did not give me technical insights about building or running software. What makes you feel the Half Life documentary is more on-topic?
(To be fair, while I think this story is on topic, I also feel it’s not very good.)
I felt the same way about it. I think some exposition about
__builtin_unreachableand why we might want that in release builds but something different in debug builds could have made it a good article.But my take was “on-topic, but not very good,” which led to neither a vote nor a flag from me. It’s certainly about computing, even if it doesn’t meet those rules of thumb for a “good” submission.
As a ‘making-of’ documentary I think it’s interesting and on-topic to anyone who does game development, even as a twenty-years-later retrospective – in particular because it’s about a game that has been so massively influential. Sure, there’s a lot in it that isn’t on-topic in that sense (I don’t think an entire documentary about the Valve/Vivendi lawsuit would be on-topic), but also a lot that is. It interested me even though I’ve never done any game development (but I’ve been curious about it for a long time).
Good point, all other off-topic stories should be flagged as well.
https://en.wikipedia.org/wiki/Whataboutism
rss2email. You already have a client for email, so no need to setup anything else. I configure
r2eto send digests each week (a single email with all rss entries attached as email attachments) and I have configured a local alias on my email server to quickly add/remove feeds by sending an email to a specific address (that only works with my personal address, which is only from clients authenticated locally).EDIT: I had uploaded “instructions” long long ago, I just remembered. https://gist.github.com/epilys/fe616b2de4e53bdfc0e1189afa438a90
You are not completely wrong, but I only “really” read my email on my main machine at home, on my work machine I occasionally open webmail if I need something, but don’t check it even daily. Same for mobile, and I wouldn’t want to read RSS feeds in K9 tbh.
This is what I do and have no major complaints.
The only minor complaint is that K9 has very aggressive HTML sanitization which can impact some feeds (no syntax highlighting for code examples) but overall it is a pleasant way to read.
This. You also get cross-device synchronization for free (if you use IMAP), and you can easily build up the history log for news, if anyone would want to go back in time to see what was hot in 2012.
Congrats on being approved by the orange conversion bot
This is just a repost bot that posts everything from lobste.rs. The guy is running some automation SaaS and is using it to promote his services on HN.
I think it’s worth banning their crawling IPs from lobste.rs simply out of spite. :P
i take advantage of that guy’s bot to give myself an extra upvote on things i would otherwise post to hn..
I’m pretty sure the repost service uses the RSS feed.
And what, the RSS feed is not retrieved by the reposter’s service? Not sure what you’re trying to say.
The more I see how things are posted on orange site, the more I start to think jwz had the right idea there…
I had to look it up to find the context on this. TIL: https://news.ycombinator.com/item?id=14840839
I find it funny (this remind me of the old “for the lulz” internet I liked as a teenager), and sad at the same time (the web was designed to link documents, referrer hijaking is usually used by jerks, such as newspapers or science journals putting paywalls when it was linked from the wrong place.)
Yep, that’s the one. When I first saw it I thought it was kind of childish and crass, but then again, so is much of the discourse on the orange site, so perhaps it’s not entirely inappropriate.
Mildly on-topic, there’s a link aggregator for retrocomputing content called two stop bits: https://twostopbits.com/news
Wow, we’ve been really slow getting the job ad up, but it’s there now!. And has been for several minutes!
Company: SCI Semiconductor
Company site: https://www.scisemi.com. The web site is terrible. Please don’t judge me!
Position(s): LLVM compiler engineers.
Location: Full remote. UK or USA are easy, other locales may be possible.
Description:
SCI Semiconductor is a startup that aims to ship and support CHERIoT microcontrollers. We currently maintain a fork of LLVM with CHERIoT support. This includes custom attributes in clang, tweaks to some mid-level optimisers, support for the ISA in code gen, some extensions for linking compartmentalised software in LLD and will grow to include LLDB support for our targets.
This role will include updating our current LLVM fork and upstreaming most of it to LLVM and long-term maintenance of that code upstream. It will also include evolution of the language features, support for other languages (such as Rust), and feedback on the long-term evolution of the ISA. A willingness to collaborate with upstream LLVM (soliciting reviews, incorporating feedback, and so on) is essential.
We are aiming to hire two candidates and can accommodate different levels of experience.
Tech stack: We build CHERIoT chips! Across the company, we work on hardware, RTOS, compilers, and supporting infrastructure. For this job, LLVM is written in C++, but if you didn’t know that already then you might not have the required experience.
Compensation:
Base salary: £60-75K for a more junior applicant, £80-100K for more senior.
Total compensation will also include
magic beansshare options, which are worth something between zero and infinite currency units (we are a young startup).I wrote our leave policy, so it’s not stupid and assumes that leave is an obligation that you have to us to make sure that you remain sufficiently relaxed that you are able to work productively, not a gift that we give you for being good little drones. You may not go more than two months without taking time off. For tax and accounting purposes (accounting fun and for calculating due salary in case of departure) you have 25 days of leave (not including public holidays). Paid time off has no hard limit (if you take more than 35 days, your manager is required to notify his manager, because this might be an indication that a team is overburdened and close to burnout, or someone has a long-term issue that may require cover), just a requirement to be a grownup about it. As a manager, I would be worried if someone took less than 25 days and would expect 25-35 to be fairly normal in the absence of family / medical crises.
Contact: Me. Happy to take questions here (this thread or private messages). Apply at info@scisemi.com
out of curiosity, how did people in your current team end up getting the experience to be an LLVM compiler engineer? I’ve always been curious about this kind of work but it all seems a bit “5 years experience required”, leading me to wonder how I can even get my foot in the door.
We’re just starting to build the compiler team, so the only person with LLVM experience is me currently. I wrote a lot of the CHERI LLVM bits, some is done the right way, some is done the way that seemed right before we learned more, and some is done the way that made it work before a deadline. The new team will get to rip out all of the bad bits and point and laugh at some of my code.
I started looking at LLVM in 2007 and built a few toy compilers with it. I started working on clang when I decided that getting GCC to support modern Objective-C was too hard, so I added IR generation for Objective-C to clang for the GCC runtime (clang could compile Objective-C on non-Apple platforms before Apple ones as a result). These patches landed in 2008. I then did a load of FreeBSD fixes and hung around in the LLVM mailing lists and IRC and got some consulting word (including the Solaris and FreeBSD ports of libc++ and associated compiler bits) and kept working on things of personal interest. In 2012 I joined the team at Cambridge to lead the compiler / languages strand of the CHERI research and I’ve mostly been doing CHERI focused bits of LLVM since then. Alex Richardson and Jessica Clarke mostly maintained it after I moved to Microsoft and my compiler work has been in a downstream form of theirs.
So, TL;DR: Mostly by accident. I wanted a working Objective-C compiler and got sidetracked.
I’d love to apply for this this, but dealing with more C++ would probably make me hate my life pretty quickly. I should probably actually learn LLVM someday though…
This sounds really exciting. I worked on Mill Computing’s custom LLVM backend for genAsm. (We couldn’t work from IR because we needed memory access order dependency details, which IR omitted.)
One of my key contributions was improving the runtime complexity of our memory dependency oracle from O(n^4) to amortized quadratic.
I’ll take some time to read up on SCI and CHERIoT, but you’ll be hearing from me. Cheers!
P.S. Your website is lightweight, readable, and works with NoScript — it gets the job done.
P.P.S. s/centre’s/centres/
P.P.P.S. I love the subtle reference to Isaac Newton.
Out of curiosity, is your codegen in C or C++?
But ‘your’, do you mean LLVM’s? There’s almost no C in LLVM, but the back ends use a DSL called TableGen in addition to C++, which defines pattern matching. It’s better than the mess of C macros that GCC uses (used?) but it’s really painful to debug (the inputs are not always clear, the outputs are state machines encoded in ten-thousand-element arrays).
The current CHERIoT toolchain is LLVM and we support C and C++ (Objective-C would be fun, but no one apart from me actually wants it. I did Objective-C bringup on CHERI MIPS ages ago but not targeting embedded systems). There’s parallel work that’s connected CHERI LLVM to rustc. I’d like to see that working with CHERIoT and for CHERIoT Rust to reach (and exceed) parity with the C/C++ language extensions that we have for compartmentalisation.
this is blog spam
I don’t agree, it contains factual, actionable information on how to check your system for the affected systemd services and listening ports.
My Ubuntu server VPS was unaffected, my home desktop was affected but I never print so I feel unaffected.
From About > Ranking:
So, if you flagged the post as spam, please undo.
From that ‘about’ link:
So this is an “already posted” submission? Should this be merged with https://lobste.rs/s/nqjmcy/attacking_unix_systems_via_cups_part_i?
It should maybe be merged, but it hasn’t really already been posted. It’s new analysis and new information.
Tags do not seem to me the appropriate functionality for such a thing.
I agree
Heads up: there is a known, working-as-intended regression in type inference primarily impacting users of old versions of the
timecrate: https://github.com/rust-lang/rust/issues/127343I wish the
timecrate was merged into the stdlib. Everyone depends on it, and it regularly either breaks support for old rustc in a minor version, or rustc breaks support for compiling an old version oftime.I’m not sure that would be a good idea since there’s a second major datetime crate in widespread use (and there was a post on here recently about a third).
Whether that’s a good thing or not, I think the
stdphilosophy is not to include things unless there’s one obvious and uncontroversial API and implementation. There are caveats to that, and maybe this is one, but maybe not.I agree with the “no extra fluff in
std” decision even if it’s painful; sometimes the best action is not what’s most pleasant. I’d cheer for a rust team effort to have a “batteries” crate, with no strong guarantees like the rest of rust, shipped with the non-minimal profile of rustup and is opt-in (likestdis opt-out, currently). And if modules get unmaintained and deprecated like in python’s standard library, they can be removed and users can fallback to an eponymous crate on crates.io maintained byrust-lang.I don’t know that we would have any of them if there were a std time, not because it would kill people’s joy to do the work, but because I think some of these crates only exist because:
Maybe there are others but idk, at least the first 2 didn’t need to exist as far as I am aware. I don’t think Chrono diverges wildly from time in terms of API.
Everyone depends on
time? I never seetimeused, actually I always assumed it was a dead project (I never looked at how active it is). I usechronoeverywhere, because that’s the one I see everyone use.Actually, the fact that
stdhasDurationandchronoalso has aDurationbut now it’s deprecated but also in this weird limbo wherechronohalf-uses it’s ownDurationand sorta-mostly-usesstd‘sDurationand then there’s some more old code lying around that wantschrono‘sDurationbecause it was made beforestdgot it. I kinda wishstddidn’t add it’s ownDurationso we could have standardized onchrono‘s. There’s a few things instdthat shouldn’t be there, in fact I think even a core developer saidErroritself was a mistake, and I agree. I’ve gotten very comfortable with the “build your own language” philosophy Rust has gotten, I almost even thinkstdshould be ripped out entirely, only salvaging all of it’s traits, adding a few more (especially to abstract async runtimes!) and putting them into several community-driven crates. I don’t strongly believe that should actually happen, mind you. It’s far too late for that, more of a retrospective idea.I often see
timeas a deeply nested transitive dependency. Crates that directly depend ontimeof crates seemingly just want to get the current time. The top ones (according to crates.io stats):rustlsand a bunch of X.509-related parsers,humantime(itself dependency of aclapand a bunch of logging libraries),tracing-subscriberandtracing(tokio,hyper,h2,tower,axum,tonic, AWS stuff, Sentry and OpenTelemetry, some other logging libraries,tokio-postgresql,color-eyre)timehas about as many downloads and a release cadence similar tochrono.There is some info missing on why you want the things you mention in the issues:
Can you expand on this? Why would you want ownership to do the state transition? Why is
&mut selfbad?Why do you need that?
Perhaps not with
&mut selfspecifically, but as it currently stands, I am first handling the new state, before mutatingself.state = state. The issue being, failure may occur, causing the transitioned state to be lost, and leaving the worker in an inconsistent state.I’d prefer a simpler
handle_event(self, event: Event), which (a) performs the transitions only and (b) gives us back the worker with the new state which we can match and action. Not sure if I’m articulating it as well as I should.I’d like to be able to get the new state more idiomatically:
Versus:
What about…
I hate to spoil the fun, but can someone please describe what the point of this repository is? All I can find in the README are more repeating e’s, and when reading that with a screen reader, any patterns that one is meant to find in there don’t come through.
There is no pattern, I suggest the blog posts linked in the top comment here.
There is no obvious and no specific point to the repository. The name and README are simply repeating e’s and people have contributed many small different programs in various languages that do something whimsical related to the letter
eor the mathematical constant with the same name. For example the Haskell file in the repository is probably the shortest valid Haskell code that printsein a loop:There are also visual gags, such as implementing a program in Conway’s Game of Life cellular automatons that has cells sliding to the right and “printing” the
echaracter by leaving dead cells behind on the grid which form the letter figure, like pixels.You can just read the source code for e.c to see what the repository is for
Did you intend this as a serious attempt to answer mwcampbell’s question?
mwcampbell says “All I can find in the README are more repeating e’s”; it seems to me very unhelpful to reply with even more repeating ‘e’s without making any attempt to explain their significance.
Mods: maybe we could change the link to the html version for better UX: https://arxiv.org/html/2406.08719v1
There’s an issue to handle arXiv URLs better; coalescing them onto the HTML version (which I didn’t know existed until now) would be a good idea.
Wow, that HTML version is horrible, wasting 3/4 of my screen on ugly sidebars.
Link to the abstract page https://arxiv.org/abs/2406.08719v1 so readers can choose.
Really glad about the temporary lifetime extensions. Now we just need to be able to call
&mut selffunctions that mutate fields in a struct while non-mutably borrowing unrelated fields in the same struct. There’s been so many times were I had to write ugly “god methods” just because the borrow checker couldn’t figure out I wasn’t mutating something that was also borrowed when trying to simply split up a function.I was also trying to figure out a solution for that problem a while back. I was proposing something tangentially related on the Rust forum, and someone mentioned a concept called view types. I quickly realized that can be used to solve this “partial borrow” problem as I call it.
Consider a syntax like this:
The
& {a}part denotes which members the function has access to.I ended up dropping it because it was way too big of a syntax for me to pursuit, and it didn’t really generate much interests on the forum anyway.
I like this a lot. It feels like you’re basically deconstructing the Self type into an anonymous substructural type, but in a way that the borrow checker understands is exclusive.
That’s an interesting syntax, but it’s not really much more different than just making static functions that mutably borrows fields through arguments anyway. You can just replace
&{a} selfwith&mut i32and it would be relatively similar (or${a, b, c} selfwith just the types). That’s the primary issue with not being able to call&mut selffunctions when non-mutably borrowing unrelated fields, because otherwise you just have to use a static function. More of a problem of clean syntax than lifetime accessibility. I do want to echo insanitybit’s comment though, it is a very interesting idea to “deconstruct”selfinto it’s fields. It’s probably worth doing some R&D into.Using this syntax is a lot easier than static methods IMO. You don’t need to repeat types of fields and it’s possible to call methods like you normally would (self.func()). And because they are types you can imagine creating aliases for common combinations:
type TypeA = {a,b} TypeBAnd even
impl {a, b} Type {}.I feel like Rust having special syntax for
selfmakes this weird and special cased. If “methods” in Rust were just static functions that accepted the Self type as the first argument syntactically (already is semantically), something likeCould have been done instead of the weird thing
&{a, b} selfis.Or maybe this could also work:
fn method(&mut self { a, b }), kind of similar to the destructing while being consistent with the current syntax.Or extend the current
selfsyntax and do:or
I’d definitely vote for the second and only the second, no need to extend the (very nice) syntactic sugar to a case where it might be confusing.
For those who aren’t aware, that’s already valid rust provided you replace
self(lowercases) withthis. You just can’t use method call syntax to call it if you do that (and it doesn’t do the proposed partial borrowing currently, you have to fully destructure the structure).Is that the same idea as Step 2: A syntax for lifetimes based on places ?
No, this is Step 3: View types.
New annotations will be required to enable that on the functions you’re calling, given Rust’s “the function signature is the point of API stability” policy. Otherwise, changing the implementation could change whether code that does that will compile.
Yeah, I know it’s a non-trivial problem to solve, just one of those “I really hope they figure it out one day” things. It should be possible to actually look into a method (at least a method, maybe not all functions) to see if there are any mutations to anything non-mutably borrowed before the method call. But that would probably be an entire architectural overhaul to the borrow checker, so I’m not holding my breath. I only really bring it up because it does feel like a “bug” in the borrow checker when actually encountering it, because I technically am doing something valid, it just can’t see that deep. You’re right though, a new type of annotation might indeed be a good fix for it.
I don’t disagree… you just seem to be missing that it’s not about “should be possible”.
As with Rust demanding explicit types for arguments and returns on non-closure functions, it’s an intentional restriction in the name of making it easier to achieve “if it compiles with dependency version X, it should continue to compile with any later semver-compatible version”.
The new type of annotation would be necessary to achieve a solution within that paradigm so that the compilation failure can reliably surface on the dependency author’s end, when the compiler says “You promised you wouldn’t access that member in this function and now you’re trying to do so”.
Namely, that’s “action at distance” and rust always avoided it if possible.
And I think that’s right. At places where internals leak (such as leaking Send & Sync from async functions), people get confused regularly.
I had a problem finding an extra monitor when working on the Ampere Altra too, I ended up getting an hdmi to displayport adapter to connect it to a monitor that was out of HDMI inputs :)
By the way, if the author is here: the twitter embedded images are not visible without login (to me at least), could you upload them somewhere else?
My (only) Raspberry Pi was originally set up sitting on the living room floor with a keyboard in front of the TV.
At other times I’ve brought up an old 15” LCD from the basement, but I think the oldest connector it can do is DVI.
People find ways, at least those who don’t only have laptops at home.
I have an HDMI to DVI adapter plugged in to my old server LCD. It screws in so is quite solid, at the cost of more visible cabling.
A really clean solution! Did the experience with EasyEDA do anything to reduce the dread in designing PCBs?
It did! The JLCPCB integration is pretty nice because you can check stock on components while choosing them and quickly view datasheets of any part.
That’s great to hear. The JLCPCB integration sounds useful. I probably should try out the JLCPCB plugin for KiCAD next time I’m making a board for similar integration.
This thread reads like guerrilla marketing.
Could be, or that two members of this community are discussing about something cool! Also, for your information, jcs created lobste.rs.
The web has made us paranoid :/
Maybe you’re the paranoid one. :)
I read ~dhnaranjo’s comment just as a funny remark.
That was my intent.