KodrAus

use std::path::PathBuf;
use std::process::Command;
use std::str;

let mut msbuild = PathBuf::from("msbuild");

let check_msbuild = Command::new(msbuild)
    .arg("--version")
    .output()
    .is_ok();

KodrAus

#![feature(unsize)]

use std::{
    any::TypeId,
    marker::Unsize,
    fmt,
};

enum Dyn<'v, T: ?Sized, TStatic: ?Sized>
{

KodrAus

using System;
using System.Threading;

namespace PureDI
{
    class Program
    {
        static void Main(string[] args)
        {
            // Create the singletons once

KodrAus

https://github.com/search?q=user%3AKodrAus+topic%3Aexample

Any example repositories I put together should turn up with a user:KodrAus topic:example GitHub search query.

KodrAus

use std::fmt;

use log::kv::{self, Source, value::{self, Fill}};

use tracing::{Value, Field, field::{self, Visit}};

#[doc(hidden)]
pub struct LogField<'kvs>(&'kvs Field, &'kvs dyn Value);

impl fmt::Debug for LogField<'_> {

KodrAus

Using cargo features to replace a set of concrete trait impls with a blanket one

There's subtlety involved in doing this so I've just dumped this out from another document in case I ever need to remember what they were in the future.

value::Visit

The Visit trait can be treated like a lightweight subset of serde::Serialize that can interoperate with serde, without necessarily depending on it. It can't be implemented manually:

/// A type that can be converted into a borrowed value.

KodrAus

union MaybeInitialized<T> {
    initialized: T,
    uninitialized: (),
}

KodrAus

/*!
This example demonstrates a potential macro for capturing log properties.

The macro uses a syntax that's _similar_ to struct literals. The idea is to support
extensions to the way properties are captured using attributes.

There's a bit of a misalignment between how formatting is communicated in the log
message and the contextual properties, but they are a bit different. Args are slurped 
up into the message using the formatting API whereas properties are exposed as data.

KodrAus

/*
An Autofac lifetime that ensures dependencies are only resolved from scoped containers.
This acts like a safety-net to prevent captive dependencies:

```
// Register some short-lived dependency using the `NonRootScopeLifetime`
var registration = builder.Register(c => c.Resolve<IStore>().BeginSession()).As<ISession>();

registration.RegistrationData.Lifetime = new NonRootScopeLifetime();
```

KodrAus

Dependable Dependencies

In this post I'd like to explore the quality libraries aspect of the [Rust 2018 roadmap RFC]. I'll lay out the framework that underpins my perspective on open source development as a starting point for conversation.

Quality means dependability. It also means a bunch of other things, but I'd like to focus on dependability here. The roadmap discusses sharpening Rust's offerings in a few focus domains, and I think a key to doing that is by supporting the dependability of libraries that fit within them.

What exactly is dependability though? I think a dependable library consists of: