ellismg / corefx

This repository contains the foundational libraries that make up the .NET Core development stack.

.NET Core Libraries (CoreFX)

The corefx repo contains the library implementation (called "CoreFX") for .NET Core. It includes System.Collections, System.IO, System.Xml, and many other components. You can see more information in Documentation. The corresponding .NET Core Runtime repo contains the runtime implementation (called "CoreCLR") for .NET Core. It includes RyuJIT, the .NET GC, and many other components. Runtime-specific library code - namely mscorlib - lives in the CoreCLR repo. It needs to be built and versioned in tandem with the runtime. The rest of CoreFX is agnostic of runtime-implementation and can be run on any compatible .NET runtime.

Build & Test Status

	Inner Loop	Outer Loop
CentOS 7.1
Debian 8
Fedora 23
openSUSE 13.2
OS X 10.11
Red Hat 7.2
Ubuntu 14.04
Ubuntu 16.04
Windows 7
Windows 8.1
Windows 10
Windows Nano Server 2016

How to Engage, Contribute and Provide Feedback

Some of the best ways to contribute are to try things out, file bugs, and join in design conversations. If you are having issues with the Full .NET Framework or .NET Runtime, the best way to file a bug is at Connect or through Product Support if you have a contract.

Want to get more familiar with what's going on in the code?

• Pull requests: Open/Closed
• , and changes

Looking for something to work on? The list of up-for-grabs issues is a great place to start. See some of our guides for more details:

• Contributing Guide
• Developer Guide
• Issue Guide

We've also started to share some of our direction via more higher-level documentation, specifically:

• Road to RTM
• How we triage
• Porting to .NET Core

You are also encouraged to start a discussion by filing an issue or creating a gist.

You can discuss .NET OSS more generally in the .NET Foundation forums.

Want to chat with other members of the CoreFX community?

.NET Core Library Components

The repo contains the source for each of the assemblies that comprises .NET Core. Each Microsoft.* or System. folder under src represents an individual library. Each such folder may contain a ref folder, which contains the source representing the "contract" or "reference assembly" for that library. It may also contain a src folder, which contains the source for some or all of the implementation for that library (some implementation may live in mscorlib in the coreclr repo, with the build tooling generating type forwards from the library assembly to mscorlib.)
It may also contain a test folder containing the tests associated with that library, whether the implementation source lives in corefx or in coreclr.

Daily Builds

Daily builds of .NET Core components are published to dotnet-core MyGet gallery. The latest version number of each library can be seen in that gallery.

License

.NET Core (including the corefx repo) is licensed under the MIT license.

.NET Foundation

.NET Core is a .NET Foundation project.

Related Projects

There are many .NET related projects on GitHub.

• The .NET home repo links to 100s of .NET projects, from Microsoft and the community.
• The .NET Core repo links to .NET Core related projects from Microsoft.
• The ASP.NET home repo is the best place to start learning about ASP.NET Core.
• dotnet.github.io is a good place to discover .NET Foundation projects.

corefx's Issues

Addition of a Rope Data Structure

Issue

Currently there is no Rope data structure implemented in the .Net library. It has been suggested that one be created to make appending, prepending, and insertion of large strings more efficient. However, there has been a second suggestion that possibly the already-existing StringBuilder data structure is sufficiently efficient to handle these types of large string processing. Finally, a third class, ImmutableList, is available from Microsoft and might also be an already-existing candidate.

Overview of considerations and recommendations are below; a more detailed document with the results of comparative testing of rope and non-rope functions is attached.

Considerations

Rope structures appear to be by far more efficient in multiple situations when manipulating very large strings. In various commentaries, manipulation of such large strings has been defined as an ‘edge’ case, which, several years ago was probably an adequate description, and even up until recently might have been adequately re-defined as a ‘specialty’ case.

More recently, Gartner has suggested that by 2020 the number of connected devices may reach 25 billion; this explosion in the IoT has the potential to push greater numbers of programmers to scenarios requiring pre-processing of big data at the edge of the network, on remote devices, as well as increased pre-processing in the cloud – and some of these scenarios will require intensive processing of large strings.

Some of this processing could commonly require, e.g.,:

• Collection of very large set(s) of strings followed by some or all of the following:
  • String search - for keywords and/or phrases
  • String split - subsetting of strings based on various inputs
  • String categorization - tagging of strings and substrings based on various inputs
  • String bucketization – grouping and/or concatenation of strings and substrings through appends/inserts
  • String packaging – sorting and formatting for delivery based on various output requirements

There are earlier investigations of developing a rope structure for the .Net library, as well as attempts to develop rope structures in some MS languages. For example, conversations in 2009 questioned the value of adding a rope structure to the library, and a later blog entry in 2011 by Eric Lippert (then with MSFT) stating he had worked on rewriting VBScript internal string manipulations to use ropes and that the code base probably still existed, commented out, as “Fancy_String”, and so I will be investigating this.

Recommendation

