> I have a good understanding of the problem, but I do not have a solution
REALLY
Just don't call background services, unless the user explicitly requested a remote service! My Linux installs and (to a lesser degree) my Windows LTSB/LTSC installs don't have these issues, you know?
I don't think that there's anything inherent about concatenative languages that forces them to be postfix. The Wikipedia definition (not authoritative, surely, but one we can all access) is:
> A concatenative programming language is a point-free computer programming language in which all expressions denote functions, and the juxtaposition of expressions denotes function composition.
As long as all functions are fixed arity—admittedly a serious limitation—there doesn't seem obviously to be any reason you couldn't write the function first (though of course it's fair to ask why you would want to).
I associate concatenative languages with stack languages, which means that the postfix syntax is obvious. But as the sibling comment mentioned, that doesn't necessarily need to be the case.
Even after perusing jq's manual multiple times and having written several complex incantations, I still have no idea how to properly combine `|` and `.[]` except by trial and error, or why `select()` needs to be used inside `map(select(...))`
Recently I needed to extract some data, and after fighting with jq and its manual for half an hour, I solved the problem in 30 seconds with node.js
I appreciate the idea behind jq, but its language is horrible. Even XPath was easier and cleaner.
Hmm. I also think jq is more awkward than it needs to be, but I don’t think the points you mention are a problem. Maybe explaining them would help?
(Note: the following explains jq’s operation using the smallest possible subset of the language, it doesn’t aim to use the most natural programs possible.)
So jq’s data model (much like XPath’s actually) is that everything is a (possibly empty) stream of (JSON) values. On input (unless you use -s), it accepts any number of concatenated JSON objects (usually separated by newlines or ACSII RS, but as JSON is self-delimiting that isn’t strictly required) and makes a stream out of them.
That is then fed into the program, a pipeline of |-separated transforms, each of which can generate zero or more output elements from each input element. For example, .foo is a one-to-one transform that, when it accepts an object, emits the value of its foo property (and fails otherwise):
And .[] is a one-to-zero-or-more transform that, on accepting an array, emits each array element separately (and fails otherwise):
$ echo '[false,1][][2]' | jq '.[]'
false
1
2
While select(F) is a one-to-zero-or-one transform that, on accepting an element, feeds it into F and lets its pass through if it got a truthy value or rejects if it got a falsy one:
OK, that last one was a bit of a lie. Because we don’t want to introduce functions into the language as a separate kind of thing to transforms, F is also a transform, so it might possibly emit more than one value in response to whatever select fed it. The full truth is that select(F) is a one-to-zero-or-more transform that emits each input value as many times as there are truthy values in F’s response to it:
That might have not been terribly useful, but it illustrates two points. First, a JSON literal is a valid transform: one that emits itself every time it gets something. (That’s why you need to write .[] for flatten: plain [] is the empty array literal.) Second, while jq cannot do many-to-one transforms, on pain of losing its streaming nature, it can do something like nested contexts, where it launches a subordinate pipeline and does something with the results.
And it is willing to collect those results instead of streaming them: if you have a pipeline P, [P] is a one-to-one transform that, for each input element, runs P on it, collects all the results from them, puts them into an array and emits that. For example:
(here . is the one-to-one identity transform). Instead of [.[] | P] you can write map(P).
What this boils down to select(C) will go through the input stream and pare down its elements to those that satisfy C, while map(select(C)) will go through the input stream of arrays and pare down each array’s elements to those that satisfy C.
Final point: if you want to give up streaming, the -s / --slurp flag will slurp the input stream into an array, then feed it to your program as a single element. That is, jq -s '.[] | P' is a worse synonym of jq P.
They should all be either allowed or denied. Why are UR-MOM or F-YOU considered offensive, while newer memes and slang that may be even more offensive can probably pass through the radar? Either allow everything, or deny vanity plates altogether.
IIRC a spinning space station would only be beneficial if it was very large and thus far from Earth and expensive.
Otherwise the difference in gravity acting on different sides of the body and more importantly the Coriolis forces would wreak havoc and cause more harm than good.
Yes, it will complain and for good reason: it has no way of knowing whether the kid next door is spoofing your router's IP or Mac address and presenting their own self-signed certificate.
I wouldn't go as far as calling it «capricious constraints imposed by the system of "certificate authorities"» but at the same time, I agree that it's not a fundamental limitation of the technology.
Better protocols could be developed to allow a browser to trust a server without (all) the limitations of the current system.
- let companies register a wild card domain in the .local (or a newlocal) namespace: .acme.local
- designate the acme company with the ability to issue certs that never expire for any name in ".acme.local" but the browser will refuse to use certs signed with that key for anything outside "*.acme.local"
pros:
- the acme company can now make equipment that the users browser can connect to over an encrypted channel with zero config on the user's part
- the equipment can live off the internet indefinitely
- if the acme company is breached, and their signing key is stolen, the attackers can only use that key to impersonate acme company, it doesn't allow them to impersonate any other domains
cons:
- the browser manufacturers don't care about this use case so its never gonna happen
- the cert on the device never expires... and can never be replaced automatically somehow. I think the only workaround is acme could enable users to load their own certs if they are so inclined, but that shouldn't be required.
You should only have to store the self-signed cert exception once, at least on a given device. Now, if you're being targeted by a state-sponsored actor they might somehow be able to get you onto a honeypot network within the 2-minute window between plugging in your router and making your first connection to its web interface, but for everybody else a self-signed cert that you accept once during initial setup should be plenty good enough.
It was definitely not. It was in the food we interested.
Trees and other plants take carbon from air, energy from the sub, and use it to build themselves. We take carbon from them and put it back into the air, using the excess energy to move and think.
Which was in the air in the past few months to handful of years depending on how fresh the food is and what it is (plant, animal). Unlike the CO2 from fossil fuels which was sequestered for millions of years. And had that not been harvested for food, it would have sat their being decomposed in a field somewhere returning that carbon right back into the atmosphere via animals and bacteria snacking on it as they broke it down.
Actually even worse as it would get converted into much more potent GHG - mostly methane.
The oil and coal only happen when organic matter is subjected to pressure and non-porous geological layers. Otherwise you get peat fields and those emit methane.
REALLY
Just don't call background services, unless the user explicitly requested a remote service! My Linux installs and (to a lesser degree) my Windows LTSB/LTSC installs don't have these issues, you know?