Microsoft Technology Licensing, LLC

Jonathan Paul De Halleux

Nikolai Tillmann

Michal J Moskal

Stephen Edward Hodges

Wolfram Schulte

Thomas J Ball

James Alexander Devine

Gabriele D'amone

Margus Veanes

Sumit Gulwani

Nikolaj Skallerud Bjorner

Jun Kato

Vu Minh Le

Manuel Alfred Fahndrich

Barend Hermanus Venter

Sebastian Burckhardt

Sean C McDirmid

Pavel Grigorenko

Zhendong Su

Manuel A Faehndrich

Xusheng Xiao

Dries Vanoverberghe

The description relates to prototyping systems, including hubs for electrically connecting devices. One example can include an electrically insulative substrate and at least two connector tabs defined by the substrate, each connector tab including a data contact, a power contact, and a ground contact positioned over the substrate. A data bus can be positioned relative to the substrate and electrically connect all of the data contacts, a power bus can be positioned relative to the substrate and electrically connect all of the power contacts, and a ground bus can be positioned relative to the substrate and electrically connect all of the ground contacts.

Electronic prototyping

The description relates to prototyping systems, including hubs for electrically connecting devices. One example can include an electrically insulative substrate and at least two connector tabs defined by the substrate. Each connector tab can include a data contact a power contact and a ground contact positioned on the substrate. A data bus can be positioned relative to the substrate and electrically connect all of the data contacts, a power bus can be positioned relative to the substrate and electrically connect all of the power contacts and a ground bus can be positioned relative to the substrate and electrically connect all of the ground contacts in accordance with a first prototyping format. The example can also include adapter contacts positioned on the substrate and configured to electrically connect to a data contact, a power contact, and a ground contact of another device that complies with a second different prototyping format.

Electronic prototyping interoperability

The description relates to electronic prototyping platforms. One example can include an electrically insulative substrate having generally opposing first and second major surfaces and that includes an orientation feature that is visible on both of the first and second major surfaces. The example can include a first mounting hole through the substrate that is bordered by a first electrical conductor associated with data transmission. The example can also include a second mounting hole through the substrate that is bordered by a second electrical conductor associated with electrical ground, and a third mounting hole through the substrate that is bordered by a third electrical conductor associated with electrical power. The example can also include an edge connector tab defined by the substrate and having three exposed electrically conductive contacts that are coupled to the data electrical conductor, the ground electrical conductor, and the power electrical conductor and insulated from one another.

Modular electronic prototyping platforms

A program development framework (PDF) is described herein which allows a user to produce a program in piecemeal fashion by successively specifying program fragments. The PDF creates a new program fragment by receiving keyword information from the user that describes a new program fragment, and then identifies context information that pertains to a programmatic context in which the new program fragment appears within the overall program being created. The PDF then generates a set of candidate program fragments that satisfy the keyword information and the context information, and ranks those candidate program fragments based on ranking information. At least part of the ranking information may be based on statistical information that is produced by analyzing a corpus of previous programs produced by one or more users. The PDF then provides the ranked program fragments to the user using various user-friendly presentation strategies.

Generating program fragments using keywords and context information

Some implementations provide techniques and arrangements for interactive user interface operation and development. For instance, some implementations may generate a user interface data structure representing a user interface, the user interface data structure being generated based at least in part on state data and imperative programming code. Then, in response to a change in one of the imperative programming code or the state data, some implementations may update the user interface data structure and render an updated interactive graphical user interface based on the updated user interface data structure.

Interface development and operation

This document describes techniques for contextually intelligent code editing. In at least some embodiments, the techniques are network-based and can use client-server interactions to develop programming code. For example, input to a local programming environment of a client can be transmitted to a server. A functionality at the server can inspect the input and determine programming options (e.g., programming terms and/or phrases) that are contextually valid in the local programming environment. A list of the programming options can then be transmitted to the client and presented via a user interface. In some embodiments, a selection of one of the programming options can cause the programming option to be populated to the local programming environment, e.g., as part of a user interface associated with the local programming environment. In at least some embodiments, the list of programming options can be cached locally on the client for quick retrieval.

Contextually intelligent code editing

A privacy control system is described herein for controlling dissemination of private information by a program. The privacy control system operates by performing static analysis to determine at least one flow within the program of private information, from a source to a sink. The static analysis is particularly configured to identify two types of flow, including: (a) an unvetted flow of untampered private information from the source to the sink; and (b) a flow of tampered private information from the source to the sink, whether vetted or unvetted. The privacy control system then prompts the user to provide a privacy control decision regarding the flow. The privacy control decision governs whether actual data or anonymized data is provided to the sink, or whether the program is terminated. A runtime system then runs the program in accordance with the privacy control decision.

