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.
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(); |
#![feature(unsize)] | |
use std::{ | |
any::TypeId, | |
marker::Unsize, | |
fmt, | |
}; | |
enum Dyn<'v, T: ?Sized, TStatic: ?Sized> | |
{ |
using System; | |
using System.Threading; | |
namespace PureDI | |
{ | |
class Program | |
{ | |
static void Main(string[] args) | |
{ | |
// Create the singletons once |
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.
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<'_> { |
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.
union MaybeInitialized<T> { | |
initialized: T, | |
uninitialized: (), | |
} |
/*! | |
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. |
/* | |
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(); | |
``` |
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: