dreamingincode

Update: This was an unintended incident: https://www.githubstatus.com/incidents/jfvgcls9swln

The full name "Jia Cheong Tan" doesn't sound like Mainland China. The name and actions could be intentionally misleading though.

https://news.ycombinator.com/item?id=39867737

It does, it's called DocumentsUI and provides the system file picker. However its main entry point is often hidden, and imo it's still somewhat suboptimal/limited in certain aspects. But it's the only way to access the private Android/data directory right now.

Material Files also provides the ability to easily open DocumentsUI for browsing Android/data.

Material Files also allows you add a shortcut to the stock file manager (DocumentsUI), using "Add storage" > "Android/data" from app drawer. You may even manually edit the shortcut to point to a specific subdirectory inside Android/data, and I plan to make that easier (so that you don't need to manually URI-encode your path if you edit) in an upcoming version.

Yes, and this app adopted it as well. There's a toggle in app settings for Material 3 v.s. the old Material 2 right now, and there used to be one between Material 1 and 2.

Different design (Material 2 or 3 v.s. Material 1 mixed with Holo), different UX (e.g. multi-window v.s. dual-pane), Open source v.s. closed source, probably somewhat richer feature set from Total Commander (not entirely sure, didn't try it in depth).

Naming is hard, and I already have to implement file management :P

Just kidding. The reason is that I started the project mostly because I wanted a file manager with proper Material Design, and it's very unlikely that I (or AOSP) adopt a completely different design system.

It's the same for all file managers and the previous way of granting access is now patched via security fixes. If it's still working for you that's very likely because you granted the access before it was fixed, and if you move to a new phone you also likely won't be able to do that any more.

It's a login prompt and you can close it to keep watching. But as linked in another comment, this link may be easier for non-Chinese viewers: https://targum.video/v/2023/8/1/e2ad3b8e86961ccfdcf411d2d4d1...

Under the guidance of Professor Haixin Chang, postdoctor Hao Wu and PhD student Li Yang from the School of Materials Science and Technology of Huazhong University of Science and Technology successfully for the first time verified the LK-99 crystal that can be magnetically levitated with larger levitated angle than Sukbae Lee‘s sample at room temperature. It is expected to realize the true potential of room temperature, non-contact superconducting magnetic levitation.

AI translated video: https://targum.video/v/2023/8/1/e2ad3b8e86961ccfdcf411d2d4d1...

Original video: https://www.bilibili.com/video/BV14p4y1V7kS

Thank you again for all the explanations!

I see. It seems sometimes we do have to live with non-deterministic behaviors or even small errors.

I'm still unsure about the following question from your answers: > when some kind of mechanism mutates two entities in different chunks, which thread is chosen to run this mutation? And how does it mutate the state for the entity in the other chunk? My initial thought was this would require adding locking on every entity, since it might be accessed from another chunk/thread. But that's clearly not ideal. Maybe have a separate list for outside-chunk changes, and merge them with internal changes later?

And regarding having two states: How/when are you sending world state to clients? My thought was to clone the current state periodically and send it to clients (can sending takes less than one tick? I don't have an idea). Sending state to clients seems to be needed if the game needs client side predication, hence this question.

Thanks! The idea of having a list of migrating entities per chunk is good, and it avoids locking on the list of all entities in a chunk. But I still have some confusion about it:

The server looks up the destination in the "active chunk set" I mentioned

but what if the entity teleports to an inactive chunk?

and then uses per-chunk std::vector<>s guarded by a mutex to push "migrating" entities.

Will these migrating entities participate in later calculation within the same tick, or are they excluded? If excluded, what happens when there are two mechanisms that mutates that entity, but the first one put it into the migrating list of another chunk? If included, the thread of which chunk will continue this calculation?

And when some kind of mechanism mutates two entities in different chunks, which thread is chosen to run this mutation? And how does it mutate the state for an entity in the other chunk?

Meanwhile since you mentioned ticks, (just to be sure) are you using a barrier per tick to wait for all threads to finish the same tick? When are the migrating entities merged into the main list, and are you using another barrier for that?

Thanks for the explanation! I happened to be thinking of similar multithreading ideas (chunks and ping-ponging states) recently, but was stuck on what happens when computation happens across chunks in multiple threads. e.g. an object move across chunk border, or an object interaction affecting two objects in different chunks. Could you elavorate on your approach about these? I'm really curious

Why do cooperations have the right to replace people's stuff? People bought it and it's their own.