Skip to main content

4 posts tagged with "Programming"

View All Tags

· 5 min read


If you're like me, you try and keep all of your coding-based clutter on a virtual machine. Which usually works great. You can maintain a clean OS, separate work from pleasure, and quickly return to a snapshot if something goes terribly wrong. But when I tried doing development for Android from a virtual machine, I quickly arrived at an unexpected hurdle.

If you try and run Android Studio's emulators, you'll quickly be reminded that you can't simply run a virtual machine inside a virtual machine. You technically can, if you enable Nested VT-x/AMD-V, but even if you succeed navigating the hell of starting an AVD android emulator from inside your VM, you'd be met by the huge performance hit of running nested virtualisation.

You can instead consider running either the Genymotion emulator or Xamarin Android Player, which both use Oracle's VirtualBox to run their emulators. But instead of running them inside your VM (and being met with the issue of nested virtualisation), you can run these emulators on your host OS. Since both of these use VirtualBox, you can take full use of the networking aspect of VMs to connect your development VM to your Android emulator VM!


Hence, my solution is to have two separate virtual machines running in VirtualBox on the host OS, and let them communicate using networking.


I'm assuming you've already

  1. Downloaded and installed VirtualBox
  2. Set up a development VM inside of VirtualBox
  3. Connected your dev VM to the outside world using either NAT or Bridged networking (I personally use bridged, since it helps me to easier access any web dev instances running in the VM)

Creating a virtual device

Alrighty, now we can download and install either Genymotion emulator or Xamarin Android Player on your host OS.

After you've done that, you can start up your software, and set up a virtual device (phone) by following the instructions.

created virtual device

Now we need to do some configuration work inside VirtualBox.

Configuring the virtual mobile device

If you open up VirtualBox, you'll see that the newly created virtual mobile device is listed in the list of machines.

list virtual devices

We need to edit the network settings for the mobile device. It will need two adapters. One is to connect to the network of the development machine (NAT or Bridged). In my case the machines are in a bridged network, which makes it easier to access from the host OS, as well as between each-other.


For some development platforms like React-Native, it's important that both the dev machine and mobile device are on the same network to allow easy debugging.

mobile bridged adapter

The other, arguably more important adapter to add/enable is the Host-only Adapter. This is the one adb will connect over.

mobile host-only adapter

Make note of the adapter name here!

VirtualBox has the habit of creating multiple host-only adapters, so this name is very important to make note of.

Configuring the development VM

Now that we have set the mobile device settings up, we need to mirror them in the develpment VM. If you've used NAT for the mobile device, redo the settings in the development one. If you've put it into a bridged network, do the same to the dev VM.

After this, we need to add a Host-only Adapter to the dev VM. Did you take note of the Adapter name from the mobile machine? This is where you use it!

dev machine host-only adapter

Starting up the machines

Normally, you just start them from their respective applications. Start the mobile machine from Xamarin or Genymotion, and start your dev VM from VirtualBox.

But I've found that if I start the mobile machine from Genymotion, it tends to reset the Host-only Adapter name, add a new one, and fail to start. So, if this happens to you, this is what I do:

  1. Start the mobile machine from VirtualBox. A command-line terminal will pop up, and will start loading.
  2. When it appears that the terminal isn't doing anything anymore, you can safely start the mobile device from Genymotion.

mobile device ready to be started from genymotion

This is how my terminal looks when it stops loading. At this stage, I start the device from Genymotion as normal.

If you haven't already, you can now start your development VM as well.

Connecting to the mobile device

In this scenario, we are going to use adb to connect to the mobile device from the dev VM. All we need is the IP that the device is running on. Both Genymotion and Xamarin provide some way to see the IP.

genymotion shows ip

But if you're having trouble to find it, you can go to VirtualBox, and see the IP from the terminal we saw earlier.

virtualbox shows ip

So, now we can easily connect from our dev VM using the command-line tool adb

kblagoev@deva:~/Android/Sdk/platform-tools$ ./adb connect
* daemon not running; starting now at tcp:5037
* daemon started successfully
connected to


And since I've used a bridged network, I can also easily do network connections between the two devices, which can be quite useful in some cases. So I recommend it, unless you have your own way of doing it.

Now you can develop! Have fun!

· 13 min read
  1. Quantum Programming by abstracting ourselves from Quantum Mechanics: Abstraction level 0
  2. Quantum Programming - Abstraction level 1: Logic Gates
  3. Quantum Programming - Abstraction level 2: State Machine and Algorithms (this)

We have been on quite the adventure so far. Let's recap our progress.

  • We've shown that by encoding information onto n qubits in superposition, we can manipulate the whole system of 2n states by only changing the state of one qubit.
  • We represented the state of each qubit as a simple 2D vector.
  • We've established that we can change the state of a single qubit (or two) by applying different logic gates to it, similarly to a classical logic gate.
  • We can now visualise the superposed state of the qubit (indeed of the whole system) on the Bloch sphere.
  • We know how to entangle two qubits, so that their states are correlated.

Now the time has come to start putting it all together. Wouldn't it be nice to actually string some gates together, and see what happens?

Well, in order to see what happens, we might want to be able to visualise the flow of our qubits' states, so we can see how each gate manipulates each qubit at each step.

Unit circle State machine

· 14 min read
  1. Quantum Programming by abstracting ourselves from Quantum Mechanics: Abstraction level 0
  2. Quantum Programming - Abstraction level 1: Logic Gates (this)
  3. Quantum Programming - Abstraction level 2: State Machine and Algorithms

We have previously worked out that a quantum computer operates logically on qubits, which are the quantum counterparts of classical bits. We've learned that a qubit can stay in a superposition while we operate on it, and then we can collapse it into a definite state upon measurement. So, for the majority of our time spent programming on the quantum computer, we will be thinking of the qubits in their state of superposition.

What would be extremely useful for our intuition now, would be to have a way to visualise this superposition. Enter the Bloch Sphere. This tool allows us to represent the whole state-space of a single qubit in one (very simple) geometric shape - the unit sphere. Think of it as the unit circle in trigonometry.

· 10 min read
  1. Quantum Programming by abstracting ourselves from Quantum Mechanics: Abstraction level 0 (this)
  2. Quantum Programming - Abstraction level 1: Logic Gates
  3. Quantum Programming - Abstraction level 2: State Machine and Algorithms

The invention of the personal computer, and the further development of the hundreds of programming languages which utilise it has allowed us programmers to completely abstract ourselves from the world of electrons flowing through solid matter, and further from the low level programming of turning gates and transistors on and off to produce binary data.