• ## Getting an image into and out of TensorFlow

Let’s assume you already have an image in numpy’s ndarray format, e.g. because you loaded it with OpenCV’s imread() function, and you want to convert it to TensorFlow’s Tensor format and later back to ndarray.

That’s essentially three calls to TensorFlow:

import cv2
import tensorflow as tf
import numpy as np

# normalize the pixel values to 0..1 range and convert them
# to a single-precision tensor
t = tf.convert_to_tensor(image_in, dtype=tf.float32)
assert isinstance(t, tf.Tensor)

# in order to convert the tensor back to an array, we need
# to evaluate it; for this, we need a session
with tf.Session() as sess:
image_out = sess.run(fetches=t)
assert isinstance(image_out, np.ndarray)

# for imshow to work, the image needs to be in 0..1 range
# whenever it is a float; that's why we normalized it.
cv2.imshow('Image', image_out)


Note that instead of using sess.run(t) we could also have used

with tf.Session() as sess:
image_out = t.eval(sess)


which essentially performs the same action. A benefit of using sess.run() directly is that we can fetch more than one tensor in the same pass through the (sub-)graph (say, tuple = sess.run(fetches=[t1, t2, t3])), whereas calling tensor.eval() always results in one separate pass per call.

• ## Dockerized .NET Core 1.0.1 and .NET Framework on Mono 4.7

TLDR; The setup is available via GitHub and the you can directly pull the sunside/dotnet Docker image.

Three components are used in this process:

• An Ubuntu Trusty base image that has libuv installed (required for Kestrel)
• A mono installation that supports .NET 4.6.1
• .NET Core 1.0.1

Ubuntu Trusty’s libuv is pretty old, so we’re building it from source. The base image is pretty straightforward, just use ubuntu:trusty, install the requirements for building libuv, as well as a bit of candy and then immediately throw away half of the stuff:

FROM ubuntu:trusty

