I am using a BBB with the Debian distro. I access Cloud9 (192.168.7.2:3000) via Chrome on my Windows 7 machine. I am able to access existing demo js programs and have written a test program (myblink.js). The editor and overall system works fine.
But when I try to run the program, nothing happens for a few seconds, then eventually, it appears to stop on the first line (which becomes highlighted yellow). When this happens, the debugger panel pops out and the bottom window shows that the "debugger listening on port 15454" and I have the option to stop the program. At this point I can step through the program, well, at least to the point where there is some asynchronous events handling required.
However, if I run "node myblink.js" app from the bash tab in Cloud9 or from a shell (via putty) it works perfectly fine.
Do I have to set anything up to enable debugging? Or is it too much to expect from the debugger and a BBB system?
Related
Background
I have a makefile which fetches and spins up a Dockerized Mediawiki instance on my local machine, from scratch, with a single make command:
https://gitlab.wikimedia.org/mhurd/mediawiki-docker-make
This works fairly well. Please try it!
Goal
I'd also like to be able to run Mediawiki's Selenium tests (as-is) in Docker containers and watch them execute "live", with the makefile, again, making it easy to kick this process off.
Approach
This work-in-progress branch adds a container for running Mediawiki Selenium tests, and a browserless-chrome container so you can watch and debug the tests "live", as they run:
https://gitlab.wikimedia.org/mhurd/mediawiki-docker-make/-/tree/selenium
As you can see from the top of this branch's readme, after running make to spin everything up, running make runseleniumtests kicks the tests off. When doing so a browser window is automatically opened which lets you see the Selenium tests which are running in the browserless-chrome container. This works... to a point.
Problem
Unfortunately, after a few tests are seen to be running, I'm seeing this error:
Protocol error (Input.dispatchMouseEvent): Target closed.
I suspect the way the browserless-chrome container manages its Chrome sessions may be to blame, as it appears the error is happening when a test causes a new page to be loaded, but I'm not sure.
Any ideas appreciated, and please try it yourself - the whole point of the makefile is to make spinning this up from scratch super simple. It only takes a couple commands and you should be able to see the tests running and the resulting error. Thanks!
Misc
Running curl -s http://127.0.0.1:3000/sessions | python3 -m json.tool on the host machine after attempting to run the tests shows there are multiple browserless-chrome sessions, but I'm unsure how to make it behave more like a non-dockerized setup - which has no problem with tests which cause page loads.
In email communication with Browserless support, they mention seeing similar issues but haven't been able to track down why:
It seems to be that the root cause may be due to "click" events aren't
working properly when your viewing the live debugger. Can you confirm
that if you don't open the live viewer, it allows the test to progress
and eventually throws new errors regarding selectors not being found? (Edit: I did)
I've also run into this live debugger behavior before and in my
experience I stopped watching the live debugger, and since I couldn't
see which selector it wasn't finding I exported a screenshot and in
that particular case, it ended up being an issue with my viewport,
since the viewport in the remote session was smaller, the styles
rendered differently then locally on my machine, when I set the
viewport size, the selectors were found - but then again, that was my
particular issue, might not be yours.
But yes, for some odd reason when you view live sessions, you can run
into this odd issue which we haven't been able to understand.
If I trigger pry or byebug, eventually while using the live-debug mode the cursor will disappear, and input will become slow/laggy. Ultimately I have to Ctrl-C and kill the unicorn/puma process. After I've quit the process the terminal works, but the cursor is sometimes still missing/invisible. Then I have to close the terminal and open another. I've tried two different servers (puma/unicorn) and two different debugging tools (pry and byebug).
Hard to say if this is related to the debug tool, the rails server or my Terminal. I'm using Terminal.app with Solarized theme.
When the cursor disappears you can enter the command stty echo and hit enter. That should bring the cursor back.
I didn't believe this until I tested it a few times, but it's really happening.
Start rails server and app from powershell: 'rails s'
open a web page from that server
note how long the page took to get served up
now in powershell, select some text
reload the webpage from step 2
note that the webpage is taking forever to load
set up the windows so that you can see the powershell window and web page at the same time
go back to powershell and hit 'Enter' (so that the selected text is copied)
note that the web page loads as soon as the powershell window leaves select mode
TLDR: Rails server started via powershell won't serve pages while powershell is in 'Select' mode.
Is there some setting in powershell that will stop it from doing this? I can see it being helpful when selecting text in the middle of a bat run but when it stops my server it's flipping obnoxious.
Open a powershell window that you would normally start rails in. Open the properties dialog for the window and deselect QuickEdit Mode on the Options tab.
I had commented thinking it was just a general issue with the console system, and it probably still is as I cannot see how powershell is involved here as it's just a parent process, but it appears to be isolated to code that is watching for input. I think the rails server might be looking for input during its main loop, and perhaps selecting text in the console is blocking this. Take this simple script that loops - but does not watch for input - on a single thread, writing to a debug listener:
ps> $i = 0
ps> while (1) { sleep -seconds 1; [diagnostics.trace]::writeline("ping: $i"); $i++ }
Now, run sysinternals/microsoft's free DbgView tool to watch the output. I am using a separate tool instead of writing to the console because this is more like your scenario where web pages are being served in the background to a socket. You can get DbgView from:
http://technet.microsoft.com/en-us/sysinternals/bb896647
When I select the text in the console, the script does not pause. I even stuffed in a check in the key buffer, and it still did not stop.
I think the Rails server is doing some kind of key checking which is being blocked somehow and interfering with its ability to process requests. It seems retarded, but my script doesn't fail even if I stuff in a check for [console]::keyavailable
ps> while (1) {
>> sleep -seconds 1;
>> [diagnostics.trace]::writeline("ping: $i");
>> $i++
>> $dummy = [console]::keyavailable
>> }
Looks like it's Rail's fault, albeit unintentionally of course.
I'm on mac osx using zsh. If I start a rails server with "rails s" I can put it in the background by hitting "ctrl-z" in my terminal (zsh).
If I open up a different terminal window then I don't see the rails server if I do "jobs". However, I can see it when I do "ps".
Is there a way I can somehow "unpause" the rails server in this new terminal window?
You can not easily move a process to a new tty. The easiest solution would be to start it in a screen session, detach screen and then resume in the new terminal.
The job is "stopped" by sending it a SIGSTOP.Your C-z doesn't send the job into the background. It "stops" it. You can then move it into the background using the bg shell builtin. However, if you send this process a SIGCONT (kill -CONT <pid>), it should bring the process back to the foreground. This can be done from a different shell.
You will not see it if you type jobs because it is a job controlled by a different shell (the other terminal window and not the one where you typed jobs). Processes however are "global" and can be seen from anywhere using the ps command (as you rightly pointed out).
Update: Looks like I spoke too soon. Apparently, the signal alone isn't enough to bring it back to the foreground. Probably something to do with the shell.
I have a strange bug somewhere in my system that causes the screen to move very fast when it occurs (I can't really describe it) and I learned to deal with it by putting my laptop to sleep then waking it up ..
I'm suspecting it's something with the display driver, and it gets fixed if the driver is restarted.
Is there a way to restart the display driver programmatically?
I noticed sometimes in vista the screen blanks for 2 seconds and a ballon tip appears in the tray saying the display driver had to restarted due to something blah blah.
So I figured there must be a way to restart it in code.
What I want to do is write a command line tool that restarts the display driver so that I can launch it with a keyboard combination when I need to.
[ UPDATE (30/1/2009) I tried restarting the aero service as suggested, but it didn't solve the problem. ]
it seems the name of the display driver "service" is igfx, however, I can't stop it from the command line
C:\>net stop igfx
The requested pause, continue, or stop is not valid for this service.
More help is available by typing NET HELPMSG 2191.
C:\>NET HELPMSG 2191
The requested pause, continue, or stop is not valid for this service.
There are two things you can try, which will restart various parts of the video stack.
Restart DWM (Aero/Glass) with:
net stop uxsms
net start uxsms
Change the resolution with a utility such as setres.exe