cmyr

This question has been answered at least twice in comments in this thread.

On this very specific point, for this specific problem, I think that `Rc<str>` is criminally underused. It's a great type if you need a heap allocated string, but want to hold on to copies of it in various places; and it derefs to `&str`, so you can use it transparently with most of `std`.

Mentioned this briefly below, but this was largely an academic exercise: there is a lot of existing code written (in python) against the python API in question, and I was curious to see how feasible it would be to reimplement that API in such a way that this existing code would continue to work with minimal modification, but now running on top of a rust implementation.

What's additionally challenging in this case is that the design of the underlying rust API (the norad crate[1]) was also more or less done, so this really was just a matter of trying to shim.

In any case, I think we more or less agree; just trying to provide a bit more background on the motivation. This was originally just circulated as a gist between a few interested parties, who were largely familiar with the motivations; it certainly didn't occur to me that it might be interesting to a general audience.

[1]: https://docs.rs/norad/0.4.0/norad/

There are a lot of existing python scripts that run on top of the existing python `ufoLib2` library, and the initial motivation for this work was seeing what would be involved in creating a wrapper API that would allow all of these existing scripts to work transparently on top of an existing rust crate.

I think there might be some issue on that hardware where 2.4ghz wifi and bluetooth share an antenna, and can interfere with each other? If you're using 2.4ghz and can use 5, give that a try.

If memory serves, adobe announced the end of support for Type 1 fonts just last year. (This was mentioned in a conference talk, but apparently it's official: https://creativepro.com/adobe-is-ending-support-for-type-1-f...)

In any case I've coincidentally spent the week spelunking in the truetype spec; there are tons of old representations and font features that a robust font parser is still expected to support, and some of it is wonderfully arcane.

The solver is still a little rough, and there are some robustness issues in certain circumstances, generally when points are very close together. This will get ironed out eventually.

This is correct, the hyperbezier positions auto points to maintain curvature, so anything that impacts curvature of a segment can cause adjustment of the handles of neighbouring segments. In addition, auto points do not need to be smooth; you can have a corner with two auto points, which will be adjusted automatically in response to changes in segments to their 'side' of the corner (see the heart demo on the page for an example of this.)

This is mostly circumstance; the prototype is a compilation to wasm of a bunch of code that was originally written for runebender, a desktop font editor. The framework that project is written in uses canvas when targeting the web.

It's jekyll under the hood, merely a tribute to the good old days. :,(

When he dies he can be the greatest ever, but today let it be Maradona.

Given all of his struggles this is not exactly a bolt of lightening from blue skies, but I'm feeling surprisingly moved by this one.

The reason this can't be done quite as you describe is outlined in the linked issue: if something implements both `Iterator` (as Range does) as well as `Copy`, then you can end up in situations where you accidentally end up copying an iterator you think you're mutating. A good example is provided here:

https://github.com/rust-lang/rust/issues/48649#issuecomment-...

I broadly agree with this, and am most frequently confused by the fact that a `Range<T>` isn't `Copy` even if `T: Copy`. I feel this was a small design mistake (having `Range` itself be an interator instead of implementing the `IntoIterator` trait) but there is a proposal to fix this that looks like it wouldn't be breaking, and so should be possible:

https://github.com/rust-lang/rfcs/issues/2848

Whatever works? My personal favourite example of "hmm, I guess you can do that" is david tolnay's publishing a blog as a rust crate; all crates have their docs parsed and uploaded to docs.rs, so, well, why not¹:

https://docs.rs/dtolnay/0.0.9/dtolnay/macro._01__await_a_min...

1. lots of reasons, probably.

various possible ways: for instance (theoretically) heat and humidity might effect how long virus survives intact outside of the host, or increased UV light exposure could speed up virus breakdown.

Carthage is listed as "Tangier"? Unless it was just added.

Neat! I was just about to need something like this, for building native app bundles for druid[1]. I'll open an issue, but do you have any interest in exposing this as a library?

[1] https://github.com/xi-editor/druid

yep, TODO is for things like possible optimizations or improvements that are known, and FIXME is for things that are... functioning, but incorrect by some reasonable definition. (YMMV)

The article says that even if orcas pass through an area where the sharks are hunting, the sharks will leave the area and not return for months. It does not mention any sharks being killed.

This isn't much different from lending your car to someone without asking if they have a driver's license, period? I mean it's slightly different (I'm not sure if the car is automatically impounded for driving without a license) but I think they're making a big deal out of a fairly minor detail. If your friend borrows your car knowing full well that if they're pulled over it's going to be evaluated... maybe in general a good sign it's time to reevaluate that friendship?

It's subtle. The second phrasing ("how not to x") is idiomatic, and means, roughly, "some things that you should not do when you do x", or "an example of how you should not go about doing x."

So, an article titled, say, "how not to paint your house" would be expected to outline things to avoid when painting your house, and "how to not paint your house" could just be "go for a bike ride instead."

This is utterly unhelpful whataboutism. The japanese internment is not ongoing, is broadly recognized as an atrocity, and has been formally apologized for by the governments involved.

- https://en.wikipedia.org/wiki/Civil_Liberties_Act_of_1988

- https://www.cbc.ca/archives/entry/1988-government-apologizes...

"Design isn't what it looks like, design is how it works".

That is: the idea of some clear separation (or worse, tension) between mechanical engineering and "design" is, to my best understanding, antithetical to what has made Apple an interesting company that makes interesting products. Mechanical engineers are doing design work. So are metallurgists and material scientists, as well as typographers.

This is a late thursday press release, and this is an uncharacteristically quick response from Gruber. He's shooting from the hip, but I think he has a valid concern, and it's a concern I suspect is shared by lots of folks who have been using apple computers for a long time: who is actually responsible for making product decisions?

This is a slight derail, so apologies, but: I've been just starting to get interested in shaders, and have been spending time reading things on shadertoy and working through BoS. Something I find really annoying about shadertoy is the pretty ubiquitous focus on minimizing code size, which I can understand in the context of demoscene, but which is super annoying when you're trying to read something to understand it.

What I'd love to see is something like an 'annotated shadertoy', which encourages inline documentation and explanation of the various moving parts. If anything like this exists, I'd love to hear about it!

The major innovation of kakoune, imo, is to combine modal editing with multiple selections. These are two very powerful concepts that haven't been combined well before, to the best of my knowledge. In any case yes, I think kak is a great editor and a definite source of inspiration.

Language features are definitely in the near-term plans for xi, and depending on what stage Rust Analyzer is at it could definitely be a good initial target for some of that work.

There's sort of an uncanny valley sort of situation, in my experience (as an anglophone canadian with the french of a 3-4 year old): If you're clearly a foreign visitor, and you're speaking bad french, it's often appreciated and maybe found slightly charming. But once you get to the point where your french is reasonably good, but you have an obvious accent, then (some) people (might, sometimes) be more inclined to be a bit snooty about it.

Well they're both on the 'fastest growing'[1] list, which is about what I'd expect.

1: https://blog.github.com/2018-11-15-state-of-the-octoverse-to...

Put another way: python 2 has a 0% chance of correctly handling Unicode.

My experience as well; started asking drivers which they preferred, and they all said Lyft. That alone is a good reason to switch. I'd happily pay a 10-20% premium if I can feel confident that it's encouraging better working conditions.

This goes for other markets as well, it's just generally hard to get good information.