chiply

Yeah, I think the story is that Penrose saw an illusion in an Escher print that encouraged him to create the Penrose Triangle, his dad Lionel created the Penrose staircase, and then sent a copy of these in the paper "Impossible objects..." to Escher, who then used the staircase in "Ascending and Descending" and others. It's kind of cool that they cite eachother in these works as inspiration here. I bet Escher could have made an interesting print of them pointing at one another in some kind of impossible object.

And apparently neither Penrose nor Escher knew about Oscar Reutersvärd's work! Oscar got robbed lol.

Author here. I think in general this is sound advice, but in Emacs it is an incredibly convenient utility. I use them all the time. Mostly simple things like wrapping function definitions, or even other macros that wrap function definitions. Most of my lisp experience is in Emacs where the config layer is essentially exposed through an elisp API. In that context, I find myself using macros a lot. But if I was building some software from scratch, like say a data processing system, I can't immediately think of scenarios where I would define macros.

Worth mentioning in Elisp that even if you don't define your own macros, you use them more often than you would think. defun, unless, def-custom, etc (more examples in the blog post) are all macros. The fact they look and feel like non-macros like special forms and built in functions implemented in C is part of what makes elisp so cool to me. There are plenty of homoiconic languages, but you rarely feel the distinction between program and data in elisp, and macro-supporting lisps in general.

I love this take because I had exactly the opposite idea. I thought the combo of remarkably simple text (not even wrapped) with incredible, full width visualizations was chef's kiss. I really like the balance there personally, but I hear you. Does your browser have Reader Mode or something like that? I don't use those tools personally, but I believe they will recast the text parts into something that renders optimally for reading (ideal font size, number of characters per line, etc....).

I love EWW! It's incredible. If you mostly use the browser for reading, you'd be surprised how much EWW actually renders. It is true that a lot of JS sites won't play nice in EWW, but I find that's quite rare, and it's easy to just switch to a chromium browser in those cases. It's my main driver for reading on the web.

Dude that milkman joke made me cackle out loud.

It's hard to draw a direct analogy there, but I feel like it echoes the same sentiment.

A soapbox I have is that GHA workflows are scripts that could run on your machine without any of the YAML stuff. Who gives a flying about the DAG or the logs? Which, by the way, if you're willing to walk to the milk store to buy your milk, could be recreated in a much more testable and maintainable way without any of the YAML bs that GHA prescribes....

But DAGs are pretty, and logstreams showing up in a browser application instill trust (for reasons that fly far above the head of yours truly). So people go for that. Pretty DAG, nice logstream; therefore, deliver my milk. All of a sudden.... The CI/CD platform is having its merry way with your SLAs, contract abidements, and hotfix deployments.

What a time to be alive.

Not to rail on the South Park thing, but the blast radius of this issue also reminds me of the episode where the internet dried up.

If this bs with GitHub continues, Parker/Stone will have to make a GitHub episode. How seen would we all feel if that happened?

I feel for you.... This is not a position you should be put in.

There's always the escape hatch of running you GHA workflows locally, but unfortunately, despite the existence of packages like `act`, there is no way to fully recreate the GHA runtime locally. Tons of the special YAML syntax just can't (more accurately, "just doesn't") get interpreted by those local actions runners.

We never went this route, but at my old org, I always advocated for considering GHA to be wrapper around a single bash script (or whatever script you want to run), as a means of completely breaking out of the GHA hellscape that is programming in YAML, who's turing-completeness is pretty dubious.

Unless you have things set up this way, you (the client of GitHub) would have to completely redesign your CI on the fly, run it locally, and then figure out how to get the D compliment of the I to work in a way that is auditable. Fat chance for most teams I bet.

Thank god you're dealing with a batch scenario. Silver lining for sure. Still, embrace the anger.

What makes my blood boil is that there's millions of DEVs literally crying at the moment worrying about how GitHub's failure to be responsible will put their jobs in jeopardy.

And fingers crossed for you my friend. We're at 5+ hours at the time of this writing.... You're batch job may still have a chance!!!

Time to rant... This is absolutely unreal.

Even self-hosted runners are impacted.... How can that be?

The cost of this globally has got to be in the hundreds of millions to companies that use CI/CD through GitHub Actions. What if prod is broken and GitHub actions is stalling the deployment of your hotfix? What if this makes your organization miss and SLA and diminish user trust? What if this makes you miss a release that you were contractually obligated to meet? This is happening during peak dev hours on a Thursday (not that it would be acceptable at any other time).

I don't understand how a service this critical to the global technical infrastructure can fail like this at all, let alone for more than a few hours. Like where's the backup generator for crises like these? You can't even use self-hosted runners? WTF? Like how can you not bring your own backup in a crisis event like this?

Not that Microsoft has a good reputation, but holy moly, you'd think they would prepare from something inevitable like this.

Unreal. Even self-hosted runners are impacted.... How can that be? The cost of this globally has got to be in the hundreds of millions to companies that use CI/CD through GitHub Actions. What if prod is broken and GitHub actions is stalling the deployment of your hotfix? What if this makes your organization miss and SLA and diminish user trust? What if this makes you miss a release that you were contractually obligated to meet? This is happening during peak dev hours on a Thursday (not that it would be acceptable at any other time).

I don't understand how a service this critical to the global technical infrastructure can fail like this at all, let alone for more than a few hours. Like where's the backup generator for crises like these? You can't even use self-hosted runners? WTF?

This is nuts. I remember there was chatter about kicking the tires of the canvas patch in Emacs with DOOM. This is sick. I hope people reading this post understand that this is DOOM the video game, not doom the emacs distro. Well done!

Just stumbled across this. It's just Emacs docs defined elsewhere but with a modern UI, great organization, and wonderful features.