Wow! My screensaver was some guy's project to invent running and walking creatures from leverages and wheels via genetic algorithms. I can't remember project name neither .edu domain connected to it.
I worked for a company with a large website. The designers were elite and worked in a darkroom on expensive Apple equipment.
At some point, it turned out that users couldn't see a certain color on the website because it could be seen on an Apple monitor, but not on a mass-market laptop's TFT screen.
I have difficulty reading the light gray text on white/bright background that too many sites favor these days. I have a pretty good 4K 32 inch monitor. Even with a full Adobe color space capable and calibrated device in a darkroom I don't want to read that combination.
I don't get it, I have medically tested 120% color vision (it was a lengthy test), definitely nothing wrong on my side, so I don't understand at all what the designers and coders are seeing that they think that that is a great idea. The difference between the pixels is objectively bad, one can take a screenshot and look at the background versus text pixels.
I worked at a really large social media company, and there was a design which looked beautiful on all of the employee's high-res screens and monitors but used too much space and just didn't work for most of the users. It never got launched, which feels like what should have happened here.
> You want your designers to have accurate color reproduction for obvious reasons
I don't know, I conclude the opposite. If you need accurate color reproduction when you publish online, you are doing something wrong.
I used to co-own a small digital printing business, so I'm aware of what all of it means, and I had an appropriate monitor myself and a paid Adobe Design Suite subscription.
But for the web, when our setup is too good it's actually a detriment. It is predictable that you end up publishing things that require your quality setup. There is a good reason not to bother with a high quality monitor usable for serious publishing and photo/video editing when you only do web thing. Which is exactly why when I bought my last monitor, which is for business work and coding and web browsing and other mundane things, I deliberately ignored all the very high quality displays, even though the company would have paid whatever I chose. It is not an advantage for that use case.
I used to work for one big company.
Every newly hired design director desperately wanted to create a new design for the corporate portal because it would add a new line to his resume.
So I've decided to give it a try.
Open installation instructions and went thru "easy install with uvx" / "get and run our sgell script" until get "pip install ty".
I do not want use other tools so I started it in pet project directory as "ty check". Is shows me progressbar and "98/99 files" then hang.
I restarted it and it hung on "68/99" and started using 100% of cpu core. I waited for 15 min and killed it.
Try to get more information about current file but there is no verbose mode but colorful "ty --help" output.
Lets wait for a year then try again.
There was a hang/performance bug [1, 2] that was reported just after the beta release, which we've since fixed [3]. You might try seeing if we get through your entire project now?
(And as an aside, there _is_ a verbose mode: if you add `-vv` you'll get DEBUG-level log messages printing out the name of each file as we start to check it, and you can set TY_MAX_PARALLELISM=1 in your env to make it very clear which file is causing the hang. That's how we debug these kinds of issues when they're reported to us.)
There are two 40-floors buildings nearby to each other in Tbilisi, Georgia, that are missing on Google Maps. All businesses have to put POI just "somewhere".
One man from Google told me that there are staff members responsible for Georgia maps but they are chilling :)
JetBrains products had colorful and useful pictograms on menu items and panels.
One day they replaced them by B&W versions and it was fail.
Few years later they introduced purple icons. For promoting some internal AI companion.
The default storage location for memo(1) output is /tmp/memo/${USER}. Most distributions either have some automatic periodic cleanup, and/or wipe it on restart.
Separately from that:
- The invocation contains *memo* right in there, so you (the user) knows that it might memoize.
- One uses memo(1) for commands that are generally slow. Rerunning your command that has a slow part and having it return in a millisecond while you weren't expecting it should make the spider-sense tingle.
In practice, this has never been a problem for me, and I've used this hacked together command for years.
A month ago, I opened an old PDF file on MacOS Monterey and found that Preview couldn't display the images in it. Chrome browser on Monterey shows inlined images. I've read this PDF on Windows for years. For Monterey I had to convert it with some online converter in order to watch inlined images.
My favorite "the worst PDF reader" is MacOS Preview.
reply