jarrettmeyer

public abstract class HttpSession : IHttpSession
{
  protected IKeyValueStore storage;
  
  public virtual int UserId
  {
    get { return Get<int>("user_id"); }
    set { storage["user_id"] = value; }
  }
  

jakesays-old

using System;
using System.Threading;


/// <summary>
/// Simple ReaderWriterLockShim wrapper that exposes read and write
/// guards.
/// </summary>
public class GuardedReaderWriterLock
{

mgedmin

# This is how you add a Jenkins slave

# On master:

  sudo -u jenkins -H ssh-keygen

# On slave

  adduser --system --group --home=/var/lib/jenkins-slave --no-create-home --disabled-password --quiet --shell /bin/bash jenkins-slave
  install -d -o jenkins-slave -g jenkins-slave /var/lib/jenkins-slave

hagbarddenstore

interface EventStream
{
	// Just a marker interface to let you know which classes are persisted.
}

class Site : EventStream
{
	private readonly HashSet<string> _registeredUsers = new HashSet<string>();

	public string Id { get; private set; }

jashkenas

Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.

For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.

But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.

SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil

swlaschin

// General hints on defining types with constraints or invariants
// 
// Just as in C#, use a private constructor 
// and expose "factory" methods that enforce the constraints
//
// In F#, only classes can have private constructors with public members. 
//
// If you want to use the record and DU types, the whole type becomes
// private, which means that you also need to provide:
// * a constructor function ("create").

cloudRoutine

Make things easy for yourself and start by running posh as admin

If you already have dnvm installed remember to run update-self if you haven't recently

Clone and checkout the coreclr branch of Kevin Ransom's Fork of the Visual F# Compiler and Tools

Installing DNVM

You need DNVM as a starting point. DNVM enables you to acquire a (or multiple) .NET Execution Environment (DNX).

GerjanOnline

It's so sad, these issues diverges the F# community more and more away from Microsoft and it also pushes away F# users

There is a big negative atmosphere about this:

Some tweets (do read the complete twitter threads, there is a lot more behind it) From F# side:

Somewhat disappointed in .NET and #fsharp lately. Where are the greener pastures though? Don't really see that many.

— Kurt Schelfthout (@kurt2001) November 18, 2015

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

guardrex

using System.Collections.Generic;
using System.IO;
using System.Linq;
using Microsoft.AspNetCore.Mvc.Razor;
using Microsoft.AspNetCore.Mvc.Razor.Directives;
using Microsoft.AspNetCore.Razor;
using Microsoft.AspNetCore.Razor.Chunks;
using Microsoft.AspNetCore.Razor.CodeGenerators;
using Microsoft.AspNetCore.Razor.Parser;
using Microsoft.AspNetCore.Razor.CodeGenerators.Visitors;

mhoyer

using System.Diagnostics;
using System.Linq;
using NUnit.Framework;
using System;
using System.Threading.Tasks;

namespace AsyncDollsAggregator
{
    [TestFixture]
    public class Test