hvdijk

That's not wrong. It's something that not everybody will like, but as long as the extensions don't conflict with anything specified by POSIX, that is permitted.

To me, the decision to let POSIX mode turn off extensions that are so widely available in other implementations that they have been approved for the next version of POSIX is an odd one. There is little reason not to already use those features today: using them is not going to seriously limit your portability. If you use them, you cannot also use pdpmake's POSIX mode. The obvious conclusion there, to me, is not to avoid using those features, but to avoid using pdpmake's POSIX mode.

Even for those that do not assume GNU make, this may not be enough. GNU Autotools are not limited to running on GNU make, but this make does not implement everything used by Autotools. The first thing I noticed it does not handle is VPATH (https://www.gnu.org/software/make/manual/html_node/General-S...) which is used by Autotools for out-of-tree builds (mkdir build && cd build && ../configure && make as opposed to ./configure && make).

C++ didn't discard that idea entirely, you can have a struct tag and a function with the same name and you need to be able to do that in order to use stat().

Remember that this started with "This one wouldn’t have been censored if it was spelt correctly :)" There is nothing about the US in there, only about correct vs incorrect spelling.

Do you have any support for your position that that is a poor spelling? There are multiple ways in active use of transliterating Japanese. One of them involves writing shi+i as shii to produce shiitake, which is then left as is. Another one of them involves writing shi+i as shī to produce shītake. As ī involves a marker English does not have, it gets dropped when used in English. Both make sense.

I wonder what your professor's opinion on OED is. It includes shitake.

https://www.lexico.com/definition/shiitake (note the "also shitake")

No, it wasn't. Merriam Webster includes shitake as a less common but valid spelling.

https://www.merriam-webster.com/dictionary/shitake

> We can clearly see that YOLOv6s detects more objects in the image and has higher confidence about their label.

If actually look at the images they provide directly above:

In the first image, the older one detects one extra tie. In the second image, the objects detected are the same. In the third image, the older one detects a stop sign, and this new network (no, let's not call it YOLOv6) appears to get confused by the two cars behind one another and detects two objects, but the bounding boxes of the objects includes both, it doesn't look like it actually separates them. But to be fair to them, they do detect an additional person on the left.

You're saying the project's maintainer is deliberately misrepresenting mrustc's goals in order to prevent malicious interference by the Rust community? Both of those seem very unlikely to me and I can't see anything in your message to provide support for those claims. I see no reason not to just take things at face value here.

> And I'd absolutely categorize "use \b instead of \< or \>" as a pretty small difference.

I don't know, to me \b always felt like a bad idea. Start of string (^) and end of string ($) make sense as different symbols, I'm not aware of people asking for a single "boundary of string" symbol that acts as (^|$), I'm not aware of any realistic use case for it that isn't better written using plain old ^ or $. I feel the same way about \< and \>: in any place where I would otherwise have to write \b I already know whether I'll want "start of word" or "end of word" and it won't make sense to allow the other, but \b forces that to be accepted too.

That said...

> Another question is whether we need to also add the negation of each of \< and \> too, to match \b and \B. (I don't know of any commonly accepted syntax for the negation of \< or \>.)

...the negation of word boundaries clearly has uses, but the negation of \< or \> would be a new invention that would add more incompatibilities between ripgrep and other implementations. As much as I'd be in favour of a negation of \< and \>, I'd be more in favour of something that also works in other implementations, which is the \B that you already have.

Just my personal views. I'm served either way by my locally patched version of ripgrep, I'll assume you know better what the rest of your users want.

BRE vs ERE is really a non-issue for me: the way they're done in GNU's regular expression implementation, BRE and ERE are the same except for small differences in when you do and don't put \ in front of certain characters. GNU supports \< and \> in BRE and in ERE mode exactly the same way, and I do use ERE mode a lot as well.

I had a stab at implementing this to see how easy or difficult it would be. Coming from someone who doesn't write Rust: it seems to be pretty much trivial. A quick and dirty implementation is at <https://github.com/hvdijk/regex/commit/511c6485e49c22c79b47a...>. I guess I can use ripgrep with this patch for now to stop my own complaining.

> Right, so you want a POSIX compatiblr tool because POSIX is what you're used to and you don't want to use any other interface.

Well, I would want to use a single RE syntax if possible. It does not have to be POSIX BRE with GNU extensions but that's what is used by the other tools I use.

Looking closer, GNU grep, git grep, ripgrep all support PCRE. That might be an okay alternative. It would take some time and effort to switch over. I do not know yet whether it would be worth the effort, but getting used to a different syntax that's used by a wide number of tools seems more useful than getting used to a different syntax that's used by a single tool, no matter how useful the tool.

> Which is fine. Keep using the old stuff. I don't see any good reason to exactly imitate POSIX when I can go build something that I think is better without being constrained by POSIX. For example, I think just having \b is better than having both \< and \>.

To be clear, \< and \> are GNU extensions, not part of POSIX.

I can't really see how making \< and \> errors is better for users than supporting it in addition to \b. I can see an argument that it's not worth the cost to implement the feature, and that's of course one you're entirely within your rights to make, but not that the feature has a negative overall value.

For the rest, it seems like you and I have different ideas about what the author meant that are going to be impossible to clear up without input from the author, so I will suggest that we drop that unless and until we do get such input.

It's nothing missing, it's just different for no clear reason, and that means remembering different syntaxes depending on which tool I am using at the moment. The one I use most: GNU grep and git grep use `\<` and `\>` for word boundaries, with ripgrep that produces "error: unrecognized escape sequence" and I have to use `\b` instead. (Note: GNU grep and git grep do support `\b` too.)

> Maybe they just mean: if you want to see how man pages are produced in Rust programs, then take a look at how these programs do it.

I do not think that is what they mean. A man page looks the same to the end user no matter what tools are used to produce it.

> Notice also that the OP started this thought with "alternative to coreutils" program.

The start of the thought was "Conform to tools that share a similar niche." ripgrep and fd being implemented in Rust are details that are not relevant to an end user. For ripgrep, the "tools that share a similar niche" would not be "tools that are implemented in Rust", it would be "tools that search in files using regular expressions", and I would be happier with a tool that matches the other tools that I use. So actually I completely agree with the author's principle, I just think it was a bad example.

> Conform to tools that share a similar niche. If you’re using Rust to make a fast alternative to popular coreutils: model its behavior, help-text, and man pages after `ripgrep` and `fd`.

I'm surprised by this. Why wouldn't you model the behaviour after grep and find? The fact that ripgrep uses a different regular expression syntax than grep is my main problem with it; if there were a utility with the functionality of ripgrep, but the RE syntax of grep, I would switch over in a heartbeat.

> Maybe it was, I don't know. What law in PA requires a proportionate response?

Nobody said it was illegal, but a disproportionate response is not likely to go over well with other people here. Whether that is a problem depends on whether you are trying to get along with other people, so will leave that for you to decide.

> They probably already know more than that, because they've seen some emails being exchanged.

Someone being in your contacts list does not mean you have ever had any contact with them.

You don't, you can trigger the installation directly from mainstream Android browsers. When the download finishes, there's typically a notification that it finished, and that notification allows you to open the downloaded file directly without having to go through a file manager.

> Mutual, consenting sexting between two teenagers can't possibly be illegal, can it?

If those teenagers are minors and are sending sexual pictures of themselves, they are sending sexual pictures of minors. Without an exception in the law to specifically allow this, that can be and is illegal by the laws that criminalise possession or distribution of sexual pictures of minors. There should be an exception in the law for it, but until there is, there isn't.

The puzzle doesn't state whether Sandy has figured it out because that information is not necessary to figure out the solution. We can infer that she has (under that implicit assumption that she is a perfect logician) by the fact that we know less than she does and still have enough information, though. As for that last part: we also don't truly know that Peter isn't lying just to mess with the puzzle, I guess. That is another implicit assumption.

We are given that he says he does know and have no reason to doubt it. It is possible that Peter and Sandy know one another and already know that they are perfect at figuring out maths/logic puzzles.

"Trillion" has two meanings. I'm Dutch, we use the traditional meaning of 10^18, what you call quintillion :)

It is both: it is a sequence of turns that if you repeat them over and over, will take you through every possible cube state. But it is possible that the shortest such sequence is trillions of moves long.

It has to exist: it's a mindbogglingly large but finite number of possible permutations, and to go from any one permutation to any other takes a finite number of moves. Therefore, if you can enumerate all possible permutations in some way, any arbitrary way will do, you have a Devil's algorithm by going through them in that order. The question is not whether a Devil's algorithm exists but what the shortest one is.

They may be enforceable even in Europe. The situation in the Netherlands is explained at <https://blog.iusmentis.com/2008/04/05/de-rechtsgeldigheid-va...>; in short, for general terms and conditions that apply to everyone, you merely need to have been suitably informed beforehand and the terms cannot be unreasonably burdensome. In Belgium, a judge ruled in October last year that an EULA cannot prohibit decompilation of software, <https://curia.europa.eu/juris/document/document.jsf?text=&do...>, a ruling that rather directly implies that EULAs are valid in general in Belgium, it is only specific clauses in EULAs that may be deemed invalid. I do not know where this idea that EULAs are invalid throughout the EU comes from. It is simply not true.

The objection that the GP raised, the lack of a check that the result includes all of the elements of the input, is not needed under your notion of a system that works according to its specification, as according to that specification it is a loop invariant. It is also not useful, as it is an infinite loop. Your view of why cosmic ray sort is not a proper sort therefore contradicts GP's explanation, even if you share the GP's conclusion. My question was aimed at further exploring the GP's view; I think an opposing view does not help here.

Do you know of any sort routine that guarantees the result includes all of the input elements even in the event of random bit flips? If not, do you consider the sorting routines in your everyday libraries improper as well or is that a special restriction reserved for this particular implementation?

That is probably a bad example. That is a GNU extension, so if handling this via the preprocessor, the right guard should just be #ifdef __GLIBC__, I think. That should cover both glibc and glibc-compatible libcs such as uClibc. (Yes, uClibc does define __GLIBC__ as well.)

Do you have examples of this? What __linux__ && !__glibc__ should mean, in my opinion, Linux but without glibc extensions. This does not imply musl, but does happen to also be what musl aims for, so there is going to be users where either would look the same.

That may be good. If the pointer arithmetic with integers, or other constructs that have the effect of disabling optimisations, is kept to the code that has additional requirements beyond what the standard guarantees, that means the code out there that does not have those additional requirements, which I suspect is the majority of code, can continue to be aggressively optimised.

That is integer arithmetic, not pointer arithmetic. My understanding of the C memory model that is mentioned in the article (look for PNVI-ae-udi) is that what you are doing is or will be well-defined. I suspect there may still be a few implementations around where the offset you get from integer subtractions has no obvious relation to the offset you would get from pointer subtractions (for two pointers where subtraction is well-defined), but for your example that makes no difference.