Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add generator for existing atoms #310
base: master
Are you sure you want to change the base?
Add generator for existing atoms #310
Changes from 3 commits
a76d552
61041f0
33594d9
fd445b8
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These two functions, and the PR in general, should describe the main idea of the existing atom generation algorithm and the assumptions it relies on. Also its limitations.
Having written that, if I understand what the
existing_atom_gen()
does, it is in fact not an atom generator (in the sense thatproper_gen:atom_gen/1
is), but it simply returns a random atom from those (currently) loaded in the atom table, which it stores in its own map, right?Since there is a magic way (the
<<131, 75, Index:24>>
trick) to access each of these atoms given anIndex
, and the upper limit of this index is known ( it is given byerlang:system_info(atom_count)
), what is the point of first iterating through all these atoms putting them in an internal map, rather than randomly picking oneIndex
in the range and returning the corresponding atom? (Perhaps after anum_tries
if this process is unlucky to only end up in atoms starting with$
.) What I am missing?Incidentally, I do not like the magic constants 131, 75 and 24. They should be made appropriate defines and ideally obtained by the Erlang/OTP system somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is correct, yes. "Find all existing atoms, (store them in the map,) pick one at random". The term "generator" is probably not the exact term to use here (I guess this is you objection?), but what is the correct term to use?
Nothing I think ;) That is a great suggestion, I'll do that. How about we use a fallback atom like
''
to return if all tries turn up atoms starting with$
? We need to return something, right?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's very unclear what these tests really test and what their underlying assumptions are.
For example, their correctness crucially depends on not loading any other Erlang modules between the two calls to
erlang:system_info(atom_count)
. Is this robust to e.g. executing all the PropEr tests in parallel?Also, it's unclear why the
default_atom_test
is using theany()
instead of theatom()
generator. For example, the test trivially succeeds ifany()
happens to return terms other than atoms...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, the tests are brittle, meant as a first attempt =(
Executing PropEr tests in parallel is likely to break them. In fact, anything else that may be going on in the system may break them.
The
default_atom_generator
option, by and large, decides what atom generator is used in theany
generator, eitheratom
orexisting_atom
(there is probably a better name for this). Anyway, this is the reason whyany
is used in the test. And yes, ifany
happens to generate only non-atoms, this test will pass. I tried with?SUCHTHAT
, but then the test fails if the generator fails to produce any atom.I'm at a loss about what to do about this, or rather how to test it PropErly. Thankful for advice 🤷♀️