You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suppose I should start by asking whether the Playground Powers That Be feel that these examples have enough educational value to justify the CPU the consume. (In short, they're demonstrating the busy loop that you create when you implement async IO without an underlying blocking API like libc::select or libc::poll.) If not, I'll delete them or host them some other way. But if so, what are my options for getting them unblocked, and how can I make sure they don't get blocked again over time? Thanks a million for your help either way.
Edit: Ooo this is issue number 1111, neat.
Edit: For searchability, the error text in the screenshot is 413 ERROR The request could not be satisfied..
The text was updated successfully, but these errors were encountered:
It's interesting that the example is accessible through that short link, but blocked when I embed the source in the link,
HTTP GET requests generally have a limit on their length. I don't know if it's CloudFront, nginx, or Axum, (my guess is CloudFront) but one of those is rejecting it because that URL is too big (over 10KiB).
Oh wow, I was just making all that up about CPU usage. (I mean, I will try to be judicious about abusing CPU time either way.) I guess there was some loose correlation between the length of the code file and how much CPU it was using, and my lizard brain just latched onto that...
Out of curiosity, do you have any suggestions for autogenerating playground links for files in the 10K-20K size range? It looks like I can make my own Gist and link to that ID, but I'm curious whether I'm missing any other good options. Thanks for your help!
This might not be the best fit for a GitHub issue, but I'm not sure where else to report it. I've been working on an article that uses a large number of Playgroud examples (rough draft), and I've noticed that some of my Playground links are blocked. A block looks like this:
I suspect I earned the original block because one of my examples burns a 2-3 seconds of CPU time, and I'll admit to abusing 5-10 minutes of total Playground CPU time while I was developing it. (I am ashamed of my crimes.) Here's a short link to an offending, CPU-burning example. It's interesting that the example is accessible through that short link, but blocked when I embed the source in the link, as I do for most links in the article. (I auto-generate them from checked-in code files.) Here's another short link to an example that burns 1 second of CPU, and the source-embedded version which is blocked.
I suppose I should start by asking whether the Playground Powers That Be feel that these examples have enough educational value to justify the CPU the consume. (In short, they're demonstrating the busy loop that you create when you implement async IO without an underlying blocking API like
libc::select
orlibc::poll
.) If not, I'll delete them or host them some other way. But if so, what are my options for getting them unblocked, and how can I make sure they don't get blocked again over time? Thanks a million for your help either way.Edit: Ooo this is issue number 1111, neat.
Edit: For searchability, the error text in the screenshot is
413 ERROR The request could not be satisfied.
.The text was updated successfully, but these errors were encountered: