I am trying to run the spectrogram.py example to work on bokeh. I get everything showing up in my browser, but the plots contain no data.
Here are the steps I did:
starting a server: bokeh-server
run the script (from bokeh/examples/embed/spectrogram/): python spectrogram.py
open page in Safari at http://127.0.0.1:5000/
I know that pyaudio is working from other scripts. Also, I added a print of the recorded data in spectrogram.py and I can see the responds to sounds I produce.
I tried both the conda installed bokeh as well as a self compiled from github.
Any suggestions?
About my setup:
bokeh.version = 0.9.1
Python 2.7.10 |Anaconda 2.1.0 (x86_64)| (default, May 28 2015, 17:04:42)
OSX Yosemite Version 10.10.2
Macbook Air 13-inch late 2010
First, should mention that the spectrogram demo does not rely on the bokeh-server. It polls a REST endpoint directly from the client. You can also check localhost:5000/data to make sure the audio data is actually getting served up.
In any case, there seems to be some cross-site validation that is failing for 127.0.0.1 for some reason. I specifically have to load it as localhost:5000 for it to work. It does not work from 127.0.0.1 for me.
If that fails, please make an issue on the Bokeh GH with any browser console output (and browser version).
Related
Using atom-editor 1.13 with the love-ide package installed to run LOVE2d 10.2 games (windows 7)
Apparently if you create a conf.lua file in the same folder as your main.lua file you can add some configuations to main.lua. So, I've got these lines of code in my conf.lua to show console.
function love.conf(t)
t.console = true
end
But when I go back to my main.lua and type print("ballz"), all I see is a blank LOVE2d game screen with no extra console window. Not really sure if this is because I'm using atom editor or not. Everything seems to be PATH'ed correctly.
On a side note, whenever I run atom using the love-ide package it always tries to install some "dependecy files" like the hyperclick-love package, and the auto-complete-love package. These fail to install because I don't have git installed.. honestly I really don't know what git is, but neither it, hyperclick, or auto-complete seemed like requirements to run my game, so in the spirit of not installing unnecessary things onto my computer I never installed these things... annoying as it is to see this notification always pop up when I start atom. Anyone know if this is contributing to the issue, or know a way to remove these notifications or auto-download-attempts? My LOVE2d code still seems to run without these packages.
Have you set up the terminal emulator in your configuration?
(Windows only) Try using the lovec.exe executable instead of the normal love.exe. The first one attaches to the console that executed the game, the second one ignores it.
Lua has a buffered output, try adding io.stdout:setvbuf('no') to the top of main.lua
I've followed the instructions at the link below to "Build and simulate a Cordova iOS app in the cloud". https://taco.visualstudio.com/en-us/docs/build_ios_cloud/
After completing the instructions I'm able to build and get the iOS simulator working, however, I'm unable to attach a debugger.
The message displayed in remotebuild is:
GET /cordova/build/5655/debug 500 10.865 ms - 28
In Visual Studio I see the following in the Debug window:
Starting launch process C:\Program Files (x86)\nodejs\node.exe "(redacted)\node_modules\vs-tac\emulator.js" --platform ios --action launch --path "(redacted)\buildInfo.json" --serverUrl https://(redacted):3000/cordova --certificateName (redacted) --language en-US --loglevel info --cliVersion 5.4.1 --npmInstallDir "(redacted)" --deployTarget "iPhone 5"
Timed out connecting debugger to remote Apache Cordova app. See Output window for JavaScript console output.
------ Cordova tools 5.4.1 already installed.
Requesting emulate on iOS Simulator for buildNumber 5655 on server https://(redacted):3000/cordova...
Emulated - Successfully sent to ios Simulator
------ Cordova tools 5.4.1 already installed.
Requesting debug on remote iOS device for buildNumber 5655 on server https://(redacted):3000/cordova...
Failed to Debug iOS remote for build (redacted)\buildInfo.json to https://(redacted):3000/cordova :
iPhone 5
My local development machine is using Visual Studio 2015 and Cordova 5.4.1. I have Node v0.12.2 installed locally and v0.12.9 installed on the MacInCloud. Following the instructions in the link above, I am NOT an admin on the Mac machine.
I've also already tried the instructions suggested in this SO answer: Visual Studio Debugger failing to connect to remote Apache Cordova app in iOS simulator
All the suggestions and the links provided by others were helpful but ultimately my assessment of the problem was not being admin/root on the Mac. The Visual Studio Cordova docs linked in my original question would suggest that you can do all that you need on a Mac without having admin/root access but in my experience that is just not the case.
To the credit of the MacInCloud group, they were very helpful in making changes that I requested to permissions and for reinstalling packages such as brew, ios-webkit-debug-proxy, remotebuild, etc... but after a while that back-and-forth kind of approach to fixing the issue proved painful. When I switched from a Managed MacInCloud server to a Dedicated one, everything worked almost immediately.
Looking back I think the initial execution of remotebuild, which executes brew -- without being admin on the box -- caused the whole process to go south. I was warned when I ran remotebuild for the first time that it would install some brew components that might need root access. That should have been a warning sign to me that not being admin on the box was going to be an issue...
Even though I was able to get a Dedicated MacInCloud server working, the lesson I learned about having control over the Mac prompted me to just buy a Mac Mini. That was a little more difficult to setup because I was now doing everything myself, but ultimately I think it will pay off in the end.
For anyone else struggling with similar issues here is a brain dump of some things I learned along the way:
You don't necessarily need to get Visual Studio talking to the Mac to debug Cordova applications. You can use Safari Web Inspector from the Mac. https://blog.nraboy.com/2015/10/debugging-your-apache-cordova-ios-app-with-safari/. Even though I finally got VS working, I actually prefer this because it is more like Chrome's debugger which I prefer to Visual Studio's.
The ios-webkit-debug-proxy NPM package mentioned in other comments and links is basically a proxy which Visual Studio uses to debug the simulator in exactly the same way Safari does as mentioned above. For this proxy to work you must also be allowed to connect to the Mac over ports 9221-9322. https://github.com/google/ios-webkit-debug-proxy. Prior to learning that I thought I only needed port 3000 open for the remotebuild proxy...
The package necessary for launching the iOS simulator from remotebuild is ios-sim and it will occasionally timeout when launching the simulator and cause the debugger not to attach. This is a known limitation. https://github.com/phonegap/ios-sim and https://blogs.msdn.microsoft.com/visualstudio/2014/11/13/tools-for-apache-cordova-update-ios-debugging-windows-8-1-support/ (see comments).
If you should feel the need to install/uninstall brew it is very easy to do. Just run the install script and if already installed it will give you instructions on how to uninstall. http://brew.sh/ and https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/Troubleshooting.md#troubleshooting. To uninstall or reinstall a NPM package is equally easy and Google is your friend.
Read and re-read both of these links for setting up a Mac: https://taco.visualstudio.com/en-us/docs/ios-guide/ and https://taco.visualstudio.com/en-us/docs/build_ios_cloud/. Getting the RemoteBuild.config right is crucial for getting secure connections to work -- especially if you want to access your Mac Mini at home from across the internet.
If you are remoting to a Mac I highly recommend iRAPP or some other VNC alternative. My experience has been that VNC is painfully slow and having a bad connection when you're troubleshooting issues just leads to more aggravation. http://www.coderebel.com/products/irapp/
As mentioned above, the MacInCloud guys were great when I asked for support, but if you do need root access for more than six months the cost of a Mac Mini is less than a Dedicated server plan.
Cheers
Since it is the call to /cordova/[...]/debug that is failing it looks like you might not have ios_webkit_debug_proxy installed. You could try making sure that homebrew is installed (from http://brew.sh) and running brew install ios-webkit-debug-proxy. Afterwards you should be able to run ios_webkit_debug_proxy without an error.
If that runs successfully then you should be able to quit out of ios_webkit_debug_proxy and debugging should work via remotebuild.
I have clone the source code from github and installed in the following way
http://docs.bokeh.org/en/latest/docs/quickstart.html#quick-installation
version
'0.11.0dev2-433-g96576eb'
Everything works fine, except for bokeh server
type in "bokeh server" in command line, get
bokeh-server: command not found
but "bokeh serve" does start the tornado server, which in documentation say Flask is used ?
run bokeh serve --show filename.py to run a specific py file.
Bokeh had an older server bokeh-server command, which was Flask based. Unfortunately it did not scale well or meet the performance we wanted to achieve. As of version 0.11 there is a new bokeh serve command that is based on Tornado and a pure websocket protocol. It is easier to deploy and use, but the changes needed to support the new server and protocol were incompatible in fundamental ways with the old server, so the old bokeh-server command has been completely removed as of version 0.11 and later.
Bokeh server examples can be found at:
https://github.com/bokeh/bokeh/tree/master/examples/app
I want to replicate this:
https://github.com/bokeh/bokeh/blob/master/examples/app/sliders_applet/sliders_app.py
On my own multiuser bokeh server (bokeh-server -m).
However the comment clearly states that you have to run:
bokeh serve app.py
This doesn't seem to be shipped with bokeh 0.10.0.
I would like to publish it like I do with my other interactive plots e.g:
Session().login('tmpuser', 'securepassword')
output_server('sliders')
# The modified sliders_app.py code
cursession().publish()
There seems to be a lot of inconsistency between the documentation for different versions and the available examples.
The server documentation here is easy to follow: http://docs.bokeh.org/en/0.10.0/docs/user_guide/server.html
I can get a server up and running and publish simple static plots, but most of the interactive examples won't run as expected. Even simple tabs won't work.
bokeh serve is the new tornado and websocket based Bokeh server. It is much more performant, scalable and easy to use. It was introduced in version 0.11, which is why it is not available in a Bokeh version 0.10 install.
You were looking at the examples in the master branch on Github. This is always the most new, cutting edge, possibly unreleased code. You can always find example specific to the actual version you have installed by navigating to:
https://github.com/bokeh/bokeh/blob/<RELEASE TAG>/examples
I had the same problem today.
I believe the documentation is written with the new version 0.11 already in mind.
I'm trying to use the latest Google NaCl SDK. Following the instructions at https://developers.google.com/native-client/pepper18/devguide/tutorial
I downloaded the naclsdk tool from their site, ran update, and got a pepper_18 folder.
I set NACL_SDK_ROOT to the pepper_18 folder, went in to 'examples' and ran make. Everything seemed to compile just fine.
I started Chrome, looked in about: flags and about: plugins, and verified that NaCl is enabled. I installed the SDK Examples app (from: https://developers.google.com/native-client/pepper18/sdk/examples) and that works just fine.
Then I tried to run my locally built and hosted examples, going to http://localhost: 5301. The HTML loads fine but the NaCl content does not load. In the hello world examples, it says "Status: LOADING..." forever.
I double checked the HTTP server logs and I don't see any errors there. Is there another place I should be looking for logged errors?
Check for version mismatch
In Chrome navigate to about:version and check that the major version of Chrome is at least that of the Pepper version you used to build your examples.
Check the JavaScript console in Chrome for any errors
You can find it by clicking the wrench icon in the upper right-hand corner in Chrome and selecting Tools -> JavaScript Console.
Inspect the NaCl module for further information
In the JavaScript console, you can also inspect the embed element of the NaCl module. E.g., if the embed tag has id="nacl_module" you can inspect it by typing
theModule = document.getElementById('nacl_module');
theModule.lastError;
Check Chrome's output to stdout/stderr
On Mac or Linux start Chrome from the terminal and look at the output on the console. E.g., on the Mac, you'd typically go
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-nacl
On Windows, Chrome does not write to the terminal if started from a command prompt. For this reason you need to redirect stdout/stderr from Chrome by setting the environment variables NACLLOG, NACL_EXE_STDOUT, and NACL_EXE_STDERR. Point them to different files, e.g.,
NACLLOG = c:\my_project\nacl.log
NACL_EXE_STDOUT = c:\my_project\nacl_stdout.log
NACL_EXE_STDERR = c:\my_project\nacl_stderr.log
Then (re-)start Chrome (making sure these environment variables are in effect).
Connect a debugger
Instructions on using the debugging support (currently only 64-bit Windows and 64-bit Linux) are available at https://developers.google.com/native-client/pepper18/beta-docs/debugging.
Restarting Chrome means closing all windows
When developing for Native Client one often restarts Chrome. It is important to close all Chrome windows; otherwise it hasn't actually restarted.
I muddled through a few issues which I will document in case they help others:
Neglected to 'make' the examples (got a clue to make them from the asker's description).
Chrome would not let me run non-store chrome apps. Went to chrome://flags and enabled Native Client and Native Client GDB-based debugging.
The JavaScript console said the demo's nmf file under .../debug/ was missing. I changed the make config to build Debug instead of Release based on this.
Chrome console complained NativeClient: NaCl module load failed: ServiceRuntime: failed to start; NaCl's GDB debug stub requires --no-sandbox flag on Windows. See crbug…. Tried running Chrome from cmd with --no-sandbox. This results in an alert You are using an unsupported command-line flag: --nosandbox. Stability and security will suffer. The aforementioned error went away, but the examples still would not run - no UI.
Went back to chrome://flags and disabled Native Client GDB-based debugging.
Then most of the examples worked. The Google Drive demo complains Error: must be run as a packged app.
have you confirmed that you've run httpd.py from the examples folder? This script creates the localhost:5103 server that the apps can be ran from.
Also, what OS are you using?
~Main