Skip to content

Conversation

@kinke
Copy link
Contributor

@kinke kinke commented Dec 1, 2017

Pinging @klickverbot and @ibuclaw.

@dlang-bot
Copy link
Contributor

Thanks for your pull request, @kinke! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.

Some tips to help speed things up:

  • smaller, focused PRs are easier to review than big ones

  • try not to mix up refactoring or style changes with bug fixes or feature enhancements

  • provide helpful commit messages explaining the rationale behind each change

Bear in mind that large or tricky changes may require multiple rounds of review and revision.

Please see CONTRIBUTING.md for more information.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

assert(bufferSize < Element.sizeof);

// Check if we have some leftover data in the buffer. Then fill the first block buffer.
// Check if we don't even fill up a single block buffer.
Copy link
Member

Choose a reason for hiding this comment

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

This is very awkward wording. What about "check if we can fill up a single block buffer"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The true-branch with early return is for the opposite case, i.e., where the current bytes in the block buffer and the new bytes to be hashed don't add up to a full Element size.

Copy link
Member

Choose a reason for hiding this comment

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

Not sure whether applicable here, but don't forget that for simple documentation matters patching someone else's PR is almost as easy as submitting a comment.

Copy link
Member

@MetaLang MetaLang Dec 2, 2017

Choose a reason for hiding this comment

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

I don't like the idea of editing someone's pull request unless it's something small and obviously wrong or it's necessary for some reason.

Copy link
Contributor

Choose a reason for hiding this comment

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

@kinke "check if we can 't fill up a single block buffer?" ;-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Now: Check if we don't fill up a full block buffer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just noticed fill up a full ... =>Check if we don't fill up a whole block buffer.

const numElements = data.length / Element.sizeof;
const remainderStart = numElements * Element.sizeof;
foreach (ref const Element block; cast(const(Element[]))(data[0 .. remainderStart]))
version (haveUnalignedLoads)
Copy link
Member

Choose a reason for hiding this comment

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

Haven't we already talked about this before? Or am I thinking of another patch.

Copy link
Contributor Author

@kinke kinke Dec 9, 2017

Choose a reason for hiding this comment

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

Possibly, not with me though; a first incarnation of this murmurhash patch is in #5358 (which I only realized after creating this PR). This one here still isn't fully satisfactory as casting a static array to another static array type may not be well-defined in the spec (haven't checked, but it's reinterpret_cast vs. conversion to new rvalue). The latest (LDC-specific) version without ambiguities is ldc-developers#44.

Edit: Now updated here too.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Now in PascalCase.

std/math.d Outdated
const real zz = z * z;

if (zz > 1.0e-20L)
enum zzThreshold = (floatTraits!real.realFormat == RealFormat.ieeeDouble ? 1.0e-14L : 1.0e-20L);
Copy link
Member

Choose a reason for hiding this comment

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

Store floatTraits!real in an alias instead of instantiating it multiple times in the same function?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Twice to be precise, and an enum isRealDouble would suffice. If you insist on adding a new line for shortening these 2 lines, I won't refuse. ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There was a third usage I previously overlooked => enum realFormat.

@joakim-noah
Copy link
Contributor

@kinke, you can remove the second and third commits relating to Android and std.allocator, as they were just merged in another pull.

@kinke
Copy link
Contributor Author

kinke commented Jan 4, 2018

Rebased and slightly reworked.

/++
The default directory where the TZ Database files are. It's empty
for Windows, since Windows doesn't have them.
+/
Copy link
Contributor

Choose a reason for hiding this comment

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

Why does this comment need to be copy-pasted for every platform?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

AFAICT just because the version(TZDatabaseDir) branch (which seems obsolete) doesn't start with the enum, but needs a prior import; otherwise, the comment could be placed once before the version branches. [Outside the scope of this PR though.]

Copy link
Contributor

Choose a reason for hiding this comment

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

It was added a week ago: #5966

Copy link
Contributor

Choose a reason for hiding this comment

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

FWIW we only support building the docs on Posix since 1.5 years, so adding comments in other branches isn't needed, but doesn't hurt either.
Anyhow @kinke said, it doesn't block this PR.

Copy link
Member

Choose a reason for hiding this comment

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

The ddoc comment really should be put in a StdDdoc version block and removed from the other versions.

Copy link
Contributor

@joakim-noah joakim-noah Jan 5, 2018

Choose a reason for hiding this comment

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

I see no reason to put this off for later, I'd rather it were at the top with a StdDdoc version or just as a comment. Just change it to say that Windows doesn't have one and TZDatabaseDir lets you set one at compile-time in an external file, which btw it doesn't even explain now.

Copy link
Member

Choose a reason for hiding this comment

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

Who can take care of this in a follow up?

@kinke
Copy link
Contributor Author

kinke commented Jan 24, 2018

Ping - the changes are trivial except for std.digest.murmurhash, but DMD and x86(_64) are mostly unaffected by that commit.

/++
The default directory where the TZ Database files are. It's empty
for Windows, since Windows doesn't have them.
+/
Copy link
Member

Choose a reason for hiding this comment

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

Who can take care of this in a follow up?

@andralex
Copy link
Member

@kinke autotester plz

@wilzbach
Copy link
Contributor

The failure is unrelated - see #6061

@joakim-noah
Copy link
Contributor

I'll fix the comments in another pull, if that's what you're asking.

kinke added 2 commits January 26, 2018 20:16
Minor fixes after cross-checking against the Cephes implementation for
doubles, see
https://github.com/jeremybarnes/cephes/blob/master/cmath/tan.c.

The `assert(!isNaN(tan(0x1p300L)))` unittest (still) fails for 64-bit
reals, while `tan(-0x1p300L) == -0x1p300L`. Not really suprising, as the
total loss threshold is 2^30; Cephes returns 0 as error for greater
(absolute) inputs.
The threshold for 128-bit quadruple reals is 2^55 btw.
@quickfur
Copy link
Member

Are @MetaLang's concerns already addressed? Should we merge?

@joakim-noah
Copy link
Contributor

I think so. It was just about a comment, which has been changed since. Can probably dismiss his review if he doesn't.

@MetaLang
Copy link
Member

I still don't like the wording (check if we don't is very awkward to read and try to understand), but if this is ready to go it's not worth holding up for a comment.

Copy link
Member

@quickfur quickfur left a comment

Choose a reason for hiding this comment

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

OK then, let's merge! It's long overdue.

@dlang-bot dlang-bot merged commit 2f25cdf into dlang:master Jan 29, 2018
@kinke kinke deleted the ldc_to_upstream branch January 29, 2018 21:19
wilzbach added a commit that referenced this pull request Jan 31, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants