GitHub PushEvent at 2014-08-19 22:41:36
Repository: chapel
Actor: noakesmichael
Payload: {"shas":[["d67062cd2df2dbb75e34e0bf15a5aa42b1f78bde","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Merge remote-tracking branch 'chapel-lang/master' into remove-nightly-stats","Thomas Van Doren",true],["65a63d17c55fe56626c519ea5d06f4a3d6f6cfac","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Remove stats tracking from nightly.\n\nBesides the fact that the stats kept in these files are no longer used,\nmaintaining them required RCS. This commit removes all stats tracking from\nnightly and thus removes RCS as a dependency. Yay!","Thomas Van Doren",true],["a0f2545d650657976f8bccbfee8c9412c31cdef0","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Remove all references to CHPL_NIGHTLY_STATDIR in bash helper scripts.","Thomas Van Doren",true],["3ef8defb784c43b4719150d883790fd21f6c4a83","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Add future for parsing boolean config args that include a space delimited value.\n\nThis does not parse correctly:\n\n  ./configVarBooleanSpaceAfter --x true\n\nThese forms do work for booleans:\n\n  ./configVarBooleanSpaceAfter --x=true\n  ./configVarBooleanSpaceAfter --x\n\nThe space delimited form does work for other types that do not support the\nimplicit value (--<var name> is a special case for booleans).","Thomas Van Doren",true],["27b997cb7a84a2af3d9bdc97ffabbe00a08d99cf","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Add fixme and default to none when srun and aprun are missing.\n\nThis can happen on an eslogin node.","Thomas Van Doren",true],["79b0773373052873ad826d5d37e862e54874e4da","f955cf5f42dff0db8f444c4740a67a0cf0b4805d@users.noreply.github.com","Remove deprecated functionality.\n\nIn looking through IO.chpl for file functionality, I noticed some methods\nwhich inform the user that they are no longer supported.  Since this message\nwas added in 2011, it seems reasonable to remove it.","Lydia Duncan",true],["0ee2a253b530ce4145fd456a44d9e4043f62c786","f955cf5f42dff0db8f444c4740a67a0cf0b4805d@users.noreply.github.com","Remove a method that has been commented out since 2011","Lydia Duncan",true],["dd31ebe95b24d2e8d675423a17a1740c2b1fdb1f","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Update chplenv launcher logic to print warning and always default to \"none\" instead of None.\n\nBased on review comments from @Kyle-B","Thomas Van Doren",true],["f1e30891b92e10644ad5b4e0bd2466f8e3db6441","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Merge branch 'master' of github.com:chapel-lang/chapel into launcher-default-fix","Thomas Van Doren",true],["5b8ce7198f56ba03e21a90c0761b913012188514","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Merge pull request #138 from thomasvandoren/launcher-default-fix\n\nAdd fixme and default to none when srun and aprun are missing.","Thomas Van Doren",true],["3eb462a22aca7148ca4453b5561c80e3ffe1f613","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Merge branch 'master' of github.com:chapel-lang/chapel into future-for-bool-config-arg-parsing","Thomas Van Doren",true],["2778e47a071287367d9db55afd136a68e7d49975","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Merge pull request #131 from thomasvandoren/future-for-bool-config-arg-parsing\n\nAdd future for parsing boolean config args that include a space delimited value.\r\n\r\nThis does not parse correctly:\r\n\r\n```bash\r\n./configVarBooleanSpaceAfter --x true\r\n```\r\n\r\nThese forms do work for booleans:\r\n\r\n```bash\r\n./configVarBooleanSpaceAfter --x=true\r\n./configVarBooleanSpaceAfter --x\r\n```\r\n\r\nThe space delimited form does work for other types that do not support the implicit value (`--<var name>` is a special case for booleans).","Thomas Van Doren",true],["1e46ca5f8e56db68a03716525d1213712ef73678","a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","Add V 1.0 of \"C for loops\"\n\n[Done in collaboration and co-reviewed with @daviditen]\n\n========================\nMotivation and Overview:\n========================\n\nPreviously most of our generated loops were of the form:\n\ni = start;\ncond = (i != end);\nwhile (cond) {\n  // loop body\n  i = i + 1;\n  cond = (i != end);\n}\n\nwhere the actual generated code was much uglier. This loop originates from the\nthese() iterator in ChapelRange.chpl.\n\nThe point of this commit is to generate loops of the form:\n\nfor (i = start; i <= end; i = i + 1) {\n  // loop body\n}\n\nThere are a couple of motivating reasons for this change. The != relational\noperator in the while loop and the way the increment was actually generated\n(example is a cleaned up version) meant the back-end compiler couldn't\nnormalize the loop and thus couldn't perform some optimizations.\n\nWe might have been able to clean up the while loop, instead of generating a c\nfor loop, but well formed c for loops are also required for things like using\nOpenACC or OpenMP so it made sense to generate clean c style for loops.\n\nThis commit brings us the first version of c for loops (with details about what\nwill be in V 2.0 below.)\n\nThis basic idea is that in ChapelRange.chpl we replace the while loops with a\nnew primitive \"C for loop\" and then since most things forward to ranges at the\nlowest level we get c for loops in many places.\n\nSome changes are to support building the iterator for the c for loop and\nbuilding zippered iterators correctly. Dead code elimination had to be\nmodified to not kill the test expr of the c for loop and loop invariant code\nmotion had to be updated to correctly find the pre-header of a c for loop.\nOther than that the only real change was adding new codegen functionality for c\nfor loops and the remaining changes are for things like adding the primitive\nitself, and in code that checked for the other loop primitives, the c for loop\nis also checked.\n\nThis version creates c for loops for non-strided, bounded ranges only. That\nhappens to be a majority of loops so you still get c for loops in many many\nplaces. V 2.0 will include c for loops for unbounded, and strided iterators.\nAdditionally iterators over a DefaultRectangular array still use a while loop\nbecause an \"optimized\" while loop was added a while back in\nDefaultRectangular's iterator instead of just forwarding to the range. The only\nreal reason these other iterators don't use c for loops in this commit is to\nmake tracking down any potential issues easier.\n\nWith this we generate exceptionally clean non-zippered c for loops, and as\nclean as we can get zippered iterators without doing de-normalization (though\nthey are still very clean.)\n\nThe current implementation has two regressions because it \"breaks\" maximal ranges\nand positively strided ranges where the high bound is max(idxType) and\nnegatively strided ranges where the low bound is min(idxType).\n\n=================\nPer file changes:\n=================\n\ncompiler/AST/bb.cpp\n - For c for loops we have to add the init, test, and incr to the basic blocks.\n   This is actually pretty simple, and is just based on the semantics of what a\n   c for loop is. The init gets executed before the loop, the test gets\n   executed before each iteration, and the incr is the last thing that happens\n   after the loop body and immediately before the test is done again.\n\ncompiler/AST/build.cpp\n - Pretty simple changes. This adds building c for loops. For a c for loop we\n   have similar code as for other loops to build up the basic parts of the loop\n   and add continue and break labels and such. The main other thing is that\n   right now c for loops are of the form:\n     __primitive(\"C for loop\", i, start, end, stride)\n   In here we take that and actually build up the init, test, and incr exprs\n   and effectively create:\n     __primitive(\"C for loop\", {i=start}, {i<=end}, {i=i+1})\n   Note that in this version the relational operator is forced to be <=. This\n   will be updated for V 2.0.\n\ncompiler/AST/iterator.cpp\n - Allow C For loops to trigger the isSingleLoopIterator optimization\n\n - Do not insert the setting of iterator->more for C For loops in zip1 and zip3\n\n - Adds two new functions to the iterator init, and incr which only get\n   populated for C for loops and changes hasMore to behave differently for C for\n   loops. For c for loops these functions basically just insert the init, test,\n   and incr exprs from the c for loop primitive into the iterator functions.\n\ncompiler/include/iterator.h\n -  Just adds the init and incr prototypes\n\ncompiler/AST/primitive.cpp\ncompiler/include/primitive.h\n - Just adds the C_FOR_LOOP primitive\n\ncompiler/AST/stmt.cpp\n - These are all just changes to codegen the c for loop. The basic jist is that\n   for take each block statement in the c for loop (init, test,incr) and\n   codegen them separately and then just insert them into the c for loop\n   string.\n - Since c for loops can only contain comma separated statements and not\n   regular statements, the real bulk of codegen here is to convert things that\n   would normally be code-genned as statements and turn them into comma\n   separated statements.\n\ncompiler/optimizations/collapseBlocks.cpp\n - We need to collapse the block statements in the c for loop headers since\n   each block statement can be composed of multiple block statements sitting\n   next to each other for zippered iterators. This puts the logic for\n   collapsing CForLoop blocks into a separate function, and also pulls the\n   logic to collapse a single block into it's own function to make it easier to\n   read.\n\ncompiler/optimizations/deadCodeElimination.cpp\n - Do not let expressions in the c for loop header be marked as dead, side\n   effect free expressions in deadExpressionElimination. The test in the c for\n   loop header is not side effect free, but we didn't have to identify anything\n   like this before. The current approach does not eliminate any expressions in\n   the header, but I should update it to only not eliminate expressions in the\n   test segment that are conditional expressions.\n\n - Similarly we mark expressions in the header as essential so regular\n   deadCodeElmination doesn't get rid of them.\n\ncompiler/optimizations/loopInvariantCodeMotion.cpp\n - Updates the helper function in LICM for inserting an expression before the\n   loop. The condition/test of the c for loop is identified as the header of\n   the loop because of how we build the basic blocks. This is technically\n   correct, but when we go to insert we look for the parent of the headers\n   first expr and try to insert before that. However for c for loops the test\n   is still in the c for loop primitive so we need to go up a few more levels\n   to get the actual loop body to insert in to.\n\ncompiler/optimizations/optimizeOnClauses.cpp\n - Just adds c for loops to the list of fast primitives\n\ncompiler/passes/createTaskFunctions.cpp\n - Just adds c for loops to the list of non parallel block constructs\n\ncompiler/resolution/functionResolution.cpp\n - Just adds prototypes and resolved flags to init and incr functions\n\ncompiler/resolution/lowerIterators.cpp\n - Changes zippered iterator creation to work with c for loops. All for loops\n   are converted to c for loops here. We then put the zip* functions in the\n   appropriate place and insert bounds checks if they were turned on. Special\n   care had to be taken for dynamically dispatched iterators because they\n   create code that cannot be in the c for loop header.\n\n - The order of this code is pretty delicate. More comments and cleanup will be\n   done to this code in V 2.0.\n\nmodules/internal/ChapelRange.chpl\n - Splits the these iterator into three iterators: One for strided and bounded\n   ranges, one for unbounded ranges, and one for non-strided and bounded\n   ranges. Then the non-strided and bounded range was converted to use a \"C for\n   loop\"\n\n - Removes the check for maximal ranges. What we really want here now is to\n   detect when a range will under or over flow. This currently can't be done at\n   range construction because in the case of strided ranges, the base range is\n   built, and then the by operator is applied to the range so you can get false\n   positives. An approach might be to do the checks at iterator time, but that\n   means you have to put the same checks in multiple places.\n    - Previously ranges such as max(int)-10..max(int) worked because we relied\n      on well defined integer overflow semantics (but integer overflow is\n      undefined in C) and we relied on the != relational operator in the\n      iterator. If you try to generate a c for loop of max(int)-10..max(int)\n      you'll end up with something like \"for (i=max(int)-10; i<max(int); i++)\"\n      and that is an infinite loop. This is currently not addressed but V 2.0\n      will add checks to warn the user of such cases and provide a different\n      (and unfortunately less performant) iterator to use in such cases. This\n      iterator should also be able to support maximal ranges.\n\n - A function withinBounds was added to replace the maximal range checks, but\n   it is currently unused. It will be used in V 2.0\n\ntest/types/range/diten/cForLoops/simpleRange.chpl\ntest/types/range/diten/cForLoops/simpleRange.good\ntest/types/range/diten/cForLoops/userCForLoops.chpl\ntest/types/range/diten/cForLoops/userCForLoops.good\ntest/types/range/diten/cForLoops/userDefIter.chpl\ntest/types/range/diten/cForLoops/userDefIter.good\ntest/types/range/diten/cForLoops/zipArray.chpl\ntest/types/range/diten/cForLoops/zipArray.good\ntest/types/range/diten/cForLoops/zipRange.chpl\ntest/types/range/diten/cForLoops/zipRange.good\n - Some simple tests to ensure c for loops are working correctly. More will be\n   added in V 2.0\n\ntest/types/range/hilde/maximalRange.chpl\n - This is a simple change to prevent an infinite loop if we break maximal\n   ranges (which I did.)\n\n=================\nV 2.0 and beyond:\n=================\n\n - Warnings for ranges with min or max bounds\n   - Make this so it can be in the range constructor?\n   - And an appropriate iterator to use for these cases\n     - As in add an iterator that a user can use for 0:uint..max(uint) or\n       max(int)-10..max(int)\n\n - User defined relational operator for c for loops\n   - This should clean up build.cpp\n   - C for loops for strided ranges and for unbounded ranges\n      - And a clever way to use <, <=, >, >= instead of !=\n\n - C for loops for Default Rectangular\n\n - See about removing the isAmbiguous call in ChapelRange iterators?\n\n - Further clean up codegen (stmt.cpp)\n   - Add checks for things that can't be in c for loops\n   - Explain why codegenValue is used.\n\n - Review lower iterators\n   - Add note about why we only have one conditional, even with bounds\n     checking (or see if that can be addressed)\n   - Review dynamically dispatched iterator code\n\nIdeal for V 3.0:\n - Switch to using op= and PRIM_ASSIGN once ref temps are gone\n - Potential iterator/range optimizations:\n   - Induction variable elimination\n   - Hoist range construction (and merge duplicate ranges)\n   - Maybe some way to indicate that the stride is positive or negative","Elliot Ronaghan",true],["73e6f899c2a12e0cabd88046aac1789da976e12f","a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","Merge pull request #165 from ronawho/CForLoops-V1\n\nAdd V 1.0 of \"C for loops\"\r\n\r\n[Done in collaboration and co-reviewed with @daviditen]\r\n\r\n========================\r\nMotivation and Overview:\r\n========================\r\n\r\nPreviously most of our generated loops were of the form:\r\n\r\ni = start;\r\ncond = (i != end);\r\nwhile (cond) {\r\n  // loop body\r\n  i = i + 1;\r\n  cond = (i != end);\r\n}\r\n\r\nwhere the actual generated code was much uglier. This loop originates from the\r\nthese() iterator in ChapelRange.chpl.\r\n\r\nThe point of this commit is to generate loops of the form:\r\n\r\nfor (i = start; i <= end; i = i + 1) {\r\n  // loop body\r\n}\r\n\r\nThere are a couple of motivating reasons for this change. The != relational\r\noperator in the while loop and the way the increment was actually generated\r\n(example is a cleaned up version) meant the back-end compiler couldn't\r\nnormalize the loop and thus couldn't perform some optimizations.\r\n\r\nWe might have been able to clean up the while loop, instead of generating a c\r\nfor loop, but well formed c for loops are also required for things like using\r\nOpenACC or OpenMP so it made sense to generate clean c style for loops.\r\n\r\nThis commit brings us the first version of c for loops (with details about what\r\nwill be in V 2.0 below.)\r\n\r\nThis basic idea is that in ChapelRange.chpl we replace the while loops with a\r\nnew primitive \"C for loop\" and then since most things forward to ranges at the\r\nlowest level we get c for loops in many places.\r\n\r\nSome changes are to support building the iterator for the c for loop and\r\nbuilding zippered iterators correctly. Dead code elimination had to be\r\nmodified to not kill the test expr of the c for loop and loop invariant code\r\nmotion had to be updated to correctly find the pre-header of a c for loop.\r\nOther than that the only real change was adding new codegen functionality for c\r\nfor loops and the remaining changes are for things like adding the primitive\r\nitself, and in code that checked for the other loop primitives, the c for loop\r\nis also checked.\r\n\r\nThis version creates c for loops for non-strided, bounded ranges only. That\r\nhappens to be a majority of loops so you still get c for loops in many many\r\nplaces. V 2.0 will include c for loops for unbounded, and strided iterators.\r\nAdditionally iterators over a DefaultRectangular array still use a while loop\r\nbecause an \"optimized\" while loop was added a while back in\r\nDefaultRectangular's iterator instead of just forwarding to the range. The only\r\nreal reason these other iterators don't use c for loops in this commit is to\r\nmake tracking down any potential issues easier.\r\n\r\nWith this we generate exceptionally clean non-zippered c for loops, and as\r\nclean as we can get zippered iterators without doing de-normalization (though\r\nthey are still very clean.)\r\n\r\nThe current implementation has two regressions because it \"breaks\" maximal ranges\r\nand positively strided ranges where the high bound is max(idxType) and\r\nnegatively strided ranges where the low bound is min(idxType).\r\n\r\n\r\n=================\r\nPer file changes:\r\n=================\r\n\r\ncompiler/AST/bb.cpp\r\n - For c for loops we have to add the init, test, and incr to the basic blocks.\r\n   This is actually pretty simple, and is just based on the semantics of what a\r\n   c for loop is. The init gets executed before the loop, the test gets\r\n   executed before each iteration, and the incr is the last thing that happens\r\n   after the loop body and immediately before the test is done again.\r\n\r\ncompiler/AST/build.cpp\r\n - Pretty simple changes. This adds building c for loops. For a c for loop we\r\n   have similar code as for other loops to build up the basic parts of the loop\r\n   and add continue and break labels and such. The main other thing is that\r\n   right now c for loops are of the form:\r\n     __primitive(\"C for loop\", i, start, end, stride)\r\n   In here we take that and actually build up the init, test, and incr exprs\r\n   and effectively create:\r\n     __primitive(\"C for loop\", {i=start}, {i<=end}, {i=i+1})\r\n   Note that in this version the relational operator is forced to be <=. This\r\n   will be updated for V 2.0.\r\n\r\ncompiler/AST/iterator.cpp\r\n - Allow C For loops to trigger the isSingleLoopIterator optimization\r\n\r\n - Do not insert the setting of iterator->more for C For loops in zip1 and zip3\r\n\r\n - Adds two new functions to the iterator init, and incr which only get\r\n   populated for C for loops and changes hasMore to behave differently for C for\r\n   loops. For c for loops these functions basically just insert the init, test,\r\n   and incr exprs from the c for loop primitive into the iterator functions.\r\n\r\ncompiler/include/iterator.h\r\n -  Just adds the init and incr prototypes\r\n\r\ncompiler/AST/primitive.cpp\r\ncompiler/include/primitive.h\r\n - Just adds the C_FOR_LOOP primitive\r\n\r\ncompiler/AST/stmt.cpp\r\n - These are all just changes to codegen the c for loop. The basic jist is that\r\n   for take each block statement in the c for loop (init, test,incr) and\r\n   codegen them separately and then just insert them into the c for loop\r\n   string.\r\n - Since c for loops can only contain comma separated statements and not\r\n   regular statements, the real bulk of codegen here is to convert things that\r\n   would normally be code-genned as statements and turn them into comma\r\n   separated statements.\r\n\r\ncompiler/optimizations/collapseBlocks.cpp\r\n - We need to collapse the block statements in the c for loop headers since\r\n   each block statement can be composed of multiple block statements sitting\r\n   next to each other for zippered iterators. This puts the logic for\r\n   collapsing CForLoop blocks into a separate function, and also pulls the\r\n   logic to collapse a single block into it's own function to make it easier to\r\n   read.\r\n\r\ncompiler/optimizations/deadCodeElimination.cpp\r\n - Do not let expressions in the c for loop header be marked as dead, side\r\n   effect free expressions in deadExpressionElimination. The test in the c for\r\n   loop header is not side effect free, but we didn't have to identify anything\r\n   like this before. The current approach does not eliminate any expressions in\r\n   the header, but I should update it to only not eliminate expressions in the\r\n   test segment that are conditional expressions.\r\n\r\n - Similarly we mark expressions in the header as essential so regular\r\n   deadCodeElmination doesn't get rid of them.\r\n\r\ncompiler/optimizations/loopInvariantCodeMotion.cpp\r\n - Updates the helper function in LICM for inserting an expression before the\r\n   loop. The condition/test of the c for loop is identified as the header of\r\n   the loop because of how we build the basic blocks. This is technically\r\n   correct, but when we go to insert we look for the parent of the headers\r\n   first expr and try to insert before that. However for c for loops the test\r\n   is still in the c for loop primitive so we need to go up a few more levels\r\n   to get the actual loop body to insert in to.\r\n\r\ncompiler/optimizations/optimizeOnClauses.cpp\r\n - Just adds c for loops to the list of fast primitives\r\n\r\ncompiler/passes/createTaskFunctions.cpp\r\n - Just adds c for loops to the list of non parallel block constructs\r\n\r\ncompiler/resolution/functionResolution.cpp\r\n - Just adds prototypes and resolved flags to init and incr functions\r\n\r\ncompiler/resolution/lowerIterators.cpp\r\n - Changes zippered iterator creation to work with c for loops. All for loops\r\n   are converted to c for loops here. We then put the zip* functions in the\r\n   appropriate place and insert bounds checks if they were turned on. Special\r\n   care had to be taken for dynamically dispatched iterators because they\r\n   create code that cannot be in the c for loop header.\r\n\r\n - The order of this code is pretty delicate. More comments and cleanup will be\r\n   done to this code in V 2.0.\r\n\r\nmodules/internal/ChapelRange.chpl\r\n - Splits the these iterator into three iterators: One for strided and bounded\r\n   ranges, one for unbounded ranges, and one for non-strided and bounded\r\n   ranges. Then the non-strided and bounded range was converted to use a \"C for\r\n   loop\"\r\n\r\n - Removes the check for maximal ranges. What we really want here now is to\r\n   detect when a range will under or over flow. This currently can't be done at\r\n   range construction because in the case of strided ranges, the base range is\r\n   built, and then the by operator is applied to the range so you can get false\r\n   positives. An approach might be to do the checks at iterator time, but that\r\n   means you have to put the same checks in multiple places.\r\n    - Previously ranges such as max(int)-10..max(int) worked because we relied\r\n      on well defined integer overflow semantics (but integer overflow is\r\n      undefined in C) and we relied on the != relational operator in the\r\n      iterator. If you try to generate a c for loop of max(int)-10..max(int)\r\n      you'll end up with something like \"for (i=max(int)-10; i<max(int); i++)\"\r\n      and that is an infinite loop. This is currently not addressed but V 2.0\r\n      will add checks to warn the user of such cases and provide a different\r\n      (and unfortunately less performant) iterator to use in such cases. This\r\n      iterator should also be able to support maximal ranges.\r\n\r\n - A function withinBounds was added to replace the maximal range checks, but\r\n   it is currently unused. It will be used in V 2.0\r\n\r\ntest/types/range/diten/cForLoops/simpleRange.chpl\r\ntest/types/range/diten/cForLoops/simpleRange.good\r\ntest/types/range/diten/cForLoops/userCForLoops.chpl\r\ntest/types/range/diten/cForLoops/userCForLoops.good\r\ntest/types/range/diten/cForLoops/userDefIter.chpl\r\ntest/types/range/diten/cForLoops/userDefIter.good\r\ntest/types/range/diten/cForLoops/zipArray.chpl\r\ntest/types/range/diten/cForLoops/zipArray.good\r\ntest/types/range/diten/cForLoops/zipRange.chpl\r\ntest/types/range/diten/cForLoops/zipRange.good\r\n - Some simple tests to ensure c for loops are working correctly. More will be\r\n   added in V 2.0\r\n\r\ntest/types/range/hilde/maximalRange.chpl\r\n - This is a simple change to prevent an infinite loop if we break maximal\r\n   ranges (which I did.)\r\n\r\n\r\n=================\r\nV 2.0 and beyond:\r\n=================\r\n\r\n - Warnings for ranges with min or max bounds\r\n   - Make this so it can be in the range constructor?\r\n   - And an appropriate iterator to use for these cases\r\n     - As in add an iterator that a user can use for 0:uint..max(uint) or\r\n       max(int)-10..max(int)\r\n\r\n - User defined relational operator for c for loops\r\n   - This should clean up build.cpp\r\n   - C for loops for strided ranges and for unbounded ranges\r\n      - And a clever way to use <, <=, >, >= instead of !=\r\n\r\n - C for loops for Default Rectangular\r\n\r\n - See about removing the isAmbiguous call in ChapelRange iterators?\r\n\r\n - Further clean up codegen (stmt.cpp)\r\n   - Add checks for things that can't be in c for loops\r\n   - Explain why codegenValue is used.\r\n\r\n - Review lower iterators\r\n   - Add note about why we only have one conditional, even with bounds\r\n     checking (or see if that can be addressed)\r\n   - Review dynamically dispatched iterator code\r\n\r\nIdeal for V 3.0:\r\n - Switch to using op= and PRIM_ASSIGN once ref temps are gone\r\n - Potential iterator/range optimizations:\r\n   - Induction variable elimination\r\n   - Hoist range construction (and merge duplicate ranges)\r\n   - Maybe some way to indicate that the stride is positive or negative","Elliot Ronaghan",true],["5f43b2d6d701ec556e2c82c211e6b93be66d2bf8","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Merge pull request #104 from thomasvandoren/remove-nightly-stats\n\nRemove stats tracking from nightly.\r\n\r\nBesides the fact that the stats kept in these files are no longer used, maintaining them required RCS. This removes all stats tracking from nightly and thus removes RCS as a dependency. Yay!\r\n\r\n@bradcray said this when asked whether or not to keep this stats tracking:\r\n\r\nI think we used to track #s of successes and failures in a simple\r\n.dat-style file using RCS? (though this was a million years ago, and I\r\ndon't think anyone's used it in ages).  I don't think we should anymore,\r\nin any case.  If/when we need it again, we can do something more modern.\r\n\r\nreviewed by @vasslitvinov","Thomas Van Doren",true],["d2733a22db4f649fd4cd0ece4965ad6888d03ee1","f955cf5f42dff0db8f444c4740a67a0cf0b4805d@users.noreply.github.com","With the exception of the mandelbrot test, all test files changed for this\ncommit had commented out usage of FileAccessMode, which was needed in the\ndeprecated method to open a file.  The mandelbrot test had created an entirely\nseparate module to store the old version, but since we have deprecated the\nfeature, this seemed no longer necessary to maintain.","Lydia Duncan",true],["899245373bc0682c1f5b20a86c500eca92d2835e","f955cf5f42dff0db8f444c4740a67a0cf0b4805d@users.noreply.github.com","Merge pull request #164 from lydia-duncan/removeDeprecatedFileOps\n\nRemove deprecated file ops and references to them [reviewed by mppf]\r\n\r\nIn looking through IO.chpl for file functionality, I noticed some functions\r\nwhich inform the user that they are no longer supported or which were\r\ncommented out and trivial. Since the code had been in this state since\r\nit was added in 2011, it seems reasonable to remove the functions in question.\r\nWith the exception of the mandelbrot test, all test files changed for this\r\ncommit had commented out usage of FileAccessMode, which was needed in the\r\ndeprecated method to open a file.  The mandelbrot test had created an entirely\r\nseparate module to store the old version, but since we have deprecated the\r\nfeature, this seemed no longer necessary to maintain.","Lydia Duncan",true]],"size":17,"ref":"refs/heads/master","head":"899245373bc0682c1f5b20a86c500eca92d2835e"}