Commit 0317f23a authored by Hai Dang's avatar Hai Dang
Browse files

remove notes

parent ae59a004
Pipeline #42811 passed with stage
in 25 minutes and 2 seconds
- Bash Rc<RefCell<T>> for read only traversal.
- Introduce GhostCell::get. Solves this problem.
- Mutably traverse list? Introduce get_mut.
- Much better, but still a probblem--Rc getting on the way.
- Enter: arenas (which are just regions).
- GhostCell works with arenas, but you can also use Cell.
- But, two limitations to Cell: Copy and single-threaded (refer to appendix for Copy issue).
- For multithreaded: continue linked list.
- as_deref() needs to be fixed
- next'x next
- Generally: make it clearer what this means about next's next's mutate.
- Get rid of discussion of Deref and DerefMut.
New notes:
- Main issue: why not references (vs. Rc)?
Sonl: sidestep discussion, say "we want a heap-allocated linked lit."
Cut second paragraph.
"The standard recommended approach."
Get rid of Rustacean comments and "with an open mind," make boring.
- \\Foo''
- Rc<T> : lifetime dynamically determined by reference counting.
- Get rid of "there are way around this in some cases."
- Don't justify it, just say "the standard thing we can use here is RefCell."
(Maybe say "there are a number of types we can consider, but we are single threaded (most are too heavyweight), and Rc<T> is not Copy.")
Maybe just say, RefCell is the only suitable standard library type (footnote).
- Introduction of RefCell:
+ Explain that you call borrow to get a Ref, and when you deref the Ref you get a hared reference.
+ When the Ref.
+ Cut paragraph about RefCell being single threaded.
+ Add line numbers to example.
+ Talk about reverse example (use as vehicle for talking about Ref and RefMut).
- Paragraph after reveree: just say "we use replace" and don't explain anything about it.
"The code is written in the best way possible given the data type."
+ Just use the version that uses the same type signature, longer code.
- Last 4 paragraphs of section 3:
+ Maybe a picture?
+ *Very* subtle,
+ "We're going into this because this is the standard thing recommended, and it really sucks."
+ Give benchmark.
+ "This does not compare favorably with the performance of language Python." -- some sick burn.
+ Refer back to examples in RefCell, when talking about guards, so we can split things up.
- Next section, paragraph 1
+ Two problems with RefCell (bot because of dynamic borrow state).
* 1. Dynamic tracking leads to new failure paths.
* 2. Tracking dynamic borrow state at such fine granularity is overkill, and it's leading to problems with things even as basic as traversing a list.
a. Tracking dynamically (space and time overhead)...
b. Tracking at level of *each* node (too fine).
+ Insight: adopt a coarser granularity (track permissions at granularity of whole data structure).
+ This also turns out to allow us to avoid paying *any* dynamic cost in common cases.
- Avoid explicit cmparison to BrandedVec.
+ Just say "in the spirit of" or something (still using phantom type API) but for interior mutability.
+ Then just descrbe it.
- Typo in GhostToken API.
+ Fix to use impl FnOnce.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment