HN user
This is not exactly true, QUERY pseudoSQL is available, but as a separate API not listed in Sheets Docs: https://developers.google.com/chart/interactive/docs/queryla... I used it as a DB for Cloudflare Workers, the only hard part is Google Auth.
In case of client-server databases one alternative that works great is to open an ssh tunnel using "ssh -L" and just connect using gui tool to it.
Yep, in Russian xerring (ксерить) sounds way better because "ox" part is rarely used in native words.
We already had serverless db for ages and it's called ... Google Sheets. You can even query it with simple SQL-like language.
The problem with most other "serverless" databases is that they don't offer HTTP API to query them from restricted environments like serverless functions.
Good job, Mastercard (and Visa)! Now all people opposing Putin and trying to gather money for leaflets will have to use state-created MIR instead. Putin will be pleased!
Basically I think this syntax addition is nonorthogonal, isn't making SQL any more powerful, but isn't solving the main usability problem, which is composability of queries in any way. Like writing JOIN's is not complicated if somewhat wordy already.
The issue, as i see it, is that adding this feature complicates the language parser even more for not that much actual gains.
1) Implementation has to do some nontrivual rewriting into actual JOIN's which uses indexes, previous special cases like NATURAL were purely syntax sugar 2) All of the tooling that depends on parsing SQL need to add sensible support or else noone will even recommend to use this 3) It is useless for anyone using ORMs in the first place, they will continue to generate normal JOIN's (less actual impact) 4) For anyone using prepared statements it automatically goes to "is not recommended to use" list because it makes your JOIN's depend on existence of foreign keys and corresponding indexes, which are an optional feature DB still should work without. I've had tasks in my career when my team added or removed foreign keys, so this type of JOIN's would make migrations even harder to do. 5) So considering all of the above this is feature designed purely for REPL and for this purpose it is also kind of useless. I can imagine remembering and typing column names in normal JOIN's, but foreign keys usually have some long unintelligeble autogenerated name.
I, personally, feel like this is a rather pointless addition to an already somewhat bloated language. It it isn't saving that much typing (we have NATURAL JOIN's already, nobody is using them), is kind of inconsistent with other language principles (we should be able to join anything to anything if we need to, see SQL-89) and limits JOIN flexibility (you don't have to join with "=" operator, JOIN's supports different types of conditions and are equivalent to WHERE clause)
Java is for pussies, in Javascript you don't even give ***** if it is literally "null" or "undefined".
Yeah, and it's not even the funniest one of a bunch of different phrases. I really prefer adding dogs instead of horseraddishes: "да и пёс с ним".
There is also an interesting solution to this problem: use native WebView, so you don't have to pack the whole Chrome with your app. Basically every "electron alternative" with HTML+CSS+JS works this way.
Basically, the site is rebranding as OnlyBans :)
You mean something like Hyperdrive (formerly Dat) + Beaker browser?
This article is like reading Gulliver's Travels Part III: A Voyage to Laputa, but as a real-life thing. Can't stop laughing!
Also, from the point of query optimisation this is a really bad idea. Usually you DO actually care about size of fields in SQL databases, because something like BOOLEAN is usually stored as single byte (or bit in a bitfield) vs 4 bytes or even 8 in case of timestamp. This not only multiplies on disk usage by at least 4 times, but also makes ALL indexes using this field way bigger. Also boolean indexes can be compressed (or stored as bitmaps), while timestamp indexes contain lots of unique values, so they can't be. This is also the reason why serial IDs are way better than UUIDs for internal IDs.
If we follow the logic of the article's author to the end, then JS doesn't have this problem either. You can await on non-Promise values, so can just say that everything is red, add await to every function call and call it a day.
Can a goat in the swarm catch a random virus from the Web? What's your policy on replacing dead instances and replication?
Also "split views", //TODO comments and focusing on one task at a time help a lot.
Personally I have an opposite problem of thinking too much about work after hours, but in case I really need to remember something it is written into notepad or note taking app. All modern text editors after introduction of Sublime Text (I use VSCode) have persistent sessions in settings, so I just keep lots of tabs (like in browser) and clear them after feature merge.
BTW, first version of Redis was actually built in equally slow TCL and later rewritten in C.
I provided all the data he needs to prove my theory (in previous linked issue) and his theory (in this issue). And now i'm the bad guy. Really? BTW, specific VM settings doesn't matter for the purpose of issue replication, the problem is guest-OS isolated, but maintainer just denies it.
The maintainer is just closing this issue and all related with his own network-"hacking" theory without proving it by himself and having 0 arguments supporting it in the first place. I started this discussion with arguments in favor of postgres BINARY being compromised. No mentions of network were at the start of dicussion except for the botnet control server which obviously isn't the cause because the connection wasn't incoming but outgoing.
Proof was in description. Maintainers claimed that problem wasn't related to image but rather to infrastructure, so we changed the base image to prove that infrastructure was totally fine. Also i personally don't actually care that much if issue with this particular image is resolved, we switched to bitnami one for the time being (and will build our own one from sources when we have time to do so). It's more of a warning for other companies/people to check for the same problem.
I know that using public docker images is a problem by itself, but this one is "official" in Docker Hub ...
After consulting with GNU sort manual: sort has -m option just for the case of merging presorted files, so you can test this by using 'split -l', then 'xargs sort' (to parallelize), then 'sort -m' to merge chunks
Was there any external requirement to specifically sort this file in-memory only? Why not just split the file into chunks (around 100MB), sort them as usual, and then k-way merge sort them after that. This, in theory, can be faster than allocating lots of RAM for radix tree, especially if you use SSD instead of HDD.
http://pythonanywhere.com This guys specialize in python hosting and have a free tier
Refcounting can mess with caches in multithreaded scenarios, so results aren't really surprising to me. It also generates unnecessary work to maintain counters on all writing threads, while concurrent tracing GC batches all its actions on separate thread.
Python, actually, is older than Euphoria. :) The cool part is the focus on cache-local data structure first. Way more popular scripting languages like JS and Lua use hash tables as their primary data structures, Python and Ruby offer arrays as secondary option, but focus on using structs (classes) everywhere. Euphoria answer to this is to use arrays of cells for everything and enum your way out of situations where you need to group things.
It is dynamicly typed with optional validators built-in. The cool part (and also the main weakness) is usage of resizable array-based vectors for all composite data types. Other distinguishing traits are RC-based GC, no higher-order functions (but ability to pass function pointers), direct memory access via BASIC-like poke. Original Euphoria language wasn't a scripting one, more like C on steroids (for MS-DOS), and its main usage was game prototyping.