axefrog

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;

namespace SuffixTreeAlgorithm
{
	public class SuffixTree
	{

axefrog

const defaultIfZero = (a, x) => x === 0 ? a : x;
const isDefined = x => x !== void 0;
const isUndefined = x => x === void 0;

const NONE = Symbol('NONE');

const chalk = require('chalk');
const val = x => (x === NONE ? (x = 'none', chalk.bold.grey) : chalk.cyan)(String(x));
let highlightActiveNode = null;
let highlightedEdges = [];

axefrog

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Runtime.InteropServices;
using SharpDX;
using SharpDX.D3DCompiler;
using SharpDX.Direct3D;
using SharpDX.Direct3D11;
using SharpDX.DXGI;

axefrog

// Here we are creating our device, swapchain, etc. A fairly basic
// example of setting up our form for Direct2D drawing. Note the
// pixel format - we need to remember this when drawing pixels to
// our raw byte array.

var swapChainDesc = new SwapChainDescription
{
	BufferCount = 2,
	Usage = Usage.RenderTargetOutput,
	OutputHandle = form.Handle,

axefrog

/*
	HTTP/HTTPS Forward Proxy
	------------------------
	The purpose of this proxy is to manage a set of third party proxies
	internally, routing incoming requests through those proxies and
	rotating which remote proxies are in use periodically as requests come
	through, and without exposing the proxy credentials to the originating
	client. Rate limiting will later be implemented internally so that if
	the remote proxies have all been utilised too heavily, a "rate limit
	exceeded" message will be returned to the client.

axefrog

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.InteropServices;
using SharpDX;
using SharpDX.D3DCompiler;
using SharpDX.Direct3D;
using SharpDX.Direct3D11;
using SharpDX.DXGI;
using SharpDX.Windows;

axefrog

My process for designing systems and solving problems is fairly simple, and in a way it seems like an obvious approach, but the degree of effectiveness of the technique is greater than what you'd intuitively expect. When most developers write notes and try to work out how to tackle some kind of architectural design challenge, it usually takes the form of a few whiteboard notes, some scribbles in a notepad, etc. Usually this is fine because the problem is small and constrained to a manageable level. If you want to tackle something bigger and more challenging though, or if you want to design a much more effective system in the first iteration, rather than two-to-three years down the track after several deployments finally lead you to the conclusions you'd like to reach up front, then this process works really well. It does feel like you're committing to a chore if you haven't done it before, and the reason it works isn't itself obvious, which is part of the reason I get pushback from a lot of developers before

axefrog

using System;
using System.Windows.Forms;
using SharpDX;
using SharpDX.D3DCompiler;
using SharpDX.Direct3D;
using SharpDX.Direct3D11;
using SharpDX.DXGI;
using SharpDX.Windows;
using Buffer = SharpDX.Direct3D11.Buffer;
using Device = SharpDX.Direct3D11.Device;

axefrog

import {Stream, Sink, Scheduler, Disposable} from '@most/types';
import {disposeOnce, disposeAll} from '@most/disposable';

export type ActivateExtension<A = any> = (source: Stream<A>) => Stream<A>;
export type DeactivateExtension = null;
export type ExtensionAction<A = any> = ActivateExtension<A>|DeactivateExtension;
export type ExtensionLifecycle<A = any> = Stream<ExtensionAction<A>>;

export function extensible<A>(source: Stream<A>, extensions: Stream<ExtensionLifecycle<A>>): Stream<A> {
  return new ExtensiblePipeline(extensions, source);

axefrog

function identity<T>(value: T): T {
  return value;
}
  
let wrap = identity;

export function inspect<T>(fn: (value: T) => T): void {
  wrap = fn;
}