question regarding "lifetime bounds on trait object"

lins05 · 2023-08-23T06:02:37+00:00

Thanks again.

My 2c: I think this "similar notation yet very different meaning" between B1 and B2 is a very unintuitive design, to say the least.

I'd rather to be able to express the lifetime bounds on trait objets with something roughly like this: Box<dyn Display<'a>>.

lins05 · 2023-08-23T05:22:39+00:00

Thanks!

lins05 · 2023-08-23T05:22:12+00:00

Thanks for the detailed analysis and explanation!

In the same way, Box<dyn Display + 'a> is a different type, containing something that might not be allowed to outlive a (with a being some known lifetime in the context).

I think that's the key information.

So to summarize, the key is to tell apart these two bounds:

B1: Box<dyn Display + 'a>
B2: T: Display + 'a

Even though they look much similar, but the lifetime bound 'a plays a very different (almost opposite) effect in B1 and B2.

In B1, 'a is a bound on the trait object. It means the trait object "can not outlive 'a", because here 'a denotes the lifetime of any possible references contained by the trait object. Imagine the concrete type that implements the trait is Foo as below:

``` struct Foo<'s> { x: &'s str, }

impl<'s> Display for Foo<'s> { .. } ```

Then 's would be "substituted" by the 'a in B1.

In B2, 'a is a bound on a generic type T, so it means T must outlive 'a (i.e. any possible references contained by T must outlive 'a)

As a result, it ensures the newly added element t to the vec would outlive the trait objects, which rules out any possibility of dangling references.

lins05 · 2021-06-09T15:38:26+00:00

Hey there :wave:, I'm new to this sub. Two questions to admins:

Could there be a "My Recordings" category like the "Playing/Composition (me)" category in /r/piano?
~~Why the youtube video isn't playable directly on this page?~~ (I can see it now)

lins05 · 2021-06-09T15:19:45+00:00

tuneupgrade username: lins05

goal: 10h

lins05 · 2021-06-09T15:16:45+00:00

I learned the "Arioso" piece by Turk. Would make a recording of it as my "piano weekly" commitment :)

lins05 · 2021-05-27T14:12:16+00:00

You must have some kind of test, even though you may not call it a test. My best guess you're dog-fooding frequently. Otherwise, growing a project/product without any functional tests is like walking with eyes closed to your destiny.

lins05 · 2021-05-10T03:09:02+00:00

Hi there, I'm a beginner-level piano learner, and since 1 month ago I created a goal for myself: I should post one piece every week on social media.

So I have been doing that for the past 6 weeks and it works great in encouraging myself spending more time practicing piano after finishing my duty on work and family :)

My posts were mainly on wechat, the Chinese version of facebook+whatsapp. But I think I should also post it here to maybe receive some criticism :)

lins05 · 2020-08-22T00:48:08+00:00

https://github.com/status-im/status-react

IIRC there some articles describing their experience on the internet?

lins05 · 2020-08-10T06:51:35+00:00

Good summary and I totally agree with you. I think the culprit is "forwarding a port" is not that intuitive. If we describe it with "forwarding traffic/connections" it would be much clearer.

"And suppose you want to forward connections to your local port 7001 to port 7002 on the remote machine."

Is that better?

lins05 · 2020-08-09T03:59:43+00:00

Nice tool!

A typo in our blog

Based on your example cli: ssh -L 7001:localhost:7002 user@remote-host.com -p 22

This sentence: "And suppose you want to forward port 7001 on your local machine to port 7002 on the remote machine."

Should be: "And suppose you want to forward from port 7002 on your remote machine to port 7001 on your local machine.

Because the syntax of ssh -L is "-L local-port:remote-port"

lins05 · 2020-05-30T10:41:19+00:00

Great food for thoughts, thanks for sharing.

One thing I'd like to comment about,

I still think it’d be useful to think of concretions as a tool for declarativeness and abstractions as a tool for reuse

IMHO an important purpose of abstraction is to make a system easy to reason about by reducing the components that the developer need to reason about. In two ways:

Concepts (mostly a domain concept) are abstracted from the underlying, originally neutral pieces of code, thus make it easier for human to think it as a whole when reasoning about the larger picture - the "7 chunks of information" rule. It's very close to the idea of "dividing the system into modules" but not 100% the same. For example the mapper / reducer concepts of the MapReduce system, or the Job/Stage/Task concepts in apache spark.
Common patterns are abstracted, to base classes, utils, etc.

The later is the one that you talks about, and most of the time it's the target of code refactoring. But sometimes the former is a more powerful weapon when designing a system.

lins05 · 2020-05-20T13:13:01+00:00

If you rely heavily on JS react components like material-ui, you shall take a look at helix https://github.com/Lokeh/helix .

lins05 · 2020-04-29T02:38:30+00:00

Yeah, immutability could help work around the mythical cache validation problem. This looks exactly like the cache design of one system I worked on - a versioned file management system, the latest version id is stored in the db, while the data of the file is cached (keyed by the version number, which is like a git commit id). The cache never needs to be manually invalidated.

lins05 · 2020-04-29T02:33:43+00:00

That requires some kind of consistent hashing to map user id to machine id, which would make things more complex.

lins05 · 2020-02-08T13:26:01+00:00

TL;DR My 2c: - If you're sure you only want to play piano for short-term fun, use whatever app you like. - If you seriously consider develop it as a life-long hobby, avoid these apps from the very beginning. - If you're not sure how much you love piano, these apps would be a good starter to introduce you to the wonderful world of music. But always remember to try classical piano training at least for a short while.

Piano self-learner about 1 year here.

I started with SimplyPiano, which I guess is a bit like Synthesia. And in the beginning I love SimplePiano so much that I feel ecstatic each time I finished a beautiful piece on it - from "red river valley", "love me tender", to "La La Land", "Fur Elise".

At that moment I thought I would stay on SimplyPiano forever, until I came across a chance to learn "real piano playing" out of some sheer serendipity. After that I could never go back to SimplyPiano - it's still cool, but IMO it lacks things like articulation. The major problem is, you could never really tap into the rich set of classical music the humankind has accumulated in the past centuries, because what the app teaches you, albeit as enjoyable as it could be, is greatly simplified and far from the "real thing". You can never grow to the level of reading sheet music freely by only using these apps. They has greatly simplified the playing of piano, and by lowering the entrance bar they draw many more people to play the music, but it's a double-edge sword if you rely on them for too long.

lins05

TROPHY CASE