Controlling the release of private information using static flow analysis

An isolation system is described for converting original product code into corresponding modified code. The isolation system operates by identifying a subset of original methods to be converted. For each such original method, the isolation system generates a modified part having at least one property with a type-safe delegate type which matches a signature of the original method. Test code, which tests the product code, can then associate a delegate instance to the thus-defined property of the original method. This prompts an execution system to dynamically execute detour code associated with the delegate instance, rather than an instrumentation of the original method, thus avoiding dependency on potentially non-deterministic functionality which would be otherwise invoked by an instrumentation of the original method.

Generating type-safe wrappers for dynamic detouring

Described are symbolic finite automata for symbolically expressing and analyzing regular expression constraints, such as for use in program analysis and testing. A regular expression or pattern is transformed into a symbolic finite automaton having transitions that are labeled by formulas that denote sets of characters (rather than individual characters). Also described is composing two or more symbolic finite automata into a resulting symbolic finite automaton that is fully satisfiable. A constraint solver may be used to ensure satisfiability.

Symbolic finite automata

An extension of symbolic execution for programs involving contracts with quantifiers over large and potentially unbounded domains is described. Symbolic execution is used to generate, from a program, concrete test cases that exhibit mismatches between the program code and its contracts with quantifiers. Quantifiers are instantiated using symbolic values encountered during a set of exhibited runs. In this setting, quantifier instantiation is limited to values supplied to or produced by a symbolic execution. Quantifier instantiation is controlled by performing a matching algorithm that uses run-time values of input and program variables in order to guide and limit the set of quantifier instantiations. With a sufficient set of instances, test cases are derived that directly witness limitations of the auxiliary assertions.

Symbolic runtime checking of quantified contracts

Disclosed is a process to generate and execute relevant, non-redundant test cases starting with an execution trace. An execution trace may be collected. A sequence of actions and the data involved in the actions may then be extracted from the execution trace and persisted separately from one another. Code for a non-deterministic program ('NDP') may be generated, comprising the sequence of actions but without determining the data. A systematic program analysis of the NDP may be made, exploring possible execution paths and beginning from the path exercised by the persisted data. A new test case may be generated which fixes particular test inputs for the NDP.

Whitebox trace fuzzing

A symbolic query exploration (QEX) module automatically produces output information that can be used to evaluate a database. The QEX module operates by converting an input query into a formula for processing by a satisfiability module theories (SMT) solver module. The SMT solver module generates a model that satisfies the formula. The model yields table information that is used to populate the database and, optionally, parameter information that is used to instantiate the query. A query evaluation module then submits the instantiated query to the populated database and evaluates whether an evaluation result produced thereby agrees with pre-specified condition information. The QEX module can preprocess the formula using either (or both) an eager expansion approach (in which the formula is expanded in an upfront manner) or a lazy expansion approach (in which axioms are identified for later possible expansion by the SMT solver module).

Symbolic query exploration

In one embodiment, a computer system determines that a previously run test scenario configured to test a software program has failed to produce an expected result due to one or more semantic errors, generates error trace code configured to monitor the called component, processes the test scenario using the error trace code, and analyzes error trace information to determine the point at which the semantic error occurs in the called component. In an alternative embodiment, a computer system detects a semantic error in a software component of a software program, constructs an error condition that may include source code representing a minimum condition under which the error occurs, generates an object invariant based on the error condition that represents an opposite condition to that represented by the error condition, and automatically generates source code change recommendations using the object invariant that prevent the semantic error from reoccurring in subsequent test scenarios.

Bounded program failure analysis and correction

In one embodiment a computer system automatically generates unit tests. The computer system accesses a parameterized unit test that provides a base outline from which one or more unit tests are automatically generated, generates input parameter values for a unit of software code, automatically generates a unit test configured to assess the functionality of the unit of software code, and receives test results from a software testing program and provides feedback to a user. In other embodiments, a computer system automatically maintains a unit test database. The computer system receives a unit test at a unit test database, assigns a test identity to the received unit test, determines that the test identity assigned to the received unit test is unique when compared to other unit tests, determines that the received unit test has different functionality coverage characteristics, and adds the received unit test to the unit test database.

Growing community of inventors

Seattle, WA, United States of America

Jonathan Paul De Halleux