FuelLabs
UFP64 type for std library
32x32 fixed point numbers library All main + math (except for logatithm, as signed integers types are not implemented yet) functions and testing. Closes #1807
When requesting a review you should consider whether it is a draft or an open PR like this one.
If it is an open PR then you must make sure that all of your CI checks pass because we are assuming that is ready to go into master so seeing a bunch of failing checks clearly indicates that it is not ready for review.
The way that you can fix the mistakes is by checking which CI check fails (indicated by the X instead of the tick / checkmark) and clicking the blue hyperlink "Details". That will take you to the error and it will tell you what the problem is - and sometimes how to fix it. Once you fix all of those mistakes then the PR is ready for an open review.
On the other hand, if it is a work in progress and you want some help via a review then you should mark it as a draft because that indicates the intent of this being unfinished.
Moreover, when submitting a PR that you are working on make sure to assign yourself to it and attach the appropriate labels. These labels should be found on the issue itself that spawned this pull request and if there are no labels then they should have been added in the first place.
Lastly, when writing a description you should use one of the special github keywords (found here) so that the issue is automatically closed when it is merged in. This also makes it easier to find the originating issue and see what it is about. Alternatively, if it is not meant to close the issue but only reference it then you can hyperlink it or use the github syntax which is to use the # symbol and then the number of the issue. Once you type in # you'll see a little drop down where you can even start typing the name of the issue if you do not remember the number.
When requesting a review you should consider whether it is a draft or an open PR like this one.
If it is an open PR then you must make sure that all of your CI checks pass because we are assuming that is ready to go into master so seeing a bunch of failing checks clearly indicates that it is not ready for review.
The way that you can fix the mistakes is by checking which CI check fails (indicated by the X instead of the tick / checkmark) and clicking the blue hyperlink "Details". That will take you to the error and it will tell you what the problem is - and sometimes how to fix it. Once you fix all of those mistakes then the PR is ready for an open review.
On the other hand, if it is a work in progress and you want some help via a review then you should mark it as a draft because that indicates the intent of this being unfinished.
Moreover, when submitting a PR that you are working on make sure to assign yourself to it and attach the appropriate labels. These labels should be found on the issue itself that spawned this pull request and if there are no labels then they should have been added in the first place.
Lastly, when writing a description you should use one of the special github keywords (found here) so that the issue is automatically closed when it is merged in. This also makes it easier to find the originating issue and see what it is about. Alternatively, if it is not meant to close the issue but only reference it then you can hyperlink it or use the github syntax which is to use the # symbol and then the number of the issue. Once you type in # you'll see a little drop down where you can even start typing the name of the issue if you do not remember the number.
CI fails due not due to my code. Merged master into my branch 5 minutes ago, really strange
Nevertheless, the issue needs to be investigated and resolved. Supposedly, this should not be causing issues but perhaps it somehow is? I don't know how it would have made it into master though.
