Trying to use gui on Colab - user-interface

I am trying to build a gui on Colab, via Tkinter.
The original project is here:
https://github.com/julrog/nn_vis
I already know that the problem is due to code being executed on Google cloud server, the problem is how can I build a gui, or more precisely can I ever link it to my local laptop to be visualized, use XMing, or something like this? (my OS is Windows

As ivan_pozdeev says, you need to run a framebuffer server (that will emulate a graphical screen) and create a DISPLAY envvar pointing to it.
!apt-get install -y xvfb # Install X Virtual Frame Buffer
import os
os.system('Xvfb :1 -screen 0 1600x1200x16 &') # create virtual display with size 1600x1200 and 16 bit color. Color can be changed to 24 or 8
os.environ['DISPLAY']=':1.0' # tell X clients to use our virtual DISPLAY :1.0
However, if you want to interact with the GUI, that's going to be hard, 'cuz Colab doesn't support interactive screens out of the box.

Related

SDL2 OpenGL in Windowed Mode on Raspbian

Using a Raspberry Pi 2 I'd like use SDL 2 to create hardware accelerated OpenGL ES 2 programs in windowed mode. I'm currently unable to do this. I'd also like the ability to toggle between full screen and windowed mode in my programs if possible.
I believe my problem is related to the build configuration I am using from SDL2 sources.
I followed this guide to get SDL2 working with OpenGL ES from sources on my Raspberry, and it works for creating full screen SDL2 programs with an OpenGL ES context:
https://solarianprogrammer.com/2015/01/22/raspberry-pi-raspbian-getting-started-sdl-2/
The guide makers configure options are:
../configure --host=armv7l-raspberry-linux-gnueabihf --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-x11 --disable-video-opengl
In his guide, the creator states: "The above options will make sure, SDL 2 is built with the OpenGL ES backend and that any SDL application will run as a full screen application,"
I would really like to modify the build configuration to allow for windowed mode. What options would I need to change in his configure to allow for OpenGL ES 2 in windowed mode which can be toggled to full screen?
https://wiki.libsdl.org/SDL_SetWindowFullscreen
That is, to have the option to create a windowed SDL2 OpenGL ES program at first, with the option to toggle between full screen and windowed from within my program. How can I make an SDL2 for Raspbian to allow for this kind of behaviour?
My system details:
Raspberry Pi 2
Raspbian OS
LXDE desktop
Thanks
You need to remove the --disable-video-x11 option you're passing to the ./configure script. X11 is the window manager and is responsible for creating your windows.
It appears this is typically not recommended since it can cause somewhat buggy behaviour.
For copy paste lovers
./configure --host=armv7l-raspberry-linux-gnueabihf --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-opengl

OSX Yosemite + Crossover (Wine) = Sporadic MIDI Sync

The setup:
OSX Yosemite.
Ableton Live 9 (Suite).
Crossover/Wine (14.0.3).
Connected device is a Novation Launchpad Mini (USB).
The problem:
The install of Ableton and most of its use work well. I have compiled and successfully installed wineasio.dll (wineasio.dll.so) to obtain low latency audio, again this works extremely well.
But what I am finding is the communication between the LP and Live is somewhat sporadic. examples of this are, having to list the LP in the midi in/out section of live multiple times just to get it to behave correctly (mostly), pads/lights randomly lighting/becoming non responsive, active tracks not showing (lighting up)
There is no pattern in all this. bug what i can say this setup works without problems in windows and OSX (obviously)
before you ask I'm having to use WINE as one of my favourite VST's is only windows based.
if someone can recommend a VM based solution (with low latency audio/ Midi) i will welcome it.

Capture network traffic as images

I am trying to create a solution that scans all network traffic and pulls out the jpg and gif images. These images could be saved to a directory and displayed by any of several "slideshow" applications or perhaps there is a simple way to show them in real time.
At my disposal is a Mac Laptop running Mountsin Lion, a terminal, and the built in wireless.
Any suggestions on an app that already does this that will run under those system requirements or perhaps a simple set if shell commands I could put together?
After a little searching I stumbled on some software called driftnet which is a network image sniffer, and is actually in Fedora's yum repo (and probably available in other distros).
Here is a description from the official site:
Driftnet is a program which listens to network traffic and picks out
images from TCP streams it observes. Driftnet is free software,
licensed under the terms of the GNU GPL.
I didn't see a homebrew package for Mac OSX so you might have to download the tar.gz and compile it yourself. It comes with very good man pages and hopefully suits your needs.

Communication over serial port using Bash

I'm trying to get a check-scanner to transmit image files to my Mac (the company only provides Windows drivers). I have the technical manual that specifies all the commands that can be sent to the device, and I'm trying the most basic commands first (blink the LED, print serial number, etc.).
I have been able to successfully communicate with the device using "Serial Tools", but I'm trying to use bash for more control of the input/output and to eventually write an automated script.
After reading a few other posts and trying several things, so far I've tried this:
Opening the port with stty command and various flags, for example:
stty -f /dev/tty.usbserial-A5002TeW speed 9600 cs8 cread clocal
stty -f /dev/tty.usbserial-A5002TeW raw speed 9600 -cstopb -parity -echo
Trying to send commands over echo:
echo $'LE 100\cM\cJ' > /dev/tty.usbserial-A5002TeW
--Note that the serial device is connected through a USB adaptor, but responds (at least in Serial Tools) as a regular serial device after I installed the right drivers for it.
--I'm trying to use the \cM\cJ characters because as the device was intended for use by Windows boxes I figured I should use their control codes, I've tried multiple permutations of the code.
The Problem:
No matter what happens, the device never responds (no blinky LED lights, no output, etc) and my bash shell hangs until I stop it (^C). I know I can probably use a Python library, and I might wind up doing that, but I'd like to at least see some basic functionality with the bash shell.
Another option would be to try to get it working under a VM (VirtualBox, Fusion, Parallels, etc.) by installing Windows in the VM on your Mac.
Most cumbersome solution, because you'd have to reboot all the time, dual boot your Mac into windows.
Finally, I have an app on my iPhone from my banking institution that simply uses the camera in the phone to photograph the front and back of a check, and they'll accept it that way. This might be an option.

Is it possible to connect to Mac OS X 10.5 Leopard's built in vnc server at a low color depth from Windows?

If I attempt to connect to Mac OS X 10.5 Leopard's built in vnc server at a low color depth from Windows, the client bombs after connecting. It only works when I set it to the highest color depth. I've tried with at least 3 windows VNC clients. Any ideas? There some setting I can set in Mac OS X?
It takes about 20 seconds to repaint the screen with my current connection and high bit depth setting.
Not with the builtin VNC server. Vine Server allows you to change the bit depth that clients connect at though.
In my experience you can't lower the color depth with the default vnc server. I won't assert it, because maybe that behaviour could be changed using a console command.
I'd recommend installing another VNC server in mac, like http://sourceforge.net/projects/osxvnc/
The built-in vnc seems to have very little configurability that I can see.
As an alternative, you can try using osxvnc which I believe allows different bit depths
You can from the client side switch to High Color(16 bits) but not Low Color(8 bits). You can also enable JPEG compression. With both of these options on the sessions speed of to me from completely unusable(~45s for initial screen draw and ~5s lag on clicking menus) to quite usable(<5s for initial screen draw and <1s lag on clicking menus).
Note that these times are for connecting from a remote computer to my home iMac on a cable modem. Also this is running dual screens witch get sent out even though I only use the primary one on VNC. I have yet to figure out a way to switch off the secondary screen in VNC and its to troublesome to unplug it.
I use both. I find the built-in VNC server in OS X offers the most compatibility with keystrokes. I use it when I'm on the local network. When using VPN (much slower), I setup Vine Server ("System Server" mode) on a non-standard port # (say 5905), with a much lower color resolution, so the screen doesn't take 30 seconds to redraw whenever I click something.
Then I just ask my client to connect over the appropriate port: 5900 calls the built-in VNC server (for high rez use on the LAN), & 5905 calls Vine Server (for screen update speed over VPN). Best of both worlds.
I gave up and started using LogMeIn's free edition.

Resources