I have installed Ruby 2, devkit & Watir. I am getting the following error. Can anyone please help me resolve this issue?
C:\devkit>irb
DL is deprecated, please use Fiddle
irb(main):001:0> require "watir"
=> true
irb(main):002:0> browser = Watir::Browser.new
LoadError: cannot load such file -- watir-classic
from C:/Ruby200/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
from C:/Ruby200/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in`require'
from C:/Ruby200/lib/ruby/gems/2.0.0/gems/watir-4.0.2/lib/watir/loader.rb:48:in `load_driver'
from C:/Ruby200/lib/ruby/gems/2.0.0/gems/watir-4.0.2/lib/watir/loader.rb:40:in `load_driver_for'
from C:/Ruby200/lib/ruby/gems/2.0.0/gems/watir-4.0.2/lib/watir/loader.rb:8:in `new'
from (irb):2
from C:/Ruby200/bin/irb:12:in `<main>'
irb(main):003:0>
I'm not sure what happened then, but in case someone else runs into this problem here is what i did to get it working. Install the watir-classic (as suggested), install ffi, uninstall ffi, install ffi again. For some reason i had 2 variations of ffi (might be due to originally installing Ruby 64 bit?), but I also uninstalled 64 bit Ruby and installed 32 bit to get this all working. – breezy katt Feb 26 at 13:47
I'm assuming you're talking about using Watir on a Windows machine. From my experience installing Ruby in the correct way is the most difficult part.
First of all, install everything as if you're on a 32 bit system. The 64 bit installation often brings unwanted issues.
That said, the ffi gem can also cause issues, so you'll have to uninstall it, and re-install with specific tags:
gem uninstall ffi
gem install ffi --platform ruby
Finally, the error that is showing LoadError: cannot load such file -- watir-classic simply means that what you're doing is trying to make use of a certain gem that is not there. In this case watir-classic, so the following should fix that:
gem install watir-classic
A complete guide on installing Watir on Windows
Related
I am trying to install pysam.
After excecuting:
python path/to/pysam-master/setup.py build
This error is produced:
unable to execute 'x86_64-conda_cos6-linux-gnu-gcc': No such file or directory
error: command 'x86_64-conda_cos6-linux-gnu-gcc' failed with exit status 1
There are similar threads, but they all seem to address the problem assumig administriator rights, which I do not have. Is there a way around to install the needed files?
DISCLAIMER: This question derived from a previous post of mine.
manually installing pysam error: "ImportError: No module named version"
But since it might require a different approach, I made it a question of its own.
You can also receive the same error while installing some R packages if R was installed using conda (as I had).
Then just install the package by executing: conda install gxx_linux-64 to have that command available.
Source:
https://github.com/RcppCore/Rcpp/issues/770#issuecomment-346716808
It looks like Anaconda had a new release (4.3.27) that sets the C compiler path to a non-existing executable (quite an embarrassing bug; I'm sure they'll fix it soon). I had a similar issue with pip installing using the latest Miniconda, which I fixed by using the 4.3.21 version and ensuring I was not doing something like conda update conda.
See https://repo.continuum.io/miniconda/ which has release dates and versions.
It should now be safe to update conda. This is fixed in the following python packages for linux-64:
python-3.6.2-h0b30769_14.tar.bz2
python-2.7.14-h931c8b0_15.tar.bz2
python-2.7.13-hac47a24_15.tar.bz2
python-3.5.4-hc053d89_14.tar.bz2
The issue was as Jon Riehl described - we (Anaconda, formerly Continuum) build all of our packages with a new GCC package that we created using crosstool-ng. This package does not have gcc, it has a prefixed gcc - the missing command you're seeing, x86_64-conda_cos6-linux-gnu-gcc. This gets baked into python, and any extension built with that python goes looking for that compiler. We have fixed the issue using the _PYTHON_SYSCONFIGDATA_NAME variable that was added to python 3.6. We have backported that to python 2.7 and 3.5. You'll now only ever see python using default compilers (gcc), and you must set the _PYTHON_SYSCONFIGDATA_NAME to the appropriate filename to have the new compilers used. Setting this variable is something that we'll put into the activate scripts for the compiler package, so you'll never need to worry about it. It may take us a day or two to get new compiler packages out, though, so post issues on the conda-build issue tracker if you'd like to use the new compilers and need help getting started.
Relevant code changes are at:
py27: https://github.com/anacondarecipes/python-feedstock/tree/master-2.7.14
py35: https://github.com/anacondarecipes/python-feedstock/tree/master-3.5
py36: https://github.com/anacondarecipes/python-feedstock
The solution that worked for me was to use the conda to install the r packages:
conda install -c r r-tidyverse
or r-gggplot2, r-readr
Also ensure that the installation is not failing because of admin privileges.
It will save you a great deal of pain
After upgrading Golang to 1.19.1, I started to get:
# runtime/cgo
cgo: C compiler "x86_64-conda-linux-gnu-cc" not found: exec: "x86_64-conda-linux-gnu-cc": executable file not found in $PATH
Installing gcc_linux-64 from the same channel, has resolved it:
conda install -c anaconda gcc_linux-64
Somewhere in your $PATH (e.g., ~/bin), do
ln -sf $(which gcc) x86_64-conda_cos6-linux-gnu-gcc
Don't put this in a system directory or conda's bin directory, and remember to remove the link when the problem is resolved upstream. gcc --version should be version 6.
EDIT: I understand the sentiment in the comments against manipulating system paths, but maybe we can use a little critical thinking for the actual case in hand before reciting doctrine. What actually have we done with the command above? Nothing more than putting an executable (symlink) called x86_64-conda_cos6-linux-gnu-gcc in one's personal ~/bin directory.
If putting something in one's personal ~/bin directory broke future conda (after it fixes the C compiler path to point to gcc it embeds), then that would be a bug with conda. Would the existence of this verbosely named compiler mess with anything else? Unlikely either. Even if something did pick it up, it's just your system gcc after all...
Wondering if anyone has had any luck running logstash on Windows 10. I can get the simple stdin input and stdout outputs to work, but I can't install any additional plugins. For example, running .\logstash-plugin.bat install logstash-input-heroku yields this output:
Validating logstash-input-heroku Installing logstash-input-heroku
Error Bundler::InstallError, retrying 1/10 An error occurred while
installing net-ssh (4.0.1), and Bundler cannot continue. Make sure
that gem install net-ssh -v '4.0.1' succeeds before bundling.
WARNING: SSLSocket#session= is not supported Error
Bundler::InstallError, retrying 2/10 An error occurred while
installing net-ssh (4.0.1), and Bundler cannot continue. Make sure
that gem install net-ssh -v '4.0.1' succeeds before bundling.
WARNING: SSLSocket#session= is not supported
(etc.)
I don't see windows 10 in the logstash support matrix so I'm guessing it's not intended to work. Perhaps on the linux subsystem for windows? Has anyone tried that? Doesn't look like java8 runs on it.
Well installation seems to have now succeeded. Thanks #Darth_Vader for the suggestion. Here's the source github issue that I referred to. The issue was resolved after updating the Gemfile (in logstash root folder) and changing the net-ssh and rest-client library versions:
# This is a Logstash generated Gemfile.
# If you modify this file manually all comments and formatting will be lost.
source "https://rubygems.org"
gem "net-ssh", "2.9.0"
gem "rest-client", "1.7.2"
gem "logstash-core", :path => "./logstash-core"
(etc...)
I installed the luarocks package on Linux Mint, and afterwards installed a couple of rocks such as sudo luarocks install telescope, but when running a script via lua script.lua, require cannot find the module.
Meta: Doing this Q&A style, because while questions that answer this exist, none seem to be generically titled or easily findable, and I hope that I can help someone with this.
In this specific case, the problem was simply that on my distribution, the default Lua version installed was at the time of writing this 5.2, whereas the LuaRocks package was built for 5.1, meaning that Lua 5.2 could not find the rocks due to using different paths for modules.
The solution to the problem was downloading the LuaRocks source code from its github repository, and compiling it for 5.2
./configure --lua-version=5.2
make build
sudo make install
To make sure I can also install packages for LuaJIT, which as of the moment uses 5.1 libs, I have also executed the above lines with lua-version=5.1 beforehand (if I executed them after, the default luarocks command would point at the 5.1 build.
To build LuaRocks, you need liblua5.2-dev and/or liblua5.1-dev
The solution for me is this.
I try
eval "$(luarocks path)"
and it works.
Hope it works for others.
I'm trying to click ok in a javascript dialog in watir 3.0. I've simplified the code as best I can to this:
#ie.button(:id, "Associate Control Activity").click_no_wait
#ie.clickprompt
def clickprompt(btn="OK", txt="")
sleep 1 until javascript_dialog.exists?
#sleep 1 until javascript_dialog.button(btn).exists? #tried both
javascript_dialog.button(btn).click
end
I often get this, some scripts more than others (very intermittent):
C:/ruby/lib/ruby/gems/1.8/gems/rautomation-0.7.2/lib/rautomation/adapter/win_32/functions.rb:317: [BUG] Segmentation fault
ruby 1.8.7 (2012-06-29 patchlevel 370) [i386-mingw32]
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
OS is Win XP sp3. I call clickpompt often, some scripts use it repeatedly, but it doesn't always fail the 4th time I call it, sometimes the 2nd, etc. Do I need to do something differently? Thanks
This is caused by faulty ffi gem. You need to install newer version of that gem for that problem to be solved. At least version 1.1.3 is needed.
The original issue can be seen here https://github.com/ffi/ffi/issues/213
Just execute the command:
gem install ffi
Or if you're using Bundler, then add this to your Gemfile:
gem "ffi", "~>1.1.3"
And execute:
bundle update ffi
I'm using gem bundler (v.0.9.6) and Rails 2.3.5, rubygems 1.3.6 and ruby 1.8.7 (On Snow Leopard). My Gemfile looks like this:
source :rubyforge
source "http://gems.github.com"
gem "rails", "2.3.5"
gem "ruby-debug"
gem "activemerchant", :require => 'active_merchant'
gem "hpricot"
gem "nokogiri"
gem "state_machine"
gem "fastercsv"
gem "yubikey"
gem "httparty"
gem "ruby-openid"
gem "mongrel"
group :development do
gem 'mongrel'
end
#teste
group :test do
gem 'rspec'
gem 'rspec-rails'
gem 'cucumber'
gem 'cucumber-rails'
gem "mechanize"
gem 'notahat-machinist', :require => 'machinist'
gem 'faker'
gem 'webrat'
gem 'selenium-client'
gem 'database_cleaner'
gem 'fakeweb'
gem 'mongrel' #Selenium needs this
end
So far so good. I've been using bundler successfully for a couple of weeks already. However, I started using Cucumber and WebRat in the Selenium mode to test some ajaxy features of the site, and whenever I was running the feature, WebRat was telling me that the Rails server was started, but I always got a XHR_ERROR, where Selenium couldn't find the URL. Well, it happened the server was not being started.
Then, I opened the webrat/lib/webrat/selenium/application_servers/rails.rb file and put a debugger statement in start method. Ran the feature again, when the debugger triggered, I printed the return of the start_command def, which was:
mongrel_rails start -d --chdir='/Users/fullofcaffeine/Projetos/myproject' --port=3001 --environment=test --pid /Users/fullofcaffeine/Projetos/myproject/tmp/pids/mongrel_selenium.pid
I copied and pasted it in the console, removed the -d and & from the end, and here's the output I got:
** Rails loaded.
** Loading any Rails specific GemPlugins
/Library/Ruby/Gems/1.8/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require': no such file to load -- /Users/fullofcaffeine/.bundle/ruby/1.8/gems/mongrel-1.1.5/lib/mongrel/init.rb (MissingSourceFile)
from /Library/Ruby/Gems/1.8/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require'
from /Library/Ruby/Gems/1.8/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:in `new_constants_in'
from /Library/Ruby/Gems/1.8/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require'
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:134:in `load'
from /Library/Ruby/Site/1.8/rubygems/source_index.rb:241:in `each'
from /Library/Ruby/Site/1.8/rubygems/source_index.rb:241:in `each'
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:112:in `load'
from /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:231:in `load_plugins'
from /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:117:in `cloaker_'
from /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:149:in `call'
from /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:149:in `listener'
from /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:99:in `cloaker_'
from /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:50:in `call'
from /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:50:in `initialize'
from /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:84:in `new'
from /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:84:in `run'
from /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in `run'
from /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281
from /usr/bin/mongrel_rails:19:in `load'
from /usr/bin/mongrel_rails:19
Check the path it is trying to load mongrel from: "~/.bundle/...", but mongrel is installed as a system gem. Bundle handles the loading of system gems fine for in other context, but in this particular case, I have no idea why it is failing :(.
I've tried to run "bundle install" again, and it always says:
Installing mongrel (1.1.5) from system
gems
I've tried uninstalling mongrel from the system to try to make bundle to install it on ~/.bundle (as this seems the source of the error, since mongrel is being searched in this path I start mongrel_rails like above), but I just couldn't do it.
gem uninstall mongrel
ERROR: While executing gem ... (Gem::InstallError)
cannot uninstall, check `gem list -d mongrel`
And when I run "gem list | grep mongrel", I get:
mongrel (1.1.5)
Weird.
I just want to be able to run Cucumber and WebRat + Selenium successfully while using gem bundler, but this is driving me nuts.
Could anyone enlighten me ?
Well, I found an workaround, kind of fishy, but works:
cp /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/ mongrel-1.1.5
Now, if you try to:
mongrel_rails start --chdir='/Users/fullofcaffeine/Projetos/myproject' --port=3001 --environment=test --pid /Users/fullofcaffeine/Projetos/myproject/tmp/pids/mongrel_selenium.pid
It will find mongrel and start the server, you can then run the Cucumber feature that uses Selenium and it will work :)
If someone else finds out or knows anything else about this issue, please share, this might end up being a bug somewhere.
I had a similar problem, but it turned out to be mismatching versions of gems between what was in my /Users/{account}/.gems/ and what was installed in either /Library/Ruby/Gems/ (default install) or in /opt/local/lib/ruby/gems/ (the Mac Ports install). As soon as I deleted the /Users/{account}/.gems/ it all worked.
I encountered this same problem, and spent a while trying to debug it. It appears that there's some kind of interaction between Mongrel, GemPlugin and Bundler. Possible solutions include:
Fix GemPlugin to play nicely with Bundler 0.9.
Modify Mongrel to no longer use GemPlugin.
Modify Webrat to support a web server other than Mongrel.
Since both GemPlugin and Mongrel are looking somewhat obsolete and abandoned these days, I decided to add Thin support to Webrat based on this patch.
You can find the new patch on github, or add the following to your Gemfile:
gem 'webrat', :git => 'git://github.com/emk/webrat.git'
...and update your features/support/env.rb file accordingly:
Webrat.configure do |config|
# Add this line.
config.application_framework = :rails_thin
# Your previous configuration here...
end
bundle exec mongrel_rails start ... ?
The point here is to load the rails gems from the bundle as well not from the system gemenv.
We have a similar scenario which was written up here:
How to get mongrel working with bundler?
Try to locate the gems directory which the current gem executable is using and delete any residue from cache or specifications directories, that should work.