It is a valid python program . This is because python will join strings that are adjacent strings (eg. "foo " "bar" is evaulated just like "foo bar") and while multiline strings are commonly used as comments they are evaluated as a string-literal rather than a comment.
You missed the point. All the examples obviously all have at least one line of code, otherwise there would be no program to display "Hello, World!" at all. The goal is to have a program that is _counted as 0 line by the software "sloc"_ even though it is not 0 line.
Did he or did you? Some arbitrary game of how you count lines of code is not interesting enough to make the front page.
Using an arbitrary metric that is not commensurate with reality is inaccurate. The point is that the title is clickbait for what amounts to a singularly exploited bug in a tool, not what was purported. Literally the same misinformation goes on in the political space all the time, where it is lamented. If it's related to quirky coding eventualities, it's lauded.
You can argue against the merits of this game or call this clickbait, and that's okay. But someone that blithely points out that there is in fact code, not even realizing the game exists, is missing the point.
There is a big difference between disagreeing with a point versus not realizing the point is there.
Which point? Are you talking about the point notinventedhear made? That point was not useful and the initial reply was not derailing and that wasn't me making that reply.
If you're talking about something else, I have no idea what you mean at all.
And nobody here has said anything in bad faith. Why do you think there was bad faith?
> But someone that blithely points out that there is in fact code, not even realizing the game exists, is missing the point.
notinventedhear didn't miss the point.
He disputed the topic (and implication) which is not "the game" but a description that is factually incorrect. You don't want to agree, that's fine. It's not subtle or complicated. To claim anyone misunderstands where this premise comes from, is a bad faith interpretation, which you inexplicably double down on.
The page says right at the very top that this is about tricking the line counter.
notinventedhear is not disputing the actual page when they say "There is still one line of code." Nor do they appear to be objecting to the title, because they're quoting part of the actual page and re-explaining it even though the page already does so.
This seems like pretty strong evidence to me that they missed the point; they missed the part about tricking.
It's not that I don't agree with what they said, it's that what they said was already thoroughly covered in the linked page, right up front and in more detail. If they understood that, then why did they even make a comment like that?
From 4 years in a large public quant house (not HFT): everything upstream of trade execution is Python with very heavy use of numpy, scipy and pandas. This has pros and cons, on balance I'd prefer a better type system, but that everyone in the org can share code has tremendous value at scale.
Briefly, the faster your execution the faster everything else needs to be. Java should be fast enough for almost anything short of HFT + colocation which is super expensive infra wise.
The skills are not different from other backend roles, but you will need to exercise more math with emphasis time series and stats.
I was _so_ excited when Rocket League first came to Linux, but that was several years before Proton[1] was released.
But according to [2] the game runs really well on Linux via Proton. Personally, I don't see any problem using Proton to play the game on my Linux gaming-rig.
The concern is that Epic will add EAC and that Proton is going to cause you to get banned or they pull the game from Steam and move it to EGS which doesn't run on Linux, and likely never will. So the question becomes why should I put more effort into a game that's likely not going to be available to me in the very near future?
Epic acquired Kamu, makers of Easy Anti Cheat, for use in Fortnite. EAC is known to block Linux players using Proton, and there's decent odds Epic adds EAC to Rocket League.
Proton is pretty great, but there are hardware limitations. Im running a pretty old video card. I can run games like Deep Rock Galactic on Windows, but it wont work on Linux as Proton needs newer linux drivers, which don't support my card, in order to run that game.
Proton works great for single player games but isn't that great of an idea for multiplayer games. Their anti-cheat system could end up banning proton users. I believe this has happened to Destiny 2 and GTA:O players.
nginx
mailinabox (email, nextcloud)
gogs
6 static websites
3 (dumb) little personal web-projects
selfoss
mumble
openvpn
# rpi-3 at home
osmc (kodi) + 8TB of raided HDDs
nginx
chorus-2 in kodi publicly available (behind htpasswd) updated w/ dynamic DNS
a nightly cron job rsyncs the from the linode instance
# another rpi-3 in garden shed
8TB of raided HDDs
nightly cron of the other rpi-3
TimescaleDB looks really very promising but this is a red flag:
"Hypertables support all standard PostgreSQL constraint types, with the exception of foreign key constraints on other tables that reference values in a hypertable"[1]
Naively I'd assume this could cause a two-colouring of your schema - the partition that can use referential integrity and another with hypertables that doesn't which feels like a pretty big trade-off.
In practice this doesn't come up a lot. Say you have a hypertable with measurement(time, device_id, value) and a device table with (device_id, device_manufacturer, device_type). Timescale fully support a foreign-key from the measurement table into the devices table. This is a common usage. A FK from another table which references a measurement row is not supported, but is also uncommon. To see why note that a part of the primary-key of the measurement table is time and so conceptually the only type of table that would want a FK into it is also a time-based table, and so the only real usage is a 1-to-1 relation. That is also uncommon and can be gotten-around with normalization.
Very excited by the prospect of a modern terminal-mail client that is easier to use!
After following the README: this is clearly not ready/designed for wide consumption - the recipe neglects to mention how to install a custom doc-tool called scdoc (by the same author?) that is required to build it - and there are no pre-built binaries (that I can see).
It's not designed to be installed from pre-built binaries. It requires some other stuff to be set up on your system, too. It's designed to be friendly for distros to package instead. If you want to install it from source, use the Makefile like everything else.
Thank you - seems like it may be a very localised issue in that case (although the fact that Wayback is also struggling to grab the content suggests otherwise).
https://github.com/cboddy/i3-workspace-names-daemon