I'm using VS codespaces to complete the current CS50X course.
I've been getting on very well with it but have hit a snag where the Terminal doesn't seem to be loading correctly. I think i'm missing a couple of options at the top of the Terminal section - Debug and Port. I'm trying to complete the Finance section of the course which involves connecting to a development server but when i try i get the following erroe message:
{"type":"https://tools.ietf.org/html/rfc7231#section-6.5.4","title":"Not Found","status":404,"traceId":"00-76b8a3e0c4eaccf805373ec05e5ec917-dccabf0efd4cf681-00"}
I've tried to Google what might be going on but i'm very new to programming and don't understand a lot of what i'm reading!!
I did notice that the shell has failed to initiate, but again, i don't really know what that means.
I've tried re-loading the window repeatedly but still get the same situation.
Any ideas would be much appreciated!!
My PC has been randomly locking up lately, and while debugging I found an issue with my Ruby/Watir project. Each time the browser.close function is called, the following occurs in dmesg (slightly different each time):
[12614.684243] Chrome_~dThread[29941]: segfault at 0 ip 00007f17889b3992 sp 00007f1786aa0b00 error 6 in libxul.so[7f1787b6a000+519c000]
I'm not sure if this is causing my PC to lock up, however it still needs resolving. I've done some searching but I can't find anyone else with this issue. The issue also appears if I ctrl + c the script.
Error 6 is: The cause was a user-mode write resulting in no page being found., which makes sense if I've closed the browser.
I've read the answer on this page, but as libxul.so is a library it didn't help much (although offered me a better understanding of debugging segfaults!).
For those looking due to the linux/segfault tag rather than ruby/watir, browser.close is a builtin function in the Watir package.
Edit:
Although it says 'Chrome', the issue actually comes from FireFox
I don't get the issue in any other browser
libxul.so is found in /usr/lib/firefox/
This was actually the result of a PC hardware issue that wasn't apparent till much later.
I'm using Google Cloud Platform and have a virtual machine. I'm also messing around with webscrapers.
I'm currently trying to do a simple scrape of reddit using a ruby script. That part works pretty well. It essentially continues down and down (to the end of reddit!) scrape the articles, though this, obviously takes some time.
Right now, in order to scrape (I'm running ruby scrape.rb > reddit.txt) I have to keep the google virtual machine ssh browser window open on my computer or the process will exit (which makes enough sense). However, what I'd like to do is have the process persist even if I close the window.
Is there a way to somehow have this process continue to run? Then I can periodically log in and check reddit.txt which will continue to grow even I'm not ssh'ed in.
Thanks!
This seems to be the answer.
The command nohup is exactly what I was looking for!
I'm not sure which link in the chain is causing the problem. I just finished setting up Discourse on Vagrant on a Windows machine. Everything seems to be working fine, except that it took a good 86000ms (a minute and a half!) for Discourse to load in the browser. Something tells me that it's not supposed to be that slow. Where can I look for problems that might be causing this?
This is the most relevant discussion on the forum.
http://meta.discourse.org/t/development-mode-super-slow/2179
Make sure you have allocated enough resources in the virtual machine.
You can also try this in the development configs
#config/environments/development.rb
config.cache_classes = true
This made a huge difference to my render time. From 8 minutes to 30 seconds. Still a bit slow though.
I had the same issue in my VM when testing Discourse. What you actually have to do is change a config setting for WEBrick. Look for your WEBrick config which is usually in /usr/lib/ruby/1.9.3/webrick/config.rb yours could be different, it all depends on your particular setup.
Then change this line
:DoNotReverseLookup => nil,
to this
:DoNotReverseLookup => true,
Restart WEBrick and you should be good to go.
I am having selenium troubles. I will do my best to explain the setup I have and what I'm trying to do.
The short version:
Running my automated tests locally using a ruby webdriver gem works fine. Running the exact same script through the selenium-server standalone jar (whether remotely or locally) does not work without strange alteration in the code.
Is there a way to get a version of the selenium server standalone jar that behaves the same way as the webdriver client libraries?
Or is there some remote ruby gem version of the selenium server so that however the gemified version of the selenium stuff can work remotely?
Basic summary: "I feel like I am in Hooters and asking for my meal to go. I am missing something very fundamental here."
What I'm trying to do:
I am trying to automate testing a web application. The idea is to be able to load the company's website and then interact with the page elements like a real user would (click a link, put text into a text box, select radio buttons and checkboxes, etc). I developed these tests using ruby 1.9.3 and the selenium-webdriver gem for ruby on a mac (10.8.2). I created a ruby wrapper library myself, which I have called "WebAutomation.rb" in which I created my own methods in order to click on elements. An example of one of the wrapper methods I made is as follows:
def WebAutomation.click_element_by_attribute(attribute_name, attribute_value, tag, contains=true)
element = WebAutomation.find_element_by_attribute(attribute_name, attribute_value, tag, contains)
#log.debug("Element returned: #{element}")
raise "Could not click element with #{attribute_name} attribute of #{attribute_value}" unless element.click
end
And the WebAutomation.find_element_by_attribute calls another methods that looks through all the elements that I give it. As another layer of abstraction, I am not running the ruby code directly, I am running it through cucumber scripts That's not my problem. This code all works locally - by that I mean when the browser being driven automatically is local to the code being run.
However, I want to be all fancy-like and not have to run the code locally because I'm on a mac, and let's say I want to do cross-browser testing like run it on IE. So I have both a remote mac and a remote windows laptop with the goal of running this through some system like Jenkins where the Jenkins box would be able to tell these remote machines to run browser tests. I'm not that far yet where I'm worried about Jenkins. I'm just trying to get the remote versions of the tests to pass.
My troubles:
Running my cucumber/ruby scripts locally work great. They're awesome, and I thought I was the man. Then I ran it to the remote mac using the same browser (chrome), and everything went to pot.
Here's what I'm doing:
On the remote mac laptop, I downloaded the selenium-server standalone jar and started it like so:
java -jar selenium-server-standalone-2.31.0.jar
It looks happy to me:
Mar 14, 2013 8:00:06 AM org.openqa.grid.selenium.GridLauncher main
INFO: Launching a standalone server
08:00:11.606 INFO - Java: Oracle Corporation 23.6-b04
08:00:11.608 INFO - OS: Mac OS X 10.8.2 x86_64
08:00:11.616 INFO - v2.31.0, with Core v2.31.0. Built from revision 1bd294d
08:00:11.728 INFO - RemoteWebDriver instances should connect to: http://127.0.0.1:4444/wd/hub
08:00:11.729 INFO - Version Jetty/5.1.x
08:00:11.730 INFO - Started HttpContext[/selenium-server/driver,/selenium-server/driver]
08:00:11.730 INFO - Started HttpContext[/selenium-server,/selenium-server]
08:00:11.731 INFO - Started HttpContext[/,/]
08:00:11.744 INFO - Started org.openqa.jetty.jetty.servlet.ServletHandler#4f8429d6
08:00:11.744 INFO - Started HttpContext[/wd,/wd]
08:00:11.747 INFO - Started SocketListener on 0.0.0.0:4444
08:00:11.747 INFO - Started org.openqa.jetty.jetty.Server#4dfbca86
So then I run my cucumber scripts, passing it some command line arguments that tell it to go to the IP of the remote mac laptop and what browser to run and what environment I want the browser to go to for our application (this isn't important).
It looks like this:
cucumber REMOTE_URL=http://10.110.10.233:4444/wd/hub BROWSER=chrome JJ_ENV=staging features/jabberjaw/contact_us.feature:3
I have code that when a REMOTE_URL parameter is passed that a remote browser is called instead of a local one. The code that gets executed is below:
#This is the code that runs for a local browser
def WebAutomation.set_browser(browser)
#log.debug("Starting browser: #{browser}")
#driver = Selenium::WebDriver.for(browser)
end
#If the remote url is passed in, then I make a remote browser
def WebAutomation.set_remote_browser(url, browser)
#log.debug("Starting remote browser: #{browser} at #{url}")
#driver = Selenium::WebDriver.for(:remote, :url => url, :desired_capabilities => browser)
end
The browser window pops up on the remote machine and it goes to the correct url and logs in. However when running remotely, the selenium-server seems to have issues in clicking elements that are not visibly on the screen. I fixed that (sort of) with a
#driver.action.move_to(element, 100, 100).perform
I had to add the 100, 100 offset because even moving seem to only get to the top left corner and the element still wasn't on the screen. The other thing is that you know that exception I raise unless element.click (code above)? Yeah, that triggers regardless of whether the click really happened or not because for some reason the remote version (selenium-server) returns nil on the element.click whether it succeeds or not. When I run the same code locally (where it uses the webdriver gem), it gives me an {} when successful and nil when it's not. So to get this code to work remotely on chrome I had to do the following:
def WebAutomation.click_element_by_attribute(attribute_name, attribute_value, tag, contains=true)
element = WebAutomation.find_element_by_attribute(attribute_name, attribute_value, tag, contains)
#driver.action.move_to(element, 100, 100).perform
#log.debug("Element returned: #{element}")
element.click
end
In essence, explicitly moving to the element found, and just trusting the click works. Yes, with cucumber I do have a thin layer of protection in that the next step in the script should be a Then step that checks whether whatever action the click was supposed to do succeeded, but it feels wrong that I have to take out that exception and potentially open myself up to false positives.
And even this altered code fails completely on a remote version of firefox (I had to move down to firefox 18, since anything above 18 seems to not work with selenium webdriver - even locally - it just opens the browser window and does nothing else). On firefox, the browser window comes up, navigates to the url, logs in (up to this point, it's like chrome), but then it just gives me the finger and says "MoveElementTargetOutOfBoundsException".
I have also tried taking out the "remoteness" and tried running the selenium-server jar locally and running my tests on a local browser but through the selenium-server jar. Like a so!
cucumber REMOTE_URL=http://localhost:4444/wd/hub BROWSER=chrome JJ_ENV=staging features/jabberjaw/contact_us.feature:3
And I get the same results, so I'm pretty convinced that my problem is that the selenium-server jar is interpreting my scripts utterly differently than my selenium webdriver gem. I cannot be the first person to have run into this, but I have googled until my eyes bled and cannot find a solution to this.
There has to be some way that the client code that runs locally is interpreted the same way remotely, yeah? This can't be a new problem, because if I have to create weird custom code for whether I am running locally or whether it's remote and whether it's chrome and whether it's firefox then this whole "automation is robust and awesome because you can do cross-browser testing and scale across environments" is some mayo-mustard packed cheesecake. That creme filling? Do not want.
So it looks like I was able to finagle my way to a partial solution.
Apparently just starting the selenium server stand alone jar was not enough. The following got me a little farther.
On the server system (the remote system that will be opening and interacting with the actual browser):
java -jar selenium-server-standalone-2.31.0.jar -role hub
Then in a new terminal window (still server system):
java -jar selenium-server-standalone-2.31.0.jar -role node http://localhost:4444/grid/register
Then on the client system (the one with the actual cucumber and webdriver scripts)
cucumber REMOTE_URL=http://10.110.10.233:4444/wd/hub BROWSER=firefox JJ_ENV=staging
**Note, if you're following along at home, this command will be different since I coded my scripts to accept the REMOTE_URL and BROWSER variables to map to a remote webdriver call.
In any case, this allowed the original code that didn't have the explicit move method to work. I still had to eliminate my raise condition because clicks are still giving me nil whether successful or not when going remotely. Firefox also no longer throws up the MoveElementTargetOutOfBoundsException.
The tests still seem much more fragile than when run locally, but it's a least some progress. If anyone has any information about why my clicks always give me "nil" when run remotely whether successful or not, I'd appreciate it. If anyone also has any other information about why adding these role paramemters (and perhaps the registration) seems to stabilize things compared to just the regular java -jar seleneium-server-standalone-2.31.0.jar command that almost all the tutorials I read told me to do, I'd be interested in this.
However, like a big bowl of fiber, these commands have at least gotten me unblocked. Nothing worse than major blockage. I hope if anyone else is having similar troubles that this helps you as well.
I have gotten myself unblocked on windows remote testing as well. Apparently for that, I needed to get the chromedriver.exe and ieserverdriver.exe and put those on the server system. On windows, you still need to start the hub, but when starting the node, you'll need to add the following parameters:
-Dwebdriver.chrome.driver=<path_to_chromedriver.exe> -Dwebdriver.ie.driver=<path_to_ieserverdriver.exe>
And then from my client machine, I had to use port 5555 instead of 4444.