- User Since
- Dec 18 2014, 1:25 PM (113 w, 5 d)
@austin tells me that this should now be fixed.
Yes you are right.
It is really hard to see what is going on here. Perhaps you could put each commit up as a separate diff?
Sun, Feb 19
Sat, Feb 18
Fri, Feb 17
Thu, Feb 16
Does your patch actually compile? arc is working again now, please can you update the diff so I can see it more clearly?
Wed, Feb 15
I don't think a test is necessary.
Tue, Feb 14
Mon, Feb 13
This commit seems like it broke the OS X build.
Sun, Feb 12
Fri, Feb 10
This passes for me now on OS X.
Like I said on the commit. The test also fails on OS X due to differences between clang and gcc I guess. I can try to test this locally so you are not waiting years for the builder to finish.
Also failing on OS X
Thu, Feb 9
What command were you running?
Tue, Feb 7
This isn't the right fix it seems.
Mon, Feb 6
Also the differential description needs to be updated to describe the feature as this will become the commit message.
@amindfv Please can you upload you SSH key and update the diff (using arc diff --update D2822) so that the changes are pushed to the staging repo and built by harbormaster?
Sat, Feb 4
- Simon's comments and update existing test to test strictness properties
I don't really think the pattern match checker is the right place to issue an inaccessibility warning so I think this is done for now.
- Choose right base commit
- Update with new base commit
- Accept new test output
Good job you spotted this Reid.
This solution feels very indirect. It is obtuse to keep dead bindings by making them live bindings in an unrelated part of the code upstream and potentially very confusing.
Fri, Feb 3
@yav The commit message is generated from the description field. If in future a user needs to search the commit logs then it is useful to include a detailed commit message rather than a pointer. For example, a user might want to know which commit introduced HexFloatLiterals extension, which they could find out by searching the commit logs for HexFloatLiterals.
See some more discussion now on D3024
I think I agree with @christiaanb about this. What is the benefit of adding natural literals to core? Trac #13186 provides no motivation and this patch provides no motivation for changing the non-core representation to be Natural. It seems much easier to keep the internal representation as Integer and convert it once to a natural in a library somewhere if that is the evidence you want to provide.
Please can you update the description to describe the feature and link to a relevant trac ticket?
Thu, Feb 2
I think this is better than not issuing any warnings as otherwise users will fix this warning and recompile and then have to fix the warnings which we didn't bother to show them. If someone complains later (which I doubt they will) we can implement something else.
I am not 100% sure this is the right fix but we will see what George says.
Wed, Feb 1
I think it is fairly self-evident removing this will cause bad things to happen but I can add a test if you so desire.
I don't know why they are different. How do people usually fix this?
Tue, Jan 31
- Fix typo
- Respond to Simon's comments.
I think this change is causing two tests to fail on the travis build.
Ok, looks like all the tests pass. I am still intrigued whether this information is used in downstream modules at all.
Did you observe that this was causing a problem or just noticed it when reading the definitions?
Do you add a test or some performance numbers to show what difference this change makes?
Mon, Jan 30
The builders are tripping up because of this change.
Fri, Jan 27
- Another test
- Don't initiase the logging action twice.
Thu, Jan 26
ok! please review.
- Some docs
- Don't introduce newlines when pprinting