I suggest that a rope data structure be developed for the library which would, at start, contain methods that allow the following types of manipulations:

• Add different string object types to the end of a rope object.
• Insert different string object types at start or anywhere within body of a rope.
• Remove all or portions of a string from a rope object.
• Split a string with overloads which allow for various scenarios.
• Order a string or subset of a string with overloads which allow for various scenarios.
• Count the number of strings and characters in a rope.

Background Research and Testing

Rope_Research.docx

Extracting Array.Sort behavior to an abstract class to support different types of sorting algorithms

Issue

Trying to incorporating a new type of sorting, more efficient in almost sorted array, like TIMSORT (details of the issue - dotnet#2252) and after some initial discussions with coreclr team, we agreed that we need to refactor the current implementation of Array.Sort which doesn’t support the flexibility to use different types of sorting algorithms. We are designing a new implementation (using similar model to solution described by Strategy Design Pattern), which will support the existing IntroSort, and also will allow flexibility to implement other new types of sorting algorithms, including TimSort.

Current Usage

This is how currently the users call the Array.Sort API which internally will use the IntroSort algorithm to sort an array:

// Declaring an Array
string[] array = new string[] { "5", "2", "13", "8", "4", "3", "2", "4", "6" };
IComparer scomparer = new StringComparer();
Array spawn = (Array)(array.Clone());

//This SORT will ALWAYS use Introsort algorithm.
Array.Sort(spawn, index, length, comparer);

Proposed API

This is how the new SORTING abstract class will look like:

public abstract class Sorting<TKey, TValue>
{

   public virtual void Sort(TKey[] array)
    { }
    public virtual void Sort(TKey[] array, int index, int length)
    { }
    public virtual void Sort(TKey[] array, Comparison<TKey> comparison)
    { }
    public virtual void Sort(TKey[] array, int index, int length, System.Collections.Generic.IComparer<TKey> comparer)
    { }
    public virtual void Sort(TKey[] keys, TValue[] items)
    { }
    public virtual void Sort(TKey[] keys, TValue[] items, int index, int length)
    { }
    public virtual void Sort(TKey[] keys, TValue[] items, System.Collections.Generic.IComparer<TKey> comparer)
    { }
    public virtual void Sort(TKey[] keys, TValue[] items, int index, int length, System.Collections.Generic.IComparer<TKey> comparer)
    { }

}

This example of Concrete classes implementation:

public class IntroSorting<TKey, TValue> : Sorting<TKey, TValue>
{
    public override void Sort(TKey[] array, int index, int length, System.Collections.Generic.IComparer<TKey> comparer)
    {
        //It will call the current Array.Sort Implementation; Just a wrap 
        Array.Sort<TKey>(array, index, length, comparer);
    }
    public override void Sort(TKey[] keys, TValue[] items, int index, int length, System.Collections.Generic.IComparer<TKey> comparer)
    {
        //It will call the current Array.Sort Implementation; Just a wrap 
        Array.Sort<TKey,TValue>(keys, items, index, length, comparer);
    }
}

public class TimSorting<Tkey, TValue> : Sorting<Tkey, TValue>
{
    public override void Sort(Tkey[] array, int index, int length, System.Collections.Generic.IComparer<Tkey> comparer)
    {
        //Implementation of TimSort Algorithm
    }
    public override void Sort(Tkey[] keys, TValue[] items, int index, int length, System.Collections.Generic.IComparer<Tkey> comparer)
    {
        //Implementation of TimSort Algorithm
    }
}

New Usage

Declaring an Array

string[] array = new string[] { "5", "2", "13", "8", "4", "3", "2", "4", "6" };
IComparer<string> scomparer = new StringComparer();
Array spawn = (Array)(array.Clone());

//Now the user can use the different types of Sorting. Something like:
TimSort myTimSortAlgorithm = new TimSort();
myTimSortAlgorithm.Sort(spawn, index, length, comparer);

//or
QuickSort myQuickSortAlgorithm = new QuickSort();
myQuickSortAlgorithm.Sort(spawn, index, length, comparer);

Details

A few more details about some decisions we made when designing this API:

1. When designing this new API we considered for quite some time using Interface instead of Abstract class. However, in order 1) to continue to support all the overloaded methods currently available through Array.Sort and 2) don’t force the users, who want to create/extend a new Sorting class, to implement all overloaded methods. With the Abstract class approach the concrete class can delegate the implementation to the base class for some of the methods.
2. We are going to cover only the Generic type methods for the existing Sort.Array in the new API.
3. We decided to go with generic in the class (class Sorting ) instead of the Method (Sort) because if certain new derived sorting class work only for particular types, we don’t have to add special logic in the Sort methods.
4. The initial Sorting algorithm that we want to support (TimSort, IntroSort and Insertion Sort) are in-place are in-place, the SORT methods are going to return VOID and if the user needs to keep the initial state of the array, they will have to clone it before calling SORT method.

Open Questions

Pull Request

Updates