Wow, didn’t realize it had enough legs for people to be hearing about it except via me! Awesome to hear that.
Rego is “for” those authz cases like the ones you mentioned in the sense that it’s definitely designed with those in mind, and I do think it does a good job for those needs. OPA itself is definitely geared for use as a microservice or container sidecar, talking over the wire. That’s kinda hard to use in a shell script though.
Once I learned it I found myself using opa eval for searching and transforming data, eventually so much so that I made a shell script called “rq” that was basically opa eval -I -f pretty… the rest is history.
I have been working on a project in a similar vein: rq[0]. Mine started out as an attempt to make a jq-like frontend for the Rego[1] language. However, I do find myself using it to simply convert from one format to another, and for pretty printing, quite often.
The interactive mode that qq has is really slick. I didn't torture test it, but it worked pretty smoothly with a quick test.
I see that the XML support is implemented using the same library as rq. This definitely has some problems, because the data model of XML does not map very cleanly onto JSON. In particular, I recall that I had problems using mxj to marshal arrays, and had to use this[2] ugly hack instead. qq seems to have done this a little more cleanly[3]. I may just have to lift this particular trick.
I definitely found CSV output to be challenging. Converting arbitrary JSON style data into something table shaped is pretty tricky. This[4] is my attempt. I have found it works well enough, though it isn't perfect.
I can also see that qq hasn't yet run into the byte order marker problem with CSV inputs yet. Might want to check out spkg/bom[5].
One final breadcrumb I'll drop - I drew a lot of inspiration for rq's input parsers from conftest[6]. That may be a good resource to find more formats and see specific usage examples of them.
Thanks for sharing! It's really interesting to see some of the convergent evolution between rq and qq.
You might be interested in the book “1177 B.C.: The Year Civilization Collapsed” by Eric H. Cline, which covers what we know about the pre-collapse civilizations as well as the collapse itself. It’s very fascinating, though it seems a lot of the details are simply lost to time.
I feel like requiring users to enter into a legal agreement with a private third party in order to perform legally required obligations for a government entity has some troubling edge cases.
What happens if a user has a dispute with ID.me, who decides to terminate their account for violating their ToS? Something tells me they will still be on the hook to pay their taxes (presumably via paper, for however long that's still supported).
34 years old, actually. I guess we can go ahead and deprecate the x86 instruction set, tcp/ip, ASCII, C, tar, and many other tools and standards that are old.
> and even that is not supported.
xterm supports vt430 emulation. I use this semi regularly. I believe mintty also supports sixels, plus a handful of others. The libsixel website has a full list.
> And I can see why, why on earth would you want to be adding support for that in 2021?
I don’t see why sixels couldn’t work. You’d probably want a tool to decode them, diff the images, and then output another sixel image. I’m admittedly not sure of such a tool existing off the shelf though.
I’m not aware of text editors supporting sixels, which could make preparing the tests a challenge. Certainly, you could imagine a text editor supporting them, but I’m not aware of one that does personally.
I will concede that for your specific use case, an off the shelf ASCII plotting library probably involves less custom tooling.
I would point out that sixels[0] exist. There is a nice library, libsixel[1] for working with it, which includes bindings into many languages. If the author of sixel-tmux[2][3] is to be believed[4], the relative lack of adoption is a result of unwillingness on the part of maintainers of some popular open source terminal libraries to implement sixel support.
I can't comment on that directly, but I will say, it's pretty damn cool to see GnuPlot generating output right into one's terminal. lsix[5] is also pretty handy as well.
But yeah, I agree, I'm not a fan of all the work that has gone into "terminal graphics" that are based on unicode. It's a dead-end, as was clear to DEC even back in '87 (and that's setting aside that the VT220[6] had it's own drawing capabilities, though they were more limited). Maybe sixel isn't the best possible way of handling this, but it does have the benefit of 34 years of backwards-compatibility, and with the right software, you can already use it _now_.
The only BlackBerry I ever owned was the BlackBerry Classic, back when that was still contemporary. Best phone I ever had. The UX was very consistent between apps, everything targeting it natively tended to be quite speedy, and the keyboard was excellent.
I also miss the "BlackBerry Hub" feature, which would aggregate your emails, BlackBerry messenger messages, and SMS messages into a single UI. It even pulled in notifications from Android apps, though opening them switched to that app rather than letting you reply in-line.
I bought mine after they had already released Android compatibility for any APK you cared to load, but unfortunately I think that feature was too little, too late.
I've been on an iPhone SE since around 2016. If I had the option to go back to using the BB Classic hardware/OS as it was when I switched, but with third-party app support and security updates, I would do it without second thought.
Regular expressions, deterministic finite automata, and nondeterministic finite automata are all equivalent[0][1].
All three of these representations are capable of describing any regular language (set of symbol sequences, or more intuitively a set of strings), and the fact that a language can be described by an NFA, DFA, or RE implies that it is regular.
I am not hugely familiar with Pearl's "extended regular expression" system, however I was under the understanding that the set of languages it can recognize is a superset of the set of all regular languages. Based on [2], it would appear that Perl regexes can recognize all regular languages, and parts of the set of all Turing-recognizable languages.
0 - Introduction to the Theory of Computation 3/e, Michael Sipser, Thm 1.39, pp. 55.
1 - Introduction to the Theory of Computation 3/e, Michael Sipser, Thm 1.54, pp. 67.
> Unless several topics can be assigned to a person (which seems to be implied in the article), in which case that's 256 bits of entropy available to classify each person.
Good catch, forgot this was a bit-vector not a single key.
> Yeah, well theoretically you could. But that assumes that browsers are able to extract and balance some very arbitrary and very specific information from the browsing habits of all people on earth in a perfect decision tree.
Not really, people have found in the past that combinations of user agent, screen resolution, installed fonts, installed extensions, and things of that sort can come very close to uniquely identifying individual people.
> Though I think you are absolutely correct that in practice the number of bits to build up a classifier able to uniquely classify each person must be pretty low. Maybe a few hundreds.
Exactly. It might not narrow it down to one person, but perhaps a relatively small pool.
At the end of the day, even if you assume good faith on Google's part (which I think is quite a leap), causing the user to present more entropy to the site will make them easier to fingerprint.
256 topics would be ceil(log2(256)) = 8 bits of entropy
30,000 topics would be ceil(log2(30000) = 15 bits of entropy
As a reminder, there are ~ 10 billion people on earth, so if you have 34 bits of entropy or so, you can uniquely identify each person.
So really, the way to think of this as "Google considers making FLoC 20% less effective at fingerprinting users", and that's not even considering other sources of entropy, like user agent or screen size.
Try It Online[0] seems to offer a very similar service - if you don't care about the collaboration aspect of it. It claims to be self-hostable[1].
glot.io[2] is another, which seems to fit more in the realm of "pastebin with runnable snippets".
As I understand it, a big sell of repl.it is that they have some kind of collaborative editing support, which none of the alternatives I was able to find in a few minutes of digging have. Google Colab has this, but only support Python (AFAIK) and is not open source.
Can't say I'm a fan of this. The new redesign looks dreadful; the weird floating tab button thing looks like a UI toolkit bug or maybe someone trying to fake tabs using buttons, rather than an intentional design choice. As other commenters have noted, there is also now no visual distinction between open tabs (tab separator is gone) - how is the user meant to tell that the non-open tabs are even intractable UI elements, let alone distinct from each other?
The menus and omnibar look the same to me though, for better or worse.
It seems like FF is getting worse with every release. Who thinks the changes (read: regressions) over the past few versions are a good idea? Who is the target audience of FF?
I was working at lot with Rego (the DSL for Open Policy Agent) and realized it was actually a pretty nice syntax for jq type use cases.