No, that's not really an accurate rephrasing. Your comment indicates the problem is that it was exposed as a specialization, KerrAvon is saying the problem was instead that the specialization wasn't effectively abstracted (hidden) behind the API of vector (ie: implication is that ideally we'd have a better API for vector that might require C++ language changes due to the nature of the problems with vector<bool>. not that we shouldn't have the specialization)
> Your comment indicates the problem is that it was exposed as a specialization
Because that is the problem? That's what C++ programmmers are unhappy about.
> ideally we'd have a better API for vector that might require C++ language changes
Ideally after almost thirty years "maybe we could re-design the whole programming language to paper over this bug?" would be such an obviously bad idea that I wouldn't see it in a response.
I recommend not indicating you're rewording another commenter when you actually disagree with them if you don't want that difference in content pointed out. I note that you've trimmed out the parts of my comment that made it clear I was drawing that distinction. Maybe you missed those?
Separately, though, it's not accurate to call this "papering over [a] bug". Wanting to have a thing that behaves like a reference that can identify things that aren't addressable directly (ie: having custom reference representations) shows up in a surprising number of places as desirable because we use references (and things like references) as an abstraction in many programming languages to enable nicer, more usable syntax (ie: having assignments behave in a particular way).
Edit: and changing the language would have been at the time that std::vector was designed (ie: c++98-ish c++ has a real problem with abstracting over not-really-references). With current c++, we can get a reference-like-object much closer to being fully transparent (`auto&&`, ranges iterator model, etc). But std::vector regrets reflect the constraints of the time when it was initially designed/standardized. C++ doesn't have a good story for making breaking changes, so if folks want a good vector for bits, today they'll go elsewhere.
> I recommend not indicating you're rewording another commenter when you actually disagree with them if you don't want that difference in content pointed out.
I can see why you're upset but KerrAvon describes their statement as the result of "a cursory web search" and it isn't false so I wanted to be clear that what they wrote was not wrong per se. I don't think I "disagree" with a person who used Google, read some stuff and came away with an emphasis on the technical reasons this is a problem rather than how it's actually a problem for real programmers.
Maybe I do disagree with you, that's very possible.
With current C++ you could design a specialization that's somwhat less crap. But what's actually important - and what would actually happen - is that you would not standardize such a specialization at all because everybody knows it's a bad idea to do this - it would still be crap if you tried today, just less crap than in 1998.
C++ chooses to have a bad story for breaking changes. That's a deliberate choice and should be understood that way. WG21 are not hapless victims.
I definitely agree that the state of the committee's management of C++'s ability to have breaking changes is not good. Languages should really learn from how rust is handling that pattern, as it seems like it's working fairly well there. Though rust so far has a much shorter lifetime, and hasn't needed to make as large of changes as C++ has needed, the editions model (or something like it) with isolation between translation units seems like it's very workable as a general pattern.
You've mixed up your context here. Web pages are not generally "facts" under US copyright law, and redistributing them from a database doesn't turn them into facts, nor does it engage the normal "collection of facts" (aka database) rules about US copyright. And even if the webpages were "facts", the only part of "collections of facts" that gets copyright protection is the creative part. Which can't be the plain content of the facts.
Here's mine[1], stating that yes databases do get some copyright protection from the collection layer to the extent that some creative addition happens.
I never claimed the individual facts/data were given copyright to the collector. Let's stick to what I said if you are going to quibble with my comment.
Here's the relevant portion of the original comment:
> Yes, it is like they think they get copyright/IP over someone else's content that they had no part in producing, just syndicating without any license.
Here's what you said:
> You do realize that US IP law does work that way, right? You can have a copyright of a collection of facts even if you don't have a copyright of each individual fact in the collection.
Here's where you've gone wrong in those original comments:
- The original poster is talking about copyright-able works (in the context of this thread, those are websites).
- We're eliding "websites" into "facts" somehow - and as I've said, facts aren't copyrightable (https://www.copyright.gov/title17/92chap1.html#102) - and collections of facts (which are only have copyright over creative portions)
- And your first sentence is misleading as the poster is talking about the content of websites being treated as copyrighted by the collector, so we're already off track with the implication that the "fact" (website) is copyrighted when it's part of a database by the database constructor.
- I then proceeded to talk about how collections of facts interact here (ie: 'even supposing if' websites were somehow facts, which they generally aren't under copyright law).
- That's where the "only the creative parts of the database are copyright-able" (https://supreme.justia.com/cases/federal/us/499/340/, https://law.justia.com/cases/federal/district-courts/FSupp2/...) comes in. And again, refer back to the original comment, which is about the websites themselves, so we're kind of off track talking about creative parts of databases, but it is somewhat relevant due to comments further up talking mentioning the "relevance scores, or rankings" as something that the agreement prevents using freely. Those "relevance scores, or rankings" might be protected by copyright, though I suspect it would be a close call.
- Making a database of all websites is not creative (see the Feist Pubs., Inc. v. Rural Tel. Svc. Co., Inc., 499 U.S. 340 (1991) linked above, where a database of all phone numbers was determined to not be creative in itself). If the results of a particular search (ie: which results correspond to a particular search) are copyrighted hasn't been fully litigated, but Google themselves didn't claim their search results were copyrighted in the ongoing Google LLC v. SerpApi, LLC (4:25-cv-10826)
litigation (https://storage.courtlistener.com/recap/gov.uscourts.cand.46..., III. B. 1 has a discussion).
Now to the most recent comment:
> Here's mine[1], stating that yes databases do get some copyright protection from the collection layer to the extent that some creative addition happens.
You haven't distinguished it from my previous comment with a statement on what is copyrightable in collections of facts. If you believe that non-creative parts of collections are copyrightable, then examine the references above in this comment, and the section in what you've linked titled "Feist: Originality and Creativity". If you don't believe that, then you may want to be more clear.
Ah okay, interesting, stuff has gotten slightly more complicated since the last time I tried this, but fundamentally it sounds about the same in terms of "boot into recovery, run a couple of custom commands, make changes, boot back".
The sealing of the filesystem can be disabled trivially, though, via a command line tool that Apple ships with MacOS that you run from recovery mode.
And then you can remount `/` as read-write, and create a new blessed snapshot with your changes made to it.
This doesn't actually delete the signed snapshot though, so the space consumed by `/System/Applications/Chess` still is consumed. I'm not sure if MacOS will allow deleting the final sealed snapshot for `/`. It might, I don't know that anyone is clamoring for it though.
but yes: that ui in the article is likely entirely imaginary, but it's likely an option (either in the ui for private beta users or by raising a support ticket or by some internal tool) to get sha256 repos today.
The goose language has dynamic allocation via builtin types, like most systems for the past 40 years (Folks were using dynamic allocation on systems back when 640k was a lot of memory). Most embedded systems these days far exceed the capabilities of 40 year old desk top computers and also use extensive dynamic allocation.
The distinction for goose is that it has fixed locations where the free must occur (function return, effectively), not that it doesn't have dynamic allocation (because it does have dynamic allocation)
People working on cortex m series chips still static alloc though. :D
Them and game programmers. Also the HFT people from my understanding.
The latter two are due to latency concerns.
Still though, it is something that I think more engineers should try out once or twice. Thinking about how buffers actually need to be is a useful exercise.
It appears they got around that by making expanding and contracting data arrays builtin types the compiler impls. And it does this by creating what they call a "data stack" for each thing that needs to grow. To me it reads like "we have a builtin type that hides the heap allocation and does the free at the scope exit ", which is fine I guess as it keeps the nature of the language in tying lifetimes strictly to function scopes.
If your system has a way to take consistent snapshots in the filesystem (btrfs, zfs) or volume manager (lvm2, perhaps with a bit of filesystem support to obtain fs consistency), that can be used to avoid database downtime, if desired.
Despite all the fancy language, its more about aligning the AI behavior with the corporation's interests.
ie: the corporation wants the AI to behave a certain way for various reasons: to make it easier for them to avoid regulation, to make the corporation more money via different tiers of AI offerings, to ensure that the corporations products are hard for competitors to use, etc. And those are just the easy ones.
Every product is shaped this way. AI is not different.
Prompt regurgitation. Model was likely instructed to create the app to do this piece "by hand" (or a phrase with similar interpretation) because the author wanted to avoid pulling in a dependency of some kind.
reply