RUN LIBUV_VERSION=1.9.1 \
&& apt-get update \
&& apt-get -y install vim-tiny nano curl wget autoconf automake build-essential libtool \
&& curl -sSL https://github.com/libuv/libuv/archive/v${LIBUV_VERSION}.tar.gz | tar zxfv - -C /usr/local/src \ && cd /usr/local/src/libuv-$LIBUV_VERSION \
&& sh autogen.sh && ./configure && make && make install \
&& rm -rf /usr/local/src/libuv-$LIBUV_VERSION \ && ldconfig \ && apt-get -y purge autoconf automake build-essential libtool \ && apt-get -y autoremove \ && apt-get -y clean \ && rm -rf /var/lib/apt/lists/*  Next step is mono. I’m using nightly builds here, but any modern installation would probably work. It’s pretty straightforward: mono-devel is required to get the system libraries (otherwise dotnet restore will be unable to restore frameworkDependencies), the rest is the compiler. ENV MONO_VERSION 4.7.0.559 ENV DEBIAN_MONO_VERSION 4.7.0.559-0nightly1 RUN apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF \ && echo "deb http://download.mono-project.com/repo/debian nightly main" > /etc/apt/sources.list.d/mono-nightly.list \ && apt-get update \ && apt-get upgrade -y \ && apt-get install -y mono-runtime=$DEBIAN_MONO_VERSION mono-mcs=$DEBIAN_MONO_VERSION mono-xbuild=$DEBIAN_MONO_VERSION mono-devel=$DEBIAN_MONO_VERSION ca-certificates-mono \ && apt-get -y autoremove \ && apt-get -y clean \ && rm -rf /var/lib/apt/lists/*  Finally, .NET Core 1.0.1 and the preview tooling (dotnet-dev-1.0.0-preview2-003131). This block brings in the tooling: RUN apt-get update \ && apt-get install -y apt-transport-https \ && echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet/ trusty main" > /etc/apt/sources.list.d/dotnetdev.list \ && apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893 \ && apt-get update \ && apt-get install -y dotnet-dev-1.0.0-preview2-003131 \ && apt-get -y autoremove \ && apt-get -y clean \ && rm -rf /var/lib/apt/lists/*  For docker versions earlier than 1.11.0, you’d also need an additional environment setting to prevent this bug: ENV LTTNG_UST_REGISTER_TIMEOUT 0  In order to prevent the „one-time“ warmup of the dotnet CLI tool, add ENV NUGET_XMLDOC_MODE skip RUN mkdir warmup \ && cd warmup \ && dotnet new \ && cd .. \ && rm -rf warmup  The final and missing clue is this comment on GitHub: When building net4xx (i.e. .NET Framework targets as opposed to .NET Core), you will run into pretty nasty errors stating that System.Native.dll couldn’t be found. Simply patch in a symlink to the file already installed by .NET Core and you’ll be fine: RUN ln -s /usr/share/dotnet/shared/Microsoft.NETCore.App/1.0.1/System.Native.so /usr/lib/libSystem.Native.so && \ ldconfig  With that, you’re done. Grab the code here or pull the image from the Docker Hub using docker pull sunside/dotnet:1.0.0-preview2-003131  • ## Building Caffe on Windows using Visual Studio 201…3 Note that now that BVLC’s caffe repository directly supports compilation on Windows, this guide has become obsolete. When attempting to check out Caffe after some wasted hours of getting TensorFlow to run on Windows (which sort-of works using Bash for Windows), I gave Caffe a try. However, the last time I tried to get a huge system of nested dependencies using CMake to work on Windows, things only got worse with every additional project. For Caffe, you’d need Boost, OpenCV, HDF and protobuf as well as some Google logging and command-line argument things amongst other stuff – and boy, make sure you got your linking, threading and runtime right, and don’t even think about mixing different C++ or Boost flavors. So there’s this Windows fork of Caffe managed by Microsoft which apparently only requires you to configure the CommonSettings.props file to your liking and then compile. The nice part is, all references are pulled using NuGet. The bad part is, the packages are all MSVC 1800, i.e. Visual Studio 2013. You’ll be able to find newer variants of Boost, but that’s about it. If you’re really trying to use Visual Studio 2015, fix the nuget.config to have the repository path fixed like described in this StackOverflow answer: <?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <add key="nuget.org" value="https://www.nuget.org/api/v2/" /> </packageSources> <add key="repositoryPath" value="..\..\NugetPackages" /> </configuration>  Also note that the path is most likely outside your build tree … but that’s how it is provided by the maintainer. I wasted another day trying to get Caffe to work in Visual Studio 2015 by selecting the 2013 toolkit but, in the end, it came down to the following error: NuGet error: unknown command 'overlay'  This overlay stuff apparently is some NuGet 2 magic that didn’t survive the dark ages, so it won’t work with NuGet 3, which I have in my path and which is also used internally by VS 2015. There are a couple of questions regarding that error, like this one on the OpenCV Answers site, issues on GitHub (with half-broken answers since the CoApp tooling doesn’t really work exist anymore), etc., but there’s no obvious solution – at least if you’re using a modern Windows development environment – that is, one that’s using NuGet 3 instead of NuGet 2.6. You can fix most of the problems by just upgrading OpenCV 2 to OpenCV 3. For that, kick out the old NuGet packages and reference the opencvdefault one as shown in this video. But even if you do that, it’ll fail on the glog 0.3.3 NuGet package which still uses overlays. As it turns out though, the NuGet package for glog 0.3.3 already contains a NuGet binary at glog.0.3.3.0/build/native/private/nuget.exe, but since it’s not in the path, it won’t use it. Copy that to the package’s root (where NuGet-Overlay.cmd can be found and you’re set. For the rest, make sure you’re using Python 2.7 though, as the Boost libraries are requiring that; also install NumPy. Using e.g. Anaconda Python, you’d want conda create -n caffe python=2.7 numpy  Which will leave you with the task to find python27_d.lib … or just build Release. • ## Rust: adding arbitrary things I just started learning Rust some days ago and, coming from a C/C++/C# background, immediately stubbed my toe on the type system. The notion of traits, however, is something I really like and allows for a stunt that is impossible in C# and ugly in C++: adding things, where by things I mean all the things. The key is to constrain a generic type parameter with the Add<T> trait. In this example, I’m constraining a generic type T1 to be Add<T2>, that is, to be able to add a T2 to itself. The result of such an operation is obviously generic as well, <T1 as Add<T2>>::Output (with Output being the type), allowing for the following code: fn add<T1, T2>(a:T1, b:T2) -> <T1 as Add<T2>>::Output where T1: Add<T2> { a+b }  While this function does nothing more than adding two values of arbitrary types (try that in C# with primitive types), the underlying mechanism allows for interesting operations such as vector-matrix multiplication without having to resort to a concrete type. A Complex would work as well as a primitive f32 (i.e. float), f64 (i.e. double), etc. You can do this in C++, but instead of having the compiler check the traits (like rustc does), you rather have to hope that someone implemented that specific operator overload or else you’d be in template error message hell. • ## „Compiler crashed with code 1“ on Mono Update: I opened a bug ticket for the described issue and it got fixed within the week. Original post: At work we recently stumbled across an interesting problem: While compilation of our C# 6 code base would work fine on Windows, a guy that works on OSX using Xamarin Studio suddenly was unable to compile the code, because „Error: Compiler crashed with code 1“. No line number, no nothing, only that. After a run through git bisect we eventually were able to track down the commit where I found the error to lie within an await happening in a string interpolation. Sadly, this problem was introduced by simply (and automatically) refactoring all occurrences of String.Format() in the file. I was able to reproduce the problem with the following simple code: private async Task<int> Foo() { await Task.Delay(1); return 42; } private async Task Bar() { Console.WriteLine($"Something {await Foo()}");
}


Apparently, the mono compiler doesn’t like that too much. The solution to this is simple: Don’t await within the interpolated string.
private async Task Bar()