There's a significant upstreaming effort and their engineers have presented at a Linux con. While not an official product, this time it might actually be different.
"This time"? It's been months. The DTSes were built and upstreamed by community members. Qualcomm was too busy absolutely wasting their time on the Windows Dev Kit which is now dead in the water. They clearly still don't get it.
And AFAICT they're not taking any leadership in the technical areas where ARM is not great (bootloader/DTS selection-y stuff, which has been a varying level of nightmare the entire time I've been tinkering with non-x86 devices. One thing when you're selling an embedded product; a different one when you start wanting distros to support your platform).
Upstreaming code taking months is not exactly unexpected. Having seen it from the other side (legal sign-off alone can be a nightmare), I wasn't expecting it overnight. ARMs lack of standardisation is a major pain but that's a multi-vendor issue. At least Qualcomm is actually engaging the Linux community. Something that works, even delayed, is better than years of community reverse engineering efforts with no guarantee of fully working.
> At least Qualcomm is actually engaging the Linux community. Something that works, even delayed, is better than years of community reverse engineering efforts with no guarantee of fully working.
I don't know that Qualcomm lifted a single finger to help the non-qualcomm employees who have been doing ALL of the work to make ANY Linux happy on their devices. Trust me, I was there with half a dozen other people trying to figure out what kernel module was so buggy that it would cause reboot when loaded in initrm, but without it would block boot. And that was just until I gave up and said to hell with it.
I gave up waiting :(. The first time in 20 years I've not used Linux on a laptop at home. The recent MacBook air deals were too inviting, and I hate to say, solved every complaint I had with my last intel machine.
Like YAML, it's only better in the simple case where everything is top-level and there's only one level of nesting.
Once you want to have arrays of nested objects or objects with arrays, I immediately wish I was just reading JSON so I knew where I was in the tree.
And for that reason, I don't think it's a full contender. I want an answer for the hard cases like nested data, not just another way to write the simple cases which is what TOML is.
For example,
[[a.b]]
x = 1
[a]
y = 2
Versus:
{
"a": {
"b": [ { "x": 1 } ],
"y": 2
}
}
It's easy to complain that the latter is noisier. But that's nothing compared to being clear.
It's not made explicit in the documentation, but TOML is very nearly a superset of JSON - just using `=` to separate key-value pairs instead of `:`, and requiring top-level names to be given explicitly, and requiring the "inline" bits to be on a single line. In TOML, your example can equivalently be:
a = { b = [ { x = 1 } ], y = 2 }
(And yes, that can be the entire document; you can have an inline table before the first table header.)
Of course, this doesn't help if you want the top level to be an "array" rather than an "object" (in JSON parlance), or if you want the entire document to represent a single primitive value. But these uses are discouraged at best anyway.
But really the goal of TOML is to highlight the location of important parts of the deserialized tree structure (hence the ability to use arbitrary long dotted paths in table headers) rather than the structure itself. It's IMO a beautiful implementation of the idea "flat is better than nested" from the Zen of Python, and it neatly sidesteps an issue I asked about many years ago on Stack Overflow (https://stackoverflow.com/questions/4372229 - the question was rightfully closed, as this sort of discussion doesn't fit the Q&A format; but it made sense to ask at the time).
I don't know if a direct comparison of TOML to YAML is fair. Among other differences, the standard way to parse YAML in Python involves a third-party library that brings in a ~2.5 MB compiled C library. Every TOML implementation I encountered - including the one that made it into the standard library - is pure Python.
To my knowledge, such uses were discouraged only because of a security issue from evaluating a JSON string as a JavaScript code and not via something like JSON.parse.
Given that TOML is intended primarily as a format for configs, a config where the root value is an array or a primitive value is hardly a relevant scenario.
Your TOML is rather convoluted, a more normal way to write it would be:
[a]
b = [{x = 1}]
y = 2
Or alternatively:
a.b = [{x = 1}]
a.y = 2
Some parsers allow newlines in TOML inline tables, so you can do:
a = {
b = [{x = 1}],
y = 2,
}
That's supposed to be in the next TOML standard, but that seems indefinitely stalled as the (only) maintainer has seemingly lost interest and there hasn't been any movement for a long time.
This is also the reason I prefer XML to JSON when things really got complex. XML is verbose but it is very readable on long form. I wish Rust actually used JSON or XML as Cargo file format.
I think it works quite nicely in Cargo as you don't generally need much nesting, but anything with depth should use JSON. It's the perfect format for clearly displaying hierarchy.
It works only for trivial projects that are compiled in a roughly up-to-date and popular environment. Custom distros, vendored forks, closed-source software, firmware projects etc. all end up with hairy Cargo files. A systems language should recognize handling complexity gradually is a part of one of its use cases.
Their dictionaries and arrays split into ini-like sections are not very readable though. The double [[ is just nasty and not possible to apply in all situations (array in map in array).
TOML explicitly disallows newlines in inline tables, so that's not a full solution (if you agree that there are some situations where multi-line inline tables are indeed required).
The most common is if you create a reference to a field of a struct that is itself weak. The GC will gc the struct and your var can go from non-nil to nil under the hood despite having zero concurrent code (that you wrote).
The good news is the vast majority of code using Weak semantics is gratuitous - "clever" code that is actually broken premature optimization, and the fix is to just Don't Do That.
AFAIK the biggest issue is the nondeterminism ("inconsistency"), especially in languages which have a weaker type system and make upgrading easy (which is the case of both Go and Java)
- you need to remember to check the result for nil/null, but the type system won't tell you
- if you upgrade twice in a row, you can have both fail, both succeed, or the first one succeed and the second one fail
It can also be tricky to use them as building blocks for weak collections, if you want to avoid unbounded growth.
Probably how Chrome (and recently, Safari) segregate profiles by window. It makes keeping work tabs and personal tabs (for example) very simple / obvious.
The title says the repo is a filters repo. Did the repo actually contain filter rules, or was it used to distribute the closed source plugin package?
I would argue filter rules count as source code as much as anything else.
It doesn't matter if the thing reading the filter rules is not open source.
Aside from that, github intentionally hosts all kinds of content that isn't literally code.
gists, pages, wiki, discussions, issues.
People also host books on github where the text is the code and git is the update system and github is the distribution system, all exactly the same as with a c program. It's not abusing the system like using the CI compute to do random other work, it's using the facilities for exactly what they are each intended for. github wants everyone to use and grow to depend on github for things like that.
You do you, everybody has different tolerance. I am allergic to ads in any form since I strongly dislike when others try to manipulate me, dont want the extra mental load of ignoring ads in a place that is supposed to be relaxing.
I wouldnt want such a device in my home even if they would pay me the sum that it costs + electric bills, every year.
reply