jameseb

Certainly there are commands not to covet the idols of the nations, but the verses you quoted come from Deuteronomy 7:25-26, where the context is giving instructions for when the Israelites enter the land, rather than commentary on the 10th commandment. If anything, it is more an application of the 1st and 2nd commandments. The account of the 10 commandments in Deuteronomy appears earlier, in 5:6-21, where Moses is quoting the commandments given in Exodus 20:1-17 by way of reminder to the new generation that is about to enter the promised land without him. The command not to covet is generally understood as having broader application than just not coveting idols.

That interpretation of the commandment against coveting seems very unlikely. Exodus 20:17 says:

“You shall not covet your neighbor's house; you shall not covet your neighbor's wife, or his male servant, or his female servant, or his ox, or his donkey, or anything that is your neighbor's."

Nothing there mentions idols, and given the references to wives, servants and houses, it seems particularly unlikely that it is specifically referring to idols.

I assume because it is a relatively new city planned to replace Seoul as the capital city to reduce congestion. Its population would be mostly people from outside moving into the area, and elderly people tend to be more set in their ways and less willing to take risks like moving to a newly formed city.

That code point is U+0D9E SINHALA LETTER KANTAJA NAASIKYAYA. It's a letter in a writing system used in Sri Lanka.

1. Why does it say where T: Sized for references &T? A reference can definitely point to an unsized type, e.g. &str.

I think the point being made is that the layout shown only applies for Sized T. Layouts for &[T] and &dyn Trait are shown elsewhere on the sheet. &str is noted under &[T].

Edit: although, similar considerations would apply to other pointer types, but that isn't noted on the sheet except for Box<[T]>

And in case you can't find the sidebar, the relevant part is:

• Image uploads are enabled 4 weeks after account creation
• Image upload limit is 500kb per image

A cup can refer to a variety of different measurements (see Cup (unit) - Wikipedia). The cup OP referenced is a metric cup, a US customary cup is 8 US fluid ounces. Measuring cups can come labelled using cups as a unit, usually including a whole cup, and that is presumably what OP was referring to.

Well, the good news is that according to this list, your instance already blocks Threads.

10 minutes based on my experience.

To give a theological answer, no. A lich is usually understood as a sorcerer who has achieved an undead state or immortality, usually by binding their soul to the corporeal world in a phylactery. That does not apply in Jesus' case, since he did not pursue any sort of magic to avoid death, much less binding his soul to a phylactery. The resurrection of Jesus was a supernatural act of God, restoring Jesus to true life.

As to the second part of your question, I was not aware that holy water harming liches was a common trope in fiction (it is usually seen in reference to vampires), but even if it is applied to undead more widely, we have established that Jesus was restored to true life, not to any form of unnatural undeath. Moreover, holiness comes from God (that which is holy is set apart for God), and Jesus is fully God, so contact with holy things would not harm him. Indeed, Christ is now in the true holy place in heaven (Hebrews 9:24), which we can only enter when cleansed by his blood (Hebrews 10:19-22).

I'm glad my points we're helpful!

There is some documentation on examples in the Cargo book. The basic procedure is to put it in an examples directory alongside the src directory (and in its own subfolder if it has multiple files), and you can add an entry for it in the Cargo.toml (although it should automatically detect it if you put it in the examples directory, so that is only strictly necessary if you want to change the default settings).

A few things I noticed:

• In http::request::parse(), do you actually need a BufReader? It would be better to make it generic over something implementing BufRead, that allows what you have but also makes tests and examples easier since you wouldn't have to open a TCP connection just to do something that is essentially string parsing.
• In http::response::Response::to_string(), that match on lines 78-85 makes me uneasy, because you are silently changing the status code if it isn't one you recognise. It would be better to signal an error. It would be even better to just check when the status code is set (perhaps with a status code enum to list the ones you support, since what you have isn't all the defined codes) so that you can't fail when converting to a string.
• Consider whether you need a special to_string() method at all, or whether you can just implement Display (which gives you to_string() for free via the ToString trait).
• You are using String as an error type pretty much everywhere. The better approach is to create an enum representing all the possible errors, so that a user of your library can match against them. Make the enum implement Error and Display and it will fit fine into the rest of the error handling infrastructure. There are crates like thiserror that can reduce the boilerplate around this.
• You have an io.rs that doesn't appear to be connected to anything.
• You have a main.rs, which seems off in something that sounds like it should be purely a library crate. You probably want that to be an example or an integration test instead.

That's all I could see with a quick look. In terms of general advice: remember to look at warnings, run cargo clippy, and look at the API guidelines.