{"push_id":833234856,"size":6,"distinct_size":6,"ref":"refs/heads/develop","head":"47d1262bacdede926da9dba7253c612f39763c9a","before":"029017c34f77df13a51abcbc95f2536891dde860","commits":[{"sha":"428b20400f3c38b9a421a471ebc05e78761378be","author":{"email":"49f286f948417fff7b3fb5e9475c023778fb9383@gmail.com","name":"rakhimov"},"message":"Rearrange ancestor traversal in Decomposition proc\n\nClones are left unprocessed\ndue to the complexity of shared arguments.\nThere seems to be a flow\nin methodology of using clones without update graph visit times.","distinct":true,"url":"https://api.github.com/repos/rakhimov/scram/commits/428b20400f3c38b9a421a471ebc05e78761378be"},{"sha":"de740b7710d4230bdb2e5032b475e2edc1c3c0c8","author":{"email":"49f286f948417fff7b3fb5e9475c023778fb9383@gmail.com","name":"rakhimov"},"message":"Fix a design flaw in Decomposition preprocessing\n\nThe fundamental flaw in Decomposition preprocessing step\nis an assumption that\nif a source node is within graph's visit bounds,\nthe failure propagation will not affect anything outside of the graph,\nso changing the node is safe.\nHowever, not all the nodes in the path to the source node\nare tested for being in the same graph,\nso if any of ancestor nodes of the source node\nis shared with another graph,\nthe result of preprocessing is not semantics preserving.\n\nThe solution to this problem\nis to conservatively clone the source without any assumptions.\nThis is 10-20x performance hit for the Decomposition preprocessor,\nbut correctness is more important.","distinct":true,"url":"https://api.github.com/repos/rakhimov/scram/commits/de740b7710d4230bdb2e5032b475e2edc1c3c0c8"},{"sha":"bbd0e4773b00f888091aa12f7781563b04f67938","author":{"email":"49f286f948417fff7b3fb5e9475c023778fb9383@gmail.com","name":"rakhimov"},"message":"Make Fuzz tester check for existence of SCRAM\n\nThe tester should not run\nif SCRAM is not found.","distinct":true,"url":"https://api.github.com/repos/rakhimov/scram/commits/bbd0e4773b00f888091aa12f7781563b04f67938"},{"sha":"c01599910c8e46af933b2e0722c1f1359b4fc91e","author":{"email":"49f286f948417fff7b3fb5e9475c023778fb9383@gmail.com","name":"rakhimov"},"message":"Generalize the interface of Boolean optimization\n\nThe Boolean optimization can be generalized\nfor propagation of success.\nThe documentation is updated together with the interface\nto give the theoretical reasoning for the generalization.\n\nThe interface is generalized by noting\nthat a particular State is propagated,\nnot necessarily Failure.\n\nPropagation of success is not, however, applied in implementation.\nMoreover, it is not yet clear\nif the propagation of success should be applied at all.","distinct":true,"url":"https://api.github.com/repos/rakhimov/scram/commits/c01599910c8e46af933b2e0722c1f1359b4fc91e"},{"sha":"e1254dcceab1c979e555c2847a4d9c4dc8b767b5","author":{"email":"49f286f948417fff7b3fb5e9475c023778fb9383@gmail.com","name":"rakhimov"},"message":"Adjust Boolean optimization for non-coherent cases\n\nThis is an experimental feature\nto assess the effect of Boolean optimization failure propagation\non non-coherent models.\n\nThe current implementation worsens the performance of coherent cases\nbecause of the need to generalize the technique.\n\nThere's no observed improvement for non-coherent models as well.\nIt is currently hard to test without having fast analysis.","distinct":true,"url":"https://api.github.com/repos/rakhimov/scram/commits/e1254dcceab1c979e555c2847a4d9c4dc8b767b5"},{"sha":"47d1262bacdede926da9dba7253c612f39763c9a","author":{"email":"49f286f948417fff7b3fb5e9475c023778fb9383@gmail.com","name":"rakhimov"},"message":"Fix C++14 lambda capture initialize back to C++11\n\nGCC 4.8.4 seems not to care.","distinct":true,"url":"https://api.github.com/repos/rakhimov/scram/commits/47d1262bacdede926da9dba7253c612f39763c9a"}]}