COVID-19 Statbar

[balala]

The site change and my regex broke - I have fixed it - download on the first post.

Unfortunately there are great chances to have to rewrite the RegExp often.

[mak_kawa]

I have avoided the issue caused by nCoV2019's html description change by adding some substitution. Scraping the web page has always such danger, as balala and dvo said.

[ms310]

I have avoided the issue caused by nCoV2019's html description change by adding some substitution. Scraping the web page has always such danger, as balala and dvo said.

I'd like to see more of what you are doing mak_kawa - will you release your skin?

[mak_kawa]

Hi ms310

So far, I am not going to release my skin, because it is "incomplete and buggy" at all.

My substitutions for the "Deaths and Recovered" values in nCoV2019 capture is very simple.
1. Remove spaces.
2. Remove linefeeds.
3. Remove parentheses and % values enclosed.
So, like this;

Code: Select all

RegExpSubstitute=1
Substitute="":"..."," ":"","\n":"","\(.*\)":""

I am not sure why "\n":"" instead of "\r\n":"", but works.

[jsmorley]

I am not sure why "\n":"" instead of "\r\n":"", but works.

The world-wide-web is pretty much entirely encoded as UTF-8 with "unix-style" line endings of \n, not \r\n, which is pretty exclusive to Windows.

This may seem confusing at first blush, but really it's not a big deal, since Rainmeter isn't going to do anything with an orphan \r anyway. Carriage Return by itself, without a Linefeed, doesn't have any impact on how a string is displayed in a meter. It literally has no meaning.

The entire \r\n, or put another way, CRLF construct is really sorta stupid. The idea of a separate Carriage Return from a Linefeed in digital data is based on, and goes back to, the typewriter. Really to the teletype machine. I don't see any "carriage" on my screen that needs to be slammed back to the right so I can start the next line at the beginning. It's just a prehensile tail, that only survives because it would be a hideous nightmare to get rid of with all the backwards compatibility issues.

When they started with the internet, a brand-new thing that didn't need to worry about backwards compatibility too much, they rightly said "why in the world would we treat this like a 1950's typewriter?" Not a 1960's or 1970's typewriter mind you, which already did away with the "carriage", but really a 1950's, manual, smash the keys and slam the big handle typewriter...

The earliest way to to transmit data used a teletype machine, which if you look at one, is really like a typewriter, using ideas translated from a player-piano. They simply said, "we understand typewriters, how can we get one to work without a human at it smashing keys?". It still used the Carriage Return / Linefeed sequence, so you had to have a way to send that in your data to tell the machine to slam the carriage to the right. I don't think you will find many teletype machines in common use anymore.

Encoding in general is a mess. It was probably unavoidable growing out of a 8-bit world that only needed to support 256 distinct characters. As the internet spread from the US Defense Department to universities and from there out to first Europe and then the world, it became clear that more and more characters were needed to support languages, and 256 characters, even with nightmarish "code pages" to try to jam characters like ü or Д or 今朝 into the set of 256, just wasn't going to get the job done. That is where the Unicode structure comes from. Right now there is UTF-8 which can encode "most" but not "all" possible Unicode characters and symbols and emoji and all that, and has the charm of being relatively "lightweight" to transmit as data, UTF-16, which can encode "more" characters, but is a bit heavier to transmit, and so is mostly used by Windows to encode local files on your system, and UTF-32, which I think might be able to encode "all" the current Unicode characters, but is relatively heavy, and I don't know if or where that is currently used. It might become more popular and ubiquitous as the internet "pipes" become larger and cheaper.

Extra credit... The QWERTY layout of the keys on your keyboard also goes back to the 1950's typewriter. The keys were laid out that way so the mostly commonly used keys were grouped in a way that in effect SLOWED you down, so the big arm with the character molded on the tip of it had time to strike the ribbon and start coming back down before you had time to get the next one going up. That kept the 44 keys on a typewriter from getting all tangled up quite as often as you typed. We still have that layout for one reason only. We are used to it, and we hate, hate, hate change...

[mak_kawa]

Hi jsmorley

Thank you for clarification and detailed explanation. UNIX-style and no typewriter! ...I now understood.

[jsmorley]

[ms310]

Skin uploaded to original post.

20200406.01 Fixed Regex, added Japan at the bottom of the popup list

[ms310]

20200407.01 - Fixed RegEx.

Skin uploaded to the first post.

[rasagedo]

nice work
https://topfreepornsites.me