Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dict manager #118

Open
wants to merge 26 commits into
base: main
Choose a base branch
from
Open

Dict manager #118

wants to merge 26 commits into from

Conversation

Juan-M-V
Copy link
Contributor

@Juan-M-V Juan-M-V commented Nov 10, 2022

Passing:

  • dict_read
  • dict_write
  • dict_update

@Juan-M-V Juan-M-V marked this pull request as ready for review November 15, 2022 20:23
hints_tests.py Outdated Show resolved Hide resolved
Juan-M-V and others added 2 commits November 18, 2022 11:35
* Add test for PyDictManager::new_dict

* Add test reading from PyDictTracker

* Add test writing to PyDictTracker

* Add test reading from a default dict

* Add test for current_ptr of PyDictTracker

* Add more checks on previous tests
Comment on lines +101 to +108
#[getter]
pub fn get_data(&self, py: Python) -> PyObject {
PyDictTracker {
manager: self.manager.clone(),
key: self.key.clone(),
}
.into_py(py)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't look like it's getting any kind of data member. Instead, this is effectively a Python object copy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm new to the RC structure, but I believe with the manager being an Rc<...>, when I'm cloning the data I'm actually taking the same pointer and increasing the reference counter by one. Am I understanding this correctly?
If the above is true, wouldn't get_data output an object referencing the same tracker in the input , also being able to modify the data inside the original input?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Yes, Rc<...> returns a reference to the same underlying object;
  2. That's true for the field, but it's still creating a new Python object (and in particular it lives on the heap);
  3. What I'm asking about is more about the type of the return. It's OK that the implementation simply refers to the same cairo-rs object, but it doesn't make a lot of sense that get_data returns the same Python type I think. I mean, think about the API usage, why would you call get_data to get the same PyDictTracker you're calling the method on?

* Add test for invalid key on dict read and write

* Add test for get_tracker with invalid dict pointer
@codecov-commenter
Copy link

Codecov Report

Merging #118 (6128817) into main (207bbbf) will increase coverage by 1.55%.
The diff coverage is 84.37%.

@@            Coverage Diff             @@
##             main     #118      +/-   ##
==========================================
+ Coverage   71.40%   72.96%   +1.55%     
==========================================
  Files          12       13       +1     
  Lines         647      736      +89     
==========================================
+ Hits          462      537      +75     
- Misses        185      199      +14     
Impacted Files Coverage Δ
src/lib.rs 0.00% <ø> (ø)
src/memory_segments.rs 96.96% <ø> (ø)
src/relocatable.rs 94.28% <0.00%> (-5.72%) ⬇️
src/dict_manager.rs 88.88% <88.88%> (ø)
src/cairo_runner.rs 69.49% <100.00%> (-3.07%) ⬇️
src/ids.rs 43.75% <100.00%> (+9.13%) ⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Comment on lines +107 to +110
self.hint_locals.insert(
"__dict_manager".to_string(),
PyDictManager::new().into_py(py),
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd much rather take the GIL only here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants