Microsoft Technology Licensing, LLC

Micron Technology Licensing, LLC

Nachiappan Nagappan

Thomas Michael Josef Zimmermann

Christian Alma Bird

Thirumalesh Bhat

Chetan Bansal

Michael C Fanning

Ashish Gupta

Mark Alistair Wilson-Thomas

Nikitha Rao

Chandra Sekhar Maddila

Kim Sebastian Herzig

Syed Masum Emran

Sumit Gulwani

Ahmed Hassan Awadallah

Benjamin Livshits

Thomas J Ball

Sean Sandys

Gustavo Araujo Soares

Arjun Radhakrishna

Sumit Kumar

Ashish Tiwari

Christopher M H Faucon

Brendan Seamus Murphy

Manish Shetty Molahalli

Zhongyan Guan

Xiang Gao

Shraddha Govind Barke

Matthew Thornhill Hall

Andreas Zeller

Magnus Madsen

Thomas M J Zimmermann

Arild E Skjolsvod

Alan Thomas Leung

Foyzul Hassan

Systems and methods for automatic recognition of entities related to cloud incidents are described. A method, implemented by at least one processor, for processing cloud incidents related information, including entity names and entity values associated with incidents having a potential to adversely impact products or services offered by a cloud service provider is provided. The method may include using at least one processor, processing the cloud incidents related information to convert at least words and symbols corresponding to a cloud incident into machine learning formatted data. The method may further include using a machine learning pipeline, processing at least a subset of the machine learning formatted data to recognize entity names and entity values associated with the cloud incident.

Automatic recognition of entities related to cloud incidents

A heuristics-based concurrent edit detector ('ConE') can notify collaborators about potential conflicts that may be caused by edits made by other collaborators. ConE may compare concurrent edits submitted by collaborators, calculate the extent of overlap between two sets of edits, apply one or more filters to balance recall versus precision, and decide whether to alert the collaborators about candidate potential conflicts. ConE may be light-weight and easily scalable to work in a very large environment with numerous collaborators.

Concurrent edit detection

A computer implemented method includes receiving an exception generated based on programming code, generating exception features from the received exception, the generated exception features being generated based on a set exception features derived from search logs, and executing a machine learning model on the received exception and generated exception features to provide information from the search logs identified as most helpful to resolve the received exception, wherein the machine learning model was trained on training data comprising extracted exceptions and the set of exception features derived from the search logs.

Automated exception featurization and search

A synthesis procedure learns program transformations for a text document, on-the-fly during an edit session, from examples of concrete edits made during the edit session and from an unsupervised set of additional inputs. The additional inputs are derived from explicit feedback from the user and inferred feedback from the user's behavior during the edit session. A reward score, based on anti-unification and provenance analysis, is used to classify the additional inputs as either a positive input or a negative input. Outputs are generated for the positive inputs that are consistent with the existing examples and then used to synthesize a new program transformation. The program transformations are then used to generate code edit suggestions during the edit session.

Feedback-driven semi-supervised synthesis of program transformations

Embodiments promote searcher productivity and efficient search engine usage by using extraquery context to detect a searcher's intent, and using detected intent to match searches to well-suited search providers. Extraquery context may include cursor location, open files, and other editing information, tool state, tool configuration or environment, project metadata, and other information external to actual search query text. Search intent may be code (seeking snippets) or non-code (seeking documentation), and sub-intents may be distinguished for different kinds of documentation or different programming languages. Search provider capabilities may reflect input formats such as natural language or logical operator usage, or content scope such as web-wide or local, or other search provider technical characteristics. Search intent detection permits efficient and effective use of a single search box for a wide variety of different searches for different kinds of results, thereby simplifying a development tool user interface.

Extraquery context-aided search intent detection

Identifying false test alarms to a developer. A code build is executed in a test system that includes computing functionality and computing infrastructure that is able to execute the build. Executing the code build includes running a plurality of system and integration tests on the code build. As a result of executing the code build, a system and integration test failure is identified. One or more characteristics of the system and integration test failure are identified. The characteristics of the system and integration test failure are compared to characteristics of a set of historical previous known false test alarms. False test alarms are failures caused by a factor other than a factor for which a test is being run. Based on the act of comparing, information is provided to a developer with respect to if the system and integration test failure is potentially a false test alarm.

Method of detecting false test alarms using test step failure analysis

Techniques pertaining to analyzing power consumed by a processing unit in a mobile computing device caused by execution of certain modules are described herein. A power trace is generated that indicates an amount of power consumed by the processing unit over time, and the power trace is aligned with an execution log. Spikes are extracted from the power trace, and computing operations are performed over the spikes to acquire data pertaining to power consumed by the processing unit that are attributable to modules in the execution log.

Analyzing power consumption in mobile computing devices

A system is described herein that predicts defects in a portion of code of an application that is configured to execute on a computing device. Versions of code are analyzed to locate change bursts, which are alterations to at least one portion of code over time-related events. If a change burst is identified, defects are predicted with respect to the code based at least in part upon the identified change burst.

Predicting defects in code

Generation of a dependency graph for code that includes code portions such as resources or functions or both. For some or all of the nodes, the dependency is calculated by determining that the given node, a depending node, depends on an affecting node. The dependency is recorded so as to be associated with the node. Furthermore, the dependency calculation method is recorded so as to be associated with the dependency. The code may perhaps include portions within two different domains, in which the mechanism for calculating dependencies may differ. In some cases, the dependency graph may be constructed in stages, and perhaps additional properties may be associated with the node, and metadata of the properties may also be recorded.

Code dependency calculation

The discussion relates to software development automated analytics. One example can access a database related to a software development project. The database can include both software code and non-code metadata. The example can analyze the non-code metadata and the software code to identify parameters. It can relate the parameters to aspects of the software development project. The example can cause a graphical user interface to be presented that conveys an individual aspect.

Software development automated analytics

An exemplary method includes receiving source code having a plurality of code segments, providing a desired level of quality for the source code, analyzing the source code to assign a complexity measure to each of the plurality of code segments and assigning a level of code coverage to each of the plurality of code segments based at least in part on the desired level of quality and the complexity measures. An exemplary system prioritizes quality improvements to source code based, in part, on a quality assessment. Such a system can improve code quality by assigning higher test coverage levels to modules with higher complexity.

Prioritizing quality improvements to source code

The present examples provide technologies for estimating code failure proneness probabilities for a code set and/or the files that make up the set. The code set being evaluated is typically comprised of binary and/or source files that embody the software for which the estimates are desired. The estimates are typically based on a set of selected code metrics, the code metrics typically selected based on corresponding failures of a previous version of the software. A historically variant metric feedback factor may also be calculated and code metric values classified relative to a baseline code set embodying the previous version of the software.

Technologies for code failure proneness estimation

Growing community of inventors

Redmond, WA, United States of America

Nachiappan Nagappan