{"push_id":1015678437,"size":8,"distinct_size":8,"ref":"refs/heads/master","head":"b71ecebc0e10bd29e50706e02eaa7e388267fd2c","before":"996187359499f77bb912ec74b88d39ca33e49174","commits":[{"sha":"a1a07b1fa5d194f15379321ba051f3808096e438","author":{"email":"a739c4f8e636da25cffcf7ae77a3ad0067722ef5@cray.com","name":"Brad Chamberlain"},"message":"Merge branch 'bug_request' of https://github.com/kushalsingh007/chapel into kushalsingh007-bug_request","distinct":true,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/a1a07b1fa5d194f15379321ba051f3808096e438"},{"sha":"fe7a6d988f66bdc68ce82f2a67bf388e22e38a5f","author":{"email":"a739c4f8e636da25cffcf7ae77a3ad0067722ef5@cray.com","name":"Brad Chamberlain"},"message":"Attempt to fix test/distributions/kushal/assignDomain.chpl\n\nThis seems to fix the bug, but may cause other problems.  Need to\ntest.\n\nAlso, changed a for into a forall because it seemed trivially\nparallelizable.","distinct":true,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/fe7a6d988f66bdc68ce82f2a67bf388e22e38a5f"},{"sha":"3096fa78ce255c029f446c6c1002f07126f793de","author":{"email":"76b11d3d92bad7a642f7c1b15d8a810ff35b7019@users.noreply.github.com","name":"Brad Chamberlain"},"message":"Change forall back into for; retire future\n\nThe forall broke in the presence of uint domains, as in\ntest/release/examples/benchmarks/hpcc/ra.chpl.  It deserves\nmore of a look, but is off-task for what I'm working on here\nsince it isn't a trivial fix.  Added a TODO to hold the place.","distinct":true,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/3096fa78ce255c029f446c6c1002f07126f793de"},{"sha":"9cff875d1b043879fbc0550a76cadd861b0e38a5","author":{"email":"76b11d3d92bad7a642f7c1b15d8a810ff35b7019@users.noreply.github.com","name":"Brad Chamberlain"},"message":"Merge branch 'master' of https://github.com/chapel-lang/chapel into fix-inter-dmap-assign","distinct":true,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/9cff875d1b043879fbc0550a76cadd861b0e38a5"},{"sha":"7b86e340c40cf5d19022fff2068890f7855e2c4e","author":{"email":"f955cf5f42dff0db8f444c4740a67a0cf0b4805d@users.noreply.github.com","name":"Lydia Duncan"},"message":"Add/fix annotations for this week\n\nThe array vector annotation for David's improvements needed to be applied more\nbroadly, as it affected more than just the test following it.  The other\nannotation on that test was listed on the date the change went in, not the date\nthe change was observed (we've been trying to be consistent on that).  Also,\nmarked the improvement to memory leaks in examples from today's run to be Ben's\nfixes to miniMD that went in yesterday.","distinct":true,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/7b86e340c40cf5d19022fff2068890f7855e2c4e"},{"sha":"0c99c06ba3f68abcb64b525bf8f6f3b99b97cdb5","author":{"email":"f955cf5f42dff0db8f444c4740a67a0cf0b4805d@users.noreply.github.com","name":"Lydia Duncan"},"message":"Fix the date for the general array as vector change annotation\n\nSince I took the annotation from the timeVectorArray section, the date it gave\nwas wrong (because the test didn't store timings the day after the change went\nin due to a perfkeys mismatch).  Update the global annotation to give the\nright date, and reinstate the annotation for timeVectorArray because annotations\nonly show up on days with data.","distinct":true,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/0c99c06ba3f68abcb64b525bf8f6f3b99b97cdb5"},{"sha":"88e5b21d00124aa236c908c224348b532e232d74","author":{"email":"76b11d3d92bad7a642f7c1b15d8a810ff35b7019@users.noreply.github.com","name":"Brad Chamberlain"},"message":"Merge pull request #3423 from bradcray/fix-inter-dmap-assign\n\nFix for test/distributions/kushal/assignDomain.chpl \r\n\r\n[reviewed by @ronawho]\r\n\r\nIn PR #3420, @kushalsingh007 demonstrated that while domain assignment is meant to be supported between domains of different distributions, and to assign just the domains' index sets, when there were arrays declared over a default domain and it was assigned a distributed domain, we ran into an internal error in dsiReallocate() (responsible for reallocating any arrays declared over the domain).  As we've been defining the language, I think this is a bug.  This PR fixes that bug.\r\n\r\nMy approach was a somewhat naive one, but seemed the fastest way to a working solution this week.  Also, since reallocation is an expensive operation in Chapel, it seems unlikely that doing a bit of extra local computation would add much overhead.  Specifically, I took the case which said \"if we're reallocating to a domain that isn't the same type as this domain (i.e., a default rectangular domain), halt\" and instead created a new default rectangular domain with the same index set, then called dsiReallocate() again, passing it that domain such that next time, the types would match.\r\n\r\nRetired the future.\r\n\r\nThe two other changes I made here were:\r\n\r\n1) I wrapped the entire procedure body in an on-clause to ensure that the new domain would be allocated on the same locale as the original.\r\n\r\n2) I added a TODO in which the 'for' loop which assigns between the old and new array seems like it could and should be a forall loop.  However, in testing, 5 tests failed which make use of domains with uint idxTypes, suggesting an int/uint problem in our standalone parallel iterators (I'm guessing based on the fact that they're newer and that the 'for' loop case works).  As a follow-on, it'd be great to fix this and enable this array copy to be a forall loop, which could result in a nice performance benefit for reallocating arrays of any significant size (including distributed arrays, since they call dsiReallocate() on each node).\r\n\r\nTested on full linux64 testing and gasnet over release/examples, multilocale, and distributions.\r\n\r\nIn making this change, it occurs to me that in another case recently, we've given default rectangular domains special flexibility that we don't give to others.  In discussing the current semantics with David, it occurred to me that it might be reasonable to only permit assignments from default arithmetic domains to distributed domains, but not vice-versa in the name of productivity in the common case and avoiding surprises in the other case.  But I'm not proposing we take this on now -- I'd rather gain more experience that suggests the current semantics are wrong before changing our current path on this question and am filing it away here as a possibility.","distinct":true,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/88e5b21d00124aa236c908c224348b532e232d74"},{"sha":"b71ecebc0e10bd29e50706e02eaa7e388267fd2c","author":{"email":"f955cf5f42dff0db8f444c4740a67a0cf0b4805d@users.noreply.github.com","name":"Lydia Duncan"},"message":"Merge pull request #3439 from lydia-duncan/annotate\n\nAdd/fix annotations for this week\r\n\r\nThe array vector annotation for David's improvements needed to be applied more\r\nbroadly, as it affected more than just the test following it. The other\r\nannotation on that test was listed on the date the change went in, not the date\r\nthe change was observed (we've been trying to be consistent on that). Also,\r\nmarked the improvement to memory leaks in examples from today's run to be Ben's\r\nfixes to miniMD that went in yesterday.","distinct":true,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/b71ecebc0e10bd29e50706e02eaa7e388267fd2c"}]}